[linux-l] CAcert - alternativen?

[Steffen Dettmer]

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

> 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. Wenn Du bei IPSec Opportunic encr
cacert traust, sollte das gleiche (un)Sicherheitsniveau rauskommen,
denke ich.

> > > Fremde self-signed certs benutzt der Browser glaub ich nicht, um
> > > weitere self-signed certs zu authentifizieren(?).
> > 
> > self-signed certs zu authentifizieren? Ist das nicht ein Widerspruch?
> 
> Ich meine, dass man dem eigenen root-cert traut und bei fremden
> self-signed-certs nur diesen certs traut, nicht deren root-cert in die
> eigene Liste aufnimmt. 

Ein self-signed-cert ist doch self-signed und nicht signed-by-root-cert,
sonst hiesse es doch nicht self-signed?!

> Weil diese fremden self-signed-certs koennten auch zur Signierung
> weiterer (boeser) certs genutzt werden, aber der Browser benutzt diese
> wahrscheinlich nicht dazu, certs zu authentifizieren. Hoffentlich.

Nein, die CA flag extenstion ist "critical" in X509v3, darf der Browser
also nicht akzeptieren.

> > enorme Serverlast? mmm... Kommt doch bloss ein 304?
> 
> 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 :)

(Nee, da ist doch das 304 egal.)

> Aber die CRLs muessten wohl mindestens einmal am Tag geprueft werden,
> wenn nicht sogar bei jeder (neuen) Website, die aufgerufen wird.  Von
> allen Clients, die SSL nutzen.

Ja, ein weites Feld mit den CRLs....


> > > EMV Co kenn ich nich. 
> > Das sind die mit den Kreditkarten (Europay, Mastercard und VISA, sind
> > aber nur noch zwei Firmen, ich glaub, Mastercard hat Europay gekauft)
> > :-) Also überhaupt fast alle Karten, weltweit gesehen. In Deutschland
> > auch, weil ec EMV-konform werden wird.
> 
> zB steckt man die Karte irgendwo kein, sie bekommt eine Challenge und
> signiert(verschluesselt) diese. 

Oder macht SDA. Theorie hin oder her, die Frage ist, was man mit den ICC
macht. Man kann zu EMV stehen, wie man will, vorbei kommen wird man
nicht.

> Mit oder ohne PIN. Ohne PIN ist das dann einfach ein Token, welches
> halt geklaut werden kann, aber ansonsten ziemlich sicher ist. Mit PIN
> ist das schon ziemlich state-of-the-art-security. 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.

> Die neue eGK wird zB auch mind. 2 DES-Schluessel enthalten.

Denke mal eher einige 3DES Schlüssel.

> Der Server hat den Master-Key, aus dem er mit Hilfe der Kartennummer
> den Schluessel der Karte ableiten kann. 

Normalerweise kommuniziert eine GeldKarte (ich denke mal Du meinste die
ZKA GeldKate) mit einer Händlerkarte (ohne Authentisierungssystem).

> Damit macht man dann sichere Verbindungen zwischen Karte und
> irgendeinem Webserver. 

(ohh-ohh)

> Geplante Dienste sind zB das Update der Versichertendaten und neue
> Funktionen fuer die Karte. 

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

> Technisch gut durchdacht, 

(wohl nicht die Krankenversichertenkarte)

> 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 man die Sicherheit ad-adsurdum fuehren kann, indem man immer die
> selben challenges schickt("static data authentication", hoert sich
> schon fast wie nen Feature an..) 

Ja, man braucht keinen teuren RSA-Chip auf der Karte. Den haben
übrigens nur die wenigesten Karten. Man muss unterscheiden zwischen den
Möglichkeiten einer Technologie und dem, was man wirklich draus macht.
Ist nicht schlimm, stundenlang in bunten
Marketing-Werbe-Hochglanzheftchen zu blättern - man darf es nur nicht
glauben.

Und ohne RSA-Chip dauert RSA über 60 Sekunden. Also macht man kein RSA.

> > > Der Algorithmenkatalog wird jaehrlich herausgegeben und sagt, was
> > > derzeit offiziell als sicher angenommen wird.
> > als sicher wofür? Ohne das "wofür" macht's ja nu keinen Sinn.
> > Normalerweise hat man einen Schutzlevel, z.B. 100.000 $ pro Key. Klar,
> > wenn man 1.000.000.000.000.000 $ Schutzlevel haben möchte, braucht man
> > vielleicht 1280 Bit ;)
> 
> Pro Key ist ja aber auch nicht so super, weil wenn ich die Hardware
> einmal gebaut habe, kann ich damit beliebig viele Keys nacheinander
> brechen.

Naja, wenn jeder Schlüssel nur noch drei Monate bräuchte, wäre die
Leistung dennoch arg begrenzt (auf ca. vier Schlüssel im Jahr)....

> In solchen Dimensionen scheint man dort nicht zu denken, aber vllt
> interessiert dich das hier:
> 
> 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.

Jedenfalls, theoretisch ist sicherlich einiges möglich. Praktisch hat
man EMV. Oder gar KrankeKarte. Oder gar cacert! Das sollte man nicht
unterstützen (wenn man nicht muss). Leider hilft einem das nur begrenzt.
Irgendwann wird die Digitale Signatur wohl leider auch Pflicht. Naja.

oki,

Steffen

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