Background
The target of this couple of posts is to describe the PKI (Public Key Infrastructure) we built as well as the Digital Signature implementation using that PKI. Both areas are really important and huge considering the scope of the task and its importance regarding security and identity management. The first one (STS ID Manager) is in charge of managing the Digital Identity of the system users while the second one (STS E-Sign) uses components of those digital identities to apply Digital Signatures to documents.Terminology
If you are still not familiar with the terminology we'll use in these posts you'll find below a brief glossary with the main terms and most accepted meanings.Digital Identity. We like specially this definition in Techopedia because it remarks its versatility and multiplicity: A digital identity is an online or networked identity adopted or claimed in cyberspace by an individual, organization or electronic device. These users may also project more than one digital identity through multiple communities. This is our purpose too. To provide a secure, durable in time, digital representation of natural and legal persons as well as their links across different businesses and areas. This representation has legal value and therefore it has to be strongly resistant to attacks.
PKI. For our purposes a PKI is the whole system in charge of managing the set of certificates, keys, secrets and related information providing Digital Identification according to the system policies. It encompasses the terms described below.
Authentication & Authorization Server. It is essential to have mechanisms of data storage to store information about the users (principals), roles, groups, areas and detailed descriptions not only about people but also about the areas of the system these users can access, permissions, privileges, etc. Some examples are LDAP, Active Directory, etc.
CSR. Certificate Sign Request. It is one of the first steps towards creating a X509 Certificate. It is generated and managed from the IDR (IDentity Request). The CSR contains key validated identity information with no mistake. It also contains the public key that will be included in the certificate and is signed with the corresponding private key. Please find below the list of fields that will be included into the certificate's subject. Mandatory fields are marked with a star.
| Distinguished Name Field | Explanation | Example |
| Country Name * | The two-letter ISO abbreviation for the country. | US |
| State/Province Name * | The state or province where your organization is located. Can not be abbreviated. | Georgia |
| City or Locality * | The city where the person or organization is located. | Atlanta |
| Organization Name * | The exact legal name of the organization related to the owner of the certificate. Do not abbreviate. | GMC |
| Organizational Unit | Optional. For additional organizational information. | Marketing |
| Common Name * | The fully qualified name of the owner. We can include here additional information (PIIID, scope) to avoid duplicates | John Doe / johndoe@gmc.com |
| Email address * | PIIID email address | johndoe@gmc.com |
Certificate. The Certificate is, nominally, a container for the public key. It includes the public key, the server name, some extra information about the server, and a signature computed by a certification authority (CA). On the other hand, a .cert (or .cer or .crt) file usually contains a single certificate, alone and without any wrapping (no private key, no password protection, just the certificate). In SSL, when the server sends its Public Key to a client, it actually sends its certificate, eventually with a few other certificates (the certificate chain that is the certificate which contains the public key of the CA which signed its certificate, and the certificate for the CA which signed the CA's certificate, and so on). Certificates are intrinsically public objects.
Some systems use the term "Certificate" to designate both the Certificate and the Private Key; despite of this the STS ID Manager sticks to the strict definition for which the certificate is the signed container for the Public Key only. The exception is the PFX file as we'll see below.
The STS ID manager provides a CRT file containing a single certificate, alone and without any wrapping (no private key, no password protection, just the certificate).
The certificate chain is simple: Root CA, User issued certificate + Timestamp Authority certificate.
Digital Identity Store. It is a storage device that meets several key requirements: encrypted storage, restricted access based on keys, activity log storing ALL actions that affect to the components of digital identities.
Certification Authority. According to Wikipedia: In cryptography, a certificate authority or certification authority (CA) is an entity that issues digital certificates. We'll add the CA has to be recognized and able to verify the status and validity of issued certificates. Obviously, you cannot sign your own certificates because they cannot be validated by trusted 3rd parties. The company is the CA in the STS PKI.
Public/Private Keys. We have talked here about two main objects. Firstly we'll talk about the Private Key. It is stored in a really restricted way in the Cloud or server and it is protected with a secret/passphrase. It is used in HTTPS to receive new SSL connections. On the other hand, the Public Key is mathematically linked to the Private Key. It is sent to every client as part of the initial steps of the connection or secure operation.
Secret/Passphrase. The password linked to a Private Key to be able to decrypt content.
OCSP (Online Certificate Status Protocol). It is a protocol designed to provide information about the revocation status of a given certificate. A certificate can be revoked (cancelled) for many reasons. For instance, an issued certificate for a user will be revoked when the user is not a member of the system any longer. Once the certificate is revoked is not valid any more. OCSP is an alternative to CRL or Certificate Revocation Lists maintained by CAs.
The STS (Secure Transaction Service) Digital Identity Architecture
The STS is now a PKI with the company as the CA, issuing certificates that will be used by the platforms for several purposes. Besides, STS includes services of Digital Identity and Digital Signature. Both services rely on the STS PKI. The purposes of these services are:
- To provide Digital Identity to system users (mainly customers) across business units. Therefore, the Digital Identity is uniform and standard.
- To maintain the PKI according to security and maintenance policies.
- To provide Digital Signature features on documents handled or generated in the system according to eIDAS. (The next post will handle this area).
The main components in the architecture are:
- STS ID Manager. It manages the PKI.
- STS E-Sign. It is in charge of Digital Signatures, signing actions using the Digital Identities components provided by the ID Manager.
- STS OCSP Service. Externally accessible service to provide validation of certificates used in digitally signed documents.
STS ID Manager Technical Specifications
The user is not provided with the components of the DID. Instead, the actions that require any component of the user's DID manage the DID to carry out the operation. A clear use case is the digital signing of a document that is the primary purpose of the issued certificates.
The main advantages of this approach are:
- The user has not to store certificates and key in the local machine. This approach allows the system to be independent of a given device. The customer can perform operations using the DID using any device.
- The maintenance of the DID is provided by the STS ID Manger, notifying the customer about any needed action regarding the DID. For instance, when the certificate expires it requires a explicit action to renew the certificate or setting a new policy for automatic renewal.
- The actions involving the DID are programmatic. Therefore, they are faster and cheaper, reducing the general cost for the PKI.
The STS ID Manager is a Cloud Native component. Azure Key Vault, Azure Active Directory with MFA (Multi-Factor Authentication), Azure Blob Storage, Message Bus, etc are used by this component.
It is written in Go. This language (supported by Google) allows a straightforward integration with Cloud Providers and infrastructure. Most importantly, Go has extremely powerful features related to PKI development and OCSP.
Communications between components in the PKI is mainly gRPC on HTTP2.
How does it work?
The consumers of the API sends a request to create a new Digital Identity (DID) for a registered user. Not all registered users have a DID but eventually any registered user can request one. The requests happen in a previously authorized session and after a successful authentication.The provided DID is composed by a principal in AAD (Azure Active Directory), a X509 certificate in PEM format, its Private Key in PEM format, a secret/passphrase and a PFX file containing the certificate and the Private Key in PKCS#12 format. The STS ID Manager is completely Cloud Native and it uses several services to store and manage the DIDs in the most secure way.
For the sake of clarity we include here more details about the creation of the DIDs. It involves:
- The creation of a X509 certificate signed by the root CA issued to the requester as a natural person in relation to a specific purpose. This purpose is meant to the association to the Organizational Unit in the certificate's subject.
- The creation of a Private Key for that certificate in PEM format.
- The generation of a secret/passphrase for the Private Key in PEM format. This secret can be accessed ONLY by programmatic actions.
- The generation of a PFX file containing the Certificate and the Private Key.
What is the PEM Format?
Defined in RFCs 1421 through 1424, this is a container format that may include just the public certificate or include an entire certificate chain including Public Key, Private Key and even root certificates. It stands for Privacy Enhanced Mail, a failed method for secure email but the container format it used lives on, and is a base64 translation of the x509 ASN.1 keys.Why a PFX file?
The PFX file is a PKCS#12 archive, a container with a lot of objects with password protection. In the STS ID Manager the PKCS#12 archive contains the provided certificate and the corresponding Private Key. Of course this container can be opened only using a secret password. Besides and unlike the PEM files, it is encrypted and it does not need additional encryption.Certificate Hierarchy
The certificates issued by the STS ID Manager are directly signed by the root CA. So, the certificate chain is really simple and straightforward.It is important to remark that a Digital Identity is issued for each relationship user/company and specific roles that need the DID.
Input/Output Data
The ID Pack is the data structure that describes a DID. The diagram below explains pretty easily its parts.
The data structures involved in communications are the IDR (IDentity Request) and the IDRes (IDentity Response). Obviously, the IDR is sent to the STS ID Manager that will validate the request acting accordingly. If everything is in order, it will create/obtain/delete a DID. In any case, the ID Pack in the IDRes will contain the whole DID. Again, the DID is not provided to the user. The IDRs are sent by other restricted authorized components in the system to carry out programmatic operations.
Vulnerability Report
| Vulnerability | Exploitation | Remediation |
|---|---|---|
| Unauthorized access to the Digital Identity Store | Digital Identity components (certificates and keys) would be used for impersonation and faked usage. | All contents into the Digital Identity Store are encrypted with strong encryption. In the improbable case a user accesses to the storage devices the retrieved content is unusable. |
| A user with an access token or a valid API Key tries to get not authorized Digital Identities | A valid user can impersonate other users by getting their digital identities. | The ID Manager always acts in the context of an open user session. No action is taken from not identified valid users. Therefore, there is a strong correspondence between the active session holder and the Digital Identity. |
| A not registered user tries to obtain a Digital Identity | To carry out operations into the system with authorization and not traceability. | ALL actions in the STS ID Manager require previous authorization against the Azure Active Directory, checking out the principal, assigned roles and groups. No operation related to DID is possible without a recurrent checking against the AAD |
| A user obtains a not authorized access to the files composing the Digital Identity (Certificate + Private Key + PFX) and he decrypts the content. | In theory the user could impersonate other principals carrying out actions with a stolen identity. | Even in the improbable case a user could get all the files involved in a given DID and decrypt the files successfully he still had to get the password for the Private Key. The secret is managed in a completely different way in the Azure Key Vault and managed ONLY by role-based restricted programmatic actions. |
Issued Certificates Technical Specifications
- Standard for Public Key Certificates: X509
- File formats: PEM and PFX (PKCS)
- Key Type: RSA
- Encryption algorithm: 4096 bits
- Certificate Signature Algorithm: SHA512 with RSA
- Expiration Time: 1 year
- Main Purpose: Client Authorization, Key Usage Digital Signature
OCSP
Last but not the least, the OCSP (Online Certificate Status Protocol) Service is used to provide a way to external parties to validate the certificates issued by our PKI. Basically, by sending the certificate issued by the PKI the 3rd Party can find out about its status. The STS OCSP Service can be used by external parties to check out the validity of issued certificates.| Status | Explanation |
|---|---|
| Good | The issued certificate is valid and active. |
| Revoked | It means that the issued certificate has been deliberately revoked. |
| Unknown | The OCSP Service did not issue this certificate. |
| ServerFailed | The OCSP Service does not work well. |