Bluetooth Hacking?
Cryptography gone Haywire

From OpenPCD

Jump to: navigation, search


Breaking good Cryptography

Cryptography did become an important part of our life. Thanks to Kerckhoffs's Principle proprietary and an undocumented algorithms are finally on the verge of extinction as new products use documented and well-researched algorithms. We regularly stumble over good cryptography that is broken by a bad implementation or wrong usage.

Hints & real world fails

  • Kerckhoffs's Principle: Never store secret keys in your application binaries. This statement applies recursively: It doesn't help to encrypt a secret key with another key hidden in the application binaries. Assume for your security assessment that sophisticated attackers can read your application binaries as easy as you read your own source code. Simply assume that your attacker is in possession of your full source code and the comprehensive protocol/data format documentation. Security by Obscurity never worked and every obfuscation can be reversed.
  • Reverse-Engineering a Cryptographic RFID Tag: Shows how a pseudo random number generator kills security by allowing to control the 'not-so-random-anymore' challenge and thus allows to replay a sniffed response to the challenge.
  • Implementing an RFID 'Mifare Classic' Attack
  • Broken Random Number Generation: Don't laugh too hard - as many people make that mistake by involuntarily making their random numbers predictable by using a library-Randomize() functions for their integrated pseudo-random number generator - making their random numbers predictable by guessing the time the program was started.
  • Console Hacking 2010 - PS3 Epic Fail: Broken Elliptic Curve Digital Signature Algorithm (ECDSA) by using the same 'random' number over and over again.
  • Using the wrong cipher mode: Theory and Practice of Cryptography: Excellent paper with a lot of do's and dont's like ECB used where CBC is needed (p13-15),
  • 17 Mistakes Microsoft Made in the Xbox Security System Using TEA encryption as a Hash is evil (see page 8). Exposing the encryption key on a external bus is not a good idea as well.
  • Don't encourage attackers by using the same keys for multiple devices or RFID/smart cards: For example HID iCLASS standard security cards use the same key all over the world: Heart of Darkness - exploring the uncharted backwaters of HID iCLASS security making it a promising target for complex attacks. This could be easily avoided if per-customer keys were used more consequently.
  • Be aware of a major RSA pitfall - RSA has the property that the product of two cipher-texts is equal to the encryption of the product of the respective plain-texts. This means if you can slip in a known plain-text and have it encrypted with the same RSA, you can calculate the original plain-text from that. This is easily avoidable if you use padding.
  • Using a cipher doesn't automatically result in transaction security: Many stream ciphers allow modification of a known plain text for unknown keys as usually a pseudo-random stream of bits (a key-stream) is generated which is XOR'ed to the plain-text.
  • Don't use the same RSA key set for signing and encryption.
  • Carefully examine possible physical side channel of your actual encryption device. A good example are Differential Power Analysis (DPA) attacks, timing attacks like the remote timing attacks on Elliptic Curve Digital Signature Algorithm (ECDSA) are are still practical.
  • An important class of attacks you need to be aware of are fault injections. Fault injections are not only limited to software, but are also true for the hardware - for example clock/power glitching to skip parts of your code to circumvent security checks.
  • Understand man-in-the-middle attacks: Even SSL encryption doesn't help if you don't get your PKI management right: For example in the german eID management software the certificate-hostname wasn't compared to the the actual host name. This allowed a man-in-the-middle attacker to pretend to the management software (AusweisApp) that an update was available - resulting in a download and remote code execution via directory traversal.
  • Use a good random source with adequate entropy - reseed constantly by using unpredictable events. A key is only good as the random source used to create it.
  • Are you using PGP/GPG for email encryption? Did you consequently verify the key fingerprint both ways with your communication partner (either by phone if you know his/her voice or by personal verification). Reading it off a website doesn't help - even if it's SSL encrypted. As the Web of Trust usually has holes, people tend to blindly sign new key blindly or after comparing fingerprints from a website or by sending around their keys via plain-text mail. A simple solution is to print your full key fingerprint on your business card or publish the fingerprint in a newspaper.
  • A variation of the fingerprint verification problem is SSH: how often did you open an SSH connection on a new machine to one of your servers without verifying the fingerprint?


Don't try to protect a tent with a safe vault door: Make sure that the other components in your system live up to the security level of the cryptography you use. A good example are buffer overflows in your code resulting in remote code execution and unauthorized access - or Differential Power Analysis (DPA) - or mechanically breaking the wooden door open that is protected by a 2048 bit RSA key protected biometric smart card... or ...

Further Reading