SmartCard - wer kennt sich aus?

Hi!

Was spricht gegen Transponder?

Gruss,
Micha

Hallo Zipzap,

ich behaupte mal einfach das ich mich mit der von dir angedeuteten Frage 
auseinandersetzen kann.... Ich entwickel seit mehreren Jahren SDK's für
Smartcards + Reader.

Zum einen must du zwischen den Kartensystemen unterscheiden....

1.) bei den Kartentypen SLE 44xx/55xx (wie von einigen vorgeschlagen) 
handelt es sich um EEPROM Speicherkarten mit PIN Authentifizierung.
Diese Karten verwenden ein 2WIRE/3WIRE Protokoll und können mit einer 
MCARD-API
programmiert werden. EEPROM Speicherkarten bieten eine ziemlich 
begrenzte
Logik, welche sich auf das PIN Management, den Fehlbedienungszähler und 
ggf. vorhandene Write Protection Eigenschaften beschränken.
Diesen Karten fehlt jeglicher Funktionsumfang einer Crypto Engine, da 
diese über keinen Prozessor verfügen.

2.) Die Masterkey Smartcard von SCM ist eine Prozessorkarte vom Typ: 
Payflex
Um diese zu programmieren must du ersteinmal das Security Management 
verstehen bzw. begreifen. Diese Smartcard wird in aller Regel blanko 
ausgeliefert. Das Dateisystem zu der Karte muß also von Dir aufgebracht 
werden. Ich schätze mal ohne grundlegendes Knowhow... brauchst du 
ungefähr 1 Jahr um die Karte mit allen Security Conditions und 
Einstellungen zu beherschen. Gleiches gilt auch für die ACOS Smartcard's

Anmerkung meinerseits:
Die meisten am Markt erhältlichen SDK's sind ziehmlich mager bestückt,
da diese wenig Informationen zur Smartcard und den Internas 
bereitstellen.
Besonders die Terminalansteuerung wird von den meisten SDK's ziemlich 
vernachläßigt... Problem hierbei... Wir haben den Standard PC/SC für 
Prozessorkarten, den CTAPI Standard für Synchrone + Asynchrone Karten, 
den CCID Standard der neueren Terminals...

Stichwort: Smartcard Kopierschutz
Alle EEPROM Speicherkarten können zu 100 % kopiert werden.
Ein READ Protection gibts bei denen nicht, daher kann z. B. jede SLE
vollständig ausgelesen werden und auf eine Blanko SLE kopiert werden.
Lediglich die PIN läßt sich nicht so ohne weiteres kopieren...
Wenn du bei den SLE Kartensystem per CTAPI programmierst, dann ist auch
das PIN Management unter bestimmten Voraussetzungen auslesbar. Defakto 
Sicherheit -> NULL :-)

Das aus meiner Erfahrung sicherste System stellt derzeit die ATMEL 
Smartcard: CRYPTO MEMORY dar. Diese Smartcard bietet eine MUTUAL 
AUTHENTICATION COMMAND, welches eine sichere Authentifizierung zwischen 
Terminal + Chipkarte ermöglicht, also eine Echheitsverifizierung der 
Smartcard durchführt, welche nicht auslesbar ist.

Aus programmatischer Sicht gesehen, stellt sich eigentlich zuerst die 
Frage, welche Karte du verwenden solltest. Aus meiner Sicht, solltest du 
eine Asynchrone Smartcard einsetzen... Damit bist du am flexibelsten in 
der Programmierung, da du direkt auf ein PC/SC aufsetzen kannst, ohne 
das du auf Fremdkomponenten zurückgreifen mußt.

Ich habe für einen Großkunden eine ActiveX/Smartcardsoftware auf Basis 
der CryptoMemory entwickelt welche eigentlich genau den Bereich abdeckt, 
den du zu lösen versuchst...

Wenn du hier Produktunterstützung benötigst, setz dich einfach mit mir 
in Verbindung, wir können das von dir umzusetzende Problem innerhalb von 
3-4 Tagen vollständig lösen !

MfG.
Mario Misic
ProScan Elektronische Systeme
www.smartcardtools.de
info@smartcardtools.de

Letztendlich entscheided in deiner Software an irgendeiner Stelle ein 
Stückchen Maschinencode, ob in die eine Richtung (Benutzer 
identifiziert) oder andere Richtung (Benutzer nicht identifiziert) 
gesprungen wird. Und das lässt sich patchen.

Jeder Benutzer, der direkten Zugriff auf die Hardware des Rechners hat, 
kann dein tolles Karten-System also umgehen.

Also ist ein übertriebener Aufwand an der Stelle eher Fassade als 
wirkliche Sicherheit. Warum machst du das nicht einfach mit Benutzername 
und Passwort?

Oliver Döring schrieb:
> Letztendlich entscheided in deiner Software an irgendeiner Stelle ein
> Stückchen Maschinencode, ob in die eine Richtung (Benutzer
> identifiziert) oder andere Richtung (Benutzer nicht identifiziert)
> gesprungen wird. Und das lässt sich patchen.
>
> Jeder Benutzer, der direkten Zugriff auf die Hardware des Rechners hat,
> kann dein tolles Karten-System also umgehen.
>
> Also ist ein übertriebener Aufwand an der Stelle eher Fassade als
> wirkliche Sicherheit. Warum machst du das nicht einfach mit Benutzername
> und Passwort?

Wie willst du denn einen Patch generieren, bei dem eine 
Authentifizierung
zwischen Terminal + Chipkarte stattfindet ? Das funktioniert absolut 
nicht,
weil der benutzer beim Muthual Authenticate KEINEN Stream erhält.
Der hierbei angestoßene Prozess findet ausschließlich zwischen beiden 
Hardware-Komponenten statt und wird nicht über den Anschluß (USB, 
Seriell, PS/2 usw.) ausgeführt. Der Vorgang ist vergleichbar zu der PIN 
Authentifizierung an Terminals mit Keypad... da kannst du die Eingabe am 
terminal auch nicht patchen -> Absolut nicht auslesebar, somit auch 
absolut sicher...

Hans schrieb:
> @Zipzap
> Schau mal Pollin Artikelnr: 100975 !
>
> Normalerweise sind die Dies in Chipkarten verbaut und haben eine richtig
> nette EAL3 Common Criteria Einstufung. Feine asym. Kryptoeinheit :-)
> Für andere kommerzielle vergleichbare Angebote ist das 100-fache
> fällig...
>
> Drin ist Philips (NXP) P8WE5032 und da sollte STARCOS drauf sein.
>
> Wohl bestes Security/Preis Verhältnis, aber es wir das schon erwähnte
> Jahr fällig,
> um im Umgang vertraut zu werden (der beste Einstiegslink ist
> http://www.wrankl.de bzw. dessen Bücher).
>
> VG,
> Hans

Du hast vergessen zu erwähnen wo Zipzap den passenden Lötkolben kaufen 
kann um die kontakte zu verdrahten :-) Damit dürfte das Preis/Leistungs 
Gefälle wohl dahin sein.

Gruß
Mario

> Der Vorgang ist vergleichbar zu der PIN
> Authentifizierung an Terminals mit Keypad... da kannst du die Eingabe am
> terminal auch nicht patchen -> Absolut nicht auslesebar, somit auch
> absolut sicher...

"Absolut sicher", jaja... Seriöse Entwickler machen eine solche Aussage 
niemals.

Der TO wollte doch Benutzer einer PC-Software identifizieren, die in 
VB.NET geschrieben werden soll. Und wie teilt das Karten-Terminal der 
Software mit, dass ein Benutzer absolut sicher identifiziert wurde und 
wie dieser heißt? An der Stelle kann man immer ansetzen, wenn die 
Software lokal ausgeführt wird.

Zipzap,

du kannst das so machen, brauchst dann allerdings eine Karte mit 
Prozessor.

Da aber sowohl der Algorithmus zum Verschlüsseln als auch die Tabelle 
mit den vorab berechneten Werten in deinem Programm stehen wird, kann 
jeder, der die ausführbare Datei deines Programmes lesen kann, den 
Schutz umgehen. Er könnte sich dann nämlich eine passende Karte 
nachbauen.

Hallo Oliver,
dir scheint der Background zur Smartcard Konfiguration vielleicht nicht 
ganz geläufig zu sein. Bei manchen Prozessorkarten... lassen sich 
Herstellerseits verschiedene Authentifizierungsmechanismen innerhalb der 
Kartenkonfiguration setzen. Ich rede jetzt nicht von den Kartenpin's...

So kann ich im Falle einer Crypto Memory Smartcard die Access Conditions 
so setzen, das beim Connecten der Smartcard automatisch das Muthual 
Authenticate auszuführen ist. Dazu bedarf es keiner einzigen Codezeile 
mehr im Frontend (z. B. VB.NET), welche du gerne manipulieren möchtest.

Du könntest zwar den Connect Befehl manipulieren, aber damit wäre auch 
der Zugriff auf die Smartcard hinfällig bzw. würde nicht ausgeführt.

Beispiel: Ich habe eine Smartcard mit 3 Zonen

Zone 0: Read/Write Only without PIN
Zone 1: Read/Write with PIN
Zone 2: Read/Write with PIN and Authentication (Mutual Auth.)

Beim Connecten der Smartcard auf Zone 0+1 findet keine relevante 
Echtheitsüberprüfung der Smartcard statt. Hingegen bei Selektierung der
Zone 2 muß die Smartcard (nicht der Anwender) sich gegenüber dem 
Terminal als Echte Karte authentifizieren. Bei den hier angestoßenen 
Prozess tauschen Smartcard + Terminal untereinander Informationen aus 
(Session- u. Authentication Keys). Dieser Vorgang findet ausschließlich 
zwischen diesen beiden Hardwarekomponenten statt und verläßt diese 
nicht, da ist also nix, was sich ggf. abhorchen ließe, bzw. nach außen 
dringt.

Sollte das Authentication zwischen beiden Komponenten scheitern, wird 
auch ein Zugriff auf die Smartcard bzw. die hiervon betroffene Zone 
nicht möglich sein. Daraus resultiert... Nicht erfolgreiche 
Selektierung, = fehlerhafte Smartcard, was eigentlich damit auch deine 
Frage beantwortet, wie das Kartenterminal der Anwendung mitteilt ob die 
Identifizierung
erfolgreich verlief oder nicht. Wenn das Authentication erfolgreich 
verläuft, wäre auch damit die Echtheit der Smartcard bestätigt und der 
Zugriff auf die hiervon betroffe Zone möglich.

Du könntest nun versuchen die Smartcard 1:1 zu kopieren und dennoch 
würde es nicht funktionieren, da dir weder die zur Laufzeit benötigten 
Session- noch die Authentication key's bekannt sind, welche unter anderm 
auch den LOT History Code der Karte abhängig sind (Serialisiere ID), 
welcher Herstellerseits kein zweites mal existiert.

Und daher kann ich als seriöser Entwickler, derzeit auch ohne weiteres 
schreiben, das diese Karte mit eine der sichersten ist, die offen am 
Markt erhältlich ist und nach jetzigem Stand der Technik mit den 
höchsten Sicherheitsstandard bietet.

Aber ich gebe dir natürlich recht, das man im Frontend durchaus sagen 
könnte, die Karte wäre echt, indem ich in der Einsprungadresse der 
hiervon betroffenen Abfrage einen Patch einbaue der mich umleitet. Wäre 
nur dann das Problem... das keine Daten da wären die man auswerten 
könnte....

MfG.
Mario

> Aber ich gebe dir natürlich recht, das man im Frontend durchaus sagen
> könnte, die Karte wäre echt, indem ich in der Einsprungadresse der
> hiervon betroffenen Abfrage einen Patch einbaue der mich umleitet. Wäre
> nur dann das Problem... das keine Daten da wären die man auswerten
> könnte....

Hallo Mario, genau darum geht es doch.

Du kannst da noch so mit tollen Begriffen um dich werfen und dein System 
anpreisen... Das nützt alles nichts, weil es hier um eine simple 
Benutzer-Authentifizierung an einer PC-Software geht. Da gibt es keine 
Daten die man auswerten könnte, außer einer Benutzer-ID und der 
Information, ob eine gültige Authentifizierung vorgenommen wurde oder 
nicht.

Und die kommt auf einer physikalischen Schnittstelle rein, welche man 
immer emulieren kann, um der Software einen bestimmten Benutzer 
unterzuschieben.

Jetzt sag bitte nicht, man könnte die Kommunikation zwischen dem PC und 
dem Kartenterminal verschlüsseln...

Die einzige seriöse Aussage wäre, dass man für eine lokal ausgeführte 
PC-Software keine sichere Authentifizierung hinbekommt.

Hallo Oliver...

Die Aufgabenstellung lautete:

Karte drin - Benutzer ist identifiziert
keine Karte drin - kein Benutzer identifiziert.

Die normalen Nutzer dürfen also nicht in der Lage sein, so eine Karte zu
"kopieren" / ich müßte also vor Ausgabe irgendetwas Eindeutiges
verschlüsselt auf die karte schreiben bzw. brauche eine Karte die einen
Algorithmus zum verschlüsseln und zurückgeben hat - na eben irgendwas um
das o.g. Ziel zu erreichen.


Die Frage von Zipzap bezieht sich eigentlich nicht auf mögliche Angriffe 
auf das Frontend, welche per Reverse Engineering und dessen was damit 
theoretisch gesehen möglich ist, sondern es geht um immer noch um o. a. 
Anforderung. Also um mögliche Vorschläge oder Empfehlungen !

Zum Thema Kopierschutz bietet sich halt das von mir beschriebene 
Verfahren bestens an. Ich kenne bis dato noch keine bessere Alternative 
als über das Muth Auth. die Authentität der Karte zu prüfen.

Vielleicht wird dein nächster Beitrag ein wenig produktiver... wir reden 
hier nicht über eine simple Eingabemaske für Benutzername und Password 
wie du's weiter oben vorgeschlagen hast... Höchst unprofessionel -> Da 
freut sich jeder Keylogger :-) und das auch ohne Patch

Gruß Mario

Man sollte bei Sicherheitsfragen immer das System als ganzes sehen. Die 
Anforderung "Karte soll nicht kopiert werden können" ist sehr spezifisch 
und nützt wenig, wenn es einfache Umwege gibt, die mit der Karte nichts 
zu tun haben.

Dazu müsste Zipzap genauer beschreiben, was er mit seiner Maßnahme 
eigentlich schützen will und wie groß ein möglicher Schaden wäre.

Die vorgeschlagenen Chipkartentechnologie mit einem Jahr 
Einarbeitungszeit ist jedenfalls so, als würde man jemandem eine 
High-End-Tresortür als Haustür installieren, während nebenan im 
Erdgeschoss ein Fenster offensteht.

Wenn man sich die spektakulären Hacks der letzten 10, 20 Jahre anschaut, 
dann geht es ganz oft um diese Fenster nebenan...

Ein solch offenes Fenster bieten manche Anbieter bereits von Hause aus 
in ihren Chipkarten an... (z. B. AT88SC1608), hat eine Backdoor 
Eigenschaft, mit dem sich die Sicherheitseinstellungen umgehen lassen...

Eine spezielle Serie der SLE4428 hat einen undokumentierten Fehler 
innerhalb der PIN Abfrage, welche auch bei falscher PIN einen 
Schreibzugriff ermöglicht...

Da gibts genug offene Fenster :-)

MfG.
Mario

Selbst der durchschnittlich begabte User hat eigentlich überhaupt keine 
Chance mit einer entwendeten Karte sich eine Kopie anzulegen.

Weil... Gute Prozessorkarten erkennst du daran, dass die zur Userzone
auch über eine Securityzone verfügen, in welcher die Konfiguration der
gesamten Karte abgebildet wird.

Dein Datendieb müßte also zuerst einmal die Security FUSES der Smartcard 
unlocken, was mit einer gewöhnlichen Software, wie man Sie im Internet 
findet überhaupt nicht funktioniert. Es gibt keine Anwendungen im Netz, 
die diesbezüglich Hilfestellung leisten.

Wenn der Aussteller der Karte seine Security Zone mit der werkseitigen 
Transportpin beibehält, hätte man einen minimalen Ansatz um die Access + 
Password Register auszulesen.

Verfügt die Karte über einen Supervisior Mode, könnte man theoretisch 
mit der Transportpin auch auf das PIN Management der Security Zone 
zugreifen,
sofern der Kartenausgeber diese nicht geändert hat. Damit hätte man 
zumindestens die PIN's für Read/Write Prozesse + Zugriff auf den 
Fehlbedienungszähler. In diesem Fall könnte man mit der Originalkarte 
durch die PIN's alle Zonen auslesen und für ein Duplikat protokollieren.

Ist die Smartcard durch das PER FUSES gelockt, ist ein Zugriff auf die 
Authentication + Session Keys nicht mehr möglich. Somit scheitert dein 
Kartendieb spätestens an dieser Stelle.

Werden die Auth+Session Keys mit der Uniqe-ID der Karte (LOT History) 
verknüpft, besteht eigentlich überhaupt keine Chance einer 1:1 Kopie !

Du könntest zudem auch eine 2 Faktoren Authentifizierung einbeziehen...

-> Read/Write with PIN and Authentication

Damit müßte dein Kartendieb auch noch die persönliche PIN des 
Karteninhabers kennen um einen halbwegs erfolgreichen Angriff 
durchzuführen...

Es gehört schön ein massives Backgroundwissen dazu eine Kartenkopie 
erfolgreich zu erzeugen und auch das funktioniert auch nur ggf. dann, 
wenn der Kartenausgeber die Securityzone aus Unwissenheit nicht 
vollständig absichert, bzw. das locken der Security FUSES ignoriert.

Fazit: Mit einer asynchronen Smartcard bist du eigentlich fast immer auf 
der sicheren Seite.

Gruß
Mario

Poll dir die technischen Informationen der einzelnen Smartcards
und schau dir die Security Features hierzu an.

Du kannst auf Kartensysteme zurückgreifen, welche ein
T=0 Protokoll bzw. T=1 Protokoll unterstützen. Das bezieht sich auf
asynchrone Karten.

Wird ausschließlich 2WIRE, 3WIRE angegeben, handelt es sich um eine rein 
synchrone Karte.

Wenn T0 u./o., T1 + 2WIRE angezeigt wird, handelt es sich um asynchrone 
Karten, bei denen im erstzugriff ein asynchrones Protokoll erwartet wird 
und dann eine interne umschaltung nach dem connecten auf das schnellere 
2Wire erfolgt. Das ist z.  B. bei der CryptoMemory der Fall.

Bei den einzelnen SDK's solltest du eigentlich Beispielprojekte 
vorfinden, welche die jeweiligen Fallbeispiele dokumentieren.

Das SDK sollte folgende Beispiele bereitstellen...

1.) Initialisierung des Terminals + Verbindungsaufbau zur Karte.
Dies kann z.b. per PC/SC o. CCID erfolgen.
Fallbeispiele, welche den Zugriff (Read, Write, Pin Auth) dokumentieren.

2.) Eine ausführliche Beschreibung der Command APDU zur Smartcard sollte 
vorhanden sein. Insbesondere zur Kartenkonfiguration. Hierzu ist es von 
Vorteil, wenn du dich mit der ISO-7816/4 befasst. Ebenfalls hilfreich 
ist die MTK Spezifikation, welche eigentlich den APDU's Aufbau mit allen 
möglichen Parametern für Terminal/Smartcard dokumentiert...

In der Regel wirst du dich egal für welches SDK du dich entscheidest mit 
eine engl. sprachigen techn. Beschreibung zur Smartcard herumschlagen 
müßen.

Wie gesagt, läßt du Dich darauf ein, steht dir ein umfangreiches Studium 
bevor, was je nach Aufwand sehr zeitintensiv sein kann.

Gruß
Mario