Certificates Flashcards
Hybrid Certificate Eigenschaften
- Binding between identity and two independent public keys (primary and secondary)
- Binding certified with two signatures (primary and secondary)
- Usage of two independent signature schemes in parallel (secure as long at least one of the used schemes is secure)
Building hybrid certificates: approaches
- Concatenation
- Certificate Encapsulation
- Key-Signature encapsulation
Backwards compatibility
- During transition phase, hybrid certificates should still work if:
-> The (legacy) server does not understand hybrid
-> The (legacy) client does not understand hybrid
-> Both entities do not understand hybrid
–> Hybrid certificates should then appear as common X.509 certificates
Building hybrid certificates: approach: concatenation
- Public key: concatenation of primary and secondary key
- Signature: concatenation of a primary and secondary signature (verifiable with CA’s primary and secondary keys)
- Algorithm OID: identifies both signature schemes
Building hybrid certificates: approach: concatenation: advantages
- minimal (data) overhead
- easy to implement
- no downgrade attacks
Building hybrid certificates: approach: concatenation: disadvantages
- new OIDs for combined signature schemes required (treated as one signature algorithm)
- No backwards compatibility, “new” signature algorithm must be known to clients
Building hybrid certificates: approach: certificate encapsulation
- Standard X.509 certificate
- One additional, non-critical extension -> hybridCert extension (contains a complete X.509 certificate)
- Identical contents as hybrid certificate except:
-> Public key replaced by secondary subject public key
-> Signed with a secondary signature scheme and key by the issuer
-> Inner certificate has no hybridCert extension
Building hybrid certificates: approach: certificate encapsulation: advantages
- Easy implementation
- Backwards compatibility
Building hybrid certificates: approach: certificate encapsulation: disadvantages
- Redundant information (issuer, subject, validity period)
-> data overhead
-> consistency check required - Potential downgrade attacks to be considered during validation
Building hybrid certificates: approach: Key-signature encapsulation
- Standard X.509 certificate
- Two additional, non-critical extensions
-> hybridKey extension contains the secondary public key
-> hybridSig extension contains the secondary signature
Building hybrid certificates: approach: Key-signature encapsulation: advantages
- No redundant information -> minimal data overhead
- Backwards compatibility
Building hybrid certificates: approach: Key-signature encapsulation: disadvantages
- more complex implementation
- potential downgrade attacks to be considered during validation
Building hybrid certificates: approach: Key-signature encapsulation: hybridKey extension
- properties:
-> extension OID
-> criticality: non critical
-> hybridKey: SubjectPublicKeyInfo: algorithm OID of the secondary public key and its parameters + secondary public key of the certificate holder
Building hybrid certificates: approach: Key-signature encapsulation: hybridSig extension
- properties:
-> extension OID
-> criticality: non-critical
-> hybridSig
–> signature algorithm: algorithm OID and its parameters used for the secondary signature
–> signature value: actual signature value (over the TBS-part of the certificate)
Building hybrid certificates: approach: Key-signature encapsulation: implementation challenges
- Secondary signature value is part of final tbsCertificate, but cannot be included during creation of secondary signature
- tbsCertificate used for creating secondary signature must include hybridSig extension with correct byte length (otherwise the tbsCertificate changes when added later)
- Original tbsCertificate for secondary signature needs to be recreated during verification
Building hybrid certificates: approach: Key-signature encapsulation: Certificate Creation steps
- Create standard tbsCertificate with all required extensions
- Add hybridKey and hybridSig extensions
- Sign resulting tbsCertificate with secondary signature algorithm and key of certificate issuer to obtain secondary signature
- Replace zero bytes with resulting secondary signature value
- Sign final tbsCertificate with primary signature algorithm and key of the certificate issuer
Building hybrid certificates: approach: Key-signature encapsulation: Hybrid certificate verification
- Verify primary signature of certificate with primary public key of issuer
- Extract tbsCertificate from the certificate
- Read signature algorithm OID from hybridSig extension
- Replace signature bytes in hybridSig extension with zero bytes
- Use resulting tbsCertificate to verify the secondary signature with the secondary public key of the issuer
- The certificate is valid, if primary and secondary signature are both valid, else invalid
Pretty Good Privacy (PGP)
- Software suite that facilitates e-mail and file protection: Encryption & Signing
PGP certificate contents
- public key
-> PGP version number
-> time when key created
-> how long key is valid
-> key type
-> the key material itself - user id
- signature
-> version number
-> signature type
-> public key algorithm
-> hash algorithm
-> hashed subpackets
-> unhashed subpackets
-> 16 bits of signed hash value
-> signature
-> counter
WAP certificates
- Wireless Application Protocol (WAP)
- Like X.509 but smaller
- For usage in mobile Internet
- Serial Number usually not longer than 8 Bytes
- Algorithms: e.g. SHA256withRSA, SHA256withECDSA
- Extensions are not all included
Card verifiable certificates
- even more compact than WAP certificates
- for usage on smart cards (authentication)
- signature with message recovery
- contains barely more than issuer, subject, public key, validity
Attribute certificates
- Similar to PKC but contains no public key (contains subject, attributes, digital signature)
- May contain attributes associated with the AC holder, e.g. role, security clearance
- placement of authorization information in PKCs is usually undesirable because:
-> authorization information often does not have the same lifetime as the binding of the identity and the public key
-> PKC issuer is not usually authoritative for the authorization information
Trust Models
- Direct Trust
- Web of Trust
- Hierarchical Trust
Meaning of trust in PKI
- Certifiers reliably check authentication of entities
- Follow certain standards and policies regarding their processes
-> We can trust, that an entity is who it pretends to be & that the used keys / crypto are secure - But not: That an entity is indeed trustworthy in its behavior, e.g., that the online shop owner actually sends out the goods you payed for - not in the scope of PKI
Direct Trust
- User receives public key directly from owner OR
- User verifies public key directly with owner
Forms of direct trust
- Fingerprint comparison (fingerprint: hash of certificate incl. signature in DER format)
- Face to Face verification
- Phone verification
- Web page verification
- Printed media verification
SSH
- Cryptographically secure operation of networks services over insecure networks
- User authentication based on password or public key
- Computer authentication based always on public key