Management of Asymmetric Key Pairs

Management of Asymmetric Key Pairs

• Asymmetric key pairs are used for encryption and digital signatures.
• Ensuring privacy of private keys is crucial for confidentiality and preventing repudiation.
• Correct public key distribution is necessary for confidentiality and validation of digital signatures.
• Temporal evolution of entity-key pair mappings necessitates handling catastrophic occurrences (like lost private keys) and normal exploitation (managing renewal and relationship termination).
• Proper key pair generation involves random secret values to prevent predictability.
• Efficient RSA public keys, with few 1 bits, accelerate operations without compromising security.
• Self-generated private keys maximize privacy.
• The private key represents a subject (e.g., citizen, service) and its compromise must be minimized, while physically secure backup copies can exist.
• Access to the private key must be controlled (e.g., password, PIN).
• Protecting the private key in a confined domain is essential.
• SmartCards and FIDO2 tokens keep the private key within the device.

Goals

• Key pair generation: understanding when and how to generate them.
• Handling private keys: safe use and maintenance.
• Public key distribution worldwide: correctness and distribution details.
• Key pair lifetime: expiry and obsolescence check procedures.

Generation of Key Pairs: Design Principles

• Random secret values are crucial for preventing predictability.
• The result of generation should be indistinguishable from noise, with all values having equal probability and no patterns linked to iteration or previous values.
• Bernoulli ½ generator is an example of a memoryless generator, where P(b=1) = P(b=0) = ½.
• Large, complex passwords protect randomly-generated secrets stored in password-protected repositories.
• Secrets can be deterministically computed from a password.
• Efficient RSA public keys, with few 1 bits, accelerate operations, and cost is proportional to the number of 1 bits without issues.

Self-generation of Private Keys

• Ensures that no other party knows the private key.
• Ideal scenario: the owner doesn't know the key yet can use it and the system maintains readability of encrypted messages.
• Flexibility: the principle can be adapted for scenarios without concerns about signature generation, where non-repudiation issues don't arise.

Handling of Private Keys: Correctness

• The private key represents a subject (e.g., a citizen, or service).
• Minimizing compromise is vital.
• Physically secure backups can be considered in some cases.
• Access path control measures (e.g., passwords, PINs) prevent unauthorized access.
• Applications that use the private key need validation.

Handling of Private Keys: Confinement

• Protection inside a secure domain (e.g., cryptographic token) ensures the integrity of the private key.
• The token generates key pairs, but only exports the public key.
• The token handles decryption and signing with the private key, preventing any exposure of the private key outside the token.
• SmartCards and FIDO2 tokens are examples of this.

Distribution of Public Keys

• Manual distribution methods can be used to distribute public keys.
• Shared secrets can be used for distribution.
• Ad-hoc methods with digital certificates can be used for distribution.
• The concept of transitive trust is related to the distribution.
• Certification hierarchies/graphs represent trust relationships between entities for public key distribution, where the relationship is unidirectional.

Public Key (Digital) Certificates

• Digital documents issued by Certification Authorities.
• Bind public keys to entities (people, servers, or services).
• Are publicly available documents, not containing private information.
• Can include additional binding info (e.g., URL, name, email).
• Cryptographically secured with a digital signature by the issuer.
• Certificate receivers validate the certificate with the CA's public key, identity, and validity date.
• Trusting the CA's behavior is implied, where they trust the documents signed by the CA when validating a certificate from a known individual, like Alice.
• X.509v3 standard defines mandatory fields (like version, subject, public key, issuer, signature, etc.).
• Binary formats (ASN.1, DER, CER, BER) and textual encodings (PEM) have different forms of implementing X.509 structure.

Key Pair Usage

• Public certificates bind key pairs to usage profiles so that private keys are not used for any purposes, other than what they are designated for.
• Common usage profiles include authentication, key distribution, digital signing, document signing, certificate issuance, certificate signing, certificate revocation list (CRL) signing and timestamping.
• Public keys have an extension for these profiles.

Certification Authorities (CA)

• Manage public key certificates for organizations.
• Validate relationships between keys and identities.
• Define policies for issuing, revoking, and distributing certificates.
• Manage certificate revocation lists.
• Provide programmatic interfaces to check the status of certificates.

Trusted Certification Authorities

• Intermediate CAs are certified by other trusted CAs, enabling the creation of certification hierarchies.
• Trusted anchors (root CAs) are self-certified.
• Manual distribution methods, such as within browser configurations on operating systems, are used for trusted root certificates.

Online Certificate Status Protocol (OCSP)

• An HTTP-based protocol for checking certificate revocation status.
• Requests are sent with the certificate serial number, and responses indicate whether the certificate is revoked.
• The OCSP response can be stapled by the server into its certificate, removing the need to check on a separate server.

Transparent Certificate Distribution

• For large-scale systems like directory systems or network protocols, digital signatures are part of the system, and automatically distributed.
• End-users might explicitly request certificates through e-mail or other services.

PKI (Public Key Infrastructure)

• Infrastructure for enabling the use of asymmetric keys and public key certificates.
• Creates asymmetric key pairs for enrolled entities and establishes enrolment and key generation policies.
• Manages the creation and distribution of public key certificates, along with enrolment policies and attributes.
• Defines and uses certification chains, handles CRL updates, and uses protocols for interoperability across components/services/people.

PKI Example: Portuguese Citizen Card

• A real-world example using PKI for personal identification and transaction security.
• Processes for enrollment, authentication, multiple key pairs (one for authentication and signing data), and certificate usage (e.g., SSL Client, email, signing, and non-repudiation) are described.
• Specific components like certificate paths and revocation lists are detailed, alongside the use of the revocation PIN.

Certificate Pinning

• A security measure where the fingerprint of the public key is added to the source code to prevent impersonation by attacker.
• The fingerprint validates the Certificate's public key.

Certification Transparency

• Addresses situations where CAs may be compromised (e.g., DigiNotar).
• Global systems record all created public certificates to ensure correct chains and provide auditing capability and ad-hoc access to certificates by end-users.

This quiz explores the essential aspects of managing asymmetric key pairs used in encryption and digital signatures. It covers key privacy, public key distribution, and the significance of proper key generation to ensure confidentiality and security. Test your knowledge on handling key pair mappings and safeguarding private keys effectively.