How to navigate through these slides:
So navigieren Sie durch diese Folien:
Rainer Perske
ca. 90 min.
Open this file with your browser:
https://www.uni-muenster.de/IT.RainerPerske/2023-01-23.CryptographyAndCertificates.WI.html
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
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
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
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: 2129 = 2 × 2128
64 bit keys are insecure (simply try all possible keys)
Examples
Secret writings, DES, RC5, IDEA, CAST, Blowfish, Twofish, Rijndael (AES), ChaCha20
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
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
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?
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
| 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 | secure for next years |
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)
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), ...
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.)
Don't worry – your software makes all this for you
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
Don't worry – your software makes all this for you
Names like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 describe the algorithms combined
Sender
signs with sender's private (secret) key
encrypts with recipient's public key
Recipient
decrypts with recipient's private (secret) key
verifies with sender's public key
Always remember:
You need your private key only for signing and decrypting, never else
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 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!
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)
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)
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 ⮌
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
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
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.
| year | total | ACME | server | client | code | ||
|---|---|---|---|---|---|---|---|
| 2022 | 9222 | 6471 | 468 | 2182 | 1 | 100 | |
| 2021 | 1053 | 625 | 7 | 419 | 2 | ||
| year | total | server | user | group | code | intern | revoc's |
| 2022 | 344 | 324 | 13 | 3 | 0 | 4 | (271) |
| 2021 | 2024 | 994 | 914 | 98 | 6 | 12 | (374) |
| 2020 | 1428 | 764 | 609 | 48 | 4 | 3 | (240) |
| 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) |
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
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
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)
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
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
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
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)
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
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
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
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
“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!
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