This last week, I took a break from conventions, classes, and reading to focus on my side project: Passloch. Passloch is a password manager project that I started over a year ago as a way for me to learn more about cryptography as well as getting experience in building a full stack platform from the ground up. I’ve had loads of help throughout the project but we’re still a ways-a-way from eventually releasing the beta. Although there’s much left to do, I wanted to spend some time talking about cryptography, how it fits into your threat models, and how it can be implemented in Android.
Cryptography
This is one of my favorite, if not my most favorite subject in security. Cryptography is “the science or study of the techniques of secret writing, especially code and cipher systems, methods, and the like”. The thing that I love about cryptography so much is that it almost feels like magic at times (in a good way!).
I wanted to take a bit to give a little introduction to cryptography and talk about some of the cryptography that is being used in Passloch. Later, I’ll talk about why some of the choices were made and finally, how they’re implemented in Passloch.
Introduction
At its core, cryptography is about looking at your threat model, evaluating what properties about your data you want to be true, and providing a strong, mathematically-based, proven system that can give you those properties.
For example, when you make transactions with your bank you generally want a couple of different properties to be true:
- You want your communication to be secret. This is called Confidentiality. You wouldn’t want anyone looking at your traffic with a tool like wireshark or TCPeek to be able to get your account number or password.
- You want your communication to not change after you send it. This is called Integrity. This means that someone couldn’t use a tool like TCPeek or Ettercap to change your data before the bank gets it. Something to keep in mind is that just because your data has Confidentiality as a property does not mean that it has integrity. This fact is exploited in a number of cryptographic attacks such as Padding Oracle. Additionally, some ciphers are known as homomorphic ciphers which means that they are designed to be malleable in predictable ways even after encryption occurs. Unpadded RSA is an example of a partial homomorphic cipher.
- You want your communication to be sent to the entity desired. This is called Authenticity. This means that the other entity you’re talking to (whether it’s a person or a bank) is actually who they say they are. There are a couple of interesting problems with this property in particular but one of the best ways we have of validating the authenticity of a message is through signatures and PKI (Public Key Infrastructure).
While there are some other, more complicated properties cryptography can give you (such as resistance to certain types of attacks, computational speedups when certain classes of parameters are used, etc.) these are the core properties that many systems use. TLS (Transport Layer Security — the little green HTTPS in your address bar), for example, satisfies all three of these properties. Let’s talk about how TLS does this.
TLS
This is what Chrome’s developer console reports my TLS connection information to be when I am connected to Medium.com. In the Secure Connection section, we can see a couple of different acronyms that inevitably describe the cryptography being used to secure my connection.
TLS 1.2 — This is the latest (I know TLS 1.3 is in the works but it’s not official… yet) version of the TLS protocol. This protocol describes how a secure negotation between my browser and Medium’s servers should work. It’s under constant peer review and occasional revision (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3 soon™) which only strengthens the protocol.
ECDHE_RSA with X25519: This stands for “Elliptic Curve Diffie-Hellman Ephemeral signed with RSA with the named curve X25519”. Quite a mouthful, huh? Let’s break this down:
Diffie-Hellman: This is an algorithm that facilitates key exchange. Imagine two people: Alice and Bob, who want to agree on a secret key with each other but are afraid that someone else, Eve, will eavesdrop and nab their key. They can use this simple key exchange to avoid sending a key directly to each other but by sending some “seemingly random” data to each other are able to arrive at the same number. (This algorithm is simple enough you can do it on paper in a minute. Give it a try!)
DHE: This stands for Diffie-Hellman Ephemeral. Ephemeral means “lasting for a very short time”. In the context of DH, this means that for each new connection the server makes with a client, it uses a brand new secret in its key exchange. This enabled a property called Perfect Forward Secrecy which means that even if we compromise the secret key of this communication it does not compromise any previous conversations (because the secret the server uses to generate the key is ephemeral!).
ECDHE: This means that instead of using numbers and a cryptosystem based on the Diffie Hellman Problem (DHP which is analogous to Discrete Logarithm Problem) which states that given g^x and g^y find g^xy , we use an elliptic curve based system that states that given G*x and G*y find G * xy . ECDLP seems to be at least as hard as DLP/DHP. Additionally, ECDH can be faster than traditional DH.
ECDHE_RSA: This is ECDHE but each message has a signature created with RSA. A signature is a verifiable way to check both integrity and authenticity. A general method of signing is to first calculate a hash of the data you want to sign and then encrypt that data using the sender’s private key. The receiver is expected to already know the public key of the sender. The receiver, after getting the message, decrypts the signature with the public key giving the receiver the original, calculated hash of the message. They then calculate the hash of the data and compare the two hashes. This provides integrity because the data cannot be changed without recalculating the signature which should be impossible to do without the private key (we assume the private key is reasonable secure). This also provides authenticity because the only way that your public key would verify the signature is if the associated private key was used to sign it.
We now know that ECDHE_RSA does three things for us: Allow us to exchange a key with the other party and provide authenticity and integrity while we’re doing this operation. The X25519 portion tells both parties that the specific elliptic curve to use is a well known Montgomery curve with predefined parameters known as X25519. It has been studied heavily and seems to be a very fast and very safe curve (remember how I said that there other types of properties that you can get through cryptography? X25519 provides some computational speed and attack resistance properties).
This was a lot just to exchange a key, but what about after we have the secret keys? How are we achieving the confidentiality, integrity, and authenticity that we desire? We use AES-128 in GCM mode.
AES
Also known as the Rijndael (sounds like “rain-dale”) Block Cipher, the Advanced Encryption Standard is a very secure symmetric encryption algorithm (that means that both parties use the same key to encrypt and decrypt). The 128 part says that the key we’re using is 128-bits long (16 bytes). This provides the confidentiality in our communications. What about the authenticity? Well, we got the key via an authentic channel so that’s where our authenticity comes from but what about the integrity? That’s where the GCM part comes in. AES can operate in different block modes. This is mostly a detail on how the different “blocks” come together and are calculated. GCM in particular offers something called AEAD (Authenticated Encryption with Associated Data) which means that it will automatically provide integrity in our communications.
Cryptography as part of a Threat Model
A threat model is a modeling technique used to enumerate the potential threats, assumptions, and mitigation techniques that a system will have. Oftentimes a diagram accompanies a threat model to show the flow of data between entity to entity.
When evaluating vulnerabilities in your communication channels, you’ll likely employ some sort of cryptography, somewhere. It might be the assumption that all of your communication channels will be using TLS or that the passwords of your users will be hashed on the server side of your application. Whatever the case, it’s important to properly scope the kinds of threats you want to protect against and recognize the the potential threat actors that you will not protect against.
For example, imagine the above threat model diagram represents an application you’re building. We’ll make the assumption that all of our communications are over TLS so that protects the user and us from people snooping in on our connections. But happens if the user is behind a corporate firewall using a company device? Well, oftentimes corporate firewalls install x.509 certificates on company devices so that they can read all of the data even in TLS encrypted conversations. This means that a corporate firewall or someone at the company with access to that firewall can read all of the data being sent.
Then the question becomes, “Should we protect against that?”. For a simple news aggregation application like this we probably don’t care. For a password manager or banking application, maybe. There are a lot of factors that one must consider when making this determination such as difficulty of implementation, trade offs in speed, and even legality.
Another thing to consider are the properties that you desire of that data. In some cases, confidentiality is not necessarily needed but integrity is. In those cases, you might just use an HMAC or signature to provide those properties.
Cryptography in Android
I’ll be honest; this is a sore topic for me.
Before API 23 (that’s android 6.0 for all of you non-android developers), the cryptographic options were less than desirable, in my opinion. I say this because mobile devices have a really awesome opportunity to instill strong security with regards to cryptography through use of the Android KeyStore, also known as the Trusted Execution Environment. This is a separate chip on your device that is locked down physically and digitally that has role of performing cryptographic functions like encryption, signing, and key generation. It can also store keys and keep keys locked until a user authenticates with a fingerprint or pin code. While the TEE existed on devices before API 23, its capabilities as defined by software were limited to mostly RSA.
With API 23+ being somewhat popular on devices, we’ll get to see stronger and stronger key generation and encryption being used. Here’s an example of how strong key generation might be done for AES 256 GCM:
Just three lines (technically..). This creates a SecretKey object that we can retrieve by calling getKey on an Android KeyStore instance. The best part about generating keys with the Android KeyStore like this is that if we take the SecretKey instance and called getEncoded (which returns the encoded form of the key — the secret in this case) it will return null. This is because the key is locked away in the KeyStore and the SecretKey instance, in this case, works a lot like a primary key in a database. We can use this instance to reference the key in the database but until we do some sort of operation with the SecretKey, it won’t show/do anything.
So if the SecretKey is locked away in the KeyStore never to be found, how do we use it for cryptographic functions?
Passloch does a lot more with cryptography and to support end-to-end encryption of all of the user’s sensitive material than what was demonstrated here. Closer to the release date, I’ll make the code base open source so other can learn and contribute to it if desired.
Closing Remarks
Next week, I promise to have lots of new stuff from the book to talk about but I’m happy that I was able to finally talk about cryptography a little. I definitely needed to take the break and catch up on work with my side project as it has been falling behind with me doing so many other things.
Anyway, as always…
See ya next week!
