Betreff: Presseberichterstattung zu Angriffen auf SSL/TLS und ggf. resultierende Fragestellungen zu Auswirkungen auf die TI

Transkript

1 Bundesamt für Sicherheit in der Informationstechnik Postfach , Bonn Bundesministerium für Gesundheit Herrn Dr. Matthias von Schwanenflügel Friedrichstraße Berlin Betreff: Presseberichterstattung zu Angriffen auf SSL/TLS und ggf. resultierende Fragestellungen zu Auswirkungen auf die TI Dr. Thomas Hesselmann HAUSANSCHRIFT Bundesamt für Sicherheit in der Informationstechnik Godesberger Allee Bonn POSTANSCHRIFT Postfach Bonn TEL +49 (0) FAX +49 (0) Bezug: BMG UALZ2 vom Bitte um Stellungnahme Datum: Seite 1 von 1 Sachstand Mit Schreiben BMG UALZ2 vom bittet das BMG das BSI um Stellungnahme zu den jüngsten Presseberichten über die mögliche Einflussnahme von Nachrichtendiensten auf die Sicherheit von Internet-Protokollen. Die nachstehende Stellungnahme des BSI bezieht sich auf die Darstellung in der Süddeutschen Zeitung. Quelle: elungen-im-internet In den aktuellen Veröffentlichungen wird behauptet, Nachrichtendienste seien in der Lage, im großen Stil Verschlüsselungstechniken, die persönliche[n] Daten, s, Bank-Überweisungen, oder andere Online-Aktivitäten schützen, zu brechen oder diese zu umgehen. Weiter heißt es, dass große Fortschritte gegen die SSL-Technologie erzielt wurden. Es werden dabei drei Angriffswege gegen die Verschlüsselung genannt: UST-ID/VAT-No: DE KONTOVERBINDUNG: Deutsche Bundesbank Filiale Saarbrücken, Konto: , BLZ: , IBAN: DE , BIC: MARKDEF1590 ZUSTELL- UND LIEFERANSCHRIFT: Bundesamt für Sicherheit in der Informationstechnik, Godesberger Allee , Bonn

2 1. Angriffe mit Supercomputern, welche die verwendeten Kryptoverfahren mit Rechenkraft brechen können, 2. Einbau von speziellen Hintertürchen (=Schadprogramme) in IT-Sicherheitsprodukte und -Lösungen auf Veranlassung von Nachrichtendiensten und in enger Kooperation mit den betroffenen Herstellern und Internet-Providern, 3. Gezielte Spezifizierung von Schwachstellen bei der Entwicklung von Verschlüsselungsstandards auf Betreiben der Nachrichtendienste und deren spätere, nachrichtendienstliche Ausnutzung durch Eingriffe in alle nach diesen Standards entwickelten Produkte, Lösungen und Dienstleistungen. In den Veröffentlichungen wird nicht beschrieben (auch nicht in groben Zügen), wie genau das Verschlüsselungsprotokoll SSL / TLS angegriffen wird. Daher können in dieser Stellungnahme nur Annahmen über mögliche Vorgehensweisen potenzieller Angreifer getroffen werden. Stellungnahme: 1. Mögliche Schwachstellen und Angriffsmöglichkeiten bei SSL/TLS TLS (Transport Layer Security) ist ein kryptographisches Protokoll zur Etablierung eines sicheren Kanals (verschlüsselt und integritätsgeschützt). Das Protokoll läuft auf der Verbindungsebene statt, so dass es weitgehend transparent für die darüberliegende Anwendung genutzt werden kann. Der häufigste Einsatzzweck ist die Absicherung der Auslieferung von Webseiten über das HTTPS Protokoll. Weitere bekannte Anwendungsfälle sind der sichere Transport von s und VPNs. Der Spezifikationsstandard von TLS wird von der IETF (Internet Engineering Task Force) in RFCs (Request For Comment) in einem öffentlichen Diskussionsprozess standardisiert. Die absichtliche Einbringung von Schwächen in derartige Standards ist bei der breiten öffentlichen Diskussion über die entsprechenden Dokumente zwar eher unwahrscheinlich, andererseits aber auch nicht ganz auszuschließen. Z.B. könnte die konkrete Ausgestaltung eines Standards spätere nachrichtendienstliche Aufklärungsaktivitäten begünstigen. Der TLS-Standard kann aber deswegen nicht als grundsätzlich unsicher angesehen werden. Allerdings entwickeln sich die Erkenntnisse über Schwachstellen und entsprechenden Gegenmaßnahmen ständig weiter und erfordern damit auch eine permanente Überarbeitung des TLS-Standards. Ältere Versionen als die jeweils aktuelle sollten daher nicht mehr oder wenn, dann unter Beachtung bestimmter Randbedingungen eingesetzt werden. Die Nutzung von TLS Version 1.1 und höher sieht das BSI grundsätzlich aber weiterhin als sicher an. TLS kann in verschiedenen Konfigurationen genutzt werden, jedoch nicht alle sind auch sicher. Beispielsweise werden beim TLS-Aufbau die zu verwendenden kryptographischen Algorithmen ausgehandelt. Aus Interoperabilitätsgründen können hierbei auch Algorithmen ausgehandelt werden, die heute als kryptographisch unsicher anzusehen sind. Mit entsprechenden technischen Hilfsmitteln wie Supercomputern sowie kryptographischem Know-How ist es bei diesen unsicheren Algorithmen möglich, den Schlüssel herzuleiten.

3 Das BSI verfolgt entsprechende Entwicklungen und veröffentlicht jährlich Empfehlungen über geeignete Algorithmen, Schlüssellängen und weiteren Parametern. Anwendungsspezifische Vorgaben finden sich in der Technischen Richtlinie ecard-projekte der Bundesregierung. Zur besseren Übersicht seien hier diesbezügliche Technische Richtlinien des BSI genannt, die auch auf unserer Webseite zur Verfügung stehen und bei Prüfungen von Produkten im Rahmen von BSI-Zertifizierungsverfahren Anwendung finden. Anwendungsspezifische Vorgaben für Kryptoverfahren finden sich in der Technischen Richtlinie ecard-projekte der Bundesregierung: TR-03116: TR für ecard-projekte der Bundesregierung TR Teil 1: Vorgaben für das Gesundheitswesen TR Teil 2: Hoheitliche Ausweisdokumente TR Teil 3: Kryptographische Vorgaben für die Infrastruktur von intelligenten Messsystemen TR Teil 4: Vorgaben für Kommunikationsverfahren im egovernment: Allgemeine, anwendungsunabhängige kryptographische Vorgaben sind darüber hinaus in der TR dokumentiert, u.a. auch Empfehlungen zur Nutzung von zertifizierten Komponenten zur Schlüsselspeicherung. Im Rahmen einer BSI-Zertifizierung wird die Einhaltung der Vorgaben für konkrete Implementierungen von Kryptoverfahren bzw. Produkten geprüft, so dass die so zertifizierten Produkte dann auch eine vertrauenswürdige Implementierung des TLS-Standards darstellen. Bei konsequenter Umsetzung der Vorgaben sowie bei Verwendung von Produkten vertrauenswürdiger Hersteller ist eine nachträgliche Entschlüsselung abgehörter Daten durch passive Angriffe unwahrscheinlich. Dies gilt natürlich nicht, wenn ein Produkt nach der Zertifizierung und vor der Auslieferung durch den Hersteller selbst oder auf Veranlassung Dritter verändert wird. Bei aktiven Angriffen hingegen greift der Angreifer auch bei unverändertem Produkt gezielt in eine Kommunikation ein mit dem Ziel, die Verschlüsselung der Daten zu umgehen oder herabzusetzen. Hierfür kann er direkt die TLS-Komponente selber negativ beeinflussen (z.b. deterministischer Seed für Zufallszahlengenerator) oder die Daten auf der Übertragungsstrecke manipulieren (Man-in-the-Middle Angriffe). Hierzu bieten sich aufgrund der Struktur von TLS eine Reihe von Ansatzpunkten an, die z.t. aber mit erheblichem Aufwand verbunden sind und nur schwer flächendeckend eingesetzt werden können. Hier wird deutlich, dass die sichere Implementierung einer sicheren TLS-Version immer zusätzlich der Vertrauenswürdigkeit des ausliefernden Herstellers und Providers bedarf. Darüber hinaus können aber all diese Voraussetzungen einschließlich einer korrekten, sicheren Konfiguration aller Komponenten (einschließlich Prüfung durch Zertifizierung) sowie sichere Einsatzumgebung der TLS-Komponente erfolgreiche Angriffe gegen die Infrastruktur nicht vollständig ausschließen. Bei dieser zusätzlichen Art von Angriffen handelt es sich um Eingriffe in die Zertifikatsinfrastruktur, wobei der Angreifer Kontrolle über eine vertrauenswürdige Zertifizierungsstelle erlangt, von der digitale Zertifikate herausgegeben werden.

4 Erläuterung: Ein inhärentes Problem bei der Verwendung von TLS in Webbrowsern ist, dass die vertrauenswürdigen Wurzelzertifikate in den Webbrowsern vorinstalliert sind und jede dieser Zertifizierungsstellen für jede Webseite Zertifikate ausstellen kann. Sofern eine der installierten Zertifizierungsstellen kompromittiert ist (s. Vorfälle Diginotar, Commodo,...) oder wenn Nachrichtendienste aufgrund gesetzlicher Vorgaben die Befugnis haben, beliebige Zertifikate auszustellen, kann der Angreifer prinzipiell jede Webseite übernehmen. Das gleiche Problem entsteht natürlich auch, wenn ein Angreifer in der Lage ist, Wurzelzertifikate zu beeinflussen. Hier kann sich der Eingriff dann über die gesamte nachfolgende Zertifizierungsinfrastruktur erstrecken. Die mit den potenziellen Möglichkeiten zur Manipulation einer Zertifizierungsinfrastruktur zusammenhängenden Probleme lassen sich jeweils nur anwendungsspezifisch lösen, in dem die Anzahl der vertrauenswürdigen Wurzelzertifikate auf ein Minimum reduziert wird und als Inhaber und Betreiber einer Wurzelzertifikatsstelle nur solche Provider ausgewählt werden, die im konkreten Anwendungsbezug ein uneingeschränktes Vertrauen genießen und gleichzeitig einer hinreichenden technischen und organisatorischen Kontrolle unterzogen werden, um ihre diesbezügliche Vertrauenswürdigkeit kontinuierlich sicherzustellen. Im Idealfall wäre anzustreben, dass jeweils nur ein Wurzelzertifikat einer Zertifizierungsstelle unter der direkten Kontrolle der für die Anwendung verantwortlichen Institution bzw. Behörde eingerichtet wird. Dies ist für allgemeine Online-Dienstleistungen im Internet kurzfristig natürlich nicht durchsetzbar. Allerdings gibt in bestimmten Fällen, z.b. in denen dem Gesetzgeber die Verantwortung über die Sicherheit einer kritischen Infrastruktur obliegt, die Möglichkeit, derartig sichere Zertifizierungshierarchien mittels geeigneter Vorschriften und Standards einzuführen und einer kontinuierlichen Kontrolle zu unterwerfen. 2. Auswirkungen auf die TI In der Telematikinfrastruktur (TI) werden etablierte und erprobte Protokolle wie TLS oder IPsec verwendet. Das SSL (Secure Sockets Layer) ist ein Vorgänger von TLS. SSL sowie TLS Version 1.0 weisen eine Reihe von bereits bekannten Schwächen auf, daher empfiehlt das BSI, TLS Version 1.1 oder höher zu nutzen. Die Telematikinfrastruktur (TI) folgt dieser Empfehlung (siehe gemspec_krypt). In der TR findet man weitere Vorgaben für das Gesundheitswesen, die in der gematik-spezifikation entsprechend berücksichtigt werden.ein zentraler Punkt bei dem im Presseartikel genannten "Umgehen [... von ] Verschlüsselungstechniken" ist die unzureichende Güte von Zufallszahlen und den daraus gebildeten kryptographischen Schlüsseln. Dazu finden sich ebenfalls detaillierte Empfehlungen in der TR Eine Anpassung der Technischen Richtlinie auf Grund der jüngsten Presseberichte sieht das BSI zurzeit nicht als notwendig an. Wie oben dargestellt, kann ein Angreifer bei Verwendung eines nicht vertrauenswürdigen Root-Zertifikates prinzipiell jede TLS-Verbindung übernehmen. Die Sicherheitsarchitektur der TI berücksichtigt diesen Aspekt durch den Einsatz einer Trust-service Status List (TSL) als zentraler Vertrauensraum der X.509-PKI sowie durch den Einsatz einer hierarchischen Root-Struktur bei den CV-Zertifikaten. In einem sicherheitskritischen Schadensfall werden in Abstimmung mit den Beteiligten geeignete Maßnahmen herbeigeführt (wie das Entfernen einer kompromittierten Teil-PKI aus der TSL).

5 Im Falle der Verschlüsselung mit Hilfe TI-fremder Zertifikate, z.b. bei der Integration von Bestandsanwendungen bzw. Bestandsnetzen in die TI muss das Schlüsselmanagementproblem auf eine andere Weise gelöst werden. Hier können bei Verwendung nicht-vertrauenswürdiger Root-Zertifikate die o.g. Probleme auftreten, die durch organisatorische Maßnahmen allein nicht gelöst werden können. Das BSI hat aus diesem Grunde auch schon vor den hier zu kommentierenden Veröffentlichungen immer größten Wert darauf gelegt, dass mit der Integration von Bestandsanwendungen und -netzen in die TI keine Internet-spezifischen Sicherheitsprobleme mit integriert werden. In der TI ist sichergestellt, dass Fachdienste und Infrastrukturdienste der zentralen TI nur innerhalb des deutschen Rechtsraums betrieben werden dürfen. Die Einhaltung der Anforderungen an TLS aus der gematik-spezifikation und TR werden für die dezentralen Produkte der TI im Rahmen einer CC-Zertifizierung geprüft. Für die zentralen Produkte der TI gibt es Sicherheitsanforderungen für Test, Zulassung und Betrieb. Im Rahmen der Zulassungen müssen Anbieter von Produkten der zentralen TI nachweisen, dass sie gemäß der Norm ISO/IEC ihre Produkte (Fachdienste oder Infrastrukturdienste der zentralen TI-Plattform) sicher betreiben. Auch sind sie verpflichtet mit dem koordinierenden Informationssicherheitssystem der TI zusammen zu arbeiten (regelmäßige Kennzahlen bereitstellen; Informationspflicht über sicherheitsrelevante Vorfälle über einer bestimmten Vorfallsschwere). Es ist ein betreiberspezifisches Sicherheitskonzept inklusive Bedrohungsanalyse, Wirksamkeitsnachweis der Sicherheitsmaßnahmen, Restrisikoabschätzung und Notfallkonzept zu erstellen, welches im Rahmen der Zulassung für die TI von einem unabhängigen Sicherheitsgutachter geprüft wird. Das Sicherheitskonzept ist dabei laufend fortzuschreiben. Die Umsetzung der im Sicherheitskonzept beschriebenen Maßnahmen wird von unabhängigen Sicherheitsgutachtern u.a. vor Ort beim Betreiber überprüft. Es ist also vom Sicherheitsstandpunkt wichtig, dass für zentrale Produkte der TI wie Fachdienste sowie für die direkt kommunizierenden Fachclients ein entsprechender Sicherheitsnachweis erbracht wird. Eine zeitnahe Migration der Anwendungen aus den Bestandsnetzen in die TI inklusive der zusätzlichen Sicherheitsnachweise ist daher zur Abwehr von Angriffen wie die in den jüngsten Presseberichten genannten aus Sicht des BSI unbedingt notwendig. Abschließend ist festzuhalten, dass bei Einhaltung der bestehenden Vorgaben ein notwendiges Sicherheitsniveau auch in Bezug auf die aktuell im Presseartikel referenzierten Probleme erreichbar ist. Zentrale Punkte dabei sind Die Sicherheitsleistung der eingesetzten Produkte bzw. zu migrierenden Bestandsanwendungen und -netze muss vor Einsatz in der TI von unabhängigen Instanzen überprüft und bestätigt werden. Dazu müssen auch eindeutige Verantwortlichkeiten (organisatorisch, ggf. auch haftungsrechtlich) vorab zugewiesen werden. Das Schlüsselmanagement für den Einsatz der kryptographischen Verfahren in der TI muss überprüfbar den für die PKI der TI definierten Anforderungen entsprechen. Die Güte der verwendeten Schlüssel muss sichergestellt sein. Die kryptographischen Vorgaben aus der TR müssen umgesetzt werden.

6 Die Überwachung des Betriebs innerhalb der TI muss auf Grundlage von ISO/IEC erfolgen, um auf Probleme zeitnah reagieren zu können. Datenknoten, die in die TI führen, müssen überwacht werden. Eine ungesicherte Datenverbindung in Netze außerhalb der TI erzeugt Sicherheitsrisiken. Weiteres Vorgehen Einhaltung der in den Spezifikationen der gematik und den Technischen Richtlinien und Schutzprofilen des BSI für die Telematik-Infrastruktur gestellten Sicherheitsvorgaben. Gewährleistung der Sicherheit der in die TI zu migrierenden Bestandsanwendungen und -netze auf ein den Sicherheitsanforderungen der TI entsprechendes Niveau. Eindeutige Zuordnung der Verantwortlichkeiten für die Sicherheit der in die TI zu integrierenden Bestandsanwendungen und -netze. Im Auftrag gez. Kowalski