Cryptography and Certificates
WWUCA and DFN-PKI

Table of contents

3. Part 1: The problem

6. Part 2: Cryptographic building blocks

18. Part 3: Certificates and Certification Authorities

27. Part 4: WWUCA and DFN-PKI

32. Part 5: Getting certificates

Part 1: The problem

4. Communication problems

5. Cryptography as problem solution

Communication problems

• No matter whether IP packet, email, 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

  • prevents meddlers from reading

  • 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

Part 2: Cryptographic building blocks

7. Symmetric cryptography (secret key systems)

8. Properties of secret key systems

9. Asymmetric Cryptography (public key systems)

10. Public key systems: When which key?

11. How do public key systems help?

12. Properties of public key systems

13. Key sizes and security

14. Cryptographic essences (fingerprints)

15. Combine systems for speed – sign and verify

16. Combine systems for speed – encrypt and decrypt

17. Summary

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: 2¹²⁹ = 2 × 2¹²⁸

  • 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

  • Too slow for huge amounts of data

  • Illustration: How it works only with public key system

  • Combine secret key system + public key system + fingerprints to speed up

Key sizes and security

• 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

Part 3: Certificates and Certification Authorities

19. How do I get somebody's public key?

20. Certificates

21. When to use a certificate

22. How to check certificates

23. Certification chains / hierarchies

24. DFN-PKI “Global” certificate hierarchy

25. How to become a Root CA

26. How to become a serious root CA

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:

  • Email, WWW, LDAP, Keyserver, etc.

  • S/MIME signatures contain the public key, most email 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 email)

  • Signature created by issuer

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

When to use a certificate

• You present your certificate:

  • As a person/group: when sending a signed email (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/IT-Portal/

  • 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

• More information about DFN-PKI in next part

• Demo: Check certificate of this page

• Demo: Edit trust of CAs in Firefox

How to become a Root CA

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

• With OpenSSL: https://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 etc.; activities of Iran, Kazakhstan, China etc.

Part 4: WWUCA and DFN-PKI

28. Zertifizierungsstelle der Uni­ver­si­tät Münster (WWUCA)

29. DFN-PKI

30. DFN-PKI hierarchies

31. Public LDAP address book for DFN-PKI

Zertifizierungsstelle der Uni­ver­si­tät Münster (WWUCA)

• Sub-CA (not a root CA)

  • realized as DFN Global Issuing CA

• 3 staff members (at WWU IT)

• +11 team members in WWU, +3 in UKM

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

• Current grow because:

  • WWU employees are obliged to protect their email communication

  • Life time of server certificates is reduced from 28 to 13 months by CA/Browser Forum since 09/2020

DFN-PKI

• Service of the German Research Network (Deutsches Forschungsnetz, DFN)

  • provided by DFN CERT GmbH in Hamburg
    (CERT = Computer Emergency Response Team)

• DFN-PKI team operates and develops the DFN-PKI

  • Department of DFN-CERT with 7 full-time employees (supported by IT staff etc. of DFN-CERT)

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

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

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

  • But: 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

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 email 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

    • Advanced:

      • Search filter: (objectclass=*)

Part 5: Getting certificates

33. How to get a personal certificate

34. How does the WWUCA issue a certificate? (1)

35. How does the WWUCA issue a certificate? (2)

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

37. Email addresses and host names in WWUCA certificates

38. Personal identification by the WWUCA

How to get a personal certificate

• Demo: Request certificate in the WWU IT portal

• You:

  • generate a key pair (on https://ca.wwu.de or in the WWU IT portal)

  • 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 your identity

  • 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 the saved JSON file or in the WWU IT portal)

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

    • CP: https://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CP.pdf

    • CPS: https://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CPS.pdf

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

  • adds some data (Subject Alternative Names): email addresses, login name, ...

  • 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

  • emails 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 email 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; usually omitted)
  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

Email addresses and host names in WWUCA certificates

• Multiple email 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 email addresses are case-sensitive:

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

• Always use lowercase only, both in certificates and in your email configuration

Personal identification by the WWUCA

• During the pandemic, personal identification is only performed in exceptional cases.

  • 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

• During the pandemic, video identification is offered to employees and institute members only.

  • Needs much more time than personal identification

  • See https://www.pki.dfn.de/policies/videoident/ (in German)

• Unfortunately, we have to put off students until after the pandemic

  • This saves you from the usual exercise (request a certificate and use it to send a signed email to the professor that is accepted as genuine by the professor's email program)

Thank you

• Rainer Perske
  https://perske.net

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