Table of contents

3. Part 1: The problem

6. Part 2: Cryptographic building blocks

15. Part 3: Combine cryptographic building blocks for speed

23. Part 4: Certificates and Certification Authorities

33. Part 5: UCAM, DFN-PKI, GÉANT TCS, Sectigo, USERTrust Network

37. Part 6: Getting certificates

46. Part 7: Your assignment

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)

Symmetric cryptography (secret key systems)

• Usually same key for encrypting and decrypting

• Both partners need to keep the key secret carefully

  ⇒ Signatures cannot be checked by third parties
   

• Every combination of two participants needs a separate key

• With n participants, you need n (n – 1) / 2 ≈ n²/2 keys

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

  • 64 bit keys are insecure (“brute force”: simply try all possible keys using many computers)

  • 128 bit keys are secure against attacks with classical computers (for physical reasons)

    • Each bit more doubles the security: 2¹²⁹ = 2 × 2¹²⁸

  • 256 bit keys are secure against attacks with quantum computers

    • Each two bits more double the security against quantum computers: √2²⁵⁸ = 2 × √2²⁵⁶

• 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

• With n participants, you need only  n key pairs

• 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 + randomness 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

  • 256 bit hashes have the security of 128 bit symmetric keys

• 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, weak), SHA‑2 (256 to 512 Bit), BLAKE2 (224 to 512 Bit), SHA‑3 (Keccak, 224 to 512 Bit), ...

Part 3: Combine cryptographic building blocks for speed

16. Sign

17. Verify

18. Sign and Verify

19. Encrypt

20. Decrypt

21. Encrypt and Decrypt

22. Summary

Sign

• Fast: Calculate essence of message

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

  • The signature is the encrypted essence

• Transmit message and signature to the recipient
   

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

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

  • If they are not equal, then message or signature are not genuine
     

Sign and Verify

Encrypt

• Create random key for secret key system

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

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

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

  • (Multiple recipients? Do this for every recipent)

• Transmit encrypted message and encrypted random key(s) to recipient(s)

Decrypt

• (Multiple recipients? Pick the encrypted random secret key that is encrypted with your public key)

• 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
   

• Names like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 describe the algorithms combined

Encypt and Decrypt

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
     

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

Part 4: Certificates and Certification Authorities

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

25. Certificates

26. Contents of a certificate

27. When to use a certificate

28. How to check certificates

29. Certification chains / hierarchies

30. How to check a certification chain

31. How to become a root CA

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

Contents of a certificate

• Certificates contain:

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

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

    • X.509: “E=rainer.perske@uni-muenster.de, CN=Rainer Perske, GN=Rainer, SN=Perske, O=Universität Münster, 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 addresses)

  • 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 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:4096 -out CA.crt -keyout CA.key

  • Publish CA.crt

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

  • By CA: issue certificate:
    openssl ca -days 10 -keyfile CA.key -cert CA.crt -in XY.req -out XY.crt

• 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 via DFN and GÉANT TCS to (currently) Sectigo

• 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 5: UCAM, DFN-PKI, GÉANT TCS, Sectigo, USERTrust Network

34. University Certification Authority Münster (UCAM)

35. DFN-PKI, GÉANT TCS, Sectigo, USERTrust Network

36. Our hierarchies

University Certification Authority Münster (UCAM)

• Service offered by CIT to university and arts academy

  • UKM is independent since 2022

• Multiple certificate types:

  • Server certificates (web and mail and other servers)

  • Client (user) certificates (email and web login)

  • PDF certificates (university internal document signing)

    • We operate our own PDF root CA

  • Everything above is integrated in the IT portal

  • Special certificates: Grid computing, code signing, ...

• 16 team members located all over the university

• I do most of the UCAM work, which takes up a quarter of my working time.

DFN-PKI, GÉANT TCS, Sectigo, USERTrust Network

• 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: The university pays 88.230 €/a for the service packet and 285.220 €/a for 2×15 GBit/s connectivity

Our hierarchies

• World-wide accepted certification hierarchies:

  • Multiple hierarchies provided by GÉANT TCS + Sectigo, e.g.:

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

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

    • USERTrust RSA CA → GEANT OV RSA CA 4 → server certificate

  • Highest available security and reliability

  • USERTrust root certificates are approved by all market leaders and built into their web+mail software

• For internal use only:

  • PDF-CA (root CA operated by UCAM, issues document signing certificates)

  • DFN-Verein “Community” PKI (root CA operated by DFN-PKI)

    • relaxed requirements for identity verification

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

Part 6: Getting certificates

38. How to get a personal certificate (1)

39. How a CA issues a certificate (1)

40. How a CA issues a certificate (2)

41. How to get a personal certificate (2)

42. UCAM and IT portal

43. Information validation

44. Personal identification

45. Email addresses and host names in UCAM certificates

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. “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 “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 31)

How to get a personal certificate (2)

• Merge private 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

UCAM and IT portal

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

• At the university, 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 UCAM 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

• Demo: Request certificate in the IT portal

Information validation

• Certificates may only contain information validated according to Baseline Requirements, CP and CPS

• Name and location of the university are validated by Sectigo against multiple sources

• Email addresses are validated against our local user database

• Server host names and domains are validated against our local network database

• Personal names are validated against different types of reliable documents or by personal identity check

  • If personal names cannot be validated sufficiently, they are omitted from the certificate

  • Then the personal certificate contains email addresses and organization only

Personal identification

• For each of the >100 groups of people at the university, I have checked whether we have seen sufficiently reliable documents (see investigation results, in German):

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

  • Most regular students were just sufficiently identified during registration by a combination of documents according to former requirements, but not sufficiently according to the new Baseline Requirements

  • All other university members, e.g. Erasmus students, are not sufficiently identified

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

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

Email addresses and host names in UCAM 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 university ID for logging in to our SSO

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

• Hosts and domains are case-insensitive

• Local parts of email addresses are case-sensitive:
   

  • perske@uni-muenster.de ≠ PERSKE@uni-muenster.de
    = =

  • perske@UNI-MUENSTER.DE ≠ PERSKE@UNI-MUENSTER.DE
     

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

Part 7: Your assignment

• To complete your assignment, you need to ...

  • request a digital ID (certificate)

  • install the digital ID into your email software

  • send a signed email to a certain email address
     

• How? See https://www.uni-muenster.de/CA/en/howto-mail.shtml
   

• Good luck!