Security By Obscurity (Sicherheit durch Verdunklung oder Geheimhaltung)
Security by obscurity, oder auch Security through obscurity — da rümpft der Sicherheitsexperte die Nase. Dass man Sicherheitskonzepte geheim halten sollte, diese Ansicht ist eindeutig überholt – soll ich sagen seit vielen Jahrzehnten? Konsens unter Sicherheitskennern ist eher das Gegenteil — Security by obscurity ist eine Gefahr (siehe auch Wikipedia).
Aber was ist wirklich davon zu halten, wenn mir das Bundesamt für Sicherheit in der Informationstechnik (BSI) in meiner Anfrage Verschlüsselung im BSI Grundschutz? antwortet, „...wenn das Bekanntwerden der Information die öffentliche Sicherheit gefährden kann“. Nun das ist in meinen Augen Unsinn, zumindest wenn angemessene Sicherheitskonzepte umgesetzt wurden. Nur wenn die Sicherheitskonzepte löchrig sind, macht Geheimhaltung einen Sinn — oder auch nicht. Denn wie sagte schon Hobbs 1851 (Hobbs) — die Einbrecher wissen sowieso mehr als wir. Wenn nur die Einsicht beim BSI (Allianz) reifen würde, immerhin, die Kollegen vom NIST (AES, NIST) sind da weiter.
An einigen Stellen muss man auch klar sehen: manches war gar nicht geheim, weder die Enigma (Winterbotham, Schulz) noch Heartbleed (CII) oder andere Probleme von Transport Layer Security (TLS). Es reicht nicht, nur zu veröffentlichen, man muss den Review auch organisieren — das ist das Ziel von CII und Google.
Hier was ich an Quellen bisher gefunden habe:
| Jahr | Person(en) | Quelle(n) | Referenzen | Zitate / Kommentare | |
|---|---|---|---|---|---|
| #1 | 1851 | Alfred Charles Hobbs | Locks and Safes | early opponent of security through obscurity was the locksmith Alfred Charles Hobbs, who in 1851 demonstrated to the public how state-of-the-art locks could be picked. In response to concerns that exposing security flaws in the design of locks could make them more vulnerable to criminals, he said: “Rogues are very keen in their profession, and know already much more than we can teach them.” | |
| #2 | 1864 | Charles Babbage | Passages from the Life of a Philosopher | “One of the most singular characteristics of the art of deciphering is the strong conviction possessed by every person, even moderately acquainted with it, that he is able to construct a cipher which nobody else can decipher.” | |
| #3 | 1883 | Auguste Kerckhoffs | La cryptographie militaire, Wikipedia: Kerckhoffs´ Prinzip | “The system must not require secrecy and can be stolen by the enemy without causing trouble” „Es darf nicht der Geheimhaltung bedürfen und soll ohne Schaden in Feindeshand fallen können.“ | |
| #4 | 1949 | Claude Shannon | Communication Theory of Secrecy Systems | (Kerckhoffs) | “To make the problem mathematically tractable we shall assume that the enemy knows the system being used.” (aka Shannon´s Maxim) |
| #5 | 1964 | Paul Barn | On Distributed Communications: IX Security, Secrecy, and tamper-free considerations | Shannon | “As a prelude to the proposal, however, the view is expressed that if one cannot safely describe a proposed system in the unclassified literature, then by definition it is not sufficiently secure to be used with confidence. A totally secure system design requires a full understanding of the problem by everyone involved with every part of the system--even those who would not normally hold any security clearance.”“The Paradox of Secrecy about Secrecy” |
| #6 | 1971 | Frederick William Winterbotham | The Ultra Secret | siehe Wikipedia: Ultra Secret, Schulz und Grathwohl | |
| #7 | 1975 | Jerome H. Saltzer, Michael Schroeder | Basic Principles of Information Protection, The Protection of Information in Computer Systems | Barn | “Open design: The design should not be secret. The mechanisms should not depend on the ignorance of potential attackers, but rather on the possession of specific, more easily protected, keys or passwords. This decoupling of protection mechanisms from protection keys permits the mechanisms to be examined by many reviewers without concern that the review may itself compromise the safeguards. In addition, any skeptical user may be allowed to convince himself that the system he is about to use is adequate for his purpose. Finally, it is simply not realistic to attempt to maintain secrecy for any system which receives wide distribution.”“We should note that the principle of open design is not universally accepted, especially by those accustomed to dealing with military security. The notion that the mechanism not depend on ignorance is generally accepted, but some would argue that its design should remain secret. The reason is that a secret design may have the additional advantage of significantly raising the price of penetration, especially the risk of detection.” |
| #8 | 1997 | National Institute of Standards and Technology (NIST) | Announcing Development of a Federal Information Processing Standard for Advanced Encryption Standard | It is intended that the AES will specify an unclassified, publicly disclosed encryption algorithm capable of protecting sensitive government information well into the next century. Gute Zusammenfassung in Advanced Encryption Standard Process der englischen Wikipedia | |
| #9 | 1998, 2011 | Bruce Schneier | Schneier´s Law | Babbage | “Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can´t break.” “If I have any contribution to this, it´s to generalize it to security systems and not just to cryptographic algorithms.” (2011) |
| #10 | 1999 | Eric S. Raymond | Linus´s Law in “The Cathedral and the Bazaar” | “given enough eyeballs, all bugs are shallow” | |
| #11 | 2000 | Bruce Schneier | Secrets and Lies | Kerckhoffs | “Kerckhoffs´ principle applies beyond codes and ciphers to security systems in general: every secret creates a potentialfailure point. Secrecy, in other words, is a prime cause of brittleness — and therefore something likely to make a system prone to catastrophic collapse. Conversely, openness provides ductility.” (Zitat in Herrero) |
| #12 | 2000 | Bruce Schneier | AES Announced | (AES) | “... I have nothing but good things to say about NIST and the AES process. ... I think NIST did an outstanding job refereeing. They were honest, open, and fair.” |
| #13 | 2002 | Matt Curtin | Developing Trust: Online Privacy and Security | Dieses Buch kenne ich noch nicht, es wird von NIST referenziert. | |
| #14 | 2003 | Matt Bishop | Computer security: Art and science | “Designers and implementers of a program must not depend on secrecy of the details of their design and implementation to ensure security.” | |
| #15 | 2003 | Rebecca T. Mercuri, Peter G. Neumann | Security By Obscurity | “The following scenarios illustrate the limitations of the myth of security by obscurity.” | |
| #16 | 2004 | Englische Wikipedia | Linear-feedback shift register | Aus eigener Beteiligung: während meines Studiums (um 1986/87 bei Professor Thomas Beth) waren Linear-feedback shift register (LFSR) modern, gewissermaßen als Ersatz für ein wirklich sicheres One-time pad — LFSR gelten inzwischen aber als unsicher – seit wann genau weiß ich nicht. | |
| #17 | 2004 | André Schulz | Alan Turing | (Winterbotham) | „... da die Codebreakers in Bletchley wussten, wie die Verschlüsselung funktioniert, waren sie bald in der Lage, den deutschen Funkverkehr komplett mitzuhören.“ (siehe auch Grathwohl) |
| #18 | 2006 | OWASP | Security by Design Principles | “Avoid security by obscurity: Security through obscurity is a weak security control, and nearly always fails when it is the only control. This is not to say that keeping secrets is a bad idea, it simply means that the security of key systems should not be reliant upon keeping details hidden.” Siehe auch Kommentar zu Patel – Miessler. | |
| #19 | 2008 | Karen Scarfone, Wayne Jansen, Miles Tracy, National Institute of Standards and Technology (NIST) | Guide to General Server Security | Saltzer, Curtin | “Open Design — System security should not depend on the secrecy of the implementation or its components.” |
| #20 | 2009 | Javier Galbally Herrero | Vulnerabilities and Attack Protection in Security Systems Based on Biometric Recognition | Kerckhoffs, SchneierSecretsLies | “That does not mean that obscurity cannot provide any protection, rather that the protection is unpredictable (you cannot guarantee that an attacker will not find out your secrets) and most probably temporary.” |
| #21 | 2009 | Deutsche Wikipedia | Security through obscurity | NIST, Herrero | „Auf diese Weise führt security by obscurity zu einem Verlust von Sicherheit, da bei diesem Prinzip die vermeintlichen Sicherheitsmethoden nicht auf ihre Wirksamkeit überprüft und die unwirksamen Methoden nicht frühzeitig als solche verworfen werden können.“ |
| #22 | 2014 | Core Infrastructure Initiative | Heartbleed Bug | LinusLaw | “The vulnerability, which had been shipped in OpenSSL's current version for more than two years, made it possible for hackers to retrieve information such as usernames, passwords and credit card numbers from supposedly secure transactions.” |
| #23 | 2015 | Y. Sheffer Porticor, R. Holz, P. Saint-Andre | Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) | Dass öffentlicher Review die Sicherheit verbessert kann man an der Entwicklung von Transport Layer Security (TLS) ablesen. Die aktuelle siebte Version ist nach heutigem Stand der Erkenntnisse sicher, die sechste noch brauchbar, alle davor sind unsicher und sollen – auch nach Ansicht des BSIs – nicht mehr eingesetzt werden. Und manchmal muss nicht nur das Konzept sondern auch die Implementierung kritisch beleuchtet werden, wie Heartbleed (CII) zeigt. | |
| #24 | 2016 | Mark S. Merkow, Jim Breithaupt | Information Security: Principles and Practices, 2nd Edition | (Hobbs, LinusLaw, NIST) | “Principle 6: Security Through Obscurity Is Not an Answer” “If the security of a system is maintained by keeping the implementation of the system a secret, the entire system collapses when the first person discovers how the security mechanism works — and someone is always determined to discover these secrets. ” |
| #25 | 2018 | Bundesamt für Sicherheit in der Informationstechnik (BSI) | Handhabung von Schwachstellen (BSI-CS 019) | „Viele Unternehmen verfolgen bei der Information über Schwachstellen häufig das Prinzip Security by Obscurity, d. h. es werden keine oder nur unzureichende Informationen über mitunter gravierende Schwachstellen veröffentlicht. Jedoch kann gerade diese Denkweise dazu führen, dass Angreifer solche Schwachstellen ausnutzen, wenn sie bereits durch eigene Erkenntnisse oder den Zukauf aus entsprechenden Quellen bekannt sind.“ Scheint leider noch kein Allgemeinwissen beim BSI zu sein. Vielleicht weil der Grundschutz an sich zu viele Schwachstellen ermöglicht? | |
| #26 | 2018 | Bruce Schneier | Click Here To Kill Everybody | CII | “In response to Heartbleed, industry created something called the Core Infrastructure Initiative... but it´s not enough.” (p. 115) “We need to change the incentives so that companies are forced to care about the security implications of their products.” (p. 126) “Reducing the amount of secrecy in government cybersecurity will go a long way to making information sharing easier, as will providing some assurances of confidentiality, and perhaps indemnification, to companies that share information.” (p. 177) “... the companies you entrust with your data and capabilities will never fully support keeping you secure. They will make design decisions that weaken your security against both criminals and governments.” (p. 209) (Seitenzahlen der Taschenbuchausgabe) |
| #27 | 2021 | Johann Grathwohl | Mythos ENIGMA in "Irren ist kryptografisch" (KA-IT-Si-Event) | Winterbotham, SchneierLaw, (Schulz) | „... in Folge des Bekanntwerdens der Entschlüsselung der Zimmermann Depesche...“ (Teil 1, um 26:15) „Bis in die 70er wurde in der Öffentlichkeit – und nicht nur da – angenommen, dass die Verschlüsselungsmaschine ENIGMA nicht knackbar ist. Allerdings war dies ein Irrtum. Die ENIGMA wurde bereits in den 30er Jahren erfolgreich analysiert und (man) hat während des zweiten Weltkriegs systematisch Nachrichten entschlüsselt.“ (Untertitel Teil 2) „Takeaways: Die falsche Anwendung kann Krypto-Verfahren erheblich Schwächen. ... Frage jemand, der sich damit auskennt“ (Teil 2, um 32:30) |
| #28 | 2021 | Maika Möbus, Heise Verlag | Belohnungsprogramm: Eine Million Dollar für Sicherheit in Open-Source-Projekten | „Google hat bekannt gegeben, Secure Open Source Rewards(SOS) mit einer Million US-Dollar zu sponsern. Das Pilotprogramm der Linux Foundation soll zur Erhöhung der Sicherheit in kritischen Open-Source-Projekten beitragen.“ | |
| (Scheinbare) Gegenstimmen | |||||
| #29 | 2006 | Ross Patel, Afentis | Security Through Obscurity | Kerckhoffs, Shannon | In Patel – Miessler werden meiner Meinung nach Begriffe durcheinandergebracht. Die Konzepte Tarnung oder Ablenkungsmanöver sind öffentlich bekannt. In welchem Helikopter der Präsident sitzt, das ist wie ein Schlüssel geheim – aber vor einem Brute-Force-Angriff schützt das nicht, dafür sind es zu wenige Helikopter. Der geänderte Port bei ssh oder anderen Protokollen schützt auch nicht vor einem echten Angreifer, aber Scriptkiddies werden effektiv gebremst. Mit den richtigen Begriffen sind das also keine Gegenstimmen sondern allenfalls unsaubere Begriffe. Und richtig ist, dass diese Konzepte allenfalls als Defense-In-Depth akzeptabel sind und damit vor einem Insider gar nicht schützen. Sinnvoll ist es, das Konzept im Sicherheitskonzept zu dokumentieren, die eigentliche Konfiguration davon getrennt abzulegen – auch das bei Secrets eigentlich eine Selbstverständlichkeit. Idealerweise verwendet man dafür ein Konfigurationsmanagement-Tool — dann kann man kontrollieren wer darauf Zugriff hat und es ggfs. auch leicht ändern. |
| #30 | 2015 | Aaron D. Campbell | Security vs Security Through Obscurity | Hobbs, LinusLaw, NIST | |
| #31 | 2020 | Esteban Borges, SecurityTrails | Security Through Obscurity | ||
| #32 | 2020 | Lifars | Security Through Obscurity | MercuriNeumann | |
| #33 | 2021 | Daniel Miessler | Secrecy (Obscurity) is a Valid Security Layer | (Shannon) | |
Weitere Einträge kann ich gern aufnehmen. Eine Email genügt.
Published on 09/28/2021, last updated on 10/15/2021.
© 2021 Joachim Lindenberg. This page reflects my personal opinion and does not provide legal advice.