Home » Wissens­wertes » Sicher­heit

Sicher­heit

Einlei­tung

In diesem Artikel geht es nicht speziell um die Sicher­heit in NeuroomNet, sondern, da NeuroomNet ja ein Web basiertes Tool ist, um die Sicher­heit von Web basierten Tools im Allge­meinen. Also darum, was man bedenken sollte, um ein System wie NeuroomNet sicher zu betreiben. Wir stehen Ihnen dabei in allen Fragen gerne mit Rat und Tat zur Seite, aber unten können sie sich schon einmal Anregungen einholen, was zu bedenken ist.

Sicher­heit ist ein zwei­schnei­diges Schwert: Ist die Sicher­heit zu hoch, wird der*die befugte Benutzer*in bei den Aufgaben so massiv behin­dert, dass die Akzep­tanz deut­lich leidet. Ist sie aber zu niedrig, kann das zu sehr ernsten Konse­quenzen führen.
Das Internet ist in diesem Punkt auch wieder Fluch und Segen zugleich.
Die Verbrei­tung von Wissen ist eine große Stärke, damit wird aber auch die Kenntnis, wie man eine Siche­rung eines Systems aushe­beln kann, schnell verbreitet. Ebenso wie der Anschluss ans Internet selbst schon die Möglich­keit schafft, ein System bequem angreifen zu können. So können auf der anderen Seite bestimmte Teil­sys­teme auto­ma­ti­siert über das Internet aktuell gehalten und vor schäd­li­chen Einflüssen bewahrt werden.
Wenn man also auf der sicheren Seite sein will, muss man mit der Zeit gehen und sein System den stetig stei­genden Anfor­de­rungen entsprechend anpassen. Dabei gibt es Bereiche mit etwas Verschnauf­pause, weil das Konzept schon sehr viel Sicher­heit mitbringt. Andere Bereiche, passen sich auto­ma­ti­siert an (wenn es denn einen Zugang zum Internet gibt) und schließ­lich gibt es Bereiche, da muss man regel­mäßig schauen, ob alles wie vorge­sehen funk­tio­niert oder passend reagieren.

Verschlüs­seln

Ein sehr erfolg­rei­ches und lang­le­biges Verfahren ist es, die Kommu­ni­ka­tion zweier Parteien zu verschlüs­seln. Damit kann ein*e Angreifer*in weder Rück­schlüsse ziehen, noch die eigent­li­chen Daten ergat­tern. Wer hier mitlesen will, muss schon enormen Aufwand betreiben und hat es viel leichter z.B. an den Endpunkten der Kommu­ni­ka­tion anzu­setzen, also bevor es ver-/ent­schlüs­selt wird. Denn moderne Verschlüsselung lässt sich immer noch nicht in kurzen Zeit­räumen knacken. So können dann auch Daten über Verbin­dungen, die über das Internet, WLAN, Mobil­funk oder andere öffent­lich einseh­bare Netz­werke laufen ohne schlechtes Gewissen über­tragen werden. Und dank ausge­feilter Mecha­nismen zur Etablie­rung der Verschlüsselung bekommt der*die Anwender*in das im besten Fall nicht einmal mit und stört sich auch nicht am tägli­chen Ablauf. Mit Ausnahme, wenn ein zeit­li­ches Limit zur Erneue­rung einer gesi­cherten Verbin­dung abge­laufen ist. Denn ein Teil­aspekt der gesi­cherten Kommu­ni­ka­tion ist es, die zugrunde liegenden Schlüssel zu erneuern, damit die lang­atmigen Angriffe erfolglos bleiben.

Fire­wall

Ein weiterer Teil­aspekt eines lang­le­bigen Sicher­heits­kon­zeptes ist der Schutz der Endpunkte durch Fire­walls. Eine Fire­wall ist ein Sicherungs­system, das ein Rech­ner­netz und einzelne Computer vor uner­wünschten Netz­werk­zu­griffen schützt. Kurzum, ein modernes System muss mit verschlüs­selter Kommu­ni­ka­tion und geschützten Netz­werken umgehen können. Wenn die Haustür und die Fenster in Ihrem Haus die Fire­wall wären, dann wäre der Tresor, in dem Sie Ihre wert­vollsten Dinge ablegen, die Verschlüsselung.

Infra­struktur

Voraus­set­zung für das Verschlüs­seln ist die Möglich­keit, den legitimen Teilnehmer*innen die Schlüssel sicher zukommen zu lassen und regel­mäßig zu aktua­li­sieren. Das wird mit Zuhil­fe­nahme von soge­nannten Zerti­fi­katen erle­digt. Ein Zertifikat kann mit einer Unter­schrift (Signatur) glaub­haft machen, von wem, für wen und bis wann es ausge­stellt wurde. Dabei unter­scheidet man, ob ein Zertifikat öffent­lich zugäng­lich sein muss oder ob es inner­halb eines abge­schlos­senen Systems zum Einsatz kommt. Die zugrunde liegende Technik, und damit die Sicher­heit, ist aber bei beiden Varianten identisch. 

Öffent­liche Anwendung (CA-signed certificates)

Bei öffentlichen Anwen­dungen mit öffent­lich zugänglichem Zertifikat, kommen spezia­li­sierte Unter­nehmen zum Einsatz. Diese erteilen Zerti­fi­kate nur durch geprüfte und kosten­pflich­tige Anträge. So ein Zertifikat kann dann für einen bestimmten Zeit­raum weiter verwendet werden, um eigene Systeme abzu­si­chern und bedarf keiner beson­deren Vorbe­rei­tung auf den Computern, die den*die Aussteller*in bereits kennen.
Die Lauf­zeit eines solchen Zerti­fi­kats ist derzeit auf 2 Jahre begrenzt und soll sogar auf 13 Monate verkürzt werden. 

Interne Anwendung (Self-signed certificates)

Bei internen Anwen­dungen kann ein selbst ausge­stelltes Zertifikat genommen werden. Beim Ausstellen dieser Zerti­fi­kate kann man dann gewisse Grenzen über­schreiten, um den admi­nis­tra­tiven Aufwand in seiner Häufig­keit zu verringern. Bei solchen internen Anwen­dungen muss aber zunächst eine Verwal­tung dieser Zerti­fi­kate etabliert werden, sowie der*die Aussteller*in den Teilnehmer*innen bekannt gemacht werden. Dies ermög­licht den Anwender*innen (bzw. Computern) zu über­prüfen, ob ein Zertifikat (noch) gültig ist oder mit einem neuen Zertifikat versorgt zu werden. Oft kommen sogar beide Zerti­fi­zie­rungs­sys­teme (intern und extern) zum Einsatz, damit der Aufwand für die Anwender*innen möglichst gering bleibt oder weil es tech­nisch sogar notwendig ist. 

Kosten und Nutzen

Grund­sätz­lich könnte alles über öffent­liche Zertifizierungs­stellen laufen, würde aber mehr Kosten verursachen. Auch könnte man alles mit internen Zertifizierungs­stellen abwickeln, würde aber dann höhere Aufwände bei der Vertei­lung der Zerti­fi­kate im öffentlichen Raum verursachen. Davon abge­sehen wäre das Instal­lieren der internen Zerti­fi­kate ein zusätz­li­cher Aufwand für die Anwender*innen. Die Akzep­tanz würde sehr schnell auf Null zurück gehen. 
Fazit

Damit alles möglichst reibungslos funk­tio­niert, muss eine soge­nannte PKI (Private-Key-Infra­struc­ture) etabliert werden. Diese hilft bei der Verwal­tung, Kontrolle und kann einzelne Aspekte auto­ma­ti­sieren. Unter­schiede gibt es durch die jeweils verwen­deten Hersteller*innen. Ebenso bedarf es entsprechend geschultem Personal, das alles einzu­richten und wie oben beschrieben, alle paar Jahre oder Monate zu erneuern. Die regel­mä­ßige Instal­la­tion erneu­erter Zerti­fi­kate muss sicher­ge­stellt sein, da diese sich nicht selbst ersetzen können.
Je komplexer ein System wird, umso eher steigt die Notwen­dig­keit eine eigene Zerti­fi­zie­rungs­stelle nebst PKI einzu­richten. Die Zeiten von „Wir stecken mal eben alles in den Netz­werk-Switch“ sind vorbei, denn sonst kann jeder sich in die Verbin­dung schalten, alles nebst Anmel­de­daten mitlesen und diese sogar während der Benut­zung mani­pu­lieren (s. a. Man-in-the-Middle Attacke).

Die Absicherung von Daten­ver­bin­dungen ist heute aus den Netz­werken wie, Internet (World Wide Web) als auch im Intranet (lokales Netzwerk/WLAN) nicht mehr wegzu­denken. Die Namen der für die Absicherung verwen­deten Proto­kolle hat fast jeder schon einmal gehört. Dennoch ist wahr­schein­lich nicht jedem klar, was nun der Unter­schied zwischen SSL, TLS und HTTPS ist und welche Sicherheits­eigenschaften diese Proto­kolle haben.
Warum ist eine abge­si­cherte Daten­verbindung sinn­voll?
Nehmen wir einmal an, ein Benutzer möchte in NeuroomNet ein Exponat ansteuern. Bei der Verwendung einer abge­si­cherten Verbin­dung profi­tiert dieser Benutzer von den Sicherheits­eigenschaften von verschlüs­selter und abge­si­cherter Kommu­ni­ka­tion. Ohne Verschlüsselung sind Daten, die über­tragen werden, für jeden, der Zugang zum entspre­chenden Netz hat, als Klar­text lesbar. Mit der zuneh­menden Verbrei­tung von offenen (d. h. unver­schlüs­selten) WLANs nimmt die Bedeu­tung von HTTPS zu, weil damit die Inhalte unab­hängig vom verwen­deten Netz verschlüs­selt werden können. Durch die Verschlüsselung ist es für Dritte unter anderem nicht möglich zu sehen, welche Seiten einer Website genau besucht wurden.
Durch die Verwendung von Zerti­fi­katen kann sicher­ge­stellt werden, dass während der Über­tra­gung keine Mani­pu­la­tion der Inhalte durch Dritte möglich ist und beispiels­weise keine Falsch­in­for­ma­tionen über Ihr Unter­nehmen in Ihre Firmen­web­site inji­ziert werden. 

Die wich­tigsten Proto­kolle zur Absicherung von Daten­ver­bin­dungen für Betreiber von Websites und Weban­wen­dungen

SSL steht für Secure Sockets Layer, wurde von Netscape entworfen und zusammen mit HTTPS erst­mals 1994 mit deren Browser veröf­fent­licht. Die Entwicklung wurde bis Version 3.0 fort­ge­setzt. Heute sind Schwach­stellen in SSL bekannt und das Protokoll sollte daher nicht mehr einge­setzt werden.

TLS steht für Trans­port Layer Secu­rity und ist das Nach­fol­ge­pro­to­koll von SSL 3.0. Die erste Version 1.0 von TLS ist eine leicht modi­fi­zierte Vari­ante der dritten Version von SSL und wurde von der IETF stan­dar­di­siert.

Die Internet Engi­nee­ring Task Force (IETF, englisch für „Inter­net­technik-Arbeits­gruppe“) ist eine Orga­ni­sa­tion, die sich mit der tech­ni­schen Weiter­ent­wick­lung des Inter­nets befasst, um dessen Funk­ti­ons­weise zu verbes­sern. Aktuell ist TLS in der Version 1.3 und mitt­ler­weile auch gut verbreitet.
TLS besteht aus zwei Haupt­kom­po­nenten: TLS Hand­shake und TLS Record. Im TLS Hand­shake findet ein sicherer Schlüssel­austausch und eine Authen­ti­sie­rung statt. TLS Record verwendet dann den im TLS Hand­shake ausgehandelten symme­tri­schen Schlüssel für eine sichere Daten­über­tra­gung – die Daten werden verschlüs­selt und mit einem MAC gegen Verän­de­rungen geschützt über­tragen. 
MAC steht für Message Authen­ti­ca­tion Code (zu deutsch Nach­rich­ten­au­then­ti­fi­zie­rungs­code) und dient dazu, Gewiss­heit über den Ursprung von Daten oder Nach­richten zu erhalten und ihre Integrität zu über­prüfen. MAC-Algo­rithmen erfor­dern zwei Eingabe­parameter, erstens die zu schüt­zenden Daten und zwei­tens einen geheimen Schlüssel, und berechnen aus beidem eine Prüf­summe, den Message Authen­ti­ca­tion Code.
Hinweis: SSL ist heut­zu­tage der weiter verbrei­tete Begriff und oftmals ist TLS gemeint, wenn von SSL gespro­chen wird.
HTTPS steht für Hyper­text Transfer Protocol Secure (englisch für „sicheres Hyper­text-Über­tra­gungs­pro­to­koll“) und ist ein Kommu­ni­ka­ti­ons­pro­to­koll im Netz­werk, mit dem Daten abhör­si­cher über­tragen werden können. Es stellt eine Trans­port­ver­schlüs­se­lung dar. 
HTTPS wird zur Herstel­lung von Vertrau­lich­keit und Integrität in der Kommu­ni­ka­tion zwischen NeuroomNet Server und Webbrowser (Client) im Netz­werk verwendet. HTTPS bezeichnet die Verwendung von HTTP über SSL (TLS). Die Verwendung von HTTPS erkennt man im Browser daran, dass der besuchten Inter­net­adresse https statt http voran­ge­stellt ist. Zudem heben die meisten modernen Browser eine abge­si­cherte Verbin­dung zusätz­lich optisch hervor.
Oftmals wird eine abge­si­cherte Verbin­dung mit der Verschlüsselung der Verbin­dung gleich­ge­setzt. SSL/TLS bietet aller­dings noch weitere Sicherheits­eigenschaften. 
Gemäß der ursprüng­li­chen Ausle­gung soll der Client-Browser nach Anwahl der HTTPS-Adresse dem Anwender zuerst das Zertifikat anzeigen. Dieser entscheidet nun, ob er dem Zertifikat für diese Sitzung vertraut, es even­tuell auch perma­nent spei­chert, gege­be­nen­falls nach Prüfung über die ange­ge­benen Links. Andern­falls wird die HTTPS-Verbin­dung nicht herge­stellt („Diese Seite verlassen“ bei Firefox bzw. „Klicken Sie hier um diese Seite zu verlassen.“ beim Internet Explorer).

Die drei Haupt­ziele beim Einsatz von SSL/TLS sind:

  • Vertrau­lich­keit (durch Verschlüsselung)
  • Daten­in­te­grität 
  • Authen­ti­zität

Diese drei Ziele werden im Folgenden erläu­tert.

Vertrau­lich­keit wird durch die Verschlüsselung der Verbin­dung gewähr­leistet. Dies garan­tiert dem Benutzer, dass seine Zugangs-Daten und beispiels­weise Steue­rungs­in­for­ma­tionen nicht von Dritten abge­fangen und miss­braucht werden können. Ebenso schützt es alle Ihre Daten in NeuroomNet und bildet damit auch die Basis zur Einhal­tung der euro­päi­schen DSGVO.
Durch die Gewähr­leis­tung der Integrität der Daten wird garan­tiert, dass eine Mani­pu­la­tion der Steuerung nicht möglich ist. Der Benutzer wäre wahr­schein­lich nicht sehr froh, wenn er statt einem Einschalten- beispiels­weise ein Löschen Befehl absetzt, und das Museum ärgert sich in solch einem Fall über die Kosten und den Aufwand für die Wieder­her­stel­lung. Noch unan­ge­nehmer ist es, wenn jemand fremdes die gesamte Steuerung über­nehmen und damit großen bis exis­tenz­be­dro­henden Schaden anrichten könnte.
Unter Authen­ti­zität versteht man, dass die Iden­tität des Museum-Betrei­bers für den Benutzer über­prüfbar ist. Durch die Sicher­stel­lung der Iden­tität des Museums, weiß der Benutzer genau, mit wem er kommu­ni­ziert. Fehlende Authen­ti­zität können Krimi­nelle beispiels­weise ausnutzen, indem sie Domain­namen regis­trieren, die der Domain eines Museums sehr ähnlich sind und eine Kopie der Steuerung unter diesen Domains bereit­stellen. Der poten­ti­elle Kunde kann nun über eine Phis­hing-E-Mail auf die gefälschte Seite gelockt werden und kann bei einer nicht abge­si­cherten Website nicht direkt erkennen, ob er beim rich­tigen Museum gelandet ist. Er gibt even­tuell seine Zugangs­daten ein und jemand anders kann nun unge­hin­dert das rich­tige Museum ansteuern.
Die Authen­ti­fi­zie­rung dient dazu, dass beide Seiten der Verbin­dung beim Aufbau der Kommu­ni­ka­tion die Iden­tität des Verbindungs­partners über­prüfen können. 

Abge­si­cherte Verbin­dungen in der Praxis

Für den Aufbau einer abge­si­cherten Verbin­dung ist ein SSL/TLS-Zertifikat notwendig. In einem Zertifikat ist unter anderem der Aussteller des Zerti­fi­kats, der Zerti­fi­ka­t­in­haber und der öffent­liche Schlüssel des Zerti­fi­ka­t­in­ha­bers gespei­chert. Zerti­fi­kate werden auf dem Server, mit dem später eine abge­si­cherte Verbin­dung aufge­baut werden soll, abge­legt. Zur Sicher­stel­lung der Integrität eines Zerti­fi­kats, wird es signiert.
Ein Sicher­heits­zer­ti­fikat kann von jeder­mann selbst gene­riert und signiert werden. Aller­dings ist bei selbst signierten Zerti­fi­katen die Authen­ti­zität für Dritte nicht gegeben, da keine unab­hän­gige Insti­tu­tion die Iden­tität des Ausstel­lers über­prüft hat. Die meisten Browser zeigen bei Websites mit selbst signierten Zerti­fi­katen daher eine Warn­mel­dung an. Für die Über­prü­fung der Authen­ti­zität einer Website oder Weban­wen­dung wird eine Vertrauens­kette zwischen dem Browser des Endbe­nut­zers und dem Server der besuchten Website gebildet. Die Browser- und Betriebs­sys­tem­her­steller über­prüfen und vertrauen ausge­wählten Orga­ni­sa­tionen, deren Zerti­fi­kate dann im Browser oder Betriebs­system hinter­legt werden. Diese Orga­ni­sa­tionen werden auch Zertifizierungs­stellen genannt. Die Zertifizierungs­stellen können die Iden­tität von Dritten über­prüfen und nach der Prüfung deren Zerti­fi­kate signieren. Damit bei der Über­prü­fung ein Mindest­stan­dard einge­halten wird, durch­laufen die als vertrau­ens­würdig einge­stuften Orga­ni­sa­tionen zuvor einen Zertifizierungs­prozess. Beim Besu­cher einer Website oder Nutzer einer Weban­wen­dung wird schluss­end­lich über­prüft, ob die Vertrauens­kette intakt ist.
Für die Über­prü­fung der Iden­tität gibt es verschie­dene Stufen, die sich im Umfang der Über­prü­fung unter­scheiden. Auf der nied­rigsten Stufe (Klasse 1), wird nur über­prüft, ob der Antrag­steller im Besitz der im Zertifikat vermerkten Domain ist. Bei Klasse 2‑Zertifikaten wird die Iden­tität des Antrag­stel­lers (Einzel­person oder Unter­nehmen) beispiels­weise mit Kopien von Ausweis­do­ku­menten und Firmen­unterlagen genauer über­prüft. Bei Klasse 3‑Zertifikaten ist die Über­prü­fung noch­mals inten­siver und weitere Doku­mente sind erfor­der­lich. Klasse 3‑Zertifikate werden auch als Extended-Vali­da­tion-Zerti­fi­kate bezeichnet und zeichnen sich unter anderem dadurch aus, dass die Verwendung in modernen Brow­sern optisch deut­lich hervor­gehoben wird. 

Empfeh­lungen für den Einsatz von HTTPS

Bei der Über­tra­gung von sensi­blen Daten ist der Einsatz eines von einer Zerti­fi­zie­rungs­stelle signierten SSL/TLS-Zerti­fi­kats immer Pflicht. Soll nur ein persön­li­cher Login-Bereich geschützt werden, reicht unter Umständen ein selbst signiertes oder vom Hosting-Provider signiertes Zertifikat aus. Bei selbst signierten Zerti­fi­katen muss aber auch dem Client die ausstel­lende Zerti­fi­zie­rungs­stelle als vertrau­ens­würdig hinter­legt werden, damit es nicht zu Warn­meldungen des Brow­sers kommt. Diese Einstel­lungen können von IT-Experten vorge­nommen werden. Das Einrichten einer netz­werk­weiten PKI Struktur ist sowohl unter Linux als auch Windows möglich. Wenn kein geeig­neter IT-Exper­te/Ad­mi­nis­trator vor Ort ist, kann NeuroomNet auch passende Experten vermit­teln und sogar die Wartung über­nehmen. Diese Experten klären, falls erfor­der­lich, die notwen­digen Unter­lagen zum Erhalt externer Zerti­fi­kate und richten diese dann auch ein. Interne Zerti­fi­kate können sehr lange Lauf­zeiten aufweisen, während externe Zerti­fi­kate schon nach einem Jahr erneuert werden müssen. 

Anmer­kungen zur Authen­ti­zität

Die Authen­ti­zität ist in der Theorie beim Einsatz von SSL/TLS-Zerti­fi­katen zwar gegeben, in der Praxis gibt es mit der Authen­ti­zität jedoch so seine Probleme und ob man auf die Iden­tität des Betrei­bers einer Website vertrauen kann, muss im Einzel­fall entschieden werden. Zum einen werden Level 1‑Zertifikate meist auto­ma­ti­siert vergeben. Dies bedeutet, dass auch für Tipp­feh­ler­do­mains, die häufig für Phis­hing-Angriffe einge­setzt werden, gültige Zerti­fi­kate erworben werden können. Zum anderen steht und fällt die Authen­ti­zität mit dem Vertrauen in die Arbeit der Zertifizierungs­stellen. Wenn es nur eine Zerti­fi­zie­rungs­stelle gibt, die bei der Echtheits­prüfung der Doku­mente der Antrag­steller unsauber arbeitet oder Namens­ähn­lich­keiten mit anderen Unter­nehmen igno­riert, ist es für Krimi­nelle möglich, Zerti­fi­kate für Unter­nehmen signieren zu lassen, mit denen sie eigent­lich nichts zu tun haben. 

Zertifikat

Das digi­tale Zertifikat für SSL/TLS, das die Authen­ti­fi­zie­rung ermög­licht, ist vom Server bereit­zu­stellen: Ein Binär­do­ku­ment, das im Allge­meinen von einer – selbst wiederum zerti­fi­zierten – Zerti­fi­zie­rungs­stelle (CA von englisch certi­fi­cate autho­rity) ausge­stellt wird, das den Server und die Domain eindeutig iden­ti­fi­ziert. Ein ausge­stelltes Zertifikat gibt immer Auskunft über den Aussteller (Zerti­fi­zie­rung­s­telle) und denje­nigen der das Zertifikat bean­tragt hat (z.B. der Webserver und dessen Betreiber).
Bei der Bean­tra­gung werden dazu etwa die Adress­daten und der Firmen­name des Antrag­stel­lers geprüft. 

Zerti­fi­zie­rungs­stelle (CA)

In der Infor­ma­ti­ons­si­cher­heit ist eine Zerti­fi­zie­rungs­stelle (englisch certi­fi­cate autho­rity oder certi­fi­ca­tion autho­rity, kurz CA) eine Orga­ni­sa­tion, die digi­tale Zerti­fi­kate heraus­gibt. Ein digi­tales Zertifikat dient dazu, einen bestimmten öffentlichen Schlüssel einer Person oder Orga­ni­sa­tion zuzu­ordnen. Diese Zuord­nung wird von der Zerti­fi­zie­rungs­stelle beglau­bigt, indem sie sie mit ihrer eigenen digitalen Unter­schrift versieht.
 
Die digitalen Zerti­fi­kate enthalten „Schlüssel“ und Zusatz­informationen, die zur Authen­ti­fi­zie­rung sowie zur Verschlüsselung und Entschlüs­se­lung vertrau­li­cher Daten dienen, die über das Internet und andere Netze verbreitet werden. Als Zusatz­informationen sind zum Beispiel Gültig­keits­dauer, Verweise auf Zerti­fi­kat­sperr­listen etc. enthalten, die durch die CA mit in das Zertifikat einge­bracht werden.
 
Die Aufgabe einer Zerti­fi­zie­rungs­stelle lautet, diese digitalen Zerti­fi­kate heraus­zu­geben und zu über­prüfen. Sie trägt dabei die Verant­wor­tung für die Bereit­stel­lung, Zuwei­sung und Inte­gri­täts­si­che­rung der von ihr ausge­ge­benen Zerti­fi­kate. Damit bildet sie den Kern der Public-Key-Infra­struktur.
 
Eine Zerti­fi­zie­rungs­stelle kann ein spezi­elles Unter­nehmen sein oder eine Insti­tu­tion inner­halb eines Unter­neh­mens, das einen entspre­chenden eigenen Server instal­liert hat (zum Beispiel mit Open­S­SL/­Un­ter­neh­mens-PKI von Micro­soft). Auch öffent­liche Orga­ni­sa­tionen oder Regie­rungs­stellen können als Zerti­fi­zie­rungs­stelle dienen, z.B. in Deutsch­land die Bundes­netz­agentur.
 
In Deutsch­land müssen für die Ausgabe von fort­ge­schrit­tenen elek­tro­ni­schen Zerti­fi­katen gemäß § 2 Nummer 2 Signa­tur­ge­setz (SigG) bezie­hungs­weise für quali­fi­zierte elek­tro­ni­sche Signa­turen gemäß § 2 Nummer 3 Signa­tur­ge­setz zusätz­liche, gesetz­lich fest­ge­legte Voraus­set­zungen erfüllt werden. Insbe­son­dere unter­liegen die Aussteller der Zerti­fi­kate der Aufsicht der Bundes­netz­agentur, um die Zuver­läs­sig­keit und Integrität dieser Zerti­fi­kate im Rechts­ver­kehr zu gewähr­leisten. Beispiels­weise muss sich der Antrag­steller für eine solche Signatur bei einer geneh­migten Stelle durch seinen Perso­nal­aus­weis persön­lich iden­ti­fi­zieren, damit ein solches elek­tro­ni­sches Zertifikat auf ihn ausge­stellt werden kann. Die von den Ausstel­lern betrie­benen Rechen­zen­tren müssen beson­ders gesi­chert sein und erfüllen damit hohe Sicher­heits­an­for­de­rungen. 

PKI

PKI steht für Public-Key-Infra­struc­ture (deutsch, Infra­struktur für öffent­liche Schlüssel) und hiermit bezeichnet man in der Kryp­to­logie ein System, das digi­tale Zerti­fi­kate ausstellen, verteilen und prüfen kann. Die inner­halb einer PKI ausge­stellten Zerti­fi­kate werden zur Absicherung rech­ner­ge­stützter Kommu­ni­ka­tion verwendet.
Heutige Sicher­heit in Unter­nehmen setzt dabei auf mehr­stu­fige Systeme, damit die oberste Zerti­fi­zie­rungs­stelle und sein privater Key nicht kompro­mit­tiert (also von Gaunern oder böswil­ligen Menschen ausge­lesen und miss­braucht) werden können. 
https://de.wikipedia.org/wiki/Public-Key-Infrastruktur 

Schlüssel (Kryp­to­logie)

Als Schlüssel (englisch Key) wird in der Kryp­to­logie eine Information bezeichnet, die einen kryp­to­gra­phi­schen Algorithmus para­me­tri­siert und ihn so steuert.
Bei modernen, compu­ter­ba­sierten symme­tri­schen und auch asym­me­tri­schen Verfahren ist der Schlüssel eine Bitfolge.
 Der Schlüssel ist die zentrale Komponente, um einen Geheim­text zu entschlüs­seln und so den Klar­text zu gewinnen.

Schlüssel bei symme­tri­schen Verfahren

Bei symme­tri­schen Verfahren, also bei allen klassischen Methoden der Kryp­to­gra­phie und auch bei modernen Algo­rithmen wie beispiels­weise dem Data Encryp­tion Stan­dard (DES) oder seinem Nach­folger, dem Advanced Encryp­tion Stan­dard (AES), verwenden beide Kommunikations­partner denselben (geheimen) Schlüssel sowohl zum Ver- als auch zum Entschlüs­seln. Während klas­si­sche Methoden, bei denen der Text von Hand geschlüs­selt (also verschlüs­selt und/oder entschlüs­selt) werden muss, als Schlüssel fast immer ein Kenn­wort benutzen, besteht der Schlüssel bei modernen, also compu­ter­ba­sierten, symme­tri­schen Verfahren zumeist aus einer Bitfolge.
Die Sicher­heit eines Verfah­rens hängt außer vom Algorithmus selbst auch von der Schlüs­sel­länge ab. Wenn gegen ein Verfahren ein Angriff gefunden wird, der effi­zi­enter ist als die Brute-Force-Methode, das Auspro­bieren aller mögli­chen Schlüssel, gilt das Verfahren als gebro­chen. Die Schlüs­sel­länge gibt bei einem sicheren Verfahren also direkt das Sicher­heits­ni­veau an.

Schlüssel bei asym­me­tri­schen Verfahren

Asym­me­tri­sche Verfahren, wie beispiels­weise das RSA-Kryp­to­system, verwenden Schlüs­sel­paare, die aus einem öffentlichen Schlüssel (engl. public key) und einem privaten (geheimen) Schlüssel (engl. private key) bestehen.
Der öffent­liche Schlüssel ist nicht geheim, er soll anderen Benut­zern bekannt sein, beispiels­weise durch Vertei­lung über Schlüssel­server bzw. Zertifizierungs­stellen. Mit ihm können öffent­liche Opera­tionen durch­ge­führt werden, also Nach­richten verschlüs­selt oder digi­tale Unter­schriften geprüft werden. Dabei ist es wichtig, dass ein öffent­li­cher Schlüssel eindeutig einem Benutzer oder Unter­nehmen zuge­ordnet werden kann. Ist das nicht der Fall, wird etwa eine Nach­richt mit dem öffentlichen Schlüssel eines anderen Benut­zers verschlüs­selt, so kann dieser die Nach­richt lesen, obwohl sie nicht für ihn bestimmt war. Um Schlüssel leicht benennen zu können, benutzt man einen Finger­ab­druck, einen kurzen Hash­wert, der einen Schlüssel eindeutig iden­ti­fi­ziert.
Um einen Geheim­text wieder zu entschlüs­seln oder eine Nach­richt zu signieren, wird der private Schlüssel benö­tigt. Im Gegen­satz zu symme­tri­schen Verfahren, bei denen sich mehrere Benutzer einen geheimen Schlüssel teilen, verfügt beim asym­me­tri­schen Verfahren nur ein Benutzer/Unternehmen über den privaten (geheimen) Schlüssel. Dieser Umstand ermög­licht es erst, eine Signatur eindeutig einem Benutzer/Unternehmen zuzu­ordnen. Daher ist es grund­le­gend, dass der private Schlüssel nicht aus dem öffentlichen abge­leitet werden kann. 

Für mehr Beispiele und Erläu­te­rungen werfen Sie einen Blick in unsere Dokumentation.