Certificates

Question 1

Hybrid Certificate Eigenschaften

Answer 1

• 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)

Question 2

Building hybrid certificates: approaches

Answer 2

• Concatenation
• Certificate Encapsulation
• Key-Signature encapsulation

Question 3

Backwards compatibility

Answer 3

• 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

Question 4

Building hybrid certificates: approach: concatenation

Answer 4

• 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

Question 5

Building hybrid certificates: approach: concatenation: advantages

Answer 5

• minimal (data) overhead
• easy to implement
• no downgrade attacks

Question 6

Building hybrid certificates: approach: concatenation: disadvantages

Answer 6

• new OIDs for combined signature schemes required (treated as one signature algorithm)
• No backwards compatibility, “new” signature algorithm must be known to clients

Question 7

Building hybrid certificates: approach: certificate encapsulation

Answer 7

• 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

Question 8

Building hybrid certificates: approach: certificate encapsulation: advantages

Answer 8

• Easy implementation
• Backwards compatibility

Question 9

Building hybrid certificates: approach: certificate encapsulation: disadvantages

Answer 9

• Redundant information (issuer, subject, validity period)
  -> data overhead
  -> consistency check required
• Potential downgrade attacks to be considered during validation

Question 10

Building hybrid certificates: approach: Key-signature encapsulation

Answer 10

• Standard X.509 certificate
• Two additional, non-critical extensions
  -> hybridKey extension contains the secondary public key
  -> hybridSig extension contains the secondary signature

Question 11

Building hybrid certificates: approach: Key-signature encapsulation: advantages

Answer 11

• No redundant information -> minimal data overhead
• Backwards compatibility

Question 12

Building hybrid certificates: approach: Key-signature encapsulation: disadvantages

Answer 12

• more complex implementation
• potential downgrade attacks to be considered during validation

Question 13

Building hybrid certificates: approach: Key-signature encapsulation: hybridKey extension

Answer 13

• 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

Question 14

Building hybrid certificates: approach: Key-signature encapsulation: hybridSig extension

Answer 14

• 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)

Question 15

Building hybrid certificates: approach: Key-signature encapsulation: implementation challenges

Answer 15

• 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

Question 16

Building hybrid certificates: approach: Key-signature encapsulation: Certificate Creation steps

Answer 16

1. Create standard tbsCertificate with all required extensions
2. Add hybridKey and hybridSig extensions
3. Sign resulting tbsCertificate with secondary signature algorithm and key of certificate issuer to obtain secondary signature
4. Replace zero bytes with resulting secondary signature value
5. Sign final tbsCertificate with primary signature algorithm and key of the certificate issuer

Question 17

Building hybrid certificates: approach: Key-signature encapsulation: Hybrid certificate verification

Answer 17

1. Verify primary signature of certificate with primary public key of issuer
2. Extract tbsCertificate from the certificate
3. Read signature algorithm OID from hybridSig extension
4. Replace signature bytes in hybridSig extension with zero bytes
5. Use resulting tbsCertificate to verify the secondary signature with the secondary public key of the issuer
6. The certificate is valid, if primary and secondary signature are both valid, else invalid

Question 18

Pretty Good Privacy (PGP)

Answer 18

• Software suite that facilitates e-mail and file protection: Encryption & Signing

Question 19

PGP certificate contents

Answer 19

• 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

Question 20

WAP certificates

Answer 20

• 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

Question 21

Card verifiable certificates

Answer 21

• 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

Question 22

Attribute certificates

Answer 22

• 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

Question 23

Trust Models

Answer 23

• Direct Trust
• Web of Trust
• Hierarchical Trust

Question 24

Meaning of trust in PKI

Answer 24

• 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

Question 25

Direct Trust

Answer 25

- User receives public key directly from owner OR - User verifies public key directly with owner

Question 26

Forms of direct trust

Answer 26

- Fingerprint comparison (fingerprint: hash of certificate incl. signature in DER format) - Face to Face verification - Phone verification - Web page verification - Printed media verification

Question 27

SSH

Answer 27

- Cryptographically secure operation of networks services over insecure networks - User authentication based on password or public key - Computer authentication based always on public key