This is the third of a series of posts discussing the paper A Comprehensive Approach to Cryptographic and Biometric Authentication from a Mobile Perspective.
Credentials based on public key cryptography provide much stronger security than ordinary passwords or one-time passwords. But a mobile device can be lost or stolen. How can a credential kept in a mobile device be protected if the user’s device is captured by an adversary? Two methods are traditionally used:
- Private key encryption. The private key is encoded as specified by PKCS #8, together with cryptographic parameters that typically include the public key or a public key certificate, and the resulting encoded string is encrypted under a symmetric data-encryption key derived from a passcode. This method is used, for example to protect SSH credentials used to manage cloud-hosted virtual servers. But as explained in Section 4.3.1 of the paper this method requires a high-entropy password, which is exceedingly difficult to type on the touchscreen keyboard of a smart phone.
- Tamper resistance. This is relied upon, for example to protect credentials in smart cards such as PIV or CAC cards. But few mobile devices have tamper resistant modules.
On an iPhone or an iPad one could think of relying on the data protection method introduced in iOS 4, which encrypts data in a locked device under a key derived from the passcode that the user enters to unlock the device and a key embedded in a hardware encryption chip. But, as explained in section 5.1 of the paper, that method has not proved to be effective.
Instead, Section 2 of the paper proposes a method for using an uncertified key pair for multifactor closed-loop authentication that makes it possible to protect the key pair without relying on any special hardware. The method is generally applicable, but is particularly useful for authentication on a mobile device. The idea is to store in the device cryptographic parameters obtained during initial credential generation, at least one of them being a secret, and later, at authentication time, to regenerate the credential from the stored cryptographic parameters and non-stored secrets supplied by the user such as a PIN and/or a biometric sample. (The non-stored secrets could be supplied by a physical uncloneable function, a PUF, in the case of an autonomous device; but the paper is not concerned with autonomous devices.) We refer to the stored parameters as a protocredential. Possession of the protocredential counts as one authentication factor, while the non-stored secrets play the role of additional authentication factors.
The paper distinguishes between parameters related to the key pair and parameters related to the non-stored secrets. In the case where a PIN is the only non-stored secret, illustrated in Figure 2, there is one non-stored-secret related parameter, a salt used to compute a randomized hash of the PIN. (Two-factor authentication with a biometric sample and three-factor authentication with a PIN and a biometric sample are discussed in Figures 3 and 4. I will discuss biometric authentication in the next blog post.) The key-pair related parameters depend on the public key cryptosystem being used. In the case of DSA and ECDSA, the key-pair related parameters are the domain parameters specified in the Digital Signature Standard. In the case of RSA, there is one key-pair related parameter, the least common multiple λ of p-1 and q-1, where p and q are the prime factors of the modulus. The key pair regeneration procedures for DSA, ECDSA and RSA are described in sections 2.6.2, 2.6.3 and 2.6.4 respectively.
In a mobile device, once the key pair has been regenerated, it is used by the device to authenticate to a mobile application with which the device has been previously registered. The application may have a native front-end or use a web browser as its front-end. The application back-end has a database that contains a record for the device, identified by a device record handle (a database primary key). To authenticate, the device sends the device record handle and the public key to the application back-end and demonstrates knowledge of the private key by signing a challenge. The back-end verifies the signature, uses the device record handle to locate the device record, computes a cryptographic hash of the public key, and verifies that the hash coincides with a hash stored in the device record. (A mobile authentication architecture that allows application developers to implement the authentication process without using a cryptographic API is described in Section 7; I will discuss it in another post later in this series.)
An adversary who captures the device and is able to read the protocredential needs the non-stored secrets to be able to regenerate the credential and authenticate. The adversary can try to guess the non-stored secrets. If a PIN is the only non-stored secret and the user chooses a 4-digit PIN, the adversary only has to try 10,000 PINs. If the adversary can test each PIN offline, it is trivial to go through all 10,000 PINs. But all PINs (in the case of DSA and ECDSA) or most PINs (in the case of RSA) produce well-formed key pairs. If the adversary does not know the public key (nor a hash of the public key), the only way to test a PIN is to try to use the key pair that it produces to authenticate online against the application back-end; and the back-end can limit the number of guesses to a very small number, such as 3 or 5 or 10. A 4-digit PIN can then be deemed to provide sufficient security, just as 4-digit PIN is usually considered secure enough for withdrawing cash from an ATM, which also limits the number of PIN guesses.
To ensure that the adversary does not know the public key, the public key should be treated as a shared secret between the device and the application back-end. Treating a public key as a secret is an unconventional and paradoxical use of public key cryptography. Section 4.1 explains that a shared symmetric secret could be used instead of a key pair but would result in a weaker security posture.
To prevent a man-in-the-middle attack, the device connects to the back-end using TLS (or some other kind of secure connection). Furthermore, the challenge signed by the device to demonstrate knowledge of the private key includes the TLS server certificate of the application back-end. Section 2.1 explains how this prevents a man-in-the-middle attack even if the adversary is able to spoof the TLS server certificate of the back-end.
All this results in a very strong defense-in-depth security posture. As discussed in Section 4.2 and summarized in Table 1, authentication is secure even against an adversary who is able to:
- Capture the user’s device and read the protocredential from the device storage; or
- Breach the security of the database back-end and obtain the hash of the public key. The adversary cannot mount an offline attack against a PIN used as single non-stored secret because the adversary does not have the protocredential, which contains at least one secret parameter. Compare this to the effect of a breach of database security when the database contains hashes of passwords, all of which become vulnerable to offline dictionary attacks; or
- Breach network security and read the traffic from the device to the back-end (e.g. after the TLS connection has been terminated at a reverse proxy, in a misconfigured infrastructure-as-a-service cloud). Again, the adversary cannot mount an offline attack against the PIN; or
- Spoof the TLS server certificate of the application back-end, as discussed above.
Also, in use cases demanding exceptionally high security, by using a high-entropy set of non-stored secrets, it is possible to achieve security even against an adversary who breaches database or communication security and then captures the device and obtains the protocredential.
We have seen how to protect an uncertified key pair used for closed-loop authentication. How about other types of credentials? Section 5 shows how the multifactor closed-loop authentication method discussed above can be used to provide effective protection for data stored in a mobile device, and in particular to provide protection for any kind of credentials, including credentials used for open-loop authentication, such as such as public key certificates, U-Prove tokens or Idemix anonymous credentials.
In the next post I will discuss the use of a biometric sample as a non-stored secret, and explain how it can achieve strong security without putting at risk the confidentiality of the user’s biometric features.