Real World Crypto: Day 3 posted January 2016

This is the 3rd post of a series of blogpost on RWC2016. Find the notes from day 1 here.

I'm a bit washed out after three long days of talk. But I'm also sad that this comes to an end :( It was amazing seeing and meeting so many of these huge stars in cryptography. I definitely felt like I was part of something big. Dan Boneh seems like a genuine good guy and the organization was top notch (and the sandwiches amazing).

SGX morning

The morning was filled with talks on SGX, the new Intel technology that could allow for secure VMMs. I didn't really understood these talks as I didn't really know what was SGX. White papers, manual, blogposts and everything else is here.

10:20pm - Practical Attacks on Real World Cryptographic Implementations

tl;dw: bleichenbacher pkcs1 v1.5 attack, invalid curve attack

If you know both attacks, don't expect anything new.

• many attacks nowadays are based on really old papers
  • BEAST in 2011 is from a 2004 paper
  • 2013/14 POODLE and lucky13 comes from a 2002 paper
  • 2012 xml encryption attack is from a 1998 bleichenbacher paper
• bleichenbacher attack
  • rsa-pkcs#1 v1.5 is used to encrypt symmetric keys, it's vulnerable to CCA
  • 2 countermeasures:
    • OAEP (pkcs#1 v2)
    • if padding is incorrect return random
  • padding fail in RWC: in apache WSS4J XML Encryption they generated 128 bytes instead of 128 bits of random
  • practical attacks found as well in TLS on JSSE, Bouncy Castle, ...
    • exception occurs if padding is wrong, it's caught and the program generates a random. But exception consumes about 20 microseconds! -> timing attacks (case JSSE CVE-2014-411)
• invalid curve attack
  • send invalid point to the server (of small order)
  • server doesn't check if the point is on the EC
  • attacker gets information on the discrete log modulo the small order
  • repeat until you have enough to do a large CRT
  • they analyzed 8 libraries, found 2 vulnerable
  • pretty serious attack -> allows you to extract server private keys really easily
  • works on ECDH, not on ECDHE (but in practice, it depends how long they keep the ephemeral key)
• HSM scenarios: keys never leave the HSM
  • they are good candidates for these kind of "oracle" attacks
  • they tested and broke Ultimaco HSMs (CVE-2015-6924)
  • <100 queries to get a key

11:10am - On Deploying Property-Preserving Encryption

tl;dw: how it is to deploy SSE or PPE, and why it's not dead

• lots of "proxy" companies that translates your queries to do EDB without re-teaching stuff to people (there was a good slide on that that I missed, if someone has it)
• searchable symmetric encryption (SSE): you just replace words by token
  • threat model is different, clients don't care if they hold both the indexes and the keys
• two kinds of order preserving encryption (OPE):
  • stateless OPE (deterministic -> unclear security)
  • interactive OPE (stateful)
  • talks about how hard it is to deploy a stateful scheme
• many leakage-abused attacks on PPE
• crypto researcher on PPE: "it's over!", but the cost and legacy are so that PPE will still be used in the future

I think the point is that there is nothing practical that is better than PPE, so rather than using non-encrypted DB... PPE will still hold.

11:30am - Inference Attacks on Property-Preserving Encrypted Databases

tl;dw: PPE is dead, read the paper

• analysis have been done and it is known what leaks and cryptanalysis have been done from these information
• real data tends to be "non-uniform" and "low entropy", not like assumptions of security proofs
• inference attacks:
  • frequency analysis
  • sorting attack
  • Lp-optimization
  • cumulative attacks
• frequency analysis: come on we all know what that is
  • Lp-optimization: better way of mapping the frequency of auxilliary data and the ciphertexts
• sorting attacks: just sort ciphertextxs and your auxiliary data, map them
  • this fails if there is missing items in the ciphertexts set
  • cumulative attack improve on this

check page 6 of the paper for explanations on these attacks. All I was expecting from this talk was explanation of the improvements (Lp and cumulative) but they just flied through them (fortunately they seem to be pretty easy to understand in the paper). Other than that, nothing new that you can't read from their paper.

2:00pm - Cache Attacks on the Cloud

tl;dw: cache attacks can work, maybe

• hypervisor (VMM) ensures isolation through virtualization
• VMs might feel each other's load on some low-level resources -> potential side channels
• covert channel in the cloud?
  • LLC is cross core (L3 cache)
• cache attacks
  • prime+probe
    • priming: find eviction set: memory line that when loaded to cache L3 will occupy a line we want to monitor
    • probing: when trying to access the memory line again, if it's fast that means no one has used the L3 cache line

• to get crypto keys from that you need to detect key-dependent cache accesses
  • for RSA check timing and number of times the cache is accessed -> multiplications
  • for AES detect the lookup table access in the last round (??)
• cross-VM cache attacks are realistic?
  • attack 1 (can't remember) (hu)
  • co-location: detect if they are on the same machine (dropbox) [RTS09]
    • they tried the same on AWS EC2, too hard now (hu)
    • new technique: LLC Cache accesses (hu)
    • new technique: memory bus contention [xww15, vzrs15]
• once they knew they were on the same machine through colocation what to target?
• libgcrypt's RSA use CRT, sliding window exponentiation and message blinding (see end of my paper to see explanation of message blinding)

conclusion:

• cache attacks in public cloud work
  • but still noise and colocation problem
• open problem: countermeasures?
• what about non-crypto code?

Why didn't they talk of flush+reload and others?

2:30am - Practicing Oblivious Access on Cloud Storage: the Gap, the Fallacy, and the New Way Forward

tl;dw: ORAM, does it work? Is it practical?

paper is here

• Oblivious RAM, he doesn't want to explain how it works
• how close is ORAM to practice?
• implemented 4 different ORAM system from the litterature and got some results from it
• CURIOUS, what they made from these research, is open-source. It's made in Java... such sadness.

Didn't get much from this talk. I know this is "real world" crypto but a better intro on ORAM would have been nicer, also where does ORAM stands in all the solutions we already have (fortunately the previous talk had a slide on that already). Also, I only read about it in FHE papers/presentations, but there was no mention of FHE in this talk :( well... no mention of FHE at all in this convention. Such sadness.

From their paper:

An Oblivious RAM scheme is a trusted mechanism on a client, which helps an application or the user access the untrusted cloud storage. For each read or write operation the user wants to perform on her cloud-side data, the mechanism converts it into a sequence of operations executed by the storage server. The design of the ORAM ensures that for any two sequences of requests (of the same length), the distributions of the resulting sequences of operations are indis-tinguishable to the cloud storage. Existing ORAM schemes typically fall into one of the following categories: (1) layered (also called hierarchical), (2) partition-based, (3) tree-based; and (4) large-message ORAMs.

2:50pm Replacing Weary Crypto: Upgrading the I2P network with stronger primitives

tl;dw: the i2p protocol

• i2p is like Tor? both started around 2003, both using onion routing, both vulnerable to traffic confirmation attacks, etc...
  • but Tor is ~centralized, i2p is ~decentralized
  • tor use an asymmetric design, i2p is symmetric (woot?)
  • in i2p traffic works in circle (responses comes from another path)
    • so twice as many nodes are exposed
    • but you can only see one direction
    • this difference with Tor hasn't really been researched
  • ...

4:20pm - New developments in BREACH

tl;dw: BREACH is back

But first, what is BREACH/CRIME?

This talk was a surprise talk, apparently to replace a canceled one?

• original BREACH attack introduced at blackhat USA 2013
  • compression/encryption attack (similar to CRIME)
  • crime was attaking the request, breach attack the response
  • based on the fact that tls leaks length
  • the https server compresses responses with gzip
  • inject content in victim when he uses http
    • the content injected is a script that queries the https server
  • attack is still not mitigated but now we use block cipher so it's OK
• extending the BREACH attack:
  • attack noisy endpoints
  • attack block ciphers
  • optimized
  • no papers?
• aes-128 is vulnerable
• mitigation proposed:
  • google is introducing some randomness in their responsness (not really working)
  • facebook is trying to generate a mask XORed to the CSRF token (but CSRF tokens are not the only secrets)
• they will demo that at blackhat asia 2016 in Singapore

4:40pm - Lucky Microseconds: A Timing Attack on Amazon's s2n Implementation of TLS

tl;dw: read the paper, attack is impractical

a debriefing of the convention can be found here