Nützliche Brancheninformationen, aktuelle Presseartikel und Neuerungen zu unserem Cloud-Speicher & Datenraum-Dienst iDGARD erhalten Sie auch über RSS und unsere Seiten in den sozialen Netzwerken.
privacyblog newsletter Lieber das Neueste aus dem privacy blog per eMail erhalten? Melden Sie sich hier für unseren kostenlosen Newsletter an.
privacyblog rss feed Der privacy blog als RSS feed für Ihren Reader.
Folgen Sie uns: Uniscon on Twitter Uniscon on Facebook Uniscon on LinkedIn Uniscon on YouTube Uniscon on google+ Uniscon on Xing

iDGARD von Prozessor-Sicherheitslücke nicht betroffen

Nach den Medienberichten über Sicherheitslücken in einer Vielzahl von Prozessoren sind viele Nutzer von Cloud-Diensten verständlicherweise verunsichert, ob ihre Daten dort wirklich sicher sind. Wir wollen Sie im Folgenden kurz über die technischen Zusammenhänge informieren und Ihnen erläutern, warum Sie als iDGARD-Nutzer von dieser Sicherheitslücke nicht betroffen sind.

Eine Frage der Architektur

Die diskutierte Sicherheitslücke liegt in der Architektur der meisten modernen Mikroprozessoren begründet. Dabei handelt es sich um eine Schwachstelle, die auf eine möglichst effiziente Nutzung von Prozessor-Ressourcen zurückzuführen ist. Diese Schwachstelle ist weder neu, noch wurde sie gerade erst entdeckt; vielmehr sind im Prinzip alle Hochleistungs-Mikroprozessoren betroffen, die bestimmte Funktionseinheiten zur Optimierung der Leistungsfähigkeit enthalten, und das bereits seit vielen Jahren.

Vereinfacht ausgedrückt rührt die Schwachstelle daher, dass vorgezogene Operationen im Progammablauf eines Prozessors vorgenommen werden. Das heißt, dass beispielsweise Codebereiche „im Voraus“ bearbeitet werden, die sich hinter Programm-Verzweigungsstellen befinden. Dies geschieht in der Annahme, dass der Code nach der Verzweigung in der einen oder anderen Richtung zu bearbeiten sein wird (Branch Prediction, Speculative Execution). Dies ist beispielsweise sinnvoll, um die Speicher- und Verarbeitungseinheiten des Prozessors möglichst gut zu synchronisieren und Leerlaufzeiten zu vermeiden.

Da sichergestellt ist, dass die vorab generierten Daten entweder verwendet (Verzweigung richtig vorhergesagt) oder bei falscher Voraussage verworfen werden, ist diese Vorgehensweise sicherheitstechnisch an sich eigentlich unbedenklich.

Wo liegt das Problem?

Zu einem Datenschutzrisiko wird dieses Verfahren erst in Szenarien, in denen sich mehrere Nutzer die gleiche Prozessorhardware teilen, wie es bei „Virtual Server“-Diensten der Fall ist, zu denen auch viele Cloud-Computing-Anwendungen gehören. Normalerweise werden den Nutzern exklusive Speicherbereiche für Code und Daten zugewiesen und diese überwacht, so dass ausgeschlossen ist, dass ein Nutzer auf Daten eines anderen Nutzers zugreifen kann. Dieser Mechanismus kann jedoch überlistet werden, indem bewusst spekulative Operationen provoziert werden, die in Programmbereichen eines anderen Nutzers liegen (beispielsweise durch falsche Voraussage der Branch-Prediction-Einheit). So können durch die Auswertung der Art der Nutzung des Zwischenspeichers indirekt Rückschlüsse auf die spekulativ durchgeführten Operationen abgeleitet werden.

Diese Informationen sind zwar zunächst nicht sehr aussagekräftig, jedoch können durch millionenfaches Wiederholen mit jeweils leicht veränderten Parametern unter bestimmten Voraussetzungen relevante Informationen über Code und/oder Daten außerhalb des eigenen Speicherbereiches erlangt werden. Detaillierte Informationen zu derartigen Angriffen finden Sie in diesem Paper.

Diese altbekannte Schwachstelle wurde bisher bewusst in Kauf genommen. So kann die Lücke durch geeignete Maßnahmen im Betriebssystem weitgehend „zugedeckt“ werden. Darüber hinaus ist es nicht sehr wahrscheinlich, dass durch „planloses“ Angreifen auf fremde Bereiche kritische Daten gewonnen werden können – besonders, da die angreifbaren Bereiche relativ klein sind und ohne zusätzliche Kenntnisse über Struktur und Verwendung des angegriffenen Bereiches nur schwer sinnvolle Aussagen möglich sind.

Allerdings haben die in den letzten Monaten bekannt gewordenen, immer ausgefeilteren Angriffsszenarien (z.B. Meltdown-Attacken) dazu geführt, dass das Risiko inzwischen deutlich höher bewertet wird. So fordert auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) Dienstanbieter dazu auf, ihre Anwendungen schnellstmöglich abzusichern und Sicherheitspatches für Betriebssysteme und Browser unmittelbar einzuspielen, sobald sie veröffentlicht werden.

iDGARD: Sicher dank Privacy by Design

iDGARD-Nutzer hingegen können aufatmen: Die Vertraulichkeit ihrer Daten ist auch im Hinblick auf die beschriebene Prozessor-Sicherheitslücke nicht gefährdet. Denn die Sicherheitslücke kann immer nur dann kritisch werden, wenn sich Programme verschiedener Nutzer eine gemeinsame Prozessor-Ressource teilen.

Dies ist bei iDGARD nicht der Fall, da im System ausschließlich Software ausgeführt wird, die von Uniscon selbst erstellt bzw. verifiziert und freigegeben wurde. Das Einbringen von im System ablauffähigem Code durch Nutzer ist nicht vorgesehen und daher technisch ausgeschlossen. Aus diesem Grund ist es nicht möglich, „bösartige“ Software in das System einzuschleusen, die Nutzerdaten ausspähen könnte.

Möchten Sie iDGARD und die Sealed Cloud selbst ausprobieren?

Dann melden Sie sich jetzt bei iDGARD an! Testen Sie den versiegelten Cloud-Dienst aus Deutschland im iDGARD-Starter-Paket inklusive Boxmail, 100 GB Speicher, 5 Voll- und 25 Gastlizenzen kostenlos!

Eine automatische Verlängerung findet nicht statt.

Wir freuen uns auf Ihr Feedback zu iDGARD. Teilen Sie uns Ihre Meinung mit uns schreiben Sie uns an: support@idgard.de.

Leser dieses Artikels interessieren sich auch für folgende Inhalte:

Datenschutzzertifizierungen von Cloud Diensten

Was ist die Sealed Cloud Technologie?

Gibt es eine Lücke zwischen Vertrauen und Innovation in der digitalen Welt?