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 and is properly used:

  • 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), ChaCha20

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

  • 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: In 1–2 decades, quantum computers will be able to break within hours:

  • all currently used public key systems

  • some currently used secret key systems

  • “Post-quantum” systems are being developed

• 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: Security is only half the length

• 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

    • (Creating good random numbers is a really hard task for deterministic computers)

  • 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_GCM_SHA384 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. How to check a certification chain

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

  • As an author: when signing a document (e.g. PDF)

    • The document reader software will check the certificate (if capable)

How to check certificates

• Non-technical:

  • Is the issuer trustworthy?

  • Is the issuer competent?

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

    • However, most people simply use the trust settings supplied by the software manufacturer

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

• user certificate or
  server certificate ← intermediate certificate ← ... ← intermediate certificate ← root certificate ⮌

How to check a certification chain

• 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

  • Software vendors include many pre-checked root certificates

  • Demo: List root certificates in Firefox – and edit trust
     

• Demo: Check certificate of this page (server) or of a user

  • www.uni-muenster.de ← Sectigo RSA ... Server CA ← USERTrust RSA Certification Authority ⮌

• More information about DFN-PKI + GÉANT TCS + Sectigo + USERTrust Network in next part

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 and GÉANT TCS

• 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 Universität Münster (WWUCA)

• Service offered by WWU IT to WWU and arts academy (UKM is independent since 2022)

• Multiple Hierarchies:

  • “Global” (old) for all types of certificates

  • “TCS” for Internet communication certificates

  • “PDF” for WWU internal document signing

  • All are integrated into IT portal

• 3 staff members in WWU IT

• + 13 team members located all over the WWU

• As programmer and maintainer of the IT portal and head of the WWUCA, I do most of the work:
  I need 1/4 of my time for the CA, all others far less

DFN-PKI

• Service of the German Research Network (Deutsches Forschungsnetz, DFN, a non-profit association)

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

  • used by all universities and large-scale research institutions in Germany

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

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

  • Multiple X.509 hierarchies with different policies and security levels

• DFN-PKI uses GÉANT TCS (also non-profit) for some of its services

  • TCS = Trusted Certificate Service; GÉANT = Gigabit European Academic Network (the name is from 2000)

  • GÉANT connects all national research and education networks in Europe with each other and the world

  • GÉANT has put TCS out to tender, the current service provider is Sectigo Ltd.

  • Sectigo Ltd. cooperates with other certification companies in the USERTrust Network

• No additional costs: DFN-PKI service is part of the DFN “all inclusive” service packet

  • But: WWU pays 88.230 €/a for the service packet and 285.220 €/a for 2×15 GBit/s connectivity

DFN-PKI hierarchies

• World-wide accepted certification hierarchies:

  • Provided by Deutsche Telekom (expires soon):

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

  • Provided by GÉANT TCS (disjunct hierarchies for RSA and ECC, each with several intermediate CAs):

    • USERTrust RSA CA → GEANT Personal CA 4 → user certificate

    • USERTrust RSA CA → GEANT OV RSA CA 4 → server certificate (manually requested)

    • USERTrust RSA CA → Sectigo RSA O. V. Secure Server CA → server certificate (via ACME)

  • Highest available security and reliability

  • Root certificates approved by all market leaders and built into their browsers and mail programs

• For internal use only: DFN-PKI “Community” PKI (root CA operated by DFN-PKI)

  • relaxed requirements for identity verification

  • currently not supported by WWUCA (our identity verifications are good enough for TCS)

Public LDAP address book for DFN-PKI certificates

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

• Use as external address book in email programs:

  • in Thunderbird: Preferences | Composition | Addressing | Directory Server | Edit Directories... | Add

  • Hostname: ldap.pca.dfn.de

  • Port number: 389

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

  • Search filter: (objectclass=*)

• Unfortunately GÉANT TCS does not offer such an address book

• Coming soon: An LDAP server with “Global” and “TCS” certificates of WWU and arts academy:

  • Hostname: usercerts.uni-muenster.de

  • Port number: 389 (LDAP), 636 (LDAPS)

  • Base DN: ou=certs,dc=uni-muenster,dc=de

• Our Exchange address book already contains all “Global” and “TCS” certificates of Exchange users

Part 5: Getting certificates

33. How to get a personal certificate (1)

34. How a CA issues a certificate (1)

35. How a CA issues a certificate (2)

36. How to get a personal certificate (2)

37. WWUCA and IT portal

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

39. Email addresses and host names in WWUCA certificates

40. Personal identification

How to get a personal certificate (1)

• Create an asymmetric key pair *

• Create a certification request by combining the public key and all relevant personal data *

• Sign the certification request with the private key *

  • So the CA can check that you are controlling the private key

• Transfer the certification request to the CA using a secure method *

  • where the CA can check your identity and

  • where the CA can check the the request really comes from you

• Usually this means:

  • electronically submitting the request file,

  • visiting a CA representative in person, presenting your passport, and

  • handing over a request form containing the fingerprint of the public key

How a CA issues a certificate (1)

• The CA verifies your identity or checks that your identity is already verified *

  • usually from the photo and the data in your passport

• The CA verifies that the certification request really comes from you *

  • usually by comparing the fingerprint of the request with the fingerprint on the request form

  • Then the CA knows that the public key in the request is yours.

• The CA checks the personal data in the certification request *

  • usually by comparing them with your passport and other reliable sources

• The CA checks that you are controlling the private key belonging to the public key **

  • usually by checking the signature of the certification request with the public key in the request

• The CA combines the public key, your personal data and additional data **

• The CA signs these combined data with the private key of the certification authority **

  • The result is the certificate and is given to you

How a CA issues a certificate (2)

• During the whole process, the CA strictly obeys its Certificate Policy (CP) and Certification Practice Statement (CPS) * **

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

  • e.g. “DFN-PKI Global” CP+CPS: https://www.pki.dfn.de/policies

  • e.g. “GÉANT TCS” CP+CPS: https://wiki.geant.org/display/TCSNT/TCS+Repository

  • All are based on the “Baseline Requirements” of the CA/Browser Forum https://cabforum.org

• There is no written “WWU PDF CA” CP+CPS

  • For „TCS“ and „PDF“, the same identification and authorization requirements are implemented

  • Unlike “TCS” certificates, “PDF” certificates are revoked only in case of compromise

  • The “PDF” CA is realized as a part of the IT portal (nearly as simple as described on slide 25)

How to get a personal certificate (2)

• Merge secret key, issued certificate, and all involved CA certificates *

  • The result is your digital ID

  • It is usually stored, encrypted with a passphrase, as an PKCS#12 file (*.p12, or rarely *.pfx)

    • PKCS = Public Key Cryptography Standard, describes file formats etc.

• Store the PKCS#12 file and the encryption passphrase in different theft-proof places as backup

• Import the PKCS#12 files into your certificate-aware software

  • First set up a good main password so that your secret key is stored encrypted in the software

  • Use certificates only as intended

    • TCS user certificates only for email (sign + encrypt) and client authentication (login)

    • TCS server certificates only for TLS servers

    • PDF certificates only for document signing

WWUCA and IT portal

• If your identity is already verified (see below), the complete process can be automated

• At WWU, this is realized mostly in the IT portal

  • All steps marked with * above are automated in the IT portal

    • this relieves both you and the WWUCA of a lot of work

  • All steps marked with ** above are automated by Sectigo

• So, with the IT portal, getting a digital ID is quite easy

  • and takes only minutes if your identity is already verified

• Demo: Request certificate in the WWU IT portal

Distinguished Names (X.500 DNs) in WWUCA certificates

• Several restrictions by CP+CPS (most of them technically enforced) that change from time to time:

  • Only servers and email addresses belonging to WWU or arts academy

  • Only personal names given in identity documents

  • No titles except if written in identity document (only Dr. in Germany, no Prof.)

  • Given names may be abbreviated or omitted if at least one complete given name is kept

  • No organizational unit

  • Organization and address details are fixed and cannot be changed

• Example: emailAddress=rainer.perske@uni-muenster.de, CN=Rainer Perske, GN=Rainer, SN=Perske, O=Westfaelische Wilhelms-Universitaet Muenster, STREET=Schlossplatz 2, postalCode=48149, L=Muenster, ST=Nordrhein-Westfalen, C=DE

Email addresses and host names in WWUCA certificates

• Multiple emails (for users), host names (for servers) etc. can be given as Subject Alternative Names

• Local feature: Special email <perske+{ID}@uni-muenster.de> gives the WWU ID for logging in to our SSO

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

• 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

• “Global” and “TCS eScience Personal” certificates require personal identification at the time of request

• “TCS Personal” certificates (our choice) require that the owner of the WWU ID has been sufficiently identified earlier on the basis of reliable documents

• For each of the >100 groups of people at the WWU, I have checked whether the requirements were met (see investigation results, in German):

• Most employees are sufficiently identified by police clearance certificate and birth certificate

• Most regular students are just sufficiently identified during registration by a combination of documents

• Unfortunately, Erasmus students are not sufficiently identified, but:
   

  • You can always prove your identity by showing in person to a WWUCA team member your
    residence permit (Aufenthaltstitel) or Passport or (only EU or FL, IS, N, CH, AND, MC, RSM) ID card

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

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

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