Public and Private Keys
Utilize symmetric cryptographic keys for encrypting and decrypting data. Use signing keys to digitally sign messages and verify the signatures of other entities.
Raidiam Connect's Public Key Infrastructure enables organizations participating in a trusted environment to obtain and utilize cryptographic key pairs in the form of a JSON Web Key Set (JWKS). Such keys can be used for data encryption/decryption or digital message signing.
Public keys, used for encryption or signature verification, are shared openly. They are represented as mathematical values, typically in binary format. However, when expressed in human-readable form, they appear as a complex sequence of characters, resembling a lengthy string of numbers and letters, serving as a lock that can be publicly distributed without compromising security. The main type of key used by the Trust Framework is the RSA Key (RFC 8017).
Private keys are bound to Public Keys and enable the decryption/encryption of data or the creation of digital signatures. Its format is similar to that of the Public Key - RSA Private Key Format. Organization's private keys must be kept secret at all times.
In Connect's PKI, key pairs are not one-size-fits-all; they are tailored for specific functions such as encryption and signing.
In digital signing, the private key is used to create a signature on a document or message, while the public key verifies that the signature is valid. This ensures the integrity of the message and the confirmation of the identity of the sender.
These key pairs are used for encrypting and decrypting data. The public key encrypts data that only the corresponding private key can decrypt, ensuring that sensitive information remains confidential during transmission.
Key usage can be divided into three levels:
- Server-Client communication with mTLS Certificates Even though certificates are not keys per se, they contain the subject's public key and are signed with Certificate Authoritie's private key. Having the subject's public key within a certificate is crucial for asymmetric encryption or digital signatures, enabling clients to encrypt messages that only the server can decrypt or verify messages signed by the server. Certificates are authenticated through a digital signature by a Certificate Authority (CA). This signature is created using the CA's private key. When a server presents its certificate to a client, the client uses the CA's public key (which the client trusts) to verify the certificate's authenticity. This process ensures the certificate indeed belongs to the server and hasn't been tampered with.
- Signed messages between applications. Applications seeking access to resources from Data Providers can utilize signing keys to digitally sign their messages, thereby, enabling validation of their identity as well as granting non-repudiation. Signatures are often done by signing the JSON payload using the private key in possession of the Data Receiver, creating a JWT (RFC 7519). Since the signature can be verified only with the public key registered for an application, signing messages ensures that if any part of the message is altered after the message was signed, the signature is no longer valid. Additionally, the signature verifies whether the message was signed by a known and trusted sender who possesses the corresponding private key. Once a message is signed, the sender cannot deny sending the message or its contents as the message could only have been signed by the Private Key, which is possessed only by the sender. This property is crucial in scenarios where proof of message origin is necessary, also defined as non-repudiation.
- Encrypted messages. Applications or Servers seeking to exchange data on unsecured channels, like the browser, can encrypt their requests (or parts of it) to ensure confidentiality and integrity of the transmitted data. In this process the Party that will send the message will use the other party's public key to encrypt the JSON object, generating a JWE (RFC 7516), which technically can only be converted back into a JSON with the receiving party's Private Key. Encryption ensures that the data contained in the request can only be read by the intended recipient. Even if an attacker intercepts the encrypted data, without the corresponding public (decryption) key, the data remains unintelligible and useless. Additionally, any unauthorized modifications to the encrypted data would fail to decrypt, alerting the recipient to potential tampering.
A JSON Web Key (JWKS) is a JSON object for transmitting and validating cryptographic keys, particularly public keys, in web-based applications. It contains an array of JSON Web Keys (JWK), each representing a cryptographic key which usually includes: Key type (kty) , Usage (use) : The usage, which can be signature (sig) or Encryption (enc), Digital Signaure Algorithm (alg), Unique identifier (kid) and the public key attributes, which for RSA type keys are the exponent (e) and the modulus (n).
Key | Description |
|---|---|
kty | Key Type - Specifies the cryptographic algorithm family used for the key (e.g., RSA, EC). |
use | Public Key Use - Indicates the intended use of the key, such as sig for signature or enc for encryption. |
kid | Key ID - A unique identifier for the key, used to match a specific key to a JWT. |
alg | Algorithm - Identifies the algorithm intended for use with the key, such as RS256 for RSA signature with SHA-256. |
n | Public Key Modulus - Only used for RSA keys, it represents the modulus value. |
e | Public Key Exponent - Only used for RSA keys, it represents the exponent value. |
x | X Coordinate - Only used for EC keys, it represents the x-coordinate on the elliptic curve. |
y | Y Coordinate - Only used for EC keys, it represents the y-coordinate on the elliptic curve. |
crv | Curve - Only used for EC keys, it specifies the elliptic curve type. |
JWKS are utilized, for example, by OAuth authorization servers and client applications for transferring in a standardized way the client application's credentials. When a client application registers with an authorization server, it can submit its public keys, or a reference that points to those keys, in the form of JWKS.
This setup is particularly relevant in the OAuth private_key_jwt client authentication method. Here, the client application sends a JWT, signed with its private key, to authenticate itself to the authorization server. The authorization server then uses the corresponding public key from the JWKS, provided at registration, to verify the token's authenticity. This process ensures that the communication between the client and the server is both secure and verifiable.
- The client application is registered at the authorization server with it's public key.
- The client application generates a JSON Web Token (JWT) header and payload and base64URL encode them.
- The payload and header are concatenated together in the encodedHeader.encodedPayload format to form an assertion.
- The assertion is signed using a cryptographic algorithm that takes the input data (assertion) and the client's private key to produce a signature.
- The signature is base64URL encoded.
- The result is concatenated to from the JWT using the encodedHeader.encodedPayload.encodedSignature format.
- The client application passes the JWT to the authorization server for client authentication, for example, while calling the authorization server's /token endpoint. The JWT is passed as the value of the client_assertion request body parameter. The request must contain the client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer parameter.
- The authorization server decrypts the received JWT using client application's public key to verify the assertion.
Below, you can see examples of each object used to create a JWT.
Below, you can find a working example of a JWT you would receive as a result along with both keys in X.509 PEM format for simplicity. You can use the below resources at sites like, for example, jwt.io to test it. Once you paste the sample JWT, public key, and private key, you will receive the message that your signature was successfully verified.