PKI Training - Day3 - Advanced Cryptography 2
Q: Name the extensions in the Certificate. Ans: AIA: CDP: CRL Distribution Point
Public Key Cryptography standards (PKCS)
PKCS# 1: Raw Signature standard. This is then used with PKCS# 7 to make it meaningful.
PKCS# 7: Cryptographic Message Syntax Standard Standard describes general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. Also known as CMS - Cryptographic Message Syntax (RFC 5652).
Steps of Signature Creation:
- Hash the Message
- Sign the Message
- Append the Signed Hash with Message
- Send the Message + Hash
- Timestamp (optional)
Steps of Verification:
- Split the Received data into Message + Hashing
- Create a hash on the received Message
- Compare the received hash and calculated hash
Additional things required for verification:
- Location of (Signed) Message Hash
- Use of algorithm for signing & Hashing
- Certificate of the signatory
PKCS# 10: Certificate Request Standard: Creation of Certificate Signing Request is created in compliance of this Standard. The created file is in .csr format. Important things in the CSR includes, Public Key of the requestee and information of the subject. Note: For subject sending the CSR, it is necessary to sign the information in CSR request to sign using its private key, to ensure the ownership of the private key.
PKCS# 11: Cryptoki: A standard to define platform independent API for communication with the HSM.
It is recommended, to not store secret data (private asymmetric key or secret(symmetric) keys) in software, but store in a secure hardware known as Hardware Security Module (HSM). The HSMs contain For personal use, USB tokens or Smartcards are available. The storage in smart cards can contain upto 16kb and a certificate averages at about 1kb. There are two user modes in HSMs:
- Admin
- User
- PKCS# 12 Personal Information Exchange Syntax standard It is recommended for user to generate the private key. But there exists a possibility to acquire an already generated key pair from another entity. In such cases, .p12 or .pfx file is used along with password to securely contain private key.
Common Filename extensions:
- .pem
- .cer, .crt, .der:
- .p7b, .p7c: For signed/encrypted email.
- .p12: may contain certificates or private keys.
- .pfx:
- .crl:
Certificate Revocation List (CRL):
In cases, where a certificate is invalidated before its endlife, such certificates are included in the Certificate Revocation List (CRL). Revocation is performed by the Certificate Serial No. instead of its public keys.
CRL Publishing:
The Revocation Status of all certificates are published via CRL that is shared as following:
- LDAP (Lightweight Directory Access Protocol)
- HTTP
All certificates have their expiry date included in its fields. CRLs only contain the certificates which aren’t expired yet and only revoked. All those certificates that have expired are excluded from the CRL. RFC 5280 suggests the certificates, Certificate Authorities and Certificates
Large CRLs:
The CRLs can grow quite huge (upto multiple MBs) and has issues to transfer and process such huge files. Following techniques are used as its solutions:
- Delta CRL: Main CRL is published periodically (i.e. Monthly or Quarterly) and the incremental CRL is made available at a shorter frequency (i.e. Weekly). Consumer can cache the main CRLs and incremental CRLs can be fetched at requirement to process/check the certificate from CRL.
Online Certificate Status Protocol (OCSP)
RFC 6960 A lightweight alternative is used in the place of CRL downloading. In this scenario, an OCSP Server is deployed to shift the processing of CRL from customer side to the server side.
OCSP responder respond all requests with its own Signature using HSM for hashing and Signing. Usual Transaction Rate: around 2000 transactions per second
In such situations, an attack can reach till its OCSP gateway because usually WAF can’t support ASN1 encoding. Therefore, an OCSP gateway is deployed to protect the internal zone.
Possible Responses of OCSP Server:
- Good
- Revoked
- Unknown
Trusted Communications (TLS/SSL)
Secure a Server/Client communication, SSL is enabled, provide a certificate (with private key), either by importing a .pfx file (including a key & certificate) or generate a key pair locally. A CSR is generated in the second case, for signing from the Certificate Authority. CSR contains the domain and information of the subject. CA has the responsibility to identify and vet the domain and other provided information. A certificate is generated by the CA and shared back to the subject. Life of a SSL certificate is 389 days.
Communication States
- At the first message between Client & Server is a Client Hello message, which includes (SSL version, list of algorithms for both session key and asymmetric encryption, compression algorithms).
- In response Server hello message is sent by the server (including the chosen most safe algorithm, compression, certificate of server).
Hand shake completed.
- Following checks are performed at the Client end:
- Check of Trust on Certificate and issuing CA
- Check of Expiry is performed
- Check of Domain & Certificate link
- Check for Revocation of the Certificate (optional)
- Generate a symmetric key, encrypt at client’s end by Public Key contained in Server’s received certificate
SSL (initiated by Mozilla) 3.0 is TLS 1.0 (maintained by independent consortium) and Following are the steps:
Time Stamping Protocol
For trusting the transactions, it is essential to assure a valid time stamp in all its transactions. A dedicated time appliance is used in the Public Key Infrastructure to ensure security of correct time in all transactions of CA. Therefore, a Time Stamping Authority (TSA) Server is deployed for providing standard time. A TSA server has a deployed NTP Appliance (with a reference time from GPS via a Physical GPS antenna) in Hardware to provide an accurate time. Additionally, an HSM is used to sign the Timestamp responses using TSA’s private keys.
Time Stamping Protocol Request
It Contains
- version
- Message Imprint
- Hash Algorithm
- Hashed Message
- TSA Policy ID
- Nonce
- Cert Request
- Extensions
Time Stamping Responses
- PKI Status Info: *
Standard RFC3161
Electronic Signature vs. Digital SignatureS
Electronic Signature:
These are non-PKI based signatures, have a legal standing and usually needs additional proofs for verification.
Q: Can both types of signatures be used together? A: Yes, usually a visible symbol also appears in the document showing that it has been signed. However, the value is of Cryptographically signed document.
PKCS#7 CMS (Cryptographic Message Syntax) and CAdES (CMS Advanced Electronic Signature) Signatures
Long term validation: Long time after signing, after the time of expiry of certificate, there is a need to keep the signature verifiable. For this purpose, usually
Levels of CAdES:
- Basic Electronic Signature
- CAdES-B: Extends XAdES-BES to conform to the identified signature policy
- CAdES-T:
- CAdES-C:
- CAdES-A:
For XML documents XCAdES Signatures
for PDF documents PAdES Signatures
- PAdES Part 2
- PAdES Part 3
- PAdES Part 4 (Archival)
Key Management
- Key Generation
- Key Exchange
- Key Storage/Escrow
- Key Usage
- Key Replacement
Concept of M of N
CA keys in HSM are stored by having its control with multiple users instead of a single user to avoid single point of compromise.
Q: What happens if none of the N people are available to perform the activity? A: Governance board may decide to allocate new people for the same roles. Data for the unlocking/activating of the systems are available within the premises.
end