The Forest → crypto

PKI and Java

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

Spawn · last tended

  • 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 veryfing 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 sytem has. “System x-123 is authenticated, but it does not has 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 :

  1. 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).
  2. 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.
  3. Collission resistence. It should be hrd 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 timelaps.

Known crypto hashes

  • MD5: Used as a checksum, but it suffer 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 propietary 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

Key generation, key ceremonies, key rotation, key wrapping, KMIP, dual control and split knowledge

Emulators

SOFTHSM2

SSL/TSL

RSA ECDS

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 revokation of digital certificates, together with the management of public key crypto setups.

It allows secure data transfer between entities.

It’s composend of :

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

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

The schema of the PKI is :

SystemVACARAUserSystemVACARAUserI would like to have a digital certificate. Here is my proof of identity.The user is authenticated. Please provide a certificate.The certificate chain is valid.Here's my certificate to authenticate me.Is this certificate valid (CRL, OCSP)yes/no

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 a identity card or password, or automatized, 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 afte
  • Certificate signature algorithm
  • Certificate Signature (the signature made by the issuer)
  • Extensions
    • Subject Alterntive Name (SAN) such as :
      • Email address
      • IP Adresss
      • 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,it’s 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

Validation

CRL and OCSP

PKCS#1 RSA algorithms and padding PKCS#7 CMS | Signed enveloppe PKCS#8 private key encoding PKCS#10 Certificate signing request PKCS#11 Cryptographic token / HSM Api PKCS#12 Keystore bundle

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 asymetric 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.

Signatures

pkcs1 vs pss

CMS

Certificates

X509, CA, SUB CA, PEM

Certificate generation

Certificate validation

CRL, OCSP, OSCP stapling

Post quantum

JCA

Standards

EIDAS

References

Reply by email