How to do cryptography right in android part 1
•Als PPTX, PDF herunterladen•
4 gefällt mir•1,309 views
This document provides an overview of cryptography concepts and best practices for implementing cryptography securely in Android applications. It discusses encryption algorithms like AES and RSA, key management practices, and the Android Keystore system which allows storing cryptographic keys in a hardware-backed secure container. It highlights that the hardest part of encryption is key management and outlines practices to avoid like storing keys with encrypted data or in plain text in code.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie How to do cryptography right in android part 1
Ähnlich wie How to do cryptography right in android part 1 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
How to do cryptography right in android part 1
- 1. Dance like nobody's watching Encrypt like everyone is How to do cryptography right in android Part #1 Arash Ramez
- 2. Basic Concepts • Cryptography is the art or science encompassing the principles and methods of transforming an intelligible message into one that is unintelligible, and then retransforming that message back to its original form • Concerned with developing algorithms which may be used to: • conceal the context of some message from all except the sender and recipient (privacy or secrecy), and/or (Confidentiality) • verify the correctness of a message to the recipient (authentication) Jefferson cylinder, developed in 1790s
- 3. Basic Concepts Plaintext the original intelligible message Ciphertext the transformed message Cipher an algorithm for transforming an intelligible message into one that is unintelligible by transposition and/or substitution methods Key some critical information used by the cipher, known only to the sender & receiver encipher (encode) the process of converting plaintext to ciphertext using a cipher and a key decipher (decode) the process of converting ciphertext back into plaintext using a cipher and a key cryptanalysis the study of principles and methods of transforming an unintelligible message back into an intelligible message without knowledge of the key. Also called codebreaking code an algorithm for transforming an intelligible message into an unintelligible one using a code-book
- 4. Two very important truisms 1. Cryptography is harder than it looks. 2. Complexity is the worst enemy of security. Enigma Rotor machine
- 6. Common pitfalls • Rolling your own cryptographic algorithms or implementations. • Misuse of libraries and algorithms. • Poor key management. • Randomness that is not random. • Failure to centralize cryptography. • Failure to allow for algorithm adaptation and evolution.
- 7. Regulations • HIPPA Breach Notification Rule • PCIDSS • GDPR : Article 17 • GDPR, RIGHT OF ERASURE (RIGHT TO BE FORGOTTEN), AND ENCRYPTION KEY MANAGEMENT (https://gdpr-info.eu/art-17-gdpr/) • Encryption is one of the most well understood mechanisms for data privacy • FIPS 140-2 • HTTPS://CSRC.NIST.GOV/PROJECTS/CRYPTOGRAPHIC-MODULE-VALIDATION- PROGRAM/VALIDATED-MODULES/SEARCH
- 9. Type of Algorithms • Hashing • One-way, irreversible, Key-less (e.g. SHA-512,SHA1,MD5) • HMAC • One-way, irreversible, Keyed-Hash (e.g. HMACSHA512) • Symmetric • One Key encrypt and decrypt (e.g. DES,3DES,AES,RC4) • Asymmetric • Two mathematically related Keys; one key reverses transformations of the other. (e.g. RSA, ECC) • Random Number Generation • Generate a random sequence of numbers
- 10. One-Way Hashing - MD5(banned) / 128bit - SHA0/SHA1 (banned 2014) / 160bit - SHA-1 shall not be used for digital signature generation after December 31, 2013. (NIST) - SHA-256 - SHA-384 - SHA-512 - SHA3
- 11. HMAC (Hash-based Message Authentication Code)
- 13. Symmetric Algorithms • RC4 (unsafe) • DES (unsafe) : 56-bit Key • TwoFish • 3DES : 64 / 112 / 168 bit • AES (Rijndael) : 128/192/256 bit
- 15. Block Cipher vs Stream Cipher • A block cipher encrypts data in specific-sized blocks, such as 64-bit blocks or 128-bit blocks. The block cipher divides large files or messages into these blocks and then encrypts each individual block separately. (DES/3DES/AES-ECB/CBC) • Encrypting a file or a specific-sized database field. • Stream ciphers encrypt data as a stream of bits or bytes rather than dividing it into blocks. (RC4/AES-GCM) • the size of the data is unknown or sent in a continuous stream, such as when streaming audio and video over a network • Important Note : Encryption keys should never be reused.
- 16. Block Ciphers • ECB ( Electronic Codebook) • CBC (Cipher Block Chaining)
- 17. Asymmetric Cryptography • Public Key Cryptography • PKI • PKE
- 18. Asymmetric Cryptography (Public Key Cryptography) • Rivest Shamir Adleman (RSA) /1978 • The basic RSA algorithm for confidentiality • Ciphertext = (plaintext)^e mod n Plaintext = (ciphertext)^d mod n Private Key = {d, n} Public Key = {e, n} • The basic RSA algorithm for authentication • ciphertext = (plaintext)^d mod n plaintext = (ciphertext)^e mod n private key = {d, n} public key = {e, n}
- 19. Asymmetric Cryptography (Public Key Cryptography) • Diffie-Hellman key agreement (Dr. Whitfield Diffie and Dr. Martin Hellman) / 1976
- 20. Elliptic Curve Cryptography (ECC) • provides similar functionality to RSA. Elliptic Curve Cryptography (ECC) is being implemented in smaller devices like cell phones. It requires less computing power compared with RSA. ECC encryption systems are based on the idea of using points on a curve to define the public/private key pair.
- 23. Keys • Bits of Protection(Key length)
- 24. Key Management : The ways to do it wrong • The hardest part of getting encryption right has to do with creating, protecting, and deploying encryption keys. It is probably the hardest part of getting an encryption strategy right. • Storing the unprotected encryption key with the protected data • Using weak protection methods to secure encryption keys • Storing the encryption key directly in application code • Using a weak encryption key - a password is an example of a weak key • Not using strong, industry standard methods of generating an encryption key • Not providing separation of duties and dual control around key management
- 25. Android Keystore
- 26. Android Keystore • KeyStore (API 1) / JKS or BKS based keystores • You will have to create a KeyStore file and you will also have to manage the secret to access to it. This secret is very sensitive and difficult to hide from attackers. • Android KeyStore Provider (API 18) • TEE based keystore • check KeyInfo#isInsideSecureHardware() method to see whether the key is saved there or not • significantly enhanced in Android 6.0 (API level 23) • Android 9 (API level 28) • StrongBox (Titan M on Google Pixel 3)
- 27. Android keystore system • The Android Keystore system lets you store cryptographic keys in a container to make it more difficult to extract from the device. Once keys are in the keystore, they can be used for cryptographic operations with the key material remaining non-exportable • introduced in Android 4.3 (API level 18) • Firstly, Android Keystore mitigates unauthorized use of key material outside of the Android device by preventing extraction of the key material from application processes and from the Android device as a whole • Secondly, Android KeyStore mitigates unauthorized use of key material on the Android device by making apps specify authorized uses of their keys and then enforcing these restrictions outside of the apps' processes.
- 28. Security Features: Extraction prevention • Key material never enters the application process. • Key material may be bound to the secure hardware. • (e.g., Trusted Execution Environment (TEE), Secure Element (SE)) of the Android device
- 29. Why does Hardware-Based Cryptography matter? • The software solution is often more accessible to an attacker • In contrast, the IP running on an FPGA is physically fully internal. • The second reason is performance. • FPGAs excel at massively parallel processing, and it’s easy to get duplex throughputs of 10 Gbps with modest clocks • Using faster silicon, higher clock speeds and more FPGA resources can push the throughput up to 100 Gbps or beyond.
- 30. Secure Storage of keys • Android also now supports hardware-backed storage for your KeyChain credentials, providing more security by making the keys unavailable for extraction. That is, once keys are in a hardware-backed key store (Secure Element, TPM, or TrustZone), they can be used for cryptographic operations but the private key material cannot be exported. Even the OS kernel cannot access this key material. While not all Android-powered devices support storage on hardware, you can check at runtime if hardware-backed storage is available by calling KeyChain.IsBoundKeyAlgorithm() • Android Keystore Nasty Bug(more common before Android 5): • if the user changes the lock screen pattern into a password or just deletes the pattern, the KeyStore will be fully corrupted. • https://doridori.github.io/android-security-the-forgetful- keystore/#sthash.G3v7Ei7g.Myhj1R0a.dpbs
- 31. Keystore API • Encryption/Decryption • https://gist.github.com/aramezx/f69bbd897cc19f29e68008659f8ed653 • https://gist.github.com/aramezx/8cc5922a9602694a02fa905149f02a63
- 32. Keystore API(cont.) • Sign/Verify • https://gist.github.com/aramezx/885cc89be75a3838c26b7b3975e4f667
- 33. Keystore API(cont.) • Key Exchange • https://gist.github.com/aramezx/e50d90af51877e6608c981e03d371a76
- 34. Keystore redesign in Android M • New symmetric cryptography API based on JCA • Requiring use authentication • Keymaster redesign • Key blob storage
- 36. Improvements in API 23 & N • keys can be generated within the secure hardware, and then used to perform cryptographic operations on user data, without the keys ever leaving the secure hardware. • High Maturity Cipher suites support • Android N : • CrytpoProvider is deprecated • Hardware-backed keystore is mandatory
Hinweis der Redaktion
- Rolling your own cryptographic algorithms or implementations. Designing a cryptographic algorithm (including protocols and modes) requires significant and rare mathematical skills and training, and even trained mathematicians sometimes produce algorithms that have subtle problems. There are also numerous subtleties with implementing cryptographic algorithms. For example, the order of operations involved when exponentiating a number — something common in cryptographic operations — can leak secret information to attackers. Standard algorithms and libraries are preferable. Misuse of libraries and algorithms. Even when using strong libraries, do not assume that just using the libraries will be sufficient. There have been numerous instances in which standard libraries were used, but the developers using the libraries made incorrect assumptions about how to use the library routines. In other situations, developers don’t choose the right algorithm or use the algorithm incorrectly. For example, an encryption scheme may protect the confidentiality of data, but may not protect against malicious modifications to the data. As another example, if an algorithm requires an initialization vector (IV), then choosing an IV with certain properties may be required for the algorithm to work securely. Understanding the nuances of algorithm and library usage is a core skill for applied cryptographers. Poor key management. When everything else is done correctly, the security of the cryptographic system still hinges on the protection of the cryptographic keys. Key management mistakes are common, and include hard-coding keys into software (often observed in embedded devices and application software), failure to allow for the revocation and/or rotation of keys, use of cryptographic keys that are weak (e.g., keys that are too short or that are predictable), and weak key distribution mechanisms. Randomness that is not random. Confusion between statistical randomness and cryptographic randomness is common. Cryptographic operations require random numbers that have strong security properties. In addition to obtaining numbers with strong cryptographic randomness properties, care must be taken not to re-use the random numbers. Failure to centralize cryptography. Numerous situations have been observed in which different teams within an organization each implemented their own cryptographic routines. Cryptographic algorithms often don’t interact nicely. Best practices indicate getting it “right” once and reusing the component elsewhere. Failure to allow for algorithm adaptation and evolution. See Bullet “Design for changes in the security properties of components beyond your control” in “Be flexible when considering future changes to objects and actors” section.
- 1) Software is more vulnerable 1.2)including an operating system making it large and complex so that it offers many opportunities to an attacker and difficult to analyse for security weaknesses. 2) Isolating the encryption code in fixed hardware and never allowing the software to come in contact with critical security parameters such as keys makes it easier to analyse the system’s overall security and many classes of threat are eliminated. 2.2) The design should have only “plaintext” (i.e., message-in-the-clear) and fully encrypted data (i.e., ciphertext) going anywhere near the device’s pins. 3)