[linux-l] CAcert - alternativen?

Steffen Schulz pepe_ml at gmx.net
Fr Aug 25 23:53:59 CEST 2006


On 060824 at 23:10, Steffen Dettmer wrote:
> * Steffen Schulz wrote on Thu, Aug 24, 2006 at 20:59 +0200:
> > Wenn ich fuer meine Domain ein cacert-cert habe, schliesse ich damit
> > jeglichen MITM ziemlich gut aus. Niemand wird fuer diese Domain einfach
> > so ein Zert erzeugen koennen, ausser mein Login bei cacert ist schlecht
> > geschuetzt.
> 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. Und so ein Angriff
ist eher langfristig ausgelegt, weil ich mich so gut wie nie bei cacert
anmelde. Man kann nich mal eben meine Verbindung kompromittieren oder
im nachhinein entschluesseln.

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.


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

> > Ich spare Aufwand, weil mir das root-cert erspart bleibt. Weil dieses
> > root-cert muss man auch verbreiten, fingerprint abrufbar haben, CRL
> > abrufbar haben.
> > 
> > (BTW, hier in der Ruhr-Uni-Bochum wird einem beigebracht, dass niemand
> >  ernsthaft CRLs benutzt, wegen der enormen Serverlast, die das erzeugen
> >  wuerde. Sollte man mal gucken, wie oft firefox die CRLs checkt...)
> 
> 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).

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.

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

Ich mein mit SmartCard alles, was irgendwie geheime Daten schuetzt,
indem nur Operationen ausgefuehrt werden koennen, wo diese Daten
eingehen, ohne dass die Daten den Chip verlassen. Die Karten werden
dann noch irgendwie evaluiert, sodass man je nach Klasse auch mit
Lupe oder Teilchenbeschleuniger nicht an die Daten kann.

zB steckt man die Karte irgendwo kein, sie bekommt eine Challenge und
signiert(verschluesselt) diese. 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.

Die neue eGK wird zB auch mind. 2 DES-Schluessel enthalten. Der Server
hat den Master-Key, aus dem er mit Hilfe der Kartennummer den
Schluessel der Karte ableiten kann. Damit macht man dann sichere
Verbindungen zwischen Karte und irgendeinem Webserver. Geplante Dienste
sind zB das Update der Versichertendaten und neue Funktionen fuer die
Karte. Technisch gut durchdacht, 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 Karte hat auch mind. 2 RSA-Keys und einige X509-Zerts, wobei
 die PKI limitiert wurde um keine langen cert-ketten zu bekommen)


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..) oder die geheimen Daten weiteren
Parteien bekannt ist, ist klar...

> > Jo, in der Industrie hat man sich mit Elliptischen Kurven noch nicht so
> > recht angefreundet. Wird vllt auch noch ne ganze Weile dauern, wegen
> > der Patentgeier...
> Vielleicht ist es auch langsam, lässt sich nicht gut in Hardware giessen
> oder sowas, keine Ahnung.

Die Grundoperationen sind teurer, aber dafuer reichen 160Bit statt
1024(, weil Index Calculus bisher nicht auf El.Kurven uebertragbar
ist).

ECC ist zB bei der eGK vorgesehen, default ist aber RSA. Genauso wie
man 3DES statt AES nimmt. Es ist halt momentan Standard und billiger
als Neuentwicklungen. Fuer viele Kniffe mit ECC fehlt vllt auch das
KnowHow. Ausserdem findet man immer wieder was, wie irgendwas noch
besser geht. Und bei ECC versaut das ggf. die Kompatibilitaet, weil man
dann in anderen Gruppen rechnet oder so.


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

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.


mfg
pepe
-- 
Hi, I'm a unix-virus.
Please copy me into your .signature to help me spread!



Mehr Informationen über die Mailingliste linux-l