Improve your app’s cryptography, from message authentication to user presence

In a perfect world, nobody needs cryptography. Everyone keeps their hands, eyes, and ears to themself; every parcel is delivered to the intended recipient without tampering; and every sender is trustworthy. But we don’t live in a perfect world. Over the past several decades, cryptography has evolved to ensure not just confidentiality through encryption but also message integrity, authentication, and nonrepudiation — all in an effort to keep messages private, authentic, and reliable.

It might be tempting to think that if your systems have a cryptographically solid implementation, then you don’t need biometrics for verifying user presence. To understand why verifying user presence might be important in a cryptographic world, let’s look at the triumphs and failures of several attributes of cryptography in turn. From there, see why you — a provider of high-value services such as banking or healthcare — might want to implement biometric authentication in addition to cryptography.

Encryption alone doesn’t prevent certain types of attacks

You can think of encryption as a function, say E, that takes in a message m and a key k and, from those parameters, produces a ciphertext c. The ciphertext is usually what everyday people refer to as the encryption, but in fact the encryption is the algorithm that produces the scrambled message that adversaries cannot read. The scrambled message itself is called the ciphertext.

c = E(m,k)

It’s practically impossible to determine the secret key k when you only partially know m or c, as long as the value of k is sufficiently large. But an adversary doesn’t need to decrypt a message in order to tamper with it. The adversary might be able to edit the ciphertext, delete the ciphertext, or resend a message that contains the ciphertext (using a process called a replay).

Not all adversaries want to steal your data; they may just want to inconvenience you. Imagine an adversary who simply replays the encrypted transaction of the $2,000 you paid to the computer store for your laptop. Assuming this is a third-party adversary who has no affiliation with the computer store, this adversary steals nothing. And you will get your money back after some disputes with the computer store. Yet you still suffer some damage in terms of time and emotional energy. Worse still, an observant adversary might be able to replace the bank account of the computer store with some other bank account — all without ever decrypting the ciphertext.

Of course we’re just scratching the surface here. There are many more well-known attacks against encryption-only solutions. And even if your encryption algorithm manages to thwart all the known attacks, there is still Emerson’s prophecy that it is the privilege of the truth to make itself known. Simply restated, you cannot keep a message private forever. Even with the best practical cryptographic designs, the pace of current technological advances only lets your messages remain private for about 30 more years, maybe 50 years with some luck. Hence, encryption by itself isn’t all that great against message integrity attackers. You also need some sort of authentication, which the next section explores.

Preserving originality with message authentication

Being deceptively misinformed in sensitive circumstances can be damaging. That’s the essential truth that inspired security engineers to create the Message Authentication Code (aka MAC or HMAC). If a sender sends a MAC along with the message, then an adversary can no longer modify the message and pretend that it’s the original message. Neither can an adversary replay the message. The best an adversary can do is delete the message so that the communication fails altogether.

What is a MAC? A MAC a is similar to a ciphertext in that it is computed using the message and a secret key. Essentially, the sender runs the message m and a secret key k through a function h, and a MAC is generated. Then the sender sends both the message and the MAC to the recipient.

m,a = h(m,k)

MACs aren’t unique per message due to the pigeonhole principle, which basically says if you have more pigeons than holes then some holes will have to house more than one pigeon. MACs have predetermined sizes, so that there are many more possible messages than MACs. It’s just that the search space is too large for an adversary to guess which MAC would go with a modified message without knowing the secret key. Hence, the reason a MAC is effective against message modification is because the secret key k is only known to the sender and the intended recipient. If an adversary changes the message, that adversary would have to also change the MAC to match, and without knowing the secret key, that’s practically impossible. Replay attacks fail because running m,a = h(m,k) twice in a row will result in two different MACs. That’s because in practice there’s usually a strictly increasing third parameter t in the function: hence we could rewrite the equation as m,a = h(m,k,t). Therefore, the MAC function helps rightful recipients to readily verify whether a replay attack occurred.

A MAC essentially requires an attacker to crack the secret key. In the presence of a MAC, imitation of the original message can no longer succeed. Integrity is built-in. As useful as MACs are, they do have some limitations when it comes to confidentiality, which the following section explains.

Signed but not sealed

It is important to note that a MAC simply signs a message but doesn’t seal it — so there’s no confidentiality. An adversary can still read the message; they just cannot change it effectively. But it’s not that difficult to both sign and seal a message. Instead of computing m,a = h(m,kₐ), simply use algebraic substitution to obtain c,a = h(c,kₐ)where c is the ciphertext obtained from c = E(m,k𝒸).

Good cryptography algorithms are like good houses. They are supposed to withstand storms not just for one day but for 30 years or longer. For cryptographers more specifically, this means anticipating adversaries who will try to crack your algorithm not just tomorrow or next month but in 10, 30 years — by which time they will have the advantage of technologies that aren’t even invented yet. Hence, a MAC doesn’t make encryption unbreakable. It just makes the work of an adversary more difficult. Attackers 30 years from now may be able to use techniques like birthday attacks or meet-in-the-middle attacks to guess the MAC’s value for an edited message, thereby causing recipients to accept imitation messages.

Asymmetric encryption scales more elegantly

So far we have discussed how cryptographers pair encryption with MAC to create signed and sealed messages. We have also discussed that the best an attacker can do is delete such messages; otherwise the message is delivered successfully, privately, and intact. It sounds like this should be all we need. But there is more. But before we discuss the “more,” let’s chat a bit about scale.

Most of the techniques discussed so far are collectively known as symmetric cryptography. Simply put, they depend on both the sender and the receiver using the exact same secret keys to encrypt and decrypt the message, and to create and verify the MACs. The problem with this approach is that, if a group has 10 members, then each member needs to share and store 9 different secret keys in order to send encrypted messages between any two members. That’s a total of 45 keys. For twenty people it’s already 190 keys; more generally, for n people it’s (n-1)n/2 keys. Imagine if, for every person in your contacts list, you had to have a different personal phone number for each person? So instead of having just one phone number that you give out to every contact, each time you make a new friend, you would need to buy an additional phone number! That’s the problem with symmetric encryption. Scaling is tough. Thankfully, there is asymmetric cryptography.

Asymmetric cryptography uses insights from number theory — in particular finite field theory and one-way functions — to achieve its elegance. Essentially each person creates a public key and a private key. Anyone who wants to communicate with you can use your public key to send you encrypted messages, but only your private key can decrypt those messages.

The intention here is not to get too deep into the number theory, but rather to bring asymmetric encryption into the conversation. You must use asymmetric encryption to support nonrepudiation, the next attribute of cryptography we discuss below.

The need for nonrepudiation

Nonrepudiation is simply a professional way of saying “no takebacks.” The e-commerce revolution has brought this very simple rule of fair play to the front and center in the world of cryptography.

In the world of symmetric cryptographic keys, the person who receives a message (say Bob) cannot prove to a judge that the sender (say Alice) is the one who actually sent the message. That’s because both Alice and Bob share the same secret key. Maybe Alice did send the original message but Bob altered it, or maybe Alice is lying. Either way, a judge cannot tell.

With asymmetric keys, however, only the person who holds the private key can sign a message. Anyone in the world can read the signature since the public key is after all public. Hence it would go like this: when Alice needs to buy something from Bob, she would use Bob’s public key to encrypt the transaction but use her own private key to add a signature to the transaction. Then when Bob receives the message, he would use Alice’s public key to verify that Alice’s private key was used to sign the transaction, and then use his own private key to decrypt the message. Hence, signature is used to provide nonrepudiation. MAC and Signature are essentially the same thing, except that one is for symmetric encryption and the other is for asymmetric encryption.

A brief recap

Now let’s recap. Cryptography is used to encrypt and authenticate messages, and to provide nonrepudiation. When the right techniques are applied, the authentication and encryption portions can be difficult to break — they depend on very hard math problems such as prime factorization, discrete logarithms, and elliptic curves, which are then applied to finite fields. It’s important to point out that while getting the encryption keys using mathematical analyses may be difficult, there are many other ways to break into a secure system such as social engineering, where an individual might be tricked into divulging confidential information. Also we didn’t include key generation and certification in our discussion because the point has been sufficiently made: As an engineering discipline, Cryptography will need to continue evolving to meet the demands of the times, in an attempt to stay ahead of adversaries.

Unlike encryption and authentication, however, nonrepudiation is a bit trickier, which is where user-presence verification might add an additional layer of difficulty for adversaries.

The importance of being present

At this point we have shown that cryptography is all about security level: how expensive (time, money, energy) it is for an adversary to tamper with a correspondence. Nonetheless, there is still a major problem: Just because a message originated from a device that I own and was signed with my private keys does not mean I sent the message. A virus or unauthorized user might have sent the message instead. For these and similar reasons, although digital signatures have been made into law internationally as ESIGN, many global merchants still don’t trust them because nonrepudiation is hard to argue without proof of user-presence, and the burden of proof does lie with the merchant.

To bolster merchant confidence in nonrepudiation, the industry has introduced Two Factor Authentication (2FA). Because cybercriminals have repeatedly broken into online accounts that are protected only by username-and-password, 2FA brings forth the idea of requiring one more thing from the agent who claims to be the rightful user. That one more thing generally falls under one of three categories: something you know, something you have, or something you are. The aim of 2FA is to give merchants confidence that the user is indeed present during a transaction. Two of the most common forms of 2FA are key fobs and verification codes that are often sent using SMS. The problem with key fobs and similar hardware tokens is that they can be lost or stolen. And an SMS message provides zero defense-in-depth for 2FA if the compromised device is the same device that receives the SMS or push notification. Hence the most advanced forms of 2FA today fall under something you are. Biometric authentication is an example of such advanced 2FA.

By including biometrics — verifying user presence — in your security implementation, your app becomes even safer and nonrepudiation becomes a reliable feature of your business model. For a healthcare or hospitality app this may mean more reliable user check-ins or cancellations. For an ecommerce or banking app, this may mean your customer service team spending less time refunding unintentional purchases made by toddlers and more time making your customers happy in more delightful ways.

The fundamental reason that makes biometric authentication a true additional hurdle against adversaries of your security system is because while biometrics and cryptography are completely independent of each other, they are both difficult for an adversary to tamper with. Ergo, their combined power makes the job of an adversary that much harder.

On Android, for example, biometric verification is a one way street. A user’s biometric information never leaves the device and is never shared with applications. When a user decides to add their biometrics to their Android device, they must do so through the system’s Settings app. If they are using their fingerprint (or face), they place their finger on a sensor which passes the fingerprint image directly to a restricted area on the Android device, referred to as the Trusted Execution Environment (TEE). Then later, when your app wants to verify user-presence through biometric authentication, the Android Framework and the biometric system on Android, which lives in the TEE, handle the entire user-presence verification process for your app. And because the Framework makes it extremely difficult to spoof the device owner’s biometrics, you can have a high level of confidence about the user-presence confirmation.

For a more in-depth treatment of how biometrics works under the hood on Android to augment your security solutions with nonrepudiation, see our blog post on using BiometricPrompt with CryptoObject.

Summary

In this post you learned the following:

• Why a good cryptography implementation needs to address confidentiality, authentication, and nonrepudiation.
• Why encryption alone is not enough to protect messages from adversaries.
• Why MAC/HMAC are effective against message modification
• Why asymmetric cryptography scales better than symmetric cryptography
• Why nonrepudiation is difficult to achieve in real life without biometric authentication
• Why biometric authentication makes a cryptography implementation stronger through user-presence verification.
• Where to go for how to implement biometric authentication in your apps.

We have also written a number of blog posts about engineering best practices, design guidelines, and tips for incorporating biometrics into your app.

• For more information about how to implement your app using biometric authentication, check out this 2-part blog series: Part 1, Part 2.
• If your app includes older logic that uses FingerprintManager, we recommend that you use BiometricPrompt instead. Learn more about BiometricPrompt as a whole in One Biometric API Over all Android, and learn how to complete the migration in this post: Migrating from FingerprintManager to BiometricPrompt

Happy Coding!