[linux-l] CAcert - alternativen?

[Steffen Schulz]

On 060827 at 15:50, Steffen Dettmer wrote:
> Vermutlich kann man den Browser nicht konfigurieren, um bei falschen
> /Schlüsseln/ überhaupt zu connecten.

Ich meinte, dass er abbrechen soll, wenn die Authentizitaet des
Zertifikats nicht geprueft werden kann. Weil die uebliche Nachfrage ja
gern reflexartig bestaetigt wird.

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

Kleiner Test brachte: "the connection was interrupted". Wuerde mich
auch wundern, wenn man das gesondert abfaengt.

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

Ja, sorry. Aber du hattest das mit eigentliche "Problem" eh schon
geklaert...aber danke fuer die Ausfuehrungen aus der Praxis :)

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

Ich hab im Laufe des Tages heute irgendwo was mit "bekommt einen 304"
gelesen und da war ich dann auch wie vom Blitz getroffen...Brett vor'm
Kopf...

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

Aber das ist manchmal gar nicht leicht. Teilweise beginnt man, am
eigenen Verstand zu zweifeln, bei dem ganzen Unfug, der verbreitet
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.

http://www.gematik.de/upload/gematik_KT_eHealth_Kartenterminal_V1_0_0_621.pdf

+ wenn einer dran fummelt, muss das akustisch oder optisch fuer den
  Nutzer sichtbar sein
+ die Dinger haben ein integriertes Display
- ein PC ist ein "virtueller Kartenleser", wenn er die gleichen
  Anforderungen erfuellt wie ein echter
- Nutzerfuehrung muss offensichtlich voranden sein, ist aber offenbar
  der Industrie ueberlassen

Zur Abnahme muss die entsprechende Sicherheitsrichtlinie vom BSI
erfuellt werden. Die sind auch auf dimdi oder gematik verlinkt. Aber
anstrengend zu lesen.

Bleibt zu hoffen, dass die ueblichen zu signierenden Dokumente
innerhalb o.g. Benutzerfuehrung erzeugt werden und dass die Terminals
kein WinXP fahren.

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

Was sind denn "Sicherheitsmodule"? Jeder, der Kartenterminals nutzt,
muss nen "Konnektor" haben. Diese Kiste baut nen VPN-Tunnel zur
Zentrale auf und verbindet zu den Terminals, die im LAN auftauchen, per
TLS. Er ist Appl-Level-Proxy, in den Specs ist eine Firewall und ein
IDS vorgeschrieben. :)

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

Das ist so einer der Punkte, der mir auch unklar ist. Hoffentlich im
integrierten Display des Kartenterminals. Gelesen hab ich das aber
nicht. Ich hoffe auch, dass man die Certs fuer TLS/VPN nur
unterschrieben bekommt, wenn man die Schutzprofile vom BSI erfuellt,
aber auch das steht nirgends.

> Weitere nette Angriffe gibt es, wenn man einfach mal ein
> Arzt-Terminal klaut (Hausbesuch oder so).

In der Theorie kannst du damit dann lediglich die Notfalldaten
auslesen. Und selbst dafuer musst du noch einen HBA besitzen und
eventuell auch noch dessen PIN kennen. (Welche Anwendungen man in
welchen Konstellationen nutzen kann, ist spezifiziert.)

> Die ungesicherten Terminals
> sind nicht in sicherer Umgebung, die Bediener sind keine
> Sicherheitsbeauftragten (sondern in der Praxis ja Krankenschwestern).

*Alle* Praxen muessen mit ihren "Primaersystemen" ans Internet.
Die Primaersysteme halten per Spec alle lokal benutzten Patientendaten
vor. In der Praxis ist das einfach das komplette LAN der Praxis mit
allen Kartenlesern und Rechnern, die Patientendaten verarbeiten
muessen.

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

In der Praxis spart man auch kein Geld, sondern bringt nur enorme
Komplexitaet ins System. Dann noch in diesem Betriebsumfeld. Sowas
bekommt Mensch nicht sicher, auch wenn er wollte.

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

Hersteller und Vorstaende haftbar bzw verantwortlich machen, wie
Schneier schon ewig verlangt..

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

War klar, dass das kommt :)

Wir waren ja auch bei Praxistauglichkeit der Rechnerentwuerfe.
112 Bit, oder allgemein 128, werden auch noch ne ganze Weile halten.
Das nicht mehr machbare liegt momentan so bei 80 Bit. 70-75
kann man mit viel Kohle und Zeit schaffen. Referenzen find ich nicht so
recht, aber dafuer das hier:

http://kai.iks-jena.de/pgp/gpg/keylengths.html#a3

Die 2 Tabellen unter #a3


> > Also wenn Geld oder Performance ein Problem sind, mag man ja mit dem
> Dann also nicht cacert.org, sondern Verisign Military Grade? :-)

Geld...

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

Jup, das kommt derzeit schwer in Mode. Aber oft liesse es sich sicher
machen. Mir ist gestern noch aufgefallen, dass der Angriff im Grunde
auf nen Denkfehler im Protokoll beruht. Haetten sie zB CBC-Mode
benutzt, haette der Angreifer kein klar/geheimtext-Paar, mit dem er den
Schluessel BFen koennte. Wenn ein Verbindungsaufbau mit falschem
Schluessel ausserdem zu 2sek Funkstille fuehren wuerde, waere das Ding
vom generellen Design er erstmal wieder sicher. Sicher im Sinne von "der
Angreifer muss 50 Jahre hinter mir in der Schlange stehen".

ePayment mit RFID geht in der Theorie anonym und sicher. Praktisch sind
die Systeme maximal pseudonymisiert. Man benutzt irgendwie SmartCards
und das sieht sicher aus, die Details sind aber unbekannt.

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

Es bleibt spannend. :)


So soll es auch sein.

mfg
pepe
-- 
No matter where you are... Everyone is always connected.
				- Serial Experiments Lain