Flexibele aansturing voor ISO-7816

Faculteit Ingenieurswetenschappen Departement Elektrotechniek – ESAT KATHOLIEKE UNIVERSITEIT LEUVEN

Flexibele aansturing voor ISO-7816

Eindwerk voorgedragen tot het behalen van het diploma van Master in de Ingenieurswetenschappen Elektrotechniek (ICT), optie ICT-Telecommunicatie en Telematica (Burgerlijk elektrotechnisch ingenieur)

Jan-Pieter Jacobs Promotor:

Prof. Dr. Ir. Ingrid Verbauwhede Dagelijkse begeleiding:

Wolf Benedikt Gierlichs Ir. Elke De Mulder

2008 – 2009

c Copyright K.U.Leuven

Zonder voorafgaande schriftelijke toestemming van zowel de promotor(en) als de auteur(s) is overnemen, kopiëren, gebruiken of realiseren van deze uitgave of gedeelten ervan verboden. Voor aanvragen tot of informatie i.v.m. het overnemen en/of gebruik en/of realisatie van gedeelten uit deze publicatie, wendt U tot de K.U.Leuven, Departement Elektrotechniek – ESAT, Kasteelpark Arenberg 10, B-3001 Heverlee (België). Telefoon +32-16-32 11 30 & Fax. +32-16-32 19 86 of via email: [email protected]. Voorafgaande schriftelijke toestemming van de promotor(en) is eveneens vereist voor het aanwenden van de in dit afstudeerwerk beschreven (originele) methoden, producten, schakelingen en programma’s voor industrieel of commercieel nut en voor de inzending van deze publicatie ter deelname aan wetenschappelijke prijzen of wedstrijden.

c Copyright by K.U.Leuven

Without written permission of the promotors and the authors it is forbidden to reproduce or adapt in any form or by any means any part of this publication. Requests for obtaining the right to reproduce or utilize parts of this publication should be addressed to K.U.Leuven, Departement Elektrotechniek – ESAT, Kasteelpark Arenberg 10, B-3001 Heverlee (Belgium). Tel. +32-16-32 11 30 & Fax. +32-16-32 19 86 or by email: [email protected]. A written permission of the promotor is also required to use the methods, products, schematics and programs described in this work for industrial or commercial use, and for submitting this publication in scientific contests.

i

Voorwoord In dit voorwoord wens ik al de mensen te bedanken die een bijdrage hebben geleverd aan het tot stand brengen van deze thesis. Hierbij denk ik in het bijzonder aan Prof. Verbauwhede, voor het aanreiken van dit interessante onderwerp. Verder wil ik ook mijn dagelijkse begeleiders Elke De Mulder en Benedikt Gierlichs bedanken voor alle hulp die zij mij gaven bij het ontwikkelen van het systeem dat deze thesis beschrijft. Zonder hun hulp had deze thesis niet geweest wat ze nu is. Ik bedank ook alle andere mensen die me met raad en daad onderweg hebben bij gestaan en mijn ouders en vrienden voor hun steun, begrip, nalezen, enzovoorts. Als laatste wil ik ook speciaal mijn vriendin Marieke danken voor het onbegrensde geduld dat ze met me gehad heeft als het even niet zo vlot ging.

ii

Abstract Deze thesis heeft tot doel het beschrijven van een flexibele aansturing voor smart cards die voldoen aan ISO 7816-3 en het T=0 protocol gebruiken. Om de lezer toe te laten zich een duidelijk beeld te vormen van de context waarin deze thesis past, geven we eerst een algemene inleiding over cryptografie, smart cards en de veiligheid hiervan. Hierna gaan we in detail in op de delen van ISO 7816 die relevant zijn voor dit project. Na deze inleiding beschrijven we de vereisten voor de oplossing van dit project: • De mogelijkheid om de kaart aan een andere klokfrequentie te laten werken dan deze die de kaartlezer voorziet. Hierbij moet de communicatie transparant zijn; een normale kaart en kaartlezer moeten zonder aanpassingen kunnen werken. Dit heeft als doel het verbeteren van de nauwkeurigheid van metingen in het kader van vermogenanalyse op de kaart. • De mogelijkheid om de kaart van de “standaard” klokfrequentie te schakelen naar een hogere kloksnelheid. Dit moet op de klokcyclus nauwkeurig kunnen gebeuren. Deze vereiste maakt het injecteren van fouten in bepaalde instructies en data mogelijk. Vervolgens beschrijven we de oplossingsmethode die we gebruikten. De eerste was een bitgebaseerde oplossing. Deze oplossing bleek niet te voldoen aan de vooropgestelde eisen. De tweede oplossing nam een bytegebaseerde aanpak, en deze slaagde wel. Door het interpreteren van ATR en PPS kan ons circuit de communicatie blijven volgen, ook al veranderen ATR en PPS de communicatieparameters. Als de kaart aan een lagere klokfrequentie werkt, kunnen er time-outs optreden. Omdat ons circuit het T=0 protocol interpreteert, kan het waar mogelijk time-outs opvangen door een WTX byte te zenden naar de kaartlezer. Hierdoor reset deze de time-out teller. Door het op de voet volgen van het T=0 protocol weet het circuit tevens wanneer de kaart juist begint met de berekening, en kan dus ook heel accuraat het kloksignaal omschakelen naar een hogere frequentie. De simulaties tonen aan dat deze aanpak werkt, en kan gebruikt worden als framework voor ander foutinjectie-aanvallen. Verder berekenen we dat de bovengrens voor de verhouding tussen de frequenties van de lezerklok en kaartklok 436 is. Tot onzer grote spijt zijn we echter wegens tijdstekort niet toegekomen aan het fysiek testen van onze VHDL code op FPGA. De uitdagingen voor de toekomst zijn dus het implementeren van de beschreven circuits in hardware, het integreren van het T=1 (of andere) protocollen en het uitbreiden van het ontworpen framework met andere nevenkanaal- en foutinjectieaanvallen. iii

Inhoudsopgave Voorwoord Abstract Inhoudsopgave Lijst van symbolen Lijst van figuren Lijst van tabellen 1 Inleiding 1.1 Cryptografie . . . . . . . . . . . . . 1.2 Smart cards . . . . . . . . . . . . . 1.3 Veiligheid van smart cards . . . . . 1.4 Deze thesis . . . . . . . . . . . . . 2 Technische achtergrond 2.1 Fysische kenmerken . . . . . . . . 2.2 Elektrische kenmerken . . . . . . . 2.3 Fysieke laag . . . . . . . . . . . . . 2.4 Tussenlaag . . . . . . . . . . . . . 2.5 Datalinklaag: T=0 . . . . . . . . . 3 Probleemstelling 3.1 Verschillende Klokfrequenties . . . 3.2 Variatie op externe klokfrequentie . 3.3 Beperkingen . . . . . . . . . . . . . 4 Oplossing 4.1 Levelshifting . . . . . . . . . . . . 4.2 Oplossing 1: Bitstream . . . . . . . 4.3 Oplossing 2: Bytestream . . . . . . 5 Resultaten 5.1 Simulatieresultaten . . . . . . . . . 5.2 Theoretische beschouwingen . . . . 5.3 Praktische resultaten . . . . . . . . 6 Conclusies en Perspectieven 6.1 Perspectieven . . . . . . . . . . . . 6.2 Conclusies . . . . . . . . . . . . . . Bibliografie A Simulatieresultaten A.1 Algemeen . . . . . . . . . . . . . . B Computer hulpmiddelen

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

iv

ii iii iv vii ix x 1 1 5 5 8 9 9 10 13 15 23 29 29 30 31 33 33 35 39 47 47 49 50 51 51 52 53 55 55 60

B.1 Versiemanagementsysteem B.2 Analoge simulatie . . . . . B.3 VHDL simulatie . . . . . B.4 Typesetting . . . . . . . . C Nevenontwikkelingen C.1 Xpdfwrapper.lua . . . . . C.2 signalmaker.lua . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

v

60 60 60 61 62 62 62

vi

Lijst van symbolen ’X’ AkB bx-by A AUX BWI BWT CLA CLK ClkC ClkCdiv ClkR ClkRdiv CWI CWT D DI ETU fklok F FI FIFOC FIFOR GetRespons GND I/O IFSC INS IOCin IOCout IORin IORout N P1-3 pR pW

Hexadecimaal getal X waarbij X tussen ’0’ en ’F’ ligt Concatenatie van de 2 bitstrings A en B Opeenvolging van bits bx tot by Laag-impedant outputniveau Extra, momenteel ongebruikt contact op de kaart Codering van BWT in TB(i) met i>2 Block Waiting Time Klassebyte in T=0 instructieheader Klok Kloksignaal aan de kaartzijde Kloksignaal aan kaartzijde na deling door klokdeler Kloksignaal aan de lezerszijde Kloksignaal aan lezerszijde na deling door klokdeler Codering van CWT in TB(i) met i>2 Character Waiting Time Bitrateaanpassingsfactor Nibble die D codeert in TA(1) Elementary Time Unit; duur van 1 bit Klokfrequentie Klokdelingsratio Nibble die F codeert in TA(1) FIFO die van de kaart zijn input krijgt FIFO die van de kaartlezer zijn input krijgt Commando dat de kaartlezer moet zenden om data van de kaart te ontvangen. Referentiepotentiaal Input/Output Information Field Size on Card Instructiebyte in T=0 instructieheader Input van de FPGA aan de kaartzijde Output van de FPGA aan de kaartzijde Input van de FPGA aan de lezerszijde Output van de FPGA aan de lezerszijde Extra guardtime (in TC(1)) Argumentbytes in de T=0 instructieheader Leespointer van een geheugenblok Schrijfpointer van een geheugenblok vii

PB PCK PPS0 PPS1-3 PPSS RE RE int RFU SW1,2 T0 T1-15 T TA,B,C,D TCK TS U UI VCC WE WE int WI WTX WWT XI Z

Procedurebyte in het antwoord op T=0 instructieheader Controlekarakter in PPS Structureel karakter in PPS PPS karakters Startkarakter in PPS Read-enable van een geheugenblok Interne read-enable van een geheugenblok Reserved for Future Usage Statuswoorden: Antwoord op volledige T=0 TPDU Structureel karakter in ATR Historische karakters in ATR Protocolnummer Interfacekarakters in ATR Controlekarakter in ATR Startkarakter in ATR Klasse van de kaart Codering van U in TA(i) met i>2 Voedingsspanning Write-enable van een geheugenblok Interne write-enable van een geheugenblok Codering van WWT in TC(2) ’60’ gestuurd door kaart nadat de hele TPDU ontvangen is, om time-out te vermijden bij een lange berekening Work Waiting Time Codering van X in TA(i) met i>2 Hoog-impedant outputniveau

viii

Lijst van figuren 1.1

Cryptografische basisbewerkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.12

Fysische kenmerken van de een ID-1 smart card en 2 wegs I/O communicatie bus . . . . . . . . . . . . Activerings- en deactiveringssequentie . . . . . . . Toleranties op het bitinterval . . . . . . . . . . . . Bytestructuur van ’3B’ in 2 conventies . . . . . . . Verloop van communicatie volgens ISO 7816 . . . . Structuur van de ATR . . . . . . . . . . . . . . . . Timing diagram van het T0 karakter . . . . . . . . Mechanisme van de PPS . . . . . . . . . . . . . . . Diagram voor T=0 protocol . . . . . . . . . . . . . Structuur van een T=0 TPDU . . . . . . . . . . . Voorbeelden T=0 protocol . . . . . . . . . . . . . . Voorbeelden T=0 protocol . . . . . . . . . . . . . .

. . . . . . . . . . . . .

10 12 13 14 15 15 16 17 21 24 24 27 28

3.1 3.2

Algemene setup om verschillende kloksnelheden toe te laten . . . . . . . . . . . . . Schets van laadstromen bij verschillende klokfrequenties . . . . . . . . . . . . . . .

29 30

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13

Diagram voor levelshifting . . . . . . . . . . . . . . . . . . Levelshifting circuit . . . . . . . . . . . . . . . . . . . . . Bitstream aanpak . . . . . . . . . . . . . . . . . . . . . . . Voorstelling van het geheugen van het FIFO-blok . . . . . Processen in FIFO blok . . . . . . . . . . . . . . . . . . . Voorbeeld van buffering door FIFO . . . . . . . . . . . . . Basisidee van de bytegebaseerde aanpak . . . . . . . . . . Volledig Systeem . . . . . . . . . . . . . . . . . . . . . . . Schets van de bemonsteringstijdstippen . . . . . . . . . . Voorbeeld van overbemonstering . . . . . . . . . . . . . . Toestanden en subtoestanden in FSMC en FSMR . . . . . T=0 protocol zoals ge¨ımplementeerd in het controllerblok WTX injectie systeem . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

34 35 35 36 37 38 39 40 40 41 43 45 46

5.1 5.2

Maximum voor ETU’ bij opeenvolgende bytes . . . . . . . . . . . . . . . . . . . . . Maximum voor ETU’ bij commando en antwoord . . . . . . . . . . . . . . . . . . .

49 50

A.1 Voorbeeld van simulatie data van hele circuit . . . . . . . . . . . . . . . . . . . . .

56

ix

posities van . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

de contacten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

2

Lijst van tabellen 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18

Contacten op de smart card en hun functie Smart card klassen volgens ISO 7816-3 . . . Wired-AND logica . . . . . . . . . . . . . . Conventies . . . . . . . . . . . . . . . . . . Codering van T0 . . . . . . . . . . . . . . . Codering van TD(i) . . . . . . . . . . . . . Codering van TA(1) . . . . . . . . . . . . . Codering van F in FI . . . . . . . . . . . . . Codering van D in DI . . . . . . . . . . . . Codering van TA(2) . . . . . . . . . . . . . Codering van XI . . . . . . . . . . . . . . . Codering van UI . . . . . . . . . . . . . . . Codering van PPS0 . . . . . . . . . . . . . . Codering van PPS2 . . . . . . . . . . . . . . Verschillende mogelijke protocollen . . . . . Waarde Procedure Byte . . . . . . . . . . . Statuswoorden volgens ISO 7816-3 . . . . . 4 gevallen ivm. data-aanwezigheid . . . . .

x

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

10 11 12 14 17 18 18 18 18 19 19 19 22 22 23 24 25 26

Hoofdstuk 1

Inleiding Samenvatting Het doel van dit hoofdstuk is het geven van de context van waaruit we vertrekken, wat de basis vormt voor wat deze thesis verderop beschrijft. Hoofdstuk 2 beschrijft veel van de hier aangeraakte topics in meer detail. Hoofdstuk 3 verduidelijkt de doelstellingen en beperkingen waaraan het ontwerp moet voldoen. Hoofdstuk 4 verklaart en verantwoordt de aanpak die we hiervoor volgden. In hoofdstuk 5 overlopen we de resultaten die we doorheen deze thesis bereikten. Hoofdstuk 6 trekt besluiten uit de resultaten van het project en stelt enkele perspectieven op toekomstige uitdagingen. In dit hoofdstuk geeft sectie 1.1 een kort overzicht over cryptografie en zijn toepassingen in het alledaagse leven. Sectie 1.2 verklaart de populariteit van smart cards vanuit deze noden voor cryptografie en elektronische identiteitsbewijzen. Hierna stelt sectie 1.3 de veiligheid van deze kaart gebaseerde oplossingen in vraag. De laatste sectie 1.4 van dit hoofdstuk beschrijft wat deze thesis bijdraagt in heel deze context.

1.1

Cryptografie “Cryptography is the study of mathematical techniques related to aspects of information security such as confidentiality, data integrity, entity authentication, and data origin authentication.” [1, Hoofdstuk 1,p4]

1.1.1

Inleiding op cryptografie

Cryptografie verschijnt in steeds meer toepassingen. Beveiligde verbindingen tussen browser en webserver, encryptie van GSM-verkeer, veilig opslaan van persoonsgevens, elektronische handtekeningen, . . . allemaal gebruiken ze een cryptografische techniek om data te beveiligen tegen onderschepping door derden, tegen vervalsing van identiteit en onwettige wijziging van gegevens. Figuur 1.1a toont het algemene principe van encryptie: met een sleutel wordt een klare tekst versleuteld en met een andere sleutel kan de bekomen cijfertekst weer ontcijferd worden. In 1

1. Inleiding

Encryptiesleutel

Klare tekst

Encryptie

Cijfertekst Klare Tekst

Handtekening algoritme

Klare Tekst

Decryptiesleutel

Klare tekst

Handtekening OK! Decryptie

Controle Handtekening

Cijfertekst Klare tekst onveranderd

(a) Versleuteling

(b) Elektronische handtekening

Figuur 1.1: Cryptografische basisbewerkingen

het geval van 2 dezelfde sleutels heet dit symmetrische encryptie. Wanneer de encryptiesleutel publiek beschikbaar is en de bestemmeling de enige is die over de decryptiesleutel beschikt heet dit assymmetrische encryptie (In het engels public key cryptography). Zo kan iedereen een geëncrypteerd bericht sturen naar de bestemmeling, maar is hij de enige die het bericht kan ontcijferen. Figuur 1.1b toont het principe van een elektronische handtekening. De elektronische handtekening is extra data berekend uit de klare tekst en de sleutel van de zender, op zo een manier dat enkel iemand met de sleutel van de zender een goede handtekening kan zetten, en dat de ontvanger deze kan controleren. Deze elektronische handtekening is volledig anders dan een handtekening op papier, ze is immers afhankelijk van de getekende data. Een handtekening op papier steunt enkel op de uniekheid van de handtekening. Dit kan niet werken voor elektronische handtekeningen, vermits elektronische data exact kunnen gekopieerd worden, en de kopies niet onderscheidbaar zijn van de originelen. De elektronische handtekening steunt op de uniekheid van de data én de handtekening samen. Algemeen gesteld gaat cryptografie over het verschuiven van de beveiliging van veel informatie naar het beveiligen van een kleine hoeveelheid data. Meer algemeen zijn de verschillende “basisbewerkingen” van cryptographie de volgenden: Data vercijfering Het encrypteren van een klare tekst met een sleutel zodat derden deze niet kunnen gebruiken. (bv. sturen van vercijferde e-mails: niemand die niet de juiste sleutel heeft kan de inhoud van de mail lezen). Data authenticiteit Het verzekeren van de integriteit van data. Op deze manier worden veranderingen van de klare tekst duidelijk: de digitale handtekening klopt niet meer. (Bv. getekende email: als iets verandert in de inhoud van de mail zal de digitale handtekening niet meer kloppen. Vermits een sleutel vereist is bij het zetten van zulk een handtekening kan de eventuele onderschepper deze niet opnieuw zetten op de veranderde data). Identificatie Via het integreren van de bovenstaande technieken in protocollen, is het mogelijk de identiteit van toestellen en personen te bevestigen. Voor een veel uitgebreidere discussie van cryptographie, zie [1]. 2

Cryptografie

Voorbeeld 1.1. Een backup van enkele gigabytes moet geheim blijven. Na versleuteling met een cryptografisch algoritme moet enkel nog de sleutel van enkele karakters geheim blijven, terwijl iedereen de versleutelde data mag zien. Natuurlijk steunt nu de hele veiligheid van informatie op de veiligheid van de sleutel. De sleutel is veel korter dan de data die hij vercijfert. Toch moet hij lang genoeg zijn om voldoende veiligheid te bieden. Dit wil zeggen dat de sleutel niet makkelijk breekbaar is. Het volgende voorbeeld verduidelijkt dit intu¨ıtief, en de volgende sectie behandelt veiligheid op een formelere wijze. Voorbeeld 1.2. Neem bijvoorbeeld een cijferslot, met telkens 10 cijfers en 3 ringen, dan zijn er slechts 103 = 1000 mogelijke combinaties. Voegen we hier 1 ring aan toe dan zijn er reeds 10000 mogelijkheden. Het kraken van het slot met 3 ringen door alle combinaties uit te proberen neemt niet veel tijd in beslag; het kraken van het slot met 4 ringen neemt echter 10 keer meer tijd in beslag. Dit is net het zelfde bij cryptografische sleutels.

1.1.2

Veiligheid van een cryptografisch systeem

De veiligheid van een cryptografisch systeem is opgebouwd uit: 1. 2. 3. 4.

Veiligheid Veiligheid Veiligheid Veiligheid

van van van van

het algoritme het protocol de implementatie het cryptografisch systeem

De veiligheid van een element steunt op de veiligheid van alle voorgaande blokken. Zo kan geen veilig protocol gebaseerd zijn op zwakke algoritmes. Eveneens kan een cryptografisch systeem niet veilig zijn als de implementatie niet veilig is. Dit geld dus niet in omgekeerde zin: een implementatie die een veilig protocol gebruikt, is niet noodzakelijk veilig. Van de elementen in de opsomming zijn de eerste 2 puur wiskundig: enkel zwaktes in de protocollen en algoritmes worden bekeken. Het zijn zwakheden in deze “veiligheden” die de cryptanalyse probeert uit te buiten. De derde is echter niet (enkel) afhankelijk van het gebruikte algoritme of protocol. In algemene zin zijn fouten in de implementatie van een cryptografisch systeem het doel van aanvallen als nevenkanaalaanvallen (zie 1.3.2). De vierde, de veiligheid van een cryptografisch systeem zelf, is het doelwit van social engenieering, phising, spoofing, enzovoort. Zo kan een systeem gebaseerd op veilige algoritmes, protocollen en implementatie toch risico lopen, bijvoorbeeld omdat de gebruikers hun geheimen vrijgeven in een antwoord op een phising mail. Hoe groot de veiligheid van een blok is, kan uitgedrukt worden in verschillende maten. De eisen die deze stellen zijn van sterk naar zwakker beschreven in de volgende paragrafen. Onconditionele veiligheid Onconditionele veiligheid is een garantie op de veiligheid vanuit een informatietheoretisch standpunt. Deze garantie zegt dat niemand, met hoeveel rekenkracht dan ook, de code kan kraken, omdat er simpelweg niet genoeg informatie voorhanden is. Voor 3

1. Inleiding

symmetrische systemen vereist dit bijvoorbeeld dat de lengte van de sleutel minstens even groot is de lengte van de te encrypteren data.

Bewijsbare veiligheid Bij bewijsbare veiligheid steunt de veiligheid van het systeem of algoritme op de veiligheid van een gekend, tot noch toe onoplosbaar probleem in de getaltheorie (zoals bijvoorbeeld het oplossen van een discreet logaritme1 ) De voorwaarde hierbij is natuurlijk dat dit “moeilijke” probleem niet opgelost wordt.

Computationele veiligheid Hierbij is er niet een echt bewijs voor de veiligheid. Een systeem is computationeel veilig als de de rekenkracht en -tijd die ervoor nodig is groter is dan deze van de veronderstelde tegenstander. Het is duidelijk dat computationele veiligheid verandert doorheen de tijd. Sommige problemen die 10 jaar geleden “onbreekbaar” waren, zijn met moderne PC’s in enkele seconden op te lossen. Dit is tevens de reden dat de aanbevolen sleutellengtes voor cryptographische systemen groter wordt2 .

1.1.3

Cryptanalyse

Cryptanalyse is net het tegenovergestelde van de cryptografie: het is de wetenschap die probeert cryptografische algoritmes of systemen te kraken. Hierbij maakt de aanvaller gebruik van allerlei zwaktes in de gebruikte algoritmes, in de implementatie van die algoritmes of in hun inpassing in een systeem. Enkele veel voorkomende klassen van cryptanalyse zijn: Gekende klaartekst aanval Hierbij beschikt de aanvaller een aantal gekende klare teksten, en hun vercijferde versie. Uit de correlatie tussen de klaar- en cijfertekst kan de aanvaller een sleutel afleiden. Gekozen klaartekst aanval Als het algoritme kwetsbaar is, kan het zijn dat door de klaartekst slim te kiezen, het algoritme de sleutel vrijgeeft. Gekozen cijfertekst aanval Bij deze aanval probeert de aanvaller op basis van enkel de decryptie het algoritme te breken. Hij probeert een aantal speciaal gekozen cijferteksten in de hoop dat dit leidt tot het vrijgeven van de sleutel. Voorbeelden van gekraakte zwakke algoritmes zijn de hashfuncties SHA-1 [2] en MD5 [3]. Dit is een groot probleem, want veel cryptografische systemen zijn op deze hashfuncties gebaseerd. Een voorbeeld van een geslaagde aanval op een cryptografisch systeem omdat het een zwak algoritme (MD5) gebruikt, is deze die onderzoekers aan T.U.Eindhoven aanwendden om een vals CA-certificaat (Certification Agency certificaat) te construeren. Alle browsers vertrouwen dit certificaat, en alle certificaten die erdoor getekend zijn. Op deze manier kan hun server in een beveiligde verbinding zich uitgeven als een server van eender welke organisatie [4]. 1

Zie http://www.rsa.com/rsalabs/node.asp?id=2186 voor een overzicht van moeilijke problemen (gecontroleerd op 25/05/09) 2 www.keylength.com beschrijft de aanbevolen sleutellengtes voor cryptografiei(gecontroleerd op 25/05/09

4

Smart cards

1.2

Smart cards

Het van buiten kennen van sleutel van 2048 bits is onbegonnen werk. Dit is onder meer waarom smart cards zo populair zijn. Smart cards zijn in de context van deze thesis chipkaarten zoals de Belgische elektronische identiteitskaarten, bankkaarten, SIS kaarten, . . . Smart cards kunnen elektronische sleutels bijhouden en cryptografische bewerkingen uitvoeren, zoals bijvoorbeeld de Belgische elektronische identiteitskaart3 doet. Hierdoor verschuift de veiligheid van een elektronische sleutel (een reeks bits) naar de veiligheid van de kaart. De eerste kaarten dienden gewoon als identiteitsbewijs, zoals de oude identiteitskaart, die door visuele inspectie van een bevoegde persoon te valideren is. Voor geheime sleutels is dit niet veilig, namelijk iedereen die de kaart in handen krijgt, kan de sleutel gewoon aflezen en kopiëren. Verder is dit niet handig vermits veilige cryptografische sleutels zeer lang zijn, en omdat de kaart zelf geen cryptografische bewerkingen kan uitvoeren. Met het opkomen van steeds meer informatiesystemen werd er overgestapt op kaarten met een magnetische strip. Op deze strip passen 1288 bits (met controlebits) [5]. Dit vereenvoudigt het uitlezen van de sleutel; met één haal door een kaartlezer is de data uitgelezen. Een groot nadeel is dat zulke kaarten eenvoudig te kopiëren zijn; de kaart is volledig passief en kan niet beslissen of hij de data al dan niet vrijgeeft. Achteraf kan de uitgelezen data eenvoudig op een andere kaart geschreven worden. Toch is deze technologie zelfs vandaag nog de meest gebruikte voor kredietkaarten in de Verenigde Staten en vele andere niet-Europese landen [6]. In Europa is de magnetische strip echter in onbruik geraakt voor belangrijke toepassingen als bankkaarten en dergelijken. Voor deze toepassingen is een chipkaart beter geschikt. Zwak beveiligde kaarten kunnen nog steeds gewoon hun geheime data vrijgeven, of gebruikt worden zonder PIN-code. Vele landen gebruiken ook chipkaarten voor financiële doeleinden die niet beveiligd zijn door een pincode [6]. De meeste Europese kaarten vereisen echter een PINcode voor ze hun gegevens vrijgeven. Deze kaarten kunnen geheime informatie opslaan en cryptografische bewerkingen uitvoeren. Dit zijn de smart cards die nu in gebruik zijn en waar deze thesis over gaat.

1.3

Veiligheid van smart cards

Vermits smart cards belangrijke data bevatten en onder meer identiteitsgegevens verwerken, is veiligheid een cruciaal punt. De kaart mag immers nooit de foute persoon aanduiden als rechtmatige gebruiker, mag nooit zomaar vertrouwelijke (of foute) gegevens versturen, . . . Deze sectie beschrijft welke gevaren er voor smart cards op de loer liggen en hoe smart cards getest kunnen worden zodat deze gevaarlijke situaties niet optreden of dat tenminste de gevolgen beperkt zijn. 3

http://eid.belgium.be

5

1. Inleiding

1.3.1

Fysieke directe aanval

Het duidelijkste zwakke punt van de smart card is natuurlijk het design. Als de smart card niet gebouwd is met veiligheid in het achterhoofd, kan deze niet-gemachtigde personen toelating geven tot privé-toepassingen. Voorbeelden hiervan zijn bijvoorbeeld protonkaarten. Als deze verloren zijn, kan de oneerlijke vinder het bedrag dat nog op de kaart staat gebruiken. Hierop is het systeem natuurlijk voorzien, in de zin dat het ontworpen is om enkel kleine bedragen zonder PIN-code te kunnen betalen. Dit model is volledig onaanvaardbaar voor bijvoorbeeld het tekenen van documenten of beheer van een bankrekening. Dit impliceert niet dat kaarten die een PIN-code vereisen inherent veilig zijn. Zelfs als de kaart een PIN-code vraagt en de gebruiker deze correct gebruikt, kan dit veiligheidsrisico’s opleveren in een niet-vertrouwde omgeving. Slecht ontworpen bankterminals kunnen PIN-codes en andere gevoelige data aan de buitenwereld blootstellen. Zo slaagden onderzoekers aan de universiteit van Cambridge er in 2008 in betaalterminals te kraken met een paperclip en een ijzerdraad [7]. Het systeem waarin de kaart functioneert moet dus veilig zijn en nog geen gevoelige data naar buiten lekken. Dit is onder andere ook een zorg bij PC-toepassingen die smart cards gebruiken. Veel standaard-kaartlezers hebben immers geen ge¨ıntegreerd toetsenbord. De gebruiker geeft de PIN-code in via het toetsenbord van de PC. Zo kunnen malware zoals Trojaanse paarden of keyloggers de gevoelige data opslaan en/of doorsturen. Hieruit blijkt dat het ontwerp van smart card systemen voldoende aandacht moet schenken aan integriteit en betrouwbaarheid van de implementatie.

1.3.2

Side channel attacks & Fault injection

Side channel attacks De voorgaande sectie bekeek enkel de klassieke kant van de zaak: de signalen die bescherming nodig hebben, zijn datasignalen. Deze hebben de bedoeling om informatie over te dragen. Er zijn echter nog andere kanalen langs waar informatie naar buiten kan lekken. Side channel attacks (of nevenkanaalaanvallen in het Nederlands) proberen deze signalen uit te buiten om zo toch gevoelige informatie te verkrijgen. Hier is dus de veiligheid van de implementatie van belang. Een mogelijke benadering hiervan is het meten van het vermogen dat een smart card op een bepaald moment aan de voeding onttrekt. De nauwkeurige meting en timing van deze meting is dus van het grootste belang. Deze vermogenmeting gebeurt terwijl de kaart een aantal keer dezelfde bewerking met de zelfde sleutel uitvoert op verschillende data. Na statistische analyse op de vermogen meting kan dit ons de gezochte gevoelige data (zoals een encryptie sleutel) opleveren [8]. Fault injection attacks Microprocessoren zijn gevoelig aan externe invloeden die tijdelijke of permanente fouten introduceren. Dit verschijnsel werd voor het eerst vastgesteld toen chips om zonder aanwijsbare redenen ongewenst gedrag vertoonden. Onderzoek wees uit dat in de verpakking van de chips een erg lage concentratie radioactief materiaal zat. De straling die die deeltjes bij hun verval produceerden was genoeg om de logica in de chips te be¨ınvloeden [9]. 6

Veiligheid van smart cards

De auteur van [10] beschrijft naast ionizerende straling deze andere manieren om fouten in chips te induceren: Variaties in voedingsspanning Variaties in de voedingsspanning tijdens de uitvoering van een instructie kunnen ervoor zorgen dat de processor de instructie fout interpreteert of ze overslaat. Deze methode is diepgaand onderzocht en achter gesloten deuren gebruikt in de smart card industrie, maar komt weinig voor in de open literatuur. Voorbeeld 1.3 geeft een voorbeeld van dit type aanval. Temperatuur Circuitmakers definiëren een boven- en ondergrens op de temperatuur waarbinnen hun circuits correct werken. Het doel hier is om de temperatuur van de chip te verlagen tot onder de ondergrens, of te verhogen tot boven de bovengrens. Hierbij beginnen de chips ongewenst gedrag te vertonen dat uitgebuit kan worden (zie voorbeeld 1.4). Wit licht Alle elektrische circuits zijn gevoelig aan licht ten gevolge van foto-elektrische effecten. De stroom ge¨ınduceerd door de fotonen kan dienen om fouten te induceren als het circuit voor een korte periode aan intens licht wordt blootgesteld. Dit kan gebruikt worden als een goedkope manier van foutinjectie. Laser Een laser kan een grote variëteit aan fouten produceren en kan gebruikt worden om fouten ge¨ıntroduceerd door deeltjesversnellers te simuleren . Het geproduceerde effect is gelijkaardig aan dat van wit licht, maar het voordeel van laser tegenover wit licht is de directionaliteit die toelaat om precies een klein gebiedje van het circuit te viseren. X-stralen en ionenbundels X-stralen en ionenbundels kunnen ook dienen als foutbronnen (wel minder voorkomend). Deze hebben het voordeel dat de foutaanvallen kunnen gebeuren zonder de verpakking van de chips te verwijderen. Variaties op het extern kloksignaal Variaties op het extern kloksignaal kunnen voor een foute uitlezing van data of een fout in de instructievolgorde (zie voorbeeld 1.5). Voorbeeld 1.3. Het schrijven in permanent geheugen in een smart card vereist een voldoende hoge voedingsspanning en -stroom. Als deze door controle van het vermogen (geleverd door de voeding aan de kaart) te klein is, kunnen fouten in de schrijfbewerking optreden. Als dit bijvoorbeeld gebeurt bij het testen van een PIN-code, kan de kaart de teller die het aantal pogingen bij houdt niet verhogen, vermits dit in het permanente geheugen staat. Op deze manier kan de aanvaller PIN-codes blijven proberen, zonder dat de kaart blokkeert na 3 pogingen. Voorbeeld 1.4. Bij temperatuuraanvallen op smart cards (nooit gedocumenteerd in de open literatuur volgens de auteur van [10]) kunnen twee effecten optreden: willekeurige veranderingen in RAM-cellen ten gevolge van verwarming en de uitbuiting van het feit dat de temperatuursgrenzen voor lees- en schrijfbewerkingen niet samenvallen voor de meeste niet-vluchtige geheugens. Door de temperatuur aan te passen naar een waarde waar de schrijfbewerkingen werken, maar de leesbewerkingen niet, of andersom, kunnen een aantal aanvallen uitgevoerd worden. Voorbeeld 1.5. Een eerste gevolg dat de variatie van de kloksnelheid kan hebben is dat het circuit een waarde probeert uit te lezen van een databus voordat het geheugen de tijd heeft de gevraagde waarde op de bus te zetten. Hierdoor neemt de processor van de kaart foute data van de databus. Verder kan dit ook tot gevolg hebben dat het circuit de uitvoering van de volgende instructie start terwijl de huidige instructie nog niet afgelopen is. Als de huidige instructie 7

1. Inleiding

dan een conditionele conditie is, die beslist welke tak in het programma van de processor te volgen, kan dit leiden tot het volgen van een foute tak. Als de conditionele instructie moest controleren of de gebruiker de rechtmatige gebruiker is, zal eender wie, zonder authenticatie, de kaart kunnen gebruiken.

1.4

Deze thesis

Deze thesis heeft tot doel een flexibele aansturing te maken voor smart cards. Die aansturing verwezenlijkt 2 elementen aangehaald in bovenstaande paragrafen: Side channel: Vermogenanalyse De vermogenanalyse wordt veel nauwkeuriger als de kaart aan een lagere klokfrequentie werkt. Zo kunnen we met dezelfde meettoestellen nauwkeurigere resultaten bereiken. De reden daarvoor is dat bij een lagere klokfrequentie de stromen getrokken door individuele bewerkingen meer tijd krijgen om uit te sterven. Dit laat ons dus toe om beter het vermogenverbruik per instructie te zien, in plaats van een gemiddelde van een aantal instructies samen. Daarom zoeken we een oplossing waarbij we toelaten dat de kaart kan werken aan eender welk extern kloksignaal (binnen bepaalde grenzen). Dit willen we echter op zo een manier doen dat we de kaartlezer niet moeten aanpassen, dus gewoon een standaard-kaartlezer kunnen gebruiken. Fout injectie: Klok glitch Deze thesis implementeert de injectie van fouten in de kaart door variaties op het kloksignaal. Hiertoe laten we de kaart toe om tussen 2 kloksnelheden te schakelen. Om een bepaalde bewerking in de uitvoering van een instructie aan te vallen, gebeurt dit een bepaalde tijd na de start van de uitvoering van de instructie, gedurende een bepaalde tijd.

8

Hoofdstuk 2

Technische achtergrond Samenvatting Dit hoofdstuk beschrijft de uitgangspositie van deze thesis. Het dient als een meer technische schets van de smart cards die voldoen aan ISO 7816-1 tot 7816-4. De opbouw van dit hoofdstuk volgt de logische indeling van een zeer laag fysiek niveau van communicatie, tot en met de datalink laag, de hoogste laag die in deze thesis van belang is. In sectie 2.1 beschrijven we eerst de puur fysische kenmerken van de smart cards. Sectie 2.2 gaat vervolgens in op de verschillende elektrische contacten en de bijbehorende signalen die van buiten af toegankelijk zijn op de kaart. Hierna volgt een uiteenzetting over de communicatie zelf, die ongeveer het OSI-lagen model volgt. Sectie 2.3 beschrijft de fysieke communicatielaag, terwijl secties 2.4 en 2.5 respectievelijk het tussenniveau en de datalinklaag beschrijven. Deze laatste sectie beschrijft enkel het T=0 protocol, vermits andere protocollen zoals T=1 niet in deze thesis aan bod komen.

Veel van de informatie in dit hoofdstuk komt uit het Smart Card Handbook [11]. Dit boek is echter niet steeds in overeenstemming met de ISO normen; waar ze verschillen, houden we vast aan de norm. In deze thesis zijn smart cards: microprocessor kaarten die voldoen aan ISO7816-1 tot -4 [12] [13] [14]. De volgende secties beschrijven algemeen hun eigenschappen.

2.1

Fysische kenmerken

Figuur 2.1 toont de fysische kenmerken die ISO-7810 [15] voorschrijft voor ID-1 smart cards. Deze smart cards zijn de meest voorkomenden en dienen als bankkaart, SIS-kaart, eID-kaart,... De dikte van de kaart (0.76mm) en de afronding van de hoeken (3.18mm) is voorgeschreven in ISO-7813 [16]. ISO7816-2 schrijft de posities (zie figuur 2.1) van de contacten op de ID-1 kaart en hun grootte. De contacten zijn 2 x 1.7mm; de ruimte tussen verschillende rijen is 0.84mm en tussen de kolommen 5.62mm. Verder definieert ISO 7816-2 ook voorwaarden inzake mechanische vervorming, ioniserende straling, magnetische en elektrische velden, etc. waaraan de kaart moet voldoen, maar die verder in deze thesis niet van belang zijn. Andere voorkomende formaten gedefinieerd in ISO 7810 zijn: 9

2. Technische achtergrond

Figuur 2.1: Fysische kenmerken van de een ID-1 smart card en posities van de contacten

ID-2 heeft afmetingen 105 x 74 mm (oa. Duits identiteitskaart) ID-3 heeft afmetingen 125 x 88 mm (formaat voor paspoorten en visas) ID-000 heeft afmetingen 25 x 15 mm (GSM SIM kaarten)

2.2

Elektrische kenmerken

ISO 7816-3 beschrijft de elektrische kenmerken van de smart cards. Contacten De contacten die zich op de kaart bevinden (zie figuur 2.1) zijn die in tabel 2.1. De signalen die met deze contacten overeenkomen zijn in de volgende paragrafen beschreven. Contact C1 C2 C3 C4 C5 C6

Afkorting VCC RST CLK AUX1 GND VPP

C7 C8

I/O AUX2

Functie Voedingsspanning Actief laag reset signaal Kloksignaal Gereserveerd voor nieuwe toepassingen (bv. USB) Referentie signaal Programmatiespanning voor EEPROM geheugen (Niet meer gebruikt, vermits kaarten nu zelf deze spanning kunnen genereren) Communicatiesignaal. Gereserveerd voor nieuwe toepassingen (bv. USB)

Tabel 2.1: Contacten op de smart card en hun functie

Reset De kaart reset op de stijgende flank van het resetsignaal. Als dit signaal de kaart reset, heet dit een warme reset, in tegenstelling tot een koude reset, waarbij het elektrisch contact met de kaart verbroken wordt. 10

Elektrische kenmerken

Klasse Klasse A Klasse B Klasse C

Voltage 5V ± 10 % 3V ± 10 % 1.8V ± 10 %

Klokfrequentie 1-5MHz 1-5MHz 1-5MHz

Maximum stroom 60 mA @ 5MHz 50 mA @ 5MHz 30 mA @ 5MHz

Tabel 2.2: Smart card klassen volgens ISO 7816-3

Voedingsspanning De voedingsspanning VCC die contact C1 voorziet hangt af van de gebruikte smart card klasse. ISO 7816-3 definieert 3 verschillende klassen, voorgesteld in tabel 2.2. De klasse A wordt vooral gebruikt voor stationaire toepassingen, bijvoorbeeld bankterminals, waar het verbruikte vermogen geen beperkende factor is. Mobiele toepassingen gebruiken eerder kaarten uit klasse C omdat deze minder vermogen gebruiken en dus de autonomie van een toestel kunnen verlengen. ISO 7816-3 vereist verder dat kaarten bestand zijn tegen het gebruik van een foute voedingsspanning; zo blijven nieuwere kaarten compatibel met oudere terminals die enkel klasse A ondersteunen. Bij het begin van de communicatie reset de kaartlezer de kaart. Hierna stuurt de kaart een antwoord: de ATR (Answer to Reset) boodschap. In die ATR worden verscheidene parameters voor de erop volgende communicatie vastgelegd; meer hierover volgt in sectie 2.3. Het kiezen van de klasse gebeurt als volgt: de kaart probeert een ATR te zenden in een eerste klasse. Als de kaartlezer deze niet kan ontvangen, zend hij de kaart een warme reset. Zo probeert de kaart alle klassen tot de lezer de ATR kan ontvangen. Uit de ATR haalt de kaartlezer de voorkeursklasse van de kaart. Als deze reeds in gebruik is, loopt de communicatie verder, anders reset de lezer de kaart en begint opnieuw, gebruik makende van de gekozen klasse.

Kloksignaal Smart cards hebben gewoonlijk geen klokgenerator op de chip, daarom is een extern kloksignaal nodig. Dit kloksignaal heeft een duty factor van 50% (met 10% marge). Intern kan dit kloksignaal nog naar believen gedeeld of vermenigvuldigd worden voor het de processor zelf bereikt. Om vermogen te besparen, ondersteunen veel kaarten het onderbreken van het kloksignaal als de CPU zich in slaapstand bevindt. Het logische niveau van de klok tijdens deze onderbreking wordt afgesproken bij het begin van de verbinding (Zie sectie 2.4.1). De ISO 7816-3 norm legt de kloksnelheid vast tussen 1 en 5MHz, hoewel de meeste microprocessoren aan een veel hogere snelheid kunnen werken (bv. 20MHz). Hierdoor gebruiken steeds meer kaarten een interne klokgenerator die een snellere werking mogelijk maakt. Dit heeft als bijkomend gevolg dat foutinjectie op het kloksignaal(zie sectie 1.3.2) niet meer mogelijk is.

Input-Output De communicatie input en output gaan over 1 zelfde wired-AND bus waar kaart en kaartlezer op aangesloten zijn. De output van de kaart en kaartlezer kan 2 toestanden aannemen: Z of hoog: de kaart of kaartlezer is inactief of zendt een hoge waarde. De desbetreffende output is hoog-impedant. Dit wil niet noodzakelijk zeggen dat het spanningsniveau op de bus hoog is; als de andere zijde in A staat, zal er op de bus een lage spanning staan. 11


In Kaartlezer

Vcc

5V

In Kaart

Pull−up Data

IO−lijn

Data

Grond

Figuur 2.2: 2 wegs I/O communicatie bus

Output kaart A A Z Z

Output Lezer A Z A Z

Spanning Bus 0V 0V 0V 5V

Tabel 2.3: Wired-AND logica

A of laag: de kaart of kaartlezer is actief en zendt een lage waarde. Hier toe brengt hij de transistor aan zijn output in geleidende stand; zo zal door spanningsdeling een lage spanning op de bus staan. Hiertoe bevat de kaartlezer een pull-up weerstand (20kΩ) die, als de transistoren aan de uitgang van kaart en kaartlezer die de bus aansturen hoog-impedant (Z) zijn, de lijn naar een hoge spanning trekt (zie figuur 2.2). Wil één van beide partijen spreken, dan schakelt hij zijn transistor naar laag-impedant (A); de lijn wordt naar een laag logisch niveau getrokken. Door een fout zouden twee partijen tegelijk actief kunnen worden. Door de bus op deze manier aan te sturen kan de spanning nooit hoger worden dan de voedingsspanning. Tabel 2.3 maakt duidelijk waarom dit een wired-AND circuit heet: het vervult de functie van een logische AND poort, en de inputs zijn enkel met draad met elkaar verbonden; er zijn geen actieve componenten in de bus zelf.

Activerings- en deactiveringssequenties De Activerings- en deactiveringssequenties zijn de volgorde van het aankoppelen en onderbreken van de signalen op de contacten van de smart card. Eerst koppelt de kaartlezer het grondsignaal aan, gevolgd door de voedingsspanning VCC. Vervolgens wordt de kloklijn actief (zie figuur 2.3)1 . Bij de deactivering wordt het reset signaal laag, vervolgens stopt de klok. Hierna wordt het I/O signaal eveneens laag. Tenslotte wordt de voedingsspanning VCC afgekoppeld.

1

The Smart card handbook en ISO 7816-3 spreken elkaar hier tegen: de norm zegt dat het I/O signaal laag moet worden na dat de klok en voor VCC stopt. In het boek blijft de I/O echter ongedefinieerd, wij volgen hier de norm

12

Fysieke laag

GND

Vcc

Klok

Reset

I/O

1111 0000 00 11 0000 1111 00 11 1111 0000 0000 1111 11110000 0000 1111 1111 0000 t1

t2

Ongedefinieerde regio

Figuur 2.3: Activerings- en deactiveringssequentie

2.3

Fysieke laag

2.3.1

Bits & ETU

De kleinste data-eenheid in de communicatie tussen de lezer en de kaart is de bit. De duur van 1 bit heet een bitinterval of ETU (Elementary Time Unit). Vermits de kaarten geen interne klok hebben (of deze alleszins niet gebruiken voor communicatie) is er geen absolute tijdsduur te plakken op de duur van 1 ETU, maar een relatieve duur uitgedrukt in aantal klokcycli. De verhouding tussen een ETU en een klokcyclus is de klokdelingsratio F gedeeld door de bitrateaanpassingsfactor D. Standaard is F = 372 klokcycli en D = 1, maar de kaart kan deze veranderen bij het begin van de communicatie. De standaard waarde voor F is zo gekozen omdat vroeger de klokfrequentie dikwijls 3.5712MHz bedroeg. Als de klokdelingsratio 372 is, is het transmissiedebiet bij deze klokfrequentie 9600 bits/s, wat bij seriële communicatie een standaard is. Zo zijn de initiële en werk ETU gegeven door: Initiële ETU =

372 fklok

1 werk ETU =

F D · fklok

De standaard definieert toleranties op de randen van het bitinterval. De overgangen tussen bits moeten gebeuren binnen deze toleranties. Ten gevolge van ruis kan de waarde van het signaal ook buiten de transitiezones drops of pieken bevatten. Een methode om dit op te lossen is binnen het stabiele interval op 3 gelijk gespreide tijdstippen het signaal te bemonsteren. Figuur 2.4 toont de toleranties op de timing van het signaal en de voorgestelde bemonsteringstijdstippen t1, t2 en t3. De communicatie tussen kaart en kaartlezer verloopt over de I/O lijn. De vertaling van logische waarden naar toestanden van de output (A/Z) hangen af van welke conventie in gebruik is (zie sectie 2.3.2).

2.3.2

Bytestructuur

Voor de omzetting van logische waarden naar de fysieke toestanden A en Z zijn er 2 conventies: de directe en inverse conventie. Bij de directe conventie komt een Z overeen met een logische 1 13


0.4 etu

0.6 etu

0.4 etu Transitiezone

t1 t2

t3

1 etu

Figuur 2.4: Toleranties op overgangen van niveau. Het bemonsteren gebeurt buiten de transitiezones. Voorbeeld van bemonsteringspunten bij 3-voudige bemonstering

Conventie Direct Invers

Bitvolgorde b0 . . . b7 b7 . . . b0

Logisch ↔ Fysiek 1 → Z, 0 → A 1 → A, 0 → Z

Tabel 2.4: Bitvolgorde en logische-naar-fysieke-niveaumapping bij verschillende conventies

en een A met een logische 0. Bij de inverse conventie is dit net omgekeerd: Z is een logische 0, A is een logische 1. Verder bepaalt de gebruikte conventie ook hoe bytes worden voorgesteld: bij directe conventie is de eerst verstuurde bit de minst significante (b0) en de laatst verstuurde de meest significante (b7). Bij inverse conventie is dit andersom, de meest significante bit (b7) komt eerst, de minst significante (b0) laatst. Ter verduidelijking staat alles samengevat in tabel 2.4. Het sturen van een byte gebeurt als volgt: eerst een startbit (altijd A, onafhankelijk van de gebruikte conventie), dan de databyte zelf. Vervolgens volgt er een pariteitsbit op de databyte en tenslotte stopbits. De duur van de stopbits wordt ook wel guard time genoemd. Deze periode beschermt tegen een te snelle opeenvolging van bytes, waardoor de ontvanger niet meer zou kunnen volgen. De pariteitsbit is de XOR (exclusieve disjunctie) van alle databits: als het aantal bits op 1 even is, is de pariteitsbit 0, anders is hij 1. Het aantal stopbits hangt af van de parameters van het gebruikte protocol op hoger niveau. Figuur 2.5 toont 2 dezelfde bytes gecodeerd in de twee conventies. Na het zenden van een boodschap controleert de zender de lijn: Als de pariteitscontrole niet klopt, kan de ontvanger dit signaleren aan de zender door halverwege de eerste ETU guard time zijn output op A te zetten en terug naar niveau Z, 1 tot 2 ETU later (zie figuur 2.5, onderaan). Hierdoor weet de zender dat de ontvanger de laatste byte foutief ontvangen heeft en zal hij deze herhalen. Deze manier van foutcontrole is verplicht bij het gebruik van T=0 en optioneel bij andere protocollen. 14

Tussenlaag

I/O Z Direct

1 Z

1 Z

0 A

1 Z

1 Z

1 Z

0 A

0 A

b0

b1

b2

b3

b4

b5

b6

b7

A

I/O Z Invers

Pariteit

Startbit

t (etu) Databyte

b7

b6

b5

b4

b3

b2

b1

b0

Z 0

Z 0

A 1

A 1

A 1

Z 0

A 1

A 1

Stopbits

A Foutindicatie

t (etu)

Figuur 2.5: Bytestructuur van ’3B’ in 2 conventies

Figuur 2.6: Verloop van communicatie volgens ISO 7816

2.4

Tussenlaag

De communicatie tussen kaart en kaartlezer volgt een strikte master-slave configuratie: de kaart stuurt nooit op eigen initiatief, enkel als de kaartlezer vooraf een TPDU (Transmission Protocol Data Unit) gestuurd heeft. Figuur 2.6 toont het verloop van de communicatie tussen de kaart en de lezer. De kaartlezer initieert de communicatie door (na aankoppeling van alle signalen) de kaart te resetten. Hierop stuurt de kaart de ATR (Answer to Reset, zie sectie 2.4.1 hieronder). Dit antwoord bevat parameters in verband met de communicatie die volgt. Als de kaart dit toelaat kan de kaartlezer bepaalde parameters veranderen. Om dit te doen stuurt de kaartlezer een PPS. De kaart beslist welke parameters ze aanneemt en stuurt deze in het antwoord op de PPS terug naar de lezer. Hierna treedt het transmissieprotocol (T=0 in deze thesis) in werking.

2.4.1

Anwser To Reset

Tussen de 400 en de 40000 klokcycli nadat de kaartlezer de kaart reset, stuurt de kaart een antwoord op deze reset (ATR of Answer To Reset). Deze paragraaf beschrijft de informatie 15


TS

T0

b1...b4 0

1

TD1

TD2

b1...b4

TD3

TD4

b5

b6

b8

b7

b6

b7

b8

TA4

b7

2

TC2

b8

TB3

b6

1

TC1

TB2

TA3

b5

b7

TB1

TA2

b1...b4 protocol

4

b5

b1...b4 protocol

3

b6

TA1

protocol

2

b5

3

TC3

b8

TB4

T1, T2, ... ,TK

4

TC4

TCK

0

Figuur 2.7: Structuur van de ATR

bevat in deze boodschap en hoe ze de latere communicatie be¨ınvloedt. Figuur 2.7 toont de structuur van de ATR-boodschap. De ATR bestaat uit een initieel karakter TS en vervolgens het structurele karakter T0. Deze 2 zijn de enige verplichte velden in de ATR. Hierna komen de interfacekarakters TA(i), TB(i), TC(i) en TD(i). Als deze ontbreken in de ATR dan gebruikt de kaartlezer de standaardwaarden voor de variabelen die de ontbrekende karakters beschrijven. Hierop volgen de historische karakters T1 tot T15, gevolgd door het controlekarakter TCK. De verdere paragrafen gaan dieper in op de betekenis van alle karakters.

Initieel karakter TS Het initieel karakter TS laat de kaartlezer weten dat de kaart een ATR wil sturen. Hieruit leidt de kaart ook de gebruikte conventie af; is het karakter ’3B’ dan is de directe conventie in gebruik, is het karakter ’3F’ dan gebruikt de kaart de inverse conventie. Figuren 2.8(a) en (b) zijn hier een grafische weergave van. Andere waarden dan ’3B’ en ’3F’ zijn niet toegelaten voor dit karakter.

Structureel karakter T0 De meest significante nibble van T0 bevat een bitveld die de aanwezigheid van de interfacekarakters TA(1), TB(1), TC(1), TD(1) aanduidt en de 4 minst significante bits bevatten het aantal historische karakters T1-T15. Tabel 2.5 toont de codering van dit karakter. 16

Tussenlaag

3

1 Z

1 Z

0 A

1 Z

1 Z

1 Z

0 A

0 A

b0

b1

b2

b3

b4

b5

b6

b7

Z

Pariteit

Startbit

B

Z

Z

Z

I/O

t (etu) Databyte

Stopbits

Z

3

F

0 Z

0 Z

1 A

1 Z

1 Z

1 Z

1 A

1 A

b0

b1

b2

b3

b4

b5

b6

b7

Pariteit

Startbit

(a) Direct

Z

Z

Z

I/O

t (etu) Databyte

Stopbits

(b) Invers

Figuur 2.8: Timing diagram van het T0 karakter b8 ... ... ... ... 1

b7 ... ... ... 1 ...

b6 ... ... 1 ... ...

b5 ... 1 ... ... ...

b4

b3

... ... ... ...

... ... ... ...

b2

b1

... ... ... ...

... ... ... ...

X

Betekenis Aantal historische karakters TA(1) aanwezig TB(1) aanwezig TC(1) aanwezig TD(1) aanwezig

Tabel 2.5: Codering van T0

Interfacekarakters De interfacekarakters bevatten informatie over het communicatieprotocol dat volgt op de ATR. De ISO 7816-3 norm maakt het onderscheid tussen globale interfacekarakters en specifieke interfacekarakters. Het verschil hiertussen is dat de globale in theorie invloed hebben op alle volgende communicatie, terwijl de specifieke enkel invloed hebben op één bepaald protocol. In praktijk zijn echter veel van de globale karakters enkel nuttig voor het T=0 protocol. Interfacekarakters die hier niet beschreven zijn, zijn dikwijls enkel nuttig en gekend door protocollen verschillend van T=0 en T=1.

Linking karakter TD(i) De TD(i) karakters bepalen samen met het T0 karakter de structuur van de ATR. De meest significante nibble van TD(i) bevat een bitveld die de aanwezigheid van de (i+1) interfacekarakters (TA(i+1), TB(i+1), TC(i+1), TD(i+1))aanduidt en de 4 minst significante bits bevatten het nummer van het protocol T dat de interfacekarakters (i+1) specifieren (Tabel 2.6). 17


b8 ... ... ... ... 1

b7 ... ... ... 1 ...

b6 ... ... 1 ... ...

b5 ... 1 ... ... ...

b4

b3

... ... ... ...

... ... ... ...

b2

b1

... ... ... ...

... ... ... ...

Betekenis Volgend protocol T (0-15) TA(i+1) aanwezig TB(i+1) aanwezig TC(i+1) aanwezig TD(i+1) aanwezig

X

Tabel 2.6: Codering van TD(i) b8

b7

b6

b5

...

...

b4 ...

X ...

...

b3 ...

b2 ...

b1 ...

Betekenis FI DI

X

Tabel 2.7: Codering van TA(1) FI F fmax FI F fmax

0000 intern ... 1000 RFU ...

0001 372 5 MHz 1001 512 5 MHz

0010 558 6 MHz 1010 768 7.5 MHz

0011 744 8 MHz 1011 1024 10 MHz

0100 1116 12 MHz 1100 1536 15 MHz

0101 1488 16 MHz 1101 2048 20 MHz

0110 1860 20 MHz 1110 RFU ...

0111 RFU ... 1111 RFU

Tabel 2.8: Codering van F in FI DI D DI D

0000 RFU 1000 RFU

0001 1 1001 RFU

0010 2 1010 1/2

0011 4 1011 1/4

0100 8 1100 1/8

0101 16 1101 1/16

0110 31 1110 1/32

0111 RFU 1111 1/64

Tabel 2.9: Codering van D in DI

Globaal interfacekarakter TA(1) TA(1) bevat FI en DI die de klokdelingsratio F en bitrateaanpassingsfactor D. Tabellen 2.7, 2.8, 2.92 tonen de codering van F en D in TA(1). De parameters F en D bepalen de lengte van 1 ETU. Initieel en na de ATR is die lengte respectievelijk gegeven door: Initiële ETU =

372 fklok

1 werk ETU =

F D · fklok

Waarin fklok de klokfrequentie in Hertz is. Als TA(1) niet gespecifieerd is, zijn de standaard waarden voor F en D respectievelijk 372 en 1. Globaal interfacekarakter TA(2) TA(2) beschrijft de toegelaten modi voor de PPS. Tabel 2.10 beschrijft de codering van TA(2). Voor de PPS zijn er 2 verschillende modi die 2 Op gebied van de codering van D en F spreken het Smart Card Handbook en de ISO 7816-3 norm elkaar tegen; wij volgen aan de norm.

18

Tussenlaag

b8 X

b7 ...

b6 ...

b5 ...

b4 ...

b3 ...

b2 ...

b1 ...

... ...

0 ...

0 ...

... X

... ...

... ...

... ...

... ...

...

...

...

...

X

Betekenis 0 Als wisselen tussen negotiable en specific modus mogelijk is,1 als niet mogelijk. Gereserveerd voor latere toepassingen 0 als transmissieparameters expliciet gedefinieerd zijn in de interfacekarakters, 1 als deze impliciet gedefinieerd zijn. Protocol T=X wordt gebruikt

Tabel 2.10: Codering van TA(2) XI X

00 Niet ondersteund

01 Laag

10 Hoog

11 Geen voorkeur

Tabel 2.11: Codering van XI UI U

00 0001 Klasse A 4.5-5.5V

00 0010 Klasse B 2.7-3.3V

00 0011 Klasse C A&B

alle anderen RFU

Tabel 2.12: Codering van UI

de kaart kan kiezen (gecodeerd in TA(2)): de specific en negotiable mode (specifieke en onderhandelbare modus). Specific mode De verandering F en D (naar wat in TA(1) gespecifieerd is) gebeurt direct na einde ATR. Deze modus laat geen verandering van parameters toe. Negotiable mode De verandering F en D naar de waarden in TA(1), of in de PPS gebeurt pas na het succesvol uitvoeren van een PPS. Verdere uitleg hierover staat in de sectie over PPS (sectie 2.4.2).

Interfacekarakters TA(i) (i>2) Of deze karakters globaal of specifiek zijn, hangt af van de waarde van T in de voorgaande TD(i-1). Als T=’F’ in TD(i-1) dan is TA(i) een globaal interfacekarakter en specifieert het de klokstopindicator (logische waarde die de klok moet aannemen als de klok onderbroken is) XI (b8kb7) (tabel 2.11) en een klasse indicator UI(b6-b1)(tabel 2.12). Als in TD(i-1) T6=’F’ dan is TA(i) een specifiek interfacekarakter dat niet in de ISO 7816 norm gedefinieerd is.

Globaal interfacekarakter TB(1) en TB(2) Deze karakters bevatten informatie over de programmeerspanning VPP. Vermits deze niet meer in gebruik zijn, gaan we er hier niet verder op in en verwijzen de lezer naar [11, p383-384] en de ISO 7816-3 norm. 19


Globaal interfacekarakter TC(1) TC(1) codeert de extra guard time N, dus de tijd (in ETU) die de beide partijen extra moeten wachten na het ontvangen van een byte (inclusief de standaard guard time van 2 ETU). Hierbij is de waarde ’FF’ echter speciaal; het effect hangt af van welk protocol later gebruikt wordt. Is dit T=0 dan is de extra guard time N = 0, dus de guard time blijft de standaard 2 ETU. In het geval van T=1 wordt de guard time 1 ETU ipv. de standaard 2 ETU. In alle andere gevallen is N gewoon de waarde die TC(1) bevat.

Specifiek TC(2) karakter (T=0) TC(2) bevat de parameter WI, die de Work Waiting Time (WWT) codeert. Deze tijd is de maximaal toegelaten tijd tussen het begin van 2 opeenvolgende bytes: work waiting time = (960 · D · W I)ETU Duurt de tijd tussen het begin van 2 opeenvolgende bytes langer, dan treedt een time-out op, wordt de communicatie onderbroken en de kaart gereset. Als TC(2) niet aanwezig is, is de standaard WI=10.

Specifiek karakter TA(i) (T=1, i>2) TA(i) (met i>2) bevat de parameter IFSC (Information Field Size on Card). Deze geeft de maximale lengte van een informatieveld weer. Dit is de maximale lengte dat het dataveld in een instructie kan aannemen. IFSC moet liggen tussen 1 en 254. Standaard is deze waarde 32 bytes.

Specifiek karakter TB(i) (T=1, i>2) De minst significante nibble (bits b4-b1) bevat CWI die de Character Waiting Time (CWT) codeert. De meest significante nibble (bits b8-b5) bevat BWI die de Block Waiting Time (BWT) codeert. Deze 2 parameters zijn gedefinieerd als: CWI

CWT = (2

+ 11)ETU

372 BWI BWT = 2 · 960 · · s + 11 ETU fklok

Vermits deze thesis niet verder in gaat op het T=1, verwijzen we de lezer naar [11, p409 ev.].

Specifiek karakter TC(i) (T=1, i>2) Enkel de minst significante bit b1 van TC(i) is van belang. Deze heeft de volgende betekenis: 0 gebruik LRC (Longitudinal Redundancy Check) foutdetectie code 1 gebruik CRC (Cyclic Redundancy Check) foutcorrectie code Alle andere bits zijn gereserveerd voor toekomstige toepassingen.

Historische karakters Deze zijn de karakters die de laatste TD(i) opvolgen. T0 geeft het aantal historische karakters aanwezig (0 tot 15). Ze coderen applicatie- of fabricant-eigen data, zoals de versie van het besturingssysteem op de kaart, het model van kaart, . . . Vaak zijn deze karakters ASCII-karakters (versienummers etc), of binaire data (zoals initialisatiedata voor een specifiek protocol). 20

Tussenlaag

initieel warme reset

warme of koude reset warme reset

ATR

negotiable mode

PPS

1

specific mode

transmissie protocol actief

1

Figuur 2.9: Mechanisme van de PPS

Controle karakter TCK Dit karakter is niet aanwezig indien de ATR enkel het T=0 protocol specifieert. Anders moet dit karakter aanwezig zijn. TCK bevat de XOR (exclusieve disjunctie) van alle ATR-karakters van T0 tot en met het karakter voor de TCK.

2.4.2

Protocol Parameter Selection (PPS)

Deze procedure laat de kaartlezer toe bepaalde parameters, die de kaart in de ATR specifieerde, te veranderen. Als de kaartlezer deze parameters wil veranderen, en de kaart gaf in de TA(2) in de ATR aan dat ze de negotiable mode ondersteunt, dan stuurt de kaartlezer als volgende boodschap een Protocol Parameter Selection (PPS) boodschap. De kaartlezer kan dit maar één keer doen. Na ontvangst stuurt de kaart dezelfde boodschap terug als ze alle gevraagde parameters ondersteunt. De kaart kan ook individuele karakters uit het antwoord weglaten; zie verder voor meer hierover. Figuur 2.9 verduidelijkt het PPS mechanisme: als de kaart een PPS toelaat (negiotable mode), dan kan de kaart, na een ATR te hebben ontvangen, een PPS sturen. Na antwoord op de PPS staat de kaart in specific mode, met de parameters die ze uit de PPS heeft aangenomen. Hierna gaat het transmissieprotocol van start (T=0 in deze thesis). Deze procedure heeft de naam PPS slechts sinds 1997, hiervoor heette het PTS, voor Protocol Type Selection.

PPS Karakters De hele PPS boodschap bestaat uit minimaal 3 en maximaal 6 karakters. De karakters PPSS, PPS0 en PCK zijn verplichte karakters; de karakters PPS1, PPS2 en PPS3 zijn optioneel.

PPSS Dit karakter laat de kaart eenduidig weten dat de lezer een PPS stuurt. De waarde van dit karakter is steeds ’FF’. Dit karakter is verplicht. 21


b8 ... ... ... ... 0

b7 ... ... ... 1 ...

b6 ... ... 1 ... ...

b5 ... 1 ... ... ...

b4

b3

... ... ... ...

... ... ... ...

b2

b1

... ... ... ...

... ... ... ...

X

Betekenis Te gebruiken protocol PPS1 aanwezig PPS2 aanwezig PPS3 aanwezig RFU

Tabel 2.13: Codering van PPS0 b8 ... ...

b7 ... ...

b6 ... ...

b5 ... ...

b4 ... ...

b3 ... ...

b2 ... ...

b1 1 0

...

...

...

...

...

...

1

...

...

...

...

...

...

...

0

...

0

0

0

0

0

0

...

...

Betekenis De kaartlezer ondersteunt N=’FF’ De kaartlezer ondersteunt N=’FF’ niet (standaard) De kaart moet 12 ETU extra guard time toevoegen bij het sturen van karakters naar de kaartlezer. De kaart moet geen extra guard time toevoegen bij het sturen van karakters naar de kaartlezer. (standaard) RFU

Tabel 2.14: Codering van PPS2

PPS0 Dit karakter is analoog aan het TD(i) karakter in de ATR. Het bevat een beschrijving van de karakters die erop volgen en een indicatie van welk protocol te volgen (tabel 2.13). Het is eveneens een verplicht onderdeel van de PPS.

PPS1 Dit karakter codeert FI en DI net zoals TA(1) dit doet( tabellen 2.7, 2.8 en 2.9 op pagina 18)3 . Als de kaart dit karakter weglaat in haar antwoord, dan neemt de lezer de standaard waarden FI = 372 en D = DI = 1 aan.

PPS2 Slechts 2 bits van PPS2 zijn in gebruik: b1 en b2. Bit b1 codeert de ondersteuning voor N=’FF’, bit b2 codeert de extra guard time voor karakters die de kaart naar de kaartlezer stuurt (tabel 2.14). Alle andere bits zijn gereserveerd voor toekomstige toepassingen.

PPS3 Karakter PPS3 is voorbehouden voor toekomstige toepassingen en dus niet beschreven in ISO 7816-3.

PCK Het controle karakter PCK is de XOR (exclusieve disjunctie) van de karakters PPSS tot PPS3. Dit karakter is tevens een verplicht karakter in de PPS. 3

22

Over de codering van PPS1 is er tegenspraak tussen [11] en de ISO 7816-3 norm; wij volgen de norm.

Datalinklaag: T=0

Protocol T=0

T=1 T=2 T=3 T=4 T=5 tot 13 T=14 T=15

beschrijving is het asynchroon half-duplex karaktertransmissieprotocol (ISO 7816-3). Dit is het enige protocol dat we in deze thesis uitgebreid bespreken. is het asynchroon half-duplex bloktransmissieprotocol (ISO 7816-3 Amd. 1). is het asynchroon full-duplex bloktransmissieprotocol (ISO 10536-4 [17], gebruikt in contactloze smart cards) is gereserveerd voor toekomstige full-duplex operaties. is gereserveerd voor een verbeterd asynchroon half-duplex karaktertransmissieprotocol. zijn gereserveerd voor toekomstige toepassingen is gereserveerd voor protocols niet gestandaardiseerd door ISO ( oa. nationale toepassingen). is gereserveerd voor toekomstige uitbreidingen. Tabel 2.15: Verschillende mogelijke protocollen

2.5

Datalinklaag: T=0

Als mogelijke linklaag protocollen kunnen processorkaarten de T=0 tot T=15 protocollen gebruiken. De ISO 7816-3 norm beschrijft deze protocollen als in tabel 2.15. Deze thesis beschouwt enkel het T=0 protocol, hoewel het principe makkelijk uitbreidbaar kan zijn naar T=1. De lezer kan de specificatie van T=1 terug vinden in de norm ISO 7816-3 Amd. 1 [14] en in [11, sectie 6.4.3]. Het T=0 protocol is een byte-georiënteerd asynchroon protocol. Dit betekent dat de byte de kleinste beschouwde eenheid is. De structuur van de bytes is zoals in sectie 2.3.2. Foutdetectie gebeurt eveneens als in sectie 2.3.2: op byteniveau (zie figuur 2.5). De volgende paragrafen beschrijven het verloop van het T=0 protocol (zie ook figuur 2.10).

TPDU Een TPDU bestaat uit een header van 5 bytes en een optioneel dataveld (0 tot 255 bytes). De header bestaat uit een klassebyte (CLA), een instructiebyte (INS) en 3 argumentbytes (P1, P2 en P3). P3 bevat de lengte (in bytes) van het dataveld (Figuur 2.11). Als P3 gelijk is aan ’00’, dan bevat de instructie geen databytes. De kaart begint dan direct aan het uitvoeren van de instructie, zonder de ontvangst hiervan te bevestigen. Is P3 echter verschillend van nul, dan moet de kaart een PB sturen (Procedure Byte) om aan te geven dat ze klaar is om de data van de kaartlezer te ontvangen. Deze PB kan de volgende waarden aannemen: INS, INS, INS+1 of INS+1 (tabel 2.16). Hierbij is INS de waarde van de instructiebyte waarop deze PB een antwoord is. Het inverteren controleert hoe de kaartlezer de data naar de kaart stuurt. Bij een nietge¨ınverteerde INS als PB stuurt de kaart alle beschikbare databytes achter elkaar; bij een ge¨ınverteerde INS als PB stuurt de kaartlezer 1 databyte afzonderlijk. De kaart kan dan op de zelfde manier de volgende (INS als PB) of alle resterende (INS als PB) databytes vragen van 23


1

2

Header

Einde instructie

WTX Timeout

Header SW1||SW2 P3 = 0 Ja

Nee

’9000’ of foutcode

Legende SW1||SW2=

Zend PB ’61XX’ Data

Nee

Nee

GetResponse

Ja

Kaart voert uit

Tekst

Lezer zendt ’Tekst’

Tekst

Header

#data=P3

Tekst

Tekst

Beslissing op basis van ’Tekst’

Tekst

Wachten op ’Tekst’

1

Ja

Voer instructie uit

Data|| SW1||SW2

2

1

Figuur 2.10: Diagram voor T=0 protocol

CLA INS

P1

P2

P3

...

Data

header

Figuur 2.11: Structuur van een T=0 TPDU

Waarde INS INS INS+1 INS+1

Betekenis Alle data in 1 keer 1 data byte Alle data in 1 keer 1 databyte

VPP VPP VPP VPP

inactief inactief actief actief

Tabel 2.16: Waarde Procedure Byte

24

Kaart zendt ’Tekst’

Verwijzing naar 1

Datalinklaag: T=0

SW1 ’90’ ’61’ ’60’ ’67’ ’6B’ ’6D’ ’6E’ ’6F’

SW2 ’00’ X geen X X X X X

Betekenis Instructie uitgevoerd, geen data Instructie uitgevoerd, X bytes data klaar Wachttijdverlenging Foute lengte van data Foute referentie INS niet geldig of ge¨ımplementeerd Kaart ondersteunt deze klasse (CLA) niet Geen precieze diagnose

Tabel 2.17: Statuswoorden volgens ISO 7816-3

de kaartlezer. Het incrementeren van de instructiebyte heeft als effect dat de kaartlezer de programmatiespanning VPP aanschakelt. Bij het ontvangen van een niet-ge¨ıncrementeerde byte schakelt de kaartlezer VPP uit. De programmatiespanning is nu technisch achterhaald, alle huidige kaarten kunnen intern deze spanning opwekken. De hierboven beschreven manier van aan- en uitschakelen van VPP heeft echter nog steeds tot effect dat het aantal verschillende instructies beperkt is tot 128 voor toepassingen die conform ISO 7816-3 willen blijven. Er zijn plannen om in een nieuwe revisie deze functionaliteit uit de norm te verwijderen en zo het aantal mogelijke instructies te verdubbelen [11, p. 404].

Antwoord op TPDU Nadat de kaart alle databytes ontvangen heeft, voert deze de gevraagde instructie uit. Als de instructie voltooid is, stuurt de kaart een antwoord in de vorm van 2 statuswoorden SW1 en SW2 (tabel 2.17). Statuswoorden die niet in tabel 2.17 staan, zijn niet in ISO 7816-3 gedefinieerd; deze zijn dikwijls toepassingsafhankelijk. De statuswoorden waartussen het onderscheid echt van belang is voor deze laag van communicatie zijn ’9000’, ’61XX’, ’60’ en de rest (foutmeldingen of waarschuwingen). Het statuswoord ’9000’ laat de kaartlezer weten dat de kaart de instructie goed verwerkt heeft en dat de kaartlezer een volgende instructie kan sturen. Het statuswoord ’61XX’ geeft aan dat de kaart de instructie goed verwerkt heeft en dat er als resultaat ’XX’ bytes data klaar zijn. De kaartlezer kan deze bytes opvragen door een GetResponse commando te sturen. Als de kaart deze ontvangt, zendt ze al de berekende data naar de kaartlezer. Dit impliceert dat er bij gebruik van het T=0 protocol geen duidelijke scheiding is tussen het linklaag protocol en de applicatielaag: er is immers een apart commando (in de applicatielaag) nodig om de uitwisseling van data te voltooien. Het statuswoord ’60’ (NULL byte in de ISO 7816-3 norm) heeft een speciale betekenis. De ISO 7816-3 norm definieert dat bij ontvangst van deze byte de kaartlezer de teller van het aantal klokcycli sinds de laatste transmissie reset. Op deze manier voorkomt dit dat WWT klokcycli zouden verstrijken (er treedt een time-out op). Dit is dus een soort wachttijd verlenging, en zal verder in deze thesis WTX (Waiting Time eXtension) genoemd worden. Alle andere statuswoorden geven een fout of waarschuwing aan, die niet in ISO 7816-3 wordt gespecifieerd (op deze in tabel 2.17 na). De precieze betekenis van deze foutmeldingen hebben 25


Geval 1 2 3 4

TPDU geen data geen data data data

Antwoord geen data data geen data data

Tabel 2.18: 4 gevallen ivm. aanwezigheid van data in TPDU en het antwoord op TPDU

eerder invloed op het applicatieniveau dan op datalinkniveau.

Data-aanwezigheid (4 gevallen) Op basis van welke van de zijden data te versturen heeft, maakt de ISO 7816-4 norm een onderscheid tussen 4 gevallen op niveau van de applicatielaag. Vermits dit onderscheid integraal terug komt op niveau van de linklaag voor T=0 specifiëren we deze hier. De 4 gevallen zijn (zie ook tabel 2.18): • Geen van beide zijden heeft data te zenden • De kaartlezer heeft data te zenden; het antwoord van de kaart bevat geen dataveld • Het commando van de kaartlezer bevat geen dataveld; het antwoord van de kaart heeft een dataveld • Beide zijden hebben elkaar data te sturen

Voordelen van T=0 Eenvoudig De implementatie van het T=0 protocol gaat gepaard met een zeer kleine implementatieoverhead. Veel gebruikt Het gebruik van T=0 is zeer wijd verspreid, vermits het het oudste smart cardprotocol is. Transmissiesnelheid Het T=0 protocol haalt een zeer goede snelheid. Dit is het gevolge van twee elementen. Ten eerste door het mechanisme van pariteitscontrole per byte, moet de zender enkel incorrecte bytes herhalen (in plaats van hele blokken in blokgebaseerde protocollen). Ten tweede gebeurt de heraanvraag van een foutief ontvangen byte tijdens de guard time, dus vereist deze geen extra byte en is de overhead van de heraanvraag zeer klein.

Nadelen van T=0 Pariteitscontrole De pariteitscontrole kan slechts één bitfout per byte corrigeren. Als de bitfoutkans door slecht contact, of storing hoog wordt, zullen veel bytes met meer dan 2 fouten per byte toch aanvaard worden als geldige bytes. Dit zorgt uiteraard voor ongewenst gedrag van de kaart. Scheiding lagen Het is duidelijk dat de linklaag en de applicatielaag bij het T=0 protocol slecht gescheiden zijn. Enkel het bestaan en de noodzaak van het GetRespons commando, geeft dit al aan. Elk van de 4 gevallen uit de bovenstaande paragraaf volgt ook een verschillend pad doorheen de flowchart in figuur 2.10. Hieruit blijkt dus dat de applicatielaag zijn steentje moet bijdragen aan het doen functioneren van de linklaag. 26

Datalinklaag: T=0

Deadlocks Het T=0 protocol kan in bepaalde situaties vast komen te zitten, zonder uitweg binnen het protocol. Bijvoorbeeld het mechanisme voor de wachttijdextensie werkt enkel voor het begin van de datastroom van de kaart naar de kaartlezer. Voor situaties waar de kaart niet genoeg data zendt, of als hele bytes wegvallen door een slechte verbinding is de pariteitscontrole op bytebasis onvoldoende. Zulke fouten blijven ongedetecteerd. Hierdoor blijft de kaartlezer wachten op de verloren databytes. De kaartlezer kan het verlies van hele bytes enkel detecteren door middel van een extra time-out, die niet in het protocol gedefinieerd is. Dezelfde situatie komt voor als de kaartlezer niet genoeg data naar de kaart stuurt, de kaart blijft eenvoudig weg wachten op de ontbrekende databytes. In praktijk integreert men een extra time-out in de kaartlezer om in zulke gevallen de kaart te resetten, maar dit is niet gestandaardiseerd en de implementatie hangt af van toepassing tot toepassing. Voorbeelden T=0 Als laatste paragraaf geven we nog enkele voorbeelden van mogelijke T=0 communicatiesequenties (figuur 2.12).

(a) T=0 Geval 1

(b) T=0 Geval 2

Figuur 2.12: Voorbeelden van het T=0 protocol: (a): Geen van beide zijdes heeft data. De kaart stuurt een WTX omdat ze meer tijd nodig heeft. (b): Het commando van de kaartlezer bevat geen data. De kaart start direct na ontvangst van de header met de berekening. Als antwoord heeft de kaart 3 data bytes. De kaartlezer vraagt deze op met het GetRespons commando. Hierop stuurt de kaart de 3 berekende databytes.

27


(c) T=0 Geval 3

(d) T=0 Geval 4

Figuur 2.12: Voorbeelden van het T=0 protocol (vervolg) : (c): Enkel de kaartlezer heeft data te sturen. De kaart vraagt de eerste 2 bytes afzonderlijk door PB = INS te sturen. Hierna vraagt ze de rest door PB = INS te sturen. (d): Zowel de kaart als de kaartlezer hebben data te sturen. De eerste keer dat de kaart data klaar heeft, stuurt de kaartlezer een ander commando dan GetResponse; de kaart gooit de berekende data weg. De tweede keer vraagt de kaartlezer de berekende data wel op.

28

Hoofdstuk 3

Probleemstelling Samenvatting Dit hoofdstuk beschrijft de doelstellingen en vereisten voor deze thesis. In de eerste sectie 3.1 gaan we in op het probleem van transparante communicatie als zender en ontvanger aan een andere klokfrequentie werken. Vervolgens behandelt sectie 3.2 het probleem van de variatie op de frequentie van het kloksignaal dat de kaart ontvangt. Tenslotte heeft sectie 3.3 het over de beperkingen die gelden bij het implementeren van de hoger beschreven vereisten.

3.1

Verschillende Klokfrequenties

Doel Het doel is de kaartlezer en de kaart constant op een verschillende klokfrequentie te laten werken. De kaartlezer werkt dan nog op het origineel kloksignaal dat hij zelf genereert, maar de kaart werkt op een willekeurig van buiten af voorzien kloksignaal. Figuur 3.1 stelt dit grafisch voor. Deze figuur maakt duidelijk hoe de kaartlezer, FPGA-bord (het circuit in deze thesis beschreven) en de kaart met elkaar communiceren. De FPGA moet de kaart kunnen Extern kloksignaal glitch Extern kloksignaal

Smart card FPGA

Kloksignaal kaartlezer Kaartlezer

Legende Communicatie Configuratie Kloksignaal

Figuur 3.1: Algemene setup om verschillende kloksnelheden toe te laten

29

3. Probleemstelling

V Klok Laadstroom

I

V Klok I Laadstroom

Tijd

Figuur 3.2: Schets van laadstromen bij verschillende klokfrequenties: bij hoge klokfrequentie lopen de stromen in elkaar over, bij lage klokfrequentie zijn deze duidelijk te onderscheiden.

voorzien van een stabiel extern kloksignaal, dat niet (noodzakelijk) het zelfde is als dat van de kaartlezer. Bij voorkeur moet de PC alle relevante parameters bij het uitvoeren via een verbinding met de FPGA kunnen instellen. Deze interface tussen FPGA en PC is een extra doelstelling, die niet kritisch is.

Motivatie We willen de kaart aan een lagere klokfrequentie doen werken omdat zo de meting van het aan de voeding onttrokken vermogen veel nauwkeuriger is. De reden daarvoor is als volgt. De logica in de processor van de kaart is CMOS logica, die als eigenschap heeft dat ze enkel energie verbruikt bij het omschakelen. Dit energieverbruik wordt veroorzaakt door transistoren die opladen of ontladen als een logische poort van waarde wisselt. Deze laadstromen veroorzaken 85% van het verbruik van een CMOS chip [8]. De oorzaak van de laad- en ontlaadstromen zijn de parasitaire capaciteiten Cp van onder andere de gates van de transistoren. Deze vormen samen met de parasitaire weerstanden Rp van het circuit RC-kringen. De tijd dat de parasitaire capaciteit nodig heeft om op te laden tot 63% van zijn capaciteit is de tijdconstante τ = Rp × Cp . Werkt de kaart aan een hoge klokfrequentie, dan is het mogelijk dat de laadstromen ten gevolge van één bewerking nog niet volledig zijn uitgestorven, als een andere reeds begonnen is. Bij een lagere klokfrequentie krijgen deze laadstromen meer tijd om uit te sterven en is het dus mogelijk een duidelijker beeld te vormen van het vermogenverbruik veroorzaakt door één bepaalde instructie (figuur 3.2).

3.2

Variatie op externe klokfrequentie

Doel Het doel van de variatie van de klokfrequentie (of glitch generation) is om aan foutinjectie te doen. Een bepaalde tijd nadat de kaart begint met de uitvoering van een instructie moet het kloksignaal gedurende een bepaalde tijd overschakelen naar een tweede extern kloksignaal voor de kaart. Deze verandering in het kloksignaal moet exact op het juiste tijdstip gebeuren, we willen immers juist 1 instructie aanvallen. In figuur 3.1 is dit weergegeven door de multiplexer tussen vaste externe klok en externe klok glitch enerzijds en de klok van de smart card anderzijds. 30

Beperkingen

Motivatie Op deze manier moet het mogelijk zijn fouten in één bepaalde bewerking van een instructie te introduceren. Zo kunnen we de veiligheid van deze smartcard tegen aanvallen op het kloksignaal te testen. Dit stelt ons in de eerste plaats in staat om fouten in de data te introduceren, door de glitch te introduceren net voor de kaart data uitleest. Vermits de vertraging ten gevolge van de logische circuits relatief groter wordt in vergelijking met de verkleinde klokperiode, zal de kaart de gegevens te vroeg en bijgevolg fout uitlezen. Een voorbeeld hiervan is de aanval op RSA beschreven in [18]. Het tekenen van eenzelfde gegeven, één keer met een correcte data (geen glitch ge¨ıntroduceerd), en één keer met foute data (een glitch ge¨ıntroduceerd die het uitlezen van data corrumpeert) zorgt ervoor dat de modulus van het RSA-systeem uitlekt. Hierdoor is heel het systeem gecompromitteerd. Een tweede resultaat van het introduceren van glitches kan zijn dat er fouten optreden in de volgorde waarin de kaart de instructies uitvoert. Als de huidige instructie niet genoeg tijd krijgt, kan het zijn dat de volgende al begint, zonder op het resultaat van de eerste te wachten. Dit is desastreus voor conditionele instructies: terwijl de controle van de conditie nog loopt, kan de instructie erna (één van de twee takken) al starten, zonder dat de conditie al gecontroleerd is. Een kaart gebruikt bijvoorbeeld een heel veilig cryptografisch algoritme en na het uitvoeren hiervan controleert ze met een conditionele instructie of de gebruiker al dan niet geauthenticeerd is [10]. Dit is een zwak punt voor een glitchaanval: het veranderen van de programmateller (die bijhoudt welke instructie processor als volgende uitvoert) gebeurt dikwijls naar het einde van de klokcyclus toe. Als er dus een glitch optreedt halverwege de klokcyclus, zorgt deze ervoor dat de processor gewoon de volgende instructie uitvoert, ipv. degene waar de conditionele instructie naar zou moeten springen [19]. Hierbij verleent de kaart dus toegang tot een routine waar normaal enkel geauthenticeerde gebruikers toegang toe hebben, bijvoorbeeld het gebruik van een private sleutel.

Bijkomende problemen De triggering van de verandering van het kloksignaal moet zo nauwkeurig mogelijk zijn. We willen immers één bepaalde bewerking in de kaart aanvallen. De vereiste nauwkeurigheid is van de orde van enkele fracties van de duur van een klokcyclus waar de kaart op werkt (verklaring zie voorgaande paragraaf).

3.3

Beperkingen

Doel De doelstellingen in de vorige secties mogen de correcte werking van het gebruikte communicatie protocol niet be¨ınvloeden: We willen transparante communicatie. De kaart en kaartlezer moeten dus nog wel steeds informatie op een juiste manier uitwisselen; als de kaartlezer een bericht stuurt, moet de kaart dit zo aan krijgen. Dit alles moet ook gebeuren zonder veranderingen aan te brengen aan de kaart, noch de kaartlezer.

Motivatie De reden waarom de communicatie transparant moet zijn, en waarom geen modificatie mag aangebracht worden aan de kaart en de lezer is omdat we bestaande kaarten willen testen, niet enkel kaarten die we zelf kunnen programmeren. Het zijn immers real-life 31

3. Probleemstelling

situaties die we willen testen, niet enkel situaties die we zelf creëeren. Als de kaart en de kaartlezer niet meer kunnen communiceren, zullen de instructies die we willen aanvallen ook niet worden uitgevoerd.

32

Hoofdstuk 4

Oplossing Samenvatting Dit hoofdstuk beschrijft de oplossingsmethode die we gebruiken opdat ons design aan de doelstellingen uit hoofdstuk 3 zou voldoen. Sectie 4.1 verklaart de implicaties die de keuze voor een FPGA-bord heeft op het project. Hierna volgen secties 4.2 en 4.3 die de twee gevolgde uitgangspunten voorstellen. Deze zijn respectievelijk een bitgebaseerde aanpak en een bytegebaseerde aanpak. Deze paragrafen leggen tevens uit welke stappen ondernomen zijn om tot een oplossing te komen, en welke problemen hierbij naar boven komen. Sectie 4.2 beschrijft tevens waarom de bitgebaseerde oplossing onvoldoende was, en waarom dan de bytegebaseerde oplossing 2 uit sectie 4.3 de voorkeur verdient.

4.1

Levelshifting

Om de “vertaling” tussen de 2 klokdomeinen te doen, hebben we een Xilinx Virtex II-Pro FPGAbord1 gekozen. We kiezen een FPGA omdat dit ons toelaat de hardware zelf te programmeren (in VHDL) en zo een circuit te bekomen dat op de klokcyclus nauwkeurig kan werken. Een dergelijke precisie is niet mogelijk met andere keuzes zoals een PIC. Het FPGA-bord is een circuit met daarop een chip, waarvan de hardware programmeerbaar is. De logica van dit bord aanvaardt enkel LVTTL logica (3.3V) voor input en output, terwijl de smart cards CMOS logica (5V) gebruiken voor communicatie. Deze incompatibiliteit lossen we op door een levelshifter te gebruiken. De volgende paragrafen beschrijven deze levelshifter. Het probleem hierbij ligt niet zo zeer in omzetten tussen verschillende logische spanningen, maar eerder in het feit dat de I/O lijn tussen kaart en kaartlezer een 2-richtingsbus is. Hierdoor volstaan standaard levelshifters niet, en is een zelf gemaakt circuit nodig. Dit circuit bevat een MC14504B Hex-levelshifter; deze component bevat 6 kanalen die kunnen shiften tussen 3.3V LVTTL en 5V CMOS logische niveaus. De keuze viel op deze levelshifter omdat deze erg eenvoudig is in gebruik, en in één verpakking direct het aantal benodigde kanalen bevat. 1

http://www.xilinx.com/products/devkits/XUPV2P.htm

33

4. Oplossing

Card Reader

IOCin

5V

FPGA VCC

MODE

LS

VDD

IO

Smartcard

IO Reset

Out

In

Levelshifter

IORin RSTin

IOCout

IORout

In Levelshifter Circuit

Figuur 4.1: Diagram voor levelshifting; het circuit omvat de componenten omsloten door de stippellijn

Deze levelshifter werkt echter maar in één richting: de inputs kunnen niet werken als outputs en vice versa. Om ook de andere communicatierichting te kunnen voorzien, schakelen we per kanaal 1 transistor (BS170, drain aan de I/O lijn, source aan de grond en gate gecontroleerd door de FPGA) om de I/O lijn ook in de richting van FPGA naar kaart of kaartlezer te kunnen aansturen (figuur 4.1). De redenen om deze transistor te kiezen zijn: het lage verbruik (het is een n-MOS transistor), de goede beschikbaarheid en de drempelspanning (max. 3V)2 die onder de 3.3V LVTTL niveau ligt. De 3.3V spanning van de output van de FPGA is genoeg om de gate van de n-MOS transistor aan te sturen, vermits de drempelspanning van de BS170 tussen de 0.8 en 3 V ligt. De FPGA heeft dus per zijde 1 inputsignaal (IOCin en IORin) en 1 output signaal (IOCout en IORout). Daarnaast krijgt de FPGA via de MC14504B ook het reset signaal RST van de kaartlezer. Aan de kaartzijde van het circuit is nog een pull-up resistor van 20kΩ nodig om deze in de kaartlezer te vervangen in het circuit tussen FPGA en kaart (zie figuur 2.2). Het uiteindelijke levelshifter-circuit ziet eruit als in figuur 4.2. Nu is als het ware de 2-wegsbus in twee gesplitst met de FPGA tussen de kaart en de kaartlezer. Langs de kant van de kaartlezer imiteert de FPGA de kaart, langs de kant van de kaart imiteert hij de kaartlezer. Als de kaartlezer iets stuurt gaat dit over de I/O lijn naar de levelshifter. Deze zet het om naar LVTTL niveaus, en geeft dit door aan IORin van de FPGA. Deze stuurt dit signaal veranderd verder naar de kaart door zijn BS170 via IOCout in stand A of Z te schakelen. De voeding levert via pull-up resistor R1 levert de benodigde spanning om bij een waarde Z aan beide uitgangen (van FPGA en kaart) de lijn naar een hoog niveau te brengen. In de richting van kaart naar kaartlezer gebeurt dit op een volledig analoge manier. Deze levelshifter oplossing zorgt dus voor elektrische connectiviteit tussen kaart en kaartlezer en de FPGA. Het ontwerp en simulatie van deze levelshifter gebeurde in Linear Technology’s LTSpice3 . 2 3

34

Datasheet Fairchild Semiconductor: BS170 Rev. C / MMBF170 Rev. D (april 1995) Gratis beschikbaar op: http://www.linear.com/designtools/software/

Oplossing 1: Bitstream

CONN1

IOC

2

Reset

3

GND

4

IOR

5

+5V

CONN2

+3.3V

1

MC14504B 1 20K

1

R1

5V

2

6 7 8

G

S

BS170

S

BS170

Q2

VCC

VDD

16

Aout

Fout

15

3

Ain

4

Bout

Fin

14

MODE

13

Eout

12

Ein

11

5

Bin

6

Cout

7

Cin

Dout

10

8

Vss

Din

9

D

Q1

Q3

3.3V

2

IOCin

3

IOCout

4

GND

5

IORout

6

Rstin

7

IORin

8

G

D

Figuur 4.2: Levelshifting circuit IOCout IORout

FIFOR

Kaart

Kaartlezer

IOCin

FIFOC

IORin ClkCdiv ClkRdiv

ClkR

Klokdeler

ClkC

Klokdeler

Figuur 4.3: Bitstream aanpak

4.2


De eerste oplossing voorziet een bitgewijze aanpak . De FPGA buffert bits komende van de kaartlezer in een FIFO, en stuurt deze achteraf door naar de kaart. De andere richting is volledig analoog (figuur 4.3). De signalen in figuur 4.3 zijn: IOCin Inputsignaal van de kaart (C voor Card) naar de FPGA. IOCout Outputsignaal van de FPGA naar de kaart. IORin Inputsignaal van de kaartlezer (R voor Reader) naar de FPGA. IORout Outputsignaal van de FPGA naar de kaartlezer. ClkC Kloksignaal aan de kaart-kant. Dit is het kloksignaal dat extern voorzien wordt. ClkR Kloksignaal aan de lezer-kant. Dit is het originele kloksignaal gegenereerd door de kaartlezer. ClkCdiv Kloksignaal aan de kaart-kant, na deling door de klokdelingsfactor F (die hier op de standaard waarde ingesteld is, in de hoop dat de meeste kaarten dit gebruiken). ClkRdiv Kloksignaal aan de lezer-kant, na deling door de klokdelingsfactor F (die hier op de standaardwaarde ingesteld is). 35

4. Oplossing

ht in Sc

hr ijf ric

ht in hr ijf ric Sc

Sc

hr ijf ric

ht in

g

p_W

g

p_W

g

p_W

p_R

p_R

Beschreven geheugen

Beschreven geheugen

p_R

Normaal

Leeg

Vol

Figuur 4.4: Voorstelling van het geheugen van het FIFO-blok

Figuur 4.3 toont het volledige systeem zoals voorgesteld in deze methode Deze bitgebaseerde aanpak heeft als voordelen dat het een heel eenvoudige implementatie heeft. Het enige belangrijke element is de FIFO. Vermits enkel bits van belang zijn, hoeft het circuit niets te weten van transmissieprotocols of hogere lagen. De volgende sectie gaat wat verder in op de blokken die voor deze aanpak benodigd zijn.

4.2.1

Bouwblokken

Klokdeler Dit blok telt het aantal klokcycli van het originele kloksignaal. Als het verlopen aantal klokcycli gelijk is aan de helft van de klokdelingsfactor F, dan verandert het blok het niveau van de gedeelde-klokuitgang. Op deze manier is het uitgangssignaal een kloksignaal met een frequentie F keer lager dan de frequentie van het kloksignaal aan de ingang. De klokdelingsfactor F heeft hier steeds de standaardwaarde 372. Binnen een bitgebaseerde aanpak kan het circuit de ATR immers niet interpreteren. Dubbelgeklokte FIFO De FIFOR en FIFOC (R en C voor Reader en Card) in figuur 4.3 zijn dubbelgeklokte FIFO (First In First Out) geheugenblokken. Dit wil zeggen: De bits die er het eerst ingaan, komen er ook het eerst uit. De term dubbelgeklokt slaat op het feit dat het kloksignaal waarop de FIFO leest en schrijft van elkaar verschillen. Naast de te verwachten datainput, data-output, lees- en schrijfkloksignaal, hebben deze FIFO’s ook vol- en leegaanduidingen. Deze geven de status van het geheugenblok aan. Verder zijn er nog een Write-Enable (WE) en een Read-Enable (RE) signaal die respectievelijk het schrijven en lezen in het geheugen toestaan. De plaats waar de processen de bits schrijven en lezen zijn respectievelijk de schrijfpointer p W en de leespointer p R. Dit zijn 2 signalen die voor alle processen zichtbaar zijn. Dit geheugen kan men voorstellen als een ring: als een pointer voorbij de laatste geheugenpositie gaat komt hij terug bij de eerste uit (figuur 4.4). De interne write-enable en read-enable (WE int en RE int) zijn de logische AND tussen WE en full int, respectievelijk RE en empty int. Als het geheugen leeg is, staat de RE int altijd op 0, er is immers niets om uit te lezen. Als het 36


p_w datain WE_int

memory

dataout

RE_int

INPUT

OUTPUT p_r

full_int_W full_int empty_int_W

CONTROL

full_int_R empty_int_R

empty_int

Figuur 4.5: Processen in FIFO blok

geheugen vol zou zitten (normaal gezien moet het geheugen groot genoeg gekozen zijn) staat de WE int altijd op 0, er is immers geen plaats om nog bits in het geheugen te schrijven. Het gebruik van deze interne enable-signalen verhindert dus het verlies, of foutieve uitlezing van data. De implementatie van deze FIFO bestaat uit 3 processen (figuur 4.5): Control Dit proces controleert de interne vol- en leegsignalen. Dit proces kan de vol-enleegstatus van het geheugen kennen, omdat als het PInput proces een bit schrijft het geheugen niet meer leeg is. Zo is het geheugen ook niet meer vol zijn na het lezen door het POutput proces. Verder kan alleen het PInput proces merken dat het geheugen vol is (laatste plaats in het geheugen beschreven). Ook kan enkel het POutput proces beslissen dat het geheugen leeg is (laatste beschikbare bit uitgelezen). PInput Dit proces controleert het schrijven in het geheugen. Het kan enkel schrijven als de interne write-enable op 1 staat. En als de schrijfpointer p W zich op maar 1 positie achter de leespointer p R bevindt, signaleert het aan het Control proces dat het geheugen vol zit. Bij de volgende nieuwe bit zou immers de oudste niet gelezen bit verloren gaan. POutput Dit proces controleert het lezen uit het geheugen. Het kan enkel lezen als de interne read-enable op 1 staat. En als de leespointer p R zich maar op 1 positie achter de schrijfpointer p W. bevind, signaleert het aan Control proces dat het geheugen leeg is. Bij de volgende leespoging zou immers een oude, reeds uitgelezen waarden op de output komen.

4.2.2

Resultaten

Dit systeem van bufferen van bits werkte zoals verwacht. Het buffert alle bits tussen de twee zijden, aan twee verschillende kloksnelheden (figuur 4.6). Verder in het project bleek dit niet genoeg te zijn. Het circuit kan nooit weten wanneer de kaart (of kaartlezer) gestopt is met zenden. Er is dus geen manier te bepalen welke enable-signalen 37

4. Oplossing

Figuur 4.6: Voorbeeld van buffering door FIFO: De schrijfklok is trager dan de leesklok. De bits die op datain aan de lage klokfrequentie binnenkomen, worden op dataout aan de hogere klokfrequentie gereproduceerd, vanaf het moment dat de RE actief wordt. Vanaf dat de leespointer de schrijfpointer heeft ingehaald, komen de nieuwe bits maar aan de zelfde snelheid als de input, tussen de bits in is de FIFO leeg en de output ongedefinieerd.

actief moeten zijn. Als deze enable-signalen om die reden dan altijd actief zijn, zal dit bij 2 verschillende klokfrequenties voor lees- en schrijfklok ervoor zorgen dat de FIFO steeds vol is (schrijfklok heeft een hogere frequentie dan de leesklok) of steeds leeg is (schrijfklok heeft een lagere frequentie dan de leesklok). Hiernaast is het ook nodig om meer van het protocol te begrijpen dan enkel domweg bits door te schuiven. De belangrijkste redenen waarom het nodig is het T=0 communicatieprotocol te interpreteren zijn: Variatie van de kloksnelheid Om fouten in bewerkingen in de kaart te induceren via het extern kloksignaal, moeten we zo nauwkeurig mogelijk weten wanneer de kaart juist begint met de berekening waarin die bewerking zit. Het nauwkeurigste vaste punt voor de uitvoering van de instructie is het einde van de laatste bit van de laatste byte die de kaartlezer stuurt. Als de FPGA enkel weet heeft van bits, kan hij onmogelijk detecteren wanneer de communicatie is afgelopen, en de berekening begint. Interpretatie ATR De ATR geeft de kaart de mogelijkheid verschillende parameters van het communicatieprotocol te veranderen. Als de FPGA de ATR niet kan interpreteren, en de kaart wenst bepaalde parameters te veranderen, dan kan de FPGA de communicatie later niet meer volgen. Stel bijvoorbeeld dat de kaart de klokdelingsratio F naar een lagere waarde zet, dan gaat ze later in de communicatie sneller sturen dan wanneer ze de standaardwaarde zou gebruiken. De FPGA weet echter van niets en zal de bits fout interpreteren. Time-out management Als de bewerking in de kaart te lang duurt zal ze normaal gezien een WTX sturen, waardoor de kaartlezer de wachttijd reset. Werkt de kaart nu op een lagere kloksnelheid, dan zal de lezer sneller over de maximale wachttijd gaan, dan dat de kaart dit merkt. Hierdoor moet de FPGA een WTX naar de kaartlezer sturen die niet van de kaart zelf afkomstig is. Om deze reden moeten we weten in welk stadium van de communicatie de kaart zit (WTX is enkel te gebruiken als de kaart een berekening uitvoert) en hoeveel klokcycli er al voorbij zijn sinds de leading edge van de laatst gestuurde byte. Omwille van al deze argumenten stappen we over naar een bytegebaseerde aanpak in sectie 4.3. Het ontwikkelen van deze oplossing is echter niet tevergeefs geweest, dit bracht ons onontbeerlijke kennis bij over het schrijven van VHDL code, en leverde ons een goede ontwikkelings- en simulatieomgeving op (zie appendices B en C). 38

Oplossing 2: Bytestream

Laag niveau

Hoog niveau

Laag niveau

IOin

IOout Ser2Par

Mem

Par2Ser

Control

Legende Ser2Par bits naar bytes Control Interpretatie Mem Buffering van bytes Par2Ser bytes naar bits

Figuur 4.7: Basisidee van de bytegebaseerde aanpak

4.3


Omwille van de conclusies getrokken in de vorige sectie, stappen we in deze sectie over op een bytegebaseerde aanpak. Dit komt neer op een hoger niveau aanpak. De communicatie gaat eerst door blokken die de laagniveau aspecten afhandelen. Voorbij deze blokken gebeurt de controle, interpretatie en buffering dus op een hoger niveau, op byteniveau. Eén richting van de communicatie ziet er dan uit als in figuur 4.7. De serieel-naar-parallel-convertor (Ser2Par) zet de binnenkomende bitstroom (aan de juiste bitrate) om naar een bytestroom. De controller interpreteert deze bytestroom. Het geheugen (Mem) buffert deze data omdat Ser2Par en Par2Ser de data aan een verschillende snelheid produceren resp. consumeren. Om de data uiteindelijk naar de andere kant te krijgen, zet de parallel-naar-serieel-convertor (Par2Ser) de gebufferde bytestroom terug om naar een opeenvolging van bits, aan de juiste bitrate. Het volledig systeem dat alles heeft om aan de hoger beschreven eisen te voldoen, ziet er uit als in figuur 4.8. De volgende secties beschrijven de implementatie van de benodigde blokken.

4.3.1

Serieel naar parallel

Overbemonstering De eerste component in dit blok is een overbemonsteraar die de binnenkomende bitstroom 3 keer overbemonstert, op de tijdstippen 0.25 ETU, 0.5 ETU en 0.75 ETU (zie figuur 4.9). Hoewel deze bemonsteringsogenblikken niet de voorgestelde punten zijn, verkleint deze keuze de overhead van implementatie, zonder dat monsters in transistiezones vallen. Op deze manier moet het kloksignaal waarop de monsters genomen worden gelijk zijn aan: fOS = fET U × 4 = fklok ×

4 F

waarin fOS de overbemonsteringsklok is, fET U de bitrate is en fklok de klokfrequentie voor deze zijde van het circuit. Op deze manier is de overbemonsteringsklok dus eenvoudiger af te leiden van fklok dan wanneer de bemonstering gebeurt op de tijdstippen in figuur 2.4. Omdat 39

4. Oplossing

Klok Lezer IORin

Interne Klok MemR

Ser2ParR

Control IORout

Klok Kaart Par2SerC

ClkDivC

MemMgt

Mux

Mux

IOCout

Glitch

ClkDivR

Par2SerR

IOCin

Mux

MemC

Ser2ParC

Figuur 4.8: Volledig systeem: voor de duidelijkheid zijn enkel datasignalen weergeven. De streeplijnen zijn de grenzen van de aangegeven klokdomeinen 0.25 etu

t1

0.25 etu

t2

t3

1 etu

Figuur 4.9: Schets van de bemonsteringstijdstippen

veel van de mogelijke waarden voor F een veelvoud zijn van 4 treedt op deze manier geen klokvermenigvuldiging op, maar een eenvoudige klokdeling door een factor gelijk aan een vierde van F. De overbemonsterde bit aan de uitgang van de overbemonsteraar krijgt de waarde van de meerderheid van de monsters op t1, t2 en t3. De vertraging die deze blok veroorzaakt is 0.75 ETU, het Valid signaal geeft dit weer. Als Valid hoog is, is de overbemonsterde bit aan de uitgang geldig. Deze overbemonstering zorgt voor een manier om eventuele variaties in het signaal op te vangen. Figuur 4.10 geeft een voorbeeld van een signaal voor en na overbemonstering. Het OSBit signaal is het overbemonsterd signaal. Dit overbemonsteren stelt dit blok ook in staat de foutsignalen (zie sectie 2.3.2) die de zender stuurt te detecteren. Bij ontvangst van zo een foutsignaal signaleert dit blok het aan de overkoepelende Ser2Par blok via de signalen ErrorP1 en ErrorP2. Deze geven respectievelijk aan dat het eerste, dan wel het tweede deel van de foutsignalisatie ontvangen is. De monsters zien er bij ErrorP1, resp. ErrorP2 uit als 1-0 en 0-1, waarbij - een “don’t care” voorstelt, hier is het signaal immers in transitie. Deze monsters stemmen overeen met de dalende flank 40


V

Valid V

rstn V

datain V

OSBit V

ErrorP1 V

ErrorP2 0

1

2

3

4

5

6

7

8 tijd(ETU)

Figuur 4.10: Voorbeeld van overbemonsterd signaal en output van de overbemonsteraar. De kleine verdelingen zijn de bemonsteringstijdstippen, de grote zijn de ETU.

halverwege een ETU en een stijgende flank, halverwege een ETU.

Serieel naar parallel Dit blok zet uiteraard de bits die in het formaat gespecifieerd in 2.4 binnenkomen om naar zuivere databytes. Het neemt dus de asynchroon, serieel verstuurde “ingepakte” bytes van de lijn (na overbemonstering) en stript er alle bits af die niet tot de data zelf behoren. Hierbij controleert het de pariteit van de byte, vergelijkt deze met de pariteitsbit en als deze fout blijkt te zijn stuurt dit blok een heraanvraag naar de zender. Op deze manier eindigt hier het lage niveau; voorbij dit blok is de data zo correct mogelijk, zonder start-, pariteits- en stopbits. Deze blok bevat verder ook logica om te detecteren of de overbemonsteraar ErrorP1 en ErrorP2 meldt met maximum 1 ETU ertussen. Dit duidt op een foutsignaal van de andere zijde. Als dit foutsignaal aankomt, stuurt dit blok het naar de controller voor verdere verwerking.

4.3.2

Parallel naar serieel

Dit blok doet het tegengestelde van wat de serieel-naar-parallel-convertor Ser2Par doet. Het neemt bytes als input en pakt deze terug in als in figuur 2.5. Om een nieuwe byte aan de input te krijgen, zet dit blok het GetData signaal naar het geheugen blok op 1 als dit geheugenblok aangeeft dat het nog niet-uitgelezen data beschikbaar heeft (ReadyOut). Door de wederzijdse communicatie tussen deze blokken, zijn we zeker dat elke byte maar 1 keer op de lijn komt. Als de controller signaleert dat er een foutsignaal van de andere zijde ontvangen is, houdt dit blok de huidige byte bij om deze te herhalen, en leest geen nieuwe byte uit het geheugen. Op deze manier is een zo correct mogelijke transmissie te bereiken. Als laatste functionaliteit heeft dit blok ook de mogelijkheid aan te duiden wanneer het de laatste bit van de huidige byte verstuurt. Hiertoe moet het sigLastIn signaal op 1 staan. Als de laatste bit vertrekt gaat dan het sigLastOut signaal naar 1, en terug naar 0 als de laatste bit weg is. Dit is van groot belang voor de variatie op het klok signaal (zie ook paragrafen over het geheugenblok en de controller). Dit blok, samen met Ser2Par vormt dus de grens tussen het laag niveau (de bits, verpakken van bytes en foutcontrole) en het hoog niveau (dat zich enkel bekommert om de data zelf). 41

4. Oplossing

4.3.3

Geheugenblok

In een eerste poging om een geheugen met onafhankelijke schrijf- en lees-enable te hebben, diende een aanpassing van FIFO (zodat deze bytes opslaat ipv. bits) uit oplossing 1 als geheugen element. Die oplossing biedt meer mogelijkheden dan strikt nodig en was omslachtig om in te passen. Het huidige geheugenblok is een blok dat in het geheugen schrijft als het blok waarvan het zijn input krijgt (Ser2Par) aangeeft dat de byte op zijn uitgang geldig is (het Valid signaal) en dat het geheugenblok niet vol zit. De gegevens die het geheugen blok opslaat, bestaan uit de databyte, en het sigLastIn signaal voor de Par2Ser. Door deze bij de databyte op te slaan, moet de controller geen kennis hebben over hoe snel, en wanneer de bytes door Par2Ser verstuurt worden. De lees- en schrijfpointer (p W en p R) gaan na de laatste positie niet terug naar de eerste positie van het geheugen. Dit vereenvoudigt het design. Dit heeft wel als implicatie dat de lengte van het geheugen correct gedimensioneerd moet zijn. Elke boodschap in het T=0 protocol kan maximum 255 bytes lang zijn, dus dit is de lengte die we voor het geheugen blok kiezen. Het schrijven gebeurt gewoon telkens 1 positie verder dan de huidige, en als de laatste positie beschreven is, is het blok vol. Dit is het grote verschil met de FIFO, waar telkens een waarde gelezen is, zijn plaats vrijkomt. Het leegmaken van het blok is de taak van het geheugenmanagementblok (MemMgt, zie sectie 4.3.4). Het ReadyOut signaal geeft aan dat er nog ongelezen bytes in het geheugen zitten, en dat het Par2Ser-blok deze kan opvragen door het GetData signaal op 1 te zetten. Zodra de byte gelezen is, verschuift de leespositie naar de volgende byte. Als deze byte al beschreven is, gaat het ReadyOut signaal naar 1, anders blijft dit 0 om aan te duiden dat er geen nieuwe data meer beschikbaar is.

4.3.4

Geheugen- en activiteitsmanagement

Dit blok vervult een belangrijke taak in heel het systeem. Het maakt de geheugen blokken leeg als de boodschap die binnen gekomen is, ook volledig naar de andere zijde doorgestuurd is. Pas dan zijn de gegevens in het geheugen overbodig en mag het geheugen resetten. Tussen het binnenkomen van een boodschap en het terug vertrekken kunnen serieuze tijdsverschillen zitten omdat de beide zijden niet aan dezelfde klokfrequentie werken. De communicatie tussen de kaartlezer en de kaart volgt een strikt master-slave model. Dit wil zeggen dat de kaart nooit uit eigen initiatief iets stuurt, enkel als de kaartlezer daar het commando toe gegeven heeft. Daarom kan steeds slechts 1 zijde actief zijn. De controller gebruikt dit signaal om te weten van welke zijde hij data moet verwachten. In het VHDL-model houdt het ActiveSel signaal de actieve zijde bij. Om te weten wanneer van zijde te wisselen (en dus het geheugen dat in de vorige periode actief was, te resetten) telt dit blok het aantal bytes die binnenkomen, en het aantal bytes die buiten gaan. Zijn deze gelijk, dan is de communicatie compleet, en kan hij van actieve zijde wisselen. 42


WaitATR

SaveATR

RespPPS

T0 TA TB TC TD Tx TCK

PPS0 PPS1 PPS2 PPS3 PCK

Receive Data Stage1 Stage2 Stage3

PPS PPS0 PPS1 PPS2 PPS3 PCK

(a) FSMC

Receive Data Stage1 Stage2 Stage3

(b) FSMR

Figuur 4.11: Toestanden en subtoestanden in FSMC en FSMR

4.3.5

Controller

De secties die volgen zijn gestructureerd volgens de verschillende processen die het controller blok omvat. Deze processen zijn: FSMC Deze FSM (Finite State Machine) interpreteert de data komende van de kaart. Ze verwerkt de ATR, het antwoord op de PPS en het T=0 protocol aan de kant van de kaart. FSMR Deze FSM interpreteert de data komende van de kaartlezer. Ze verwerkt de PPS en het T=0 protocol, aan de kant van de kaartlezer. TIM Dit proces staat in voor het beheer van de time-outs als de kaart te traag werkt doordat de klok voorzien aan de kaart een lagere frequentie heeft dan de klokfrequentie van de kaartlezer. Om deze time-outs te voorkomen, stuurt dit proces een nep-WTX. Glitch Dit proces zorgt voor het omschakelen tussen de stabiele kloksnelheid en de veranderde kloksnelheid tijdens de glitch.

4.3.5.1

FSMC

De FSMC is de FSM die verantwoordelijk is voor de communicatie aan de kaartzijde. Deze FSM bevat als het ware voor elk deel van de communicatie een sub-FSM. Zo is zijn er voor de ontvangst van ATR, PPS, en T=0 aparte subtoestanden. Met deze subtoestanden bedoelen we dat binnen 1 toestand verschillende subtoestanden mogelijk zijn, terwijl een andere toestand andere subtoestanden heeft (figuren 4.11(a) en (b)). De volgende paragrafen leggen elk van deze toestanden uit. ATR interpretatie (RecvATR) De subtoestanden geassocieerd met het ontvangen van de ATR zijn T0, TA, TB, TC, TD, de historische karakters Tx en TCK. De toestand TS ontbreekt, de WaitATR toestand ontvangt deze, vooraleer over te schakelen naar de RecvATR toestand. Bij de bytes waar meerderen van zijn (de interface en historische karakters) houdt een teller bij welke byte net ontvangen is. De keuze voor deze subtoestanden is een evidentie, gezien de manier waarop de ATR gestructureerd is. Deze FSM is actief als de geheugenmanagementblok de kaart als actief aanduidt. Dit is de eerste FSM die actief wordt na een reset, ze moet immers de ATR die de kaart stuurt interpreteren. Die interpretatie is in de eerste plaats de interpretatie van de bytes die de structuur van de ATR 43

4. Oplossing

aangeven, als gespecifieerd in sectie 2.4.1. De T0 en TD(i) bytes duiden aan welke interface karakters er volgen, hoeveel historische karakters er zijn en wat het gespecifieerd protocol is. In de tweede plaats interpreteert deze FSM ook de waarden van de belangrijkste parameters in de ATR, namelijk de klokdelingsratio F, de bitrate-aanpassingsfactor D, de extra guard time N en de modi toegelaten voor een eventuele PPS. Andere parameters zijn ofwel overbodig geworden (die in verband met programmatiespanning), of niet van toepassing op het T=0 protocol (de specifieke interfacekarakters van andere protocollen). Als de ATR volledig ontvangen is, neemt de FSM deze in gebruik voor de erop volgende communicatie en signaleert deze aan de betrokken blokken: F en D voor Ser2Par en Par2Ser, N voor Par2Ser.

Antwoord op PPS (RespPPS) Bij de PPS zijn de subtoestanden de verschillende karakters van de PPS. De FSM ontvangt dit antwoord op PPS wel, maar gaat er vanuit dat de kaart alles aanneemt wat de kaartlezer voorstelt in de PPS, en dat het antwoord op de PPS dus een exacte kopie is van wat de lezer stuurde. In realiteit kan de kaart echter verzoeken van de kaartlezer weigeren door deze in het antwoord op de PPS weg te laten. De FSM zal zulk een antwoord op PPS structureel nog goed ontvangen, maar niet handelen naar de waarden die de kaart weigerde. Dit is niet ge¨ımplementeerd omdat een PPS niet veel voorkomt, en dus een niet volledig geaccepteerde PPS nog minder.

T=0, kant kaart (ReceiveData) De subtoestanden bij het verwerken van het T=0 protocol zijn de subtoestanden Stage1, Stage2 en Stage3. Wat juist in welke toestand valt, is te zien in figuur 4.12. De opsplitsing in de “stages” is een logische keuze: afhankelijk van de 4 gevallen ivm. databeschikbaarheid (zie sectie 2.5) komen bepaalde “stages” voor. Als de commando TPDU bijvoorbeeld geen dataveld bevat, schakelt FSMC direct van Stage1 naar Stage3, terwijl Stage2 niet uitgevoerd wordt. Na de ATR en PPS (als deze aanwezig is), interpreteert deze FSM het T=0 protocol beschreven in sectie 2.5. Het schema gevolgd door de FSM in dit stadium van de communicatie ziet er uit als in figuur 4.12. De reden dat in deze figuur takken terug komen, is dat de FSM van status wisselt om het ogenblik dat een nieuwe byte binnenkomt. Maar de tak die de communicatie volgt hangt soms af van de huidige byte. Vermits de FSM niet ogenblikkelijk van toestand kan wisselen, moet dezelfde functionaliteit meer dan één keer aanwezig zijn. Dit is bijvoorbeeld het geval bij het ontvangen van de header als de kaart gesignaleerd heeft dat ze data klaar heeft. Hier kan de FSM niet weten wat volgt: een nieuwe instructie of een GetRespons opdracht.

4.3.5.2

FSMR

Deze FSM heeft ongeveer dezelfde structuur, maar voorziet de communicatie aan lezerszijde. De toestanden en subtoestanden van deze FSM zijn weergegeven in figuur 4.11b. Deze FSM ontvangt dus de PPS en verwerkt de lezerszijde van het T=0 protocol (figuur 4.12).

PPS De PPS ontvangst is exact hetzelfde als de ontvangst van het antwoord op PPS in FSMC. Het enige verschil is dat FSMR de waarden uit de PPS effectief toepast in de FPGA 44


FSMR

Communication

FSMC

Command

Stage 1

Command

Stage 1

(zet P3 en INS)

Procedure Byte

Als P3~=0

Procedure Byte

Stage 2

P3=0

P3/=0

P3 ~=0

P3 =0

perByte = 0

perByte = 1

PB=INS

PB= not INS

(zet perByte=0)

(zet perByte=1)

PB=INS

PB= not INS

(zet perByte=0)

(zet perByte=1)

Data

Als perByte =1

Procedure Byte Tot DataComplete = 1

Data

Stage 2 Aantal bytes gestuurd = P3

WTX

WTX

(zet DataComplete = ’1’) WTX

Error of OK Data Ready

SW1||SW2

Data Ready

Stage1

Error of OK

(Zet NumData)

(Zet NumData)

Stage1

Stage 3

Stage 3 Als NumData ~= 0

ExpectData =1

ExpectData =0 P3/=0

Command

P3=0 WTX

niet GetRespons

GetRespons

(zet ExpectData=’0’)

(zet ExpectData=’1’)

Als ExpectData

Receive NumData+2 bytes.

PB=INS

PB= not INS

(zet perByte=0)

(zet perByte=1)

Data Ready

Error of OK

(Zet NumData)

Data||SW1||SW2 Stage 2

Stage 1

Stage 1

Stage 2

Stage 3

Stage1

Figuur 4.12: T=0 protocol zoals ge¨ımplementeerd in het controllerblok

voor verdere communicatie, terwijl FSMC enkel de bytes bijhoudt om te zien waar de PPS stopt en T=0 start. Nadat de PPS verstuurt van de kaartlezer ontvangen is, en de kaartlezer het antwoord op PPS gestuurd heeft zijn de nieuwe parameters van kracht.

T=0, kant lezer (ReceiveData) De lezerskant van het T=0 protocol is veel eenvoudiger dan de kaartkant. Dit is een gevolg van de master-slave configuratie van de communicatie. Dit deel van de FSM heeft echter nog een belangrijke taak: als het geheugen de laatste byte die de kaart zal ontvangen voor ze de uitvoering van de instructie start, opslaat, activeert deze FSM het sigLastIn signaal voor de parallel-naar-serieel convertor. Het geheugen slaat deze samen met de databyte op, zodat de Par2Ser weet dat hij de laatste bit van deze byte moet signaleren. Het doel van deze signalisatie wordt duidelijk in de paragraaf over de glitchgeneratie.

4.3.5.3

TIM

Dit proces telt het aantal klokcycli sinds het begin van de laatste byte komende van de kaartlezer. Dreigt het aantal klokcycli de WWT (geëncodeerd door TC2 uit de ATR, zie sectie 2.4) te 45

4. Oplossing

Control Selector Timeout DataController 1 IOCoutPSR

Par2Ser

ReadyOutC==’1’

Mux DatainC

DataMemC

0

MemC ReadyOut

GetData

ValidC

0

’0’

1

GetDataMemC

Figuur 4.13: WTX injectie systeem

overschrijden, dan zendt dit proces een nep-WTX byte (’60’) naar de kaartlezer. Hiermee simuleert de controller dat de kaart deze WTX stuurde omdat de uitvoering van een instructie te lang duurde. In realiteit gebeurt de time-out omdat de kaart werkt aan een lagere klokfrequentie dan de kaartlezer. Om dit WTX signaal te kunnen sturen schakelt dit proces de multiplexer die zich bevindt tussen enerzijds de Par2Ser aan de lezerszijde en anderzijds de controller en het geheugen om (figuur 4.13). De selector voor die multiplexer zorgt er eveneens voor dat het GetData signaal van het geheugen afschakelt. Normaal gezien is dit geen probleem, omdat de time-out nooit zou verlopen als er nog data in het geheugen zou zitten. Deze voorzorgsmaatregel is toch genomen opdat er ook geen byte zou verloren gaan als die net op hetzelfde ogenblik als de WTX vervanging zou aankomen. Om ervoor te zorgen dat de Par2Ser de WTX byte van de controller verstuurt, gaat ook het Ready signaal van het geheugen door de multiplexer. Van de controller komt ook een ReadyOut signaal dat steeds op 1 staat. Hierdoor vraagt de Par2Ser direct de databyte via GetData. Wanneer dit proces dit signaal ontvangt, weet het dat de WTX-byte goed vertrokken is en schakelt de multiplexer weer in de normale stand. 4.3.5.4

Glitch

Dit proces bekommert zich over de variatie van de kloksnelheid. De mogelijkheid van de Par2Ser om de laatste bit van de laatste byte voor uitvoering van de instructie in de kaart is erg belangrijk. Dit is immers de nauwkeurigste aanduiding van het begin van de berekening die we uit de communicatie kunnen halen. Na deze signalering van de laatste bit, telt dit proces het aantal klokcycli van een externe klok. Na een vooraf ingesteld aantal klokcycli (Offset) schakelt dit proces de kaartklok om van de normale snelheid naar de aangepaste snelheid. Deze verandering blijft aangehouden gedurende een vooraf ingesteld aantal klokcycli (Duration). Hierna schakelt dit proces de klok terug naar de stabiele klokfrequentie. De waarden van Offset en Duration zijn afhankelijk van de toepassing, van welke instructie we willen aanvallen. Hoe hoger de frequentie van deze externe klok, hoe kleiner de granulariteit en hoe groter de precisie met dewelke we een bepaalde bewerking kunnen aanvallen.

46

Hoofdstuk 5

Resultaten Samenvatting Dit hoofdstuk beschrijft de resultaten die uit deze thesis voort komen. Sectie 5.1 beschrijft de resultaten die uit de simulatie voortkomen. Sectie 5.2 geeft enkele theoretische beschouwingen rond de mogelijkheden van ons circuit. Sectie 5.3 beschrijft welke praktische resultaten deze thesis oplevert.

5.1

Simulatieresultaten

Deze sectie gaat in op de resultaten van de vele simulaties die we uitvoerden. Kort samengevat zijn de bereikte resultaten: Het interpreteren van de ATR, het interpreteren van de PPS, het interpreteren van het T=0 protocol en de variatie op het kloksignaal. De volgende secties verduidelijken deze resultaten. Een voorbeeld van signalen bekomen uit simulatie zijn te vinden in appendix A.

5.1.1

Linklaag communicatie

De laag-niveaucommunicatie verloopt zoals verwacht: de verschillende blokken zetten bits correct om naar byte, en andersom. De FPGA interpreteert eventuele foutsignalering, en herhaalt de foute bit. Bij foute ontvangst stuurt de FPGA zelf een foutsignaal. Zo zijn de databytes op hoger niveau in de FPGA bijna zeker correct. De communicatie tussen de twee klokdomeinen verloopt zoals gepland. Het enige verschil is dat bij het zenden van opeenvolgende databytes van de trage kant naar de snelle, de tijd tussen de bytes groter is dan normaal.

5.1.2

Interpretatie ATR

De FPGA interpreteert de ATR om de volgende communicatie te kunnen blijven volgen. Natuurlijk houdt de FPGA de structuur van de ATR bij, om te zien wanneer deze eindigt. De parameters die belangrijk zijn voor de communicatie zijn: 47

5. Resultaten

Klokdelingsratio F Deze geeft de verhouding tussen 1 ETU en een klokcyclus aan. Deze is van fundamenteel belang, vermits deze specifieert hoelang een bitinterval moet duren. Bitrateaanpassingsfactor D Deze speelt eveneens een grote rol in de timing van de bits, en specifieert samen met F de verhouding tussen klokcyclus en ETU. Guard time uitbreiding N Deze factor is belangrijk om tussen de bytes genoeg tijd te voorzien, zodat de kaart genoeg tijd per byte heeft om deze te verwerken. Work Waiting Time(WWT) De maximale tijd die mag verstrijken sinds het begin van de laatstgestuurde byte. Als de kaart niet binnen deze tijd antwoord, neemt de lezer aan dat er iets mis is, en reset de kaart. Dus het is erg belangrijk deze variabele te kennen, zodat de controller de WTX byte op tijd kan zenden. PPS mode specificatie Dit is belangrijk om te weten wanneer de nieuw afgesproken variabelen in werking treden. Als in de specific mode de nieuwe variabelen al direct na de ATR van kracht zijn, en de FPGA voorziet dit niet, loopt de hele verder communicatie mis. Deze parameters worden dus door de FSMC in het Controllerblok ge¨ınterpreteerd, en (afhankelijk van de PPS mode specificatie) toegepast na de ATR, dan wel na het antwoord op PPS.

5.1.3

Interpretatie PPS

De FPGA interpreteert de PPS aan lezerszijde en schakelt de parameters om naar de gevraagde parameters. Hierbij is echter geen rekening gehouden met het antwoord op de PPS van de kaart. De FPGA houdt er rekening mee dat het antwoord komt, maar zal niet handelen naar het al dan niet weglaten van bepaalde PPS bytes door de kaart. Deze keuze is gemaakt omdat een PPS al niet veel voorkomt, en het weigeren van een PPS nog minder. Voor de meeste applicaties zijn kaart en kaartlezer immers perfect op elkaar afgesteld.

5.1.4

Interpretatie T=0

De interpretatie van T=0 werkt in alle gevallen in simulatie zoals verwacht. Dus de FPGA weet juist in welk stadium van communicatie de kaart en kaartlezer zijn. Dit is niet enkel voor de interpretatie en het doorsturen van data van belang, maar ook voor het voorkomen van time-outs en het veranderen van de kloksnelheid, is het cruciaal exact te weten in welk stadium de communicatie is.

5.1.5

Time-out management

Het time-out mechanisme werkt in simulatie; net voordat de WWT verstreken is, stuurt de controller de WTX, en voorkomt hierbij de time-out. Dit mechanisme kan echter niet alle time-outs oplossen, vermits het sturen van een WTX enkel kan als de kaartlezer de kaart een instructie zond (en niet GetRespons). In dit geval kan er nog steeds een time-out optreden. Hetzelfde geldt voor situaties waar de kaartklok zo traag gaat dat de time-out optreed tussen de leidende flanken van 2 opeenvolgende bytes (zie ook sectie 5.2). 48

Theoretische beschouwingen

IOCin

S

databyte

P GT S

databyte

P GT

IORout

WTT=12ETU’

Figuur 5.1: Maximum voor ETU’ bij opeenvolgende bytes

5.1.6

Variatie kloksignaal

Dit werkt in simulatie ook zoals verwacht. Nadat de laatste bit van de laatste byte van de laatste boodschap van lezer naar kaart voor uitvoering van de instructie, start de teller. Als dan Offset klokcycli verlopen zijn, verandert de klok gedurende Duration klokcycli. Hierna schakelt de klok terug naar de standaard snelheid.

5.2

Theoretische beschouwingen

De tijd tussen opeenvolgende bytes komende van de kaart mag de WWT niet overschrijden. Figuur 5.1 toont de opeenvolging van databytes gezonden door de kaart, en hoe ons circuit deze aan een hogere bitrate naar de lezer stuurt. Vermits de tijd tussen de leidende flanken van twee bytes maximum WWT ETU (aan de lezersklokfrequentie) mag bedragen, geeft dit ons (bij de standaard waarde 10 voor WWI en 1 voor D) een bovengrens voor de verhouding flezer tot fkaart van 2400 : 12ET U 0 = W W T = 960 × D × W W I = 9600ET U → 1ET U 0 = 2400ET U Waarbij ETU’ de lengte van een bitinterval aan de kaartzijde is. Een tweede situatie kan zich voordoen als volgt: als de kaartlezer een GetRespons commando stuurt, kan de kaart dit niet beantwoorden met een PB, in onze interpretatie van de norm kan de kaart enkel een PB sturen als ze een instructie uitvoert, niet als het enkel om data ophalen gaat. Figuur 5.2 toont de signalen van kaartlezer naar FPGA (IORin), van FPGA naar de kaart (IOCout), van de kaart naar de FPGA (IOCin) en van de FPGA naar de kaartlezer (IORout). De berekening in deze tweede situatie levert ons een meer restrictieve bovengrens op: 22ET U 0 = W W T = 960 × D × W W I = 9600ET U → 1ET U 0 ' 436ET U We gaan ervan uit dat dit de kleinste bovengrens aan de verhouding tussen de kaartklok en de lezerklok binnen dit design. De klokfrequentie van de kaart kan dus theoretisch maximaal 436 keer lager zijn dan de klokfrequentie van de kaartlezer. In praktijk zal de bovengrens nog wat lager liggen, aangezien deze berekening abstractie maakt van de vertraging ge¨ıntroduceerd door ons circuit en van de responstijd van de kaart op de GetRespons instructie. 49

5. Resultaten

IORin

IOCout

S

GetRespons

P GT

12 ETU’ S

IOCin

Databyte 1

P GT

10 ETU’ IORout WWT = 12 + 10 ETU’

Figuur 5.2: Maximum voor ETU’ bij commando en antwoord

5.3 5.3.1

Praktische resultaten Levelshifting

Testen met de levelshifters wijzen uit dat ze in staat zijn snel genoeg te werken om de communicatie te volgen. Ze werken in beide richtingen, met een bij de gebruikte snelheden verwaarloosbare overshoot.

5.3.2

Real-life tests

Tot onze spijt zijn we wegens tijdsgebrek niet toegekomen aan het in hardware implementeren van het in deze thesis beschreven circuit.

50

Hoofdstuk 6

Conclusies en Perspectieven Samenvatting Dit hoofdstuk trekt besluiten uit deze thesis, en formuleert voorstellen omtrent verder onderzoek en ontwikkelingen die op deze materie kunnen gebeuren. Sectie 6.2 bespreekt de resultaten van deze thesis, welke conclusie deze met zich meebrengen. Sectie 6.1 stelt enkele punten voor waar deze thesis niet aan toe gekomen is.

6.1 6.1.1

Perspectieven Hardware

Een mogelijkheid van toekomstig werk is de herwerking van de geschreven VHDL code om te werken in hardware. Deze thesis heeft daar al een poging naar gedaan, maar is wegens tijdsgebrek ongetest gebleven. Hierom beperkten we onze conclusies tot de simulaties.

6.1.2

Andere nevenkanaalaanvallen

Het circuit in deze thesis beschreven houdt enkel rekening met het veranderen van de kloksnelheid en het beheer van de communicatie zodat deze transparant kan gebeuren. Het hier voorgestelde circuit kan dienen als platform om andere nevenkanaal aanvallen uit te voeren. De controller weet perfect in welk stadium de communicatie zich bevindt, en kan (analoog aan het variëren van de kloksnelheid van de kaart) mits kleine moeite ook andere aanvallen aansturen (zoals bijvoorbeeld een dip in het vermogen als de kaart in haar permanent geheugen schrijft). Het toevoegen van een nieuwe aanval is erg eenvoudig. Alles wat nodig is, is een FSM die ofwel op het laatste-bit-signaal triggert net als de glitch injectie, ofwel op een bepaalde instructie, die altijd al verschijnt op het INS signaal in de controller. Deze uitbreidingen kunnen ook zorgen voor een georchestreerd samenspel van foutinjectie aanvallen dankzij de nauwkeurige triggering net voordat de kaart een berekening start. 51

6. Conclusies en Perspectieven

6.1.3

Ander protocollen

Het circuit ontworpen in het kader van deze thesis interpreteert slechts het T=0 protocol. Dit protocol is echter niet het enige voorkomende; er zijn ook nog het gestandaardiseerde T=1 protocol, en niet-gestandaardiseerde T=14 en andere protocollen. Het toevoegen hiervan in de controller is een kwestie van een extra staat toe te voegen in FSMR en FSMC, en hierin de interpretatie van het nieuwe protocol onder te brengen. Op deze manier kan het circuit meer protocollen en dus ook meer kaarten ondersteunen.

6.2

Conclusies

Deze thesis toont aan dat wat we willen bereiken zeker theoretisch mogelijk is, en ook in simulatie werkt. Dus transparante communicatie doorheen verschillende kloksignalen is mogelijk, met het opvangen van time-outs. Als theoretische bovengrens voor de verhouding tussen de kaartklok en lezerklok is 436. De reële maximum verhouding ligt waarschijnlijk lager vermits de berekening de vertraging doorheen de FPGA, en de responssnelheid van de kaart niet in rekening brengt. Het circuit beschreven in deze thesis kan dienen als een framework om op accurate doch eenvoudige wijze nieuwe aanvallen op te stellen en deze te combineren met een meer nauwkeurige vermogenmeting dankzij de verlaagde kaartklokfrequentie.

52

Bibliografie [1] V. Menezes, van Oorschot, Handbook of Applied Cryptography. CRC Press, 2001, nr. ISBN: 0-8493-8523-7, gratis online beschikbaar (laatst gecontroleerd op 9/05/2009). [Online beschikbaar]: http://www.cacr.math.uwaterloo.ca/hac/ [2]

X. Wang, Y. L. Yin, en H. Yu, “Finding collisions in the full sha-1,” in In Proceedings of Crypto. Springer, 2005, pp. 17–36, laatst gecontroleerd: 22/05/09. [Online beschikbaar]: http://cryptome.org/wang sha1 v2.zip

[3] V. Klima, “Finding md5 collisions – a toy for a notebook,” Cryptology ePrint Archive, Report 2005/075, 2005, laatst gecontroleerd: 21/5/09. [Online beschikbaar]: http://eprint.iacr.org/2005/075 [4] M. Stevens, A. Sotirov, J. Appelbaum, A. Lenstra, D. Molnar, D. A. Osvik, en B. de Weger, “Short chosen-prefix collisions for md5 and the creation of a rogue ca certificate,” Cryptology ePrint Archive, Report 2009/111, 2009, laatst gecontroleerd: 21/05/09. [Online beschikbaar]: http://eprint.iacr.org/2009/111 [5] Iso magnetic stripe card standards. Laatst gecontroleerd: 9/5/2009. [Online beschikbaar]: http://www.cyberd.co.uk/support/technotes/isocards.htm [6] A. Johnson. (2008, oktober) U.s. credit cards becoming outdated, less usable abroad. Laatst gecontroleerd: 15/5/09. [Online beschikbaar]: http://www.creditcards.com/ credit-card-news/outdated-smart-card-chip-pin-1273.php [7] S. Drimer, S. J. Murdoch, en R. Anderson, “Thinking inside the box: systemlevel failures of tamper proofing,” University of Cambridge, Tech. Rep. ISSN: 1476-2986, 2008, laatst gecontroleerd: 15/5/09. [Online beschikbaar]: http: //www.cl.cam.ac.uk/techreports/UCAM-CL-TR-711.pdf [8] M. Aigner en E. Oswald, “Power analysis tutorial,” University of Technology Graz, Tech. Rep., laatst gecontroleerd: 15/5/09. [Online beschikbaar]: http: //www.iaik.tugraz.at/aboutus/people/oswald/papers/dpa tutorial.pdf [9] T. C. May en M. H. Woods, “A new physical mechanism for soft errors in dynamic memories,” San Diego, CA, USA, pp. 33–40, april 1978. [10] H. Bar-El, H. Choukri, D. Naccache, M. Tunstall, en C. Whelan, “The sorcerer’s apprentice guide to fault attacks,” Proceedings of the IEEE, vol. 94, Issue: 2, nr. ISSN: 0018-9219, pp. 370–382, 2006, laatst gecontroleerd: 15/5/09. [Online beschikbaar]: http://eprint.iacr.org/2004/100.pdf [11] W. E. W. Rankl, Smart Card Handbook, Third edition. John Wiley & Sons, Ltd, 2004, nr. ISBN: 0-470-85668-8. 53

Bibliografie

[12] ISO 7816-1:Identification cards – Integrated circuit(s) cards with contacts – Part 1: Physical characteristics, ISO Std., 1998. [13] ISO 7816-2:Identification cards – Integrated circuit cards – Part 2: Cards with contacts – Dimensions and location of the contacts, ISO Std., 2007. [14] ISO 7816-3:Identification cards – Integrated circuit cards – Part 3: Cards with contacts – Electrical interface and transmission protocols, ISO Std., Rev. Ammendement 2, 2006. [15] ISO 7810: Identification cards – Physical characteristics, ISO Std., 2003. [16] ISO 7813:Information technology – Identification cards – Financial transaction cards, ISO Std., 2006. [17] ISO 10536-3:Identification cards – Contactless integrated circuit(s) cards – Part 3: Electronic signals and reset procedures, ISO Std., 1996. [18] D. Boneh, R. DeMillo, en R. Lipton, “On the importance of checking cryptographic protocols for faults,” Lecture Notes in Computer Science, vol. 1233, pp. 37–51, 1997. [19] S. M. Ross, S. Moore, R. Anderson, P. Cunningham, R. Mullins, en G. Taylor, “Improving smart card security using self-timed circuits,” in Technology”, Fourth AciD-WG Workshop, Grenoble, ISBN, 2002, pp. 211–218. [Online beschikbaar]: http://www.cl.cam.ac.uk/∼swm11/research/smartcards.html

54

Bijlage A

Simulatieresultaten In deze appendix tonen we enkele simulaties van ons circuit.

A.1

Algemeen

In figuurA.1 is een normale communicatie tussen kaart en kaartlezer te zien. Eerst komt het IOCin signaal binnen in de Ser2Par aan kaartzijde. Deze overbemonstert de bits, en zet deze om in bytes, rekening houdende met de gebruikte conventie. dit resulteert in de bytes getoond in het datainC signaal. Signaal IORout toont het signaal na omzetting naar bits door Par2Ser aan lezerszijde. Merk op dat de bytes hier inderdaad met een grotere tussentijd aankomen, maar dat de waarde wel dezelfde is, zij het aan een andere bitrate. Nadat de lezer de ATR ontvangen heeft, stuurt deze een eerste (imaginair) commando, weer zien we de data eerst op het IORin signaal, daarna omgezet naar bytes in het datainR signaal, en tenslotte na omzetting naar de lagere bitrate, op IOCout. Merk verder ook het ActiveSel signaal op, dat aanduidt welke zijde actief is kaart (0) of kaartlezer (1). Om te controleren of alles naar behoren werkt, produceert de simulatie van de controller ook een “log” van wat er juist op welk tijdstip gebeurde. Deze log vindt u hieronder: 0 fs 0 fs

: FSMC: Reset controller FSM : ACT: Reset ACT process, Card is active

192 fs : FSMC: SSwaitATR (ts) : Received 0x3B, using direct convention 384 fs : FSMC: SSaveATR (t00) : T0 character is 00: Present characters: ; number of historical bytes = 0 Next ATR character is ta1 576 fs : FSMC: SSaveATR (ta1) : Received TA1: F,fmax = 1,NA (Testing usage only) , D = 1 : FSMC: SSaveATR (ta1) : Setting clockdivision factor to 4*64/64/4 =1 Finished reception of the ATR, switching to SReceiveData 616 fs : ACT: Activated by CardAct, set ActiveSel to Reader 976 fs : FSMR: CLA byte is 0x00 , a ISO 7816-4 class (files and security). 1072 fs : FSMR: INS byte is 0xA4

55

56

iocin=1 iorout=1 datainr[7:0]=UU UU iorin=1 iocout=1 activesel=0 getdatar=0 getdatac=0 glitch=0 memcreadyo=0 memrreadyo=0 rstnmemc=0 rstnmemr=0 siglastin=0 siglastoutc=0 siglastoutr=0 validc=0 validr=0

0 Time datainc[7:0]=UU UU 3B

10

81

00 A4 12 34 00

1 ps

2 ps 90

00

12 34 56 00

3 ps 61

4 ps 04

C0 12 34 04

A. Simulatieresultaten

Figuur A.1: Voorbeeld van simulatie data van hele circuit

Algemeen

1168 1264 1280 1360 1776 2144 2184 2336 2376 2584 2680 2776 2872 2888 2968 3376 3744 3784 3936 3976 4176 4272 4368 4464 4480 4560

fs fs fs fs fs fs fs fs fs fs fs fs fs fs fs fs fs fs fs fs fs fs fs fs fs fs

4976 5328 5368 5520 5712 5904 6096 6288

fs fs fs fs fs fs fs fs

6328 fs 6536 fs 6632 fs 6728 fs 6824 fs 6840 fs 6920 fs 7328 fs 7696 fs 7736 fs 7736 fs 7944 fs 7968 fs 8320 fs 8360 fs 8568 fs 8592 fs 8944 fs request 8984 fs 9192 fs

: FSMR: P1 byte is 0x12 : FSMR: P2 byte is 0x34 TimeoutEnable is now ’1’ : FSMR: P3 byte is 0x00 : ACT: Activated by ReaderAct, set ActiveSel to Card : FSMC: TimeoutEnable is now ’0’. 114 clockcycles of 153600 have passed. : FSMC: Received SW1||SW2 = 9000, execution OK : ACT: Activated by CardAct, set ActiveSel to Reader : FSMR: CLA byte is 0x00 , a ISO 7816-4 class (files and security). : FSMR: INS byte is 0x12 : FSMR: P1 byte is 0x34 : FSMR: P2 byte is 0x56 TimeoutEnable is now ’1’ : FSMR: P3 byte is 0x00 : ACT: Activated by ReaderAct, set ActiveSel to Card : FSMC: TimeoutEnable is now ’0’. 113 clockcycles of 153600 have passed. : FSMC: Received SW1||SW2 = 6104, 4 of databytes ready in card : ACT: Activated by CardAct, set ActiveSel to Reader : FSMR: CLA byte is 0x00 , a ISO 7816-4 class (files and security). : FSMR: INS byte is 0xC0 : FSMR: P1 byte is 0x12 : FSMR: P2 byte is 0x34 TimeoutEnable is now ’1’ : FSMR: P3 byte is 0x04 : FSMR: INS byte was 0xC0 = GetRespons, will receive numData bytes : ACT: Activated by ReaderAct, set ActiveSel to Card : FSMC: Received databyte 0xDE TimeoutEnable is now ’0’. 112 clockcycles of 153600 have passed. : FSMC: Received databyte 0xAD : FSMC: Received databyte 0xBE : FSMC: Received databyte 0xEF : FSMC: Received databyte 0x90 : FSMC: Received last byte SW2 0x00 Received 0x9000, OK as last word : ACT: Activated by CardAct, set ActiveSel to Reader : FSMR: CLA byte is 0x00 , a ISO 7816-4 class (files and security). : FSMR: INS byte is 0x12 : FSMR: P1 byte is 0x34 : FSMR: P2 byte is 0x45 TimeoutEnable is now ’1’ : FSMR: P3 byte is 0x05 : ACT: Activated by ReaderAct, set ActiveSel to Card : FSMC: Received inverted INS byte 0xED , request for one byte at a time. TimeoutEnable is now ’0’. 113 clockcycles of 153600 have passed. : ACT: Activated by CardAct, set ActiveSel to Reader : FSMR: Receiving one byte at a time : 0x01 : ACT: Activated by ReaderAct, set ActiveSel to Card : FSMC: Received inverted INS byte 0xED , request for one byte at a time. : ACT: Activated by CardAct, set ActiveSel to Reader : FSMR: Receiving one byte at a time : 0x02 : ACT: Activated by ReaderAct, set ActiveSel to Card : FSMC: Received non-inverted INS byte 0x12 , for all bytes at once. : ACT: Activated by CardAct, set ActiveSel to Reader : FSMR: Receiving all bytes at once : 0x03

57

A. Simulatieresultaten

9288 fs : FSMR: Receiving all bytes at once : 0x04 9304 fs TimeoutEnable is now ’1’ 9384 fs : FSMR: Received last byte 0x05 Set sigLastBit to 1 9600 fs : ACT: Activated by ReaderAct, set ActiveSel to Card 9968 fs : FSMC: Card asks for WTX 10008 fs WTX received: TimeoutEnable remains ’1’. 89 clockcycles of 153600 have passed. 10160 fs : FSMC: Card asks for WTX 10200 fs WTX received: TimeoutEnable remains ’1’. 24 clockcycles of 153600 have passed. 10352 fs : FSMC: 10392 fs TimeoutEnable is now ’0’. 24 clockcycles of 153600 have passed. 10544 fs : FSMC: Received SW1||SW2 = 0x9000: No further specification. 10584 fs : ACT: Activated by CardAct, set ActiveSel to Reader 10792 fs : FSMR: CLA byte is 0x00 , a ISO 7816-4 class (files and security). 10888 fs : FSMR: INS byte is 0x65 10984 fs : FSMR: P1 byte is 0x43 11080 fs : FSMR: P2 byte is 0x21 11096 fs TimeoutEnable is now ’1’ 11176 fs : FSMR: P3 byte is 0x04 11584 fs : ACT: Activated by ReaderAct, set ActiveSel to Card 11936 fs : FSMC: Received non-inverted INS byte 0x65 , request for all bytes at once. 11976 fs TimeoutEnable is now ’0’. 111 clockcycles of 153600 have passed. 11976 fs : ACT: Activated by CardAct, set ActiveSel to Reader 12184 fs : FSMR: Receiving all bytes at once : 0x31 12280 fs : FSMR: Receiving all bytes at once : 0x41 12376 fs : FSMR: Receiving all bytes at once : 0x59 12392 fs TimeoutEnable is now ’1’ 12472 fs : FSMR: Received last byte 0x26 Set sigLastBit to 1 12784 fs : ACT: Activated by ReaderAct, set ActiveSel to Card 13136 fs : FSMC: Card asks for WTX 13176 fs WTX received: TimeoutEnable remains ’1’. 99 clockcycles of 153600 have passed. 13328 fs : FSMC: 13368 fs TimeoutEnable is now ’0’. 24 clockcycles of 153600 have passed. 13520 fs : FSMC: Received SW1||SW2 = 0x6104: Length of data to expect is 4 13560 fs : ACT: Activated by CardAct, set ActiveSel to Reader 13760 fs : FSMR: CLA byte is 0x00 , a ISO 7816-4 class (files and security). 13856 fs : FSMR: INS byte is 0xC0 13952 fs : FSMR: P1 byte is 0x12 14048 fs : FSMR: P2 byte is 0x23 14064 fs TimeoutEnable is now ’1’ 14144 fs : FSMR: P3 byte is 0x00´ a´ a : FSMR: INS byte was 0xC0 = GetRespons, will receive numData bytes 14560 fs : ACT: Activated by ReaderAct, set ActiveSel to Card 14928 fs : FSMC: Received databyte 0x27 14968 fs TimeoutEnable is now ’0’. 114 clockcycles of 153600 have passed. 15120 fs : FSMC: Received databyte 0x18 15312 fs : FSMC: Received databyte 0x28 15504 fs : FSMC: Received databyte 0x18 15696 fs : FSMC: Received databyte 0x90 15888 fs : FSMC: Received last byte SW2 0x00 Received 0x9000, OK as last word

58

Algemeen

15928 fs : ACT: Activated by CardAct, set ActiveSel to Reader ./controller_tb:info: simulation stopped by --stop-time

59

Bijlage B

Computer hulpmiddelen Dit hoofdstuk beschrijft kort de verschillenden hulpmiddelen die gedient hebben om deze thesis tot stand te brengen. De voorkeur gaat uit naar open-source en gratis beschikbare software.

B.1

Versiemanagementsysteem

Voor versiemanagementsysteem viel onze keuze op Mercurial1 . Dit omdat het een snelle, efficiënte interface biedt tot verschillende versies, eenvoudig toe laat versies te vergelijken en terug te draaien, een handige webinterface biedt om versies op te volgen en een enorm eenvoudige manier biedt een snapshot van de huidige versie te maken. Alle bronbestanden voor deze thesis zijn beheerd door Mercurial.

B.2

Analoge simulatie

Voor de het ontwerp en simulatie van de analoge circuits (levelshifting, zie 4.1) is Linear Technologies LTSpice gebruikt. Dit pakket is gratis te downloaden op hun website2 . Dit programma biedt CAD voor elektrische circuits en een uitgebreide componentdatabase. Verder is het een Windows programma, dat door middel van Wine3 perfect op Linux werkt.

B.3

VHDL simulatie

Het schrijven van de VHDL code gebeurde in Vim4 omwille van de syntax-hilighting, en alle andere geavanceerde functies die deze editor biedt. 1

www.selenic.com/mercurial/ http://www.linear.com/designtools/software/ 3 http://winehq.org 4 http://www.vim.org/ 2

60

Typesetting

Het grootste deel van de VHDL simulatie gebeurt in GHDL5 , een open-source VHDL simulator geschreven in ADA. Vooraf gebruikten we freehdl6 maar dit bleek niet flexibel genoeg en was moeilijk in gebruik. De analyse en compilatie van alle blokken en de simulatie van alle testbenches zijn georchestreerd door GNU Make7 . Dit stelde ons samen met Mercurial ook in staat eenvoudig backups te maken, en huidige versies te op te laden voor controle.

B.4

Typesetting

Voor het schrijven van deze thesis, was de keuze voor LATEX 2ε 8 een evidentie omwille van de efficiëntie, het professionele resultaat, de tijd bespaart op de layout, de automatische nummering, enz. Het schrijven van de broncode gebeurde in Vim met de Vim-latexsuite plugin9 . Dit pakket biet ondanks zijn ouderdom nog steeds veel functionaliteiten voor het typen van LATEXcode in Vim. De bijna alle figuren zijn geproduceerd met Xfig10 , een licht vectorgraphics teken paket. De slimme en eenvoudige mechanismes die dit programma voorziet zijn een plezier bij het tekenen van diagrammen en schemas. De communicatievoorbeelden zijn gegenereerd met Mscgen11 . Hierbij was GNU Make weer bijzonder handig om alle vereisten tussen figuren, bronbestanden en refferenties te beheren, en opnieuw te genereren als er iets veranderd was. Het liet ook toe steeds de recentste versie van de tekst online te hebben.

5

http://ghdl.free.fr/ http://www.freehdl.seul.org/ 7 http://www.gnu.org/software/make/ 8 http://www.latex-project.org/ 9 http://vim-latex.sourceforge.net/ 10 http://www.xfig.org/ 11 http://www.mcternan.me.uk/mscgen/ 6

61

Bijlage C

Nevenontwikkelingen In de loop van dit project ontwikkelden we een aantal handige tools. Deze zijn puur informatief opgenomen in deze appendix.

C.1

Xpdfwrapper.lua

Dit klein programma voorziet een wrapper voor Xpdf1 dat de gebruiker toelaat zelf bookmarks te maken in een PDF. Dit programma is geschreven in murgaLua2 , een cross-platform Lua3 implementatie die een hele boel extra’s aan boord heeft (FLTK GUI, Sqlite database engine, LuaSocket, . . . ). Dit programma staat online op http://jpjacobs.ulyssis.org/scripts/xpdfwrapper.lua (25/05/09).

C.2

signalmaker.lua

Dit Lua programma heeft als doel het omzetten van een bit/byte string naar VHDL. Het maakt gebruik van optparse.lua4 voor het verwerken van commandolijn opties. Het oproepen van het programma gebeurt als volgt: signalmaker.lua -m <mode> Waarin clock 1 ETU vertegenwoordigt, in eenheden units. De datastring hangt af van de modus. De verschillende modi die het programma ondersteunt zijn: hex Neem een bytestring (in hexadecimale karakters,bv. AB01 12) als input, en genereer een bytesignaal (type <=X"00" after 0 ns, X"11" after 10 ns, . . . ) bit Neem een bitstring (“0010 0111”) en genereer een bit signaal, bijvoorbeeld <= ’1’ after 0 ns,’0’ after 10 ns,... 1

http://www.foolabs.com/xpdf/ http://www.murga-projects.com/murgaLua/ 3 http://www.lua.org 4 http://lua-users.org/wiki/CommandLineParsing 2

62

signalmaker.lua

htb De naam van modus staat voor Hex-to-Bit: het zet een bytestring in hexadecimale karakters om naar een bit string. De omzetting van bytes naar bits gebeurt volgens de conventie gespecifieerd met -c Voor de volledige help, gebruik signalmaker.lua --help. Dit programma is online te vinden op: http://jpjacobs.ulyssis.org/scripts/signalmaker.lua

63

Flexibele aansturing voor ISO-7816

Recommend Documents