Hallo an alle, ich möchte SmartCards benutzen, um Benutzer einer PC-Software zu identifizieren: 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. Ein bischen habe ich gelesen und gesucht und bin z.B. auf dieses dev.-Kit gestoßen: http://www.cardomatic.de/start.php?development-kits.php?gclid=CKy_puHv6KMCFdgv3wodeTgn3g (ca. Mitte der Seite) Vorher will ich aber erstmal verstehen, wie das Ganze funktioniert.. viel später soll dann statt PC und Lesegerät mal uC und Lesegerät zusammenarbeiten, und ich würde die Karte auch gerne verwenden, um mich damit am PC (Windows) anzumelden. Meine Fragen: 1) Was für eine Sorte "SmartCard" brauche ich bzw. welche gehen auch nicht, damit man sie nicht einfach mit einem Lese/Schreibgerät kopieren kann? 2) Die PC-Software soll in VB.NET geschrieben werden. Brauche ich eine Windows-API, reicht das .Net-Framework oder wird der Kartenleser irgendwie "nativ" im Windows unterstützt, wie Tastatur oder Maus? 3) Welche Standards/Sorten von Karten/Kartenlesern sind günstig, weit verbreitet und einfach zu handhaben? Vielleicht kommt ja ganz am Ende ein "SmartCard" Artikel hier in der Artikelsammlung raus.. danke vorab schonmal für Eure Hilfe!
Haben soche Karten nicht normal auch ne feste Kartennummer, dann könntest Du ja die Nummer mit nem Geheimen Schlüssel(nur deiner Software auf dem PC bekannt) verschlüsseln und das Ergebniss in den Nutzdatenbereich der Karte schreiben. So kann man die Karte nicht kopieren da der Wert im veränderbaren Bereich nur zu der festen Kartennummer passt.
Schau Dir die mal an, die kann nicht einfach kopieren: http://www.reichelt.de/?;ARTICLE=37029 http://www.reichelt.de/?;ARTICLE=37030
@usuru warum meinst Du, dass man die nicht einfach kopieren kann? Ich hab das Datenblatt nicht ganz verstanden.. aber es würde doch ausreichen, wenn ich eine zweite Karte genauso programmiere..? Eine eindeutige Nummer ist doch nicht drauf, oder?
Ach so, falls das jetzt komisch aussieht, die Antwort von 16:51 war für TEK gemeint.. :-)
Hier gibts was fertiges: http://webshop.scmmicro.com/CHIPDRIVE%25AE-MyKey_detail_18_185.html die passenden Karten: http://webshop.scmmicro.com/_detail_9_181.html Die obigen Links von usuru sind reine Memory-Karten. Hier mal Datenblätter dazu: http://www.idcardmarket.com/download/sle5528.zip http://www.idcardmarket.com/download/sle5542.zip Die lassen sich zwar gegen Veränderung schützen, aber nicht gegen Auslesen. Sicherer wären Prozessorkarten, z.B.: http://www.smartcardzone.com/acos3.asp
Das "Fertige" finde ich ein bischen unpraktisch, weil ich das gerät am PC lassen will, nur die Karte soll ausgetauscht werden (ist da bischen unhandlich), Anders gesagt, bei 10 potentiellen Nutzer vom Programm will ich nicht 10 Lesegeräte in Form von USB-Sticks mitkaufen müssen. Also Frage 1 sieht im Moment so aus: Prozessorkarte geht, reine Memorykarte geht nicht. Geht noch etwas anderes / gibt es Karten ohne Prozessor, aber mit eindeutiger, auslesbarer, unveränderbarer Hersteller-Id?
Hi! Was spricht gegen Transponder? Gruss, Micha
Gibts da im Moment überhaupt welche fertig und gut verfügbar, die noch nicht geknackt und damit duplizierbar sind?
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
@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
Zipzap schrieb: > Das "Fertige" finde ich ein bischen unpraktisch, weil ich das gerät am > PC lassen will, nur die Karte soll ausgetauscht werden (ist da bischen > unhandlich), Anders gesagt, bei 10 potentiellen Nutzer vom Programm will > ich nicht 10 Lesegeräte in Form von USB-Sticks mitkaufen müssen. Mußt Du auch nicht. Die Karten gibts auch in "groß" und lassen sich auch mit anderen Kartenlesern benutzen. > Also Frage 1 sieht im Moment so aus: Prozessorkarte geht, reine > Memorykarte geht nicht. Geht noch etwas anderes / gibt es Karten ohne > Prozessor, aber mit eindeutiger, auslesbarer, unveränderbarer > Hersteller-Id? Was sollen das dann für Karten sein? Naja, die SLE-Karten haben zwar wohl eine eindeutige, auslesbare und unveränderbare Hersteller-ID, nur wird halt auch niemand daran gehindert genau diese ID auf eine andere Blanko-Karte zu kopieren.
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. Das ist aber bei User + PW das selbe in Grün. > ... Warum machst du das nicht einfach mit Benutzername > und Passwort? Z.B. weil eine Karte einschieben schneller geht, als Username + Passwort eintippen, die erwähnte spätere Anwendung mit µC garkeine Tastatur hat, die User ständig die PWs vergessen. Oder, oder... ;-) frank
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.
wow.. jetzt hab ich erstmal zu lesen! :-) Aber ehrlich mal: Ein Jahr Einarbeitung? Ich will doch - laienhaft ausgedrückt - nur folgendes: Ich versehe die Karten mit einer laufenden Nummer (die man nicht direkt auslesen kann). Dann sende ich an die Karte einen String, den sie unter Einbeziehung dieser Nummer verschlüsseln soll und zurückgeben - wenn mein PC das Gleiche herausbekommt (oder in einer vorher ausgerechneten Tabelle stehen hat) - ist es ok, sonst eben nicht. Vielleicht hab ich auch einen Denkfehler, aber ich hatte frühe mal Rockey-Dongles im Einsatz, die irgendwie so funktioniert haben... oder ich hab nen Denkfehler, oder die Welt funktioniert einfach anders.. :-)
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.
>Ich versehe die Karten mit einer laufenden Nummer (die man nicht direkt >auslesen kann). Dann sende ich an die Karte einen String, den sie unter >Einbeziehung dieser Nummer verschlüsseln soll und zurückgeben - wenn >mein PC das Gleiche herausbekommt (oder in einer vorher ausgerechneten >Tabelle stehen hat) - ist es ok, sonst eben nicht. Es kommt immer darauf an, wieviel Sicherheit man haben moechte... Im Smartcard Business herrschen "verschaerfte Anforderungen" ;-) Echte "Freaks" koennen (ich uebertreibe mal hie und da..) - aus dem Stromverbrauch den Schluessel auslesen - aus dem differenziellen Stromverbrauch den Schluessel auslesen - aus den Laufzeiten fuer Choosen-Plaintext Eingaben den Schluessel herausbekommen - aus gezielten Stoerungen des Chips (mit "Amateur-Hausmitteln") Bits umkippen lassen und den Schluessel auslesen - aus der Struktur des Chips den Schluessel auslesen - den Chip schichtweise abtragen und den Schluessel (und "geheime" Kryptoalgos) auslesen Als Gegenmassnahmen gibt es eine Reihe patentierter Tricks... Quellen: -CCC-Kongresse, dedected.org, google -Power Analysis Attacks, Mangard, Oswald, Popp, Springer >Vielleicht hab ich auch einen Denkfehler, aber ich hatte frühe mal >Rockey-Dongles im Einsatz, die irgendwie so funktioniert haben... Bist Du sicher, dass der Dongle sicher ist? Dafuer gibt es die EAL Pruefungen, bei denen unabhaengige Labors die angepriesene Sicherheit unabhaengig pruefen bzw. geprueft haben... >oder ich hab nen Denkfehler, oder die Welt >funktioniert einfach anders.. :-) Naja, die Welt ist differenzierter.... und die Ansprueche verglichen zu frueher hoeher und im Kundengeschaeft eine Tendenz sich nach allen Richtungen hin von Anspruechen freizustellen, aber minimal "state-of-art" zu verwenden :-) ;-) VG, Hans
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
>Die einzige seriöse Aussage wäre, dass man für eine lokal ausgeführte >PC-Software keine sichere Authentifizierung hinbekommt. Wenn man mal davon absieht, dass viele Firmen dazu uebergegangen sind, Appliances anstatt SW zu verticken um dort Manipulationen (auch vertraglich) zu erschweren bzw. die Services/Server ins eigene RZ zu stellen, gaebe es theoretische Methoden genau zu kontrollieren, was auf dem Rechner laeuft und ob er manipuliert wird: Dazu muesste aber ab dem Stromeinschalten ein Sicherheitssystem (z.B. TPM) laufen, was nur authorisierte (fehlerfreie) BS bootet, das BS nur authoriserte (fehlerfreie) Programme ausfuehrt. Das ist bei Spielekonsolen versucht worden... m.E. mit maessigem Erfolg. Ein Sicherheitssystem ist nur so stark wie das schwaechste Glied... Die Benutzerauthenisierung ist eines davon, unter anderem weil ich annehme, dass es da auch um (Benutzer-)Lizenzzahlungen geht und da ist ein gutes gerichtlich verwertbares Authentiserungskonzept hinsichtlich der nachweisbaren Benutzer irgendwie fallentscheidend... VG, Hans PS: Sorry wegen der Rechtschreibung, ich hab' leider nur eine englische Tastatur ;-( PPS: ich arbiete in einer Applianceloesung-orientierten Firma und an die Leistungsfaehigkeit der HW ist die Hoehe der Lizenzzahlung gekoppelt...je mehr Benutzer desto lahmer wird die Kiste, desto schneller wird das groessere Modell ($$) genommen... das kommt auch vielen Firmen entgegen, weil benutzerbasierte Lizenzierung macht nur Stress ;-)
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
Also gut, ich präzisiere mal die Anforderungen: Stellen wir uns einen durchschnittlich begabten PC-Benutzer vor. Der will das Sicherheitssystem mit der Karte umgehen und einem Mitarbeiter "etwas anhängen". Schritt 1) Karte vom Mitarbeiter "unbemerkt kurz ausleihen" Schritt 2) Er besorgt sich im Internet Software für den Kartenleser (der ja auch schreiben kann) und kopiert damit die Daten auf der Karte -> mit der Kopie soll dann keine Autentifizierung möglich sein. Natürlich kann man das (lokal ausgeführte) Programm analysieren, die Stelle suchen, wo das Lesegerät angesprochen wird etc., aber das traue ich dem "Normalbenutzern" eher nicht zu bzw. so sicher muß es nicht sein.
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
Danke Mario, also ich lese heraus, ich brauche eine "asynchrone Smartcard" welche der o.g. sind das bzw. wie erkenne ich sie, wenn ich welche kaufen will? Sind in dem o.g. dev.-Kit welche dabei? Ja und dann brauche ich noch ein möglichst einfaches VB.NET-"Kochrezept", wie ich die Seriennummer unterbringe (sofern sie nicht schon bei der herstellung drauf ist) und wie ich auf die Karte zugreife. Ich hoffe, in dem Dev.-Kit ist das alles drin / werde später da mal anrufen.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.