[linux-l] CAcert - alternativen?

[Steffen Schulz]

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...

> > 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...

> 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.

Egal...

> > 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."

> > 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..

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

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. Es ist auch tatsaechlich die
Karte, die hier Endpunkt ist. Fuer Card-to-Card-auth wird dagegen asym.
Crypto verwendet.

> Versichertendaten auf einer GeldKarte? Oder meinst Du diese komische
> Krankenversichertenkarte?

elektronische Gesundheitskarte, eGK..

> > 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.

> > 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

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.

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...

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

mfg
pepe
-- 
  ,·'·,
 : :' :                                                +47/611-344-01
 `. `'                                        gpg --recv-key A04D7875
   `-  www.debian.org                     mailto: pepe at cbg.dyndns.org