This presentation covers common cryptographic attacks, secure cryptographic implementation requirements, an overview of FIPS 140-2 and secure crypto implementation guidelines

1. Trupti Shiralkar
Common Crypto Attacks and
Secure Implementations
Guidelines

2. Disclaimer
This disclaimer informs readers that the views, thoughts, and opinions expressed in the presentation
belong solely to the author, and not necessarily to the author’s employer, organization, committee or other
group or individual.
All the images used in this presentation do not belong to me and are subject to copyright protection act.

3. Agenda
• Why should we study common crypto attacks?
• Common Crypto Attacks
o Vulnerabilities in cryptographic ciphers and protocol
o Vulnerabilities in cryptographic Libraries
• FIPS 140-2: what works/ doesn’t work?
• Secure Implementation Guidelines
• Conclusion

4. Why Should We Study
Crypto Attacks
Building a secure cryptographic system is easy to do so badly and
very difficult to do well. Unfortunately, most people can’t tell the
difference.
~ Bruce Schniner

5. Fighting Russians in Winter
• 35,000 troops
reduced to 19,000
• Swedish empire
ended in 1709
Swedish Invasion
(1707)
• 610,000 troops
reduced to 120,000
• Napoleon’s defeat
French Invasion
(1812)
• Lessons learnt from
the history were
ignored
German Invasion
(1941)

6. Cryptographic Ciphers
There are two types of encryption: One that will prevent your sister
from reading your diary and one that will prevent your government.
- Bruce Schneier

7. Cryptographic Ciphers
Insecure vs secure cipher
• Any cipher which provides 128 bits + of cryptographic strength is considered safe before quantum computing becomes norm
Examples: AES (128, 192, 256 bits)
• NSA Suit B Cryptography for classified and unclassified information
ü AES (128,256) for symmetric encryption with counter mode for low bandwidth/GCM mode for high bandwidth
ü ECDSA for digital signature
ü ECDH for key agreement
ü SHA-256 or SHA-384 for message digest
• Insecure ciphers
☀ MD5, SHA-1,
☀ DES, TDES
☀ RSA, DSA with 1024 bits key pair
☀ RC4
• Quantum Safe ciphers
Ciphers which are safe against attack by a quantum computer.
AWS crypto quantum safe ciphers wiki

8. Cryptographic Attacks & Vulnerabilities Chronology
• DES was broken using deep crack (IBM 1997)
• ROBOT (1998-2017)
• EC DRBG Backdoor (2007-2013)
• Lucky 13 (2013)
• BEAST (2013)
• POODLE (2014)
• HeartBleed (2014)
• Logjam (2015)
• FREAK (2015)
• DROWN (2016)

9. Cryptographic Backdoor
• RNG Backdoor is implemented in FIPS approved
Dual EC DRBG which was identified by Microsoft
Engineers in 2007.
• NSA runs BULLRUN program to crack encrypted
online data
• NSA paid $10 million to RSA to put backdoor in
BESAFE library
• NSA spent $250 million per year to insert this
backdoor in software and hardware products.
• In 2013, NY Times article indicated presence of
backdoor
• NIST SP 800-90A was published in 2006 and
withdrawn in 2014.

10. Padding Oracle Attack
• In cryptography plaintext is padded to be
compatible with cryptographic primitives.
• Oracle is usually a server that responds
whether the message is correctly padded or
not.
• This attack uses padding validation of
cryptographic message to decrypt ciphertext.
• CBC mode provides only confidentiality.
• In case of CBC mode based encryption, the
servers returns a message weather padding of
encrypted text is correct or not resulting in
decryption of ciphertext without encryption
key.
• Examples: Lucky 13, FREAK, POODLE, Logjam

11. ROBOT (Return Of Bleichenbacher’s Oracle Threat) CVE-2017-13099
• 20 years old crypto vulnerability (identified in 1998)
• Researchers built proof of concept scanned
infrastructure and found facebook, F5, Cisco,
BouncyCastle, WolfSSL and few more vendors
vulnerable.
• This attack is applicable to RSA key exchange
(TLS_RSA_WITH_AES_128_CBC_SHA)
• Root Cause: The error messages in the RSA
encryption standard PKCS#1v1.5 padding scheme
allows adaptive chosen cipher text attack.
• Impact: attacker can decrypt encrypted data and
sign communications using the sites’ private key
resulting in information disclosure.
• Resolution: Do not use PKCS#1v1.5.
• TLS v 1.3 has decided deprecate the use of RSA key
exchange PKCS #1v 1.5

12. LUCKY 13 (CVE-2013-0169)
• This is a timing attack which is basically a side
channel attack. Attacker analyzes time takes
to execute the cipher operations.
• Root cause: Attacker exploits badly formatted
padding in TLS cipher that uses CBC mode
• Impact: Attacker can obtain plaintext
authentication cookies.
• Martin R. Albrecht and Paterson
demonstrated variant of Lucky 13 attack on
Amazon s2n and fount it vulnerable.
• Resolution: Add random time delays to beat
statistical analysis, use authenticated
encryption AES-GCM/CCM

13. BEAST Browser Exploit Against SSL/TLS (CVE-2011-3389)
• BEAST is an attack which was revealed in September
2011
• This is a purely client side vulnerability.
• Root cause: weakness in CBC mode, except the first
random string of IV used for encryption, rest all IVs are
predictable during active man in the middle attack
causing chosen plaintext vulnerability in TLS/SSL.
• Impact: According to Gregory Bard’s paper, the
success rate of this attack is 100%.
• Resolution: use explicit IV, AES-GCM in TLS 1.2

14. POODLE(Padding Oracle On Downgraded Legacy Encryption) CVE-2014-3566
• Root Cause: For backward compatibility, many
legacy server support downgrading request to
SSL v3 which uses insecure RC4 or CBC mode
• Impact: Attacker uses Man-In-the-Middle
attack to downgrade protocol to SSV3
• Secret encrypted with RC4 and sent many
times, it leaks more and more information
with bit flipping attack.
• 256 SSL v3 requests are required to obtain1
byte of plain text data.
• Resolution: Disable SSL v3 or use
TLS_FALLBACK_SCSV which ensures that
legacy system is involved

15. HeartBleed (CVE-2014-0160)
• January 1, 2011 German developer introduced Heartbeat
extension to OpenSSL.
• This TLS extension implements keep-alive functionality
without performing a renegotiation.
• This flaw was discovered by Codenomicon + Google security
engineers in April,2014.
• Root cause: Buffer over read vulnerability which lacks bound
checking, reads more data than the size of buffer causing
memory safety issues.
• Impact: Attacker can read sensitive information including
private keys from 64 MB memory, decrypt server traffic and
impersonate server.
• Resolution: upgrade OpenSSL library to OpenSSL v1.0.1g.

16. LOGJAM( CVE-2015-4000)
• Root Cause: Logjam exploits the TLS protocol flaw of
supporting export grade Diffie- Helman (512 bit)
• Impact: TLS connection is downgraded to export level
Diffie-Hellman using man-in-the-middle attack
• Resolution: Reject small primes in DHE handshake,
accept 2048 bits or lager DHE group, transition to
ECDH.

17. FREAK (Factoring Attack on RSA Export Keys) CVE-2015-0204
• Root cause: Attacker can conduct Man-in-the-Middle attack to
force clients to use weaker encryption (RSA 512 bit) which is
easy to decrypt.
• Weak RSA Export options:
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
• Impact: Attacker can decrypt cipher text.
• Resolution: disable export grade cipher suite.

18. DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) CVE-2016-0800
• Breaking TLS using SSLv2: Published in August
2016
• According to https://drownattack.com , 33%
HTTPS servers were affected.
• Root cause: Attacker exploits fundamental flaw in
SSL v2 which utilizes 40 bits RSA key material.
• Impact: 40,000 probes and 2^50 computations
are required to decrypt 1/900 TLS connections
from victim. Amazon EC2 computation cost for is
$440
• In case of OpenSSL bug, 17,000 probes are
required to decrypt 1/260 TLS connections from
victim. It will take less than one min on a fast PC
to decrypt the key.
• Resolution: upgrade OpenSSL library and do not
use SSLv2

19. Vulnerabilities in
Cryptographic Libraries
S
Strong cryptography is very powerful when it is done right, but it is not a panacea.
Focusing on cryptographic algorithms while ignoring other aspects of security is like
defending your house not by building a fence around it, but by putting an immense
stake in the ground and hoping that your adversary runs right into it.
~ Bruce Schneier

20. OpenSSL Vulnerability Trend

21. OpenSSL Vulnerability Categorization

22. OpenSSL Vulnerability Categorization

23. Bouncy Castle Vulnerabilities
Known vulnerabilities
1. ROBOT (CVE-2017-13098)
2. Invalid curve attack (CVE-2015-7940)
~ Bouncy Castle does not validate EC point curve and attacker can send several
specially crafted ECDH key exchange request to obtain private key.
3. Timing Side Channel Attack (CVE-2013-1624)
~ During processing of malformed CBC padding, timing attack on MAC validation
operation results in plaintext recovery.
4. Bleichenbacher vulnerability (ROBOT) (CVE-2007-6721)

24. Lessons Learnt from FIPS 140-2
• Finite State Model crypto libraries
• Self Test
- known answer test for each cipher
• Conditional tests
- pairwise consistency test
• Key Generation Entropy
• Random number conditional tests
- stuck bit test
• Key Zerorization
- Securely delete keys after usage by overwriting it with
zeros or random data.
• Tamper Resistance
Tamper detection, Tamper Evidence and Tamper Response

25. Entropy
• Longer key does not guarantee more security
• What is entropy?
• How to measure entropy?
• Tools : NIST’s Statistical test suite, Dieharder
https://w.amazon.com/index.php/Infosec/Cryptography/Guidelines/Dieharder
• Best security practices
Ø Ensure all sources of entropy are secure
ØThe entropy of the key should be equivalent to the cryptographic strength indicated by the key size
o AES 256 bits (cryptographic strength: 256 bits)
o RSA 2048 bits (cryptographic strength: 128 bits)

26. Why FIPS 140-2 doesn’t guarantee security?
• Cipher suite recommendations including key size, modes are dictated
by NIST (or NSA ?)
• Application security or full stack (end to end) issues are not captured
• Scope of crypto review is limited to boundary of the library
• Crypto requirements do not change as technology changes
• Paper Chase: Too much emphasis on documentation
• Time required for certification is more that the life of version of
crypto product /service

27. Secure implementation
Guidelines
Prussian general Carl von Clausewitz calls "the position of the interior." A good
security product must defend against every possible attack, even attacks that
haven't been invented yet.
~ Bruce Schniner

28. Secure cryptographic implementation guidelines
• Do not reuse cryptographic parameters (key, IV, key material)
• Check the size of input parameters to avoid buffer overflows.
• Destroy all copies (temporary files, virtual memory)of plaintext after it is encrypted.
• Erase key material properly after usage
• Do not leave keys and password on host and rely on OS to protect it.
• Audit flooding should be prohibited to avoid hiding attacker’s identity
• Ensure the protection of compromised keys stored as hot list
• Selection of weak password in Password Base Key Derivation Function(PBKDF) ( Password less than size
10 could result as a weak protection for resulting AES-256 bit key)
• Along with encryption, ensure the integrity and authenticity of the data.

29. Summary
Buckets of crypto Vulnerabilities:
• Lack of security control
• Insecure configuration
• Insufficient entropy/randomness
• Implementation bugs
• Mathematical flaws
• Design flaws
• 1990s era export grade cryptography

30. Conclusion
• Weaker encryption (1990s era US export) is baked in many software products which is root cause of
many crypto vulnerabilities.
• A strong and secure cryptographic keys do not guarantee a secure cryptosystem.
• Security builders should be aware of cryptanalytic attacks so that old mistakes are not repeated over
and over again.
• Security control developers and cryptographers should work together efficiently.
• Discuss the gravity of consequences of a security trade off to enhance usability with cryptographers.

31. References
• https://w.amazon.com/index.php/AWSCryptoBR/Cryptosystems
• http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
• https://projectbullrun.org/dual-ec/documents/dual-ec-20150731.pdf
• https://eprint.iacr.org/2017/1189.pdf
• http://www.cs.umd.edu/~jkatz/security/downloads/padding-oracle-attacks.pdf
• http://kodu.ut.ee/~mroos/turve/2015/referaadid/Rodion_Krjutskov.pdf
• https://www.openssl.org/~bodo/ssl-poodle.pdf
• https://drownattack.com/drown-attack-paper.pdf

32. Question?
Contact: tshiralk@amazon.com