IT Security

Name

Private-Key Information Syntax Standard

Comments

Describes syntax for encrypted private key informations including a set of attributes (e.g. distinguished name of a top-level CAs public key).

Name

Certification Request Standard

Comments

Format of messages (Certificate Signing Request) sent to a CA to request certification of a public key. (RFC 2986).

Name

Cryptographic Token Interface 

Comments

An API defining a generic interface to cryptographic tokens. 

Name:

Personal Information Exchange Syntax Standard 

Comments 

Defines a file format used to store private keys with accompanying public key certificates, protected with a password-based symmetric key

Be aware: Keeping private keys in software token is not very secure. The security of such a token is the security of the password protecting it. Passwords tend to be insecure.

When you receive a certicate - for example - from an email. The certicate indicates the owner's name is Bob. How can you be sure that the certicate really belongs to Bob? Eve could generate a certicate with the same name called "Bob" and could snif the net to intercept the emails between Bob and you. This is an easy way of a man-in-the-middle-atacc. Fortunately each certicate has its unique ingerprint, lice a person does. If you can ind a way to verify the certicate's ingerprint with Bob then you are sure that the certicate really belongs to Bob and not someone else.

There is no global PKI today, and there never will be!

It is even hard to build a national PKI, accepted by a majority of application provider in one specific country! 

Finally, security depends on the trustworthiness of a credential issuing instance! (Trust Service Provider) 

Any public and trusted CA can issue certificates for any domain name without obtaining permission.

Are these CAs trustworthy? Who are these organizations, which we allow to issue certificates with very little supervision?

hich are the political and economic interests behind? 

We have ~170 Root CA in trust store

19 Root CAs signed ~15‘430 ICAs

Certificates are bound to a DNS record.

Needs DNS Sec

Trust is shifted from CAs to DNS hoster (.ch, .com. ...)

Browser (or other application) fixes a certificate for a specific webpage. (google.ch needs certain certificate)

Can be used to avoid Mathew in the middle attacks

Pinning similar to trust store

New certificates will be saved in a publicly available certificate list. 

--> Domain Admins can check which certificates are valid for their domain 

--> Certificates without ID in the ledger will not be accepted by browser

--> nobody knows what to do when you find invalid certs

End Entity (EE)

Certification Authority (CA)

Registration Authority (RA)

Validation Authority (VA)

Repository

In cryptography, a PKI is an arrangement that binds public keys with respective user identities by means of a certificate authority (CA). The user identity must be unique within each CA domain. The third-party validation authority (VA) can provide this information on behalf of CA. The binding is established through the registration and issuance process, which, depending on the assurance level of the binding, may be carried out by software at a CA or under human supervision. The PKI role that assures this binding is called the registration authority (RA), which ensures that the public key is bound to the individual to which it is assigned in a way that ensures non-repudiation.

Issuer of Digital Identities

Trust Anchor

In general is a registration location, where a user has to be registered personally. 

Registration Authorities convert 'real' identities in ‚digital‘ identities

Examples

Bank-desk / Post-office

A small meshed network of local agencies

Human resources / Personal office in a company

 IT-Services

Private:

--> used in a company / department

--> used for internal applications only

--> used for VPN / User Auth / WPA

public

--> trusted, well known and reachable

--> Known by Browser

--> Internet Level

Only really used for private CAs

Only one CA that issues certificates

Default way to handle public CA

Tree model with one root ca and many sub CAs

RootCA only signs sub CA and can then be locked away.

SubCAs will then isue EE certificates (mabbe for specific purposes only)

1. Starts with EE approaching RA/CA with a specific request.

2. Key Pair Generation using established algorithms (by EE mostly)

3. Certificate Creation (CA is responsible)

4. Key / Certificate Distribution 

--> Require secure transmission

--> Specific protocols for this purpose

5. Certificate Dissemination 

--> Making certificate information available to the requestor

6. Key Backup

--> Provided by CA or trusted third party

Domain Validation

Organization Validation

Extended Validation

Can only be issued by certified CA

Need to verify the owner of Website more throughout

Structurally not different from other certs

Browser usually display EV Certs slightly different (green bar)

Class 1

--> Non-Repudiation only

Class 2

--> Digital Signature / Authentication

Class 3

--> Digital Signature / Authentication / encipherment

Class 4

--> Digital Signature / Authentication / encipherment

A certificate whose primary purpose is identifying a person with high assurance in public non-repudiation services. 

Via PKI Standard PKCS#10 (over TLS or PKCS#7)

Simple Certificate Enrollment Protocol (SCEP)

Auto-Enrollment from Microsoft

Certificate Request Message Format (CRMF) 

Proof of possession of the private key.

To make sure a Mathew can't intercept the communication and change the public key. 

Personal Security Environment (PSE)

Smartcards

Cryptocards

Hardware Security Modules (HSM)

HSM (or Hardware Security Module) is defined as a piece of hardware and associated software/firmware that usually attaches to the inside of a PC or server and provides at least the minimum of cryptographic functions. These functions include (but are not limited to) encryption, decryption, key generation, and hashing. The physical device offers some level of physical tamper-resistance and has a user interface and a programmable interface.

Sometimes it is necessary to immediately block usage of a certificate before its expiration date.

A revocation request allows an End Entity (or RA) to revoke a still valid certificate by the CA.

The CA must publish the revocation subsequently on a specific infrastructure.

There are two realization concepts:

-->Black-list approach

>>>>Certificate Revocation Lists (CRL)

-->White-list approach

>>>>Online Certificate Status Protocol (OCSP)

The client checks CRL List directly. 

CRL too expensive thus OSPF mostly used

OCSP may be expensive for CA

OCSP has privacy leaks

Website Owner requests OCSP Service and sends valid timestamp together with certificate

Certificates expire --> what then

Renewal

--> same certificate same keys new dates

Updates

New Keys, Certificate and new dates

Keys for

--> signing

--> encrypting

--> non repudiation

--> authentication

CAs also offer time stamping services

A trustworthy timestamp should be added every time a user digitally signs a document to achieve a higher level of legal probative value (Beweiskraft).

A hash value of the content is digitally time-stamped by a trustworthy DTS and embedded in the to be signed document of the author. This makes time of creation provable later on.