Status quo of digital identities and the management

Centrally hosted online identities with user databases

A step in the right direction of handling digital identities was to establish the linkability of these identities and central user databases. Collaboration enables online providers to link users, usually via the same username, email address, or by comparing attributes. This principle, which is addressed here in a very rudimentary way, is called federated identity or federated identity management.

Even if this approach brings relief for the user, it is still necessary that we manage our accounts and passwords securely. But unfortunately, good handling on the part of the user does not automatically bring a high level of protection; we continue to see breaches, hacks on identities, or the unknowing linking of user identity data, e.g. for monetization on the provider side. The real problem is that our data still remains within these centralized service providers and, strictly speaking, is also in their ownership in many cases, or at least under their sovereignty.

Legislation such as the General Data Protection Regulation (GDPR) has led to better privacy protection and IT security for the management of digital identities. Nevertheless, many service providers accept loopholes because it is difficult to prove violations and the risk of high fines is rather low. Even if this can be proven, it is not guaranteed, that security leaks or missing security measures in user databases containing personal information will be exploited by attackers. Such targets are simply too concentrated and coveted for that. Even techniques such as multi-factor authentication (Proof of identity using a combination of two or more different factors, e.g., by querying knowledge and possession) are usually not enough to stop any compromises.

So, we notice that federated identities also continue to have user database weaknesses, especially as they continue to be highly centralized.

Identity management with digital certificates & PKI

Another very important concept is offered by digital certificates. They are widely used and form an important basis for security in today’s web-enabled world. In part, they also technically complement the previously discussed approach of centralized user databases. In the following, we will discuss this approach in more detail to show the advantages and disadvantages, since some elements from this concept are also applied in the case of decentralized identities.

First of all, a digital certificate is just a data record that adheres to a certain standardized form (e.g., x509) and can confirm the identity of the owner or an object, as well as other properties, by means of a cryptographic process. In particular, it helps to verify the authenticity and integrity (freedom from manipulation) of the identity of a person or object and the properties attributed to it. For this purpose, a certificate consists of various information, including a serial number and an expiration date. It also contains the digital verifiable signature of the issuing authority, the so-called Certificate Authority (CA), and the public key of the certificate holder. In addition, a certificate can contain rules that allow the certificate holder to act within defined parameters.

Furthermore, digital certificates require a kind of technical construct in which they can operate. This construct is called a public key infrastructure (PKI), which is essentially responsible for exchanging, issuing, and managing these digital certificates, i.e., identity management.

Typical use cases of PKI-based certificate identities we find

  • in email encryption and signature,
  • in the digital signing of documents,
  • when authenticating to cloud services or other on-premises applications,
  • in secure communication in the corporate environment (servers, terminals, interfaces, routers),
  • when accessing corporate networks (WIFI & VPN),
  • for digital test marks,
  • or already in authentication and secure communication between networked devices on the Internet of Things (IoT), Industry 4.0, connected driving.

In summary, digital certificates and a PKI provide the means for authentication and signature verification of entities, as well as data encryption and secure exchange of information.

How does the PKI work?

Identity management with digital certificates within a public key infrastructure requires the following core components and actors:

The Certificate Authority (CA): The Certificate Authority forms the basis of trust of a PKI. It contains several elements and procedures that are used, for example, by a company to issue and store digital certificates. However, it is essential that the CA is responsible for the cryptographic signing of certificates and that it is therefore possible to prove that a certificate was issued or signed by precisely this CA. This is important to be able to validate that this CA belongs to a trustworthy entity, e.g., a company, online service or government agency. In addition, a CA can determine and verify the validity of a certificate. If a certificate is invalid or even revoked (due to a loss of trust), this can be detected.

Registration Authority (RA): The RA is an entity that ensures the identification and registration of a subscriber or an identity holder. The identity holder is an entity, e.g., a company, another CA, a device, a system, or a person. The RA ensures that the CA can trust that only certificate requests processed by the RA are accepted and signed.

The concept of public key infrastructure is essentially based on asymmetric encryption, which uses a public key and a private key. These are initially nothing more than bit sequences. In cryptography, these public and private keys are used very frequently to encrypt and decrypt data. Public and private keys are always generated as a pair and are therefore mathematically linked. A communication participant, e.g., a person with a PC or a networked device, creates its key pair for a purpose, for example, by means of a security module (e.g., hardware security module) on the device. While the private key remains safely stored in the security module, the public key is used for exchange. While this exchange is easily possible, the problem is that a third party in the digital world cannot verify that the person being interacted with is who they claim to be.

This is not done with an easily forgeable and weak handwritten signature as in the real world, instead using a digital and cryptographically secure signature (e.g. via DSA or RSA). However, this signature should be verifiable, preferably, in the concept of PKI, by a verifiable body and not by the entity itself.

This is where the Certification Authorities (CAs) come into play, forming a trusted entity. For that, the entity transfers the public key to a CA after the entity has been checked by the Registration Authority (RA). The CAs also have their own public key and private key. The CA now takes the entity’s public key and issues the entity an X.509 certificate with this entity’s public key. This certificate is signed with the CA’s private key and returned to the entity.

In short, the certificate authority has used its private key to sign the public key of the entity in the format of the certificate that this public key is actually that of the entity.

This certificate can now be used by the entity and transferred to a third party. The third party can verify this certificate because the entity’s public key has been registered with the CA and the certificate has been signed by the CA. This is done automatically by verifying the CA’s signature with the CA’s available public key. This means that the third party can be sure that the entity’s public key has not been exchanged and can now establish each other’s identities if both recognize the trusted CA.

Read Part 1 here.