Certificates Flashcards

1
Q

Hybrid Certificate Eigenschaften

A
  • 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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Building hybrid certificates: approaches

A
  • Concatenation
  • Certificate Encapsulation
  • Key-Signature encapsulation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Backwards compatibility

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Building hybrid certificates: approach: concatenation

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Building hybrid certificates: approach: concatenation: advantages

A
  • minimal (data) overhead
  • easy to implement
  • no downgrade attacks
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Building hybrid certificates: approach: concatenation: disadvantages

A
  • new OIDs for combined signature schemes required (treated as one signature algorithm)
  • No backwards compatibility, “new” signature algorithm must be known to clients
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Building hybrid certificates: approach: certificate encapsulation

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Building hybrid certificates: approach: certificate encapsulation: advantages

A
  • Easy implementation
  • Backwards compatibility
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Building hybrid certificates: approach: certificate encapsulation: disadvantages

A
  • Redundant information (issuer, subject, validity period)
    -> data overhead
    -> consistency check required
  • Potential downgrade attacks to be considered during validation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Building hybrid certificates: approach: Key-signature encapsulation

A
  • Standard X.509 certificate
  • Two additional, non-critical extensions
    -> hybridKey extension contains the secondary public key
    -> hybridSig extension contains the secondary signature
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

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

A
  • No redundant information -> minimal data overhead
  • Backwards compatibility
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

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

A
  • more complex implementation
  • potential downgrade attacks to be considered during validation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

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

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

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

A
  • 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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

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

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

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

A
  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
17
Q

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

A
  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
18
Q

Pretty Good Privacy (PGP)

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

PGP certificate contents

A
  • 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
20
Q

WAP certificates

A
  • 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
21
Q

Card verifiable certificates

A
  • 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
22
Q

Attribute certificates

A
  • 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
23
Q

Trust Models

A
  • Direct Trust
  • Web of Trust
  • Hierarchical Trust
24
Q

Meaning of trust in PKI

A
  • 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
25
Q

Direct Trust

A
  • User receives public key directly from owner OR
  • User verifies public key directly with owner
26
Q

Forms of direct trust

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

SSH

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