Chapter 04 Certificates - ...€¦ · X509 Certificates TU Darmstadt | Cryptography and Computer Algebra | Lecture: Public Key Infrastructures Relevant Standard: X.509 (ITU-T) PKIX

Public Key Infrastructures

Chapter 04Certificates

Cryptography and ComputeralgebraProf. Dr. Johannes BuchmannDr. Alexander Wiesmaier

2

PKC - Definition

Public key certificates are data structures that bind public key values to subjects. The binding is asserted by having a trusted CA digitally sign each certificate …

[From RFC 5280]

TU Darmstadt | Cryptography and Computer Algebra | Lecture: Public Key Infrastructures

3TU Darmstadt | Cryptography and Computer Algebra | Lecture: Public Key Infrastructures

Example: Secure Browsing

http://www.bsi.de

http://www.bsi.de/

4

Click on icon


5

Click on view


6

Digital Signature

Public key certificates

Subject (Name)

Public-keyBinding eID public key

protection of authenticity


7

Certificate properties

Protected binding of a key to the key holder

Its authenticity is independent of the means of transportation

It can be used online and offline

It is a proof of the binding

It can be used for key servers


8

Certificate standards

X.509 X.509 (ITU-T) PKIX (RFC 5280)

Pretty Good Privacy (PGP) OpenPGP (RFC 4880) GNU Privacy Guard (GnuPG or GPG)

WAP certificates Like X.509 certificates but smaller

Card Verifiable Certificates (CVC) Even smaller than WAP certificates

Simple PKI / Simple Distributed Security Infrastructure SPKI, pronounced spoo-key SDSI, pronounced sudsy


9

X509 Certificates


Relevant Standard:

X.509 (ITU-T)

PKIX (RFC 5280)

Content (excerpt):

Name / Pseudonym of the holder

Public Key (and algorithm) of the holder

Unique ID of the certificate

Validity period of the certificate

Identity of the certificate issuer

Key usage limitation for the public keys

Encoding:

Abstract Syntax Notation Nr.1: ASN.1

Distinguished Encoding Rules: DER

10

X.509 Certificates


file://../Certificates/BNeztA_Root.cer (bin)

../Certificates/BNeztA_Root.cer

11

X.509 Certificates: Contents


Version (0=v1, 1=v2, 2=v3)Serial Number (Unique within PKI)Certificate Signature AlgorithmIssuerValidity PeriodSubjectSubject Public Key Info

Version 1(1988)

Subject Unique ID (worldwide unique)Issuer Unique ID (worldwide unique)Version 2

(1993)

ExtensionsVersion 3(1997)

12

Certificate (ASN.1)

Certificate ::= SEQUENCE {

tbsCertificate TBSCertificate,

signatureAlgorithm AlgorithmIdentifier,

signatureValue BIT STRING }

To Be Signed (TBS) Certificate

This part holds all information; this will be signed.

Algorithm

The algorithm that is used for signing the TBS part.

Signature Value

The calculated signature.


13

Certificate (ASN.1)

Certificate:

Data: [ ........ ]

Signature Algorithm: ripemd160WithRSA

00:92:0e:fb:67:80:96:c8:e0:af:2c:6c:21:c5:7c:26:a5:5d:a0:da:ef:18:1c:da:97:6c:2f:6a:10:96:06:72:82:dd:44:63:96:60:64:1f:77:25:38:67:0d:26:83:cd:d2:e3:64:83:eb:5c:92:f1:08:e2:ea:e8:a9:b1:8f:ad:d5:f6:9f:56:51:a1:79:9f:3f:fa:3d:54:4c:98:bc:c8:ed:cb:e1:e5:00:e3:b1:7e:19:98:4c:e6:fe:2b:7b:7b:f6:07:bc:2d:58:8b:0e:5b:4d:42:e3:c1:56:76:ee:fa:8e:eb:89:a1:a6:54:0c:dc:72:95:82:4e:85:5f:9d:57:9f


14

TBSCertificate (ASN.1)

TBSCertificate ::= SEQUENCE {

version [0] EXPLICIT Version DEFAULT v1,

serialNumber CertificateSerialNumber,

signature AlgorithmIdentifier,

issuer Name,

validity Validity,

subject Name,

subjectPublicKeyInfo SubjectPublicKeyInfo,

issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,

-- If present, version MUST be v2 or v3

subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,

-- If present, version MUST be v2 or v3

extensions [3] EXPLICIT Extensions OPTIONAL

-- If present, version MUST be v3 }


15

Version

Holds the version of X.509 that the certificate is.

Version ::= INTEGER { v1(0), v2(1), v3(2) }

file://../Certificates/text/BNetz_Root_Version.cxt (text)



../Certificates/text/BNetz_Root_Version.cxt


16

Serial Number

The serial number of the certificate

CertificateSerialNumber ::= INTEGER

Positive integer

Must be unique for the same issuer Two certificates from the same issuer are not allowed to have the same serial number

file://../Certificates/text/BNetz_Root_Serial.cxt (text)



../Certificates/text/BNetz_Root_Serial.cxt




17

Signature

Specifies the algorithm that was used to sign the certificatee.g. SHA1withRSA

AlgorithmIdentifier ::= SEQUENCE {algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL }

algorithm: the algorithm OID (1.2.840.113549.1.1.5) Parameters: any needed parameters (like the elliptic curve to

be used – in ECDSA)MUST be the same as the signatureAlgorithm of the certificate

file://../Certificates/text/BNetz_Root_Signature.cxt (text)



../Certificates/text/BNetz_Root_Signature.cxt




18TU Darmstadt | Cryptography and Computer Algebra | Lecture: Public Key Infrastructures

2*AlgorithmIdentifier?

19

Issuer

Holds the name of the issuer (CA)

Looks like:

CN=RBG CA, OU=FB Informatik, O=TU Darmstadt, C=DE

file://../Certificates/text/BNetz_Root_Issuer.cxt (text)



../Certificates/text/BNetz_Root_Issuer.cxt




20

Validity

Shows the period of time that a certificate can be used

Validity ::= SEQUENCE {

notBefore Time,

notAfter Time }

file://../Certificates/text/BNetz_Root_Validity.cxt (text)



../Certificates/text/BNetz_Root_Validity.cxt


21

Subject

Holds the name of the certificate holder

Looks like:

CN=Vangelis Karatsiolis, OU=FB20, O=TUD, C=DE

It is an X.500 DN (distinguished name)

Associated to the public key contained in the certificate

The same DN is not allowed to be given to two different entities

file://../Certificates/text/BNetz_Root_Subject.cxt (text)



../Certificates/text/BNetz_Root_Subject.cxt

../Certificates/text/BNetz_Root_Subject.cxt


22

Public Key

Holds the public key of the entity

SubjectPublicKeyInfo ::= SEQUENCE {

algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING }

file://../Certificates/text/BNetz_Root_PublicKey.cxt (text)




../Certificates/text/BNetz_Root_PublicKey.cxt

../Certificates/text/BNetz_Root_AKIE.cxt


23

X.509 unique identifiers

Version 2 and 3 only

Identifies an issuer or subject, in case a DN is reused

UniqueIdentifier ::= BIT STRING

Subject Unique ID (world wide unique)Issuer Unique ID (world wide unique)Version 2

(1993)


24

X.509 Extensions

Drawbacks of X.509v1 und X.509v2:

Predetermined naming structure according to X.500 (e.g. usage of email

addresses is not possible).

No statements about the intended usage of the certified key.

No statements about the underlying policy (e.g. how was the identity of the

certificate owner verified?).

Solution:

Flexible extension fields.

ExtensionsVersion 3(1997)


25

Extensions: Properties

Assignment of extra attributes to the owner

public or private key

issuer

Support for better certificate management

Arbitrary extensions Bad interoperability


26

Extensions

Hold additional information

Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

Extension ::= SEQUENCE {

extnID OBJECT IDENTIFIER,

critical BOOLEAN DEFAULT FALSE,

extnValue OCTET STRING }


27

X.509 (Non)critical extensions

Critical Non-Critical

Known valid valid

Unknown invalid valid


28

Subject Key Identifier (SKIE)

Identifies certificates that contain a particular public key.

MUST be included in all CA certificates (non-critical)

160 bit hash of the Public Key (exclude tag, length, number of unused bits)

Or “0100” followed by 60 lsbits of the hash of the public key

SubjectKeyIdentifier ::= KeyIdentifier

KeyIdentifier ::= OCTET STRING

file://../Certificates/text/BNetz_Root_SKIE.cxt (text)



../Certificates/text/BNetz_Root_SKIE.cxt



29

Authority Key Identifier (AKIE)

Identifies the public key that corresponds to the private key that has signed the certificate.

MUST be included in all certificates (non-critical)

(unless it is a self-signed certificate)

AuthorityKeyIdentifier ::= SEQUENCE {

keyIdentifier [0] KeyIdentifier OPTIONAL,

authorityCertIssuer [1] GeneralNames OPTIONAL,

authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }

KeyIdentifier ::= OCTET STRING

file://../Certificates/text/BNetz_Root_AKIE.cxt (text)




../Certificates/text/BNetz_Root_AKIE.cxt





30

Key Usage

Defines the purpose of the key contained in the certificate.

KeyUsage ::= BIT STRING {

digitalSignature (0), nonRepudiation (1), keyEncipherment (2), dataEncipherment (3), keyAgreement (4), keyCertSign (5),cRLSign (6), encipherOnly (7), decipherOnly (8) }

file://../Certificates/text/BNetz_Root_KeyUsage.cxt (text)


http://www.ietf.org/rfc/rfc5280.txt (pp 29ff)



../Certificates/text/BNetz_Root_KeyUsage.cxt



http://www.ietf.org/rfc/rfc5280.txt

32

Subject Alternative Name

The subject alternative name extension allows additional identities to be bound to the subject of the certificate.

for example:

Internet electronic mail address

a DNS name

an IP address

uniform resource identifier (URI)

all possible combinations

Before included, this information MUST be verified since it is bound to a public key.


33

Subject Alternative Name (2)

SubjectAltName ::= GeneralNames

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {

otherName [0] OtherName,

rfc822Name [1] IA5String,

dNSName [2] IA5String,

x400Address [3] ORAddress,

directoryName [4] Name,

ediPartyName [5] EDIPartyName,

uniformResourceIdentifier [6] IA5String,

iPAddress [7] OCTET STRING,

registeredID [8] OBJECT IDENTIFIER }

file://../Certificates/text/CSCA_SAN.cxt (text)

file://../Certificates/Country_Signing_CA.cer (bin)



../Certificates/text/CSCA_SAN.cxt


../Certificates/Country_Signing_CA.cer

34

Issuer Alternative Name

Associates Internet style identities with the certificate issuer.

SHOULD NOT be marked critical

IssuerAltName ::= GeneralNames


35

Subject Directory Attributes

It is used to convey identification attributes (e.g., nationality) of the subject. The extension is defined as a sequence of one or more attributes.

MUST be non-critical

SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute


36

Extended Key Usage (1)

Indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension

For example: Code signing OCSP signing Timestamping

ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId KeyPurposeId ::= OBJECT IDENTIFIER

file://../Certificates/text/BNetz_TSS_EKU.cxt (text)

file://../Certificates/BNeztA_TSSSigner.cer (bin)



../Certificates/text/BNetz_TSS_EKU.cxt


../Certificates/BNeztA_TSSSigner.cer

37

Extended Key Usage (2)

If a certificate contains both a key usage extension

and an extended key usage extension, then both

extensions MUST be processed independently and the

certificate MUST only be used for a purpose consistent

with both extensions. If there is no purpose consistent

with both extensions, then the certificate MUST NOT

be used for any purpose.

Source: RFC 4334


38

List of other extensions

Certificate Policies

Policy Mappings

Policy Constraints

Basic Constraints

Name Constraints

CRLDistributionPoints

Inhibit Any-Policy

Freshest CRL

Authority Information Access

Subject Information Access


39

PGP

Pretty Good Privacy (PGP) is a computer program thatprovides cryptographic privacy and authentication. PGP is oftenused for signing, encrypting and decrypting e-mails to increasethe security of e-mail communications. It was created by PhilipZimmermann in 1991.

PGP and similar products follow the OpenPGP standard (RFC4880) for encrypting and decrypting data.


Source: http://en.wikipedia.org/wiki/Pretty_Good_Privacy

http://en.wikipedia.org/wiki/Pretty_Good_Privacy

40

GPG

GNU Privacy Guard (GnuPG or GPG) is a free softwarealternative to the PGP suite of crypto-graphic software. GnuPG iscompliant with RFC 4880.

GPG is a part of the Free Software Foundation's GNU softwareproject, and has received major funding from the Germangovernment. It is released under the terms of version 3 of theGNU General Public License.


Source: http://en.wikipedia.org/wiki/GNU_Privacy_Guard

http://en.wikipedia.org/wiki/German_government

http://en.wikipedia.org/wiki/GNU_Privacy_Guard

41

PGP certificates


42

PGP certificates: contents

[From http://www.ece.cmu.edu/~adrian/630-f04/PGP-intro.html]


file://../Certificates/text/wiesmaie_pub.cxt (text)

file://../Certificates/gpg/wiesmaie_pub.asc (bin)

http://www.ece.cmu.edu/~adrian/630-f04/PGP-intro.html





../Certificates/text/wiesmaie_pub.cxt

../Certificates/gpg/wiesmaie_pub.asc

43

One UserID with one signature

A simple PGP certificate -Example

Legend

Public Key Packet

User ID Packet

Signature Packet


44

Example (2)


One UserID with one signature and

a second UserID without signature

Legend

Public Key Packet

User ID Packet

Signature Packet

45

Example (3)

One UserID with four signatures


Legend

Public Key Packet

User ID Packet

Signature Packet

46

A more complicated PGP certificate

One UserID with one signature and

a second UserID with one signature and

a second key (subkey) with one signature

Legend

Public Key Packet

User ID Packet

Signature Packet


47

Public Key Packet

Creation TimeVersion

Public Key Algorithm

Public Key

(RSA case)


48

User ID Packet

A User ID packet consists of UTF-8 text that is intended torepresent the name and email address of the key holder. Byconvention, it includes an RFC 2822 mail name-addr, but thereare no restrictions on its content. The packet length in the headerspecifies the length of the User ID.

[From RFC 4880]

Example:

Alex Wiesmaier <[email protected]>


49

Signature Packet

…

…


Version

Signature Type

Public Key Algorithm

Hash Algorithm

Counter

Hashed Subpackets

Unhashed Subpackets

16 bits of signed hash value

Signature (RSA Case)

50

Subpacket content

signature creation time signature expiration time exportable certification trust signature regular expression revocable key expiration time placeholder for backward compatibility preferred symmetric algorithms revocation key

issuer key ID notation data preferred hash algorithms preferred compression algorithms key server preferences preferred key server primary user id policy URL key flags signer's user id reason for revocation


51

PGP Keys


http://gpg-keyserver.de/pks/lookup?search=wiesmaier&op=vindex




52

WAP certificates

Wireless Application Protocol (WAP)

Like X.509 certificates but smaller

For usage in mobile Internet

Serial Number: usually not longer than 8 bytes

Algorithms: SHA1withRSA, SHA1withECDSA

Extensions: not all are included


53

WAP certificates – ASN.1

WAPCertificateInfo ::= SEQUENCE {

version [0] EXPLICIT Version DEFAULT v1,

serialNumber CertificateSerialNumber,

signature AlgorithmIdentifier {{SupportedSignatureAlgorithms}},

issuer Name

{{SupportedNamingAttributes}},

validity Validity,

subject Name

{{SupportedNamingAttributes}},

subjectPublicKeyInfo SubjectPublicKeyInfo {{SupportedPublicKeyAlgorithms}},

extensions [3] EXPLICIT Extensions {{SupportedExtensions}} OPTIONAL

}


54

CV Certificates

Card Verifiable Certificate (CVC)

Even compacter than WAP Certificates

For usage on smart cards (authentication)

Signature with message recovery

Contains barely more than Issuer, Subject, Public Key, Validity


55

Attribute certificates

Digital Signature

Subject (Name)

AttributesBinding eID attributes

protection of authenticity


56

Attribute certificate

An attribute certificate (AC) is a structure similar to a PKC; the main difference being that the AC contains no public key. An AC may contain attributes that specify group membership, role, security clearance, or other authorization information associated with the AC holder.

[From RFC 5755]


57


Authorization information may be placed in a PKC extension or placed in a separate attribute certificate (AC). The placement of authorization information in PKCs is usually undesirable for two reasons. First, authorization information often does not have the same lifetime as the binding of the identity and the public key. When authorization information is placed in a PKC extension, the general result is the shortening of the PKC useful lifetime. Second, the PKC issuer is not usually authoritative for the authorization information. This results in additional steps for the PKC issuer to obtain authorization information from the authoritative source.

[From RFC 5755]


58


Authorization information may be placed in a PKC extension or placed in a separate attribute certificate (AC). The placement of authorization information in PKCs is usually undesirable for two reasons. First, authorization information often does not have the same lifetime as the binding of the identity and the public key. When authorization information is placed in a PKC extension, the general result is the shortening of the PKC useful lifetime. Second, the PKC issuer is not usually authoritative for the authorization information. This results in additional steps for the PKC issuer to obtain authorization information from the authoritative source.

[From RFC 5755]


59


AttributeCertificate ::= SEQUENCE {

acinfo AttributeCertificateInfo,

signatureAlgorithm AlgorithmIdentifier,

signatureValue BIT STRING }

Attribute Certificate Information (acinfo)

This part holds all information; this will be signed.

Signature Algorithm

The algorithm that is used for signing the acinfo part.

Signature Value

The calculated signature.


Documents

Chapter 04 Certificates - ...€¦ · X509 Certificates TU Darmstadt | Cryptography and Computer Algebra | Lecture: Public Key Infrastructures Relevant Standard: X.509 (ITU-T) PKIX