Zertifikate, Signaturen & Co. // deutsch
the native web GmbH
https://www.youtube.com/watch?v=NL7ySTGXt9w

Transkript (automatisch erstellt)

0:00 hi gestern haben wir uns mit hev funktionen und message of education codes beschäftigt heute gucken wir uns mal zertifikate und digitale signaturen
0:08 an wenn alles und bob kommunizieren dann machen sie das heutzutage natürlich über das internet wenn man noch ein bisschen verallgemeinert kann man sagen man ist
0:16 häufig mit einem client unterwegs der mit einem server kommunizieren soll und diese kommunikation soll zwei anforderungen erfüllen zum einen soll
0:23 sich verschlüsselt ablaufen zum anderen soll sie auch authentifiziert ablaufen im falle des kleinen ist das in der regel über den benutzernamen und
0:31 kennwort gelöst auf der serverseite auch der server soll sich natürlich authentifizieren damit ich sicher sein kann dass ich mit dem richtigen server
0:38 kommunizieren dieser erste aspekt nämlich die verschlüsselung der verbindung ist relativ einfach zu bewerkstelligen man
0:45 nimmt das http protokoll und tunnelt das einfach über ein anderes verschlüsseln das protokoll und das ist in der regel das tls
0:53 beziehungsweise das ssl protokoll und man erhält auf diesem wege https oder tls schrägstrich ssl und das nennt man dann eben https die verschlüsselung die
1:03 dort stattfindet findet aus performance gründen symmetrisch statt jetzt ist das problem dass damit die symmetrische verschlüsselung
1:09 funktionieren kann man zunächst einen schlüssel austauschen muss dieser schlüssel der wird natürlich nicht für jede anwenderinnen und für jeden
1:17 anwender im vorfeld generiert und dann einmal festgelegt sondern der wird ad hoc ausgehandelt dafür gibt es verschiedene verfahren beispielsweise
1:24 das diffie hellman key exchange verfahren das auf ähnlichen ansätzen basiert wie die asymmetrische verschlüsselung die viel spannendere
1:32 frage ist aber wieder zweiter aspekt umgesetzt werden kann also wie die authentifizierung des servers funktioniert woher weiß der client dass
1:40 er mit dem richtigen server kommuniziert und das ist zunächst mal eine berechtigte frage denn eine angreiferin oder ein angreifer könnte beispielsweise
1:47 die dns einträge manipulieren und den kleinen so auf einem eigenen server umleiten und dieser server könnte im schlimmsten fall die anfragen mit lesen
1:56 verändern und dann aber transparenz sozusagen den eigentlichen ziel zu aber weiter leiten in diesem fall spricht man von einer man
2:03 in the middle attacke und das ist natürlich für die anwenderin oder den anwender im schlimmsten fall wie gesagt auch noch völlig trans
2:10 rennt das heißt ich möchte sicherstellen dass sich als client mit dem richtigen server kommunizieren und genau dafür komponiert zertifikate
2:18 ins spiel die grundlage für zertifikate ist public key kryptographie das heißt man braucht auf einem server zunächst mal einen
2:25 privaten schlüssel und einen öffentlichen schlüssel dann ist nämlich klar dass wenn ich den öffentlichen schlüssel abfrage und diesen
2:32 öffentlichen schlüssel verwenden daten zu verschlüsseln das ist nur der entsprechende server wieder entschlüsseln können denn nur er
2:37 kennt ja den zugehörigen privaten schlüssel jetzt ist nur die frage woher weiß ich dass der öffentliche schlüssel eben auch
2:44 zu einer bestimmten domain gehört und genau dafür fügt man an diesen öffentlichen schlüssel sozusagen metadaten an wo
2:50 drinsteht zu welcher domain dieser öffentliche schlüssel gehört allerdings wirft das die frage auf wer verhindert dass eine angreiferin oder ein angreifer
2:59 einfach beliebige meta daten an einen beliebigen öffentlichen schlüssel hängen kann und dass das ganz einfach man braucht einen vertrauenswürdigen dritten
3:07 der diesen zusammenhang zwischen öffentlichen schlüssel und metadaten sozusagen überprüft und dann auch bestätigt und dafür gibt es digitale
3:15 signaturen also wenn man so will das wird beglaubigt und mit einer unterschrift bestätigt eine digitale signatur ist tatsächlich sehr sehr
3:23 einfach zu erstellen das ist nämlich nichts anderes als ein asymmetrisches verschlüsselungsverfahren rückwärts angewendet wir haben uns bisher immer so
3:31 gehabt dass wenn es eine nachricht verschlüsselt an bob schicken wollte das alles die nachricht mit dem öffentlichen schlüssel von bob verschlüsselt hat in
3:40 dem wissen dass dann ausschließlich bob diese nachricht wieder entschlüsseln kann da nur er über den privaten zugehörigen schlüssel verfügt nun kann
3:47 alles das ganze aber auch umkehren wenn alles nämlich eine nachricht mit ihrem eigenen privaten schlüssel verschlüsselt dann ist diese nachricht nur noch mit
3:56 ihrem öffentlichen schlüssel entschlüsseln war das wirkt auf den ersten blick relativ sinnfrei weil diese entschlüsselung ja jeder vornehmen kann
4:04 der punkt ist aber die tatsache dass sich die nachricht mit dem öffentlichen schlüssel von ellis entschlüsseln lässt bedeutet oder dies beweist dass die
4:12 nachricht ursprünglich mit dem privaten schlüssel von alles verschlüsselt wurde und das kann natürlich nur alles gemacht
4:18 haben und damit ist die urheberschaft sozusagen bestätigt das heißt eine digitale signatur ist nichts anderes als eine verschlüsselung bei der die rolle
4:26 von öffentlichen und privaten schlüssel sozusagen vertauscht werden und einen solchen öffentlichen schlüssel plus die zugehörigen metadaten was einen server
4:35 sozusagen beschreibt plus die digitale signatur einer vertrauenswürdigen dritte instanz das ist ein so genanntes zertifikat und diese vertrauenswürdige
4:44 dritte instanz oder vertrauenswürdige dritte der in diesem fall diese zuordnung von öffentlichen schlüssel zum metadaten überprüft und das mit seiner
4:52 digitalen signatur bestätigt das ist dann eine sogenannte certificate of thirty und von dass ein unternehmen von denen kann nicht mehr entsprechend
5:01 zertifikate gegen geld ausstellen lassen jetzt ist die frage das ist eigentlich ein sehr gutes vorgehen aber die frage ist natürlich wer garantiert werden dass
5:11 die digitale signatur wirklich von dieser certificate of haiti stammt und da ist es relativ einfach weil die digitale signatur ja wiederum auf public
5:20 key kryptographie basiert auch die kann man ja mit einem zertifikat ausstatten das heißt man da die digitale signatur mit dem privaten schlüssel der ca
5:28 erzeugt wird könnte ich die digitale signatur mit dem öffentlichen schlüssel des pazifiks of thirty überprüfen wenn an diesem öffentlichen schlüssel
5:38 wiederum metadaten hängender die certificate of turkey beschreibt und das von einem vertrauenswürdigen vierten in dem fall bestätigt worden ist dann kann
5:45 ich mir sicher sein dass die ca wirklich die ca ist also die zertifikat auf haiti von der ich ausgehen der vertrauenswürdige vierte in diesem fall
5:54 braucht lediglich eine möglichkeit digitale signaturen zu erstellen um das wirklich bestätigen zu können was die frage aufwirft wer das in identität
6:02 wiederum sicherstellt und so hangelt man sich dann von certificate of war ii tc certificate of amity von ca zu ca zu zehnt und immer so weiter
6:11 und das ist theoretisch eine endlos lange kette irgendwann muss man aber natürlich mal an ein ende gekommen und das sind dann die sogenannten root
6:18 zertifikat of peace und das vertrauen wiederum in diese zertifikate wird einfach dadurch begründet dass die entsprechenden zertifikat
6:27 bereits im betriebssystem oder im browser enthalten sind das heißt man vertraut letzten endes auf den hersteller des betriebssystems oder auf
6:35 den hersteller des browsers den man verwendet dass dieser hersteller eben hingehen wird und die zertifikate der lukas entsprechend überprüft und
6:43 sicherstellt dass eben keine ungültigen blut cas hineinreichen das ganze ist vom sicherheitsempfinden wenn man sich das im hinterkopf behält
6:52 dass das im grunde genommen nur letzten endes eine frage des vertrauens ist auf seiten des betriebssystem herstellers beziehungsweise des brauseherstellers
6:59 ist das von der sicherheit eher ein bisschen fragwürdig aber es ist das beste was wir derzeit im internet zu bieten haben
7:06 dann war es eben auch diese freiheit ermöglicht dass man eben nicht über im vorhinein ausgehandelte schlüssel gehen muss sondern das ganze eben adhoc laufen
7:15 kann insofern es ist ok aber das ist eben das beste was wir bislang haben das ist übrigens auch der ganz wichtige grund weil diese root ca ist theoretisch
7:24 zertifikate für jeden und alles ausstellen können also das den obliegt sozusagen sehr sehr viel verantwortung deshalb man als entwicklerin oder als
7:31 entwickler niemals ruht c a zertifikat oder generell zertifikate von dritten auf seinem rechner installieren sollte sein es sei es der arbeitgeber seines
7:42 kunden weil man damit theoretisch das eigene system kompromittiert weil eben derjenige der dieses zertifikat kontrolliert dann in der lage ist
7:51 beliebige zertifikate auszustellen auch für beliebige offizielle internetseiten von denen man eigentlich davon ausgeht dass sie wirklich überprüft worden sind
7:59 und damit ist die ganze sicherheit unterlaufen bzw die ganze sicherheit ist eben nur noch so sicher wie dieses eine ca zertifikat
8:06 was man sozusagen nach installiert hat weswegen ich stark dazu raten würde so etwas nicht zu machen oder wenn dann nur innerhalb einer virtuellen maschine aber
8:14 niemals auf dem eigenen host systemen so und damit kommen wir mit der heutigen folge zum ende dieser woche zum thema verschlüsselung und kryptographie
8:23 ich hoffe dass euch die folge heute gefallen hat wenn ja dann würde ich mich freuen wenn ihr einen daumen nach oben da last und wenn ihr den kanal noch
8:30 nicht abonniert habt dann macht das doch vielleicht bei der gelegenheit und aktiviert die glocke damit ihr von youtube auch über neue videos regelmäßig
8:37 benachrichtigt werden und in dem sinne wünsche ich euch dann ein schönes baldiges wochenende der freitag liegt ja noch vor uns aber dann
8:44 ein schönes wochenende passt auf euch auf bleibt gesund und dann sehen wir uns am montag wieder macht's gut