Get Ready for The 2017 Underhanded Crypto Contest

The Underhanded Crypto Contest is back, and we can’t wait to see all the nifty tricks you’ll come up with to put backdoors into cryptography. Last year we wanted to see backdoors that exclusively related to cryptocurrencies, and we didn’t get much of a response. So, this year, we’re open to any kind of crypto backdoor that you can think of.

To give you all a head start, here are a couple of ideas:

  1. Backdooring random number generators. Suprisingly, we’ve only ever had one submission for a backdoored random number generator, back in 2014 by Solar Designer. Random number generators are important to almost every aspect of cryptography, so they’re a great thing to backdoor. And it’s hard to tell when a number is random and when it isn’t, so there’s lots of room to add an undetectable backdoor.

  2. Deceptive APIs. A lot of design work in modern cryptography goes into making crypto library APIs easy to use, or more importantly hard to misuse. To do that, we need to better understand why some APIs are more susceptible to being used incorrectly. So, here’s a challenge: Design a crypto library API that looks like something developers would want to use, but that would probably end up being used wrong (in an insecure way) in practice.

You definitely don’t have to pick one of these ideas for your own entry, but we’re really curious to see just how far these ideas can be taken.

If you’d like to participate, have a read over the contest rules, and then sign up for our (very low traffic, zero spam) participant mailing list so that we can
send you updates.

Sign up for the 2017 Underhanded Crypto Contest (Mailchimp Form)

Also, if you’re interested in being a volunteer judge for this year’s contest or would like to show that your company supports cryptography research by sponsoring one of the prizes, please get in touch at [email protected].

The deadline is going to be July 1st this year. That’s only a few months away, so the time to start working on your entry is now!

Rules for the 2017 Underhanded Crypto Contest

Rules for the 2017 Underhanded Crypto Contest

Introduction

The Underhanded Crypto contest was inspired by the famous Underhanded C Contest, which is a contest for producing C programs that look correct, yet are flawed in some subtle way that makes them behave inappropriately. This is a great model for demonstrating how hard code review is, and how easy it is to slip in a backdoor even when smart people are paying attention.

The Underhanded Crypto Contest is the same but for cryptography. We welcome backdoors in implementations of cryptography (in any language) as well as backdoors at the design level so that any implementation of the design would contain a weakness.

Topic

This year, we’re accepting all kinds of submissions, as long as they have something to do with cryptography. Your entry can take the form of a patch to the code of an existing cryptography project, a description of the way you could modify an existing design to add a backdoor, your own design for an entirely new cryptosystem, or anything you’d like. Of course, entries that come with a proof of concept implementation or are very well explained are most likely to be rated highly by our judges.

To help you out, here’s are a couple of categories we’d like to see submissions for this year.

  1. Backdooring random number generators. Suprisingly, we’ve only ever had one submission for a backdoored random number generator, back in 2014 by Solar Designer. Random number generators are important to almost every aspect of cryptography, so they’re a great thing to backdoor. And it’s hard to tell when a number is random and when it isn’t, so there’s lots of room to add an undetectable backdoor.

  2. Deceptive APIs. A lot of design work in modern cryptography goes into making crypto library APIs easy to use, or more importantly hard to misuse. To do that, we need to better understand why some APIs are more susceptible to being used incorrectly. So, here’s a challenge: Design a crypto library API that looks like something developers would want to use, but that would probably end up being used wrong (in an insecure way) in practice.

You are not required to to work within these categories, and entries in these categories will not automatically be ranked any higher than unrelated entries.

Submitting

To submit an entry to the contest, simply email it to [email protected]. We’re
accepting submissions from now up until July 1st.

To make the process easier for our volunteer judges, we ask that you put your submission in the following format. Please send your entry as a compressed folder (.tar.gz, .tar.bz2, .zip, .7z, etc.) with the following structure:

  • README-JUDGES.txt – An explanation of your submission for the judges to read. This must explain what all the files in the submission/ folder are.
  • AUTHORS.txt – The list of people who worked on your entry. See the template below.
  • LICENSE.txt – The open source license your submission is released under (CC0, GPL, MIT, BSD, etc.)
  • submission/ – A directory containing the technical contents (code, etc.) of your submission.
  • (OPTIONAL) blogpost/ – This is totally optional, but if you’d like us to post your explanation of our entry on our blog, you can include a “blog post style” explanation here. Please write your blog post in either plain text or markdown. You can include some images too if they’ll help explain your entry. We can’t guarantee that we’ll publish it, but if it’s well-written and explains something neat, there’s a high chance we will!

README-JUDGES.txt must explain what the stuff in the submission/ directory is, and must completely reveal the weakness in your entry (don’t try to make the judges find your backdoor!). In this file, explain to the judges what your entry does, why it’s hard to detect, and why it is a valuable entry that deserves to win. Keep it succinct please, our judges are volunteering their time!

The AUTHORS.txt file should contain the following contents for each member of your team (or just yourself if you’re working alone). The authors will be listed on the website in the same order you place them in this file, so it is up to you if you want to put them in order by contribution or alphabetical.

Which author is the primary contact for your team (required if you have multiple authors)?

Author #1
=========

Which email address should we use to contact you? (required)

What name / pseudonym would you like us to use for you on our website (required)?

Is there a website you'd like us to link to on our website when we mention your name (optional)?

What's your Twitter handle (optional)?

Author #2
=========

... repeat the questions for each author ...

Plagiarism is strictly forbidden. You are encouraged to build on previous work, but if you fail to cite it or don’t explain how your work is different from what came before, your submission will be rejected.

Prizes

We’re working on getting some sweet cash prizes for this year’s winners.

Judging

Judging is done at our discretion. The judges will be volunteers (usually cryptography/infosec experts) who are independent from the contest organizers, and they will be free to judge the entries in a fair way that’s compatible with the amount of time they are willing to devote to the contest.

Announcing the Winners

We’ll announce the winners around the same time as DEF CON 25 (late July).

Eligibility

The contest organizers and judges are not eligible to participate in the contest. Prizes may not be available should the winner(s) live in a country subject to embargo by the United States or Canada, or due to other legal restrictions. In the event that prizes can not be awarded due to legal restrictions, the contest organizers will make a good faith effort to resolve the situation within the applicable laws; if it is determined that the situation is not reasonably resolvable, the prizes will be donated to an appropriate charity.

If a winner does not wish to provide the identifying information necessary to deliver any prize(s) they have won, the prize(s) will be donated to an appropriate charity.

The 2016 Backdoored Cryptocurrency Contest Winner

Earlier this year, we opened a contest with a special focus on backdoors in cryptocurrencies. Despite offering a $500 first-place prize from our sponsor Zcash, and a $250 second-place prize from our sponsor NCC Cryptography Services, only one person sent in a submission. It’s a good one, though, and our judges agreed to award it the first-place prize.

Our sponsors:

 

Zcash Logo          NCC Group Logo

 

Here’s the slide deck for our talk at Crypto & Privacy Village, where we announced the winner. The winning entry is by nickler. You can download the entire entry here (12KiB). What follows is the author’s own explanation of their entry.

Nickler’s Explanation

F*** your shoebox money. Eleeterium is the next generation cryptocurrency. It offers perfect anonymity, infinite scalability, absolute decentralization and super-Turing hyper-complete smart contracts. Get your eleet coins and start profiting today. To do so just send all your bitcoins to burn address 3LEETmEZWJX9ULbsFQVgL2QgGCJHPZJVaJ to destroy them. This triggers the
creation of eleet coins and transfers them directly to your wallet. Coins sent to the burn address are provably unspendable. The address encodes the Bitcoin script <signature> OP_2 <pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG (*). It’s easy to see that the multisig requires signatures for both pubkeys. One signature is already provided in the script. Of course it’s impossible to
create a valid signature for a fixed pubkey without knowing the message. Therefore, this script’s evaluation can never succeed and coins sent to it are transferred irreversibly.

-q.e.d.

(*) You can verify that yourself by executing bitcoin-cli decodescript
 47304402203c5288058306b3bf5cd8202413b867e11588a351117a07b9929f41f693043623022017430fa896ff26763970aa9f0c169d48250ac274fe9b3313b37ea585a7358eda035221023b439207c8a0a082a5c5a968632be9a363f5e1a4150276604eedbaa4943f2650210316b0dbf710b8739eec21a806e7142db1755a0f902b79ccef3116c782a74a510652ae.

–cryptopirate42

 

Burn addresses have been used in Bitcoin to transfer value to another blockchain in a one-way fashion. The idea is that coins sent to the burn address are destroyed which allows to create a proportional amount on the alternative blockchain. For example 1CounterpartyXXXXXXXXXXXXXXXUWLpVr is a historical burn address that was used to bootstrap the counterparty system. Another burn address is 1111111111111111111114oLvT2 which would require a signature for a public key whose RIPEMD-160 hash is all zeros.

In contrast, the burn address used to bootstrap Eleeterium is created from a multisig script. In general, spending coins in a multisig address requires providing signatures for the public keys stated in the script. Let’s look a little bit deeper into what happens when Alice sends coins to the burn address. Alice creates a transaction TxA with an output out0 that contains the script and an integer denoting the amount of coins.

    +------------+        +------------+
    |       out0 +--------> in0   out0 |
    +------------+        +------------+
    TxA                   TxB

If Bob would want to spend this output, Bob creates a transaction TxB that has an input in0 containing a reference to TxA‘s output out0 in the form of a TxA‘s hash and out0‘s index. Additionally, the input has to contain the script (scriptSig) which makes referenced output script (scriptPubKey) evaluate to true. Bob effectively moves the coins by adding an output out0 to his transaction containing the public key of the receiver of the coins.

In the case of the burn address the encoded scriptPubKey is special because it already contains one of the two required signatures. The message for which the signature is verified is the hash of the transaction spending the coins (TxB). However, at the time of creation of the scriptPubKey, the hash of TxB can not be known to Bob because it contains Alice’s transaction hash. Therefore, the signature in the scriptPubKey must be invalid and there is no scriptSig that would allow spending the coins…

Exploiting the backdoor

Contrary to our expectation of signature schemes, the creator of the burn address is able to spend coins sent there because of a subtle bug in Bitcoin’s signature scheme known as SIGHASH_SINGLE bug. SIGHASH_SINGLE is a so called sighash flag. Sighash flags are appended to signatures and determine which part of the transaction is hashed and therefore which part of the transaction is covered by the signature. The standard sighash flag SIGHASH_ALL indicates that all outputs of the transaction are signed. Its counterpart is SIGHASH_NONE which to my knowledge does not have a use case as of today. A signature with the SIGHASH_SINGLE flag covers only the output that has the same index as the input containing the signature. This can be useful when multiple parties jointly create a transaction by independently adding their own input-output pairs. Consider the following transaction subgraph:

    +------------+
    |       out0 +---+
    +------------+   |    +------------+
    TxA              +----> in0   out0 |
                          |            |
                     +----> in1        |
    +------------+   |    +------------+
    |       out0 +---+    TxC
    |            |
    |       out1 |
    +------------+
    TxB

If the signature in input in0 of TxC has the SIGHASH_SINGLE flag then the signature covers output out0. What happens if a signature in input in1 has the SIGHASH_SINGLE flag and there is no corresponding output? It would be reasonable to assume that such a signature is invalid. And indeed Bitcoin’s SignatureHash function returns error code 1 in such a case. However, 1 is never interpreted as an error code but rather as the actual result of the hash function. What a classic bug!

It turns out that due to the SIGHASH_SINGLE bug the creator of the “burn” address is in fact in control of the coins. The python script appended to this article demonstrates insertion and exploitation of the backdoor using python-bitcoinlib and a private “regtest” Bitcoin network. In order to further investigate the resulting transactions, run bitcoin-cli -regtest getrawtransaction <txid> 1.

The scammer created the backdoored address in the following way: He generated two fresh key pairs (pubkey1, sk1), (pubkey2, sk2) and created a multisig script that requires a signature for pubkey1 and a signature for pubkey2. He used sk2 to sign the message 1, added the resulting signature with SIGHASH_SINGLE to the multisig script and converted the entire script to the “burn” address. The script requires multiple signatures to ensure that only he has access to the backdoor. Let’s assume Bob sends coins to the address in output out0 of transaction TxB. When the scammer decides to spend those coins, he creates a transaction TxC that spends an arbitrary output he has control over (TxA:out0) and the output sending to the “burn” address (TxB:out0). Because in1 has a greater index than out0, the signature for pubkey2 is valid and he just to provide a signature over TxC for pubkey1. This time he uses SIGHASH_ALL to protect from replay attacks against himself.

Bitcoin improvement proposal 141 (“Segregated Witness”) introduces a new signature scheme that fixes the SIGHASH_SINGLE bug. If there is no corresponding output to the input then SIGHASH_SINGLE will just behave like SIGHASH_NONE and not sign any of the outputs. In contrast to the old scheme, the input reference is included in the signature hash which makes Eleeterium backdoor impossible in the new scheme. However, segregated witness is backwards compatible (“softfork”) and therefore does not prevent messing with the SIGHASH_SINGLE bug. Segregated witness was merged into Bitcoin Core recently and will be fully deployed once the softfork activates.

nickler, 2016-06-30

Prizes for the 2016 Contest

Underhanded Crypto Contest participants put a lot of effort into their submissions, and it’s important for us to reward that effort. This year, we’ve worked out sponsorship agreements that let us give out cash prizes to the top two entries. See the contest rules for more information.

First Place Prize: $500 USD

The first-place prize of $500 USD is being provided by Zcash.

Zcash Logo

Second Place Prize: $250 USD

The second-place prize of $250 USD is being provided by NCC Cryptography Services.

NCC Group Logo

We’ve Extended the Deadline for the 2016 Contest

We, the organizers, have been super busy with other things this year, and haven’t been promoting the contest on social media as we’d have liked. With the current deadline of June 1, 2016 only days away, it would be unfair for us to start promoting the contest now. Everyone should have a chance to submit their best idea before we stop accepting submissions.

So we’re extending the deadline to June 30, 2016, giving you another month to work on your entries. We’ve updated the contest rules page with the new due date.

2016 Call for Judges

This year’s Underhanded Crypto Contest is about cryptocurrencies and the submission deadline is quickly approaching. We’re looking for volunteer judges competent in cryptography and/or cryptocurrencies to help us pick two winners (first place and second place) out of the submissions. Judges get early access to the submissions and work with each other to determine which of them contain novel ways of inserting weaknesses into cryptocurrency systems.

The process we used for judging the 2014 contest was too process-heavy and placed an undue burden on our judges’ time. This year, it should be a lot easier to judge since:

  • we’re only looking for two or three judges,
  • the new process is less formal and strict,
  • the submissions will come in a standardized format.

Judging will happen in July and must be finished by August. If you’re interested in being a judge, and you’re available in July, please email Taylor at [email protected].

2016 Call for Sponsors

Update (2016-06-06): The sponsors have been selected! See the 2016 prize announcement.

Sponsoring the 2016 Underhanded Crypto Contest is a great way to show that your organization supports innovative attack-oriented research into making cryptocurrencies more secure. We’re looking for a couple of organizations to sponsor the first and second place prizes for this year’s contest. The sponsorship options are:

  • Gold: $500 USD. One gold sponsorship slot is open which will be used for the first-place prize.
  • Silver: $250 USD. One silver sponsorship slots is open which will be used as the second-place prize.

The gold sponsor gets their company logo (with hyperlink) on the front page of our website until the 2017 contest begins. The hyperlinked logo will also be included in all future blog posts about the 2016 contest and its winners. The silver sponsor gets the same thing except the gold sponsor’s logo will be larger, distinguished as being the gold sponsor, and will come first on the page. Sponsor logos will also be displayed and mentioned in any talks we give about the 2016 contest.

Sponsors will be responsible for sending the U.S. dollar prize to the winners our volunteer judges select, and for their own tax implications of doing so. Contest winners will be responsible for their own tax implications of receiving the prize.

If you’re interested in being either a gold or silver sponsor, please email Taylor at [email protected]

Rules for the 2016 Underhanded Crypto Contest

Introduction

The Underhanded Crypto contest was inspired by the famous Underhanded C Contest, which is a contest for producing C programs that look correct, yet are flawed in some subtle way that makes them behave inappropriately. This is a great model for demonstrating how hard code review is, and how easy it is to slip in a backdoor even when smart people are paying attention.

The Underhanded Crypto Contest is the same but for cryptography. We welcome backdoors in implementations of cryptography (in any language) as well as backdoors at the design level so that any implementation of the design would contain a weakness.

Topic

This year’s contest is focused on cryptocurrencies. Your task is to put a subtle backdoor or weakness into a cryptocurrency, such that someone who knows about the weakness can use it to their advantage. The weakness should be hard to detect; imagine that you’re trying to insert it into the Bitcoin core code and that it will have to pass code review, or imagine that your idea will be submitted to an academic journal and will have to pass peer review. It doesn’t have to be completely undetectable, but the more damage you can do with as little chance of detection as possible, the better.

Your entry can take the form of a patch to the code of an existing cryptocurrency, a description of the way you could modify an existing design to add a backdoor, your own design for an entirely new cryptocurrency, or whatever. The only requirement is that there must be strong evidence that your backdoor will actually work. It is not enough to say “here’s a neat idea, and if you were to figure out these details it would work.” You must actually figure out the details! Of course, a working proof-of-concept is the best way to demonstrate your backdoor.

Submissions

To submit an entry to the contest, email it to [email protected]. We’re accepting submissions now, and the deadline for the 2016 contest is June 1, 2016 Extended to: June 30, 2016.

To make things easier for us and our volunteer judges, we require that you put your submission into the following format. Please send your submission as a compressed folder (.tar.gz, .tar.bz2, .zip. .7z, etc.) with the following contents:

  • README-JUDGES.txt – An explanation of your submission, for the judges to read.
  • AUTHORS.txt – The list of people who worked on your entry. See the template below.
  • LICENSE.txt – The open source license your submission is released under (CC0, GPL, MIT, BSD, etc.)
  • submission/ – A directory containing the technical contents (code, etc.) of your submission.
    • README-JUDGES.txt must explain what everything in this directory is!
  • blogpost/ – A directory containing a “blog post style” explanation of your entry. Please put the blog post contents in a plain text file. You may include images in this directory, too, if you want to use images to help explain your entry. Reference the image by its filename in the plain text file.

README-JUDGES.txt must explain what the stuff in the submission/ directory is, and must completely reveal the weakness in your entry (don’t try to make the judges find your backdoor!). In this file, explain to the judges what your entry does, why it’s hard to detect, and why it is a valuable entry that deserves to win. Keep it succinct; the judges don’t have unlimited time.

The blog post may be published on this website to help popularize your idea. Your audience when writing the blog post is a member of the infosec community who is interested in understanding your idea. Keep in mind that your reader might not have any formal background in cryptography or cryptocurrencies, so it may be necessary to give a higher level explanation than you did in README-JUDGES.txt. The blog posts will be published with you listed as the author, and can include a link to your website.

The entire contents of your submission must be under some sort of open source license. Good candidates are CC0, MIT, BSD, and GPL. Include the license text of the one you chose in LICENSE.txt. Assume everything you send us will be released to the public, but we will keep the entries secret until the judging is complete.

The AUTHORS.txt file should contain the following contents for each member of your team (or just yourself if you’re working alone). The authors will be listed on the website in the same order you place them in this file, so it is up to you if you want to put them in order of most-contributed to least-contributed or just alphabetical.

 

Which author is the primary contact for your team (required if you have multiple authors)?

Author #1
=========

What email address can we reach you at (required)?

What name / pseudonym would you like to be referred to by on the website (required)?

What website would you like us to link to (optional)?

What is your Twitter handle (optional)?

... Repeat the above for each author ...

Plagiarism is strictly forbidden. You are welcome to build on previous work, but if you fail to cite it or don’t explain how your work differs from it, your submission will be rejected.

Prizes

We don’t have any prizes lined up yet. We’ll be working with sponsors to try and get some cool prizes for the winners!

Judging

Judging is done at our discretion. The judges will be volunteers who are independent from the contest organizers, and they will be free to judge the entries in a fair way that’s compatible with the amount of time they are willing to devote to the contest. Not everyone will have time to look over all of the submissions, so it is the judges’ job to select the submission (or submissions) that are noteworthy and deserve to be highlighted.

Announcement of the Winners

The winners will be announced some time around the first week of August.

Eligibility

The contest organizers and judges are not eligible to participate in the contest. Prizes may not be available should the winner(s) live in a country subject to embargo by the United States or Canada, or due to other legal restrictions. In the event that prizes can not be awarded due to legal restrictions, the contest organizers will make a good faith effort to resolve the situation within the applicable laws; if it is determined that the situation is not reasonably resolvable, the prizes will be donated to an appropriate charity.

If a winner does not wish to provide the identifying information necessary to deliver any prize(s) they have won, the prize(s) will be donated to an appropriate charity.

2016 Underhanded Crypto Contest

The Underhanded Crypto Contest is back for another year!

This year we have a special theme: cryptocurrencies. A cryptocurrency is made up of lots of moving parts that interact with each other in subtle ways, so you have more room to play. There are both more components to target and more potential goals. Your backdoor could let you steal secret keys, steal currency, carry out double-spend attacks, inflate the value of the currency, de-anonymize transactions, and much more. You can do it by applying a classic backdoor technique to encryption code or do it more subtly by mucking with the consensus rules. As long as it has something to do with cryptocurrencies, it’s fair game.

Keep in mind that the world of cryptocurrencies is a vast space, larger than Bitcoin. Submissions that patch the Bitcoin core code are very welcome, but you’re also encouraged to attack altcoins and unimplemented academic work. You could even invent an entire cryptocurrency of your own. We’re excited to see what you do.

You can find the contest rules and instructions for submitting your entry here.