Management of Asymmetric Key Pairs PDF

Management of Asymmetric key pairs SIO André Zúquete Problems to solve Ensure proper and correct use of asymmetric key pairs Privacy of private keys ꟷ To ensure confidentiality (when used for decryption) ꟷ To prevent the repudiation of digital sig...

Management of Asymmetric key pairs SIO André Zúquete Problems to solve Ensure proper and correct use of asymmetric key pairs Privacy of private keys ꟷ To ensure confidentiality (when used for decryption) ꟷ To prevent the repudiation of digital signatures (when used for signature issuing) Correct distribution of public keys ꟷ To ensure confidentiality (when used for encryption) ꟷ To ensure the correctness of digital signatures (when used for signature validation) João Paulo Barraca, André Zúquete SIO 2 Problems to solve Temporal evolution of (entity, key pair) mappings To tackle catastrophic occurrences ꟷ Loss of private keys To tackle normal exploitation requirements ꟷ Renewal of key pairs for reducing discovery risks ꟷ End of the bound between entity and key pair (e.g. professional relationship) João Paulo Barraca, André Zúquete SIO 3 Problems to solve Ensure a proper generation of key pairs Random generation of secret values ꟷ So that they cannot be easily predicted Increase efficiency without reducing security ꟷ Make security mechanisms more useful ꟷ Increase performance João Paulo Barraca, André Zúquete SIO 4 Goals Key pair generation ꟷ When and how should they be generated Handling of private keys ꟷ How do I use them, while maintaining them private Distribution of public keys ꟷ How are they correctly distributed worldwide Lifetime of key pairs ꟷ When will they expire ꟷ Until when should they be used ꟷ How can I check the obsolesce of a key pair João Paulo Barraca, André Zúquete SIO 5 Generation of key pairs: design principles Good random generators for producing secrets Result is indistinguishable from noise ꟷ All values have equal probability ꟷ No patterns resulting from the iteration number or previous values Example: Bernoulli ½ generator ꟷ Memoryless generator ꟷ P(b=1) = P(b=0) = ½ ꟷ Coin toss João Paulo Barraca, André Zúquete SIO 6 Generation of key pairs: design principles Large, complex passwords for protecting secrets When randomly-generated secrets are stored in password- protected readable repositories When secrets are deterministically computed from a password João Paulo Barraca, André Zúquete SIO 7 Generation of key pairs: design principles Facilitate without compromising security Efficient RSA public keys ꟷ Few 1 bits, typically 2k+1 prime values (3, 17, 65537) ꟷ Accelerates operations with public keys ꟷ Cost is proportional to the number of 1 bits ꟷ No security issues João Paulo Barraca, André Zúquete SIO 8 Generation of key pairs: design principles Self-generation of private keys Maximizes privacy as no other party ever knew the private key ꟷ Only the owner has the key ꟷ Even better: The owner doesn’t know the key, but may use the key Principle can be relaxed when not involving signature generation ꟷ Where there are no issues related with non-repudiation ꟷ In confidential communications it allows to maintain the readability of encrypted messages João Paulo Barraca, André Zúquete SIO 9 Handling of private keys Correctness The private key represents a subject ꟷ e.g., a citizen, a service ꟷ Its compromise must be minimized ꟷ Physically secure backup copies can exist in some cases The access path to the private key must be controlled ꟷ Access protection with password or PIN ꟷ Correctness of applications that get their value João Paulo Barraca, André Zúquete SIO 10 Handling of private keys Confinement Protection of the private key inside a (reduced) security domain (ex. cryptographic token) ꟷ The token generates key pairs ꟷ The token exports the public key but never the private key ꟷ The token internally decrypts/signs with the private key Example: SmartCards, FIDO2 tokens ꟷ We ask the SmartCard to decrypt/sign something ꟷ The private key never leaves the SmartCard João Paulo Barraca, André Zúquete SIO 11 Distribution of public keys Distribution to all senders of confidential data ꟷ Manual ꟷ Using a shared secret ꟷ Ad-hoc using digital certificates Distribution to all receivers of digital signatures ꟷ Manual ꟷ Ad-hoc using digital certificates João Paulo Barraca, André Zúquete SIO 12 Distribution of public keys Certification concept Transitive trust ꟷ If A trusts KX+, and B trusts A, then B trusts KX+ ꟷ Trust paths / graphs Certification hierarchies / graphs ꟷ With the trust relations expressed between entities ꟷ Certification is unidirectional! João Paulo Barraca, André Zúquete SIO 13 Public key (digital) certificates Digital Document issued by a Certification Authority (CA) Binds a public key to an entity ꟷ Person, server or service Are public documents ꟷ Do not contain private information, only public one ꟷ Can have additional binding information (URL, Name, email, etc.) Are cryptographically secure ꟷ Digitally signed by the issuer, cannot be changed João Paulo Barraca, André Zúquete SIO 14 Public key (digital) certificates Can be used to distribute public keys in a trustworthy way A certificate receiver must validate it in many ways ꟷ With the CA’s public key ꟷ Can also validate the identification ꟷ Validate the validity ꟷ Validate if the corresponding key pair is being properly used A certificate receiver trusts the behavior of the CA ꟷ Therefore, will trust the documents they sign ꟷ When a CA associates a certificate to Alice If the receiver trusts the CA Then it will trust that the public key in the certificate belongs to Alice João Paulo Barraca, André Zúquete SIO 15 Public key (digital) certificates X.509v3 standard Binary formats ꟷ Mandatory fields ꟷ ASN.1 (Abstract Syntax Notation) Version DER, CER, BER, etc. Subject ꟷ PKCS #7 Public key Cryptographic Message Syntax Standard Dates (issuing, deadline) ꟷ PKCS #12 Issuer Personal Information Exchange Syntax Standard Signature etc. Textual encodings ꟷ Extensions ꟷ PEM (Privacy Enhanced Mail) Critical or non-critical ꟷ base64 encoding of X.509 PKCS #6 ꟷ Extended-Certificate Syntax Standard João Paulo Barraca, André Zúquete SIO 16 Key pair usage The public certificate binds the key pair to a usage profile ꟷ Private keys are seldom multi-purpose Typical usage profiles ꟷ Authentication / key distribution Digital signature, Key encipherment, Data encipherment, Key agreement ꟷ Document signing Digital signature, Non-repudiation ꟷ Certificate issuing (exclusively for CAs) Certificate signing, CRL signing ꟷ Timestamping (exclusively for TSAs) Public key certificates have an extension for this ꟷ Key usage (critical) João Paulo Barraca, André Zúquete SIO 17 Certification Authorities (CA) Organizations that manage public key certificates ꟷ Companies, not for profit organizations or governmental ꟷ Have the task of validating the relation between key and identity Define policies and mechanisms for: ꟷ Issuing certificates ꟷ Revoking certificates ꟷ Distributing certificates ꟷ Issuing and distributing the corresponding private keys Manage certificate revocation lists ꟷ Lists of revoked certificates ꟷ Programmatic interfaces to verify the current state of a certificate João Paulo Barraca, André Zúquete SIO 18 Trusted Certification Authorities Intermediate CAs: CAs certified by other trusted CAs ꟷ Using a certificate Transitive trust ꟷ Enable the creation of certification hierarchies on public key Trusts public key Trusted anchor (or certification root) Root CA CA 1 ꟷ One that has a trusted public key Issues certificate ꟷ Usually implemented by self-certified certificates Issuer = Subject Intermediate CA CA 2 ꟷ Manual distribution Issues certificate e.g., within browsers code (Firefox, Chrome, etc.), OS End-user certificate (person, institution, service, etc.) João Paulo Barraca, André Zúquete SIO 19  End-entity certificate (host) (certificate issued by a CA) João Paulo Barraca, André Zúquete SIO 20  Intermediate CA Root CA (CA certificate issued (Certificate is self- by another CA) signed) João Paulo Barraca / André Zúquete SIO 21 Refreshing of asymmetric key pairs Key pairs should have a limited lifetime ꟷ Because private keys can be lost or discovered ꟷ To implement a regular update policy Problem ꟷ Certificates can be freely copied and distributed ꟷ The universe of holders of certificates is unknown Therefore, we cannot contact them to eliminate specific certificates Solutions ꟷ Certificates with a validity period (not before, not after) ꟷ Voluntary use of certificate revocation lists To revoke certificates before expiring their validity João Paulo Barraca / André Zúquete SIO 22 Certificate revocation lists (CRL) Base or delta ꟷ Complete / differences Signed lists of certificates (identifiers) prematurely invalidated ꟷ Must be regularly consulted by certificate receivers ꟷ OCSP protocol for single certificate validation RFC 5280 RFC 6960 unspecified (0) keyCompromise (1) ꟷ Can tell the revocation reason CACompromise (2) affiliationChanged (3) superseded (4) Publication and distribution of CRLs cessationOfOperation (5) certificateHold (6) ꟷ Each CA keeps its CRL and allows public access to it removeFromCRL (8) privilegeWithdrawn (9) AACompromise (10) João Paulo Barraca, André Zúquete SIO 23 Base CRL and Delta CRL João Paulo Barraca, André Zúquete SIO 24 Online Certificate Status Protocol HTTP-based protocol to assert certificate status ꟷ Request includes the certificate serial number ꟷ Response states if the certificate is revoked Response is signed by the CA and has a validity ꟷ One check per certificate Requires lower bandwidth to clients ꟷ One check per certificate instead of a bulk download of the CRL Involves higher computational overhead to CAs ꟷ One check per certificate ꟷ Privacy issues as the CA will know that a certificate is being used João Paulo Barraca, André Zúquete SIO 25 OCSP stapling Add a recent OCSP response to certificate sent by a server ꟷ Reduces verification delay and load on CA ꟷ Avoids privacy issues Very useful in some specific scenarios ꟷ e.g. Wi-Fi network authentication João Paulo Barraca, André Zúquete SIO 26 Distribution of public key certificates Transparent (integrated with systems or applications) ꟷ Directory systems Large scale (ex. X.500 through LDAP) Organizational (ex. Windows 2000 Active Directory (AD), Manually (UA IDP)) ꟷ On-line: within protocols using certificates for peer authentication eg. secure communication protocols (TLS, IPSec, etc.) eg. digital signatures within MIME mail messages or within documents Explicit (voluntarily triggered by users) ꟷ User request to a service for getting a required certificate ꟷ eg. request sent by e-mail ꟷ eg. access to a personal HTTP page João Paulo Barraca, André Zúquete SIO 27 PKI (Public Key Infrastructure) (1/2) Infrastructure for enabling a proper use of asymmetric keys and public key certificates Creation of asymmetric key pairs for each enrolled entity ꟷ Enrolment policies ꟷ Key pair generation policies Creation and distribution of public key certificates ꟷ Enrolment policies ꟷ Definition of certificate attributes João Paulo Barraca, André Zúquete SIO 28 PKI (Public Key Infrastructure) (2/2) Definition and use of certification chains (or paths) ꟷ Insertion in a certification hierarchy ꟷ Certification of other CAs Update, publication and consultation of CRLs ꟷ Policies for revoking certificates ꟷ CRL issuing policies and distribution services ꟷ OCSP services Use of data structures and protocols enabling inter-operation among components / services / people João Paulo Barraca, André Zúquete SIO 29 PKI Example: Portuguese Citizen Card Enrollment ꟷ In loco, personal enrolment Certification path Multiple key pairs per person ꟷ Uses a well-known, widely distributed root certificate ꟷ One for authentication Self-Certified PT root CA ꟷ One for signing data ꟷ CC root CA below PT root CA ꟷ Both generated inside smartcard, not exportable ꟷ CC Authentication CA and CC signature CA below CC root CA ꟷ Both require a PIN to be used in each operation CRLs Certificate usage (authorized) ꟷ Signature certificate revoked by default ꟷ Authentication Revocation is removed if the CC owner explicitly requires the SSL Client Certificate, Email (Netscape cert. type) usage of CC digital signatures Signing, Key Agreement (key usage) ꟷ All certificates are revoked upon a owner request ꟷ Signature Requires a revocation PIN Email (Netscape cert. type) ꟷ CRL distribution points explicitly mentioned in each Non-repudiation (key usage) certificate João Paulo Barraca, André Zúquete SIO 30 Certificate Pinning If attacker has access to a trusted Root, it can impersonate every entity ꟷ Manipulate a trusted CA into issuing certificate (unlikely) ꟷ Inject custom CA certificates in the victim's database (likely) Certificate Pinning: add the fingerprint of the PubK to the source code ꟷ Fingerprint is a hash (e.g. SHA256) Validation process: ꟷ Certificate must be valid according to local rules ꟷ Certificate must have a public they with the given fingerprint João Paulo Barraca, André Zúquete SIO 31 Certification Transparency (RFC 9162) Problems ꟷ CAs can be compromised (e.g., DigiNotar) By attackers By governments, etc. ꟷ Compromise is difficult to detect Result in the change of assumptions associated to the behavior of the CA Owner will selfdom know Definition: a global system records all public certificates created ꟷ Ensure that only a single certificate has the correct roots ꟷ Stores the entire certification chain of each certificate ꟷ Presents this information for auditing Organizations or ad-hoc by the end users João Paulo Barraca, André Zúquete SIO 32