Kryptografie/tmp: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
VisuellWikitext
Die Seite wurde neu angelegt: „ = III: Theory = == 16. Overview == <blockquote>Number theorists are like lotus-eaters - having tasted this food they can never give it up.</blockquote>— Leopold Kronecker This chapter provides the necessary background information on why chapter [practicalsettings] recommended ''cipher string B''. We start off by explaining the structure of cipher strings in section [architecture] (architecture) and define PFS in [pfs]. Next we present ''Cipher Strin…“
 
K Textersetzung - „Kryptografies“ durch „Kryptografie“
 
(145 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== Motivation ==
siehe [[Kryptografie/Motivation]]


= III: Theory =
== Geheime Übermittlung ==
=== Voraussetzungen ===
* Der Empfänger kennt den Schlüssel
* aber sonst niemand
* Ohne Kenntnis des Schlüssels
* ist es unmöglich oder sehr schwierig den Klartext herauszufinden


== 16. Overview ==
=== Schwierigkeiten ===
<blockquote>Number theorists are like lotus-eaters - having tasted this food they can never give it up.</blockquote>— Leopold Kronecker
* Schlüssel muss vorher vereinbart werden
* Schlüssel muss geheim bleiben „geheimer Kanal“
* Das Kryptografieverfahren muss sicher sein


This chapter provides the necessary background information on why chapter [practicalsettings] recommended ''cipher string B''.
=== Vorhängeschloss-Analogie ===
* Der Klartext ist „eingeschlossen“, und nur Alice und Bob haben den richtigen Schlüssel für das Schloss.


We start off by explaining the structure of cipher strings in section [architecture] (architecture) and define PFS in [pfs]. Next we present ''Cipher String A'' and ''Cipher String B'' in section Recommended cipher suites.
== Kryptographisches Grundprinzip ==


This concludes the section on cipher strings. In theory, the reader should now be able to construct his or her own cipher string. However, the question why certain settings were chosen still remains. To answer this part, we need to look at recommended keylengths, problems in specific algorithms and hash functions and other cryptographic parameters. As mentioned initially in section [relatedPublications], the ENISA (ENISA and Vincent Rijmen, Nigel P. Smart, Bogdan warinschi, Gaven Watson, 2013), ECRYPT 2 (II & SYM, 2012) and BSI (für Sicherheit in der Informationstechnik (BSI), 2018) reports go much more into these topics and should be consulted in addition.
=== Umwandlung eines Klartextes  ===
* (p, plain text) in einem chiffrierten Text (c, ciphertext)
* mit Hilfe einer reversiblen kryptographischen Funktion f:


We try to answer the questions by explaining issues with random number generators (section Random Number Generators), keylengths (section Keylengths), current issues in ECC (section A note on Elliptic Curve Cryptography), a note of warning on SHA-1 (section A note on SHA-1) and some comments on Diffie Hellman key exchanges (section A note on Diffie Hellman Key Exchanges). All of this is important in understanding why certain choices were made for ''Cipher String A and B''. However, for most system administrators, the question of compatibility is one of the most pressing ones. Having the freedom to be compatible with any client (even running on outdated operating systems) of course, reduces the security of our cipher strings. We address these topics in section TODO. All these sections will allow a system administrator to balance his or her needs for strong encryption with usability and compatibility.
=== symmetrische und asymmetrische Algorithmen ===
* Kryptografie / Entschlüsselung
* Schlüssel als zusätzliches Argument zu Funktion f


Last but not least, we finish this chapter by talking about issues in PKIs (section Public Key Infrastructures), Certificate Authorities and on hardening a PKI. Note that these last few topics deserve a book on their own. Hence this guide can only mention a few current topics in this area.
== Verschlüsseln mit symmetrischen Verfahren ==


== 17. Cipher suites ==
=== Kryptografie und Entschlüsselung mit selbem Schlüssel ===
* DES, IDEA
* Effizient, aber Schlüsselaustauschproblem


=== 17.1. Architectural overview ===
=== Ver- und Entschlüsselung mit symmetrischer Kryptografie ===
This section defines some terms which will be used throughout this guide.


A cipher suite is a standardized collection of key exchange algorithms, encryption algorithms (ciphers) and Message authentication codes (MAC) algorithm that provides authenticated encryption schemes. It consists of the following components:
=== Symmetrische Substitution ===
=== Sender und Empfänger müssen den gleichen Schlüssel besitzen ===
* um miteinander Kommunizieren zu können
* Secret-Key-Verfahren
* Eignet sich gut, um große Datenmengen zu verschlüsseln
* Nachteil
* Um die Nachricht verwerten zu können, muss der Schlüssel mit übertragen werden
* was einen Schwachpunkt darstellt


; Key exchange protocol
=== Symmetrische Substitutionsverfahren ===
: "An (interactive) key exchange protocol is a method whereby parties who do not share any secret information can generate a shared, secret key by communicating over a public channel. The main property guaranteed here is that an eavesdropping adversary who sees all the messages sent over the communication line does not learn anything about the resulting secret key." (Katz & Lindell, 2008)  Example: <code>DHE</code>
; Authentication
: The client authenticates the server by its certificate. Optionally the server may authenticate the client certificate. Example: <code>RSA</code>
; Cipher
: The cipher is used to encrypt the message stream. It also contains the key size and mode used by the suite. Example: <code>AES256</code>
; Message authentication code (MAC)
: A MAC ensures that the message has not been tampered with (integrity). Example: <code>SHA256</code>
; Authenticated Encryption with Associated Data (AEAD)
: AEAD is a class of authenticated encryption block-cipher modes which take care of encryption as well as authentication (e.g. GCM, CCM mode). Example: <code>AES256-GCM</code>


Listing 46. Composition of a typical cipher string
=== Klassifizierungen ===
+-----+  +-----+  +--------+  +--------+
* Zeichenchiffren
| DHE +--+ RSA +--+ AES256 +--+ SHA256 +
* Blockchiffren
+-----+  +-----+  +--------+  +--------+
* Stromchiffren
{| class="wikitable"
* Zeichenchiffrierung
|
* Ermittelt jedes Zeichen des Geheimtextes aus dem entsprechenden Zeichen des Klartextes mit Hilfe des Schlüssels
|A note on nomenclature
* Cäsar-Addition
* Stromchiffrierung
* Der Klartext wird Byte-weise über eine XOR-Operation verschlüsselt
* Sie Erzeugt eine sich zyklisch verändernde Byte-Folge, die mit dem Klartext verknüpft wird
* Blockchiffrierung
* Klartext wird in Bitgruppen geteilt
* über mehrstufige Verfahren mit dem Schlüssel über gleichbleibende Operationen in Geheimtext umgewandelt
* DES


There are two common naming schemes for cipher strings – IANA names (see appendix Links) and the more well known OpenSSL names. In this document we will always use OpenSSL names unless a specific service uses IANA names.
== Asymmetrischer Kryptografie/public key-Kryptografie ==
|}
 
=== Public Key Kryptografie ===


=== 17.2. Forward Secrecy ===
=== Ver- und Entschlüsselung mit verschiedenen Schlüsseln ===
Forward Secrecy or Perfect Forward Secrecy is a property of a cipher suite that ensures confidentiality even if the server key has been compromised. Thus if traffic has been recorded it can not be decrypted even if an adversary has got hold of the server key.
* “Vergleichbar mit einem Briefkasten - jeder kann etwas hinein werfen, aber nur einer kann es herausnehmen.”
* Schlüssel-Paare: Öffentlicher und privater Schlüssel
* z.&nbsp;B.&nbsp;: RSA, ElGamal, Elliptische Kurven (ECC)
* Problem
* Meist ineffizienter als symmetrische Verfahren
* deshalb häufig nur zum Austausch symmetrischer Schlüssel und für Unterschriften
* Der private Schlüssel darf aus dem öffentlichen nicht errechenbar sein
* Einwegfunktion mit Falltür
* Nur unter Kenntnis einer zusätzlichen Information effizient umkehrbar
* z.&nbsp;B.&nbsp;x = loga y mod n (RSA-Verfahren) unter Kenntnis der Primfaktoren


* Forward secrecy (Wikipedia)
=== Asymmetrische Substitution ===
* Pushing for Perfect Forward Secrecy, an Important Web Privacy Protection (EFF)
* Es werden 2 komplementäre Schlüssel benötigt
* SSL: Intercepted today, decrypted tomorrow (Netcraft)
* 1 Key zum chiffrieren der Nachricht
* 2 Key zum dechiffrieren der Nachricht
* Einer der Schlüssel kann gefahrlos öffentlich bekannt gegeben werden (Public-Key)
* Wird mit einem Schlüssel chiffriert
* kann nur mit dem anderen Schlüssel dechiffriert werden


=== 17.3. Recommended cipher suites ===
=== Vorteile von Public-Key-Verfahren ===
* Jeder Kommunikationspartner benötigt einen Schlüssel
* seinen Private Key
* Der zweite Schlüssel wird veröffentlicht
* Nachteil
* Hohe Komplexität der durchzuführenden Operationen
* Die Multiplikation 2 Zahlen stellt eine einfache Operation dar
* während der umgekehrte Vorgang, also die Faktorzerlegung eines Produkts, einen enormen Rechenaufwand bedeuten kann


== 18. Recommended cipher suites ==
=== Absicherung der asymmetrischen Substitution ===
In principle system administrators who want to improve their communication security have to make a difficult decision between effectively locking out some users and keeping high cipher suite security while supporting as many users as possible. The web-site Qualys SSL Labs gives administrators and security engineers a tool to test their setup and compare compatibility with clients. The authors made use of ssllabs.com to arrive at a set of cipher suites which we will recommend throughout this document.
* Schwäche
{| class="wikitable"
* keine eindeutige Zuordnung des öffentlichen Schlüssels zu seinem Besitzer
|
* Ein „Man-in-the-Middle“ könnte sich dazwischen schalten und die Nachrichten unbemerkt entschlüsseln
|Caution
* Informationen des öffentlichen Schlüssels und seines Besitzers sollten aus vertrauenswürdiger Quelle stammen
* Möglichkeiten im Rahmen der Public Key Infrastructure (PKI)
* Schlüssel kann über ein sicher betrachtetes Medium übertragen werden
* Beispiel
* Persönliche Übergabe, Telefon, Brief, Fax
* Identität des Schlüsselinhabers Zertifizieren lassen


these settings can only represent a subjective choice of the authors at the time of writing. It might be a wise choice to select your own and review cipher suites based on the instructions in section [ChoosingYourOwnCipherSuites].
=== Trust Center ===
|}
==== Certification Authority [CA] ====
* Zertifizierungsinstanz (Trust Center)
* Zur Überprüfung der Schlüsselinhaber
* Sender und Empfänger verwalten Listen von Zertifizierungsinstanzen
* Überprüfung Zusammenhang öffentlicher Schlüssel und deren Absender
* Zertifikat nach ITU-Standard X.509
* ALTERNATIVE
* Authentizität eines öffentlichen Schlüssels durch einen bekannten Kommunikationspartner bestätigen lassen
* „Web of True“ von PGP


=== 18.1. Configuration A: Strong ciphers, fewer clients ===
== Substitution vs. Signatur ==
At the time of writing, our recommendation is to use the following set of strong cipher suites which may be useful in an environment where one does not depend on many, different clients and where compatibility is not a big issue. An example of such an environment might be machine-to-machine communication or corporate deployments where software that is to be used can be defined without restrictions.
* Algorithmen asymetrischer Kryptografieen unterscheiden sich
* ob eine Nachricht verschlüsselt oder signiet werden soll


We arrived at this set of cipher suites by selecting:
=== Substitution ===
* Absender verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des Empfängers
* so, dass er sie mit seinem privaten Schlüssel wieder im Klartext lesen kann


* TLS 1.2
=== Signatur ===
* Perfect forward secrecy / ephemeral Diffie Hellman
* Absender erzeugt mit seinem privatem Schlüssel eine Signatur
* strong MACs (SHA-2) or
* Empfänger kann durch Verwendung des öffentlichen Schlüssel des Absenders die Nachricht verifiziert
* GCM as Authenticated Encryption scheme


This results in the OpenSSL string: <code>EDH+aRSA+AES256:EECDH+aRSA+AES256:!SSLv3</code>
== Tunneling ==
siehe [[Kryptografie/Tunneling]]


Table 14. Configuration A ciphers
= Wie baut man eine sicheren Block Cipher? =
{| class="wikitable"
=== Probleme bei der Entwicklung von Kryptografieverfahren ===
!ID
{| class="wikitable sortable options"
!OpenSSL Name
!Version
!KeyEx
!Auth
!Cipher
!MAC
|-
|-
|'''0x009F'''
| [[Vertraulichkeit]] || Schutz der Daten vor unberechtigter Einsichtnahme
|DHE-RSA-AES256-GCM-SHA384
|TLSv1.2
|DH
|RSA
|AESGCM(256)
|AEAD
|-
|-
|'''0x006B'''
| [[Authentisierung]] || Sicherstellung der Herkunft, Verbindlichkeit
|DHE-RSA-AES256-SHA256
|TLSv1.2
|DH
|RSA
|AES(256) (CBC)
|SHA256
|-
|-
|'''0xC030'''
| [[Anonymität]] || Schutz vor Bekanntwerden des Absenders und Empfängers
|ECDHE-RSA-AES256-GCM-SHA384
|TLSv1.2
|ECDH
|RSA
|AESGCM(256)
|AEAD
|-
|-
|'''0xC028'''
| [[Integrität]] || Unveränderlichkeit von Daten und Verlässlichkeit von Programmen
|ECDHE-RSA-AES256-SHA384
|TLSv1.2
|ECDH
|RSA
|AES(256) (CBC)
|SHA384
|}
|}
{| class="wikitable"
|
|Compatibility


At the time of this writing only Win 7 and Win 8.1 crypto stack, OpenSSL >= 1.0.1e, Safari 6 / iOS 6.0.1 and Safari 7 / OS X 10.9 are covered by that cipher string.
== Mary Stuart 1516 - 1558 ==
|}
Bekanntes Opfer der Kryptoanalye
 
== Shannon‘s Principle of Confusion ==
Substitution Cipher
 
== Shannon‘s Principle of Diffusion ==
Transposition Cipher
 
== Symmetrische Kryptografieverfahren ==
=== Einfachster Einsatz  ===
* basiert auf der logischen Exklusiv-Oder-Funktion
* 2 XOR Verknüpfung eines A Zeichens mit einem B hat wieder das ursprüngliche Zeichen A zum Ergebnis
* Es entspricht also der Inversen Verknüpfung:
* (A+B)+B=A+(B+B)Assoziativgesetz=A+0Eigenschaft von XOR=AEigenschaft von XOR
* Der Sender verschlüsselt ein Zeichen A mit einem Schlüssel B per XOR und versendet das Ergebnis
* Der Empfänger verknüpft das Ergebnis erneut mit Schlüssel B und erhält dann wieder das Zeichen A
 
=== Symmetric Algorithms: Block Ciphers ===
 
=== Some Popular Block Ciphers ===
 
== Symmetric Algorithms: Stream Ciphers ==
 
= RC4 =
=== RC Rivest Cipher  ===
* Stromverschlüsselungsverfahren
* Basiert auf XOR-Verknüpfung
* Sehr schnell und einfach
* Eignet sich gut in Software
* Der Algorythmus macht aus dem eingegebenen Schlüssel S einen langen, pseudo-zufälligen internen Schlüssel P
* Dieser wird zur Chiffrierung des Klartextes verwendet
* RC4 Speichert 258 verschiedene Zusatzinformationen
* 256 sind Permutationen von 0-255 und somit gleich verteilt
 
= DES =
=== Familie der Blockchiffren ===
* Teilt eine Nachricht in 64 Bit große Datenblöcke
* 3 bearbeitungsschritte werden benötigt, um den Klartext wieder herzustellen.
* Am weitesten verbreiteter Algorythmus, auch wenn nicht mehr ganz Zeitgemäß
* Nachfolger: 3DES
* Wird in Finanzdienstleistungen eingesetzt und führt die Kryptografie 3 mal hintereinander aus
 
=== Data Encryption Standard (DES)Sicherheit von DES ===
* DES
* erlaubt mit 56 Bit Schlüssellänge
* 72 Billiarden mögliche Schlüssel
* ist heute nicht mehr ausreichend
* per Brute-Force in 5 Tagen (?) geknackt
 
== Permutation ==
* DES besteht aus 3 Bearbeitungsschritten
* Initiale Permutation
* Ver-/Entschlüsselung in mehreren Runden
* finale Permutation
* DES wurde in den 70er Jahren zur Implementation in Hardware entwickelt
* durch die damals noch kleinen CPU Register
* Finale Permutation = Inverse der initialen Permutation
* Nach der Durchführung der initialen und finalen Permutation, steht ein Bit wieder an ursprünglicher Stelle
 
; Kryptografie
* DES basiert auf einer 64 Bit Kryptografie
* wovon jedoch nur 56 Bit kryptographisch relevant sind
* Jedes 8 Bit = Parity-Bit
* DES erzeugt 16 verschiedene 48 Bit lange Schlüssel
* Es werden aus 56 relevanten Bit mit einer Permutation 2 28 Bit Muster generiert (C[i-1] und D[i-1]).
* Die Teilschlüssel werden nun um 1 oder 2 Bit nach links rotiert.
* Die erzeugten Schlüssel C[i] und D[i] werden zu C[i-1] und D[i-1].
* 2 24Bit Folgen aus C[i] und D[i] werden zum Schlüssel K[n]
 
== Kryptografie ==
* DES teilt den Klartext in 64 Bit Blöcke und
* splittet sie nochmal in 2 32 Bit lange Bestandteile (L[n] und R[n]).
* R[n] wird über eine Mangler-Funktion ,mittels tabellenbasierter Umrechnung auf Grundlage der Eingangsvariable R[n] und des Schlüssels K[n], vermischt.
 
== Genügen 128 Bit? ==
* IDEA
* International Data Encryption Algorithm
* arbeitet mit 128 Bit Schlüssellänge, sonst ähnlich wie der DES
* 3.43669 * 1038
* knacken benötigt etwa 1012 Jahre
* Daher gilt der IDEA heute als sicher
 
== Asymmetrische Kryptografieverfahren ==
 
=== Setzen auf 2 unterschiedliche Schlüssel ===
* Privater Schlüssel (privat key) [Dechiffriert-Algorythmisch]
* Öffentlicher Schlüssel (public key) [Chiffriert-Algorythmisch]
* Es lässt sich nicht vom public key auf den private key schließen
* Der public key kann von Dritten zur Kryptografie von Informationen genutzt werden
* die der Besitzer des private keys nur entschlüsseln kann
 
=== Bekanntester Vertreter ===
* RSA-Algorythmus
* Die Multiplikation 2er Zahlen stellt eine einfache Operation dar
* während der umgekehrt Vorgang eine enorme Rechenleistung bedeutet
 
= RSA =
=== Basiert auf folgenden 4 Schritten ===
* Wähle 2 große Primzahlen p und q, die geheim bleiben
* Berechne das Produkt n = p*q
* Für öffentlichen Schlüssel wähle e < n
* die teilerfremd zur Eulerschen Funktion E(n) = (p-1)*(q-1) ist
* Für privaten Schlüssel bestimme eine Zahl
* d = e^-1 mod E(n)
* Dann gilt
* e*d = 1 mod E(n)
* [d,n] ist der private Schlüssel
 
=== Algorithmus bei der Kryptografie ===
* Alice verschlüsselt
* ihren Klartext m gemäß c = m^e mod n und
* sendet ihn an Bob.
* In diesem Fall ist [e,n] der öffentliche Schlüssel von Bob
* Bob entschlüsselt
* den Geheimtext c mit seinem privaten Schlüssel [d,n] gemäß m = c^d mod n
* und erhält auf Grund des Zusammenhangs von d und e den Klartext m
 
* Der Empfänger führt bei der Entschlüsselung die gleiche Operation wie der Sender bei der Kryptografie durch
* Algorythmus zur Erzeugung und Überprüfung von Signaturen
* Alice sendet eine signierte Nachricht, indem sie s = m^d mod n erzeugt und überträgt
* [d,n] = Privater Schlüssen von Alice
* Bob entschlüsselt die Signatur gemäß m = s^e mod n und erhält auf Grund des Zusammenhangs von d und e den Klartext m
* [e,n] = öffentlicher Schlüssel von Alice
 
= Advanced Encryption Standard =
* Nachfolgestandard für DES
* 3DES mit 128 Bit gilt noch als sicher
* wegen der Dreifachverschlüsselung deutlich langsamer als AES
* AES unterstützt 128, 192 und 256 Bit lange Schlüssel
* Beispiel Hamachi
* AES mit 256 Bit Schlüssellänge
* im Modus Cipher-Block-Chaining
 
== Advanced Encryption Standard (AES)http://www.nist.gov/aes ==
* DES is nearly 25 years old!
* Triple DES with a 168 bit key is the current Federal Information Processing Standard FIPS 46-3 (renewed in October 1999).
* Single DES with 56 bit key is permitted for legacy systems only.
* Evaluation of an Advanced Encryption Standard
* The National Institute of Standards and Technology (NIST,U.S. Department of Commerce) started a public contest in 1997.
* 5 final candidate algorithms. Decision by NIST in Spring 2001
* Requirements for AES
* AES shall be publicly defined.
* AES shall be a symmetric block cipher.
* AES shall be implementable in both hardware and software.
* AES shall be designed so that the key length may be increased as needed.
* AES block size n = 128 bits, key size k = 128, 192, 256 bits
 
== AES Round 2 Finalists ==
* MARS(IBM)
* Modified Feistel Network - 32 Rounds
* Based on Mixed Structure DES
* RC6 (RSA)
* Feistel Network - 20 Rounds
* Based on Modified RC5
* Rijndal(Joan Daemen / Vincent Rijmen)
* Modified Substitution Permutation Network - 10 Rounds
* Based on Square
* Serpent (Ross Anderson / Eli Biham / Lars Knudsen)
* Substitution Permutation Network - 32 Rounds
* Based on Bitlice Operations
* Twofish(Bruce Schneier)
* Feistel Network - 16 Rounds
* Based on Modified Blowfish
 
== Cipher Block Chaining (CBC) ==
* Um eine Frquenzanalyse zu verhindern wird eine Verkettung von Datenblöcken durchgeführt
* Dabei wird der zu verschlüsselnde Datenblock exklusiv mit dem letzten verschlüsselten Datenblock verknüpft
* Gleiche Datenblöcke werden so unterschiedlich modifiziert und unterschiedlich verschlüsselt
* Problem: Erste Datenblock
* Erzeugung eines Initialisierungs-Vekros (IV)
* Der IV wird zur Entschlüsselung benötigt
* daher wird er dem Empfänger übermittelt
* Vertraulichkeit ist nicht erforderlich
* IPsec – Protokolle übertragen den IV in jedem Datenpaket
 
== Advanced Encryption Standard ==
=== CBC-Mode Entstehung von Mustern ===
* Rückschlüsse auf den Klartext
* Anders als der ECB-Mode (Electronic Code Book) verhindert der CBC-Mode (Cipher Block Chaining) bei Kryptografiealgorithmen die Entstehung von Mustern im Chiffrat,
* Dazu lässt CBC das Ergebnis der vorherigen Blockoperation in die aktuelle einfließen (Chaining)
* Sowohl ECB als auch CBC sind für so genannte Bit-Flipping-Attacken anfällig
* Angreifer versucht im Chiffrat einzelne Bit manipulieren
* ohne Kenntnis des Schlüssels
* ohne später beim Entschlüsseln durch den Empfänger einen Fehler zu provozieren
* auch für verschlüsselte Pakete die Integrität gesichert werden, etwa mit HMAC
* Da sich so der Inhalt manipulieren lässt
* In CBC werden jeweils Blöcke von jeweils 16 Datenbytes verschlüsselt
* Das CBC-Verfahren initialisiert mit einem zufällig gewählten 128 Bit langen Initialisierungsvektor
* wird bei ESP-Paket den chiffrierten Nutzdaten vorangestellt
* Da Daten blockweise verschlüsselt werden
* muss der letzte Datenblock mit Füll-Bytes zur vollen Blocklänge aufgefüllt
* die Anzahl dieser Stopf-Bytes wird im Längen-Byte festgehalten
 
== Vergleich: AES und 3DES ==
 
= IDEA =
=== Familie der Blockchiffrierung ===
* jedoch wendet er 128 Bit Schlüssel auf 64 Bit Datenpakete des Klartextes an
* Basiert auf einer Mischung 3 mathematischen Funktionen
* die jeweils auf 16 Bit Blöcke des Testes angewandt werden.
* Neben XOR kommt die Addition modulo 2^16 und die Multiplikation modulo 2^16+1 zum Einsatz
* Alle 3 Operationen werden zu einem recht komplizierten Netzwerk verknüpft, das 8 Runden durchlaufen wird
* Trotz komplizierter Verfahren, schneller und sicherer als DES
 
== Hybride Kryptografieverfahren ==
 
=== Vorteile aus asymmetrischen und symmetrischen Kryptografie  ===
* Hohe Effizienz
* gesteigerte Sicherheit
* Flexibilität
* Austausch der erforderlichen Schlüssel
* erfolgt über ein asymmetrisches Verfahren
* Kryptografie größerer Datenmengen
* kommen symetrische Algorythmen zum Einsatz
 
== Vergleich Klassisch - Modern ==
 
=== Sowohl die klassischen Verfahren wie Vigenère als auch die modernen Verfahren wie IDEA… ===
* …benötigen einen Schlüssel der beiden Parteien im Vornherein bekannt ist
* …sind symmetrisch (Entschlüsselung ist Umkehrung der Kryptografie)
* …sind in gewissen Masse anfällig auf Kryptoanalyse (z.&nbsp;B.&nbsp;Brute-Force)
 
== Fazit ==
 
=== Die Geschichte der Kryptografie ist ein Wettbewerb  ===
* zwischen Kryptografiespezialisten und Kryptoanalysten
* Momentan liegen die Verschlüssler mit dem IDEA vorne
* da dieses Verfahren nur mit Brute-Force geknackt werden kann
* dies wegen der großen Schlüssellänge auch auf modernsten Computern noch zu lange dauert
 
= TMP =
=== Abstract ===
* Unfortunately, the computer security and cryptology communities have drifted apart over the last 25 years. Security people don’t always understand the available crypto tools, and crypto people don’t always understand the real-world problems.
* — Ross Anderson ''([https://bettercrypto.org/#bibliography-default-anderson2008security Anderson, 2008])''
* This guide arose out of the need for system administrators to have an updated, solid, well researched and thought-through guide for configuring SSL, PGP, SSH and other cryptographic tools in the post-Snowden age. Triggered by the NSA leaks in the summer of 2013, many system administrators and IT security officers saw the need to strengthen their encryption settings. This guide is specifically written for these system administrators.
* As Schneier noted in ([https://bettercrypto.org/#bibliography-default-Sch13 Schneier, 2013]), it seems that intelligence agencies and adversaries on the Internet are not breaking so much the mathematics of encryption per se, but rather use software and hardware weaknesses, subvert standardization processes, plant backdoors, rig random number generators and most of all exploit careless settings in server configurations and encryption systems to listen in on private communications. Worst of all, most communication on the internet is not encrypted at all by default (for SMTP, opportunistic TLS would be a solution).
* This guide can only address one aspect of securing our information systems: getting the crypto settings right to the best of the authors' current knowledge. Other attacks, as the above mentioned, require different protection schemes which are not covered in this guide. This guide is not an introduction to cryptography. For background information on cryptography and cryptoanalysis we would like to refer the reader to the references in appendix [https://bettercrypto.org/#links Links] and [https://bettercrypto.org/#suggested_reading Suggested Reading] at the end of this document.
* The focus of this guide is merely to give current ''best practices for configuring complex cipher suites'' and related parameters in a ''copy & paste-able manner''. The guide tries to stay as concise as is possible for such a complex topic as cryptography. Naturally, it can not be complete. There are many excellent guides ([https://bettercrypto.org/#bibliography-default-ii2011ecrypt II & SYM, 2012]) and best practice documents available when it comes to cryptography. However none of them focuses specifically on what an average system administrator needs for hardening his or her systems' crypto settings.
* This guide tries to fill this gap.
 
; The guide was produced in an open source manner: every step of editing can be traced back to a specific author via our version control system.
 
== Introduction ==
=== Audience ===
Sysadmins. Sysadmins. Sysadmins. They are a force-multiplier.
 
=== Related publications ===
* Ecrypt II [https://bettercrypto.org/#ii2011ecrypt [ii2011ecrypt]]
* Ecrypt II ([https://bettercrypto.org/#bibliography-default-ii2011ecrypt II & SYM, 2012]), ENISA’s report on Algorithms, key sizes and parameters ([https://bettercrypto.org/#bibliography-default-ENISA2013 ENISA and Vincent Rijmen, Nigel P. Smart, Bogdan warinschi, Gaven Watson, 2013])&nbsp;and BSI’s Technische Richtlinie TR-02102 ([https://bettercrypto.org/#bibliography-default-TR02102 für Sicherheit in der Informationstechnik (BSI), 2018]) are great publications which are more in depth than this guide. However, this guide has a different approach: it focuses on ''copy & paste-able settings'' for system administrators, effectively breaking down the complexity in the above mentioned reports to an easy to use format for the intended target audience.
 
=== How to read this guide ===
* This guide tries to accommodate two needs: first of all, having a handy reference on how to configure the most common services’ crypto settings and second of all, explain a bit of background on cryptography. This background is essential if the reader wants to choose his or her own cipher string settings.
* System administrators who want to copy & paste recommendations quickly without spending a lot of time on background reading on cryptography or cryptanalysis can do so, by simply searching for the corresponding section in [https://bettercrypto.org/#bestpractice Best Practice].
* It is important to know that in this guide the authors arrived at two recommendations: ''Cipher string A'' and ''Cipher string B''. While the former is a hardened recommendation a latter is a weaker one but provides wider compatibility. ''Cipher strings A and B'' are described in [https://bettercrypto.org/#recommendedciphers Recommended cipher suites].
* However, for the quick copy & paste approach it is important to know that this guide assumes users are happy with ''Cipher string B''.
* While [https://bettercrypto.org/#bestpractice Best Practice] is intended to serve as a copy & paste reference, [https://bettercrypto.org/#theory Theory] explains the reasoning behind ''cipher string B''. In particular [https://bettercrypto.org/#ciphersuites Architectural overview] explains how to choose individual cipher strings. We advise the reader to actually read this section and challenge our reasoning in choosing ''Cipher string B'' and to come up with a better or localized solution.


=== 18.2. Configuration B: Weaker ciphers but better compatibility ===
=== Disclaimer ===
In this section we propose a slightly weaker set of cipher suites. For example, there are known weaknesses for the SHA-1 hash function that is included in this set. The advantage of this set of cipher suites is not only better compatibility with a broad range of clients, but also less computational workload on the provisioning hardware.
* A chain is no stronger than its weakest link, and life is after all a chain.
* — William James
*  Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it.
* — Edward Snowden ''answering questions live on the Guardian’s website''
* This guide specifically does not address physical security, protecting software and hardware against exploits, basic IT security housekeeping, information assurance techniques, traffic analysis attacks, issues with key-roll over and key management, securing client PCs and mobile devices (theft, loss), proper [https://en.wikipedia.org/wiki/Operations_security Operations Security], social engineering attacks, protection against tempest ([https://bettercrypto.org/#bibliography-default-Wikipedia:Tempest i_wikipedia_Tempest (codename)_, 2018])&nbsp;attack techniques, thwarting different side-channel attacks (timing–, cache timing–, differential fault analysis, differential power analysis or power monitoring attacks), downgrade attacks, jamming the encrypted channel or other similar attacks which are typically employed to circumvent strong encryption.
* The authors can not overstate the importance of these other techniques. Interested readers are advised to read about these attacks in detail since they give a lot of insight into other parts of cryptography engineering which need to be dealt with[[https://bettercrypto.org/#_footnotedef_1 1]]) ].
* This guide does not talk much about the well-known insecurities of trusting a public-key infrastructure (PKI)[[https://bettercrypto.org/#_footnotedef_2 2]]. Nor does this text fully explain how to run your own Certificate Authority (CA).
* Most of this zoo of information security issues are addressed in the very comprehensive book ''Security Engineering'' by Ross Anderson ([https://bettercrypto.org/#bibliography-default-anderson2008security Anderson, 2008]).
* For some experts in cryptography this text might seem too informal. However, we strive to keep the language as non-technical as possible and fitting for our target audience: system administrators who can collectively improve the security level for all of their users.
*  Security is a process, not a product.
* — Bruce Schneier
* This guide can only describe what the authors currently ''believe'' to be the best settings based on their personal experience and after intensive cross checking with literature and experts. For a complete list of people who reviewed this paper, see the <acknowledgements>. Even though multiple specialists reviewed the guide, the authors can give ''no guarantee whatsoever'' that they made the right recommendations. Keep in mind that tomorrow there might be new attacks on some ciphers and many of the recommendations in this guide might turn out to be wrong. Security is a process.
* We therefore recommend that system administrators keep up to date with recent topics in IT security and cryptography.
* In this sense, this guide is very focused on getting the cipher strings done right even though there is much more to do in order to make a system more secure. We the authors, need this document as much as the reader needs it.


'''All examples in this publication use Configuration B'''.
==== Scope ====
In this guide, we restricted ourselves to:* Internet-facing services
* Commonly used services
* Devices which are used in business environments (this specifically excludes XBoxes, Playstations and similar consumer devices)
* OpenSSL
We explicitly excluded:* Specialized systems such as medical devices, most embedded systems, industrial control systems (ICS), etc.
* Wireless Access Points
* Smart-cards/chip cards


We arrived at this set of cipher suites by selecting:
=== Methods ===
#  C.O.S.H.E.R - completely open source, headers, engineering and research.
# — A. Kaplan ''His mail signature for many years''
# For writing this guide, we chose to collect the most well researched facts about cryptography settings and let as many trusted specialists as possible review those settings. The review process is completely open and done on a public mailing list.
# The document is available (read-only) to the public Internet on the web page and the source code of this document is on a public git server, mirrored on GitHub.com and open for public scrutiny. However, write permissions to the document are only granted to vetted people. The list of reviewers can be found in [https://bettercrypto.org/#acknowledgements Acknowledgements].
# Every write operation to the document is logged via the <tt>git</tt> version control system and can thus be traced back to a specific author. We accept git pull requests on the [https://github.com/BetterCrypto/Applied-Crypto-Hardening github mirror] for this paper.
# Public peer-review and multiple eyes checking of our guide is the best strategy we can imagine at the present moment [[https://bettercrypto.org/#_footnotedef_3 3]].
# We invite the gentle reader to participate in this public review process. Please read the [https://github.com/BetterCrypto/Applied-Crypto-Hardening/blob/master/CONTRIBUTING.md Contributing] document.


* TLS 1.2, TLS 1.1, TLS 1.0
== Appendix ==
* allowing SHA-1 (see the comments on SHA-1 in section [SHA])
=== Links ===
# [https://www.iana.org/assignments/tls-parameters/tls-parameters.txt IANA official list of Transport Layer Security (TLS) Parameters]
# [https://www.imperialviolet.org/2010/12/04/ecc.html Elliptic curves and their implementation (04 Dec 2010)]
# [https://arstechnica.com/information-technology/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ A (relatively easy to understand) primer on elliptic curve cryptography]
# [https://github.com/ioerror/duraconf Duraconf, A collection of hardened configuration files for SSL/TLSservices (Jacob Appelbaum’s github)]
# [https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/ssl_attacks_survey.pdf Attacks on SSL a comprehensive study of BEAST, CRIME, TIME, BREACH, LUCKY 13 & RC4 Biases]
# [https://www.eff.org/https-everywhere/deploying-https EFF How to deploy HTTPS correctly]
# [https://www.computerworld.com.au/article/46254/bruce_almighty_schneier_preaches_security_linux_faithful/?pp=3 Bruce Almighty: Schneier preaches security to Linux faithful (on not recommending to use Blowfish anymore in favor of Twofish)]
# [https://bugzilla.mindrot.org/show_bug.cgi?id=1647 Implement FIPS 183-3 for DSA keys (1024bit constraint)]
# [https://eprint.iacr.org/2013/734.pdf Elliptic Curve Cryptography in Practice]
# [https://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf Factoring as a Service]
# [https://dankaminsky.com/2012/08/06/bo2012/ Black Ops of TCP/IP 2012]
# [https://www.youtube.com/watch?v=Z7Wl2FW2TcA SSL and the Future of Authenticity, Moxie Marlinspike - Black Hat USA 2011]
# [https://www.enisa.europa.eu/publications/algorithms-key-sizes-and-parameters-report ENISA - Algorithms, Key Sizes and Parameters Report (Oct.’13]
# [https://tools.ietf.org/html/rfc3526 Diffie-Hellman Groups standardized in RFC3526]
# [https://www.cosic.esat.kuleuven.be/ecc2013/files/kenny.pdf TLS Security (Survey + Lucky13 + RC4 Attack) by Kenny Paterson]
# [https://arxiv.org/abs/1309.7366v1 Ensuring High-Quality Randomness in Cryptographic Key Generation]
# [https://en.wikipedia.org/wiki/Ciphertext_stealing Wikipedia: Ciphertext Stealing]
# [https://en.wikipedia.org/wiki/Malleability_(cryptography) Wikipedia: Malleability (Cryptography)]
# [http://www.ciphersbyritter.com/GLOSSARY.HTM Ritter’s Crypto Glossary and Dictionary of Technical Cryptography]


This results in the OpenSSL string:
=== Suggested Reading ===
# This section contains suggested reading material.
# Cryptography Engineering: Design Principles and Practical Applications, Ferguson, N. and Schneier, B. and Kohno, T. (ISBN-13: 978-0470474242)
# Security Engineering: A Guide to Building Dependable Distributed Systems, Anderson, R.J. (ISBN-13: 978-0470068526)
# Applied cryptography: protocols, algorithms, and source code in C, Schneier, B. (ISBN-13: 978-0471117094)
# Guide to Elliptic Curve Cryptography, Hankerson, D. and Vanstone, S. and Menezes, A.J. (ISBN-13: 978-0387952734)
# A Introduction To The Theory of Numbers, Godfrey Harold Hardy, E. M. Wrigh (ISBN-13: 978-0199219865)
# Malicious Cryptography: Exposing Cryptovirology, Young A., Yung, M. (ISBN-13: 978-0764549755)


<code>'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'</code>
=== Further Research ===
The following is a list of services, software packages, hardware devices or protocols that we considered documenting but either did not manage to document yet or might be able to document later. We encourage input from the community.


Table 15. Configuration B ciphers
; Further Protocols
{| class="wikitable"
{| style="border-spacing:0;width:14.018cm;"
!ID
|- style="border:none;padding:0.049cm;"
!OpenSSL Name
|| DNSSec (mention BCPs)
!Version
|| DANE
!KeyEx
|| Tor
!Auth
|- style="border:none;padding:0.049cm;"
!Cipher
|| S/Mime (check are there any BCPs? )
!MAC
|| TrueCrypt, LUKS, FileVault
|| AFS
|- style="border:none;padding:0.049cm;"
|| Kerberos
|| NNTP
|| NTPs tlsdate
|- style="border:none;padding:0.049cm;"
|| Moxa , APC, und co…​ ICS
||
||
|- style="border:none;padding:0.049cm;"
|| rsyslog
|| tftp
|| (s)ftp(s)
|- style="border:none;padding:0.049cm;"
|| haproxy
||
||
|-
|-
|'''0x009F'''
|}
|DHE-RSA-AES256-GCM-SHA384
 
|TLSv1.2
; Further Protocols (Network centric)
|DH
{| style="border-spacing:0;width:9.917cm;"
|RSA
|- style="border:none;padding:0.049cm;"
|AESGCM(256)
|| IPv6 security
|AEAD
||
||
|- style="border:none;padding:0.049cm;"
|| Wi-Fi, 802.1x
|| SIP
|| SRTP
|- style="border:none;padding:0.049cm;"
|| Kerberos
|| NNTP
|| NTPs tlsdate
|- style="border:none;padding:0.049cm;"
|| BGP / OSPF
|| LDAP
|| seclayer-tcp
|- style="border:none;padding:0.049cm;"
|| RADIUS (RADSEC)
|| racoon
|| strongswan
|- style="border:none;padding:0.049cm;"
|| l2tp
||
||
|- style="border:none;padding:0.049cm;"
|| Ethernet to serial
|| DSL modems
||
|- style="border:none;padding:0.049cm;"
|| UPnP, natPmp
||
||
|- style="border:none;padding:0.049cm;"
|| HTTP Key Pinning (HTKP)
||
||
|- style="border:none;padding:0.049cm;"
|| Monitoring: SNMPv3
||
||
|-
|-
|'''0x006B'''
|}
|DHE-RSA-AES256-SHA256
 
|TLSv1.2
; Further Applications
|DH
{| style="border-spacing:0;width:7.853cm;"
|RSA
|- style="border:none;padding:0.049cm;"
|AES(256)
|| Lync
|SHA256
|| Tomcat
|-
||
|'''0xC030'''
|- style="border:none;padding:0.049cm;"
|ECDHE-RSA-AES256-GCM-SHA384
|| Microsoft SQL Server
|TLSv1.2
|| Microsoft Exchange
|ECDH
||
|RSA
|- style="border:none;padding:0.049cm;"
|AESGCM(256)
|| IBM HTTP Server
|AEAD
||
|-
||
|'''0xC028'''
|ECDHE-RSA-AES256-SHA384
|TLSv1.2
|ECDH
|RSA
|AES(256)
|SHA384
|-
|'''0x009E'''
|DHE-RSA-AES128-GCM-SHA256
|TLSv1.2
|DH
|RSA
|AESGCM(128)
|AEAD
|-
|'''0x0067'''
|DHE-RSA-AES128-SHA256
|TLSv1.2
|DH
|RSA
|AES(128)
|SHA256
|-
|'''0xC02F'''
|ECDHE-RSA-AES128-GCM-SHA256
|TLSv1.2
|ECDH
|RSA
|AESGCM(128)
|AEAD
|-
|'''0xC027'''
|ECDHE-RSA-AES128-SHA256
|TLSv1.2
|ECDH
|RSA
|AES(128)
|SHA256
|-
|'''0x0088'''
|DHE-RSA-CAMELLIA256-SHA
|SSLv3
|DH
|RSA
|Camellia(256)
|SHA1
|-
|'''0x0039'''
|DHE-RSA-AES256-SHA
|SSLv3
|DH
|RSA
|AES(256)
|SHA1
|-
|'''0xC014'''
|ECDHE-RSA-AES256-SHA
|SSLv3
|ECDH
|RSA
|AES(256)
|SHA1
|-
|'''0x0045'''
|DHE-RSA-CAMELLIA128-SHA
|SSLv3
|DH
|RSA
|Camellia(128)
|SHA1
|-
|'''0x0033'''
|DHE-RSA-AES128-SHA
|SSLv3
|DH
|RSA
|AES(128)
|SHA1
|-
|'''0xC013'''
|ECDHE-RSA-AES128-SHA
|SSLv3
|ECDH
|RSA
|AES(128)
|SHA1
|-
|-
|'''0x0084'''
|CAMELLIA256-SHA
|SSLv3
|RSA
|RSA
|Camellia(256)
|SHA1
|-
|'''0x0035'''
|AES256-SHA
|SSLv3
|RSA
|RSA
|AES(256)
|SHA1
|-
|'''0x0041'''
|CAMELLIA128-SHA
|SSLv3
|RSA
|RSA
|Camellia(128)
|SHA1
|-
|'''0x002F'''
|AES128-SHA
|SSLv3
|RSA
|RSA
|AES(128)
|SHA1
|}
|}
{| class="wikitable"
|
|Compatibility


Note that these cipher suites will not work with Windows XP’s crypto stack (e.g. IE, Outlook),
;Commerical Network Equipment Vendors
|}
Other ideas:
{| class="wikitable"
* SAML federated auth providers [[https://bettercrypto.org/#_footnotedef_42 42]]
|
* Elastic Load Balancing (ELB)[[https://bettercrypto.org/#_footnotedef_43 43]]
|Explanation
 
==== Software not covered by this guide ====
# telnet: Usage of telnet for anything other than fun projects is highly discouraged
# Puppet DB: A Proxy or a tunnel is recommended if it needs to be facing public network interfaces.[[https://bettercrypto.org/#_footnotedef_44 44]]
# rsync: Best use it only via SSH for an optimum of security and easiest to maintain.
 
=== Bibliography ===
# Adam Langley, Ben Laurie, Emilia Kasper. (2013). Certificate Transparency. [http://www.certificate-transparency.org/ http://www.certificate-transparency.org] [https://datatracker.ietf.org/doc/rfc6962/ https://datatracker.ietf.org/doc/rfc6962/] .
# Adam Langley, et. al. (2013). Go X.509 Verification Source Code. [https://code.google.com/p/go/source/browse/src/pkg/crypto/x509/verify.go#173 https://code.google.com/p/go/source/browse/src/pkg/crypto/x509/verify.go#173] .
# Anderson, R. (2008). ''Security engineering''. Wiley.com. Retrieved from [http://www.cl.cam.ac.uk/ rja14/book.html http://www.cl.cam.ac.uk/ rja14/book.html]
# Bernstein, D. J., & Lange, T. (2013). ''Security dangers of the NIST curves'' (Presentation slides). Retrieved from [http://cr.yp.to/talks/2013.09.16/slides-djb-20130916-a4.pdf http://cr.yp.to/talks/2013.09.16/slides-djb-20130916-a4.pdf]
# C. Evans and C. Palmer. (2013). Public Key Pinning Extension for HTTP. [https://tools.ietf.org/html/draft-ietf-websec-key-pinning-09 https://tools.ietf.org/html/draft-ietf-websec-key-pinning-09] .
# Damon Poeter. (2011). Fake Google Certificate Puts Gmail at Risk. [http://www.pcmag.com/article2/0,2817,2392063,00.asp http://www.pcmag.com/article2/0,2817,2392063,00.asp] .
# Durumeric, Z., Kasten, J., Bailey, M., & Halderman, J. A. (2013). Analysis of the HTTPS Certificate Ecosystem. In ''Proceedings of the 13th Internet Measurement Conference''. Retrieved from [https://jhalderm.com/pub/papers/https-imc13.pdf https://jhalderm.com/pub/papers/https-imc13.pdf]
# Elinor Mills. (2011). Fraudulent Google certificate points to Internet attack. [http://news.cnet.com/8301-27080_3-20098894-245/fraudulent-google-certificate-points-to-internet-attack/ http://news.cnet.com/8301-27080_3-20098894-245/fraudulent-google-certificate-points-to-internet-attack/] .
# Engblom, J. (2011). ''Evaluating HAVEGE Randomness'' (Blog: Observations from Uppsala). Retrieved from [http://jakob.engbloms.se/archives/1374 http://jakob.engbloms.se/archives/1374]
# ENISA and Vincent Rijmen, Nigel P. Smart, Bogdan warinschi, Gaven Watson. (2013). ''ENISA - Algorithms, Key Sizes and Parameters Report''. Retrieved from [http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report]
# für Sicherheit in der Informationstechnik (BSI), B. (2018). ''BSI TR-02102 Kryptographische Verfahren''. Retrieved from [https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/tr02102_node.html https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/tr02102_node.html]
# H. Tschofenig and E. Lear. (2013). Evolving the Web Public Key Infrastructure. [https://tools.ietf.org/html/draft-tschofenig-iab-webpki-evolution-01.txt https://tools.ietf.org/html/draft-tschofenig-iab-webpki-evolution-01.txt] .
# Heninger, N., Durumeric, Z., Wustrow, E., & Halderman, J. A. (2012). Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices. In ''Proceedings of the 21st USENIX Security Symposium''. Retrieved from [https://factorable.net/weakkeys12.extended.pdf https://factorable.net/weakkeys12.extended.pdf]
# Hoffman, P., & Schlyter, J. (2012). The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. IETF. Retrieved from [https://www.ietf.org/rfc/rfc6698.txt https://www.ietf.org/rfc/rfc6698.txt]
# i_mit_Realm configuration decisions_. (2013). (Documentation). Retrieved from [http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html]
# i_wikipedia_Discrete logarithm_. (2013). (Wikipedia). Retrieved from [https://en.wikipedia.org/wiki/Discrete_logarithm https://en.wikipedia.org/wiki/Discrete_logarithm]
# i_wikipedia_Tempest (codename)''. (2018). (Wikipedia). Retrieved from [https://en.wikipedia.org/wiki/Tempest https://en.wikipedia.org/wiki/Tempest](codename)
# II, E. C. R. Y. P. T., & SYM, D. (2012). ECRYPT II, 79–86. Retrieved from [http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf]
# Katz, J., & Lindell, Y. (2008). ''Introduction to modern cryptography''. Chapman & Hall/CRC. Retrieved from [http://books.google.at/books?id=WIc_AQAAIAAJ http://books.google.at/books?id=WIc_AQAAIAAJ]
# Kivinen, T., & Kojo, M. (2003). More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). IETF. Retrieved from [https://www.ietf.org/rfc/rfc3526.txt https://www.ietf.org/rfc/rfc3526.txt]
# Postel, J. (1980). DoD standard Transmission Control Protocol. IETF. Retrieved from [https://www.ietf.org/rfc/rfc761.txt https://www.ietf.org/rfc/rfc761.txt]
# Raeburn, K. (2005). Advanced Encryption Standard (AES) Encryption for Kerberos 5. IETF. Retrieved from [https://www.ietf.org/rfc/rfc3962.txt https://www.ietf.org/rfc/rfc3962.txt]
# ''SafeCurves: choosing safe curves for elliptic-curve cryptography''. (2013). (Technical Background). Retrieved from [http://safecurves.cr.yp.to/rigid.html http://safecurves.cr.yp.to/rigid.html]
# Schneier, B. (2013). ''The NSA Is Breaking Most Encryption on the Internet'' (Blog: Schneier on Security). Retrieved from [https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html]
# Yarom, Y., & Falkner, K. (2013). Flush+ Reload: a high resolution, low noise, L3 cache side-channel attack. Cryptology ePrint Archive, Report 2013/448, 2013. [http://eprint/ http://eprint]. iacr. org/2013/448/. 3. Retrieved from [http://eprint.iacr.org/2013/448.pdf http://eprint.iacr.org/2013/448.pdf]
 
=== Weblinks ===
# https://bettercrypto.org/
[[Kategorie:Tmp]]
 
= Kryptografie =
 
== Geheime Kommunikation von Caesar bis 1950 ==
 
== Monoalphabetische Substitution Caesar-Chiffre ==
 
== Skytale ==
 
=== Der Skytale verwendet einen Transpositions-Algorithmus ===
 
== Atbash und Rot-13 ==
 
=== Bei Atbash wird der erste Buchstabe durch den letzten ausgetauscht ===
 
=== Julius Cäsar verwendete das Verfahren Rot-13 ===
 
== Kryptografie mit der Vigenere Tabelle ==
 
== Geheime Kommunikation von 1950 bis heute ==
 
= Kryptografie =
Grundlagen
 
== Kryptografie - Terminologie ==
 
== Teilbereiche der Kryptografie ==
 
=== Kryptografie  ===
* Durchführung und Studium Ver- und Entschlüsselung
* Daten werden mathematisch so kodiert, dass nur ausgewählte Personen die Daten decodieren können
* Dazu werden lesbare Daten (Klartext) durch einen mathematischen Algorithmus mit einem geheimen Schlüssel kodiert (Chiffretext)
* Ziel ist eine möglichst sichere Kryptografie
 
=== Kryptoanalyse ===
* Hier ist das Ziel eine Kryptografie zu brechen und so
* Sicherheitslücken zu entdecken
 
== Das Problem ==
 
=== Nur Bob soll die Nachricht von Alice empfangen können… ===
 
== Die Lösung ==
 
== Klassische Kryptografie ==
* Der Klartext (K) wird mittels eines Schlüssels verschlüsselt.
* Mithilfe desselben Schlüssels kann der Geheimtext (G) wieder entschlüsselt werden.
 
== Kryptografie - Terminologie (II) ==
 
== Geheime Übermittlung ==
 
=== Voraussetzungen ===
* Der Empfänger kennt den Schlüssel
* aber sonst niemand
* Ohne Kenntnis des Schlüssels
* ist es unmöglich oder sehr schwierig den Klartext herauszufinden
 
=== Schwierigkeiten ===
* Schlüssel muss vorher vereinbart werden
* Schlüssel muss geheim bleiben, „geheimer Kanal“
* Das Kryptografieverfahren muss sicher sein
 
== Vorhängeschloss-Analogie ==
* Der Klartext ist „eingeschlossen“, und nur Alice und Bob haben den richtigen Schlüssel für das Schloss.
 
== Kryptographisches Grundprinzip ==
 
=== Umwandlung eines Klartextes  ===
* (p, plain text) in einem chiffrierten Text (c, ciphertext)
* mithilfe einer reversiblen kryptografischen Funktion f:
 
=== symmetrische und asymmetrische Algorithmen ===
* Kryptografie / Entschlüsselung
* Schlüssel als zusätzliches Argument zu Funktion f
 
== Verschlüsseln mit symmetrischen Verfahren ==
 
=== Kryptografie und Entschlüsselung mit selbem Schlüssel ===
* z.&nbsp;B.&nbsp;: DES, IDEA
* Effizient, aber Schlüsselaustauschproblem
 
== Ver- und Entschlüsselung mit symmetrischer Kryptografie ==
 
== Man-in-the-Middle ==
* Der Man-in-the-Middle (Mellory)
* schaltet sich zwischen eine Kommunikation
* fängt die gesendeten Datenpakete ab
* Diese kann er nun entschlüsseln, verändern, verschlüsseln und unbemerkt an den Empfänger weiterleiten
* Alice und Bob glauben direkt miteinander zu kommunizieren
* Dies ist jedoch nur möglich, wenn der Mellory die Möglichkeit hatte, an der Verteilung der öffentlich Schlüssel eine Manipulation vorzunehmen
* Wird der Schlüssel über ein zuverlässiges Medium übertragen
* ist der Diffie-Hellman-Algorythmus gegen solche Angriffe geschützt
 
== Asymmetrischer Kryptografiepublic key-Kryptografie ==
 
== Asymmetrischer Kryptografiepublic key-Kryptografie ==
 
== Public Key Kryptografie ==
 
=== Ver- und Entschlüsselung mit verschiedenen Schlüsseln ===
* “Vergleichbar mit einem Briefkasten - jeder kann etwas hinein werfen, aber nur einer kann es herausnehmen.”
* Schlüssel-Paare: Öffentlicher und privater Schlüssel
* z.&nbsp;B.&nbsp;: RSA, ElGamal, Elliptische Kurven (ECC)
* Problem
* Meist ineffizienter als symmetrische Verfahren
* deshalb häufig nur zum Austausch symmetrischer Schlüssel und für Unterschriften
* Der private Schlüssel darf aus dem öffentlichen nicht errechenbar sein
* Einwegfunktion mit Falltür
* Nur unter Kenntnis einer zusätzlichen Information effizient umkehrbar
* z.&nbsp;B.&nbsp;x = loga y mod n (RSA-Verfahren) unter Kenntnis der Primfaktoren
 
== Transposition vs. Substitution ==
 
=== Transposition  ===
* jeweils 2 aufeinander folgende Buchstaben vertauschen
* wodurch sich neue Wörter ergeben
* wir auch als Scambling (Verwürfelung) bezeichnet
* Beispiel
* Netz = Enzt
* Einsatzgebiet
* drahtlose Übertragungstechniken
 
=== Substitution ===
* Bei der Substitution werden die Buchstaben des Klartextes im Geheimtext durch andere ersetzt
* Dabei wird jeder Buchstabe durch den ersetzt, der im Alphabet 3 Stellen weiter hinten steht.
* Cäsar-Addition
* Beispiel
* Netz = Qhzc
 
== Symmetrische Substitution ==
 
=== Sender und Empfänger müssen den gleichen Schlüssel besitzen ===
* um miteinander Kommunizieren zu können
* Secret-Key-Verfahren
* Eignet sich gut, um große Datenmengen zu verschlüsseln
* Nachteil
* Um die Nachricht verwerten zu können, muss der Schlüssel mit übertragen werden
* was einen Schwachpunkt darstellt
 
== Symmetrische Substitutionsverfahren ==


For a detailed explanation of the cipher suites chosen, please see [ChoosingYourOwnCipherSuites]. In short, finding a single perfect cipher string is practically impossible and there must be a tradeoff between compatibility and security. On the one hand there are mandatory and optional ciphers defined in a few RFCs, on the other hand there are clients and servers only implementing subsets of the specification.
=== Klassifizierungen ===
* Zeichenchiffren
* Blockchiffren
* Stromchiffren
* Zeichenchiffrierung
* Ermittelt jedes Zeichen des Geheimtextes aus dem entsprechenden Zeichen des Klartextes mit Hilfe des Schlüssels
* Cäsar-Addition
* Stromchiffrierung
* Der Klartext wird Byte-weise über eine XOR-Operation verschlüsselt
* Sie Erzeugt eine sich zyklisch verändernde Byte-Folge, die mit dem Klartext verknüpft wird
* Blockchiffrierung
* Klartext wird in Bitgruppen geteilt
* über mehrstufige Verfahren mit dem Schlüssel über gleichbleibende Operationen in Geheimtext umgewandelt
* DES


Straightforwardly, the authors wanted strong ciphers, forward secrecy [25] and the best client compatibility possible while still ensuring a cipher string that can be used on legacy installations (e.g. OpenSSL 0.9.8).
== Asymmetrische Substitution ==
|}
* Es werden 2 komplementäre Schlüssel benötigt
Our recommended cipher strings are meant to be used via copy and paste and need to work "out of the box".
* 1 Key zum Chiffrieren der Nachricht
* 2 Key zum Dechiffrieren der Nachricht
* Einer der Schlüssel kann gefahrlos öffentlich bekannt gegeben werden (Public-Key)
* Wird mit einem Schlüssel chiffriert
* kann nur mit dem anderen Schlüssel dechiffriert werden


* TLSv1.2 is preferred over TLSv1.0 (while still providing a useable cipher string for TLSv1.0 servers).
== Vorteile von Public-Key-Verfahren ==
* AES256 and CAMELLIA256 count as very strong ciphers at the moment.
* Jeder Kommunikationspartner benötigt einen Schlüssel
* AES128 and CAMELLIA128 count as strong ciphers at the moment
* seinen Private Key
* DHE or ECDHE for forward secrecy
* Der zweite Schlüssel wird veröffentlicht
* RSA as this will fit most of today’s setups
* Nachteil
* AES256-SHA as a last resort: with this cipher at the end, even server systems with very old OpenSSL versions will work out of the box (version 0.9.8 for example does not provide support for ECC and TLSv1.1 or above). Note however that this cipher suite will not provide forward secrecy. It is meant to provide the same client coverage(eg. support Microsoft crypto libraries) on legacy setups.
* Hohe Komplexität der durchzuführenden Operationen
* Die Multiplikation 2 Zahlen stellt eine einfache Operation dar
* während der umgekehrte Vorgang, also die Faktorzerlegung eines Produkts, einen enormen Rechenaufwand bedeuten kann


=== 18.3. Compatibility ===
== Absicherung der asymmetrischen Substitution ==
{| class="wikitable"
* Schwäche
|
* keine eindeutige Zuordnung des öffentlichen Schlüssels zu seinem Besitzer
|TODO
* Ein „Man-in-the-Middle“ könnte sich dazwischenschalten und die Nachrichten unbemerkt entschlüsseln
* Informationen des öffentlichen Schlüssels und seines Besitzers sollten aus vertrauenswürdiger Quelle stammen
* Möglichkeiten im Rahmen der Public Key Infrastructure (PKI)
* Schlüssel kann über ein sicher betrachtetes Medium übertragen werden
* Beispiel
* Persönliche Übergabe, Telefon, Brief, Fax
* Identität des Schlüsselinhabers zertifizieren lassen


Write this section. The idea here is to first document which server (and openssl) version we assumed. Once these parameters are fixed, we then list all clients which are supported for Variant A) and B). Therefore we can document compatibilities to some extent. The sysadmin can then choose roughly what he looses or gains by omitting certain cipher suites.
== Trust Center ==
|}


== 19. Random Number Generators ==
=== Certification Authority [CA] ===
(Image license: CC-BY-NC)
* Zertifizierungsinstanz (Trust Center)
* Zur Überprüfung der Schlüsselinhaber
* Sender und Empfänger verwalten Listen von Zertifizierungsinstanzen
* Überprüfung Zusammenhang öffentlicher Schlüssel und deren Absender
* Zertifikat nach ITU-Standard X.509
* ALTERNATIVE
* Authentizität eines öffentlichen Schlüssels durch einen bekannten Kommunikationspartner bestätigen lassen
* „Web of True“ von PGP


A good source of random numbers is essential for many crypto operations. The key feature of a good random number generator is the non-predictability of the generated numbers. This means that hardware support for generating entropy is essential.
== Kryptografie ==


Hardware random number generators in operating systems or standalone components collect entropy from various random events mostly by using the (low bits of the) time an event occurs as an entropy source. The entropy is merged into an entropy pool and in some implementations there is some bookkeeping about the number of random bits available.
<div style="text-align:center;margin-left:2cm;margin-right:0cm;">Message Authentication Code</div>


=== 19.1. When Random Number Generators Fail ===
== Einweg-Hash-Funktion ==
Random number generators can fail – returning predictable non-random numbers – if not enough entropy is available when random numbers should be generated.


This typically occurs for embedded devices and virtual machines. Embedded devices lack some entropy sources other devices have, e.g.:
=== Message Authentication Code (MAC) ===
* Dienen bei Datenbank-Anwendungen der einfachen Indizierung von Informationen.
* Dabei werden beispielsweise Kundendaten durch Bildung einer Quersumme zu einem Wert zusammengefasst, denn man Hash-Wert nennt
* Ebenfalls einsetzbar als Authentifizierung und Signatur
* Es darf nicht möglich sein
* die original Information zu rekonstruieren
* durch eine ähnliche Information denselben Hash-Wert zu bekommen
* Es werden keine Schlüssel benutzt, da sie für jeden berechenbar sein sollen


* No persistent clock, so boot-time is not contributing to the initial RNG state.
== Hash-Funktion ==
* No hard-disk: No entropy from hard-disk timing, no way to store entropy between reboots.


Virtual machines emulate some hardware components so that the generated entropy is over-estimated. The most critical component that has been shown to return wrong results is an emulated environment is the timing source (Engblom, 2011).
=== Message Authentication Code (MAC) ===
* Ableitung von „to hash up“
* zerhacken, zerkleinern, durcheinander bringen
* generiert aus einer beliebig langen Zeichenkette eine zweite Zeichenfolge fixer länge.
* Anforderungen
* muss eindeutig sein
* muss einfach zu berechnen sein
* inverse Funktion muss schwierig zu berechnen sein
* muss kollisionsresistent sein
* Hashes lassen sich nicht zur Kryptografie einsetzen
* sie sind nicht reversibel


Typically the most vulnerable time where low-entropy situations occur is shortly after a reboot. Unfortunately many operating system installers create cryptographic keys shortly after a reboot (Heninger, Durumeric, Wustrow, & Halderman, 2012).
== Hash-Algorithmus ==
* Prüfsumme
* Über einen Hash-Algorithmus lässt sich aus einem beliebig langen Datensatz eine Prüfsumme fester Länge berechnen
* Kollisionsfreiheit
* Dieser Hashwert soll möglichst einmalig sein
* Damit ist sichergestellt, dass der Datensatz nicht so manipuliert werden kann, dass der Hashwert trotzdem noch derselbe ist
* SHA-1 und MD5
* Üblicherweise kommen SHA-1 (Secure Hash Algorithm) mit 160 Bit
* MD5 (Message Digest Algorithm) mit 128 Bit zum Einsatz
* ESP mit 96 Bit
* Bei ESP wird der Hashwert von 128, respektive 160 Bit auf 96 Bit abgeschnitten
* (Keyed-)Hash Message Authentication Codes
* Zur Authentisierung von Daten
* HMAC ist eine Sonderform des MAC, bei der zusammen mit einem geheimen Schlüssel ein Hash-Wert etwa über Datenpaket gebildet wird
* Bei VPNs benutzt man in der Regel HMAC-MD5 oder HMAC-SHA-1


Another problem is that OpenSSL seeds its internal random generator only seldomly from the hardware random number generator of the operating system. This can lead to situations where a daemon that is started at a time when entropy is low keeps this low-entropy situation for hours leading to predictable session keys (Heninger, Durumeric, Wustrow, & Halderman, 2012).
== MD-5 ==


For systems where – during the lifetime of the keys – it is expected that low-entropy situations occur, RSA keys should be preferred over DSA keys: For DSA, if there is ever insufficient entropy at the time keys are used for signing this may lead to repeated ephemeral keys. An attacker who can guess an ephemeral private key used in such a signature can compromise the DSA secret key. For RSA this can lead to discovery of encrypted plaintext or forged signatures but not to the compromise of the secret key (Heninger, Durumeric, Wustrow, & Halderman, 2012).
=== Am weitesten verbreitete Message-Digest-Funktion ===
* Mit MD-2 und MD-4 einer der Hash-Funktionen, die stetig verbessert werden
* Nachrichten werden in 512 Bit Blöcken verarbeitet
* indem es 16 x 32 Bit Blöcke zusammenfasst
* Auch als MAC erhält man einen 128 Bit langen Block aus 32 Bit Blöcken
* Die Verarbeitung findet in mehreren Stufen statt
* Dabei dienen ein 512 langer Block und das MAC der vorangegangenen Stufe als Eingangsfolge


== 20. Keylengths ==
== SHA-1 ==
On the choice between AES256 and AES128: I would never consider
using AES256, just like I don't wear a helmet when I sit inside my car. It's
too much bother for the epsilon improvement in security.
Recommendations on keylengths need to be adapted regularly. Since this document first of all is static and second of all, does not consider itself to be authoritative on keylengths, we would rather refer to existing publications and websites. Recommending a safe key length is a hit-and-miss issue.


Furthermore, when choosing an encryption algorithm and key length, the designer/sysadmin always needs to consider the value of the information and how long it must be protected. In other words: consider the number of years the data needs to stay confidential.
=== Schwäche von MD-5 ===
* relativ schnelle Kollisionen der Hash-Werte
* SHA-1 generiert aus einer maximal 2^64 Bit langen Eingangsfolge eine 160 Bit lange Zeichenfolge
* Dabei arbeite es mit 512 bit Blöcken
* Der Algorithmus verwendet 5 Stufen mit jeweils 80 Schritten
* Ergebnisfolge ist wesentlich länger als bei MD-5
* wodurch Kollisionen unwahrscheinlicher sind
* Durchschnittliche Kollisionen:
* MD-5=2^60
* SHA-1=2^80


The ECRYPT II publication gives a fascinating overview of strengths of symmetric keys in chapter 5 and chapter 7. Summarizing ECRYPT II, we recommend 128 bit of key strength for symmetric keys. In ECRYPT II, this is considered safe for security level 7, long term protection.
== Digital Signature Algorythm (DSA) ==
* Chiffriert einen, durch eine Hash-Funktion generierten, MAC mittels eines privaten Schlüssels
* Vorgehen eines mit SHA-1 generierten MAC
* Auswahl einer Primzahl p zwischen 512 und 1024 Bit
* Berechnung des Primfaktors q der Zahl (p-1). q ist 160 Bit lang
* Berechnung einer Zahl g
* mit g = h^(p-1/q) mod p, wobei h < p und g > 1
* Auswahl einer weiteren Zahl x
* als Privater Schlüssel des Senders Alice (x < q)
* Zahl y = g^x mod p wird nun als öffentlicher Schlüssel verwendet


In the same ECRYPT II publication you can find a practical comparison of key size equivalence between symmetric key sizes and RSA, discrete log (DLOG) and EC keylengths. ECRYPT II arrives at the interesting conclusion that for an equivalence of 128 bit symmetric size, you will need to use an 3248 bit RSA key (II & SYM, 2012).
== Substitution vs. Signatur ==
* Algorithmen asymmetrischer Kryptografien unterscheiden sich
* ob eine Nachricht verschlüsselt oder signiert werden soll


There are a couple of other studies comparing keylengths and their respective strengths. The website <nowiki>https://www.keylength.com/</nowiki> compares these papers and offers a good overview of approximations for key lengths based on recommendations by different standardization bodies and academic publications. Figure #fig:keylengths.com[1] shows a typical comparison of keylengths on this web site.
=== Substitution ===
* Absender verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des Empfängers
* so, dass er sie mit seinem privaten Schlüssel wieder im Klartext lesen kann


=== 20.1. Summary ===
=== Signatur ===
For asymmetric public-key cryptography we consider any key length below 3248 bits to be deprecated at the time of this writing (for long term protection).
* Absender erzeugt mit seinem privaten Schlüssel eine Signatur
* Empfänger kann durch Verwendung des öffentlichen Schlüssels des Absenders die Nachricht verifiziert


For elliptic curve cryptography we consider key lengths below 256 bits to be inadequate for long term protection.
== Kryptografie ==


For symmetric algorithms we consider anything below 128 bits to be inadequate for long term protection.
<div style="text-align:center;margin-left:2cm;margin-right:0cm;">Tunneling</div>


=== 20.2. Special remark on 3DES: ===
== Ende-zu-Ende vs. Abschnittsweise Sicherheit ==
We want to note that 3DES theoretically has 168 bits of security, however based on the NIST Special Publication 800-57 [26].


Due to several security problems the effective key length should be considered 80 bits. The NIST recommends not to use 3DES any more and to migrate to AES as soon as possible.
=== Ende-zu-Ende ===
* 2 Endgeräte handeln einen sicheren Kanal, bauen ihn auf und halten ihn aufrecht
* Alternativ können nur kritische Übertragungen verschlüsselt werden
* Beispiel
* Kommunikation zwischen 2 Mailservern, wenn der Client eine Nachricht verschlüsselt überträgt


== 21. A note on Elliptic Curve Cryptography ==
=== Vor- und Nachteile ===
Everyone knows what a curve is, until he has studied enough
* Ende-zu-Ende hat eine geringe Angriffsfläche
mathematics to become confused through the countless number
* benötigt jedoch viel Rechenleistung und eine gute Konfiguration
of possible exceptions.
* Abschnittssicherheit hat eine größere Angriffsfläche
Elliptic Curve Cryptography (simply called ECC from now on) is a branch of cryptography that emerged in the mid-1980s. The security of the RSA algorithm is based on the assumption that factoring large numbers is infeasible. Likewise, the security of ECC, DH and DSA is based on the discrete logarithm problem (i_wikipedia_Discrete logarithm_, 2013). Finding the discrete logarithm of an elliptic curve from its public base point is thought to be infeasible. This is known as the Elliptic Curve Discrete Logarithm Problem (ECDLP). ECC and the underlying mathematical foundation are not easy to understand - luckily, there have been some great introductions on the topic. [27] [28] [29].
* beschränkt jedoch hohe Sicherheitsanforderungen auf die Gateways


ECC provides for much stronger security with less computationally expensive operations in comparison to traditional asymmetric algorithms (See the Section Keylengths). The security of ECC relies on the elliptic curves and curve points chosen as parameters for the algorithm in question. Well before the NSA-leak scandal, there has been a lot of discussion regarding these parameters and their potential subversion. A part of the discussion involved recommended sets of curves and curve points chosen by different standardization bodies such as the National Institute of Standards and Technology (NIST) [30] which were later widely implemented in most common crypto libraries. Those parameters came under question repeatedly from cryptographers (Bernstein & Lange, 2013).
== Tunneling ==


At the time of writing, there is ongoing research as to the security of various ECC parameters (''SafeCurves: choosing safe curves for elliptic-curve cryptography'', 2013). Most software configured to rely on ECC (be it client or server) is not able to promote or black-list certain curves. It is the hope of the authors that such functionality will be deployed widely soon. The authors of this paper include configurations and recommendations with and without ECC - the reader may choose to adopt those settings as he finds best suited to his environment. The authors will not make this decision for the reader.
=== Mehrfaches Einpacken eines Pakets auf einer Transportebene ===
{| class="wikitable"
* Einsatzgebiet heute meist bei abschnittsweise Sicherheit
|
* IP/IP-Tunneling
|Warning
* Für Transport über klassische IP-basierte Netze kann man IPv6 über IPv4 tunneln


One should get familiar with ECC, different curves and parameters if one chooses to adopt ECC configurations. Since there is much discussion on the security of ECC, flawed settings might very well compromise the security of the entire system!
=== Layer-2-Tunneling ===
|}
* Pakete der OSI-Schicht 2
* meist PPP-frames
* werden in IP-Pakete verpackt
* So tunnelt man alle „Nicht-IP-Protokolle“


== 22. A note on SHA-1 ==
== Tunneling ==
In the last years several weaknesses have been shown for SHA-1. In particular, collisions on SHA-1 can be found using 263 operations, and recent results even indicate a lower complexity. Therefore, ECRYPT II and NIST recommend against using SHA-1 for generating digital signatures and for other applications that require collision resistance. The use of SHA-1 in message authentication, e.g. HMAC, is not immediately threatened.


We recommend using SHA-2 whenever available. Since SHA-2 is not supported by older versions of TLS, SHA-1 can be used for message authentication if a higher compatibility with a more diverse set of clients is needed.
=== Layer-3-Tunnelung ===
* Die Pakete der Vermittlungsschicht werden in IP-Frames verpackt
* Bekanntes Verfahren dieser Art ist IPsec


Our configurations A and B reflect this. While configuration A does not include SHA-1, configuration B does and thus is more compatible with a wider range of clients.
== Kryptografie ==
=== Wie baut man eine sicheren Block Cipher? ===


== 23. A note on Diffie Hellman Key Exchanges ==
== Probleme bei der Entwicklung von Kryptografieverfahren ==
A common question is which Diffie-Hellman (DH) parameters should be used for Diffie Hellman key-exchanges [31]. We follow the recommendations in ECRYPT II (II & SYM, 2012).


Where configurable, we recommend using the Diffie Hellman groups defined for IKE, specifically groups 14-18 (2048–8192 bit MODP) (Kivinen & Kojo, 2003). These groups have been checked by many eyes and can be assumed to be secure.
=== Vertraulichkeit ===
* Schutz der Daten vor unberechtigter Einsichtnahme


For convenience, we provide these parameters as PEM files on our webserver [32].
=== Authentisierung ===
* Sicherstellung der Herkunft
* Verbindlichkeit


== 24. Public Key Infrastructures ==
=== Anonymität ===
Public-Key Infrastructures try to solve the problem of verifying whether a public key belongs to a given entity, so as to prevent Man In The Middle attacks.
* Schutz vor Bekanntwerden des Absenders und Empfängers


There are two approaches to achieve that: ''Certificate Authorities'' and the ''Web of Trust''.
=== Integrität ===
* Unveränderlichkeit von Daten und Verlässlichkeit von Programmen


Certificate Authorities (CAs) sign end-entities’ certificates, thereby associating some kind of identity (e.g. a domain name or an email address) with a public key. CAs are used with TLS and S/MIME certificates, and the CA system has a big list of possible and real problems which are summarized in section Hardening PKI and (Durumeric, Kasten, Bailey, & Halderman, 2013).
== Wie baut man eine sicheren Block Cipher? ==


The Web of Trust is a decentralized system where people sign each other’s keys, so that there is a high chance that there is a "trust path" from one key to another. This is used with PGP keys, and while it avoids most of the problems of the CA system, it is more cumbersome.
== Mary Stuart 1516 - 1558Bekanntes Opfer der Kryptoanalyse ==


As alternatives to these public systems, there are two more choices: running a private CA, and manually trusting keys (as it is used with SSH keys or manually trusted keys in web browsers).
== Shannon‘s Principle of ConfusionSubstitution Cipher ==


The first part of this section addresses how to obtain a certificate in the CA system. The second part offers recommendations on how to improve the security of your PKI.
== Shannon‘s Principle of DiffusionTransposition Cipher ==


=== 24.1. Certificate Authorities ===
== Kryptografie ==
In order to get a certificate, you can find an external CA willing to issue a certificate for you, run your own CA, or use self-signed certificates. As always, there are advantages and disadvantages for every one of these options; a balance of security versus usability needs to be found.


==== 24.1.1. Certificates From an External Certificate Authority ====
<div style="text-align:center;margin-left:2cm;margin-right:0cm;">Angriffe auf Kryptografieen</div>
There is a fairly large number of commercial CAs that will issue certificates for money. Some of the most ubiquitous commercial CAs are Verisign, GoDaddy, and Teletrust. However, there are also CAs that offer certificates for free. The most notable examples are StartSSL, which is a company that offers some types of certificates for free, and CAcert, which is a non-profit volunteer-based organization that does not charge at all for issuing certificates. Finally, in the research and education field, a number of CAs exist that are generally well-known and well-accepted within the higher-education community.


A large number of CAs is pre-installed in client software’s or operating system’s`‘trust stores’'; depending on your application, you have to select your CA according to this, or have a mechanism to distribute the chosen CA’s root certificate to the clients.
== Entschlüsselung ==
* Die Entschlüsselung ist die Umkehrung der Kryptografie (symmetrische Verfahren)
* Das heisst beim Beispiel-Caesar-Verfahren jetzt um 3 Buchstaben zurückverschieben:
* ABCDEFGHIJKLMNOPQRSTUVWXYZ
* xyzabcdefghijklmnopqrstuvw
* So wird aus „KDOOR“ wieder ein „hallo“.


When requesting a certificate from a CA, it is vital that you generate the key pair yourself. In particular, the private key should never be known to the CA. If a CA offers to generate the key pair for you, you should not trust that CA.
=== Moderne Verfahren ===
* Das heute im kommerziellen Gebrauch am häufigsten eingesetzte Verfahren heisst DES
* DES steht für „Data Encryption Standard“
* Es funktioniert im Prinzip wie ein mehrfach hintereinander angewandtes Substitutionsverfahren


Generating a key pair and a certificate request can be done with a number of tools. On Unix-like systems, it is likely that the OpenSSL suite is available to you. In this case, you can generate a private key and a corresponding certificate request as follows:
== Angriffe auf Kryptografieen ==
<code>$ openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize> -sha256</code>
<code>Country Name (2 letter code) [AU]:DE</code>
<code>State or Province Name (full name) [Some-State]:Bavaria</code>
<code>Locality Name (eg, city) []:Munich</code>
<code>Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example</code>
<code>Organizational Unit Name (eg, section) []:Example Section</code>
<code>Common Name (e.g. server FQDN or YOUR name) []:example.com</code>
<code>Email Address []:admin@example.com</code>
<code>Please enter the following 'extra' attributes</code>
<code>to be sent with your certificate request</code>
<code>A challenge password []:</code>
<code>An optional company name []:</code>


==== 24.1.2. Setting Up Your Own Certificate Authority ====
=== Chifertext-Only Angriff ===
In some situations it is advisable to run your own certificate authority. Whether this is a good idea depends on the exact circumstances. Generally speaking, the more centralized the control of the systems in your environment, the fewer pains you will have to go through to deploy your own CA. On the other hand, running your own CA maximizes the trust level that you can achieve because it minimizes external trust dependencies.
* Versucht eine Kryptografie nur bei Kenntnis des chiffrierten Textes zu lösen
* Gößte Herausforderung für jeden Kryptoanalytiker


Again using OpenSSL as an example, you can set up your own CA with the following commands on a Debian system:
=== Known-plaintext-Angriff ===
<code>$ cd /usr/lib/ssl/misc</code>
* Der Angreifer besitzt neben dem Chiffretext auch den Klartext (oder einen Teil davon) und hat nun die Aufgabe den Schlüssel oder den Kryptografiealgorithmus zu finden.
<code>$ sudo ./CA.pl -newca</code>
Answer the questions according to your setup. Now that you have configured your basic settings and issued a new root certificate, you can issue new certificates as follows:
<code>$ cd /usr/lib/ssl/misc</code>
<code>$ sudo ./CA.pl -newreq</code>
Alternatively, software such as TinyCA that acts as a "wrapper" around OpenSSL and tries to make life easier is available.


==== 24.1.3. Creating a Self-Signed Certificate ====
=== Chosen-Plaintext Attack  ===
If the desired trust level is very high and the number of systems involved is limited, the easiest way to set up a secure environment may be to use self-signed certificates. A self-signed certificate is not issued by any CA at all, but is signed by the entity that it is issued to. Thus, the organizational overhead of running a CA is eliminated at the expense of having to establish all trust relationships between entities manually.
* Auch Teile des Klartextes können wertvolle Hilfe leisten
* Attacker can choose the plaintext that gets encrypted thereby potentially getting more information about the key


With OpenSSL, you can self-sign a previously created certificate with this command:
=== Adaptive Chosen-Plaintext Attack ===
<code>$ openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095</code>
* Attacker can choose a series of plaintexts, basing choice on the result of previous encryption
You can also create a self-signed certificate in just one command:
* differential cryptanalysis!
<code>$ openssl req -new -x509 -keyout privkey.pem -out cacert.pem -days 1095 -nodes -newkey rsa:<keysize> -sha256</code>
The resulting certificate will by default not be trusted by anyone at all, so in order to be useful, the certificate will have to be made known a priori to all parties that may encounter it.


=== 24.2. Hardening PKI ===
=== Brute Force Angriff ===
In recent years several CAs were compromised by attackers in order to get a hold of trusted certificates for malicious activities. In 2011 the Dutch CA Diginotar was hacked and all certificates were revoked (Elinor Mills, 2011). Recently Google found certificates issued to them, which were not used by the company (Damon Poeter, 2011). The concept of PKIs heavily depends on the security of CAs. If they get compromised the whole PKI system will fail. Some CAs tend to incorrectly issue certificates that were designated to do a different job than what they were intended to by the CA (Adam Langley, et. al., 2013).
* Nacheinander werden alle möglichen Schlüssel durchprobiert
* Kann bei jeder Kryptografiemethode eingesetzt werden
* Der Angreifer muss jedoch erkennen, wann der richtige Schlüssel gefunden wurde, daher werden diese Angriffe oft als Known-plaintext-Angriff durchgeführt


Therefore several security enhancements were introduced by different organizations and vendors (H. Tschofenig and E. Lear, 2013). Currently two methods are used, DANE (Hoffman & Schlyter, 2012) and Certificate Pinning (C. Evans and C. Palmer, 2013). Google recently proposed a new system to detect malicious CAs and certificates called Certificate Transparency (Adam Langley, Ben Laurie, Emilia Kasper, 2013). In addition, <nowiki>RFC 6844</nowiki> describes Certification Authorization Records, a mechanism for domain name owners to signal which Certificate Authorities are authorized to issue certificates for their domain.
== Dechiffrierung verschlüsselter NachrichtenBrute Force Angriff ==
* Die Brute-force Methode ist bei sehr großen Schlüsseln wirkungslos
* Dann muss sich der Gegner auf die Analyse des Chiffrats verlassen
* Dabei muss der Angreifer eine gewisse Vorstellung haben, um was für eine Art Ausgangstext es sich handelt
* zum Beispiel eine .exe-Datei, Word-Datei oder einen Text mit deutschem Inhalt
* Oder der Gegner spekuliert auf bestimmte Muster des Klartextes
* Word-Dateien fangen zum Beispiel immer mit dem selben Muster an
* Kryptoanalyse basiert auf der Ausnutzung
* von Spuren der Struktur oder
* des Musters des Klartextes
* Diese bestehen auch nach Kryptografie und sind im Chiffretext zu erkennen


=== 24.3. Certification Authorization Records ===
== Exhaustive Testing ==
<nowiki>RFC 6844</nowiki> describes Certification Authorization Records, a mechanism for domain name owners to signal which Certificate Authorities are authorized to issue certificates for their domain.


When a CAA record is defined for a particular domain, it specifies that the domain owner requests Certificate Authorities to validate any request against the CAA record. If the certificate issuer is not listed in the CAA record, it should not issue the certificate.
=== Monoalphabetischen Substitution (Cäsar) ===
* jedem Buchstaben eines Alphabets mit 27 Buchstaben (26 + ein Satzzeichen) wird ein beliebig anderen zuordnet
* 27 Möglichkeiten für den ersten Buchstaben
* 26 Möglichkeiten für den zweiten Buchstaben
* 25 Möglichkeiten für den dritten Buchstaben
* etc.
* Das enspricht 27 * 26 * .... * 2 * 1 = 27!
* rund 1,09*10e28 Zuordnungsmöglichkeiten


The RFC also permits Certificate Evaluators to test an issued certificate against the CAA record, but should exercise caution, as the CAA record may change during the lifetime of a certificate, without affecting its validity.
== Statische Analyse ==
* Angreifer nutzen die Schwachstellen der Kryptverfahren
* Dabei analysieren sie statisch den verschlüsselten Datenverkehr
* Im Fall der monoalphabetischen bedeutet das
* Die Häufigkeit der verschlüsselten Buchstaben bleibt gleich und kann durch einfache Häufigkeitsanalyse Rückschlüsse auf den Originaltext ziehen
* Jedoch muss deren Sprache kennen bzw.&nbsp;erraten
* Der Buchstabe „e“ tritt in der deutschen Sprache am häufigsten auf
* Auch Buchstabenpaare (Biagramme) treten mit unterschiedlicher Häufigkeit auf
* Durch diese Kenntnisse können monoalphabetische Codes schnell entschlüsselt werden


CAA also supports an iodef property type which can be requested by a Certificate Authority to report certificate issue requests which are inconsistent with the issuer’s Certificate Policy.
== Known oder Chosen Plaintext ==
* Teilweise vorhersehbar
* Kryptografieen und Kryptografien zu knacken fällt einem Angreifer leichter, wenn er Teile des Klartextes bereits kennt.
* Die Header-Daten von IP Paketen lassen sich unschwer erraten/ermitteln und ermöglichen so Know-Plaintext-Attacken
* Diese Methode funktioniert auch bei Paketen, bei denen Teile der Informationen im Header vorhersagbar sind
* Der Angreifer hat auch die Möglichkeit, eigenen Text zu verschlüsseln.
* Ist dieser abhörbar, so können Rückschlüsse über den Verschlüssellungsalgorythmus gezogen werden


==== 24.3.1. Configuration of CAA records ====
== MustererkennungDie Methode des wahrscheinlichen Wortes ==
BIND supports CAA records as of version 9.9.6.


A CAA record can be configured by adding it to the zone file:
=== Bei der „Methode des wahrscheinlichen Wortes“ wählt man ein Wort aus, dass mit hoher Wahrscheinlichkeit im Klartext vorkommt, und sucht das Chiffrat ab, ob und wo das Muster dieses Wortes in ihm enthalten ist. Bsp.: „neun“ (Muster: ABCA) ===
<code>$ORIGIN example.com</code>
        <code>CAA 0 issue "ca1.example"</code>
        <code>CAA 0 iodef "<nowiki>mailto:security@example.com</nowiki>"</code>
If your organization uses multiple CA’s, you can configure multiple records:
      <code>CAA 0 issue "ca1.example"</code>
      <code>CAA 0 issue "ca2.example"</code>
"ca1.example" and "ca2.example" are unique identifiers for the CA you plan on using. These strings can be obtained from your Certificate Authority, and typically are its top level domain. An example is "letsencrypt.org" for the Let’s Encrypt CA operated by the Internet Security Research Group.


Knot-DNS supports CAA records as of version 2.2.0.
== Most Cryptoanalytic Attacks base on theRedundancy of Natural Language Texts ==


==== 24.3.2. Validation of CAA records ====
== Angriffsarten ==
Once a CAA record is deployed, it can be validated using the following dig query:
* Angreifer hat mehrere Möglichkeiten
<code>$ dig CAA google.com</code>
* Informationen einer verschlüsselten Nachricht zu erhalten
* die vom Sender A („Alice“) an Empfänger B („Bob“) geschickt wird
<code>; <<>> DiG 9.10.3-P4-Debian <<>> CAA google.com</code>
* Am leichtesten können Nachrichten an
* Hubs
<code>;; ANSWER SECTION:</code>
* Switches und
<code>google.com.          3600 IN  CAA  0 issue "symantec.com"</code>
* Router abgehört werden
On older versions of Dig, which do not support CAA records, you can query the record type manually:
<code>$ dig +short -t TYPE257 google.com</code>
<code>\# 19 0005697373756573796D616E7465632E636F6D</code>


== 25. TLS and its support mechanisms ==
== Kryptografie ==


=== 25.1. HTTP Strict Transport Security (HSTS) ===
<div style="text-align:center;margin-left:0cm;margin-right:0cm;">Kryptologische Verfahren</div>
HTTP Strict Transport Security (HSTS) is a web security policy mechanism. HSTS is realized through HTTP header by which a web server declares that complying user agents (web browsers) should interact with it by using ''only'' secure HTTPS connections. [33]


HSTS header is bound to a DNS name or domain by which the server was accessed. For example if server serves content for two domains and it is HTTPS enabled only for one domain, the browser won’t enforce HSTS for the latter.
== Der Schlüsselaustausch ==
* Sicherheitsrelevant für alle bisher kennen gelernten Verfahren ist der Schlüsselaustausch
* muss zuvor über einen geheimen Kanal stattfinden
* Nicht immer hat man aber die Möglichkeit sich z.&nbsp;B.&nbsp;persönlich zu treffen
* Public-Key
* Es gibt jedoch ein Möglichkeiten, auch über einen unsicheren Kanal den Schlüsselaustausch durchzuführen
* Diese Verfahren tragen den Namen „Public-Key“
* Schlüsselaustausch ist ein Problem …
* Verschiedene Schlüssel für verschiedene Kommunikationspartner notwendig
* Diffie-Hellman Schlüsselaustausch-Verfahren
* Basiert auf Schwierigkeit, den „diskreten Logarithmus“ zu berechnen
* Gegeben sein ein Primzahl-Modulus p und eine Zahl x
* 1) Alice wählt eine zufällige, geheime Zahl a und berechnet y1=x^a mod p
* 2) Bob wählt eine zufällige, geheime Zahl b und berechnet y2=x^b mod p
* Beide senden sich ihr y1 bzw.&nbsp;y2 zu
* Alice berechnet s = y2^a = x^(ba) mod p
* Bob berechnet s‘ = y1^b = x^(ab) mod p = s


HSTS reduces the risk of active man-in-the-middle attacks such as SSL stripping, and impersonation attacks with ''untrusted'' certificate. HSTS also helps to avoid unintentional mistakes such as insecure links to a secure web site (missing HTTPS links [34]), and mistyped HTTPS URLs.
== Diffie-Hellman-Key-Exchange ==
* Über das Diffie-Hellman-Key-Exchange-Verfahren (DH) lassen sich kryptographische Schlüssel sicher über unsichere Kanäle aushandeln
* Es ist selbst kein Kryptografieverfahren und tauscht auch keine Schlüssel im eigentlichen Sinne aus
* Das von Martin Hellman und Whitfield Diffie entwickelte Verfahren beruht auf den Eigenschaften diskreter Logarithmen:
* zwar ist es einfach, eine Zahl zu potenzieren
* Es ist aber nur mit sehr großem Aufwand möglich, den diskreten Logarithmus einer Zahl zu berechnen
* Bei der Aushandlung einigen sich die VPN-Peers auf eine Primzahl p und eine Primitivwurzel g mod p
* Beide Faktoren dürfen unverschlüsselt übertragen werden
* Anschließend erzeugt jede Seite eine geheime Zufallszahl a/b und berechnet daraus den Wert Za= ga mod p beziehungsweise Zb = gb mod p
* Za und Zb werden an den Partner übertragen
* Daraus kann nun jede Seite den gemeinsamen symmetrischen Schlüssel K berechnen:
* Zba mod p = Zab mod p = K


After the web browser receives a HSTS header in a ''correctly'' [35] prepared SSL session it will automatically use secure HTTPS links for accessing the server.
== Diffie-Hellman-Key-Exchange ==
* Sind die eingesetzten Zahlen hinreichend groß, ist es für einen Angreifer so gut wie unmöglich, den Key zu knacken
* Große Zahlen erfordern allerdings mehr Rechenaufwand
* Die Größe der Zahlen bestimmt die gewählte DH-Gruppe
* Die kleinste DH Gruppe 1 hat 768 Bit und die größte definierte Gruppe 18 besitzt 8192 Bit
* Empfohlen wird derzeit der Gebrauch der Gruppe 5 mit 1536 Bit


This prevents unencrypted HTTP access (SSL striping, mistyped HTTPS URLs, etc.) when the server is accessed later by the client.
== Diffie-Hellman ==
* Vereinbarung eines gemeinsamen symmetrischen Schlüssels über einen unsicheren Kanal.
* Basiert auf 2 Schlüsseln
* Alice und Bob sind einer große Primzahl p und ein ganzahliger Wert g (Generator) frei zugänglich
* Alice generiert eine große Zufallszahl a, berechnet eine Zahl A = g^a mod p
* Bob generiert ebenfalls eine große Zufallszahl b, berechnet eine Zahl B = g^b mod p
* und sendet B an Alice
* Alice berechnet eine Zahl K[1] = B^a mod p.
* Bob berechnet eine Zahl K[2] = A^b mod p.
* K[1] und K[2] sidn gleich.
* Es gilt K = K[2] = K[2] = g^a*b mod p
* K wird als geheimer symmetrischer Schlüssel verwendet


When a server (that previously emitted a HSTS header) starts using an untrusted certificate, complying user agents must show an error message and ''block the server connection''. Thus impersonation MITM attack with ''untrusted'' certificates cannot occur.
== Symmetrische Kryptografieverfahren ==


For the initial setup HSTS header needs a trusted secure connection over HTTPS. This limitation can be addressed by compiling a list of STS enabled sites directly into a browser. [36]
=== Einfachster Einsatz  ===
* basiert auf der logischen Exklusiv-Oder-Funktion
* 2 XOR Verknüpfung eines A Zeichens mit einem B hat wieder das ursprüngliche Zeichen A zum Ergebnis
* Es entspricht also der Inversen Verknüpfung:
* (A+B)+B=A+(B+B)Assoziativgesetz=A+0Eigenschaft von XOR=AEigenschaft von XOR
* Der Sender verschlüsselt ein Zeichen A mit einem Schlüssel B per XOR und versendet das Ergebnis
* Der Empfänger verknüpft das Ergebnis erneut mit Schlüssel B und erhält dann wieder das Zeichen A


==== 25.1.1. HSTS Header Directives ====
== Symmetric Algorithms: Block Ciphers ==
HSTS header can be parametrized by two directives:


* max-age=<number-of-seconds>
== Some Popular Block Ciphers ==
* includeSubdomains


''max-age'' is a required directive. This directive indicates the number of seconds during which the user agent should enforce the HSTS policy (after the reception of the STS header field from a server).
== Symmetric Algorithms: Stream Ciphers ==


''includeSubdomains'' is an optional directive. This directive indicates that the HSTS policy applies to this HSTS host as well as ''any subdomains of the host’s domain name''.
== RC4 ==


==== 25.1.2. HSTS Client Support ====
=== RC = Rivest Cipher  ===
HSTS is supported [37] by these web browsers:
* Stromverschlüsselungsverfahren
* Basiert auf XOR-Verknüpfung
* Sehr schnell und einfach
* Eignet sich gut in Software
* Der Algorythmus macht aus dem eingegebenen Schlüssel S einen langen, pseudo-zufälligen internen Schlüssel P
* Dieser wird zur Chiffrierung des Klartextes verwendet
* RC4 Speichert 258 verschiedene Zusatzinformationen
* 256 sind Permutationen von 0-255 und somit gleich verteilt


* Firefox version >= v4.0
== DES ==
* Chrome version >= 4.0
* Android Browser >=4.4
* Opera version >= 12.0
* Opera mobile >= 16.0
* Safari >= 7.0
* Microsoft Internet Explorer >= 11 (with update provided 09. June 2015)
* Microsoft Edge >= 12


==== 25.1.3. HSTS Considerations ====
=== Familie der Blockchiffren ===
Before enabling HSTS it is recommended to consider following:
* Teilt eine Nachricht in 64 Bit große Datenblöcke
* 3 bearbeitungsschritte werden benötigt, um den Klartext wieder herzustellen.
* Am weitesten verbreiteter Algorythmus, auch wenn nicht mehr ganz Zeitgemäß
* Nachfolger: 3DES
* Wird in Finanzdienstleistungen eingesetzt und führt die Kryptografie 3 mal hintereinander aus


* Is it ''required'' to serve content or services over HTTP?
== Data Encryption Standard (DES)Sicherheit von DES ==
* Enabling ''includeSubdomains'' and SSL certificate management.
* DES
* Proper value of ''max-age''.
* erlaubt mit 56 Bit Schlüssellänge
* 72 Billiarden mögliche Schlüssel
* ist heute nicht mehr ausreichend
* per Brute-Force in 5 Tagen (?) geknackt


It is recommended to serve all content using HTTPS, but there are exceptions to this rule as well. Consider running a private PKI [38]. CRLs and OCSP responses are published typically by HTTP protocol. If HSTS is enabled on the site where OCSP and CRLs are published the browser might fail fetching CRL or validating OCSP response.
== Permutation ==
* DES besteht aus 3 Bearbeitungsschritten
* Initiale Permutation
* Ver-/Entschlüsselung in mehreren Runden
* finale Permutation
* DES wurde in den 70er Jahren zur Implementation in Hardware entwickelt
* durch die damals noch kleinen CPU Register
* Finale Permutation = Inverse der initialen Permutation
* Nach der Durchführung der initialen und finalen Permutation, steht ein Bit wieder an ursprünglicher Stelle


Similar reasoning goes for ''includeSubdomains''. One needs to be sure that HTTPS can be enforced for all subdomains. Moreover the administrators are advised to watch for expiration of the SSL certificate and handle the renewal process with caution. If a SSL certificate is renewed after expiration or misses a (HSTS enabled) domain name, the connection to site will break (without providing override mechanism to the end user).
== Kryptografie ==
* DES basiert auf einer 64 Bit Kryptografie
* wovon jedoch nur 56 Bit kryptographisch relevant sind
* Jedes 8 Bit = Parity-Bit
* DES erzeugt 16 verschiedene 48 Bit lange Schlüssel
* Es werden aus 56 relevanten Bit mit einer Permutation 2 28 Bit Muster generiert (C[i-1] und D[i-1]).
* Die Teilschlüssel werden nun um 1 oder 2 Bit nach links rotiert.
* Die erzeugten Schlüssel C[i] und D[i] werden zu C[i-1] und D[i-1].
* 2 24Bit Folgen aus C[i] und D[i] werden zum Schlüssel K[n]


Finally HSTS should be tested with lower ''max-age'' values and deployed with higher ''max-age'' values.
== Kryptografie ==
* DES teilt den Klartext in 64 Bit Blöcke und
* splittet sie nochmal in 2 32 Bit lange Bestandteile (L[n] und R[n]).
* R[n] wird über eine Mangler-Funktion ,mittels tabellenbasierter Umrechnung auf Grundlage der Eingangsvariable R[n] und des Schlüssels K[n], vermischt.


==== 25.1.4. Testing HSTS ====
== Genügen 128 Bit? ==
HSTS can be tested either using locally or through the Internet.
* IDEA
* International Data Encryption Algorithm
* arbeitet mit 128 Bit Schlüssellänge, sonst ähnlich wie der DES
* 3.43669 * 1038
* knacken benötigt etwa 1012 Jahre
* Daher gilt der IDEA heute als sicher


For local testing it is possible to utilize Chrome Web browser UI by typing chrome://net-internals/#hsts [39] in the address bar.
== Asymmetrische Kryptografieverfahren ==


Testing over the Internet can be conducted by Qualys SSL Labs test <nowiki>https://www.ssllabs.com/ssltest/</nowiki>. ''Strict Transport Security (HSTS)'' information is located in the ''Protocol Details'' section.
=== Setzen auf 2 unterschiedliche Schlüssel ===
* Privater Schlüssel (privat key) [Dechiffriert-Algorythmisch]
* Öffentlicher Schlüssel (public key) [Chiffriert-Algorythmisch]
* Es lässt sich nicht vom public key auf den private key schließen
* Der public key kann von Dritten zur Kryptografie von Informationen genutzt werden
* die der Besitzer des private keys nur entschlüsseln kann


==== 25.1.5. References ====
=== Bekanntester Vertreter ===
* RSA-Algorythmus
* Die Multiplikation 2er Zahlen stellt eine einfache Operation dar
* während der umgekehrt Vorgang eine enorme Rechenleistung bedeutet


* Websites Must Use HSTS in Order to Be Secure: <nowiki>https://www.eff.org/deeplinks/2014/02/websites-hsts</nowiki>
== RSA ==
* OWASP: HTTP Strict Transport Security: <nowiki>https://www.owasp.org/index.php/HTTP_Strict_Transport_Security</nowiki>
* HSTS Browser Compatibility List: <nowiki>https://caniuse.com/stricttransportsecurity</nowiki>
* <nowiki>RFC 6797</nowiki>:HTTP Strict Transport Security (HSTS) - Examples: <nowiki>https://tools.ietf.org/html/rfc6797#section-6.2</nowiki>


=== 25.2. HTTP Public Key Pinning (HPKP) ===
=== Basiert auf folgenden 4 Schritten ===
Much like HTTP Strict Transport Security (HSTS), HTTP Public Key Pinning (HPKP) is a Trust-On-First-Use (TOFU) mechanism. It protects HTTPS websites from impersonation using certificates issued by compromised certificate authorities. The data for Pinning is supplied by an HTTP-Header sent by the WebServer.
* Wähle 2 große Primzahlen p und q, die geheim bleiben
* Berechne das Produkt n = p*q
* Für öffentlichen Schlüssel wähle e < n
* die teilerfremd zur Eulerschen Funktion E(n) = (p-1)*(q-1) ist
* Für privaten Schlüssel bestimme eine Zahl
* d = e^-1 mod E(n)
* Dann gilt
* e*d = 1 mod E(n)
* [d,n] ist der private Schlüssel


==== 25.2.1. HPKP Header Directives ====
== RSA ==
HPKP provides two different types of headers:


* Public-Key-Pins
=== Algorithmus bei der Kryptografie ===
* Public-Key-Pins-Report-Only
* Alice verschlüsselt
* ihren Klartext m gemäß c = m^e mod n und
* sendet ihn an Bob.
* In diesem Fall ist [e,n] der öffentliche Schlüssel von Bob
* Bob entschlüsselt
* den Geheimtext c mit seinem privaten Schlüssel [d,n] gemäß m = c^d mod n
* und erhält auf Grund des Zusammenhangs von d und e den Klartext m


HPKP header can be parametrized by following directives:
== RSA ==
* Der Empfänger führt bei der Entschlüsselung die gleiche Operation wie der Sender bei der Kryptografie durch
* Algorythmus zur Erzeugung und Überprüfung von Signaturen
* Alice sendet eine signierte Nachricht, indem sie s = m^d mod n erzeugt und überträgt
* [d,n] = Privater Schlüssen von Alice
* Bob entschlüsselt die Signatur gemäß m = s^e mod n und erhält auf Grund des Zusammenhangs von d und e den Klartext m
* [e,n] = öffentlicher Schlüssel von Alice


* pin-sha256="<YOUR_PUBLICKEY_HASH⇒"
== Advanced Encryption Standard ==
* max-age=<number-of-seconds>
* Nachfolgestandard für DES
* includeSubdomains
* 3DES mit 128 Bit gilt noch als sicher
* report-uri="<<nowiki>https://YOUR.URL/TO-REPORT</nowiki>>"
* wegen der Dreifachverschlüsselung deutlich langsamer als AES
* AES unterstützt 128, 192 und 256 Bit lange Schlüssel
* Beispiel Hamachi
* AES mit 256 Bit Schlüssellänge
* im Modus Cipher-Block-Chaining


'''pin-sha256''' is a required directive. It can and should be used several (at least two) times for specifying the public keys of your domain-certificates or CA-certificates. Operators can pin any one or more of the public keys in the certificate-chain, and indeed must pin to issuers not in the chain (as, for example, a backup-pin). Pinning to an intermediate issuer, or even to a trust anchor or root, still significantly reduces the number of issuers who can issue end-entity certificates for the Known Pinned Host, while still giving that host flexibility to change keys without a disruption of service. OpenSSL can be used to convert the public-key of an X509-certificate as follows:
== Advanced Encryption Standard (AES)http://www.nist.gov/aes ==
<code>$ openssl x509 -in <certificate.cer> -pubkey -noout |</code>
* DES is nearly 25 years old!
  <code>openssl rsa -pubin -outform der |</code>
* Triple DES with a 168 bit key is the current Federal Information Processing Standard FIPS 46-3 (renewed in October 1999).
  <code>openssl dgst -sha256 -binary |</code>
* Single DES with 56 bit key is permitted for legacy systems only.
  <code>openssl enc -base64</code>
* Evaluation of an Advanced Encryption Standard
<code>writing RSA key</code>
* The National Institute of Standards and Technology (NIST,U.S. Department of Commerce) started a public contest in 1997.
<code>pG3WsstDsfMkRdF3hBClXRKYxxKUJIOu8DwabG8MFrU=</code>
* 5 final candidate algorithms. Decision by NIST in Spring 2001
This piped usage of OpenSSL first gets the Public-Key of <certificate.cer>, converts it do DER (binary) format, calculates an SHA256 Hash and finally encodes it Base64. The output (including the ending Equal-Sign) is exactly whats needed for the ''pin-sha256="<YOUR_PUBLICKEY_HASH⇒"'' parameter.
* Requirements for AES
* AES shall be publicly defined.
* AES shall be a symmetric block cipher.
* AES shall be implementable in both hardware and software.
* AES shall be designed so that the key length may be increased as needed.
* AES block size n = 128 bits, key size k = 128, 192, 256 bits


To generate the hash for a prepared backup-key just create a certificate-signing-request and replace <code>openssl x509</code> by <code>openssl req -in <backup-cert.csr> -pubkey -noout</code> as first OpenSSL command.
== AES Round 2 Finalists ==
* MARS(IBM)
* Modified Feistel Network - 32 Rounds
* Based on Mixed Structure DES
* RC6 (RSA)
* Feistel Network - 20 Rounds
* Based on Modified RC5
* Rijndal(Joan Daemen / Vincent Rijmen)
* Modified Substitution Permutation Network - 10 Rounds
* Based on Square
* Serpent (Ross Anderson / Eli Biham / Lars Knudsen)
* Substitution Permutation Network - 32 Rounds
* Based on Bitlice Operations
* Twofish(Bruce Schneier)
* Feistel Network - 16 Rounds
* Based on Modified Blowfish


Instead of using OpenSSL even web-services like <nowiki>https://report-uri.io/home/pkp_hash/</nowiki> can be used to get a suggestion for the possible Public-Key-Hashes for a given website.
== Cipher Block Chaining (CBC) ==
* Um eine Frquenzanalyse zu verhindern wird eine Verkettung von Datenblöcken durchgeführt
* Dabei wird der zu verschlüsselnde Datenblock exklusiv mit dem letzten verschlüsselten Datenblock verknüpft
* Gleiche Datenblöcke werden so unterschiedlich modifiziert und unterschiedlich verschlüsselt
* Problem: Erste Datenblock
* Erzeugung eines Initialisierungs-Vekros (IV)
* Der IV wird zur Entschlüsselung benötigt
* daher wird er dem Empfänger übermittelt
* Vertraulichkeit ist nicht erforderlich
* IPsec – Protokolle übertragen den IV in jedem Datenpaket


'''max-age''' is a required directive (when using the ''Public-Key-Pins'' header). This directive specifies the number of seconds during which the user agent should regard the host (from whom the message was received) as a "Known Pinned Host".
== Advanced Encryption Standard ==


'''includeSubdomains''' is an optional directive. This directive indicates that the same pinning applies to this host as well as ''any subdomains of the host’s domain name''. Be careful - you need to use a multi-domain/wildcard-certificate or use the same pub/private-keypair in all subdomain-certificates or need to pin to CA-certificates signing all your subdomain-certificates.
=== CBC-Mode Entstehung von Mustern ===
* Rückschlüsse auf den Klartext
* Anders als der ECB-Mode (Electronic Code Book) verhindert der CBC-Mode (Cipher Block Chaining) bei Kryptografiealgorithmen die Entstehung von Mustern im Chiffrat,
* Dazu lässt CBC das Ergebnis der vorherigen Blockoperation in die aktuelle einfließen (Chaining)
* Sowohl ECB als auch CBC sind für so genannte Bit-Flipping-Attacken anfällig
* Angreifer versucht im Chiffrat einzelne Bit manipulieren
* ohne Kenntnis des Schlüssels
* ohne später beim Entschlüsseln durch den Empfänger einen Fehler zu provozieren
* auch für verschlüsselte Pakete die Integrität gesichert werden, etwa mit HMAC
* Da sich so der Inhalt manipulieren lässt
* In CBC werden jeweils Blöcke von jeweils 16 Datenbytes verschlüsselt
* Das CBC-Verfahren initialisiert mit einem zufällig gewählten 128 Bit langen Initialisierungsvektor
* wird bei ESP-Paket den chiffrierten Nutzdaten vorangestellt
* Da Daten blockweise verschlüsselt werden
* muss der letzte Datenblock mit Füll-Bytes zur vollen Blocklänge aufgefüllt
* die Anzahl dieser Stopf-Bytes wird im Längen-Byte festgehalten


'''report-uri''' is an optional directive. The presence of a report-uri directive indicates to the web-browser that in the event of pin-validation failure, it should post a report to the report-uri (HTTP-Post is done using JSON, Syntax see {RFC-7469 Section 3} [40]). There are WebServices like <nowiki>https://report-uri.io/</nowiki> out there which can be used to easily collect and visualize these reports.
== Vergleich: AES und 3DES ==


==== 25.2.2. HPKP Client Support ====
== IDEA ==
HPKP is supported [41] by these web browsers:


* Firefox version >= 35
=== Familie der Blockchiffrierung ===
* Chrome version between version 38 and 72
* jedoch wendet er 128 Bit Schlüssel auf 64 Bit Datenpakete des Klartextes an
* Android Browser >= 44
* Basiert auf einer Mischung 3 mathematischen Funktionen
* Opera version >= 25
* die jeweils auf 16 Bit Blöcke des Testes angewandt werden.
* Neben XOR kommt die Addition modulo 2^16 und die Multiplikation modulo 2^16+1 zum Einsatz
* Alle 3 Operationen werden zu einem recht komplizierten Netzwerk verknüpft, das 8 Runden durchlaufen wird
* Trotz komplizierter Verfahren, schneller und sicherer als DES


Currently (20. Dec 2018) there is no HPKP support in: Apple Safari, Microsoft Internet Explorer and Edge. HPKP Support has been removed from Google Chrome and Chromium from version 72 onwards.
== Hybride Kryptografieverfahren ==


==== 25.2.3. HPKP Considerations ====
=== Vorteile aus asymmetrischen und symmetrischen Kryptografie  ===
Before enabling HPKP it is recommended to consider following:
* Hohe Effizienz
* gesteigerte Sicherheit
* Flexibilität
* Austausch der erforderlichen Schlüssel
* erfolgt über ein asymmetrisches Verfahren
* Kryptografie größerer Datenmengen
* kommen symetrische Algorythmen zum Einsatz


* Which Public-Keys to use for Pinning (Certificate + Backup-Certificate, CAs, Intermediate-CAs)
== Vergleich Klassisch - Modern ==
* Proper value of ''max-age''. Start testing with a short Period, increase Period after deployment.
* Be careful when using ''includeSubdomains'', are all your subdomains covered by the defined Public-Key-Hashes?


The administrators are advised to watch for expiration of the SSL certificate and handle the renewal process with caution.
=== Sowohl die klassischen Verfahren wie Vigenère als auch die modernen Verfahren wie IDEA… ===
* …benötigen einen Schlüssel der beiden Parteien im Vornherein bekannt ist
* …sind symmetrisch (Entschlüsselung ist Umkehrung der Kryptografie)
* …sind in gewissen Masse anfällig auf Kryptoanalyse (z.&nbsp;B.&nbsp;Brute-Force)


If a SSL certificate is renewed without keeping the public-key (reusing the CSR) for an HPKP enabled domain name, the connection to site will break (without providing override mechanism to the end user).
== Fazit ==


==== 25.2.4. Testing HPKP ====
=== Die Geschichte der Kryptografie ist ein Wettbewerb  ===
HPKP can be tested either using locally or through the Internet.
* zwischen Kryptografiespezialisten und Kryptoanalysten
* Momentan liegen die Verschlüssler mit dem IDEA vorne
* da dieses Verfahren nur mit Brute-Force geknackt werden kann
* dies wegen der großen Schlüssellänge auch auf modernsten Computern noch zu lange dauert


There is a handy bash-script which uses OpenSSL for doing several SSL/TLS-Tests available at <nowiki>https://testssl.sh/</nowiki>
== Kryptografie ==
<code>$ wget -q <nowiki>https://testssl.sh/testssl.sh</nowiki></code>
<code>$ wget -q <nowiki>https://testssl.sh/mapping-rfc.txt</nowiki></code>
<code>$ chmod 755 ./testssl.sh</code>
<code>$ ./testssl.sh <nowiki>https://example.com</nowiki></code>
<code># Sample Output, just HSTS and HPKP Section (Full report is quite long!):</code>
<code>Strict Transport Security    182 days=15724800 s, includeSubDomains</code>
<code>Public Key Pinning # of keys: 2, 90 days=7776000 s, just this domain</code>
            <code>matching host key: pG3WsstDsfMkRdF3hBClXRKYxxKUJIOu8DwabG8MFrU</code>
For local testing it is possible to utilize Google Chrome web-browser, just open the Chrome net-internals-URL: chrome://net-internals/#hsts.


For Mozilla Firefox there is an plug-in provided by the "Secure Information Technology Center Austria" available: <nowiki>https://demo.a-sit.at/firefox-plugin-highlighting-safety-information/</nowiki>
<div style="text-align:center;margin-left:2cm;margin-right:0cm;">Geschwindigkeit</div>


Testing over the Internet can be conducted by Qualys SSL Labs test <nowiki>https://www.ssllabs.com/ssltest/</nowiki>. ''Public Key Pinning (HPKP)'' information is located in the ''Protocol Details'' section.
== Geschwindigkeit ==


There is also a fast online HPKP-only check at <nowiki>https://report-uri.io/home/pkp_analyse</nowiki>.
== Geschwindigkeit ==


==== 25.2.5. References ====
== Geschwindigkeit ==


* OWASP: Certificate and Public Key Pinning: <nowiki>https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning</nowiki>
== Geschwindigkeit ==
* HPKP Browser Compatibility List: <nowiki>https://caniuse.com/\#feat=publickeypinning</nowiki>
* <nowiki>RFC 7469</nowiki>:Public Key Pinning Extension for HTTP - Examples: <nowiki>https://tools.ietf.org/html/rfc7469\#section-2.1.5</nowiki>

Aktuelle Version vom 27. Juli 2024, 10:37 Uhr

Motivation

siehe Kryptografie/Motivation

Geheime Übermittlung

Voraussetzungen

  • Der Empfänger kennt den Schlüssel
  • aber sonst niemand
  • Ohne Kenntnis des Schlüssels
  • ist es unmöglich oder sehr schwierig den Klartext herauszufinden

Schwierigkeiten

  • Schlüssel muss vorher vereinbart werden
  • Schlüssel muss geheim bleiben „geheimer Kanal“
  • Das Kryptografieverfahren muss sicher sein

Vorhängeschloss-Analogie

  • Der Klartext ist „eingeschlossen“, und nur Alice und Bob haben den richtigen Schlüssel für das Schloss.

Kryptographisches Grundprinzip

Umwandlung eines Klartextes

  • (p, plain text) in einem chiffrierten Text (c, ciphertext)
  • mit Hilfe einer reversiblen kryptographischen Funktion f:

symmetrische und asymmetrische Algorithmen

  • Kryptografie / Entschlüsselung
  • Schlüssel als zusätzliches Argument zu Funktion f

Verschlüsseln mit symmetrischen Verfahren

Kryptografie und Entschlüsselung mit selbem Schlüssel

  • DES, IDEA
  • Effizient, aber Schlüsselaustauschproblem

Ver- und Entschlüsselung mit symmetrischer Kryptografie

Symmetrische Substitution

Sender und Empfänger müssen den gleichen Schlüssel besitzen

  • um miteinander Kommunizieren zu können
  • Secret-Key-Verfahren
  • Eignet sich gut, um große Datenmengen zu verschlüsseln
  • Nachteil
  • Um die Nachricht verwerten zu können, muss der Schlüssel mit übertragen werden
  • was einen Schwachpunkt darstellt

Symmetrische Substitutionsverfahren

Klassifizierungen

  • Zeichenchiffren
  • Blockchiffren
  • Stromchiffren
  • Zeichenchiffrierung
  • Ermittelt jedes Zeichen des Geheimtextes aus dem entsprechenden Zeichen des Klartextes mit Hilfe des Schlüssels
  • Cäsar-Addition
  • Stromchiffrierung
  • Der Klartext wird Byte-weise über eine XOR-Operation verschlüsselt
  • Sie Erzeugt eine sich zyklisch verändernde Byte-Folge, die mit dem Klartext verknüpft wird
  • Blockchiffrierung
  • Klartext wird in Bitgruppen geteilt
  • über mehrstufige Verfahren mit dem Schlüssel über gleichbleibende Operationen in Geheimtext umgewandelt
  • DES

Asymmetrischer Kryptografie/public key-Kryptografie

Public Key Kryptografie

Ver- und Entschlüsselung mit verschiedenen Schlüsseln

  • “Vergleichbar mit einem Briefkasten - jeder kann etwas hinein werfen, aber nur einer kann es herausnehmen.”
  • Schlüssel-Paare: Öffentlicher und privater Schlüssel
  • z. B. : RSA, ElGamal, Elliptische Kurven (ECC)
  • Problem
  • Meist ineffizienter als symmetrische Verfahren
  • deshalb häufig nur zum Austausch symmetrischer Schlüssel und für Unterschriften
  • Der private Schlüssel darf aus dem öffentlichen nicht errechenbar sein
  • Einwegfunktion mit Falltür
  • Nur unter Kenntnis einer zusätzlichen Information effizient umkehrbar
  • z. B. x = loga y mod n (RSA-Verfahren) unter Kenntnis der Primfaktoren

Asymmetrische Substitution

  • Es werden 2 komplementäre Schlüssel benötigt
  • 1 Key zum chiffrieren der Nachricht
  • 2 Key zum dechiffrieren der Nachricht
  • Einer der Schlüssel kann gefahrlos öffentlich bekannt gegeben werden (Public-Key)
  • Wird mit einem Schlüssel chiffriert
  • kann nur mit dem anderen Schlüssel dechiffriert werden

Vorteile von Public-Key-Verfahren

  • Jeder Kommunikationspartner benötigt einen Schlüssel
  • seinen Private Key
  • Der zweite Schlüssel wird veröffentlicht
  • Nachteil
  • Hohe Komplexität der durchzuführenden Operationen
  • Die Multiplikation 2 Zahlen stellt eine einfache Operation dar
  • während der umgekehrte Vorgang, also die Faktorzerlegung eines Produkts, einen enormen Rechenaufwand bedeuten kann

Absicherung der asymmetrischen Substitution

  • Schwäche
  • keine eindeutige Zuordnung des öffentlichen Schlüssels zu seinem Besitzer
  • Ein „Man-in-the-Middle“ könnte sich dazwischen schalten und die Nachrichten unbemerkt entschlüsseln
  • Informationen des öffentlichen Schlüssels und seines Besitzers sollten aus vertrauenswürdiger Quelle stammen
  • Möglichkeiten im Rahmen der Public Key Infrastructure (PKI)
  • Schlüssel kann über ein sicher betrachtetes Medium übertragen werden
  • Beispiel
  • Persönliche Übergabe, Telefon, Brief, Fax
  • Identität des Schlüsselinhabers Zertifizieren lassen

Trust Center

Certification Authority [CA]

  • Zertifizierungsinstanz (Trust Center)
  • Zur Überprüfung der Schlüsselinhaber
  • Sender und Empfänger verwalten Listen von Zertifizierungsinstanzen
  • Überprüfung Zusammenhang öffentlicher Schlüssel und deren Absender
  • Zertifikat nach ITU-Standard X.509
  • ALTERNATIVE
  • Authentizität eines öffentlichen Schlüssels durch einen bekannten Kommunikationspartner bestätigen lassen
  • „Web of True“ von PGP

Substitution vs. Signatur

  • Algorithmen asymetrischer Kryptografieen unterscheiden sich
  • ob eine Nachricht verschlüsselt oder signiet werden soll

Substitution

  • Absender verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des Empfängers
  • so, dass er sie mit seinem privaten Schlüssel wieder im Klartext lesen kann

Signatur

  • Absender erzeugt mit seinem privatem Schlüssel eine Signatur
  • Empfänger kann durch Verwendung des öffentlichen Schlüssel des Absenders die Nachricht verifiziert

Tunneling

siehe Kryptografie/Tunneling

Wie baut man eine sicheren Block Cipher?

Probleme bei der Entwicklung von Kryptografieverfahren

Vertraulichkeit Schutz der Daten vor unberechtigter Einsichtnahme
Authentisierung Sicherstellung der Herkunft, Verbindlichkeit
Anonymität Schutz vor Bekanntwerden des Absenders und Empfängers
Integrität Unveränderlichkeit von Daten und Verlässlichkeit von Programmen

Mary Stuart 1516 - 1558

Bekanntes Opfer der Kryptoanalye

Shannon‘s Principle of Confusion

Substitution Cipher

Shannon‘s Principle of Diffusion

Transposition Cipher

Symmetrische Kryptografieverfahren

Einfachster Einsatz

  • basiert auf der logischen Exklusiv-Oder-Funktion
  • 2 XOR Verknüpfung eines A Zeichens mit einem B hat wieder das ursprüngliche Zeichen A zum Ergebnis
  • Es entspricht also der Inversen Verknüpfung:
  • (A+B)+B=A+(B+B)Assoziativgesetz=A+0Eigenschaft von XOR=AEigenschaft von XOR
  • Der Sender verschlüsselt ein Zeichen A mit einem Schlüssel B per XOR und versendet das Ergebnis
  • Der Empfänger verknüpft das Ergebnis erneut mit Schlüssel B und erhält dann wieder das Zeichen A

Symmetric Algorithms: Block Ciphers

Some Popular Block Ciphers

Symmetric Algorithms: Stream Ciphers

RC4

RC Rivest Cipher

  • Stromverschlüsselungsverfahren
  • Basiert auf XOR-Verknüpfung
  • Sehr schnell und einfach
  • Eignet sich gut in Software
  • Der Algorythmus macht aus dem eingegebenen Schlüssel S einen langen, pseudo-zufälligen internen Schlüssel P
  • Dieser wird zur Chiffrierung des Klartextes verwendet
  • RC4 Speichert 258 verschiedene Zusatzinformationen
  • 256 sind Permutationen von 0-255 und somit gleich verteilt

DES

Familie der Blockchiffren

  • Teilt eine Nachricht in 64 Bit große Datenblöcke
  • 3 bearbeitungsschritte werden benötigt, um den Klartext wieder herzustellen.
  • Am weitesten verbreiteter Algorythmus, auch wenn nicht mehr ganz Zeitgemäß
  • Nachfolger: 3DES
  • Wird in Finanzdienstleistungen eingesetzt und führt die Kryptografie 3 mal hintereinander aus

Data Encryption Standard (DES)Sicherheit von DES

  • DES
  • erlaubt mit 56 Bit Schlüssellänge
  • 72 Billiarden mögliche Schlüssel
  • ist heute nicht mehr ausreichend
  • per Brute-Force in 5 Tagen (?) geknackt

Permutation

  • DES besteht aus 3 Bearbeitungsschritten
  • Initiale Permutation
  • Ver-/Entschlüsselung in mehreren Runden
  • finale Permutation
  • DES wurde in den 70er Jahren zur Implementation in Hardware entwickelt
  • durch die damals noch kleinen CPU Register
  • Finale Permutation = Inverse der initialen Permutation
  • Nach der Durchführung der initialen und finalen Permutation, steht ein Bit wieder an ursprünglicher Stelle
Kryptografie
  • DES basiert auf einer 64 Bit Kryptografie
  • wovon jedoch nur 56 Bit kryptographisch relevant sind
  • Jedes 8 Bit = Parity-Bit
  • DES erzeugt 16 verschiedene 48 Bit lange Schlüssel
  • Es werden aus 56 relevanten Bit mit einer Permutation 2 28 Bit Muster generiert (C[i-1] und D[i-1]).
  • Die Teilschlüssel werden nun um 1 oder 2 Bit nach links rotiert.
  • Die erzeugten Schlüssel C[i] und D[i] werden zu C[i-1] und D[i-1].
  • 2 24Bit Folgen aus C[i] und D[i] werden zum Schlüssel K[n]

Kryptografie

  • DES teilt den Klartext in 64 Bit Blöcke und
  • splittet sie nochmal in 2 32 Bit lange Bestandteile (L[n] und R[n]).
  • R[n] wird über eine Mangler-Funktion ,mittels tabellenbasierter Umrechnung auf Grundlage der Eingangsvariable R[n] und des Schlüssels K[n], vermischt.

Genügen 128 Bit?

  • IDEA
  • International Data Encryption Algorithm
  • arbeitet mit 128 Bit Schlüssellänge, sonst ähnlich wie der DES
  • 3.43669 * 1038
  • knacken benötigt etwa 1012 Jahre
  • Daher gilt der IDEA heute als sicher

Asymmetrische Kryptografieverfahren

Setzen auf 2 unterschiedliche Schlüssel

  • Privater Schlüssel (privat key) [Dechiffriert-Algorythmisch]
  • Öffentlicher Schlüssel (public key) [Chiffriert-Algorythmisch]
  • Es lässt sich nicht vom public key auf den private key schließen
  • Der public key kann von Dritten zur Kryptografie von Informationen genutzt werden
  • die der Besitzer des private keys nur entschlüsseln kann

Bekanntester Vertreter

  • RSA-Algorythmus
  • Die Multiplikation 2er Zahlen stellt eine einfache Operation dar
  • während der umgekehrt Vorgang eine enorme Rechenleistung bedeutet

RSA

Basiert auf folgenden 4 Schritten

  • Wähle 2 große Primzahlen p und q, die geheim bleiben
  • Berechne das Produkt n = p*q
  • Für öffentlichen Schlüssel wähle e < n
  • die teilerfremd zur Eulerschen Funktion E(n) = (p-1)*(q-1) ist
  • Für privaten Schlüssel bestimme eine Zahl
  • d = e^-1 mod E(n)
  • Dann gilt
  • e*d = 1 mod E(n)
  • [d,n] ist der private Schlüssel

Algorithmus bei der Kryptografie

  • Alice verschlüsselt
  • ihren Klartext m gemäß c = m^e mod n und
  • sendet ihn an Bob.
  • In diesem Fall ist [e,n] der öffentliche Schlüssel von Bob
  • Bob entschlüsselt
  • den Geheimtext c mit seinem privaten Schlüssel [d,n] gemäß m = c^d mod n
  • und erhält auf Grund des Zusammenhangs von d und e den Klartext m
  • Der Empfänger führt bei der Entschlüsselung die gleiche Operation wie der Sender bei der Kryptografie durch
  • Algorythmus zur Erzeugung und Überprüfung von Signaturen
  • Alice sendet eine signierte Nachricht, indem sie s = m^d mod n erzeugt und überträgt
  • [d,n] = Privater Schlüssen von Alice
  • Bob entschlüsselt die Signatur gemäß m = s^e mod n und erhält auf Grund des Zusammenhangs von d und e den Klartext m
  • [e,n] = öffentlicher Schlüssel von Alice

Advanced Encryption Standard

  • Nachfolgestandard für DES
  • 3DES mit 128 Bit gilt noch als sicher
  • wegen der Dreifachverschlüsselung deutlich langsamer als AES
  • AES unterstützt 128, 192 und 256 Bit lange Schlüssel
  • Beispiel Hamachi
  • AES mit 256 Bit Schlüssellänge
  • im Modus Cipher-Block-Chaining

Advanced Encryption Standard (AES)http://www.nist.gov/aes

  • DES is nearly 25 years old!
  • Triple DES with a 168 bit key is the current Federal Information Processing Standard FIPS 46-3 (renewed in October 1999).
  • Single DES with 56 bit key is permitted for legacy systems only.
  • Evaluation of an Advanced Encryption Standard
  • The National Institute of Standards and Technology (NIST,U.S. Department of Commerce) started a public contest in 1997.
  • 5 final candidate algorithms. Decision by NIST in Spring 2001
  • Requirements for AES
  • AES shall be publicly defined.
  • AES shall be a symmetric block cipher.
  • AES shall be implementable in both hardware and software.
  • AES shall be designed so that the key length may be increased as needed.
  • AES block size n = 128 bits, key size k = 128, 192, 256 bits

AES Round 2 Finalists

  • MARS(IBM)
  • Modified Feistel Network - 32 Rounds
  • Based on Mixed Structure DES
  • RC6 (RSA)
  • Feistel Network - 20 Rounds
  • Based on Modified RC5
  • Rijndal(Joan Daemen / Vincent Rijmen)
  • Modified Substitution Permutation Network - 10 Rounds
  • Based on Square
  • Serpent (Ross Anderson / Eli Biham / Lars Knudsen)
  • Substitution Permutation Network - 32 Rounds
  • Based on Bitlice Operations
  • Twofish(Bruce Schneier)
  • Feistel Network - 16 Rounds
  • Based on Modified Blowfish

Cipher Block Chaining (CBC)

  • Um eine Frquenzanalyse zu verhindern wird eine Verkettung von Datenblöcken durchgeführt
  • Dabei wird der zu verschlüsselnde Datenblock exklusiv mit dem letzten verschlüsselten Datenblock verknüpft
  • Gleiche Datenblöcke werden so unterschiedlich modifiziert und unterschiedlich verschlüsselt
  • Problem: Erste Datenblock
  • Erzeugung eines Initialisierungs-Vekros (IV)
  • Der IV wird zur Entschlüsselung benötigt
  • daher wird er dem Empfänger übermittelt
  • Vertraulichkeit ist nicht erforderlich
  • IPsec – Protokolle übertragen den IV in jedem Datenpaket

Advanced Encryption Standard

CBC-Mode Entstehung von Mustern

  • Rückschlüsse auf den Klartext
  • Anders als der ECB-Mode (Electronic Code Book) verhindert der CBC-Mode (Cipher Block Chaining) bei Kryptografiealgorithmen die Entstehung von Mustern im Chiffrat,
  • Dazu lässt CBC das Ergebnis der vorherigen Blockoperation in die aktuelle einfließen (Chaining)
  • Sowohl ECB als auch CBC sind für so genannte Bit-Flipping-Attacken anfällig
  • Angreifer versucht im Chiffrat einzelne Bit manipulieren
  • ohne Kenntnis des Schlüssels
  • ohne später beim Entschlüsseln durch den Empfänger einen Fehler zu provozieren
  • auch für verschlüsselte Pakete die Integrität gesichert werden, etwa mit HMAC
  • Da sich so der Inhalt manipulieren lässt
  • In CBC werden jeweils Blöcke von jeweils 16 Datenbytes verschlüsselt
  • Das CBC-Verfahren initialisiert mit einem zufällig gewählten 128 Bit langen Initialisierungsvektor
  • wird bei ESP-Paket den chiffrierten Nutzdaten vorangestellt
  • Da Daten blockweise verschlüsselt werden
  • muss der letzte Datenblock mit Füll-Bytes zur vollen Blocklänge aufgefüllt
  • die Anzahl dieser Stopf-Bytes wird im Längen-Byte festgehalten

Vergleich: AES und 3DES

IDEA

Familie der Blockchiffrierung

  • jedoch wendet er 128 Bit Schlüssel auf 64 Bit Datenpakete des Klartextes an
  • Basiert auf einer Mischung 3 mathematischen Funktionen
  • die jeweils auf 16 Bit Blöcke des Testes angewandt werden.
  • Neben XOR kommt die Addition modulo 2^16 und die Multiplikation modulo 2^16+1 zum Einsatz
  • Alle 3 Operationen werden zu einem recht komplizierten Netzwerk verknüpft, das 8 Runden durchlaufen wird
  • Trotz komplizierter Verfahren, schneller und sicherer als DES

Hybride Kryptografieverfahren

Vorteile aus asymmetrischen und symmetrischen Kryptografie

  • Hohe Effizienz
  • gesteigerte Sicherheit
  • Flexibilität
  • Austausch der erforderlichen Schlüssel
  • erfolgt über ein asymmetrisches Verfahren
  • Kryptografie größerer Datenmengen
  • kommen symetrische Algorythmen zum Einsatz

Vergleich Klassisch - Modern

Sowohl die klassischen Verfahren wie Vigenère als auch die modernen Verfahren wie IDEA…

  • …benötigen einen Schlüssel der beiden Parteien im Vornherein bekannt ist
  • …sind symmetrisch (Entschlüsselung ist Umkehrung der Kryptografie)
  • …sind in gewissen Masse anfällig auf Kryptoanalyse (z. B. Brute-Force)

Fazit

Die Geschichte der Kryptografie ist ein Wettbewerb

  • zwischen Kryptografiespezialisten und Kryptoanalysten
  • Momentan liegen die Verschlüssler mit dem IDEA vorne
  • da dieses Verfahren nur mit Brute-Force geknackt werden kann
  • dies wegen der großen Schlüssellänge auch auf modernsten Computern noch zu lange dauert

TMP

Abstract

  • Unfortunately, the computer security and cryptology communities have drifted apart over the last 25 years. Security people don’t always understand the available crypto tools, and crypto people don’t always understand the real-world problems.
  • — Ross Anderson (Anderson, 2008)
  • This guide arose out of the need for system administrators to have an updated, solid, well researched and thought-through guide for configuring SSL, PGP, SSH and other cryptographic tools in the post-Snowden age. Triggered by the NSA leaks in the summer of 2013, many system administrators and IT security officers saw the need to strengthen their encryption settings. This guide is specifically written for these system administrators.
  • As Schneier noted in (Schneier, 2013), it seems that intelligence agencies and adversaries on the Internet are not breaking so much the mathematics of encryption per se, but rather use software and hardware weaknesses, subvert standardization processes, plant backdoors, rig random number generators and most of all exploit careless settings in server configurations and encryption systems to listen in on private communications. Worst of all, most communication on the internet is not encrypted at all by default (for SMTP, opportunistic TLS would be a solution).
  • This guide can only address one aspect of securing our information systems: getting the crypto settings right to the best of the authors' current knowledge. Other attacks, as the above mentioned, require different protection schemes which are not covered in this guide. This guide is not an introduction to cryptography. For background information on cryptography and cryptoanalysis we would like to refer the reader to the references in appendix Links and Suggested Reading at the end of this document.
  • The focus of this guide is merely to give current best practices for configuring complex cipher suites and related parameters in a copy & paste-able manner. The guide tries to stay as concise as is possible for such a complex topic as cryptography. Naturally, it can not be complete. There are many excellent guides (II & SYM, 2012) and best practice documents available when it comes to cryptography. However none of them focuses specifically on what an average system administrator needs for hardening his or her systems' crypto settings.
  • This guide tries to fill this gap.
The guide was produced in an open source manner
every step of editing can be traced back to a specific author via our version control system.

Introduction

Audience

Sysadmins. Sysadmins. Sysadmins. They are a force-multiplier.

Related publications

How to read this guide

  • This guide tries to accommodate two needs: first of all, having a handy reference on how to configure the most common services’ crypto settings and second of all, explain a bit of background on cryptography. This background is essential if the reader wants to choose his or her own cipher string settings.
  • System administrators who want to copy & paste recommendations quickly without spending a lot of time on background reading on cryptography or cryptanalysis can do so, by simply searching for the corresponding section in Best Practice.
  • It is important to know that in this guide the authors arrived at two recommendations: Cipher string A and Cipher string B. While the former is a hardened recommendation a latter is a weaker one but provides wider compatibility. Cipher strings A and B are described in Recommended cipher suites.
  • However, for the quick copy & paste approach it is important to know that this guide assumes users are happy with Cipher string B.
  • While Best Practice is intended to serve as a copy & paste reference, Theory explains the reasoning behind cipher string B. In particular Architectural overview explains how to choose individual cipher strings. We advise the reader to actually read this section and challenge our reasoning in choosing Cipher string B and to come up with a better or localized solution.

Disclaimer

  • A chain is no stronger than its weakest link, and life is after all a chain.
  • — William James
  • Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it.
  • — Edward Snowden answering questions live on the Guardian’s website
  • This guide specifically does not address physical security, protecting software and hardware against exploits, basic IT security housekeeping, information assurance techniques, traffic analysis attacks, issues with key-roll over and key management, securing client PCs and mobile devices (theft, loss), proper Operations Security, social engineering attacks, protection against tempest (i_wikipedia_Tempest (codename)_, 2018) attack techniques, thwarting different side-channel attacks (timing–, cache timing–, differential fault analysis, differential power analysis or power monitoring attacks), downgrade attacks, jamming the encrypted channel or other similar attacks which are typically employed to circumvent strong encryption.
  • The authors can not overstate the importance of these other techniques. Interested readers are advised to read about these attacks in detail since they give a lot of insight into other parts of cryptography engineering which need to be dealt with[1]) ].
  • This guide does not talk much about the well-known insecurities of trusting a public-key infrastructure (PKI)[2]. Nor does this text fully explain how to run your own Certificate Authority (CA).
  • Most of this zoo of information security issues are addressed in the very comprehensive book Security Engineering by Ross Anderson (Anderson, 2008).
  • For some experts in cryptography this text might seem too informal. However, we strive to keep the language as non-technical as possible and fitting for our target audience: system administrators who can collectively improve the security level for all of their users.
  • Security is a process, not a product.
  • — Bruce Schneier
  • This guide can only describe what the authors currently believe to be the best settings based on their personal experience and after intensive cross checking with literature and experts. For a complete list of people who reviewed this paper, see the <acknowledgements>. Even though multiple specialists reviewed the guide, the authors can give no guarantee whatsoever that they made the right recommendations. Keep in mind that tomorrow there might be new attacks on some ciphers and many of the recommendations in this guide might turn out to be wrong. Security is a process.
  • We therefore recommend that system administrators keep up to date with recent topics in IT security and cryptography.
  • In this sense, this guide is very focused on getting the cipher strings done right even though there is much more to do in order to make a system more secure. We the authors, need this document as much as the reader needs it.

Scope

In this guide, we restricted ourselves to:* Internet-facing services

  • Commonly used services
  • Devices which are used in business environments (this specifically excludes XBoxes, Playstations and similar consumer devices)
  • OpenSSL

We explicitly excluded:* Specialized systems such as medical devices, most embedded systems, industrial control systems (ICS), etc.

  • Wireless Access Points
  • Smart-cards/chip cards

Methods

  1. C.O.S.H.E.R - completely open source, headers, engineering and research.
  2. — A. Kaplan His mail signature for many years
  3. For writing this guide, we chose to collect the most well researched facts about cryptography settings and let as many trusted specialists as possible review those settings. The review process is completely open and done on a public mailing list.
  4. The document is available (read-only) to the public Internet on the web page and the source code of this document is on a public git server, mirrored on GitHub.com and open for public scrutiny. However, write permissions to the document are only granted to vetted people. The list of reviewers can be found in Acknowledgements.
  5. Every write operation to the document is logged via the git version control system and can thus be traced back to a specific author. We accept git pull requests on the github mirror for this paper.
  6. Public peer-review and multiple eyes checking of our guide is the best strategy we can imagine at the present moment [3].
  7. We invite the gentle reader to participate in this public review process. Please read the Contributing document.

Appendix

Links

  1. IANA official list of Transport Layer Security (TLS) Parameters
  2. Elliptic curves and their implementation (04 Dec 2010)
  3. A (relatively easy to understand) primer on elliptic curve cryptography
  4. Duraconf, A collection of hardened configuration files for SSL/TLSservices (Jacob Appelbaum’s github)
  5. Attacks on SSL a comprehensive study of BEAST, CRIME, TIME, BREACH, LUCKY 13 & RC4 Biases
  6. EFF How to deploy HTTPS correctly
  7. Bruce Almighty: Schneier preaches security to Linux faithful (on not recommending to use Blowfish anymore in favor of Twofish)
  8. Implement FIPS 183-3 for DSA keys (1024bit constraint)
  9. Elliptic Curve Cryptography in Practice
  10. Factoring as a Service
  11. Black Ops of TCP/IP 2012
  12. SSL and the Future of Authenticity, Moxie Marlinspike - Black Hat USA 2011
  13. ENISA - Algorithms, Key Sizes and Parameters Report (Oct.’13
  14. Diffie-Hellman Groups standardized in RFC3526
  15. TLS Security (Survey + Lucky13 + RC4 Attack) by Kenny Paterson
  16. Ensuring High-Quality Randomness in Cryptographic Key Generation
  17. Wikipedia: Ciphertext Stealing
  18. Wikipedia: Malleability (Cryptography)
  19. Ritter’s Crypto Glossary and Dictionary of Technical Cryptography

Suggested Reading

  1. This section contains suggested reading material.
  2. Cryptography Engineering: Design Principles and Practical Applications, Ferguson, N. and Schneier, B. and Kohno, T. (ISBN-13: 978-0470474242)
  3. Security Engineering: A Guide to Building Dependable Distributed Systems, Anderson, R.J. (ISBN-13: 978-0470068526)
  4. Applied cryptography: protocols, algorithms, and source code in C, Schneier, B. (ISBN-13: 978-0471117094)
  5. Guide to Elliptic Curve Cryptography, Hankerson, D. and Vanstone, S. and Menezes, A.J. (ISBN-13: 978-0387952734)
  6. A Introduction To The Theory of Numbers, Godfrey Harold Hardy, E. M. Wrigh (ISBN-13: 978-0199219865)
  7. Malicious Cryptography: Exposing Cryptovirology, Young A., Yung, M. (ISBN-13: 978-0764549755)

Further Research

The following is a list of services, software packages, hardware devices or protocols that we considered documenting but either did not manage to document yet or might be able to document later. We encourage input from the community.

Further Protocols
DNSSec (mention BCPs) DANE Tor
S/Mime (check are there any BCPs? ) TrueCrypt, LUKS, FileVault AFS
Kerberos NNTP NTPs tlsdate
Moxa , APC, und co…​ ICS
rsyslog tftp (s)ftp(s)
haproxy
Further Protocols (Network centric)
IPv6 security
Wi-Fi, 802.1x SIP SRTP
Kerberos NNTP NTPs tlsdate
BGP / OSPF LDAP seclayer-tcp
RADIUS (RADSEC) racoon strongswan
l2tp
Ethernet to serial DSL modems
UPnP, natPmp
HTTP Key Pinning (HTKP)
Monitoring: SNMPv3
Further Applications
Lync Tomcat
Microsoft SQL Server Microsoft Exchange
IBM HTTP Server
Commerical Network Equipment Vendors

Other ideas:

  • SAML federated auth providers [42]
  • Elastic Load Balancing (ELB)[43]

Software not covered by this guide

  1. telnet: Usage of telnet for anything other than fun projects is highly discouraged
  2. Puppet DB: A Proxy or a tunnel is recommended if it needs to be facing public network interfaces.[44]
  3. rsync: Best use it only via SSH for an optimum of security and easiest to maintain.

Bibliography

  1. Adam Langley, Ben Laurie, Emilia Kasper. (2013). Certificate Transparency. http://www.certificate-transparency.org https://datatracker.ietf.org/doc/rfc6962/ .
  2. Adam Langley, et. al. (2013). Go X.509 Verification Source Code. https://code.google.com/p/go/source/browse/src/pkg/crypto/x509/verify.go#173 .
  3. Anderson, R. (2008). Security engineering. Wiley.com. Retrieved from rja14/book.html http://www.cl.cam.ac.uk/ rja14/book.html
  4. Bernstein, D. J., & Lange, T. (2013). Security dangers of the NIST curves (Presentation slides). Retrieved from http://cr.yp.to/talks/2013.09.16/slides-djb-20130916-a4.pdf
  5. C. Evans and C. Palmer. (2013). Public Key Pinning Extension for HTTP. https://tools.ietf.org/html/draft-ietf-websec-key-pinning-09 .
  6. Damon Poeter. (2011). Fake Google Certificate Puts Gmail at Risk. http://www.pcmag.com/article2/0,2817,2392063,00.asp .
  7. Durumeric, Z., Kasten, J., Bailey, M., & Halderman, J. A. (2013). Analysis of the HTTPS Certificate Ecosystem. In Proceedings of the 13th Internet Measurement Conference. Retrieved from https://jhalderm.com/pub/papers/https-imc13.pdf
  8. Elinor Mills. (2011). Fraudulent Google certificate points to Internet attack. http://news.cnet.com/8301-27080_3-20098894-245/fraudulent-google-certificate-points-to-internet-attack/ .
  9. Engblom, J. (2011). Evaluating HAVEGE Randomness (Blog: Observations from Uppsala). Retrieved from http://jakob.engbloms.se/archives/1374
  10. ENISA and Vincent Rijmen, Nigel P. Smart, Bogdan warinschi, Gaven Watson. (2013). ENISA - Algorithms, Key Sizes and Parameters Report. Retrieved from http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report
  11. für Sicherheit in der Informationstechnik (BSI), B. (2018). BSI TR-02102 Kryptographische Verfahren. Retrieved from https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/tr02102_node.html
  12. H. Tschofenig and E. Lear. (2013). Evolving the Web Public Key Infrastructure. https://tools.ietf.org/html/draft-tschofenig-iab-webpki-evolution-01.txt .
  13. Heninger, N., Durumeric, Z., Wustrow, E., & Halderman, J. A. (2012). Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices. In Proceedings of the 21st USENIX Security Symposium. Retrieved from https://factorable.net/weakkeys12.extended.pdf
  14. Hoffman, P., & Schlyter, J. (2012). The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. IETF. Retrieved from https://www.ietf.org/rfc/rfc6698.txt
  15. i_mit_Realm configuration decisions_. (2013). (Documentation). Retrieved from http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html
  16. i_wikipedia_Discrete logarithm_. (2013). (Wikipedia). Retrieved from https://en.wikipedia.org/wiki/Discrete_logarithm
  17. i_wikipedia_Tempest (codename). (2018). (Wikipedia). Retrieved from https://en.wikipedia.org/wiki/Tempest(codename)
  18. II, E. C. R. Y. P. T., & SYM, D. (2012). ECRYPT II, 79–86. Retrieved from http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf
  19. Katz, J., & Lindell, Y. (2008). Introduction to modern cryptography. Chapman & Hall/CRC. Retrieved from http://books.google.at/books?id=WIc_AQAAIAAJ
  20. Kivinen, T., & Kojo, M. (2003). More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). IETF. Retrieved from https://www.ietf.org/rfc/rfc3526.txt
  21. Postel, J. (1980). DoD standard Transmission Control Protocol. IETF. Retrieved from https://www.ietf.org/rfc/rfc761.txt
  22. Raeburn, K. (2005). Advanced Encryption Standard (AES) Encryption for Kerberos 5. IETF. Retrieved from https://www.ietf.org/rfc/rfc3962.txt
  23. SafeCurves: choosing safe curves for elliptic-curve cryptography. (2013). (Technical Background). Retrieved from http://safecurves.cr.yp.to/rigid.html
  24. Schneier, B. (2013). The NSA Is Breaking Most Encryption on the Internet (Blog: Schneier on Security). Retrieved from https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html
  25. Yarom, Y., & Falkner, K. (2013). Flush+ Reload: a high resolution, low noise, L3 cache side-channel attack. Cryptology ePrint Archive, Report 2013/448, 2013. http://eprint. iacr. org/2013/448/. 3. Retrieved from http://eprint.iacr.org/2013/448.pdf

Weblinks

  1. https://bettercrypto.org/

Kryptografie

Geheime Kommunikation von Caesar bis 1950

Monoalphabetische Substitution Caesar-Chiffre

Skytale

Der Skytale verwendet einen Transpositions-Algorithmus

Atbash und Rot-13

Bei Atbash wird der erste Buchstabe durch den letzten ausgetauscht

Julius Cäsar verwendete das Verfahren Rot-13

Kryptografie mit der Vigenere Tabelle

Geheime Kommunikation von 1950 bis heute

Kryptografie

Grundlagen

Kryptografie - Terminologie

Teilbereiche der Kryptografie

Kryptografie

  • Durchführung und Studium Ver- und Entschlüsselung
  • Daten werden mathematisch so kodiert, dass nur ausgewählte Personen die Daten decodieren können
  • Dazu werden lesbare Daten (Klartext) durch einen mathematischen Algorithmus mit einem geheimen Schlüssel kodiert (Chiffretext)
  • Ziel ist eine möglichst sichere Kryptografie

Kryptoanalyse

  • Hier ist das Ziel eine Kryptografie zu brechen und so
  • Sicherheitslücken zu entdecken

Das Problem

Nur Bob soll die Nachricht von Alice empfangen können…

Die Lösung

Klassische Kryptografie

  • Der Klartext (K) wird mittels eines Schlüssels verschlüsselt.
  • Mithilfe desselben Schlüssels kann der Geheimtext (G) wieder entschlüsselt werden.

Kryptografie - Terminologie (II)

Geheime Übermittlung

Voraussetzungen

  • Der Empfänger kennt den Schlüssel
  • aber sonst niemand
  • Ohne Kenntnis des Schlüssels
  • ist es unmöglich oder sehr schwierig den Klartext herauszufinden

Schwierigkeiten

  • Schlüssel muss vorher vereinbart werden
  • Schlüssel muss geheim bleiben, „geheimer Kanal“
  • Das Kryptografieverfahren muss sicher sein

Vorhängeschloss-Analogie

  • Der Klartext ist „eingeschlossen“, und nur Alice und Bob haben den richtigen Schlüssel für das Schloss.

Kryptographisches Grundprinzip

Umwandlung eines Klartextes

  • (p, plain text) in einem chiffrierten Text (c, ciphertext)
  • mithilfe einer reversiblen kryptografischen Funktion f:

symmetrische und asymmetrische Algorithmen

  • Kryptografie / Entschlüsselung
  • Schlüssel als zusätzliches Argument zu Funktion f

Verschlüsseln mit symmetrischen Verfahren

Kryptografie und Entschlüsselung mit selbem Schlüssel

  • z. B. : DES, IDEA
  • Effizient, aber Schlüsselaustauschproblem

Ver- und Entschlüsselung mit symmetrischer Kryptografie

Man-in-the-Middle

  • Der Man-in-the-Middle (Mellory)
  • schaltet sich zwischen eine Kommunikation
  • fängt die gesendeten Datenpakete ab
  • Diese kann er nun entschlüsseln, verändern, verschlüsseln und unbemerkt an den Empfänger weiterleiten
  • Alice und Bob glauben direkt miteinander zu kommunizieren
  • Dies ist jedoch nur möglich, wenn der Mellory die Möglichkeit hatte, an der Verteilung der öffentlich Schlüssel eine Manipulation vorzunehmen
  • Wird der Schlüssel über ein zuverlässiges Medium übertragen
  • ist der Diffie-Hellman-Algorythmus gegen solche Angriffe geschützt

Asymmetrischer Kryptografiepublic key-Kryptografie

Asymmetrischer Kryptografiepublic key-Kryptografie

Public Key Kryptografie

Ver- und Entschlüsselung mit verschiedenen Schlüsseln

  • “Vergleichbar mit einem Briefkasten - jeder kann etwas hinein werfen, aber nur einer kann es herausnehmen.”
  • Schlüssel-Paare: Öffentlicher und privater Schlüssel
  • z. B. : RSA, ElGamal, Elliptische Kurven (ECC)
  • Problem
  • Meist ineffizienter als symmetrische Verfahren
  • deshalb häufig nur zum Austausch symmetrischer Schlüssel und für Unterschriften
  • Der private Schlüssel darf aus dem öffentlichen nicht errechenbar sein
  • Einwegfunktion mit Falltür
  • Nur unter Kenntnis einer zusätzlichen Information effizient umkehrbar
  • z. B. x = loga y mod n (RSA-Verfahren) unter Kenntnis der Primfaktoren

Transposition vs. Substitution

Transposition

  • jeweils 2 aufeinander folgende Buchstaben vertauschen
  • wodurch sich neue Wörter ergeben
  • wir auch als Scambling (Verwürfelung) bezeichnet
  • Beispiel
  • Netz = Enzt
  • Einsatzgebiet
  • drahtlose Übertragungstechniken

Substitution

  • Bei der Substitution werden die Buchstaben des Klartextes im Geheimtext durch andere ersetzt
  • Dabei wird jeder Buchstabe durch den ersetzt, der im Alphabet 3 Stellen weiter hinten steht.
  • Cäsar-Addition
  • Beispiel
  • Netz = Qhzc

Symmetrische Substitution

Sender und Empfänger müssen den gleichen Schlüssel besitzen

  • um miteinander Kommunizieren zu können
  • Secret-Key-Verfahren
  • Eignet sich gut, um große Datenmengen zu verschlüsseln
  • Nachteil
  • Um die Nachricht verwerten zu können, muss der Schlüssel mit übertragen werden
  • was einen Schwachpunkt darstellt

Symmetrische Substitutionsverfahren

Klassifizierungen

  • Zeichenchiffren
  • Blockchiffren
  • Stromchiffren
  • Zeichenchiffrierung
  • Ermittelt jedes Zeichen des Geheimtextes aus dem entsprechenden Zeichen des Klartextes mit Hilfe des Schlüssels
  • Cäsar-Addition
  • Stromchiffrierung
  • Der Klartext wird Byte-weise über eine XOR-Operation verschlüsselt
  • Sie Erzeugt eine sich zyklisch verändernde Byte-Folge, die mit dem Klartext verknüpft wird
  • Blockchiffrierung
  • Klartext wird in Bitgruppen geteilt
  • über mehrstufige Verfahren mit dem Schlüssel über gleichbleibende Operationen in Geheimtext umgewandelt
  • DES

Asymmetrische Substitution

  • Es werden 2 komplementäre Schlüssel benötigt
  • 1 Key zum Chiffrieren der Nachricht
  • 2 Key zum Dechiffrieren der Nachricht
  • Einer der Schlüssel kann gefahrlos öffentlich bekannt gegeben werden (Public-Key)
  • Wird mit einem Schlüssel chiffriert
  • kann nur mit dem anderen Schlüssel dechiffriert werden

Vorteile von Public-Key-Verfahren

  • Jeder Kommunikationspartner benötigt einen Schlüssel
  • seinen Private Key
  • Der zweite Schlüssel wird veröffentlicht
  • Nachteil
  • Hohe Komplexität der durchzuführenden Operationen
  • Die Multiplikation 2 Zahlen stellt eine einfache Operation dar
  • während der umgekehrte Vorgang, also die Faktorzerlegung eines Produkts, einen enormen Rechenaufwand bedeuten kann

Absicherung der asymmetrischen Substitution

  • Schwäche
  • keine eindeutige Zuordnung des öffentlichen Schlüssels zu seinem Besitzer
  • Ein „Man-in-the-Middle“ könnte sich dazwischenschalten und die Nachrichten unbemerkt entschlüsseln
  • Informationen des öffentlichen Schlüssels und seines Besitzers sollten aus vertrauenswürdiger Quelle stammen
  • Möglichkeiten im Rahmen der Public Key Infrastructure (PKI)
  • Schlüssel kann über ein sicher betrachtetes Medium übertragen werden
  • Beispiel
  • Persönliche Übergabe, Telefon, Brief, Fax
  • Identität des Schlüsselinhabers zertifizieren lassen

Trust Center

Certification Authority [CA]

  • Zertifizierungsinstanz (Trust Center)
  • Zur Überprüfung der Schlüsselinhaber
  • Sender und Empfänger verwalten Listen von Zertifizierungsinstanzen
  • Überprüfung Zusammenhang öffentlicher Schlüssel und deren Absender
  • Zertifikat nach ITU-Standard X.509
  • ALTERNATIVE
  • Authentizität eines öffentlichen Schlüssels durch einen bekannten Kommunikationspartner bestätigen lassen
  • „Web of True“ von PGP

Kryptografie

Message Authentication Code

Einweg-Hash-Funktion

Message Authentication Code (MAC)

  • Dienen bei Datenbank-Anwendungen der einfachen Indizierung von Informationen.
  • Dabei werden beispielsweise Kundendaten durch Bildung einer Quersumme zu einem Wert zusammengefasst, denn man Hash-Wert nennt
  • Ebenfalls einsetzbar als Authentifizierung und Signatur
  • Es darf nicht möglich sein
  • die original Information zu rekonstruieren
  • durch eine ähnliche Information denselben Hash-Wert zu bekommen
  • Es werden keine Schlüssel benutzt, da sie für jeden berechenbar sein sollen

Hash-Funktion

Message Authentication Code (MAC)

  • Ableitung von „to hash up“
  • zerhacken, zerkleinern, durcheinander bringen
  • generiert aus einer beliebig langen Zeichenkette eine zweite Zeichenfolge fixer länge.
  • Anforderungen
  • muss eindeutig sein
  • muss einfach zu berechnen sein
  • inverse Funktion muss schwierig zu berechnen sein
  • muss kollisionsresistent sein
  • Hashes lassen sich nicht zur Kryptografie einsetzen
  • sie sind nicht reversibel

Hash-Algorithmus

  • Prüfsumme
  • Über einen Hash-Algorithmus lässt sich aus einem beliebig langen Datensatz eine Prüfsumme fester Länge berechnen
  • Kollisionsfreiheit
  • Dieser Hashwert soll möglichst einmalig sein
  • Damit ist sichergestellt, dass der Datensatz nicht so manipuliert werden kann, dass der Hashwert trotzdem noch derselbe ist
  • SHA-1 und MD5
  • Üblicherweise kommen SHA-1 (Secure Hash Algorithm) mit 160 Bit
  • MD5 (Message Digest Algorithm) mit 128 Bit zum Einsatz
  • ESP mit 96 Bit
  • Bei ESP wird der Hashwert von 128, respektive 160 Bit auf 96 Bit abgeschnitten
  • (Keyed-)Hash Message Authentication Codes
  • Zur Authentisierung von Daten
  • HMAC ist eine Sonderform des MAC, bei der zusammen mit einem geheimen Schlüssel ein Hash-Wert etwa über Datenpaket gebildet wird
  • Bei VPNs benutzt man in der Regel HMAC-MD5 oder HMAC-SHA-1

MD-5

Am weitesten verbreitete Message-Digest-Funktion

  • Mit MD-2 und MD-4 einer der Hash-Funktionen, die stetig verbessert werden
  • Nachrichten werden in 512 Bit Blöcken verarbeitet
  • indem es 16 x 32 Bit Blöcke zusammenfasst
  • Auch als MAC erhält man einen 128 Bit langen Block aus 32 Bit Blöcken
  • Die Verarbeitung findet in mehreren Stufen statt
  • Dabei dienen ein 512 langer Block und das MAC der vorangegangenen Stufe als Eingangsfolge

SHA-1

Schwäche von MD-5

  • relativ schnelle Kollisionen der Hash-Werte
  • SHA-1 generiert aus einer maximal 2^64 Bit langen Eingangsfolge eine 160 Bit lange Zeichenfolge
  • Dabei arbeite es mit 512 bit Blöcken
  • Der Algorithmus verwendet 5 Stufen mit jeweils 80 Schritten
  • Ergebnisfolge ist wesentlich länger als bei MD-5
  • wodurch Kollisionen unwahrscheinlicher sind
  • Durchschnittliche Kollisionen:
  • MD-5=2^60
  • SHA-1=2^80

Digital Signature Algorythm (DSA)

  • Chiffriert einen, durch eine Hash-Funktion generierten, MAC mittels eines privaten Schlüssels
  • Vorgehen eines mit SHA-1 generierten MAC
  • Auswahl einer Primzahl p zwischen 512 und 1024 Bit
  • Berechnung des Primfaktors q der Zahl (p-1). q ist 160 Bit lang
  • Berechnung einer Zahl g
  • mit g = h^(p-1/q) mod p, wobei h < p und g > 1
  • Auswahl einer weiteren Zahl x
  • als Privater Schlüssel des Senders Alice (x < q)
  • Zahl y = g^x mod p wird nun als öffentlicher Schlüssel verwendet

Substitution vs. Signatur

  • Algorithmen asymmetrischer Kryptografien unterscheiden sich
  • ob eine Nachricht verschlüsselt oder signiert werden soll

Substitution

  • Absender verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des Empfängers
  • so, dass er sie mit seinem privaten Schlüssel wieder im Klartext lesen kann

Signatur

  • Absender erzeugt mit seinem privaten Schlüssel eine Signatur
  • Empfänger kann durch Verwendung des öffentlichen Schlüssels des Absenders die Nachricht verifiziert

Kryptografie

Tunneling

Ende-zu-Ende vs. Abschnittsweise Sicherheit

Ende-zu-Ende

  • 2 Endgeräte handeln einen sicheren Kanal, bauen ihn auf und halten ihn aufrecht
  • Alternativ können nur kritische Übertragungen verschlüsselt werden
  • Beispiel
  • Kommunikation zwischen 2 Mailservern, wenn der Client eine Nachricht verschlüsselt überträgt

Vor- und Nachteile

  • Ende-zu-Ende hat eine geringe Angriffsfläche
  • benötigt jedoch viel Rechenleistung und eine gute Konfiguration
  • Abschnittssicherheit hat eine größere Angriffsfläche
  • beschränkt jedoch hohe Sicherheitsanforderungen auf die Gateways

Tunneling

Mehrfaches Einpacken eines Pakets auf einer Transportebene

  • Einsatzgebiet heute meist bei abschnittsweise Sicherheit
  • IP/IP-Tunneling
  • Für Transport über klassische IP-basierte Netze kann man IPv6 über IPv4 tunneln

Layer-2-Tunneling

  • Pakete der OSI-Schicht 2
  • meist PPP-frames
  • werden in IP-Pakete verpackt
  • So tunnelt man alle „Nicht-IP-Protokolle“

Tunneling

Layer-3-Tunnelung

  • Die Pakete der Vermittlungsschicht werden in IP-Frames verpackt
  • Bekanntes Verfahren dieser Art ist IPsec

Kryptografie

Wie baut man eine sicheren Block Cipher?

Probleme bei der Entwicklung von Kryptografieverfahren

Vertraulichkeit

  • Schutz der Daten vor unberechtigter Einsichtnahme

Authentisierung

  • Sicherstellung der Herkunft
  • Verbindlichkeit

Anonymität

  • Schutz vor Bekanntwerden des Absenders und Empfängers

Integrität

  • Unveränderlichkeit von Daten und Verlässlichkeit von Programmen

Wie baut man eine sicheren Block Cipher?

Mary Stuart 1516 - 1558Bekanntes Opfer der Kryptoanalyse

Shannon‘s Principle of ConfusionSubstitution Cipher

Shannon‘s Principle of DiffusionTransposition Cipher

Kryptografie

Angriffe auf Kryptografieen

Entschlüsselung

  • Die Entschlüsselung ist die Umkehrung der Kryptografie (symmetrische Verfahren)
  • Das heisst beim Beispiel-Caesar-Verfahren jetzt um 3 Buchstaben zurückverschieben:
  • ABCDEFGHIJKLMNOPQRSTUVWXYZ
  • xyzabcdefghijklmnopqrstuvw
  • So wird aus „KDOOR“ wieder ein „hallo“.

Moderne Verfahren

  • Das heute im kommerziellen Gebrauch am häufigsten eingesetzte Verfahren heisst DES
  • DES steht für „Data Encryption Standard“
  • Es funktioniert im Prinzip wie ein mehrfach hintereinander angewandtes Substitutionsverfahren

Angriffe auf Kryptografieen

Chifertext-Only Angriff

  • Versucht eine Kryptografie nur bei Kenntnis des chiffrierten Textes zu lösen
  • Gößte Herausforderung für jeden Kryptoanalytiker

Known-plaintext-Angriff

  • Der Angreifer besitzt neben dem Chiffretext auch den Klartext (oder einen Teil davon) und hat nun die Aufgabe den Schlüssel oder den Kryptografiealgorithmus zu finden.

Chosen-Plaintext Attack

  • Auch Teile des Klartextes können wertvolle Hilfe leisten
  • Attacker can choose the plaintext that gets encrypted thereby potentially getting more information about the key

Adaptive Chosen-Plaintext Attack

  • Attacker can choose a series of plaintexts, basing choice on the result of previous encryption
  • differential cryptanalysis!

Brute Force Angriff

  • Nacheinander werden alle möglichen Schlüssel durchprobiert
  • Kann bei jeder Kryptografiemethode eingesetzt werden
  • Der Angreifer muss jedoch erkennen, wann der richtige Schlüssel gefunden wurde, daher werden diese Angriffe oft als Known-plaintext-Angriff durchgeführt

Dechiffrierung verschlüsselter NachrichtenBrute Force Angriff

  • Die Brute-force Methode ist bei sehr großen Schlüsseln wirkungslos
  • Dann muss sich der Gegner auf die Analyse des Chiffrats verlassen
  • Dabei muss der Angreifer eine gewisse Vorstellung haben, um was für eine Art Ausgangstext es sich handelt
  • zum Beispiel eine .exe-Datei, Word-Datei oder einen Text mit deutschem Inhalt
  • Oder der Gegner spekuliert auf bestimmte Muster des Klartextes
  • Word-Dateien fangen zum Beispiel immer mit dem selben Muster an
  • Kryptoanalyse basiert auf der Ausnutzung
  • von Spuren der Struktur oder
  • des Musters des Klartextes
  • Diese bestehen auch nach Kryptografie und sind im Chiffretext zu erkennen

Exhaustive Testing

Monoalphabetischen Substitution (Cäsar)

  • jedem Buchstaben eines Alphabets mit 27 Buchstaben (26 + ein Satzzeichen) wird ein beliebig anderen zuordnet
  • 27 Möglichkeiten für den ersten Buchstaben
  • 26 Möglichkeiten für den zweiten Buchstaben
  • 25 Möglichkeiten für den dritten Buchstaben
  • etc.
  • Das enspricht 27 * 26 * .... * 2 * 1 = 27!
  • rund 1,09*10e28 Zuordnungsmöglichkeiten

Statische Analyse

  • Angreifer nutzen die Schwachstellen der Kryptverfahren
  • Dabei analysieren sie statisch den verschlüsselten Datenverkehr
  • Im Fall der monoalphabetischen bedeutet das
  • Die Häufigkeit der verschlüsselten Buchstaben bleibt gleich und kann durch einfache Häufigkeitsanalyse Rückschlüsse auf den Originaltext ziehen
  • Jedoch muss deren Sprache kennen bzw. erraten
  • Der Buchstabe „e“ tritt in der deutschen Sprache am häufigsten auf
  • Auch Buchstabenpaare (Biagramme) treten mit unterschiedlicher Häufigkeit auf
  • Durch diese Kenntnisse können monoalphabetische Codes schnell entschlüsselt werden

Known oder Chosen Plaintext

  • Teilweise vorhersehbar
  • Kryptografieen und Kryptografien zu knacken fällt einem Angreifer leichter, wenn er Teile des Klartextes bereits kennt.
  • Die Header-Daten von IP Paketen lassen sich unschwer erraten/ermitteln und ermöglichen so Know-Plaintext-Attacken
  • Diese Methode funktioniert auch bei Paketen, bei denen Teile der Informationen im Header vorhersagbar sind
  • Der Angreifer hat auch die Möglichkeit, eigenen Text zu verschlüsseln.
  • Ist dieser abhörbar, so können Rückschlüsse über den Verschlüssellungsalgorythmus gezogen werden

MustererkennungDie Methode des wahrscheinlichen Wortes

Bei der „Methode des wahrscheinlichen Wortes“ wählt man ein Wort aus, dass mit hoher Wahrscheinlichkeit im Klartext vorkommt, und sucht das Chiffrat ab, ob und wo das Muster dieses Wortes in ihm enthalten ist. Bsp.: „neun“ (Muster: ABCA)

Most Cryptoanalytic Attacks base on theRedundancy of Natural Language Texts

Angriffsarten

  • Angreifer hat mehrere Möglichkeiten
  • Informationen einer verschlüsselten Nachricht zu erhalten
  • die vom Sender A („Alice“) an Empfänger B („Bob“) geschickt wird
  • Am leichtesten können Nachrichten an
  • Hubs
  • Switches und
  • Router abgehört werden

Kryptografie

Kryptologische Verfahren

Der Schlüsselaustausch

  • Sicherheitsrelevant für alle bisher kennen gelernten Verfahren ist der Schlüsselaustausch
  • muss zuvor über einen geheimen Kanal stattfinden
  • Nicht immer hat man aber die Möglichkeit sich z. B. persönlich zu treffen
  • Public-Key
  • Es gibt jedoch ein Möglichkeiten, auch über einen unsicheren Kanal den Schlüsselaustausch durchzuführen
  • Diese Verfahren tragen den Namen „Public-Key“
  • Schlüsselaustausch ist ein Problem …
  • Verschiedene Schlüssel für verschiedene Kommunikationspartner notwendig
  • Diffie-Hellman Schlüsselaustausch-Verfahren
  • Basiert auf Schwierigkeit, den „diskreten Logarithmus“ zu berechnen
  • Gegeben sein ein Primzahl-Modulus p und eine Zahl x
  • 1) Alice wählt eine zufällige, geheime Zahl a und berechnet y1=x^a mod p
  • 2) Bob wählt eine zufällige, geheime Zahl b und berechnet y2=x^b mod p
  • Beide senden sich ihr y1 bzw. y2 zu
  • Alice berechnet s = y2^a = x^(ba) mod p
  • Bob berechnet s‘ = y1^b = x^(ab) mod p = s

Diffie-Hellman-Key-Exchange

  • Über das Diffie-Hellman-Key-Exchange-Verfahren (DH) lassen sich kryptographische Schlüssel sicher über unsichere Kanäle aushandeln
  • Es ist selbst kein Kryptografieverfahren und tauscht auch keine Schlüssel im eigentlichen Sinne aus
  • Das von Martin Hellman und Whitfield Diffie entwickelte Verfahren beruht auf den Eigenschaften diskreter Logarithmen:
  • zwar ist es einfach, eine Zahl zu potenzieren
  • Es ist aber nur mit sehr großem Aufwand möglich, den diskreten Logarithmus einer Zahl zu berechnen
  • Bei der Aushandlung einigen sich die VPN-Peers auf eine Primzahl p und eine Primitivwurzel g mod p
  • Beide Faktoren dürfen unverschlüsselt übertragen werden
  • Anschließend erzeugt jede Seite eine geheime Zufallszahl a/b und berechnet daraus den Wert Za= ga mod p beziehungsweise Zb = gb mod p
  • Za und Zb werden an den Partner übertragen
  • Daraus kann nun jede Seite den gemeinsamen symmetrischen Schlüssel K berechnen:
  • Zba mod p = Zab mod p = K

Diffie-Hellman-Key-Exchange

  • Sind die eingesetzten Zahlen hinreichend groß, ist es für einen Angreifer so gut wie unmöglich, den Key zu knacken
  • Große Zahlen erfordern allerdings mehr Rechenaufwand
  • Die Größe der Zahlen bestimmt die gewählte DH-Gruppe
  • Die kleinste DH Gruppe 1 hat 768 Bit und die größte definierte Gruppe 18 besitzt 8192 Bit
  • Empfohlen wird derzeit der Gebrauch der Gruppe 5 mit 1536 Bit

Diffie-Hellman

  • Vereinbarung eines gemeinsamen symmetrischen Schlüssels über einen unsicheren Kanal.
  • Basiert auf 2 Schlüsseln
  • Alice und Bob sind einer große Primzahl p und ein ganzahliger Wert g (Generator) frei zugänglich
  • Alice generiert eine große Zufallszahl a, berechnet eine Zahl A = g^a mod p
  • Bob generiert ebenfalls eine große Zufallszahl b, berechnet eine Zahl B = g^b mod p
  • und sendet B an Alice
  • Alice berechnet eine Zahl K[1] = B^a mod p.
  • Bob berechnet eine Zahl K[2] = A^b mod p.
  • K[1] und K[2] sidn gleich.
  • Es gilt K = K[2] = K[2] = g^a*b mod p
  • K wird als geheimer symmetrischer Schlüssel verwendet

Symmetrische Kryptografieverfahren

Einfachster Einsatz

  • basiert auf der logischen Exklusiv-Oder-Funktion
  • 2 XOR Verknüpfung eines A Zeichens mit einem B hat wieder das ursprüngliche Zeichen A zum Ergebnis
  • Es entspricht also der Inversen Verknüpfung:
  • (A+B)+B=A+(B+B)Assoziativgesetz=A+0Eigenschaft von XOR=AEigenschaft von XOR
  • Der Sender verschlüsselt ein Zeichen A mit einem Schlüssel B per XOR und versendet das Ergebnis
  • Der Empfänger verknüpft das Ergebnis erneut mit Schlüssel B und erhält dann wieder das Zeichen A

Symmetric Algorithms: Block Ciphers

Some Popular Block Ciphers

Symmetric Algorithms: Stream Ciphers

RC4

RC = Rivest Cipher

  • Stromverschlüsselungsverfahren
  • Basiert auf XOR-Verknüpfung
  • Sehr schnell und einfach
  • Eignet sich gut in Software
  • Der Algorythmus macht aus dem eingegebenen Schlüssel S einen langen, pseudo-zufälligen internen Schlüssel P
  • Dieser wird zur Chiffrierung des Klartextes verwendet
  • RC4 Speichert 258 verschiedene Zusatzinformationen
  • 256 sind Permutationen von 0-255 und somit gleich verteilt

DES

Familie der Blockchiffren

  • Teilt eine Nachricht in 64 Bit große Datenblöcke
  • 3 bearbeitungsschritte werden benötigt, um den Klartext wieder herzustellen.
  • Am weitesten verbreiteter Algorythmus, auch wenn nicht mehr ganz Zeitgemäß
  • Nachfolger: 3DES
  • Wird in Finanzdienstleistungen eingesetzt und führt die Kryptografie 3 mal hintereinander aus

Data Encryption Standard (DES)Sicherheit von DES

  • DES
  • erlaubt mit 56 Bit Schlüssellänge
  • 72 Billiarden mögliche Schlüssel
  • ist heute nicht mehr ausreichend
  • per Brute-Force in 5 Tagen (?) geknackt

Permutation

  • DES besteht aus 3 Bearbeitungsschritten
  • Initiale Permutation
  • Ver-/Entschlüsselung in mehreren Runden
  • finale Permutation
  • DES wurde in den 70er Jahren zur Implementation in Hardware entwickelt
  • durch die damals noch kleinen CPU Register
  • Finale Permutation = Inverse der initialen Permutation
  • Nach der Durchführung der initialen und finalen Permutation, steht ein Bit wieder an ursprünglicher Stelle

Kryptografie

  • DES basiert auf einer 64 Bit Kryptografie
  • wovon jedoch nur 56 Bit kryptographisch relevant sind
  • Jedes 8 Bit = Parity-Bit
  • DES erzeugt 16 verschiedene 48 Bit lange Schlüssel
  • Es werden aus 56 relevanten Bit mit einer Permutation 2 28 Bit Muster generiert (C[i-1] und D[i-1]).
  • Die Teilschlüssel werden nun um 1 oder 2 Bit nach links rotiert.
  • Die erzeugten Schlüssel C[i] und D[i] werden zu C[i-1] und D[i-1].
  • 2 24Bit Folgen aus C[i] und D[i] werden zum Schlüssel K[n]

Kryptografie

  • DES teilt den Klartext in 64 Bit Blöcke und
  • splittet sie nochmal in 2 32 Bit lange Bestandteile (L[n] und R[n]).
  • R[n] wird über eine Mangler-Funktion ,mittels tabellenbasierter Umrechnung auf Grundlage der Eingangsvariable R[n] und des Schlüssels K[n], vermischt.

Genügen 128 Bit?

  • IDEA
  • International Data Encryption Algorithm
  • arbeitet mit 128 Bit Schlüssellänge, sonst ähnlich wie der DES
  • 3.43669 * 1038
  • knacken benötigt etwa 1012 Jahre
  • Daher gilt der IDEA heute als sicher

Asymmetrische Kryptografieverfahren

Setzen auf 2 unterschiedliche Schlüssel

  • Privater Schlüssel (privat key) [Dechiffriert-Algorythmisch]
  • Öffentlicher Schlüssel (public key) [Chiffriert-Algorythmisch]
  • Es lässt sich nicht vom public key auf den private key schließen
  • Der public key kann von Dritten zur Kryptografie von Informationen genutzt werden
  • die der Besitzer des private keys nur entschlüsseln kann

Bekanntester Vertreter

  • RSA-Algorythmus
  • Die Multiplikation 2er Zahlen stellt eine einfache Operation dar
  • während der umgekehrt Vorgang eine enorme Rechenleistung bedeutet

RSA

Basiert auf folgenden 4 Schritten

  • Wähle 2 große Primzahlen p und q, die geheim bleiben
  • Berechne das Produkt n = p*q
  • Für öffentlichen Schlüssel wähle e < n
  • die teilerfremd zur Eulerschen Funktion E(n) = (p-1)*(q-1) ist
  • Für privaten Schlüssel bestimme eine Zahl
  • d = e^-1 mod E(n)
  • Dann gilt
  • e*d = 1 mod E(n)
  • [d,n] ist der private Schlüssel

RSA

Algorithmus bei der Kryptografie

  • Alice verschlüsselt
  • ihren Klartext m gemäß c = m^e mod n und
  • sendet ihn an Bob.
  • In diesem Fall ist [e,n] der öffentliche Schlüssel von Bob
  • Bob entschlüsselt
  • den Geheimtext c mit seinem privaten Schlüssel [d,n] gemäß m = c^d mod n
  • und erhält auf Grund des Zusammenhangs von d und e den Klartext m

RSA

  • Der Empfänger führt bei der Entschlüsselung die gleiche Operation wie der Sender bei der Kryptografie durch
  • Algorythmus zur Erzeugung und Überprüfung von Signaturen
  • Alice sendet eine signierte Nachricht, indem sie s = m^d mod n erzeugt und überträgt
  • [d,n] = Privater Schlüssen von Alice
  • Bob entschlüsselt die Signatur gemäß m = s^e mod n und erhält auf Grund des Zusammenhangs von d und e den Klartext m
  • [e,n] = öffentlicher Schlüssel von Alice

Advanced Encryption Standard

  • Nachfolgestandard für DES
  • 3DES mit 128 Bit gilt noch als sicher
  • wegen der Dreifachverschlüsselung deutlich langsamer als AES
  • AES unterstützt 128, 192 und 256 Bit lange Schlüssel
  • Beispiel Hamachi
  • AES mit 256 Bit Schlüssellänge
  • im Modus Cipher-Block-Chaining

Advanced Encryption Standard (AES)http://www.nist.gov/aes

  • DES is nearly 25 years old!
  • Triple DES with a 168 bit key is the current Federal Information Processing Standard FIPS 46-3 (renewed in October 1999).
  • Single DES with 56 bit key is permitted for legacy systems only.
  • Evaluation of an Advanced Encryption Standard
  • The National Institute of Standards and Technology (NIST,U.S. Department of Commerce) started a public contest in 1997.
  • 5 final candidate algorithms. Decision by NIST in Spring 2001
  • Requirements for AES
  • AES shall be publicly defined.
  • AES shall be a symmetric block cipher.
  • AES shall be implementable in both hardware and software.
  • AES shall be designed so that the key length may be increased as needed.
  • AES block size n = 128 bits, key size k = 128, 192, 256 bits

AES Round 2 Finalists

  • MARS(IBM)
  • Modified Feistel Network - 32 Rounds
  • Based on Mixed Structure DES
  • RC6 (RSA)
  • Feistel Network - 20 Rounds
  • Based on Modified RC5
  • Rijndal(Joan Daemen / Vincent Rijmen)
  • Modified Substitution Permutation Network - 10 Rounds
  • Based on Square
  • Serpent (Ross Anderson / Eli Biham / Lars Knudsen)
  • Substitution Permutation Network - 32 Rounds
  • Based on Bitlice Operations
  • Twofish(Bruce Schneier)
  • Feistel Network - 16 Rounds
  • Based on Modified Blowfish

Cipher Block Chaining (CBC)

  • Um eine Frquenzanalyse zu verhindern wird eine Verkettung von Datenblöcken durchgeführt
  • Dabei wird der zu verschlüsselnde Datenblock exklusiv mit dem letzten verschlüsselten Datenblock verknüpft
  • Gleiche Datenblöcke werden so unterschiedlich modifiziert und unterschiedlich verschlüsselt
  • Problem: Erste Datenblock
  • Erzeugung eines Initialisierungs-Vekros (IV)
  • Der IV wird zur Entschlüsselung benötigt
  • daher wird er dem Empfänger übermittelt
  • Vertraulichkeit ist nicht erforderlich
  • IPsec – Protokolle übertragen den IV in jedem Datenpaket

Advanced Encryption Standard

CBC-Mode Entstehung von Mustern

  • Rückschlüsse auf den Klartext
  • Anders als der ECB-Mode (Electronic Code Book) verhindert der CBC-Mode (Cipher Block Chaining) bei Kryptografiealgorithmen die Entstehung von Mustern im Chiffrat,
  • Dazu lässt CBC das Ergebnis der vorherigen Blockoperation in die aktuelle einfließen (Chaining)
  • Sowohl ECB als auch CBC sind für so genannte Bit-Flipping-Attacken anfällig
  • Angreifer versucht im Chiffrat einzelne Bit manipulieren
  • ohne Kenntnis des Schlüssels
  • ohne später beim Entschlüsseln durch den Empfänger einen Fehler zu provozieren
  • auch für verschlüsselte Pakete die Integrität gesichert werden, etwa mit HMAC
  • Da sich so der Inhalt manipulieren lässt
  • In CBC werden jeweils Blöcke von jeweils 16 Datenbytes verschlüsselt
  • Das CBC-Verfahren initialisiert mit einem zufällig gewählten 128 Bit langen Initialisierungsvektor
  • wird bei ESP-Paket den chiffrierten Nutzdaten vorangestellt
  • Da Daten blockweise verschlüsselt werden
  • muss der letzte Datenblock mit Füll-Bytes zur vollen Blocklänge aufgefüllt
  • die Anzahl dieser Stopf-Bytes wird im Längen-Byte festgehalten

Vergleich: AES und 3DES

IDEA

Familie der Blockchiffrierung

  • jedoch wendet er 128 Bit Schlüssel auf 64 Bit Datenpakete des Klartextes an
  • Basiert auf einer Mischung 3 mathematischen Funktionen
  • die jeweils auf 16 Bit Blöcke des Testes angewandt werden.
  • Neben XOR kommt die Addition modulo 2^16 und die Multiplikation modulo 2^16+1 zum Einsatz
  • Alle 3 Operationen werden zu einem recht komplizierten Netzwerk verknüpft, das 8 Runden durchlaufen wird
  • Trotz komplizierter Verfahren, schneller und sicherer als DES

Hybride Kryptografieverfahren

Vorteile aus asymmetrischen und symmetrischen Kryptografie

  • Hohe Effizienz
  • gesteigerte Sicherheit
  • Flexibilität
  • Austausch der erforderlichen Schlüssel
  • erfolgt über ein asymmetrisches Verfahren
  • Kryptografie größerer Datenmengen
  • kommen symetrische Algorythmen zum Einsatz

Vergleich Klassisch - Modern

Sowohl die klassischen Verfahren wie Vigenère als auch die modernen Verfahren wie IDEA…

  • …benötigen einen Schlüssel der beiden Parteien im Vornherein bekannt ist
  • …sind symmetrisch (Entschlüsselung ist Umkehrung der Kryptografie)
  • …sind in gewissen Masse anfällig auf Kryptoanalyse (z. B. Brute-Force)

Fazit

Die Geschichte der Kryptografie ist ein Wettbewerb

  • zwischen Kryptografiespezialisten und Kryptoanalysten
  • Momentan liegen die Verschlüssler mit dem IDEA vorne
  • da dieses Verfahren nur mit Brute-Force geknackt werden kann
  • dies wegen der großen Schlüssellänge auch auf modernsten Computern noch zu lange dauert

Kryptografie

Geschwindigkeit

Geschwindigkeit

Geschwindigkeit

Geschwindigkeit

Geschwindigkeit

Abgerufen von „https://wiki.foxtom.de/index.php?title=Kryptografie/tmp&oldid=103986“