Hello everybody and welcome to the second part of our 32C3 recap!
In case you didn’t see the first part, make sure to check it out 😉
This talk was held by Nadia Heninger and Alex Halderman on the second day of the congress. Both work in academic and the field of cryptology. They talked about the “Logjam”-Attack they and several colleagues discovered and published in may of 2014. They started their talk by explaining how they uncovered the vulnerability which was quite interesting since Logjam was no breaking news anymore. And well it was inspired by the congress of the year before, 31C3. The research was conducted because they got curious how the NSA might be able to decrypt VPN traffic as stated by Jacob Applebaum and Laura Poitras in their “reconstructing narratives” talk.
Nadia and Alex identified different kinds of attacks against crypto, e.g. against implementation of crypto, either the NSA might find vulnerabilities or insert backdoors, just like in the juniper case (though it is still unclear how they placed the backdoors there). The other way is to break symmetric crypto like AES or on the other hand to break public key crypto. And in their research they went with the last one. They then compared the most popular public key schemes, RSA and Diffie Hellmann and recited the old recommendation of using DH over RSA because it offers forward secrecy due the ephemeral key and more computational power is required to break the cipher if the DH parameters are chosen well, meaning that the prime has to be random.
And as it turns out in many cases they are not chosen well. The other thing that came back at use, were the backdoors from the nineties, the export function which downgraded SSL to only 512 bit keys due export regulations. And 97% of servers that supported that export functionality used only three different primes as DH parameter, making it the perfect target for precomputation attacks. The reason for that are hard coded primes in the sources. An attacker must be willing to spend quite some time e.g. one week for precomputation, then she could start a man in the middle attack an try to downgrade the encryption but in order to succeed she needs to de/encrypt traffic on the fly. But thanks to the precomputation this part can be performed in about 70 seconds making this attack feasible.
These result can also be transferred to attacks that don’t use a MitM like logjam but do capture traffic to decrypt it later. When the data is stored there is no need to decrypt the traffic on the fly and longer precomputational phases, as well as longer phases for the actual decryption are acceptable.
Their recommendation to get out of this mess is to shift to DH using elliptic curves and if you are unable to use elliptic curves you should use a least 2048 bit keys that are randomly chosen.
by plutoo , derrek & smea
The talk of Smealum, Derrek, and Plutoo this year was about breaking the Nintendo 3DS. Console hacking has also a long tradition at the CCC conference.
The first part of the talk gives a brief overview about the architecture of the 3DS and the new 3DS. The new 3DS of 2014/15 consists of an ARM 11 CPU with up to 804 MHz, 256MB FCRAM and 6MB VRAM. It has also a second CPU (ARM946) which plays an important role in exploiting the system. The main operating system runs on the ARM11, also the games and applications on 4 cores. It has access to all the main memory, like the FCRAM, WRAM and VRAM. The WRAM contains the kernel code and structures.
The FCRAM is divided in 3 different regions:
- APPLICATION: contains game/apps
- SYSTEM: applets, menu, browser
- BASE: system modules, MMU tables, handle tables
The ARM9 part of the hardware is basically a complete separate CPU which runs the same microkernel as the ARM11. The role of this CPU is to broker hardware access that is sensitive in terms of security, like the different source media that is encrypted. It is also responsible for all the crypto mechanisms which use a hardware key scrambler and an AES engine. All what can be signed is signed on the 3DS and also all what can be encrypted is encrypted on this console including all the game media, game saves or NAND flash.
To exploit the system there were some challenges to solve. The 3DS enforces strictly Date Execution Prevention, so the pages are either R, RW or RX and no way to re-protect them from the ARM11 user land. Luckily ASLR is not used for the console.
During their research it turns out that the 3DS runs a very old version of Webkit which it exploitable easily. They used a game called Cubic Ninja as initial entry point which allows to use QR codes in the game for user made levels. It turns out that the parsing of the QR code can crash the game and may be usable as entry point.
To get code execution on the system they used the GPU which has access to the higher part of the FCRAM. So it was possible to execute own code and they created a homebrew launcher which used a ROP chain which was introduced through overwriting a heap object. The next step was to gain access to the system region of the FCRAM and the Nintendo shell. It turns out that this is in the part of the FCRAM what the GPU cannot access. Luckily the new 3DS has a new SAFE_MODE shell which can run at the same time as the original shell. As the FCRAM in the lower part gets filled up, this process allocates memory in the part of the RAM what the GPU can access and therefore it is exploitable. This enables code execution under a system module of the new 3DS.
In the last part of the talk they explained how they reverse engineered the hardware crypto modules and bypassed the signature check for the firmware to place own code on the flash of the console. The AES modules what is used has some key slots that are not readable and can be filled by the boot ROM, so the keys are never exposed to the CPU. The key scrambler creates a new key out of two keys X and Y what are given from the system in hardware. So in theory the resulting key should be secret depending on the hardware design. It turns out that key scrambler was also used in the WII U, where this is implemented in software. So they were able to extract a part of the used keys from the WII U.
Additional they reverse engineered the hardware function of the key scrambler. Therefore they flipped bits in the input keys to check how the function is built and figured out that it consists of an adder with a rotation function like F(x,y) = (((x<<<2) ^y )+C)<<<87. Finally, it was possible to simplify this formula and recalculate the remaining secret key used in the key scrambler.
To conclude this talk, the hack was basically possible because of the shared memory access in the console. So it always should be considered carefully if shared IO is the right way even if the sensitive stuff of the system seems to be protected. Additional it can be said, that adding hardware modules may be a good point in terms of security, but they should then only be used as hardware design and never exposed as software module on any other point.
Quantum computers may be able to break certain cryptographic algorithms. For example, a number of cryptographic algorithms rely on the fact that the discrete logarithm is difficult to compute by a classical computer for certain mathematical groups. Other algorithms rely on the fact that factorization of large integers into primes is difficult. Nevertheless, it may be possible for quantum computers to perform such computations efficiently, which means that the corresponding cryptographic algorithms would be broken if such quantum computers exist. Fortunately, quantum computers that can perform such operations efficiently do not exist up to now, but it is generally agreed that it may be possible to build them in the near future.
In their talk “PQCHacks”, Daniel J. Bernstein (djb) and Tanja Lange discussed which cryptographic algorithms will be dead if general-purpose quantum computers can be built and they present cryptographic algorithms that can withstand quantum computers (so-called post-quantum cryptography or PQC).
The talk was opened with an introduction to the recently developed D-Wave quantum computer. The major point of this introduction is that although this computer is based on quantum mechanical operations, it is not a universal quantum computer. It cannot store stable qubits such that error correction can be performed. It cannot perform basic qubit operations. And it can not run Shor’s algorithm (an algorithm for integer factorization) as well as other important algorithms. But future research is strongly focused on the implementation of a universal quantum computer and therefore it is only a matter of time till one of these computers will be build. Progress within this field is summarized here.
Now fast forward to a time where universal quantum computers exist which can solve Shor’s algorithm in polynomial time. This would mean that integers can be efficiently factorized and RSA is therefore dead. Moreover, the discrete-logarithm problem in finite fields and on elliptic curves would be solved and therefore DSA and ECDSA would be dead, respectively.
There exist ways to develop cryptographic algorithms that are secure against attacks by a quantum computer. For example, one could rely on physical cryptography (i.e. a locked brief case) or quantum cryptography (i.e. cryptography based on quantum algorithms). Although such types of cryptography may be resistant to attacks by quantum computers, it can be financially expensive. Moreover, physical cryptography is highly inconvenient (e.g. sending the locked brief cases) and quantum cryptography may only work under very special circumstances (e.g. that are fulfilled in theory but often not in the real world). Therefore, other solutions are desperately sought after and with this we come to the core topic of the talk: classical algorithms that are quantum resistant.
Recommendations for long-term secure post-quantum systems have been summarized by the presenters (and co-authors) in a research paper. The paper can be found here. For symmetric encryption AES-256 and Salsa20 with a 256-bit key have been thoroughly analyzed and are recommended (Serpent-256 is currently evaluated). For symmetric authentication either GCM using a 96-bit nonce and a 128-bit authenticator or Poly1305 are recommended. For public-key encryption McEliece with binary Goppa codes (length n = 6960, dimension k = 5413, t = 119 errors) are recommended (QC-MDPC, Stehlé-Steinfeld NTRU, and others are currently evaluated). For public-key signatures, hash-based signature schemes such as XMSS and SPHINCS-256 are recommended (HFEv and others are currently evaluated).
During the second part of the talk, the mathematics of Lamport’s hash-based signature scheme has been discussed. The nice feature of this signature scheme is that the security of it is easy to understand. All that is needed is a secure hash function from which the signature scheme is build up. The signature scheme is then constructed successively: the hash function is first used to sign empty messages, from this a signing for 1-bit messages is constructed, then – using this 1-bit signing scheme – a 2-bit signing algorithm is constructed, and so on. However, Lamport’s signature scheme is a one-time signature scheme, i.e. only one message can be signed with a certain private key. The scheme has been extended to a 8-time signature scheme by Merkle which uses basically 8 Lamport keys (but stores them efficiently). On the downside, the statefulness of this scheme, i.e. if keeping track of if a certain key has been used, is inconvenient (and can lead to problems, for example, if a virtual machine is cloned). It is also possible to eliminate the state, but this may sometimes lead to large signatures (in terms of storage size).
The final part of the talk focused on the mathematics of code-based encryption (e.g. McEliece cryptosystem and Niederreiter cryptosystem). The key message is that such code-based encryption may provide a sufficient post-quantum security. Overall, the talk provided a nice overview on quantum resistant cryptography and introduced also a sample of the mathematics that is needed to understand the basics of this topic.