After the videos on threat modeling an example seems in order. Securology provides us with a good one in Selecting a Pistol Safe as (part of) the basis of a procurement decision. This is his set of requirements:

So, I needed a way to “securely” (that’s always a nebulous word) store a firearm– namely a pistol– such that it could meet the following criteria:

1. Keep children’s and other family members’ hands off of the firearm
2. Stored in, on, or near a nightstand
3. Easily opened by authorized people under stress
4. Easily opened by authorized people in the dark
5. Not susceptible to power failures
6. Not susceptible to being “dropped open”
7. Not susceptible to being pried open
8. Not opened by “something you have” (authentication with a key) because the spouse is horrible at leaving keys everywhere.
9. For sale at a reasonable cost
10. An adversary should not know (hear) when the safe was opened by an authorized person

But I didn’t care a lot about the ability to keep a dedicated thief from stealing the entire safe with or without the firearm inside.

Read on at Securology to see how various products fail to fulfill this set of requirements. This example is illustrative in that it addresses several distinct threat aspects and tradeoffs. The pistol is not simply an asset needing protection, it is also by itself a security mechanism against certain threats. The resulting optimization problem is pretty interesting: keeping (some) unauthorized people from accessing the pistol while maintaining availability to the authorized in a practical sense.

Jon Ronson has found a way of writing a commedy about torture and warfare. Best thing about it – many of the ideas behind it like many of the non-lethal weapons are real. Funny, isn’t it? Here some of the ideas.

Subliminal Sound Weapon

LED-Flashlight

Dangerous Microwaves

Grotesque Weaponry

The Hippies behind it

Sicherheitshinweise verlangen oft umständliche und aufwändige Verhaltensweisen, die im Alltag stören. Unser Tipp: Befolgen Sie die Regeln nur jedes zweite Mal. So können Sie Usability und Sicherheit vereinen. Sie bekommen von jedem ein bisschen.

Kann mir jemand sagen, ob ich das möchte? Oder weiß wenigstens jemand, unter welchen Umständen so eine Meldung typischerweise zustandekommt? Der Text klingt ein wenig schräg, und der Hilfe-Button ist nur Dekoration.

Neue Regeln für Radfahrer, dabei hat doch eine neue Studie gerade enthüllt, dass sich die Radfahrer noch nicht mal an die alten halten und Regelverstöße absichtlich begehen. Vielleicht hat man deshalb jetzt die Regeln auch eher gelockert. Das nennt man dann bedarfsgerechte Gesetzgebung.

Yesterday I visited the CAST-Workshop on mobile security for intelligent cars, which ended with a very interesting discussion that illustrated the complexity of the problem and raised many interesting questions. First the speakers gave a good overview over the main research areas and important projects like Evita or SIM-TD, which is said to be the biggest field test world wide, that focusses on car-2-x-communication. Everybody agreed on the main distinctions (Safety vs. Security; in-car communication, car2car communication, etc.) and privacy issues were the main topic. As Frank Kargl  from the University of Ulm pointed out, the car has a strong connection to its owner and its movements might tell a lot about the individual. Already privacy concerns have entered the car world, because navigation tools send home gps information and companies like Tom Tom generate a large data collection.

Everybody agreed that privacy may be paramount for user acceptance at least in Europe and that safety is an important topic. Marc Menzel from Continental pointed out that car2car-communication will only be effective if the majority of cars is equipped with on board units. This however may take ten years or more. Therefore mobility functions and car2infrastructure communication will probably be the first signs of future eSafety.  As an example Menzel named basic services as the identification of road and traffic conditions, in order to tackle route congestion and event related road dangers.  Economic factors will also be of importance. Of course there are ideas of identifying the cars with help of PKI, but any certification will cost money and how much will a car owner be willing to pay?

This question triggered a lifely discussion about what degree of security is needed and it became apparent that there is no consensus regarding key applications and their main use cases and therefore no least common denominator.  Menzel pointed out that IT security has to consider the complete car system, i. e. include other technologies and procedures into its scenarios. If for example a hacker would impersonate an ambulance one would not have to use IT means to identify the driver – the license plate filmed by a video camera would do. On the other hand Marko Wolf from Escrypt made clear that the possibilities of a car attacker go beyond those of a normal IT hacker, because the first can launch an attack from the inside, offline and even has physical possesion of the target. In contrast an attacker, who tries to overtake a server does not have these opportunities.

During a coffee break a colleague point out that the car industry should learn from the internet and just establish basic means for communication (protocols & on board units) and leave the rest to developers. I don’t agree because using a car is much more dangerous than using your pc. I might trust my browser blocking some new window but not my car deciding which way to go – at least not yet. Still it is an interesting thought, like the use of open-source code for in vehicle communication, because this might change the value chain of the car world, not to mention the life-cycle. Can you imagine a patch tuesday for your car? What went absolutely unnoticed was the psychology of the driver: I just can’t imagine how my father will respond to an intelligent car. To condition the user might take some years. But even if the system is accepted easily, there may be a falls alarm and what if somebody dies because the driver followed the system’s instruction? A lot of security questions, but the reality does not need to answer them all at once. The combustion engine was invented in the 19th century, the safetybelt followed 100 years later.

Links

www.car-2-car.org

www.comesafety.org

www.evita-project.org

www.preciosa-project.org

www.sevecom.org

www.simtd.de

Warum viele auf Identitätsmanagement abfahren und sich davon einen Sicherheitsgewinn erhoffen, habe ich mich schon früher gefragt. Ein Teilproblem dabei: was ist eigentlich die Identität einer Firma oder Organisation? Warum das ein Problem ist, illustrieren jetzt ausgerechnet Verbraucherschützer, die uns beim Schutz vor Phishing helfen möchten. Sie geben die üblichen Tipps – und illustrieren ihre Erklärung über SSL ausgerechnet mit einer URL-Zeile der Dresdner Bank:

Die ist seit kurzem eine Marke der Commerzbank, und das zeigt der Browser auch an. Formal ist das völlig korrekt, aber dem Bankkunden hilft diese zertifizierte Identitätsinformation nur bedingt weiter. Oder gelten SSL-Zertifikate nur in Verbindung mit Nachrichten aus dem Wirtschaftsteil?

Übrigens muss der arme Nutzer nicht nur zwischen Unternehmen und Marken unterscheiden, sondern auch zwischen echten und weniger echten Warnungen. Wer bei der Adresseingabe das Präfix www vergisst, dem macht die Technik unnötig Angst:

Auch dies ist formal völlig korrekt, hilft dem Nutzer aber nicht weiter. Er kann aus solchen Beobachtungen kein einfaches, konsistentes Sicherheitsmodell entwickeln. Verbraucherportale mit wohlmeinenden Tipps ändern daran nichts und lösen deshalb auch das Problem nicht.

… Sie haben einen einfachen Phishing-Filter sehr glücklich gemacht.

Über die Tipps des Auswärtigen Amtes zur Redution des persönlichen Terrorrisikos wollte ich mich auch noch lustig machen. Muss ich aber nicht, denn Burkhard Müller-Ullrich hat über diese CYA-Aktion bereits alles gesagt:

»Nochmal zum Mitschreiben: Das Außenministerium rät Mallorca-Urlaubern, Menschenansammlungen zu meiden. Man fragt sich, ob der Verfasser dieses Ratschlags schon mal auf Mallorca war und was er sonst noch von der Welt weiß.«

(Die Achse des Guten: Menschenmassen meiden!)

Tatsächlich geht es wohl gar nicht gar nicht darum, brauchbare Sicherheitshinweise zu geben. Das wäre weder nötig noch praktikabel, denn das persönliche Risiko ist auch nach den Knallfröschen vom Wochenende gering und jede weitere Reduktion mit übergroßen Kosten verbunden. Aber ein zuständiges Amt traut sich nur selten, einfach mit den Schultern zu zucken und unvermeidliche Risiken auf sich beruhen zu lassen. Irgendetwas muss man vorher tun, damit einem später keiner vorwerfen kann, man habe nichts getan. Risikointuition nennen wir das, und sie ergibt sich stets aus der persönlichen Perspektive des Handelnden. Wobei der Begriff Intuition vielleicht falsch ist, denn der Kern des Problems ist nicht die intuitive Bewertung des Risikos, sondern dessen Betrachtung aus der individuellen Perspektive.

(direct, via)

Sock security has been troubling me for a long time. Endless sundays I have spent with the fight against the single sock syndrom. But those days are over. Thanks to a colleague I have discovered sockstar, the revolutionary tool to improve the lower department of your wardrobe-BCM – a simple thing that just does what it should, if you manage to integrate it into your business processes… [end of commercial] http://www.sockstar.de/

Dieser Tipp ist nicht neu, aber mein Leidensdruck war nicht so groß, dass ich aktiv danach gesucht hätte. Das Verhalten von Firefox bei formal ungültigen SSL-Zertifikaten lässt sich etwas weniger nervig gestalten:

• about:config aufrufen
• browser.xul.error_pages.expert_bad_cert auf true setzen
• browser.ssl_override_behavior auf 2 setzen

(gefunden hier, Erklärung da).

Damit spart man sich ein paar unnötige Mausklicks.

Google schlägt seinen Benutzern gleich beim Eintippen populäre Suchbegriffe vor:

Aber nicht für alle Eingaben:

An fehlenden Daten dürfte das kaum liegen.

Microsoft hat den .NET Messenger für Nutzer in Kuba, Syrien, Iran, Sudan und Nordkorea gesperrt. Diese Länder unterliegen einem Embargo der Vereinigten Staaten; US-Firmen dürfen mit ihnen keine Geschäfte machen. Manche finden das hirnrissig (das ist es auch, aber es ist Gesetz), während andere die Umsetzung für hirnrissig halten. Microsoft benutzt nämlich einfach die im Profil hinterlegte Landeseinstellung des Nutzers, und die ist frei wählbar.

Diese Implementierung ist aber nicht hirnrissig, sondern vollständig rational und typisch für Compliance-Probleme. Security dreht sich um die Lösung eigener Probleme, die Durchsetzung eigener Interessen mit technischen und organisatorischen Mitteln. Diese Mittel sollen – im Rahmen des jeweils vertretbaren Aufwandes – effektiv sein, also böswillige Angriffe tatsächlich abwehren. Dabei besteht ein direkter Zusammenhang zwischen den erwarteten Schäden durch Angriffe und dem vertretbaren Aufwand.

Compliance hingegen erfordert die Wahrung fremder Interessen, auferlegter Regeln und Anforderungen. Zu eigenen Interessen eines Unternehmens werden sie erst aufgrund angedrohter Zwangsmaßnahmen. Effektivität ist auch hier das Ziel, aber maßgeblich sind nun nicht mehr die direkten Auswirkungen, sondern die angedrohten. Die sind willkürlich festgelegt.

Ein Unternehmen, das Compliance erzielen möchte beziehungsweise muss, wird deshalb jeweils zum einfachsten und billigsten Mittel greifen, das die angedrohten Zwangsmaßnahmen genügend zuverlässig abwehrt. Dieses Mittel muss keinen realen Effekt haben. Es muss lediglich die Kontrolleure zufriedenstellen. Die Lösung von Microsoft für das Compliance-Problem des Messengers leistet dies vermutlich.

Das tatsächliche Problem ist damit vorerst gelöst. Ob Kubaner, Sudanesen oder Nordkoreaner mit dem .NET Messenger chatten, ist dagegen nur ein Scheinproblem. Ohne Compliance-Zwänge wäre es Microsoft einfach egal. Aus geschäftlicher Sicht gäbe es keinen Grund darüber auch nur nachzudenken.

(direct scam)

Kryptologie-Nerds mit ausgeprägter Paranoia dürfte die Lösung nicht überzeugen, weil sie grundsätzlich niemandem trauen und jeder hinter ihnen her ist, aber die Idee ist trotzdem gut:

»Die PrivacyBox soll es in erster Linie Journalisten, Bloggern und anderen Publizierenden ermöglichen, eine vorratsdatenfreie (und auch anonyme) Kontaktmöglichkeit für Informanten anzubieten. Sie steht aber auch weiteren Interessierten offen.«

Die PrivacyBox stellt als Grundfunktion gerichtete anonyme Kommunikation über ein Web-Interface zur Verfügung. Der Empfänger ist nur durch ein Pseudonym gekennzeichnet, der Sender liefert seine Nachricht über ein Web-Formular ab. Krypto-Voodoo mit TOR und PGP ist optional möglich, wird aber nicht erzwungen. Das ist Sicherheit für normale Menschen. Wir brauchen mehr davon.

(vgl. auch: Yes)

Ein Nachtrag zu meinem Passwort-Post neulich:

Im aktuellen Risks Digest 25:60 findet sich ein Hinweis auf ein Paper mit dem Titel Do Strong Web Passwords Accomplish Anything? das ähnlich argumentiert und außerdem die unterschiedlichen Perspektiven einzelner Nutzer und einer ganzen Organisation betrachtet. Die Autoren weisen am Ende aber auch darauf hin, dass ihr Paper nicht dazu gedacht ist, Verhaltensregeln für Benutzer abzuleiten.

Don’t Click: http://tinyurl.com/af3t4n

Remote Deposit Capture

Wohlmeinende Sicherheitshinweise finden wir allerorten. Oft sind sie  nur deshalb entstanden, weil jemand gezwungen war, sich zum Thema zu äußern. Wozu das führt, wissen wir seit Harry G. Frankfurt sehr gut und offensichtlich wird es, wenn sich die Hinweise direkt widersprechen.

Kinder sollten Internetseiten niemals direkt ansurfen, indem sie die Adresse in den Browser eingeben, lernen wir heute. Fein, aber wenn sie dann erwachsen sind, dann sollen sie die URL fürs Online-Banking immer direkt eingeben. Und nun? [Oliver, Du hast doch Kinder. Wie würdest Du ihnen das erklären? ]

Sicherheitshinweise können zu sinnvollem Verhalten auffordern oder von weniger sinnvollem abraten: »Legen Sie im Auto den Sicherheitsgurt an!« oder: »Versuchen Sie nie, schlauer zu sein als die Bahnschranke!« Dagegen ist nichts zu sagen,außer dass man die Wirkung nicht überschätzen sollte. Sicherheitshinweise werden nicht nur nicht gelesen, sie setzen auch an der falschen Stelle an. Sicherheitshinweise vermitteln Wissen, aber keine Fähigkeiten, Regeln oder Gewohnheiten und sind deshalb ungefähr so wirksam wie das Lesen eines Kochrezeptes gegen den Hunger.

Darüber hinaus können Sicherheitstipps auch eine Ausrede sein, eine Ausrede dafür, dass man dem Benutzer willkürlich Aufgaben zuweist. Das machen wir in der IT-Sicherheit gerne, wenn wir am Ende unserer Weisheit angelangt sind oder die Lehrbuchwelt von Alice und Bob mit der Realität verwechseln. Dann verfügen wir schon mal, der Benutzer unseres Systems habe auf kleine gelbe Schlösser zu achten und aus eigenem Antrieb SSL-Zertifikate zu prüfen, obwohl ihm das Arbeit macht und für den Erfolg seiner Interaktion mit dem System völlig bedeutungslos ist.

Kaum etwas aus der IT-Sicherheit hat sich so weit verbreitet wie die Regeln für die sichere Passwortwahl. Das ist gut, obwohl es viele nicht davon abhält, trotzdem ein leicht erratenes Trivialpasswort zu verwenden. Einige Details allerdings sind dabei auf der Strecke geblieben, was zuweilen zu Verwirrung führt. Zwei typische Missverständnisse:

1. Man kann die Sicherheit eines Passworts messen.
2. Lang ist immer gut, kurz ist immer schlecht.

Das erste Missverständnis geht wohl darauf zurück, dass man nicht klar zwischen dem Prozess der Passwortwahl und dem Passwort als Ergebnis unterscheidet. Ein Passwort ist in erster Linie ein Geheimnis. Als solches muss es zunächst gar keine besonderen Anforderungen erfüllen, sondern nur eben geheim bleiben. Diese Anforderung erfüllt auch die Zeichenfolge Passwort. Da es um Security geht, haben wir aber einen intelligenten Gegner, den wir auch Angreifer nennen. Der wird alles versuchen, was ihm praktisch möglich ist und was unsere Sicherheitsmechanismen nicht verhindern.

Nicht hindern können wir den daran, dass er einfach versucht, unser Passwort zu erraten. Wir können aber versuchen, seine Erfolgswahrscheinlichkeit mit dieser Methode klein zu halten. Dazu wählen wir das Passwort am besten völlig zufällig. Jede andere Wahlmethode führt nämlich dazu, dass der Angreifer seine Ratemethode optimieren und seine Erfolgswahrscheinlichkeit erhöhen kann.

Das ist jedoch nur die halbe Wahrheit. Da viele Menschen ihr Passwort eben nicht zufällig wählen, kann ein Angreifer, der es nicht speziell auf uns abgesehen hat, seine Methode unabhängig von unserem Verhalten optimieren. Dazu bildet er in seiner Ratemethode einfach das typische Verhalten vieler Nutzer nach. Das hilft ihm nicht überall, aber da die Trivialpasswortnutzer häufig vorkommen, fährt er damit im Mittel besser als beim zufälligen Raten. Unser Angreifer wird also zuerst die häufigsten Passworte durchprobieren, etwa Passwort, geheim und alle kurzen Zeichenfolgen, danach andere Wörter aus den Wörterbüchern natürlicher Sprachen (zum Beispiel Reihenhaus, Pusteblume oder Pippi Langstrumpf) sowie naheliegende Modifikationen davon (zum Beispiel Reihenhau$, Pusteblume43). Der Rest wird dann zufällig abgearbeitet.

Unser Passwort sollte also zufällig gewählt sein, aber nicht zu denjenigen gehören, die der Angreifer vermutlich zuerst ausprobiert. Das ist mit einem sicheren Passwort gemeint.

Und die Länge? Die Länge bestimmt, wieviele Versuche der Angreifer unternehmen muss, um unser Passwort auf jeden Fall herauszubekommen. Um etwa eine einzelne Ziffer (0…9) zu erraten, sind höchstens zehn Versuche nötig, im Mittel die Hälfte davon. Bei vier  Ziffern sind es schon 10.000 mögliche Folgen. Wie lang das Passwort wirklich sein muss, hängt von mehreren Faktoren ab: vom Zeitaufwand ro Versuch zum Beispiel sowie davon, ob dem Angreifer ein Hashwert des Passworts zur Verfügung steht.

Um ein Passwort zu erraten, muss der Angreifer irgendwie prüfen können, ob er das richtige erwischt hat. Das geht entweder am System (Online-Angriff) oder eben mit dem Hashwert (offline), wenn er ihn kennt. Der Hashwert ist das, was man normalerweise von einem Passwort speichert. Daraus lässt sich das Passwort nicht berechnen, aber man kann umgekehrt den Hashwert eines eingegebenen Passwortes berechnen und mit dem gespeicherten vergleichen.

Offline mit dem Hashwert kann der Angreifer beliebig viele Versuche machen. Lediglich die benötigte Zeit setzt ein effektives Limit. Die Zeit hängt von der Anzahl der nötigen Versuche ab und die wiederum von der Zahl der möglichen Passworte, also derLänge.

Weit effektiver lässt sich die Zahl der Versuche im Online-Angriff beschränken, denn dabei muss der Angreifer mit dem System interagieren. Das System kann also die Fehlversuche zählen und zum Beispiel nach dem dritten den Zugang sperren, so dass man selbst mit dem richtigen Passwort nicht  mehr reinkommt. Wenn man sich sicher sein kann, dass der Angreifer keine Hashwerte für Offline-Angriffe in die Finger bekommt, dann muss man sich nur um diese drei Versuche kümmern. Das Passwort muss dann nur so lang sein, dass es in drei Versuchen nur mit geringer Wahrscheinlichkeit zu erraten ist.

Dafür kann eine vierstellige PIN wie am Geldautomaten oder ein fünfstelliges Passwort wie beim Online-Banking genügen. In beiden Fällen ist das Passwort außerdem nicht der einzige Schutz. Am Geldautomaten braucht man außerdem die Karte zur PIN, beim Online-Banking für jeden Geschäftsvorfall eine Transaktionsnummer. Dass die Länge genügt, zeigt sich auch daran, dass es die Angreifer in der Praxis meist mit Ausspähen in seinen verschiedenen Formen versuchen