• Left clicking here jumps to the first page.

• Left clicking into the top bar  jumps to the previous page.

• Left clicking into the bottom bar  jumps to the next page.

• Right clicking into the bottom bar  jumps to the previous page.

• Left clicking into the gray areas  jumps to the next page.

For printing the contents simply use the print function of your browser.

© 2011-2020 Rainer Perske and University of Münster

# Cryptography and CertificatesWWUCA and DFN-PKI

Rainer Perske

ca. 90 Min.

## Communication problems

• No matter whether IP packet, e-mail, WWW page or any other kind of message:

• The message does not arrive at the recipient

• The message is read by a meddler during transfer

• The message is altered by a meddler during transfer

• A meddler sends a faked message

• The sender wants:

• (to make the message arrive at the recipient)

• to prevent meddlers from reading or altering

• The recipient wants:

• to check or prove that the message is unaltered

• to check or prove that the message originates from the indicated sender

## Cryptography as problem solution

• Encryption

• complicates purposeful alterations by third parties

• Electronic (digital) signature

• proves that the message originates from the indicated sender

• proves that the messages is unaltered

• proves it to anybody

• Cannot prevent message loss

## Symmetric cryptography (secret key systems)

• Usually same key for encrypting and decrypting

• Every combination of two participants needs a separate key

• Both partners need to keep the key secret carefully

⇒ Signatures cannot be checked by third parties

• The number of keys increases quadratically with the number of participants

## Properties of secret key systems

• Calculations are fast

• Arbitrary numbers can be used as key (usually)

• If the system itself has no weakness:

• Key sizes: 64 bit = broken; 80 bit = weak; 112 bit = still secure; 128 bit = secure

• Even better: 160, 192, 224, or even 256 bit keys

• Each bit more doubles the security: 2129 = 2 × 2128

• 64 bit keys are insecure (simply try all possible keys)

• Examples

• Secret writings, DES, RC5, IDEA, CAST, Blowfish, Twofish, Rijndael (AES)

• ## Asymmetric Cryptography (public key systems)

• Uses two complementary keys (key pairs)

• One key for encrypting, the other for decrypting

• One key for signing, the other for verifying

• From one key the other key cannot be calculated

⇒ One key can be public

• Only one key pair per participant

• One key (the private key) is used by the owner of the key pair

• The other key (the public key) is used by all other participants

• The number of keys increases only linearly with the number of participants

## Public key systems: When which key?

• Use the private key for those actions that only the owner may do

• Signing (by sender) and verifying (by any recipient or third party):

• Only the sender may sign

⇒ private key of sender for signing

⇒ corresponding public key of sender for verifying

• Encrypting (by any sender) and decrypting (by recipient):

• Only the recipient may decrypt

⇒ private key of recipient for decrypting

⇒ corresponding public key of recipient for encrypting

## How do public key systems help?

• Encrypting prevents meddlers from reading

• Verifying the signature proves the originating sender

• Verifying the signature proves that the message is unaltered

• Everybody can verify the signature

• Encrypting and signing are independent of each other

• Need only signing? ⇒ only the sender needs a key pair

• Need only encrypting? ⇒ only the recipient needs a key pair

• Public keys can easily be distributed

• New danger: How do we know that a public key is genuine?

## Properties of public key systems

• Only numbers with certain properties can be used as keys

• Systems are based on various mathematical issues, mostly on:

• Huge prime numbers

• Examples: RSA, ElGamal/DH, Rabin, ...

• Elliptic curves (ECC)

• Examples: NIST Curve P-192 ... P-521, Curve25519, Curve448, E-521, Brainpool P256t1, ...

• Calculations are slower (by a factor of 1000) due to huge numbers

## Key sizes and security

Secret key
AES etc.
Public key
RSA
Public key
ECC
Keys are currently
considered
64 768 130 broken
80 1024 160 weak
112 2048 224 (still) secure
128 3072 256 secure
192 7680 384 militarily secure
256 15360 512 long-time secure
• Larger keys are usually more secure

• Very different absolute numbers depending on algorithm for same estimated security → table

• But: Quantum computers will be able to break:

• all currently used public key systems

• some currently used secret key systems

• Regarding security, key size is only one factor (usually far from being the weakest link in the chain)

## Cryptographic essences (fingerprints)

• Mathematical hash function, one-way function

• Calculations are fast

• Create from message of arbitrary length an essence (fingerprint) of fixed length

• Essences are very short, 128 to 512 bit (16 to 64 byte)

• Cryptographic requirement: From an essence the message cannot be calculated

• More drastic requirement: No two different messages with the same essence can be found (birthday paradoxon)

• Then signing the essence is as good as signing the message

• Examples: MD5 (128 Bit, broken), SHA-1 (160 Bit, broken), RIPEMD-160 (160 Bit), SHA-2 (256 to 512 Bit), BLAKE2 (224 to 512 Bit), SHA-3 (Keccak, 224 to 512 Bit), ...

## Combine systems for speed – sign and verify

• To sign:

• Fast: Calculate essence of message

• Slow but few data: Encrypt essence with sender's private key

• Transmit message and signature to the recipient

• To verify:

• Slow but few data: Decrypt signature with sender's public key

• Fast: Calculate essence of message

• Fast and few data: Compare the results of both steps

• (This signature method is used most often but there are other methods.)

• Illustration: How it works with all components combined

• Don't worry – your software makes all this for you

## Combine systems for speed – encrypt and decrypt

• To encrypt:

• Create random (!) key for secret key system

• Fast: Encrypt the (signed) message with random secret key

• Slow but few data: Encrypt the random secret key with recipient's public keys

(Do last step for every recipent)

• Transmit encrypted message and encrypted random key to recipient

• To decrypt:

• Slow but few data: Decrypt the encrypted random secret key with the recipient's private key

• Fast: Decrypt the (signed) message with the random key

• Illustration: How it works with all components combined

• Don't worry – your software makes all this for you

• Names like TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA describe the algorithms combined

## Summary

• Sender

1. signs with sender's private (secret) key

2. encrypts with recipient's public key

• Recipient

1. decrypts with recipient's private (secret) key

2. verifies with sender's public key

• Always remember:

• You need your private key only for signing and decrypting, never else

## How do I get somebody's public key?

• Danger: How do we know that a public key is genuine?

• Often not feasible: Personal handover or trustworthy courier

• Split the problem:

• Transfer the public key (may be insecure)

• Check the authenticity of the received key

• How to transfer:

• E-Mail, WWW, LDAP, Keyserver, etc.

• S/MIME signatures contain the public key, most mail programs remember them

• How to check the authenticity:

• Check the fingerprint obtained from a trustworthy source

• Check the signature of the message containing the key (If sender = owner: The cat catches its tail?)

• Check the certificate containing the key

## Certificates

• Certificates are electronically signed confirmations

• “This public key belongs to this identity (person, server)”

• Fixed formats (OpenPGP, X.509, OpenSSH, ...) for automatic verification

• Certificates contain:

• Public Key (X.509) or its fingerprint (OpenPGP)

• Owner of key (“subject”: full name or FQDN, organization etc.)

• X.509: “CN=Rainer Perske, O=Westfaelische Wilhelms-Universitaet Muenster, L=Muenster, ST=Nordrhein-Westfalen, C=DE”

• X.509: “CN=www.uni-muenster.de, O=.....” (see above)

• OpenPGP: “Rainer Perske (office) <rainer.perske@uni-muenster.de>”

• Further data (issuer, serial number, validity period, purpose, alternative names like e-mail)

• Signature created by issuer

• Certificates do not contain the owner's private key!

## When to use a certificate

• As a person/group: when sending a signed e-mail (attached to the signature)

• The recipient will check signature and certificate

• As a server: when accepting an TLS (HTTPS, IMAPS, POP3S, ...) connection

• The client will check the certificate and compare the host name

• As a client: when connecting to an TLS (HTTPS, IMAPS, POP3S, ...) server

• Only if expected by the server (better security than password authentification)

• The server will check the certificate

• Try: https://xsso.uni-muenster.de/MeinZIV/

• As a programmer: when signing a piece of software code

• The operating system of the target system will check signature and certificate before installing

## How to check certificates

• Non-technical:

• Is the issuer trustworthy?

• Is the issuer competent?

• This assessment is done by the person to whom the certificate is presented

• Technical:

• Verify the authenticity of the certificate

• Either compare with a fingerprint obtained from a trustworthy source

• Or check its signature with the issuer's public key

• (The cat catches its tail? No, it catches the tail of the preceding cat)

## Certification chains / hierarchies

• A certificate may be signed with a public key

• which is contained in another certificate

• which is signed with a public key

• which is contained in yet another certificate

• ... ... ...

• The final certificate is signed with itself: root certificate

• Software vendors include many pre-checked root certificates, see below

• A certificate is valid, if

• the root certificate is genuine and

• all issuers in the chain are trustworthy and competent

• When you present your certificate, you have to present the intermediate certificates, too

• Then the certificate checker only needs the root certificate

## DFN-PKI “Global” certificate hierarchy

• Our old chain (until July 2019):

• Deutsche Telekom Root CA 2 → DFN-PCA → WWUCA → server/user

• Our new chain (since November 2016):

• T-TeleSec GlobalRoot Class 2 → DFN-PCA → DFN Global Issuing CA → server/user

• The 400 CAs in the DFN-PKI share a common “DFN Global Issuing CA” certificate

• Demo: Edit trust of CAs in Firefox

## Public LDAP address book for DFN-PKI

• Contains all published certificates of all CAs in the DFN-PKI “Global” hierarchy

• Use as external address book in e-mail programs:

• in Thunderbird:

• Preferences | Composition | Addressing | Directory Server | Edit Directories... | Add

• General:

• Hostname: ldap.pca.dfn.de

• Port number: 389

• Base DN: O=DFN-Verein,C=DE

• Search filter: (objectclass=*)

## How to become a Root CA

• A certification authority (CA) is somebody issuing certificates as his business

• With OpenSSL: www.openssl.org

• Set up a complete root CA:
mkdir demoCA demoCA/newcerts ; touch demoCA/index.txt ; echo 01 >demoCA/serial
openssl req -x509 -newkey rsa:2048 -out CA.crt -keyout CA.key
openssl x509 -in CA.crt -noout -text

• By client: create a key pair and a request:
openssl req -new -nodes -out XY.req -keyout XY.key

• By CA: create certificate:
openssl ca -days 10 -keyfile CA.key -cert CA.crt -in XY.req -out XY.crt
openssl x509 -in XY.crt -noout -text

• CAs and Root CAs are not “per se” trustworthy

## How to become a serious root CA

• Set up a policy with rules for security, target audience, privacy, methods, archiving, contents, life times, revocations etc. you declare to obey strictly

• Announce yourself to the browser makers (for Mozilla use Bugzilla)

• Example: Deutsche Telekom Root CA 2: https://bugzilla.mozilla.org/show_bug.cgi?id=378882

• Request sent: April 2007; integration in Firefox+Thunderbird: July 2009

• Rigorous checking of requirements (policies, audits etc.) over months and years

• Requesting CA has to adapt every little bit of its policy and its operation to the requirements

• Leading party in the ongoing development is the CA/Browser Forum: https://cabforum.org/

• Most of our policy changes in the last years came due to new CA/Browser Forum requirements

• It costs millions of Euros to operate a CA that meets all requirements:

• All universities delegate CA operation to DFN and DFN cooperates with German Telekom

• We don't want to trust “Honest Achmed”: https://bugzilla.mozilla.org/show_bug.cgi?id=647959

• Serious background: blunders of Commodo, DigiNotaar and others

## Zertifizierungsstelle der Universität Münster (WWUCA)

DFN-PKI “Global” X.509 certificates issued by the WWUCA
year total server user group code intern revoc's
2019 1223 662 518 29 4 10 (311)
2018 895 396 464 21 5 9 (198)
2017 940 320 577 34 3 6 (162)
2016 611 241 345 11 5 9 (147)
2015 323 176 135 3 2 7 (73)
2014 596 351 226 9 4 6 (133)
2013 369 177 180 4 3 5 (45)
2012 282 113 157 1 3 8 (92)
2011 309 81 217 3 1 7 (36)
2010 202 100 91 0 9 2 (14)
2009 158 69 86 0 0 3 (20)
2008 265 166 96 1 0 2 (92)
2007 307 159 136 1 2 9 (18)
• Sub-CA (not a root CA)

• 3 staff members (at WWU IT)

• further team members: 10 in WWU, 3 in UKM

• I spend some 10 % of my time for the WWUCA, all others far less.

• Peak in 2014: Heartbleed (OpenSSL bug), SHA-1 deprecation, Poodle (SSLv3 bug)

• Current grow: WWU employees are obliged to protect their e-mail communication

• OpenPGP discontinued after 2011:
Less than 15 requests per year

## DFN PKI

• Service of the German Research Network provided by DFN CERT GmbH in Hamburg
(CERT = Computer Emergency Response Team)

• DFN-PKI team (8 members) operates and develops the DFN-PKI

• Three X.509 hierarchies with different policies: “Global”, “Basic”, “Grid”

• 398 outsourced subordinate CAs of DFN e.V. members (incl. WWUCA)

• OpenPGP discontinued after 2009 due to lack of demand

• No additional costs: DFN PKI service is part of the DFNInternet service

• WWU pays 285.220 €/a for 2×15 GBit/s

## DFN PKI hierarchies

• DFN-PKI “Global” (sub-CA of “T-TeleSec GlobalRoot Class 2”)

• highest available security, approved by all market leaders

• WWUCA is working in this hierarchy.

• DFN-PKI “Basic” (root CA)

• relaxed requirements for identity control

• not supported by WWUCA (all identification methods available to the WWUCA that fulfil the “Basic” requirements also fulfil the “Global” requirements.)

• DFN-PKI “Grid” (root CA, for scientific grid computing, acknowledged by the EUGridPMA)

• has no subordinate CAs but I am “sleeping” registrar (currently no demand)

• OpenPGP (not a hierarchy but a web of trust)

• discontinued by DFN after 2009, by WWUCA after 2011 due to lack of demand

## How to get a personal certificate

• Demo: Request certificate in user portal MeinZIV

• You:

• generate a key pair (on ca.wwu.de or with MeinZIV)

• pass the public key and personal data to the CA (on that page)

• hand the key's fingerprint to the CA (face-to-face, presenting your identity card)

• The CA:

• Checks the key's fingerprint

• Creates the certificate using its private key

• Sends the certificate to you (and publishes it if requested)

• You:

• join certificate and private key (do you know where it is? in your browser profile or in MeinZIV)

• create a certificate backup file (.p12/.pfx) that can be imported into any certificate-aware software

## How does the WWUCA issue a certificate? (1)

• The WWUCA team member:

• strictly obeys Certificate Policy (CP) and Certification Practice Statement (CPS)

• Rules for security, target audience, privacy, methods, archiving, contents, life times, revocations etc.

• checks all aspects of your request (perhaps applies corrections or rejects)

• compares the fingerprint on the form with that of the public key

• thus the WWUCA knows the public key with the given fingerprint is yours

• (electronically) signs a confirmation message to the certification server

• (manually) signs and archives your request form

## How does the WWUCA issue a certificate? (2)

• The well-protected DFN PKI certification server automatically:

• checks the signature of the message and the accreditation of the signer

• checks conformance of the request (only our domains? etc.)

• So I cannot issue certificates for google.com

• creates the certificate

• mails the certificate to the requester

• publishes the certificate via LDAP (if requested)

## Distinguished Names (X.500 DNs) in WWUCA certificates

• Several restrictions by CP+CPS (most of them technically enforced by DFN PKI):

• Only servers and e-mail addresses belonging to WWU, UKM, or KA

• emailAddress=. . . (only for users, at most one, but see below)
CN=. . . (exactly one must be given; only name parts from identity card, no “Prof.“ or alike)
OU=. . . (optional; avoid abbreviations)
O=Westfaelische Wilhelms-Universitaet Muenster (or) O=Universitaetsklinikum Muenster (or) O=Kunstakademie Muenster - Hochschule fuer bildende Kuenste (must be given)
L=Muenster, ST=Nordrhein-Westfalen, C=DE (must be given)

• Limited field length (64), limited character set (a-z A-Z 0-9 ' ( ) + , - . / : = ? space)

• Convert german letters: ä ö ü ß Ä Ö Ü ⇒ ae oe ue ss Ae Oe Ue

• Remove accents: Ibáñez ⇒ Ibanez, Łódź ⇒ Lodz

• Phonetically transcribe other scripts: Δήμητρα ⇒ Dimitra, Ærøskøbing ⇒ Aeroeskoebing

• Order matters and no other fields allowed

## E-mail addresses and host names in WWUCA certificates

• Multiple e-mail addresses (for users), host names (for servers) etc. can be given as Subject Alternative Names

• Full qualified domain names (FQDNs) only (“www.wwu.de” but not “www”)

• These names are verified, too

• Hosts and domains are case-insensitive

• Local parts of e-mail addresses are case-sensitive:

• perske@wwu.de   =   perske@WWU.DE     PERSKE@WWU.DE

• Always use lowercase only, both in certificates and in your e-mail configuration

## Tomorrow

• Bring the printed and signed „Zertifikatantrag für ein Nutzerzertifikat“

• Bring your valid identity card or passport

• Driving licence, student card, or other documents are not accepted!

• Expired documents are not accepted!

• Only accepted German documents: Personalausweis, Reisepass, Aufenthaltstitel

## Thank you

• Rainer Perske

• Westfälische Wilhelms-Universität
WWU IT
Zertifizierungsstelle
Röntgenstraße 7–13
48149 Münster

• ca@uni-muenster.de
+49 251 83 31590 (fon)
+49 251 83 31555 (fax)

• https://www.uni-muenster.de/WWUCA/