-
Notifications
You must be signed in to change notification settings - Fork 16
Design Documentation
Tiqr was designed late 2010 to improve both the usability and the security of multi-factor authentication (MFA) over existing solutions.
At the time, most multi-factor authentication solutions were based on small hardware devices that were expensive, easy to forget, and used proprietary technologies that were not interoperable. To improve usability, a software-based solution running on a user's mobile device was designed, initially dubbed mobi. This was not a novel idea, as Google had release its authenticator app a little earlier. What was new was to use modern features of mobile phones to improve usability, such as the phones camera and the fact that phones could communicate over the Internet with an authentication server, either to receive authentication requests (using push notifications) or to send authentication responses.
tiqr is a mobile application for 2-factor authentication. It implements the OCRA challenge-response authentication algorithm based on a secret shared between the phone and an authentication server. The authentication challenge is generated on the server and presented to the phone using a QR code, or send to the phone using a push notification if the user is already known. The user authenticates by entering a PIN to unlock its shared secret with which a response is calculated. The response it sent to the authentication server using HTTPS, where it is verified with the secret shared with the server.
Two basic principles relevant to the design of tiqr are:
- no homebrew cryptography
- phones cannot keep secrets
These are elaborated on below.
tiqr is designed to use only standard cryptographic building blocks, so as to reuse known-good algorithms and well-tested implementations thereof. No innovation was desired in this respect, and it was decided to use an OATH algorithm as the core authentication algorithm.
To improver interoperability, The Initiative for Open Authentication (OATH) was formed to standardise MFA algorithms, resulting in several IETF standard algorithms for generating one-time-passwords (OTPs). These standards HOTP, TOTP, and OCRA were all based on shared secrets and the HMAC authentication algorithm, differing only on the source of the HMAC input message (a counter, a timestamp, or an explicit challenge, respectively).
OCRA was the less popular algorithm as it required arbitrary input strings to be provided by the user. On a mobile phone this was not a problem however, making OCRA attractive because of its added security benefits.
In 2010, phones did not have secure hardware to protect data stored on the phone, like today's iPhones with Secure Enclave, or Android Devices with for instance titan chips. This means one has to assume that the shared secret used in the OCRA algorithm has to be stored on disk, and that an attacker getting hold of the phone is able to retrieve any information stored on the phone.
For this reason, the shared secret needs to be encrypted before being stored. The decryption key however, cannot be stored on disk either for the same reason, but can also not be memorised by the user. The solution is to encrypt the shared secret using AES with a key derived from a user PIN. This way, the inability to store a secret on a phone is compensated by storing the PIN in the user's brain (not secure hardware per se, but good enough to protect against adversaries with access to the phone).
Note that it is easy to brute-force a PIN, but as the authentication algorithm needs to perform an authentication to discover if it has used the correct shared secret, such brute-force attacks can be mitigated on the server. For instance by blocking user accounts after too many failed authentications, or by using some exponential backoff algorithm to substantially increase the time required to search the entire PIN space.
An earlier version of tiqr used public key cryptography in a challenge-response algorithm. This has the benefit of not having to share a secret with the server. Only a public key need to be stored on the server for verifying authentication responses, while the private key is stored on the client phone. At the time, the only public key algorithm readily available on mobile devices was RSA, which has the problem that it has too much structure in its private keys (a minimal representation of an RSA private key contains two prime numbers, which are easily distinguished from random data). This means one cannot protect the private key by encrypting it using a key derived from a PIN, as an attacker could easily brute-force the PIN space to discover the private key using a primality test. Note that using an ECC-based challenge-response algorithm like P256 would have been feasibly, as its private key can be arbitrary integers.
TODO:
- mnemonics
- biometrics
- push notifications and token exchange
- fallback when offline
- use on mobile phones
tiqr was presented during LISA'11, the 25th international conference on Large Installation System Administration (December 2011). See tiqr: a novel take on two-factor authentication.