The Forest → crypto

PKI

This is a forest note. It is still growing, so it will change.

Spawn Jul 28, 2026 · last tended Aug 2, 2026

java
cryptography
pki

When reproducing, using, or extracting this text, always reference the source and the author : Ignacio Rondini

These are my notes on Java-PKI-Cryptography notes.

Cryptography basics and concepts

Important concepts

Identification: The act of indicating a person or thing’s identity. “I am system x-123”
Authentication: The act of verifying an assertion. In this case, that the identity correspond to the person claiming it. “The system saying it’s system x-123 it’s indeed the system x-123”
Authorization : Is the verification of the privileges or right an authenticated user or system has. “System x-123 is authenticated, but it does not have admin rights.”
(Data) Integrity: Is the maintenance and assurance of data accuracy and consistency. “The message that was sent it was the one received, even through a hostile medium”.
(Data) Tampering: It’s when an attacker has modified the information, compromising its integrity and reliability.
Non-repudiation/Data origin authentication: It’s the feature that a message has integrity and that the origin of the data can be proved. “A sender cannot say that the message received it’s not what she sent”
Confidentiality: Assurance that no entity can maliciously or by accident, view a payload in clear text.

Cypher

A cypher is an algorithm for encoding (via an encryption function) and decoding (via a decryption function) messages. A message could be any text, but ultimately, it will be a collection of bytes. It works broadly as a function: CypherText = cypher (plainText)

They can be categorised by :

The base structure on what they act :
- Block ciphers that act on blocks of data
  - Such as AES
- Stream ciphers, that act on a stream or series of data.
  - Such as Salsa20 and Chacha
The keys they use
- Symmetric key, where the private key is used for both encrypting and decrypting.
  - Such as DES/AES
- Asymmetric key, where the private key is used for encrypting (or signing), and the public key for decrypting (or verifying a signature).
  - Such as RSA, EC
  - In many cases, most cases?, it’s possible to deduct the public key from the private key;

The keys used, which are in the end also a series of bytes, condition the (d)encryption protocol: The longer the key, more difficult it’s to break by brute force the schema, however, it takes more time to perform the operations.

Crypto Hash

A hash is a function that receives an input of any size and transform it into one of fixed size. For instance, the function First that receives any word and returns its first letter, complies with this definition. E.g., First (Hello) = H.

A cryptohash is a hash function that receives a message and generate a digest (or message digest) that should be quick to calculate, but hard to reverse (it’s a one way function), and thus should have the following properties :

Pre-image resistance: For every value of a digest d, it should be hard to find a message m such that d = hash (m). This is not the case for our First function, as for a given digest, say h, it’s easy to find any word such that h = First (word).
Second pre-image resistance: Given m1, it should be hard to find a m2 such that hash (m1) = hash (m2). Again, this is not the case with our First function as for a given word, we can always find other words that start with the sme letter such that they have the same hash.
Collision resistance. It should be hard to find m1 and m2 such that hash (m1) = hash (m2)

In this context, hard should mean that it’s not possible for a given adversary with enough computing power, to break the schema on a determined timelapse.

Known crypto hashes

MD5: Used as a checksum, but it suffers from collision attack and chosen-prefix attack.
SHA-1 same
SHA-2: 256, 521,…

One time pad

One notable encryption schema that can’t be cracked, where you only use once, a preshared key of equal lenght or longer than the message. The encryption and decryption is performed via a modular addition of the bytes: plain-text ⨁ pad = cypher-text

Keystores

A keystore is an archive or store that allows to manage private keys and certificates.

JKS

A legacy Java KeyStore with proprietary format.

PK12

A standard defining the format of the store. It can be encrypted and signed. It can store certificates, private keys, CRLs. The extension is .p12.

They can be created, parsed and read with OpenSSl pkcs12 command or other tools. It’s typically used to store a private key with it’s corresponding certificate chain.

HSM

Private keys can also be stored in HSM. For more information, look at the HSM section.

HSM

HSMs or Hardware security modules, are system that allow the storage of keys and the execution of some cryptographic functions. The act as a separate device from which private keys (or symmetric keys) should never leave. They may have tampering detection mechanism or even tampering deletion of keys.

Its main functions are :

Secure key generation (by using real random generators).
Secure key storage
Key management
Cryptographic functions (such as signatures or encryption/decryption)
Secure key deletion.

Key generation

The hsm perform secure key generation. They usually use true source of entropy, ie, they use real random generators based on physical noise, to convert this real randomness into a key. This is important because common random number generators are not really random, they are rather pseudo random, ie, they usually use a seed that determines the random suite to be generated. There could also be correlation that could be exploited.

Key ceremony

When performing actions with the most sensitive keys, for instance root keys of CAs, a ceremony, or strict protocol is defined. The protocol describe the actions and audit trail. The goal is to give the most security that the master key won’t get misused or exfiltrated from the hsm.

Key rotation

In order to avoid using a key for long time, and thus increasing the exposure risk to that key if ever get compromised, there’s a periodical replacement of keys. This can be a policy or mandated by standards like PCI-DSS.

The rotation can take place on a time interval, after some amount of usage or after some events There’s however, a need to keep operation runnings, so there should be some overlap. Ie, old signatures should still be able to get validated and encrypted data should still be able to be decrypted. For the first case, signature verification, the public key should still be available. For the second case, encryption, the key used to decrypt should be kep, and if it’s a symmetric, it should be set only to decrypt.

Key wrapping

A key is just a series of bytes. If you need to transfer it (to another hsm for instance), you cannot transfer it in plain text. So we encrypt it with another key (A wrapping key)

Split knowledge

Is the principle based on what not only one person is able to perform sensitive and critical operations, such as decrypting data. So no single person can compromise the system.

Dual control

Is a complementary principle, that it requires that two or more authorised person to perform jointly a task. Such a task could be decrypting data, rotating a or putting online a master key, generate keys etc.

KMIP

The Key Management Interoperability Protocol is a communication protocol that defines the format of message for the manipulation of cryptographic keys.

A KMIP server stores and controls the “managed objects”, such as keys and certificates.

It has overlap with PKCS#11, which is used to control an HSM.

PKI

Public Key Infrastructure, it’s a schema or arrangement that binds public keys with the identity of entities or persons. It’s a group of roles, policies, hardware, software and procedures that enable the creation, management, distribution, usage, storing and revocation of digital certificates, together with the management of public key crypto setups.

It allows secure data transfer between entities.

It’s composed of :

A certificate authority (CA) , which stores, issues and signs digital certificates.
A registration authority (RA), which verifies the identity of entities requesting the certificates.
A central directory, a secure location in which keys are stored and indexed.
A certificate management system, that manages the access to the certificates and their deliveries.
A certificate policy, which states the PKI’s procedures.

The validation authority (VA) helps determine whether the digital certificate is revoked, by publishing, CRL lists.

The schema of the PKI is :

It has as goal, being able to provide trust services, such that actors can have :

Confidentiality
Data integrity
Authenticity (Authentication of parties.)

Certificates

A certificate binds a public key to an identity. To avoid man in the middle attacks, they should be created by a trusted CA.

There are different methods to verify the identity, which is done by the RA. It could be manual process, like when asking for an identity card or password, or automatised, like when requesting a certificate for a website, where we generate a key pair , sign something and send the cypher text together with the public key so the RA can verify that we are the owner of the private key that correspond to the public key that will be linked into owr certificate.

Certificate content

So, what’s on a digital certificate? Well, the main format is X.509 and has a lot of fields. Among them, the mains are :

Subject name (who is this certificate for)
Subject public key info (the public key itself and the algorithm used)
The issuer name (the ca/subca or self-signed)
The validity period
- Not before
- Not after
Certificate signature algorithm
Certificate Signature (the signature made by the issuer)
Extensions
- Subject Alternative Name (SAN) such as :
  - Email address
  - IP Address
  - URI
  - DNS name
  - etc The full chain of trust can be built based on the issuer information found on the certificate.

Sub CA

Note that the root CA, is usually offline, to avoid having to use the private key of the root ca, so it can be kept in a safe place offline. So it’s usually a sub ca, or an intermediary ca whose own certificate (hence, its own identity) is certified by the CA. Said otherwise, the certificate of the Sub ca is signed with the key of the root CA. Thus, afterwards, users needing a certificate gets theirs emitted by the sub CA. Hence, their certificates is signed by the sub CA, whose certificate is signed by the root CA. This is what we call a certificate chain.

A certificate is valid if and only if all its certificate chain is valid. The certificate of the root ca is self-signed.

Man in the middle attack

A man in the middle attack happens when an adversary entity intercepts the communications between two parties. The adversary can thus impersonate the parties by giving its certificate and message instead of the original. Thus, the importance to have trusted CA that emits the certificates instead of using self-signed ones.

Say a user wants to go to the site www.trustedsite.test, if we allow self-signed certs, then an adversary can intercept the call, then give a self-signed certificate for that website (or a cert coming from a malicious CA) and return a fake version of the site.

Validation

First of all, to validate a certificate, we need to validate its full chain of trust, i.e., validate any intermediary CA and the root CA. It could be that one of the CA was compromised and the certificates revoked at some point. So it could be that a new certificate was created by a compromised sub CA. This is why it’s important to have the full chain certificate.

How do we validate them? There’s an RFC defining the protocol to validate a given path. Here are a few things that get validates :

The public key information and signatures.
Current date against the validity period of the certificate.
The revocation status.

Revocation

It is important to be able to revocate, means invalidate, a given certificate before it expires. If a CA has been compromised, for instance, because its private key was leaked. Then, we would like that every certificate signed by that key to be invalid. Thus, the importance of revoking the certificate. It could also be the case that the information on the certificate was erroneous.

There are two main methods.First of all CRL (certificate revocation lists),which is a list of certificates that have been revoked by a CA before their end of validity and thus, should not be trusted. CAs simple publish a list of the certificates. However, these list may:

Grow a lot in time or could be costly to check every time on the full list. (this is way CAa publish also delta CRLs)
There’s a gap time between the revocation of the certificate and the publication on the CRL.
If the server providing the CRL is down, the client should decide what to do (consider that there’s no revocation OR assume there’s a revocation)
If there’s a complete dependency to the crl, the pki system or the application depending on it could be subject to DoS attack

And example on the Flanders CRL .

A second way of validating is OCSP (Online certificate status protocol). A client wanting to validate a certificate will call the OCSP responder (server) to get the status ofa single certificate. A few notes :

OSCP carry less data than CRLs so the network usage is less
Client side libraries are easier to implement
It discloses that a given client/application used the certificate to the OCSP at a given time. For web browsing for instance, the browser would call an OCSP, disclosing that a given user/IP accessed a given url at a given time.
The responses are Good, Revoked or Unknown. Or a technical error.
There could be a reply attack if an adversary intercepts the response and re-use it afterwards.

There’s also the possibility to have an OCSP-Stapling. The actor presenting his certificate, it also sends the OCSP response signed by A CA (or trusted OCSP responder), so the validation is not needed to be performed at the authentication step.

HMAC (Hash message authentication code)

First of all, a MAC (message authentication code or authentication tag), is a piece of information, derivate from a message, to support integrity checking and authenticating the message. It’s based on a preshared private key, that’s both used for creating the MAC and verifying it. So anyone who is able to verify it, can also generate MACs.

For this reason, MACs have no non-repudiation property.

A HMAC is a MAC using a crypto hashing function (SHA, MD5 etc). It trades the usage of asymmetric algorithms and PKI infrastructure for a faster use of a preshared key. It’s up to the users to ensure the key is well managed.

Digital Signatures

A digital signature is not the same as an electronic signature, which is any data that’s used by the person signing to create the signature. For instance, an image of the signature, the name, etc. It typically has the same value as a handwritten signature (wet signature).

A digital signature is backed up by a cryptographic scheme and a PKI. Its aim is to verify the authenticity of a message, both in authorship and authorship of the signature. It thus implies non repudiation. In other words, a digital signature allows to verify that a message has been sent by an entity, and that the message received is equal to the one the entity signed. The most common is RSA.

The common function is

In real scenarios, the public key alone is not enough. A PKI is needed to enable trust, so a certificate should be sent.

The other way around, RSA (or asymmetric schemes) can be used to encrypt messages using the public key such that only the owner of the private key can decrypt it.

Note that what do we sign is a HASH (using SHA256 for instance) or message digest, and not the full original message. Based on that you could have ECDSA - SHA256, RSA PKCS1-SHA512

Different methods of encryption and signature schemes exist :

PKCS V1_5 (RSA) :
- Deterministic schema. The same message and key reproduce the same signature.
- Message digest extraction. It can be extracted from the signature.
- Complete: Having the public key, it can be possible to recover the message digest. The signature is made on (padding) || DigestInfo, the info has the algorithm and the hashed value. So it can just be extracted.
RSA_PSS (As an improvement of rsa) :
- Non-deterministic schema. It’s randomised and uses a salt, so unless there’s a zero length salt, signing the same message with the same key won’t give the same result.
- It has external parameters that need to be known.
- The message digest can’t be extracted. You can verify if a given digest correspond to the signature.
Elliptic-curves : ECDSA based on problems on elliptic curves (rsa is based on integer factorisation)

The main difference between EC and RSA are :

The “hard problem”, ie, the mathematical problem that backs the schema. (ie, it should be infeasible to retrieve the private key from the public key)
The signature size : EC are smaller
Signing speed: EC are faster
Verification speed: EC are slower
Key generation: EC are faster

SSL/TSL

SSL (secure sockets layers) is the predecessor of TSL (Transport layer security). They are protocols to secure network communication, notably through internet.

The schema allows to avoid eavesdropping (reading of messages between parties, even if the messages are being intercepted) and to avoid tampering.

It uses a client server model.

The private key generation can be either by encrypting a random number and using it to create a private key, or using the Diffie-Hellman key exchange (see next section)

TLS is more secure than SSLv3 in symmetric key generation.

Diffie-Hellman key exchange

It’s a protocol to securely generate a symmetric crypto key over a public channel. It goes like this:

They can now use the shared secret to create a symmetric key. This implies that the function F that’s used to compute has the property F (a,F (b,g,p),p) = F (b,F (a,g,p),p). In this case, we have that (g^a)^b = (g^b)^a mod p.

Formats

BASE64

It’s a binary to text encoding that uses 64 characters to represent 6-bit segments of a sequence of byte. It allows to send binary information through mediums than only support text.

PEM

The pem format is the most common file format for exchanging crypto keys and certificates. The value to be transmitted is encoded unsing BASE 64 and inserted between two tags. Which lead to the format

-----BEGIN <TYPE>-----
BASE 64 encoded value
-----END <TYPE>-----

Where the value can be, for instance, PRIVATE KEY or CERTIFICATE. The extension is typically .pem, .cer or .crt for certificates and .key for keys.

PKCS#7 CMS cryptographic message syntax

It’s a format defining the container or enveloppe used to store and exchange signed and/or encrypted data. It’s composed on a content, a certificate , a signature and a signer information, such as (a timestamp, the hash algorithm information, the signature itself etc)

PKCS standards

The public key cryptographic standards are a group of standards defining public keyinfrastructures. They are:

Standard	Description	Version
PKCS #1	RSA Cryptography standard. Defines the properties of RSA	2.2
PKCS #2	Withdrawn	No longer active
PKCS #3	Diffie-Hellman Key agreement standard.	1.4
PKCS #4	Withdrawn
PKCS #5	Password based encryption standard.	2.1
PKCS #6	Extended-Certificate Syntax Standard.	1.6
PKCS #7	CMS. Cryprographic message syntax Standard.	1.5
PKCS #8	Private-key information syntax standard.	2.0
PKCS #9	Select attribute type	2.0
PKCS #10	Certification request standard	1.7
PKCS #11	Cryptografic token interface (cryptoki). Interface for HSM.	3.2
PKCS #12	Personal Information exchange syntax standard. Format for keystores.	1.4
PKCS #13	Apparently abandonned
PKCS #14	Apparently abandonned
PKCS #15	Cryptographic Token information format standard. ???	1.1

PKI