Hey! I'm David, a security consultant at Cryptography Services, the crypto team of NCC Group . This is my blog about cryptography and security and other related topics that I find interesting.

# Generating randomness and you're too close to boot?

## posted July 2016

If you want to generate good randomness, but are iffy about /dev/urandom because your machine has just booted, and you also don't know how long you should wait before /dev/urandom has enough entropy, then maybe you should consider using getrandom (thanks rwg!). From the manpage:

By default, getrandom() draws entropy from the /dev/urandom pool.

If the pool has not yet been initialized, then the call blocks

Also it seems like the instruction RDRAND on certain Intel chips returns "true" random numbers. It's also interesting to see that it was audited twice by Cryptography Research, which resulted in two papers, the recent one being in 2012 and done by Kocher et al: Analysis of Intel's Ivy Bridge Digital Random Number Generator.

comment on this story

# Generating one's own elliptic curve.

## posted July 2016

Dear Mr.DAVID
I am learning about generating an elliptic curves cryptography , in your notes I find:-
JPF: Many people don’t trust NIST curves. How many people verified the curve generation? Open source tools would be nice.
Flori: people don't trust NIST curves anymore, surely for good reasons, so if we do new curves we should make them trustable. Did anyone here tried generating nist, dan, brainpool etc...? (3 people raised their hands).
Would you give me some reasons for generating our own curves? what are the good reasons that some people do not trust on NIST CURVES?
hager

Hello Mr. HAGER

Well, the history of how standard curves were generated has been pretty chaotic, and djb has shown that this might be a bad thing for us in his Bada55 paper.

NIST says that they generated their curves out of the hash of a sentence that is unknown and lost. The german Brainpool curves seem to ignore their own standards on how to generate secure curves.

one of the standard Brainpool curves below 512 bits were generated by the standard Brainpool curve-generation procedure

So how bad is it? We know that choosing random parameters for your crypto algorithms can lead to unsecure or even backdoored constructions. See how to choose Sboxes in DES, how to choose nothing-up-my-sleeve numbers for hash functions, how to choose secure parameters for Diffie-Hellman, how Dual EC is backdoored if you know how the main points P and Q were generated, ...

Well, so far we don't really know. The fact that we haven't been able to crack any of the curves we use is "reassuring". I like to look at bitcoin as a proof that at least one of them hasn't been broken :) But as many researchers suspect, the NSA might be years ahead of us in cryptanalysis. So it is possible that they might have found one (or more) issues with elliptic curve cryptography, and that they generated "weak" curves before publishing them through NIST's standards.

So far, there hasn't been enough advances in ECC (a relatively old field in cryptography) to make you worried enough to generate your own curves. Some people do that though, but they know what they're doing. They even released a paper on how to generate safe curves using nothing-up-my-sleeves parameters. Like that, you can review the generation process and see that nothing was done to harm you.

Some people also worry about sparse primes, and that's one more paranoid reason to use random curves as above.

But seriously, if you don't want to go through all the trouble, you should probably start using one of the curve specified in this RFC: Curve 25519 or Curve 448. They use state-of-the-art research, reproducible generation and have been vetted by many people.

comment on this story

# Blackhat + Defcon

## posted July 2016

Blackhat and Defcon are almost here! I'll be landing there on Friday 29th and will give a crypto training at Blackhat, then on the 5th will give a talk at the Defcon Village track about Diffie-Hellman and backdoors.

If you have any interest in cryptography and want to meet up say the word! We should probably organize a drunk cryptographer evening (anyone interested?)

Also, I should be looking in what talks are interesting, if you think a particular one is please share in the comment section =)

comment on this story

# I talked at the NCC Group open forum

## posted June 2016

I was at the offices of Braintree this evening, talking about the history of TLS, backdoors and Diffie-Hellman. If you missed it, my paper was released a few days ago and this is the talk that is packaged with it =)

my colleagues and I preparing the event in the beautiful atrium of Braintree

starting the talk!

Someone asked me for the slides, you can find them on the github repo. You can find the .keynote file as well containing videos (but you need osx).

I'll be looking into submitting this talk to conferences, if you have any idea where I'll be happy to hear suggestions =)

# How to Backdoor Diffie-Hellman is on ePrint

## posted June 2016

My latest whitepaper just got published on ePrint. It's available here.

Looking to seek answers to the recent Snowden revelations and the history of state agencies backdoors, this paper looks at what the secret spies might have been researching in order to find new ways to observe and tamper with the people's traffic. What if we just sabotaged one of the most trusted cryptographic algorithm of the last 40 years? What if we backdoored Diffie-Hellman?

comment on this story

# Interested in Crypto and living in Chicago?

## posted June 2016

Next week on wednesday NCC Group will host its second open forum in Chicago. And I'll be one of the speaker!

If you are interested in crypto, I'll be talking about backdoors and Diffie-Hellman. This will be the occasion of explaining what my latest whitepaper that was released today is about.

John Downey will also be talking about "Cryptography Pitfalls".

By the way, if you're interested in such events in Chicago. OWASP was today (and we even learned how to brew beer there). There are also other security related events that you can get update on from this twitter.

comment on this story

# DTLS and Finished messages

## posted June 2016

Sorry i am using DTLS 1.2 instead TLS 1.2. Kindly explain the structure of finished message, like how many bytes for "nonce", how many bytes are encrypted data and how many bytes for authentication tag.

I'm writing this because I want to clear things up: you can ask me pretty much anything and I'll do my best to answer here. So please ask away if you have a question in crypto! There is also a contact form for that.

## Differences between DTLS and TLS

TLS is an application layer protocol. Some people say that it's a transport layer protocol. This is false. It runs in whatever program you are using on top of TCP/UDP. Although it is used to transport the real content of the application: it can be seen as an intermediate transport layer running in the application layer.

The TLS we know, the one that runs in our browser, typically runs on top of TCP. But in some situations, the developer might want to use UDP to exchange packets. Since UDP forgives packet loss (think multiplayer video games or audio/video conferences), it is important that TLS is setup accordingly to forgive those packet loss as well. For this, we use a similar but different specification than TLS: DTLS.

DTLS is what you use if you need TLS on top of UDP.

The main DTLS RFC documents the differences with TLS. Most of them are modification to the protocol so that the connection doesn't terminate/break if a message is lost, duplicated, out of order, etc...:

• records can't be split into several datagrams
• the sequence number is written in each record
• errors (duplicates, loss, out of order) are tolerated
• no stream cipher can be used (no state can be used if errors are tolerated)
• protections against DoS attacks (apparently DTLS has some problems with DoS attacks)
• ...

## Finished messages

The simplest TLS handshake goes like this:

• the client sends its ClientHello packet
• the server replies with his ServerHello packet
• the client sends (his part of) the shared secret in a ClientKeyExchange packet

Now I omitted a bunch of packets that are usually part of the handshake as well. For example:

• the server usually sends his certificate after the ServerHello message.
• the server might also take part in the creation of the shared secret in some modes (including ephemeral modes)

But this is not what is interesting to us here.

After enough messages have been sent to compute the shared secret, a ChangeCipherSpec message is sent by both the client and the server to announce the beginning of traffic encryption. Followed directly by an encrypted Finished message authenticating all the previous handshake messages.

In my knowledge, the Finished message is the only encrypted message of a handshake. It is also the moment where the handshake is "authenticated" and where Man-In-The-Middle attacks usually stop.

Now what is in that Finished message?

Exactly the same things as in TLS. The TLS 1.2 RFC shines a bit more light on the subject:

struct {
opaque verify_data[verify_data_length];
} Finished;

verify_data = PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1];

finished_label =
For Finished messages sent by the client, the string "client finished". For Finished messages sent by the server, the string "server finished".

Don't forget that this Finished structure is then encrypted before being sent in a record. The Hash and the PRF we already defined in previous posts, the handshake_messages value is what interest us: it is the concatenation of all the binary data received and sent during the handshake, in order, and not including this Finished one.

Now DTLS has the particularity that some messages are re-sent, out of order, etc... so duplicates must be ignored, real order must be preserved.

## How do I know that?

Besides reading the RFC, you might often want to know what's happening for real. To be a bit more informative, let me tell you how I quickly get that kind of information when I'm curious:

• I setup a server key + certificate: openssl req -x509 -new -nodes -keyout key.pem -out server.pem.
• I start the server: openssl s_server -dtls1 -key key.pem -port 4433 -msg.
• I connect to it with a client: openssl s_client -dtls1 -connect localhost:4433 -msg.

The -msg argument will print out the exact content of the messages sent. In the case of the Finished message, it will show the unencrypted hexadecimal data sent. If you want to see the real encrypted data that is sent, you can use the -debug option.

You might also want to have a bit more information about every records. A good way to do this is to record the traffic with tcpdump: sudo tcpdump udp -i lo0 -s 65535 -w handshake.pcap and to open the .pcap file in Wireshark and enter udp && dtls in the filter area.

# Crypto training at Black Hat US 2016

## posted May 2016

I'll be in Vegas for the next Black Hat USA giving a crypto training with my coworkers Javed Samuel and Alex Balducci.

You have a nice summary on the official training page.

It's 2 days crash course on our knowledge as crypto consultants. There will be a lot of general culture, protocols, side-channels, random numbers, ... as well as deep segments and exercises on common crypto attacks.

If you're not interested, you can still hit me up for drinks around Black Hat or Defcon, I'll be in Vegas. Otherwise I'll be in Santa Barbara a few week after for CRYPTO and CHES. If you're in need of crypto conference, there is also SAC happening in Canada between Defcon and CRYPTO (I won't be there).

comment on this story

# Referencing eprint papers

## posted May 2016

Just realized that each ePrint paper has a BibTeX snippet to reference the paper in your own work. If you don't know what I'm talking about, I'm talking about that:

Go on any paper's page and click on the BibTeX Citation link. The snippet needs to be included in a .bib file and referenced from the your main .tex

@misc{cryptoeprint:2015:767,
author = {Daniel J. Bernstein and Tanja Lange and Ruben Niederhagen},
title = {Dual EC: A Standardized Back Door},
howpublished = {Cryptology ePrint Archive, Report 2015/767},
year = {2015},
note = {\url{http://eprint.iacr.org/}},
}

# How Gavin Andresen was duped into believing Wright is Satoshi

## posted May 2016

I won't be talking about how weird Wright is, how he was debunked a multitude of times, and how you shouldn't believe the press.

What I will be talking about, is how Gavin Andresen, a main bitcoin developer, could have been duped into thinking Wright was Satoshi:

I believe Craig Steven Wright is the person who invented Bitcoin.

First. How weird is it that instead of just signing something with Satoshi's public key and releasing it on the internet, Mr. Wright decides to demo a signature verification on closed door to TV channels, magazines and some bitcoin dev on a trip to London? From reddit, Gavin wrote:

Craig signed a message that I chose ("Gavin's favorite number is eleven. CSW" if I recall correctly) using the private key from block number 1. That signature was copied on to a clean usb stick I brought with me to London, and then validated on a brand-new laptop with a freshly downloaded copy of electrum. I was not allowed to keep the message or laptop (fear it would leak before Official Announcement).

That last sentence... is the rule number one in a magic trick or scam.

Now people are pointing out from the blogpost this intentional mistake in Wright's script to verify a signature:

Looks like the signature is also taken from an old transaction, so Wright is re-using a signature to prove he verified "something". Except he swapped the something.

Another way he might have done it, on his website he also has a oneliner:

>> base64 –decode signature > sig.asn1 & openssl dgst -verify sn-pub.pem -signature sig.asn1 sn7-message.txt

But the & sign is a single one instead of &&, making the two commands run at the same time instead of running the second command after the first one.

Someone else points at other tricks, like using doppelganger letters from the UTF-8 set of characters to trick someone in a demo.

myvar = "foo"
myvаr = "bar"  # This is a *different* variable.

print("first one:", myvar)
print("second one:", myvаr)

The amount of sleigh of hands that could have been done here is actually really interesting. We have cryptographic signatures so that we don't need to believe in human lies, but if the human is in between you and the verification of the signature, then good luck!

Also that python script makes me think of using this as a proof of concept backdoor.

comment on this story

# The Noise Protocol Framework

## posted April 2016

WhatsApp just announced their integration of the Signal protocol (formerly known as the Axolotl protocol). An interesting aspect of it is the use of a TLS-like protocol called Noise Pipes. A protocol based on the Noise protocol framework, a one-man work led by Trevor Perrin with only a few implementations and a moderately long specificiations available here. I thought it would be interesting to understand how protocols are made from this framework, and to condense it in a 25 minutes video. Here it is.

comment on this story

# The Juniper paper is out!

## posted April 2016

The Juniper paper is going to be a big deal

That's what I wrote at the end of Real World Crypto, 2 days after Hovav Shacham talked about the subject at the same conference.

If you have no idea what Juniper is or what happened here, go check the blogpost I wrote on the subject.

The paper is available on eprint. titled A Systematic Analysis of the Juniper Dual EC Incident, it contains some background on Dual EC, IKE and a timeline of event that should read like a nice story. This is the paper you're going to read next week! So go print it now =)

comment on this story

# CVE-2016-3959

## posted April 2016

CVE-2016-3959 also called the golang infinite loop just triggered a new version of the language Go. The cherry on the cake is that it was discovered by me!

The issue was announced here on github, and in a bunch of different places. Here's a short Q/A to explain what's up:

Q: What's vulnerable?

A: Anything that uses the big.Exp function concurrently where the modulo parameter can be controlled by an attacker. For crypto this means mostly DSA and RSA which are used for example in TLS and SSH, as well as many other cryptographic applications, like recently in the Let's Encrypt client (hope they patched). ECDSA also use the big.Exp function but this elliptic curve version of DSA usually does not use custom curves so the attacker has usually no known way to make someone compute calculations over his curves parameters if they are non-standard.

Q: What's big.Exp?

A: It's the exponentiation function of Go. Declared in the big number library of Go: big.

func (z *Int) Exp(x, y, m *Int) *Int

Q: What's a big number library?

A: Programming languages have int types that can usually hold integers up to 64bits (For example, in C this type is called uint64_t). But crypto needs numbers that are much bigger than that, up to 4000 bits sometimes. So big number libraries are the libraries used to play with numbers of such sizes without getting a headache =)

Q: What was the problem with big.Exp?

A: It was a pretty simple one, the lack of a zero check for the modulus made the calculation turn into an infinite loop. Interestingly the developers of Go did not patch the vulnerability by adding the zero check inside of big.Exp but did it inside of the implementations of DSA, RSA and ECDSA. This means that other cryptographic functions or non-cryptographic functions that employ this big.Exp function, concurrently, with the third parameter controlled by the user, might still be subject to DoS attacks.

If you have any other questions feel free to ask! The comment section is here for that ;)

# Some Q/A on phone security

## posted March 2016

There is an excellent blogpost here on how would you go about getting into an encrypted phone.

I asked some questions to one of the co-author Adwait Nadkarni, I thought that it might be interesting to others:

But offline attacks can also be much harder, because they require either trying every single possible encryption key, or figuring out the user’s passcode and the device-specific key (the unique ID on Apple, and the hardware-bound key on newer versions of Android).

Q: I don't understand why you would have to guess that HBK, can't you just access it on the phone?

A: Thats a good question. To prevent the security from only being dependent on the user-supplied passcode, the HBK is supposed to be inaccessible from most software, similar to the iOS device-specific UID. That is, the HBK is supposed to be accessible only via the trusted executable environment (TEE), that is isolated on a different microprocessor. Untrusted software (even with compromise of the main kernel) is not supposed to be able to directly access the HBK.

That said, the reality is manufacturer-dependent. The TEE on different devices has been repeatedly compromised (Qualcomm TEE implementation compromised in 2014, HTC in 2015, etc.). Thus, there is threat of software compromise that may allow the attacker to retrieve or misuse the HBK.

Q: Is the secure enclave on the recent iPhones that TEE? Does that mean that most phones are vulnerable to offline brute force attacks? (since most phone don't have TEE (I'm not sure about that) and have a 4-6 digit PIN instead of an alphanumeric password)

A: The TEE is for Android; iOS uses secure enclave similarly. Most phones that do not use a device-specific key (i.e., old Android devices that run <Android 4.4, very old iOS devices) are vulnerable to offline brute-force attacks. Most phones (even old ones like our Nexus 4) do have TEE.

We built our own MDM application for our Android phone, and verified that the passcode can be reset without the user’s explicit consent; this also updated the phone’s encryption keys. We could then use the new passcode to unlock the phone from the lock screen and at boot time

Q: if you do that, the content on the phone would have to be decrypted with the real passcode and re-encrypted with your new passcode. I would imagine that the real passcode is not stored anywhere (there should be a password hash stored instead for verification only), so how does that technique works for the decryption phase? (don't know if the question is clear enough)

A: The phone is not directly encrypted with the passcode, but with a randomly generated DEK. The DEK is then encrypted with the KEK, which in turn is generated from the passcode and the HBK. Now, when the passcode is changed, the phone decrypts the DEK with the old KEK, then recreates the new KEK with the new passcode and HBK, and re-encrypts the DEK with the new KEK. Data is not touched when the passcode changes.

Q: so, specifically then, how does the phone uses the old KEK if it doesn't have the old passcode?

A: The old KEK is not created on the fly, but stored in the hardware-backed keystore (accessible only via the TEE). The TEE can retrieve it to decrypt the encrypted DEK.

Generally, operating system software is signed with a digital code that proves it is genuine, and which the phone requires before actually installing it.

this part made me wonder, what if we used lasers? Fault attacks are a big thing in the smart card industry, why is no one talking about it for cellphones? This prompted me to ask Frederico Menarini from Riscure:

Q: In iOS or Android if you want to update the phone, the update needs to be signed with Apple or Google or Samsung, etc... update key. But what you could do if you could mount a fault attack (lasers?) would be to target the point where the cellphone refuses the patch because of a false signature.

A: In principle, fault attacks are possible on phones – nothing prevents it and the scenario you described is valid. Laser attacks might be challenging though because certain chips use package-on-package or chip stacking, which means that you might not be able to directly affect the CPU using light.

In general attacking mobile phone chips will be complicated because they run at extremely high frequencies compared to smartcards (smartcards rarely run faster than 50 MHz) and because the feature size is much smaller (state of the art in smartcards is 90nm, which makes targeting the right area of the chip with a laser easier).

comment on this story

# Demo of the Diffie-Hellman backdoor

## posted March 2016

Here's a little demo of my work in progress research =)

The top right screen is the client, the bottom right screen is the server. I modified two numbers in some Socat file (hopefully it will be one number soon) and the backdoor is there. It's a public value and both the server and the client can generate their own certificates and use them in the TLS connection. For simplicity I don't do that, but just know that it would change nothing.

To get a Man-in-the-middle position I took the simplest approach I could think of: the screen on the left is a proxy, the client connect to the server through the proxy.

You will see that the proxy on the left will start parsing the server and the client packets as soon as it sees a TLS handshake. It then collects the server and the client Randoms, the server and the client DH public keys, and the DH parameters of the server to check if the backdoor is there. You will see a red message displaying that indeed, the backdoor is present.

For simplicity again (this is a proof of concept) I only use TLS 1.2 with AES128-CBC as the symmetric cipher and SHA-256 as the hash function used in the PRF/MAC/etc...

In a few seconds the premaster key, then the master key, then the MAC and encryption keys are computed and the traffic is then decrypted live.

comment on this story