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/2022-01-24.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:
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)
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 | 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)
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), ...
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
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 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
Our former “Global” chain (until July 2019):
Deutsche Telekom Root CA 2 → DFN-PCA → WWUCA → server/user
Our current “Global” 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
Our new “TCS” chain (since August 2021):
The USERTrust Network → Sectigo Ltd. → GÉANT TCS → server/user
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
More information about DFN-PKI in next part
Demo: Check certificate of this page
Demo: Edit trust of CAs in Firefox
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 | s. | client | code | grid | ||
|---|---|---|---|---|---|---|---|---|
| 2021 | 1053 | 625 | 7 | 416 | 2 | 3 | ||
| year | total | server | user | group | code | intern | revoc's | |
| 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) | |
Sub-CA (not a root CA)
“Global” realized by DFN Global Issuing CA
“TCS” realized by GÉANT TCS
3 staff members (at WWU IT)
+14 team members in WWU
+2 in UKM
I spend some 20 % of my time for the WWUCA, all others far less
Provides service for university and arts academy
(UKM CA is becoming independent)
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 8 full-time employees (supported by IT staff etc. of DFN-CERT)
Multiple X.509 hierarchies with different policies:
“TCS” (operated by GÉANT, administered by DFN-PKI)
“Global”, “Basic”, “Grid” (operated and administered by DFN-PKI)
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 “TCS” (sub-CA of “The USERTrust Network”)
DFN-PKI “Global” (sub-CA of “T-TeleSec GlobalRoot Class 2”)
highest available security, approved by all market leaders
WWUCA is working in these hierarchies
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” and “TCS” requirements.)
DFN-PKI “Grid” (root CA, for scientific grid computing, acknowledged by the EUGridPMA)
not supported by WWUCA due to lack of demand
OpenPGP (not a hierarchy but a web of trust)
discontinued by DFN after 2009, by WWUCA after 2011 due to lack of demand
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=*)
Unfortunately GÉANT TCS does not offer such an address book
(We consider to offer an LDAP server with “Global” and “TCS” certificates of WWU and arts academy)
Demo: Request certificate in the WWU IT portal
You:
generate a key pair
securely (see slide 19) pass the public key and your personal data to the CA
The CA:
Verifies your identity (as carefully as specified in the certification policy)
Verifies that the public key is really yours (dito)
Creates your certificate signed by its private key
Sends your certificate to you (and publishes it if requested)
You:
merge certificate and private key (and involved CA certificates) into your digital ID
create a certificate backup file (.p12/.pfx) that can be imported into any certificate-aware software
All these steps can be assisted or automated by software or web services like the WWU IT portal
For “Global” certificates, 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.
“Global” CP: https://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CP.pdf
“Global” 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
For “TCS” certificates, the complete process is fully automated in the WWU IT portal
The well-protected certification server at DFN-PKI (“Global”) resp. Sectigo (“TCS”) 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
sends the certificate to the requester (by email for “Global”, by download for “TCS”)
publishes the certificate via LDAP (if requested, only “Global”)
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 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)
GN=. . ., SN=. . . (given name and surname,
must be given)
O=Westfaelische Wilhelms-Universitaet Muenster (or)
O=Kunstakademie Muenster - Hochschule fuer bildende Kuenste (must
be given)
L=Muenster, ST=Nordrhein-Westfalen, C=DE (and more, must be given,
requirements change sometimes)
Only for “Global”: Limited character set “PrintableString” (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
Limited field length (64), order matters and no other fields allowed
Multiple emails (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” 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
During the pandemic, video identification is offered to employees and institute members only
“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:
You can prove your identity in a video conference by showing
German Aufenthaltstitel (preferred)
or Passport or ID
card (only EU or FL, IS, N, CH, AND, MC, RSM)
Driving licence, student card, or other documents are not accepted
Expired documents are not accepted
For those participants of this lecture who cannot select the WWU IT Portal item “New ID ‘TCS’ (WWU)”:
I offer you a video identification
In Zoom, you'll find yourself in the waiting room (you can do other things while you wait)
I'll then bring you into the conference one at a time (to protect your privacy)
Please have your WWU ID (login name) and your Aufenthaltstitel (or other ID document) ready
If you have a cheap webcam without autofocus, please have a
magnifying glass ready
Or use a smartphone or tablet instead (I must be able to read the small
writing in your document)
Today or tomorrow, after the lecture:
PIN: 128 256
On other days: Please call me by phone, not before 10 a. m.
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)