[linux-l] CAcert - alternativen?

[Steffen Dettmer]

* Steffen Schulz wrote on Sun, Aug 27, 2006 at 03:37 +0200:
> On 060827 at 01:10, Steffen Dettmer wrote:
> > * Steffen Schulz wrote on Fri, Aug 25, 2006 at 23:53 +0200:
> > > > OK, es ist genauso sicher, wie ein HTTP MITM, was ja auch nicht so ganz
> > > > einfach ist. Braucht man also wieder kein cert.
> > > 
> > > Aehm...nee, der Login bei cacert passiert mit SSL. 
> > Den wollte man im meinem Szenario ja auch gar nicht angreifen, na egal.
> 
> Es laeuft in dem Szenario aber nirgends HTTP**, auf das man MITM machen
> koennte, daher meine Verwirrung...egal...

Na, das ist doch genau das, was man mit dem cacert.org cert absichern
möchte, oder? Na, ich glaub, wir drehen uns im Kreis :)

> > > Wenn ich hoeher gesteckte Sicherheitsziele habe, mach ich nicht https
> > > mit dyndns und cacert. Sondern zB IPSec, was grundsaetzlich erstmal
> > > abbricht, wenn die Keys nicht stimmen.
> > SSL kann man auch so konfigurieren.
> 
> Aber den Browser anscheinend nicht...

Vermutlich kann man den Browser nicht konfigurieren, um bei falschen
/Schlüsseln/ überhaupt zu connecten. Weiss ich aber nicht. Kann mich
nicht erinnern, mal was in der Form von "Seite präsentiert ein
Zertifikat, verwendet aber einen anderen Schlüssel" gesehen zu haben.
Aber heute könnte ich mir das durchaus vorstellen, dass es sowas gibt.
Man möchte ja immer irgendwie was anzeigen, ob nu richtig oder nicht,
besser, als wenn's dann heisst: "Der Browser XY kann das aber"...

> > Ein self-signed-cert ist doch self-signed und nicht
> > signed-by-root-cert, sonst hiesse es doch nicht self-signed?!
> 
> Na ueblich(dachte ich) ist doch, dass man zum Signieren nen
> (eigenes, ja) root-cert erzeugt und dieses irgendwo sicher lagert.

Ich weiss nicht, ob Du Dich nur "knapp" ausdrückst, aber falls nicht:
das root-cert muss man nicht sicher lagern sondern authentisch
übertragen. Ein root-cert ist immer selbst-signiert, das ist korrekt
(sonst wäre es ja ein sub-CA-cert). Eine CA zu betreiben ist aufwändig.
Man braucht eine dedizierte Hardware, ohne Netz evtl. ohne Platte, eine
Policy (vermutlich das teuerste in Arbeitszeit), evtl. ein Gutachten
(dann ist das das teuerste), eine physikalisch gesicherte Umgebung zum
Lagern der CA Schlüssel (evtl. Zugangskontrolle etc). Je nach Sicherheit
reicht ein Stahlschrank im Büro oder muss es ein zertifizierter
Sicherheitsraum sein. Wie auch immer, ich denke, für ein, zwei
Zertifikate im Jahr ist kaufen einfach das billigste. Kostet vielleicht
200 EUR/Jahr, dafür kann man vielleicht gerade mal die Einleitung der
Policy schreiben.

Ein Stahlschrank mit Laptop würde ich persönlich für einfach SSL Seiten
für ausreichend halten, da ein physikalischer Angriff auf den Server
vermutlich auch nicht stärker gesichert ist (und wer physikalisch an den
Server kommt, hat eh gewonnen) - es sei denn natürlich, man zertifiziert
viele Server, dann muss die CA natürlich entsprechend gesichert sein,
dass es idealerweise einfacher ist, /alle/ Server anzugreifen, als die
CA unerkannt anzugreifen. Hat man die Anforderung nicht, weil man alle
Zertifikate im selben Rechenzentrum einsetzt, reicht meiner Meinung nach
ein Stahlschrank oder ein Safe in diesem Rechenzentrum (weil: wer da
drin ist, braucht nicht den Safe knacken, sondern bootet die Server kurz
mal von CD und installiert ein rootkit).

Wobei ich hier nirgendwo sehe, wo ein cacert.org Zertifikat hilft. Es
suggeriert fälschliche Sicherheit, ist damit meiner Meinung nach absolut
kontra-produktiv.

> > > Was da kommt, weiss ich nicht(wohl entweder die CRL oder ein
> > > Gueltig/Ungueltig, letzteres erzeugt aber auch Last).
> > lol, aber RSA Schlüssel benutzten :)
> 
> Es sprach einmal eine Geisteswissenschaftlerin zu mir...
> 
> "Wenn ich nur Dinge benutzen wuerde, die ich verstehe, saessen wir
> jetzt im Dunkeln."

Was heisst das jetzt? Natürlich muss man nicht alle Dinge /selbst/
verstehen, aber man muss Marketing, Möglichkeiten und Theorie auf der
einen Seite und Praxis auf der anderen unterscheiden können. Theoretisch
haben wir ja auch keine Arbeitslosigkeit :)

> > > Fuer sowas RSA statt zB 3DES zu nehmen kann schon ziemlich bekloppt
> > > sein. Es kommt halt auf die Details an.
> > RSA und 3DES sind so erstmal "gleich sicher". Sorry, aber dieser
> > asymetric-Hype geht mir auf die Nerven. asymetric braucht man für n:m
> > Vertrauen, nicht für mehr Sicherheit an sich. Aber ist ja auch egal.
> 
> Ja, steht doch da. Je nach Anwendung ist RSA hier voellig unnoetig
> und 3DES wesentlich performanter..

Ach so, ja stimmt. 3DES (und Co) haben i.d.R. den Vorteil, dass man
Schlüssel ableiten kann. In einer 1:n Vertrauensbeziehung eine meiner
Meinung nach wundervolle Technik. Man braucht keine Datenbanken für
(öffentliche) Schlüssel oder Zertifikate. Das ist elegant. Naja, wie
auch immer.

> > > Damit macht man dann sichere Verbindungen zwischen Karte und
> > > irgendeinem Webserver. 
> > (ohh-ohh)

Ich hab jetzt eine ganze Weile nach allgemeinen technischen
Informationen zum Betrieb der eGK gegoogelt, aber nichts wirklich
helfendes gefunden. Das beste war noch

http://www.dimdi.de/dynamic/de/ehealth/karte/downloadcenter/technik/loesungsarchitektur/loesungsarchitektur_aktuell/loesungsarchitektur_spezif/egk_gesamtsicht_v1.pdf

Komischerweise sind die Grafiken in dem PDF bei mir teils dermassen
langsam, dass man kaum blättern kann.

Jedenfalls auf den ersten Blick ein sehr schönes Dokument, leider
enthält es keine konkreten Sicherheitsrichtlinien, nur Ideale (kein
"nicht-authorisierter Zugriff", aber nicht, wie dieser erreicht wird).

Da meines Wissens nach keine Klasse-3 Kartenleser eingesetzt werden, ja,
der Arzt bzw. die Apotheke wohl nichtmal ein Sicherheitsmodul benötigen
werden, kann das ja nicht sicher sein. Wie will man denn ohne
tamper-responsive Kartenleser sicher sein, dass die PIN nicht ausgespät
wird? tamper-evident ist meiner Meinung nach noch zu wenig, weil ich als
Kunde nicht erkennen kann, wie das entsprechende Sicherheitsmodul
Manipulationen anzeigt. Vielleicht müsste hinten ein Sigel sein, aber
das kann ich nicht wissen, also auch nicht prüfen. Richtigerweise braucht
man Klasse-4 Leser, damit man Manipulationen erkennen und verfolgen
kann. Ein VPN Tunnel von einem PC ist dazu natürlich nicht ausreichend
(da der PC über einen Trojaner oder von einem normalen Techniker
manipuliert werden kann, was für den Karteninhaber in keinem Fall
erkenntlich wäre).

Na, und das mit der digitalen Signaturmöglichkeit ist meiner Meinung
nach eine Katastrophe. Man kann anscheinend beliebige Daten signieren.
Da soll man dann evtl. ein Word-Doc unterschreiben. Das wird auf einem
evtl. manipulierten PC verfälscht angezeigt oder es enthält Macros, die
z.B. je nach Systemdatum etwas unterschiedliches anzeigen (derartige
Angriffe gab es bereits).

Am Ende sagt man sich dann aber, aus Kostengründen nimmt man einen
Klasse-1 Leser, weil die heute schon dastehen. Da hämmert dann am Ende
die Schwester die Karte in eine Tastatur und man soll irgendwo seine PIN
eingeben. Vielleicht gar über eine PC-Tastatur oder ein anderes
ungeschütztes Gerät. Die Klartext-PIN liegt dann mindestens im PC vor
und kann problemlos ausgespäht werden.

Als Karteninhaber darf ich aber nichtmal verweigern, meine PIN an so
einem System einzugeben. Eigentlich könnte ich sie gleich per Mail
verschicken, aber das will keiner hören. Die PIN ist zwar nicht sicher,
aber danach sichert man mit high-security-crypto ab. Super.

> Das dacht ich auch. Die serverseitigen Dienste bei der eGK sind bisher
> anscheinend nicht definiert und allem anschein nach wird tatsaechlich
> direkt mit Webservern gesprochen. Oder zumindest irgendwelchen
> Servern, die mit SOAP klarkommen und 3DES koennen. 

Also, wenn es tatsächlich nichtmal "serverseitig" Sicherheitsmodule
geben soll, kann man den Kram sowieso komplett vergessen. Aber sooo
extrem schlecht wird es ja hoffentlich nicht sein. Nur sehr schlecht (==
billig).

> Es ist auch tatsaechlich die Karte, die hier Endpunkt ist. Fuer
> Card-to-Card-auth wird dagegen asym.  Crypto verwendet.

Wie kann ich als Karteninhaber prüfen und einschränken, gegen welche
Gegenstelle sich die Karte authentifiziert und umgegekehrt? Die Karte
hat weder Display noch Tastatur, dem PC dadran kann ich nicht trauen und
ein Sicherheitsmodul gibt es nicht. Also muss ich meine PIN
ungesicherten Komponenten verraten. Da man die PIN ausspähen kann, muss
man die Kryptografie gar nicht angreifen, man kann sie ja einfach
benutzen. Weitere nette Angriffe gibt es, wenn man einfach mal ein
Arzt-Terminal klaut (Hausbesuch oder so). Die ungesicherten Terminals
sind nicht in sicherer Umgebung, die Bediener sind keine
Sicherheitsbeauftragten (sondern in der Praxis ja Krankenschwestern).

Meiner Meinung nach sieht man nur wieder: theoretisch könnte man das
sicher machen. Die Sicherheit ist an einigen Stellen sehr hoch (lange
Schlüssel etc), aber an anderen (Zugriffskontrolle und
Karteninhaberprüfung) niedrig. Damit ist die Gesamtsicherheit niedrig,
weil der Angreifer ja nicht das Sicherste, sondern das Einfachste
angreifen wird.

> > Versichertendaten auf einer GeldKarte? Oder meinst Du diese komische
> > Krankenversichertenkarte?
> 
> elektronische Gesundheitskarte, eGK..

(ja, sorry, dachte, GK sei GeldKarte)

> > > liegendie Probleme wie immer ganz woanders, zB dass ein Arzt am Tag
> > > 20x seine PIN eingibt oder einfach, dass sich das gesamte Projekt
> > > gar nicht rechnet.
> > Die Krankenversichertenkarte war irgendwie ganz krank, hab die
> > Details vergessen, sie sollte einfach KrankeKarte heissen lol
> 
> Das bemerkenswerte ist, dass X grosse Firmen, die sich mit
> Chipkartensicherheit, grossen Projekten und Sicherheit an sich
> eigentlich "auskennen", hier jahrelang Konzepte ausarbeiten,
> standardisierte Protokolle nutzen und Specs veroeffentlichen.
> Und trotzdem kommt was inherent unsicheres dabei heraus.

Ja, natürlich, ist doch logisch. Sicherheit kostet Geld. Also ist jede
Firma daran interessiert, es so unsicher wie möglich zu machen. Dass man
überhaupt was sichert, liegt nur an Zulassungsbedingungen. Mehr machen
kostet mehr Geld, muss ein Unternehmen also lassen (da es ja Geld
verdienen und nicht verschwenden soll). Die eGK wird ja nicht
eingeführt, um Sicherheit zu erhöhen (nicht wirklich), sondern um
angeblich Kosten zu sparen (und Geld in Lobbies zu pumpen). Das ganze
muss dabei so kompliziert sein, dass es nur grosse Firmen (idealerweise
gar nur eine) (wirtschaftlich) machen kann, sonst bekommt man am Ende
Probleme mit den Ausschreibungen. So ein Projekt muss in der
Realisierung mindestens eine Million Euro, besser zehn, kosten (je
Komponente).

> > > http://www.cryptolabs.org/rsa/WeisLucksBogkTwirlDatenschleuder.html
> > > Datenschleuder hin oder her, die ersten beiden sind bekannte Leute.
> > Ja, für mit zehn Millionen kann man schon ne Menge machen. Jedenfalls
> > theoretisch. Meist ist sowas ja immer sehr theoretisch.
> 
> www.hyperelliptic.org/tanja/SHARCS/talks06/copacobana.pdf

Wirklich cool, programierbare parrallele Maschine! Wollte doch hier
jemand in der Liste bauen, sowas (für SETI at home oder so), müsste doch
sehr geeignet sein, und wirklich billig. Müsste auch gut zum rendern
gehen etc, wenn man denn die Software hinkriegen würde.

> Bei der Leistung muss man noch beachten, dass es aus dem
> universitaeren Umfeld stammt und Geld ne grosse Rolle spielte. Es ist
> daher auch nicht auf einen einzelnen Algorithmus optimiert, sondern
> auf Operationen, die viele Algorithmen gemeinsam haben.

Wie auch immer, brute-force lässt sich immer schön parallelisieren,
klar. 56 Bit in 8 Tagen. Für 112 Bit (3DES) braucht man 2^56 mal länger,
dass sind dann 1.579.344.526.858.694 Jahre, richtig?

Nehmen wir an, das Budget wäre nicht 9.000 $, sondern 9.000.000.000.000
(neuntausend Millarden), dann dauert es nur noch 1.579.344 Jahre, also
anderthalb Millionen Jahre, korrekt?

Für einen einzigen Schlüssel (mit known-plaintext).

Ich glaube, 3DES reicht für zu Hause damit noch aus ;)

> Also wenn Geld oder Performance ein Problem sind, mag man ja mit dem
> Minimum leben koennen, aber fuer den Hausgebrauch gibts keinen Grund,
> da zu sparen...

Dann also nicht cacert.org, sondern Verisign Military Grade? :-)

> BTW kann man mit solcher Hardware das 3DES im Basic Access Control des
> ePass brechen, weil hier die MRZ als Schluessel eine zu geringe
> Entropie hat. Einmal mithoeren reicht. Paper bei www.prosec.rub.de

Na super. Zum ePass und ähnlichen Sachen (der grösster Hammer sind ja
diese komischen contactless-Implantate) gabs schon langweilig viele
Angriffe, fand ich. Ist meiner Meinung nach immer das gleiche: an einer
Stelle hat man sinnlose Sicherheit und man zieht den falschen Schluss,
man hätte was sicherers. Genau wie das Märchen, RFID würde sicher
kommunizieren oder schwer zu missbrauchen. Ich glaub, die wirklich guten
Hacker sind nur noch am feiern, wenn sie in die Zukunft gucken. Dann
muss man nicht mal mehr ne Karte klauen, es reicht, am Opfer
vorbeizugehen. Und es merkt nichtmal, dass die Karte geklaut ist (oder
benutzt wurde), herrliche Zeiten für die Angreifer...

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.