Anbieter zum Thema

MicroConsult Academy GmbH

emlix GmbH

Kryptologie – sichere Software, die nicht zu knacken ist?

Bei der Entwicklung von Embedded-Systemen können durch den Einsatz von kryptologischen Verfahren viele Prozesse sicher oder zumindest sicherer gemacht werden. Reinhard Wobst (UNIX Software) hat in seiner Funktion als Softwareentwickler festgestellt, dass mit großer Regelmäßigkeit immer wieder die gleichen Fehler bei der Implementierung von Kryptologie gemacht werden.

Während seines Vortrags auf dem ESE Kongress erklärte er, warum und wie es Eindringlingen oft unnötig leicht gemacht wird. So gehen Softwareentwickler häufig davon aus, dass niemand die von ihnen entwickelten Algorithmen knacken kann. Das Gegenteil ist der Fall. Ein gängiges Mittel ist etwa das Schreiben unklaren oder scheinbar verworrenen Codes.

Doch gerade bei der heutigen Vernetzung wird jedes Verfahren früher oder später bekannt. Interessant ist die auch von Wobst formulierte Erkenntnis, dass der Selbsttest eines eigenentwickelten Algorithmus möglicherweise zu dem Ergebnis führt, dass es nicht einmal dem ursprünglichen Programmierer gelingt, ihn zu knacken.

Aber die Wirklichkeit sieht leider anders aus: "Jeder kann einen Algorithmus entwickeln, den er selbst nicht brechen kann, aber es geht darum, dass ihn andere nicht brechen können."[1]

Letztlich sieht man es einem Algorithmus, auch wenn er noch so obskur erscheint, nicht an, ob er nun sicher ist oder nicht. Wobst rät seinen Entwicklerkollegen, konservativ zu sein und bekannte und altbewährte Algorithmen und Methoden zu nutzen. Das Forschen nach Sicherheit solle den Forschern überlassen werden.

Anhand zahlreicher Beispiele belegte Reinhard Wobst, wie schnell es geschehen kann, dass ein Softwareentwickler Gutes wollend das Falsche tut bzw. das Richtige nicht richtig macht. Und er zeigte auch die Grenzen auf, die selbst einer perfekt implementierten Kryptologie gesetzt sind, wie denial of service Attacken oder der immer erfolgversprechende Versuch, das stets schwächste Element eines Walls von Maßnahmen für die Sicherheit zu instrumentalisieren: den User selbst.

So kam Wobst bei seinem Vortrag zu der Schlussformel, dass gesunder Menschenverstand niemals hinter Formalismen verschwinden darf. Für die Realisierung von Sicherheit gilt immer, dass etwas Sicherheit besser ist als gar keine.

Qualität und höchstmögliche Security für Embedded-Software

Wie real die Risiken von Angriffen auf Embedded-Systeme sind, zeigte Lucas von Stockhausen von Hewlett-Packard in seinem Vortrag "Mehr Sicherheit für Embedded Code" am Beispiel einer Manipulation einer handelsüblichen Insulinpumpe. Es sei möglich, durch Umgehen von Restriktionen die Insulindosis, die eine solche Pumpe automatisch verabreicht, aus einer Entfernung von 100 m und völlig unbemerkt zu verändern. Damit könne man einem Diabetiker jederzeit eine Überdosis Insulin injizieren.

Diese Gefahr mag konstruiert erscheinen, für den Pumpenhersteller und für den Patienten ist sie aber sehr real und höchst bedrohlich. Das Bundesministerium für Wirtschaft und Technologie stellte bereits 2010 eine zunehmende und alarmierende Professionalisierung von Angriffen fest. Dabei berichten die Medien meist nur über die spektakulärsten Fälle, wie zum Beispiel den bereits erwähnten Stuxnet-Wurm, der für den Einsatz auf industrielle Ziele optimiert wurde.

Die psychologischen Sicherheitslücken

Viele Angriffe sind weniger spektakulär, doch kaum weniger gefahrenvoll. Gerade überraschende Angriffsszenarien auf Embedded-Systeme zeigen, wie schwierig es sein kann, schon in der Softwareentwicklung vorauszusehen, wie ein späterer Angriff aussehen kann. Aus diesem Grund spielt die sichere Softwareentwicklung, der sichere Code, eine entscheidende Rolle. Angesichts des rasanten Fortschritts, der von zunehmendem Zeit-, Konkurrenz- und Erfolgsdruck zuverlässig begleitet wird, muss neben Qualitätsforderungen auch das höchstmögliche Sicherheitsniveau realisiert werden.

Bei Embedded-Software erfolgt eine verbesserte Zugangssicherheit über Software-Updates, sagte Prof. Dr.-Ing. Hans-Joachim Hof. Daraus ergeben sich gleichermaßen Aufgaben für die Entwicklung von Soft- und Hardware. In puncto Hardware werden sichere Interfaces und Übertragungsprozeduren benötigt. Die Software muss so aufgebaut sein, dass sie autorisiert korrigiert, aber nicht ohne Autorisierung manipuliert werden kann. Das Motto "Verbauen und Vergessen" gehört damit der Vergangenheit an.

Nicht zu vergessen sind die psychologisch bedingten Sicherheitslücken, zu denen Peter Siwon von MicroConsult in seinem Seminar „Irren ist menschlich“ Beispiele nannte. Und das sowohl auf Entwickler- wie auf Anwenderseite.

Unter hohem Zeitdruck neigt man dazu, Sicherheitsregeln zu brechen. Menschen nehmen dann höhere Risiken in Kauf, um den Stress loszuwerden. Stresshormone schränken unsere Fähigkeit ein, über die langfristigen Folgen unseres Verhaltens nachzudenken. Zudem leide unser Qualitätsbewusstsein unter dem Bedürfnis, den „Schmerz“ loszuwerden. Beides zusammen stellt eine explosive psychologische Mischung dar.

Wichtige Voraussetzungen für Security, wie beispielsweise umfassende Tests, fallen unter den Tisch. Eine weitere Sicherheitslücke entsteht durch Denkfaulheit. Um unser Gedächtnis zu entlasten, greifen wir nicht nur bei Passwörtern auf altgewohnte oder bequeme Denk- und Verhaltensmuster zurück.

Wunder Punkt Software Security: Horrorszenarien sind nicht Stoff für Hollywood

Thomas Batt, beim Training- und Consultingspezialisten MicroConsult zuständig für Software Engineering Management, zieht folgendes Resümee: „(Horror-)Szenarien, bei denen Embedded-Systeme durch äußere Angriffe manipuliert werden oder bei denen sogar die komplette Kontrolle übernommen wird, sind keine Hollywoodphantasien. Wir sind heute von einer rasant wachsenden Zahl von Embedded-Systemen umgeben und verlassen uns darauf, dass Herstellerfirmen sie zugangs- und angriffssicher entwickeln, testen und produzieren.

Doch Tatsache ist, dass für den größten Teil des Embedded-Marktes die Qualitätsmerkmale Zugangs- und Angriffssicherheit noch Neuland sind. Diese Qualitätsmerkmale müssen sich künftig wie ein roter Faden durch den gesamten Entwicklungs- und Produktionsprozess der Produkte ziehen. Dazu benötigen wir geeignete Methoden - insbesondere für den Test - sowie unterstützende Tools, Standards und Zertifizierungen. Doch selbst mit noch so hochentwickelten Maßnahmen können wir die Risiken nur minimieren, nicht aber völlig ausschließen.“

Quellennachweis:

[1] B. Schneier, Memo to the Amateur Cipher Designer

* Peter Siwon ist Business Development Manager beim Schulungs- und Consulting-Spezialist MicroConsult in München und Alexander Sedlak ist als freier Autor tätig.

(ID:33431560)