Electronic identity is an important concept as it lies on the crossroads of the digital, the physical and the legal worlds. How do you prove your identity without being physically present? I’ve previously given an overview talk on electronic identification, tackled the high-level and philosophical aspects, and criticized biometric-only identification as insecure. Now I want to list a few practical ways in which eID can be implemented.

First, it’s important to mention the eIDAS regulation which makes electronic identity a legal reality. It says what an electronic identification scheme is and what are its legal effects (proving that you are who you claim to be). And it defines multiple “levels of assurance”, i.e. the levels of security of a method of authentication. But it is a broad framework that doesn’t tell you how to do things in the technical world.

And while electronic identification is mostly cited in the context of government and municipal services, it applies to private companies as well. Currently in the US, for example, the SSN is used for electronic identification. This is a very poor approach, as leaking the SSN allows for identity theft. In the EU there are many different approaches to do that, from the Estonian PKI-based approach, to UK’s verify initiative, which relies on the databases of private companies.

You can see electronic identity as a more legally-meaningful login. You still perform a login, in many cases using username and password as one of the factors, but it carries additional information – who is the actual person behind that login. In some cases it doesn’t have to even give information on who the person is – it can just confirm that such a person exists, and some attributes of that person – age (e.g. if you want to purchase alcohol online), city of registration (e.g. if you want to use municipal services), conviction status (e.g. if applying for a driver in an Uber-like service). It is also very useful when doing anti money laundering checks (e.g. if you are a payment provider, an online currency or crypto-currency exchange, etc.)

Electronic identification schemes can be public and private. Public are operated by governments (federal or state in the case of the US), a particular institution (e.g. the one the issues driver’s licenses). Private ones can be operated by any company that has had the ability to verify your physical identity – e.g. by you going and signing a contract with them. A bank, a telecom, a utility company.

I will use “authentication” and “identification” interchangeably, and for practical purposes this is sort-of true. They differ, of course, as authentication is proving you are who you are, and identification is uniquely identifying you among others (and they have slightly different meanings when it comes to cryptography, but let’s not get carried away in terminology).

Enrollment is the process of signing you up in the electronic identification scheme’s database. It can include a typical online registration step, but it has to do proper identity verification. This can be done in three ways:

• In-person – you physically go to a counter to have your identity verified. This is easy in the EU where ID cards exists, and a bit harder in the US, where you are not required to actually have an identity document (though you may have one of several). In that case you’d have to bring a birth certificate, utility bills or whatever the local legislation requires
• Online – any combination of the following may be deemed acceptable, depending on the level of assurance needed: a videoconferencing call; selfie with an identity document; separate picture of an identity document; camera-based liveness detection; matching of selfie with government-registered photo. Basically, a way to say that 1. I have this document 2. I am the person on the document. This could be automated or manual. But does not require physical presence.
• By proxy – by relying on another eID provider that can confirm your identity. This is an odd option, but you can cascade eID schemes.

And then there’s the technical aspects – what do you add to “username and password” to make identity theft less likely or nearly impossible:

• OTP (one-time passwords). This can be a hardware OTP token (e.g. RSA SecureID) or a software-based TOTP (like Google Authenticator). The principal of both is the same – the client and the server share a secret, and based on the current time, generate a 6-digit password. Note that storing the secrets on the server side is not trivial – ideally that should be on an HSM (hardware security module) that can do native OTP, otherwise the secrets can leak and your users can be impersonated (The HSM is supposed to not let any secret key leave the hardware). There are less secure OTP approaches, like SMS or other type of messages – you generate one and send it to a registered phone, viber, telegram, email, etc. Banks often use that for their login, but it cannot be used across organizations, as it would require the secrets to be shared. Because the approach is centralized, you can easily revoke an OTP, e.g. declare a phone or OTP device as stolen and then go get a new one / register a new phone.
• PKI-based authentication – when you verify the person’s identity, have them generate a private key, and issue a X.509 certificate for the corresponding public key. That way the user can use the private key to authenticate (the most straightforward way – TLS mutual authentication, where the user signs a challenge with the private key to confirm they are the “owners” of the certificate). The certificate would normally hold some identifier which can then be used to fetch data from databases. Alternatively, the data can be on the certificate itself, but that has some privacy implications and is rarely a good option. This option can be use across institutions, as you can prove you are the person that owns a private key without the other side needing to share a secret with you. They only need the certificate, and it is public anyway. Another benefit of PKI-based authentication is revokability – in case the user’s private key is somehow compromised, you can easily revoke a certificate (publish it in a CRL, for example).
• Biometrics – when you are enrolled, you scan a fingerprint, a palm, an iris, a retina or whatever the current cool biometric tech is. I often argue that this cannot be your main factor of authentication. It can and sometimes should be used as an additional safeguard, but it has a big problem – it cannot be revoked. Once a biometric identifier is leaked, it is impossible to stop people from using it. And while they may not be able to fool scanners (although for fingerprints that has been proven easy in the past), the scanners communicate with a server which perform authentication. An attacker may simply spoof a scanner and make it seem to the server that the biometric data was properly obtained. If that has to be avoided, scanners have to themselves be identified by signing a challenge with a private key in a secure hardware module, which make the whole process too complicated to be meaningful. But then again – the biometric factor is useful and important, as we’ll see below.

The typical “factors” in an authentication process are: something you know (password, PIN), something you have (OTP token, smartcard, phone) and something you are (biometrics). The “something you have” part is what generates multiple variations to the PKI approach mentioned above:

• Use an unprotected storage on a computer to store the private key – obviously not secure enough, as the private key can be easily extracted and your identity can thus be stolen. But it has to be mentioned, as it can be useful in lower-risk scenarios
• Use a smartcard – a hardware device that can handle PKI operations (signing, encryption) and does not let private keys leave the hardware. Smartcards are tricky, as they require a reader (usually plugged via USB) and vendor-specific drivers and “magic” to have browser support. Depending on the circumstances, it could be a good approach, as it is the most secure – there is no way for someone to impersonate you, apart from stealing your smartcard and knowing both your smartcard PIN and your password. The problem with plugging the smartcard can be alleviated by utilzing NFC with a smartphone (so just place the card on the back of the smartphone in order to authenticate) but that leads to a lot more other problems, e.g. how to protect the communication from eavesdropping and MITM attacks (as far as I know, there is no established standard for that, except for NFC-SEC, which I think is not universally supported). The smartcard can be put on a national ID card, a separate card, or even the ones in existing bank cards can be reused (though issuers are reluctant to share the chip with functionality (applets) other than the EMV).
• Use a smartphone – smartphones these days have secure storage capabilities (e.g. Android’s Trusted execution environment or iPhone’s Secure Enclave). A few years ago when I was doing more thorough research, these secure modules were not perfect and there were known attacks, but they have certainly improved. You can in many cases rely on a smartphone to protect the private key. Then, in order to authenticate, you’d need a PIN or biometrics to unlock the phone. Here’s when biometrics come really handy – when they don’t leave the phone, so even if leaked, they cannot be used to impersonate you. They can only be used to potentially make a fake fingerprint to unlock the phone (which should also be stolen). And of course, there’s still the password (“something you know”).
• Remote HSM – the private keys can be stored remotely, on a hardware security module, so that they cannot physically leave the hardware. However, the hardware is not under your physical control and unlocking it requires just a PIN, which turns this scheme into just “something you know” (times 2, if you add the password). Remote identification and remote signing schemes are becoming popular and in order for them to be secure, you also have to somehow associate the device with the particular user and their private key on the HSM. This can be done in a combination of ways, including the IMEI of the phone (which is spoofable, though) and utilizing some of the aforementioned options – the protected storage of the phone and OTPs handled behind the scene. (Note: the keys on the HSM should be in the protected storage. Having them in an external database encrypted by the master key is not good enough, as they can still leak). If you are going to rely on the smartphone secure storage anyway, what’s the benefit of the remote HSM? It’s twofold – first – loosing the phone doesn’t mean you cannot use the same key again, and second – it reduces the risk of leaking the key, as the HSM is theoretically more secure than the smartphone storage
• Hybrid / split key – the last two approaches – the smartphone secure storage and the remote HSM can be combined for additional security. You can have the key split in two – part in the smartphone, part on the HSM. That way you are reducing the risk of the key leaking. Losing the phone, however, would mean the key should be regenerated and new certificates should be issued, but that may be okay depending on the usecase.

As you can see, the smartphone secure storage is becoming animportant aspect for electronic identification that is both secure and usable. It allows easily adding a biometric factor without the need to be able to revoke it. And it doesn’t rely on a clunky smartcard that you can’t easily plug.

I won’t go into the details of the the server side of things – how is the single-sign-on handled (e.g. using SAML 2.0 or OpenID Connect), how are identity providers federated, how multiple countries’ schemes can be interconnected. From a UX point of view, normally the user clicks “login with eID”, gets redirected to a page on the identity provider domain, gets asked to authenticate (via mobile, smartcard, otp, password, whatever), and then gets redirected to the service provider, which can obtain a token from the URL and exchange that token for information about the authenticated person. In a federated context there could be some additional redirects and/or choosing a provider from a dropdown.

So obviously this is not everything that can be said about secure electronic identification, but I think it’s enough details to get a good picture. It’s not trivial and getting it wrong may lead to real-world damages. It is viewed as primarily government-related, but the eID market in Europe is likely going to grow (partly thanks to unifying the legislation by eIDAS) and many private providers will take part in that. In the US the problem of identity theft and the horrible practice of using the SSN for authentication is being recognized and it’s likely that legislative efforts will follow to put electronic identification on track and in turn foster a market for eID solutions (which is currently a patchwork of scanning and manual verification of documents).

The ultimate goal is to be both secure and usable. And that’s always hard. But thanks to the almost ubiquitous smartphone, it is now possible (though backup options should exist for people that don’t have smartphones). Electronic identification is a key enabler for the so called “digital transformation”, and getting it right is crucial for the digital economy. Apologies for the generic high-level sentence, but I do think we should have technical discussions at the same time as policy discussions, otherwise the two diverge and policy monsters are born.