FEDERALE OVERHEIDSDIENST INFORMATIE- EN COMMUNICATIETECHNOLOGIE

7 DECEMBER 2006. - Koninklijk besluit tot vaststelling van de specificaties en registratieprocedure van de leesapparatuur voor de elektronische identiteitskaart en tot wijziging van het koninklijk besluit van 13 februari 1998 houdende specificaties van de leesapparatuur voor de sociale identiteitskaart

Verslag aan de Koning Sire, Het ontwerp van koninklijk besluit dat wij de eer hebben Uwe Majesteit voor te leggen, strekt ertoe artikel 6quinquies van de wet van 19 juli 1991 betreffende de bevolkingsregisters en de identiteitskaarten en tot wijziging van de wet van 8 augustus 1983 tot regeling van een Rijksregister van de natuurlijke personen, ingevoegd bij wet van 25 maart 2003 uit te voeren. Voormeld artikel voorziet dat normen en functionele en technische specificaties kunnen worden vastgelegd waaraan de apparatuur (de kaartlezer) en de toepassingen moeten voldoen teneinde het uitlezen en het bijwerken van de elektronisch op de identiteitskaart opgeslagen gegevens mogelijk te maken.

Het vastleggen van normen en van technische en functionele vereisten is, in het belang van de gebruikers van de elektronische identiteitskaart en de diverse toepassingen, wenselijk. Wanneer men het gebruik van de elektronische identiteitskaart wil stimuleren dan dient men er voor te zorgen dat er voldoende kaartlezers in omloop zijn die de elektronische identiteitskaart kunnen lezen.

Om bij de gebruiker geen twijfel te laten bestaan welke lezers verenigbaar zijn met de elektronische identiteitskaart wordt er een vrije registratieprocedure voorzien voor leveranciers van verenigbare leesapparatuur. Via de procedure kan de conformiteit van de apparatuur met de vastgestelde normen en specificaties worden gecontroleerd zodat aan de gebruiker en de potentiële koper ervan de waarborg kan worden geboden dat de apparatuur juist functioneert. Via een label wordt de conformiteit van een kaartlezer aan de voormelde standaarden bevestigd.

Tenslotte beoogt de registratieprocedure via de toekenning van een label te vermijden dat apparatuur wordt gebruikt die de elektronische identiteitskaart zou kunnen beschadigen.

Het gebruik van het label, als merk gedeponeerd, door leveranciers van leesapparatuur wordt aan bepaalde minimale voorwaarden onderworpen. De specificaties van het label evenals de gebruiksvoorwaarden die daarop betrekking hebben, worden als bijlage bij het ontwerp van dit besluit opgenomen.

Er moet worden gestreefd naar een maximale interoperabiliteit van de diverse kaartlezers; anders gesteld dient de overheid ervoor te zorgen dat de kaartlezers die de elektronische identiteitskaart kunnen lezen ook andere kaarttypes die worden gebruikt in de relatie met de overheid, in het bijzonder de sociale identiteitskaart, kunnen lezen.

Vandaar dat ervoor wordt gekozen om dezelfde registratieprocedure te hanteren als degene die momenteel gebruikt wordt voor de leveranciers van leesapparatuur voor de sociale identiteitskaart. Omwille van duidelijkheidsredenen wordt er daarom geopteerd om beide registratieprocedures via één en hetzelfde besluit te regelen. Hiertoe wordt via dit besluit het koninklijk besluit van 13 februari 1998 houdende specificaties van de leesapparatuur voor de sociale identiteitskaart gewijzigd.

De registratieprocedure kan kort worden omschreven als volgt : De leverancier van de leesapparatuur dient tegenover de overheid de verenigbaarheid te kunnen aantonen met de functionele specificaties en de normalisatienormen, die als bijlage bij dit koninklijk besluit zijn opgenomen.

Bij bewijs van verenigbaarheid wordt de leverancier door de overheid geregistreerd en voorziet de leverancier vervolgens zijn leesapparatuur van een elektronisch registratienummer en een daartoe bestemd label.

De lijst van verenigbare leesapparatuur, alsook de specificaties betreffende deze lezers, is tevens op de website van de bevoegde overheid te raadplegen.

Wij hebben de eer te zijn, Sire, van Uwe Majesteit de zeer eerbiedige en zeer getrouwe dienaren, De Minister van Binnenlandse Zaken, P. DEWAEL De Minister van Economie, M. VERWILGHEN De Minister van Sociale Zaken, R. DEMOTTE De Minister van Middenstand en Landbouw, Mevr. S. LARUELLE De Minister van Werk, P. VANVELTHOVEN

7 DECEMBER 2006. - Koninklijk besluit tot vaststelling van de specificaties en registratieprocedure van de leesapparatuur voor de elektronische identiteitskaart en tot wijziging van het koninklijk besluit van 13 februari 1998 houdende specificaties van de leesapparatuur voor de sociale identiteitskaart ALBERT II, Koning der Belgen, Aan allen die nu zijn en hierna wezen zullen, Onze Groet.

Gelet op de wet van 19 juli 1991 betreffende de bevolkingsregisters en de identiteitskaarten en tot wijziging van de wet van 8 augustus 1983 tot regeling van een Rijksregister van de natuurlijke personen, inzonderheid op artikel 6quinquies, ingevoegd bij wet van 25 maart 2003;

Gelet op de wet van 26 juli 1996 tot modernisering van de sociale zekerheid en tot vrijwaring van de leefbaarheid van de wettelijke pensioenstelsels, inzonderheid op artikelen 41 en 49;

Gelet op het koninklijk besluit van 18 december 1996 houdende maatregelen met het oog op de invoering van een sociale identiteitskaart ten behoeve van alle sociaal verzekerden, met toepassing van de artikelen 38, 40, 41 en 49 van de wet van 26 juli 1996 houdende de modernisering van de sociale zekerheid en tot vrijwaring van de wettelijke pensioenstelsels, bekrachtigd bij de wet van 26 juni 1997, inzonderheid op artikel 4, derde lid;

Gelet op het koninklijk besluit van 13 februari 1998 houdende specificaties van de leesapparatuur voor de sociale identiteitskaart;

Gelet op het advies van de Inspectie van Financiën, gegeven op 14 mei 2006;

Gelet op de akkoordbevinding van Onze Minister van Begroting gegeven op 30 juni 2006;

Gelet op het advies van de Kruispuntbank van de sociale zekerheid, gegeven op 26 september 2006;

Gelet op het feit dat is voldaan aan de formaliteiten voorgeschreven door Richtlijn 98/34/EG van 22 juni 1998 van het Europees parlement en de Raad betreffende de informatieprocedure op het gebied van normen en technische voorschriften;

Gelet op advies 40.903/1/Vvan de Raad van State, gegeven op 3 augustus 2006, met toepassing van artikel 84, § 1, eerste lid, 1°, van de gecoördineerde wetten op de Raad van State;

Op de voordracht van Onze Minister van Binnenlandse Zaken, Onze Minister van Economie, Onze Minister van Sociale Zaken en Volksgezondheid, Onze Minister van Middenstand en Landbouw en van Onze Minister van Werk, en op het advies van Onze in Raad vergaderde Ministers, Hebben Wij besloten en besluiten Wij :

Artikel 1.Het opschrift van het koninklijk besluit van 13 februari 1998 houdende specificaties van de leesapparatuur voor de sociale identiteitskaart wordt vervangen als volgt : "Koninklijk besluit tot vaststelling van de specificaties en de registratieprocedure van de leesapparatuur voor de elektronische identiteitskaart en de sociale identiteitskaart".

Art. 2.In artikel 1 van hetzelfde koninklijk besluit worden de volgende wijzigingen aangebracht : a) in het tweede streepje worden de woorden : " -"leverancier" : iedere persoon die leesapparatuur fabriceert, rechtstreeks of onrechtstreeks verdeelt, of die instaat voor het onderhoud van het hele of een deel van het leesapparaat dat dient om gegevens uit te lezen of te schrijven op de sociale identiteitskaart" vervangen door de woorden " -"leverancier" : iedere persoon die leesapparatuur fabriceert, rechtstreeks of onrechtstreeks verdeelt, of die instaat voor het onderhoud van het hele of een deel van het leesapparaat dat dient om gegevens uit te lezen of te schrijven op de sociale identiteitskaart en/of op de elektronische identiteitskaart;"; b) een derde streepje wordt toegevoegd, luidend als volgt : "- "wet" : Wet van 19 juli 1991 betreffende de bevolkingsregisters en de identiteitskaarten en tot wijziging van de wet van 8 augustus 1983 tot regeling van een Rijksregister van de natuurlijke personen.»

Art. 3.Artikel 2 van hetzelfde besluit wordt vervangen als volgt : "De leesapparatuur bedoeld in artikel 4, derde lid, van het koninklijk besluit of in artikel 6quinquies van de wet moet voldoen aan de toepasselijke functionele specificaties en aan de toepasselijke in bijlage beschreven normalisatienormen, opdat de identiteitskaarten zouden kunnen worden gebruikt".

Art. 4.In artikel 3 van hetzelfde besluit worden in de eerste zin de woorden "voor gebruik van de sociale identiteitskaart" toegevoegd tussen de woorden "van de bevoegde personen," en "kunnen de volgende documentatie bekomen".

Art. 5.Een artikel 3bis wordt in hetzelfde besluit ingevoegd, luidend als volgt : "De leveranciers die deze leesapparatuur ter beschikking wensen te stellen voor gebruik van de elektronische identiteitskaart, kunnen de volgende documentatie bekomen bij de Federale overheidsdienst Informatie- en Communicatietechnologie : 1° specificaties van het systeem van de elektronische identiteitskaart, 2° beschrijving van de commando's nodig voor het lezen en schrijven van de elektronische identiteitskaart, 3° beschrijving van de procedure voor het online testen van de elektronische identiteitskaart, 4° proefexemplaren van de elektronische identiteitskaart."

Art. 6.In artikel 4 van hetzelfde besluit worden de volgende wijzigingen aangebracht : a) in de eerste zin worden de woorden "van de bevoegde personen" en "bij de Kruispuntbank van de sociale zekerheid" geschrapt;b) in de bepaling onder 2° worden de woorden "met betrekking tot de naleving van de ISO-norm 7816 - 1 tot 4, en anderzijds met betrekking tot de naleving van de technische en functionele specificaties en van de kwaliteits- en performantiecriteria die in bijlage worden vermeld" vervangen door de woorden "met betrekking tot de naleving van de relevante delen van de ISO-norm 7816, en anderzijds met betrekking tot de naleving van de toepasselijke technische en functionele specificaties en van de toepasselijke kwaliteits- en performantiecriteria in bijlage I bij dit besluit".

Art. 7.Een artikel 4bis wordt in hetzelfde besluit ingevoegd, luidend als volgt : «

Art. 4bis.§ 1. De leverancier dient zijn referentiedossier in : 1° bij de Kruispuntbank van de sociale zekerheid voor zover enkel een registratienummer wordt aangevraagd voor een leesapparaat dat dient om gegevens uit te lezen en/of te schrijven op de sociale identiteitskaart;2° bij de Federale overheidsdienst Informatie- en Communicatietechnologie voor zover enkel een registratienummer wordt aangevraagd voor een leesapparaat dat dient om uitsluitend gegevens uit te lezen en/of te schrijven op de elektronische identiteitskaart. § 2. Indien gelijktijdig een registratienummer wordt aangevraagd voor een leesapparaat dat dient om zowel op de sociale identiteitskaart als op de elektronische identiteitskaart gegevens uit te lezen en/of te schrijven, dient de leverancier twee aparte referentiedossiers in en duidt telkens aan dat het gaat om een gelijktijdige registratieprocedure.

De Kruispuntbank van de sociale zekerheid en de Federale overheidsdienst Informatie- en Communicatietechnologie informeren elkaar onverwijld van de gelijktijdige neerlegging door de leverancier. » § 3. De aanvraag tot registratie van een leesapparaat voor de elektronische identiteitskaart geschiedt aan de hand van het modelformulier vastgesteld in bijlage II bij dit besluit.

Art. 8.In artikel 5 van hetzelfde besluit worden de volgende wijzigingen aangebracht : a) de eerste zin wordt vervangen als volgt : "De Kruispuntbank van de sociale zekerheid of de Federale overheidsdienst Informatie- en Communicatietechnologie na eensluidend advies van de Federale Overheidsdienst Binnenlandse zaken, kent binnen een periode van 45 kalenderdagen na ontvangst van het referentiedossier een registratienummer toe aan elk ingediend referentiedossier, voor zover het de in artikel 4 vermelde stukken omvat en daaruit blijkt dat aan de in artikel 2 vermelde voorwaarden is voldaan";b) de tweede zin wordt vervangen als volgt : "De leverancier die een referentiedossier indient, verbindt er zich toe, het door de Kruispuntbank van de sociale zekerheid en/of de Federale overheidsdienst Informatie- en Communicatietechnologie toegekend registratienummer op elektronische wijze in de leesapparatuur te brengen.Voor wat betreft de leesapparatuur voor gebruik van de elektronische identiteitskaart verbindt de leverancier zich er bovendien toe, volgens de in bijlage II bij dit besluit voorziene specificaties, op een zichtbare wijze elke geregistreerd leesapparaat van een label te voorzien."

Art. 9.Een artikel 5bis wordt in hetzelfde besluit ingevoegd, luidend als volgt : «

Art. 5bis.De Kruispuntbank van de sociale zekerheid, wat betreft de sociale identiteitskaart, en de Federale overheidsdienst Informatie- en Communicatietechnologie, wat betreft de elektronische identiteitskaart, beschikken over het recht om de geregistreerde leesapparatuur aan een grondige controle te onderwerpen bij klacht of vermoeden van niet-overeenstemming van het leesapparaat met het ingediende referentiedossier. »

Art. 10.In artikel 6 van hetzelfde besluit wordt het tweede lid vervangen als volgt "De leverancier die een referentiedossier heeft ingediend, verbindt zich ertoe de door hem geïnstalleerde leesapparatuur aan te passen ingeval de functionele specificaties en de normalisatienormen die hem door de Kruispuntbank van de sociale zekerheid en/of de Federale overheidsdienst Informatie- en Communicatietechnologie worden meegedeeld, evolueren."

Art. 11.In artikel 6bis van hetzelfde besluit worden de volgende wijzigingen aangebracht : a) het eerste lid wordt vervangen als volgt : "Elke wijziging van de functionele specificaties, die wordt meegedeeld door de Kruispuntbank van de sociale zekerheid en/of de Federale overheidsdienst Informatie- en Communicatietechnologie, wordt geregistreerd bij de Kruispuntbank van de sociale zekerheid, wat betreft de leesapparaten voor de sociale identiteitskaart, en/of de Federale overheidsdienst Informatie- en Communicatietechnologie, wat betreft de leesapparaten voor de elektronische identiteitskaart."; b) het tweede lid wordt vervangen als volgt : "De termijn tussen de levering van de nieuwe functionele specificaties door de Kruispuntbank van de sociale zekerheid en/of de Federale overheidsdienst Informatie- en Communicatietechnologie en de mogelijkheid om de aanpassingen af te laden bij de gebruikers van de leesapparatuur mag drie maanden niet overschrijden."; c) het derde lid wordt vervangen als volgt : "Het referentiedossier met betrekking tot de nieuwe functionele specificaties wordt voorgelegd op de wijze zoals bepaald in artikel 4bis van dit besluit door de indiener van het oorspronkelijke registratiedossier."; c) In het vierde lid worden de woorden ", wat de Kruispuntbank voor de sociale zekerheid betreft," ingevoegd tussen de woorden "omvat" en "de volgende elementen";e) een vijfde lid wordt toegevoegd, luidend als volgt : "Het referentiedossier omvat, wat de Federale overheidsdienst Informatie- en Communicatietechnologie betreft, de volgende elementen die tot de verantwoordelijkheid van de indiener behoren : 1.documentatie van de procedures tot aflading van de nieuwe functionele specificaties op de leesapparatuur; 2. gebruikershandboek aan de hand waarvan de gebruiker van de leesapparatuur de nieuwe functionele specificaties in alle veiligheid kan afladen op zijn leesapparatuur;3. modelonderhoudscontracten; 4. demonstratie van de aflading van de nieuwe versie op elk type geregistreerde leesapparatuur."

Art. 12.Artikel 7 van hetzelfde besluit wordt vervangen als volgt : «

Art. 7.De leverancier die een registratienummer heeft ontvangen, verbindt zich ertoe met alle passende middelen de Kruispuntbank van de sociale zekerheid en/of de Federale overheidsdienst Informatie- en Communicatietechnologie bij te staan, teneinde de oorzaak van eventuele werkingsproblemen van de geregistreerde kaartlezer en/of de daarbij horende software of van vervalsing van de sociale identiteitskaarten en/of elektronische identiteitskaarten te kunnen opsporen. »

Art. 13.Artikel 8 van hetzelfde besluit wordt vervangen als volgt : «

Art. 8.Iedere persoon die gemachtigd is om de sociale identiteitskaart en/of de elektronische identiteitskaart te gebruiken, kan bij de Kruispuntbank, wat betreft de leesapparaten voor de sociale identiteitskaart, en bij de Federale overheidsdienst Informatie- en Communicatietechnologie, wat betreft de leesapparaten voor de elektronische identiteitskaart, de lijst van de referentiedossiers alsook de referentiedossiers van de modellen van leesapparatuur raadplegen zoals die door de leveranciers werden ingediend, met inbegrip van de vermeldingen van gelijkwaardigheid ten opzichte van de technische specificaties, de performantie- of kwaliteitscriteria. »

Art. 14.Artikel 9 van hetzelfde besluit wordt gewijzigd als volgt : " Onze Minister van Sociale Zaken en Volksgezondheid, Onze Minister van Binnenlandse zaken, Onze Minister van Economie, Onze Minister van Middenstand en Landbouw en onze Minister van Werk zijn, elk wat hen betreft, belast met de uitvoering van dit besluit."

Art. 15.De bij dit besluit gevoegde bijlage I vervangt de bijlage bij het koninklijk besluit van 13 februari 1998 houdende specificaties van de leesapparatuur voor de sociale identiteitskaart.

De bij dit besluit gevoegde bijlagen II en III worden toegevoegd als bijlagen II en III aan hetzelfde koninklijk besluit.

Art. 16.Dit besluit treedt in werking de dag waarop het in het Belgisch Staatsblad wordt bekendgemaakt.

Art. 17.Onze Minister van Binnenlandse Zaken, Onze Minister van Economie, Onze Minister van Sociale Zaken en Volksgezondheid, Onze Minister van Middenstand en Landbouw en Onze Minister van Werk, zijn, elk wat hen betreft, belast met de uitvoering van dit besluit.

Gegeven te Brussel, 7 december 2006.

ALBERT Van Koningswege : De Minister van Binnenlandse Zaken, P. DEWAEL De Minister van Economie, M. VERWILGHEN De Minister van Sociale Zaken, R. DEMOTTE De Minister van Middenstand en Landbouw, Mevr. S. LARUELLE De Minister van Werk, P. VANVELTHOVEN

Bijlage I Inhoudsopgave Art. 1er.

Registratieprocedure lezers 1. Inleiding 1.1. Doel van de bijlagen 1.2. Reikwijdte 1.3. Lezerscategorieën 1.4. Platformen 1.5. Omgeving 2. Vereisten en specificaties 2.1. Model- en beveiligingsvereisten 2.2. Vereisten voor de kaartinterface 2.3. Vereisten voor de gebruikersinterface 2.4. Vereisten voor de applicatie-interface 2.5. Specifieke vereisten 3. Low-level testscenario's 3.1. ISO7816/APDU-scenario 3.2. Datacaptatiescenario 3.2.1. Kaartversie en RRN-certificaat 3.2.2. Identiteit, adres en foto 3.2.3. PIN controleren 3.3. Cryptoki/PKCS(11-scenario 3.3.1. Initialiseren library, slot en token 3.3.2. Handtekening aansturen met authenticatiesleutel 3.3.3. PIN wijzigen 3.3.4. Handtekening aansturen met handtekeningsleutel 3.3.5. PIN wijzigen 4. High-level valideringsscenario's 4.1. Scenario I :installatie/desinstallatie en Plug&Play 4.1.1. Precondities 4.1.2. Controledoelstellingen 4.1.3. Postcondities 4.2. Scenario II : sterke authenticatie 4.2.1. Precondities 4.2.2. Controledoelstellingen 4.2.3. Postcondities 4.3. Scenario III : datacaptatie en wijziging PIN 4.3.1. Precondities 4.3.2. Controledoelstellingen 4.3.3. Postcondities 4.4. Scenario IV : electronische handtekening 4.4.1. Precondities 4.4.2. Controledoelstellingen 4.4.3. Postcondities Art. 2.

Specificaties van de kaartlezers 1. Compatibiliteit van de hardware met de chip 2.Compatibiliteit van de software met de chip 2.1. Alle lezers 2.2. Lezers met pinpad 2.2.1. Te implementeren kaartcommando's (APDU) 2.2.2. Te implementeren lezercommando's (APDU) 2.2.3. PIN-formaat 3. Compatibiliteit van de software met de middleware 3.1. PC/SC drivers 3.2. Integratie met de middleware 3.2.1. SCR_Init ( ) 3.2.2. SCR_VerifyPIN( ) 3.2.3. SCR_ChangePIN( ) 3.3. Display 3.3.1. SCR_VerifyPIN( ) 3.3.2. SCR_ChangePIN( ) Art. 3.

Specificaties Identity Middleware 1. Inleiding 1.1. Matrix ontwikkelingsomgeving 2. Functionele specificaties 2.1. Versies en compatibiliteit 2.2. Ingeven PIN 2.3. Opmerking over de maximumlengte van de parameters 2.4. Multi-threaded applicatie 2.5. API-organisatie 2.6. Functies voor initialisatie en beëindiging 2.6.1. BEID_Init 2.6.2. BEID_Exit 2.7. Identiteitsfuncties 2.7.1. BEID_GetID 2.7.2. BEID_GetAddress 2.7.3. BEID_GetPicture 2.7.4. Offline identiteitsfuncties 2.7.4.1. BEID_GetRawData 2.7.4.2. BEID_SetRawData 2.8. Algemene high-level functies 2.8.1. BEID_BeginTransaction 2.8.2. BEID_EndTransaction 2.8.3. BEID_SelectApplication 2.8.4. BEID_ReadFile 2.8.5. BEID_WriteFile 2.8.6. BEID_VerifyPIN 2.8.7. BEID_ChangePIN 2.8.8. BEID_GetPINStatus 2.9. Low-level functies 2.9.1. BEID_GetVersionInfo 2.9.2. BEID_SendAPDU 2.9.3. BEID_FlushCache 2.10. Identificatie PIN 2.10.1. Types PIN 2.10.2. Gebruik PIN 2.11. OCSP en CRL input policy parameters 2.12. Status van de functies 2.12.1. Algemene return-codes 2.13. Controle handtekening en validering certificaten 2.13.1. Controle handtekening 2.13.2. Controle certificaat en validatieresultaten 2.13.3. Genruikte OCSP et CRL policies 3. Programmeerinterfaces 3.1. C API 3.1.1. Structures 3.1.2. Functions 3.2. Java API 3.2.1. Data Classes 3.2.2. Main Classe 3.2.3. Applet Classe 3.3. ActiveX API 3.3.1. Interfacedefinities 3.3.2. Functies 4. Installatie 4.1. Installatiepakket 4.2. Runtime 4.3. C Library 4.4. Java Art. 3bis Specificaties Crypto Middleware 1. Doel 2.Architectuur 2.1. Interfaces 2.1.1. De CRYPTO API-Interface 2.1.1.1. CSP high-level architectuur 2.1.1.2. CSP low-level architectuur 2.1.2. De PKCS(11-interface 2.1.2.1. PKCS(11 high-level architectuur 3. Programmeurshandleiding 3.1. Inleiding 3.2. De Crypto API-Interface 3.2.1. CryptAcquireContext 3.2.2. CryptReleaseContext 3.2.3. CryptGenerateKey 3.2.4. CryptDeriveKey 3.2.5. CryptDestroyKey 3.2.6. CryptSetKeyParam 3.2.7. CryptGetKeyParam 3.2.8. CryptSetProvParam 3.2.9. CryptGetProvParam 3.2.10. CryptSetHashParam 3.2.11. CryptGetHashParam 3.2.12. CryptExportKey 3.2.13. CryptImportKey 3.2.14. CryptEncrypt 3.2.15. CryptDecrypt 3.2.16. CryptCreateHash 3.2.17. CryptHashData 3.2.18. CryptHashSessionKey 3.2.19. CryptSignHash 3.2.20. CryptDestroyHash 3.2.21. CryptVerifySignature 3.2.22. CryptGenRandom 3.2.23. CryptGetUserKey 3.2.24. CryptDuplicateHash 3.2.25. CryptDuplicateKey 3.3. De PKCS(11-Interface 3.3.1. Geïmplementeerde API calls 3.3.1.1. Algemene functies 3.3.1.2. Functies voor het beheer van slot en token 3.3.1.3. Functies voor het beheer van sessies 3.3.1.4. Functies voor het beheer van objecten 3.3.1.5. Functies voor ondertekening 3.3.1.6. Digest-functies 3.3.1.7. Functies voor random-generatie (worden binnenkort bevestigd) 3.3.2. Ondersteunde handtekeningmechanismen 3.3.3. Slot- en token-informatie 3.3.4. Gedrag in het geval van een pinpad-lezer 3.3.5. Gedrag met een niet-verwerpingssleutel 4. Referenties Art.1. Registratieprocedure lezers 1. Inleiding 1.1. Doel van de bijlagen Dit document bevat de specificaties en beschrijft de vereisten waaraan moet worden voldaan om het label "Belgische eID compatibel" voor kaartlezers te verwerven.

Vooraleer het registratieproces te starten, dient de aanvrager (vb. producent, wederverkoper, distributeur of integrator van kaartlezers) intern een aantal taken/scenario's uit te voeren waarop de conformiteitscertificaten, de benchmarkinformatie en de uiteindelijke validering zullen worden gebaseerd : 1) De noodzakelijke ISO-accreditatiecertificaten verwerven waarmee de ISO-organen technische conformiteit garanderen - zie hoofdstuk "Technische specificaties".2) De low-level testscenario's uitvoeren (intern met eigen apparatuur) en de gevraagde benchmarkinformatie ophalen - zie hoofdstuk "Low-level scenario's".3) De high-level valideringsscenario's uitvoeren (online via de eID-testwebsite) en de gevraagde bevestigingsinformatie ophalen - zie hoofdstuk "High-level scenario's". De aanvrager dient dan het registratieformulier in te vullen (met alle gevraagde gedetailleerde productinformatie) en in te dienen bij de registratieautoriteit voor kaartlezers.

Opmerking1 : het registratieformulier bevat een conformiteitsverklaring waarin de producent bevestigt dat de aanvrager alle vorige stappen heeft uitgevoerd en dat de informatie in de verklaring correct is.

Opmerking 2 : de registratieautoriteit voor kaartlezers behoudt zich het recht voor de conformiteit van de kaartlezer verder te controleren (bijvoorbeeld in het geval van klachten). Samen met het registratieformulier worden er drie exemplaren van het product waarnaar in het registratieformulier wordt verwezen, ingediend voor archivering en controle. 1.2. Reikwijdte Dit document betreft de registratie van kaartlezers. Met kaartlezers bedoelen we elk apparaat dat een SmartCard-interface voor de eID-kaart biedt (apart of niet, geïntegreerd of niet, toepassingsspecifiek of niet).

Dit document heeft geen betrekking op de specifieke vereisten in verband met kaartlezers die worden gebruikt voor het beheer van kaarten (activering van de kaart, (her-)initialisatie PIN/PUK, wijziging van gegevens, enz.) die specifiek zijn voor de autoriteit die de kaart aflevert (bijvoorbeeld initiële activering kaart) en/of het deblokkeren van de kaart (bijvoorbeeld ingeval er te veel foute PIN-codes werden ingevoerd) en/of het wijzigen van de kaart (bijvoorbeeld ingeval het adresbestand moet worden bijgewerkt). Dit type lezers vereist speciale PIN/PUK-samenvoegfuncties die buiten het kader van dit document vallen. 1.3. Lezerscategorieën De lezers worden verder ondergebracht in categorieën op basis van de volgende criteria : - connectable (connecteerbaar) : als de lezer over een hostinterface beschikt (vb. USB, RSR232, PCMCIA, enz.); - secure display (beveiligd scherm) : als de lezer over een specifiek display beschikt voor de visualisatie van berichten; - secure pinpad (beveiligd pinpad) : als de lezer over een specifiek pinpad beschikt voor het ingeven van de PIN-code; secure application (beveiligde applicatie) : als de lezer een beveiligd communicatiekanaal heeft geïnstalleerd met de piloting-applicatie;

Voor de raadpleging van de tabel, zie beeld - Value checkers : niet-geconnecteerde lezer waarmee de inhoud van de chip gemakkelijk kan worden gelezen, maar waarmee geen cryptografische transacties kunnen worden uitgevoerd (niet onderworpen aan registratie). - Transparante lezers : connecteerbare lezer zonder specifiek display of pinpad (de PIN- en statuscodes worden ingevoerd en getoond via niet-beveiligde media zoals het toetsenbord en het scherm). - Secured lezers : connecteerbare lezer met specifiek display en/of pinpad (de PIN- en statuscodes worden direct ingevoerd via het pinpad en/of op het display getoond). - Trusted lezers : beveiligde lezers met beveiligde applicaties die over een beveiligd kanaal beschikken om met de lezer te communiceren. 1.4. Platformen Aangezien de ondersteuning van de eID-kaart platformspecifiek is, zal de registratie per platform worden gevraagd (de lezer kan uiteraard voor verschillende platformen worden geregistreerd via meervoudige registratie).

De volgende platformen worden momenteel ondersteund, maar de registratieautoriteit behoudt zich het recht voor platformen toe te voegen/te schrappen naargelang van de vraag op de markt, de ondersteuning van de leverancier, enz.

Voor de raadpleging van de tabel, zie beeld Aangezien er platformen in talrijke varianten verkrijgbaar zijn, gaan we ervan uit dat de tests/scenario's worden uitgevoerd op een basisversie van de eenvoudigste versie van een bepaald platform (vb. de home edition en niet de professional edition, de personal edition en niet de server edition, enz.) waarop alle momenteel beschikbare (beveiligings-) patches werden geïnstalleerd. Als de lezer specifieke varianten en/of patches vereist, moeten deze duidelijk in het registratieformulier worden opgegeven en zullen ze op de website met de lijst van de geregistreerde lezers worden vermeld.

Om een gemeenschappelijke interface voor de applicaties te bieden, moet de lezer over een set API- implementaties beschikken (vb. deel van het installatiepakket of direct vooraf geïnstalleerd). Sommige van deze APIs zijn platformspecifiek (vb. Microsoft CryptoAPI), sommige zijn specifiek Belgisch (vb. eID runtime) - zie hoofdstuk "Specificaties".

De registratieautoriteit behoudt zich het recht voor het testscenario aan te passen om de technische evoluties van platformspecifieke interfaces en standaarden te volgen. 1.5 Omgeving Aangezien de beveiligingsvereisten van de eID-kaart omgevingspecifiek zijn, zal de registratie tevens een onderscheid maken tussen de lezers voor een thuis-/werk-/mobiele omgeving en lezers voor een openbare omgeving - zie hoofdstuk "Beveiligingsvereisten".

Lezers die in openbare plaatsen worden geïnstalleerd, en niet onder de controle van de Belgische burgers vallen, moeten namelijk aan speciale beveiligingsvereisten voldoen, die als volgt kunnen worden samengevat : - beschikbaarheid van een secure pinpad om de vertrouwelijkheid van de PIN-code te waarborgen; - beschikbaarheid van een secure display om de juistheid van de berichten te waarborgen.

Er zullen twee "Belgische eID compatibel"-logo's worden gebruikt om deze twee lezerscategorieën van elkaar te onderscheiden. 2. Vereisten en specificaties 2.1. Model- en beveiligingsvereisten Een eID-kaart-compatibele omgeving kan worden opgesplitst in een eindgebruiker die met een eID-compatibel systeem werkt. Het eID-systeem kan verder worden opgesplitst in 3 delen : - de eID-kaart zelf - de eID-kaart-compatibele lezer - de eID-kaart-compatibele applicatie Voor de raadpleging van de tabel, zie beeld De eID-kaart-compatibele applicatie bevat alle applicatiespecifieke componenten, die onder meer vereist zijn voor het presenteren van documenten, het bekijken van gegevens/attributen, het formatteren van handtekeningen, enz. In één fysieke eenheid kunnen verschillende applicatie-instanties aanwezig zijn die dezelfde lezer delen.

De eID-kaart-compatibele lezer moet alle noodzakelijke algemene componenten (hardware en/of software) bevatten om de eID-kaart te interfacen in overeenstemming met de beveiligingsvereisten die worden beschreven in [CEN/CWA 14170] en omgezet in de technische specificaties [EID/READERS 2.7.3] en [EID/CRYPTO 1.4.0] en [EID/IDENTITY 1.0.0]. Meer bepaald : - PINPAD (User Input & Authentication Component - Component voor input van de gebruiker en authenticatie) : deze component biedt beveiligde authenticatiefuncties waarmee de eindgebruiker PIN-codes ingeeft op een zodanige manier dat ze kunnen worden vergeleken met de PIN die zich op de kaart bevindt. In het algemeen kunnen we een onderscheid maken tussen lezers die over een specifiek pinpad beschikken en lezers die gebruik maken van het algemene toetsenbord (numpad). Deze component moet voldoen aan de veiligheidsvereisten die worden beschreven in [CEN/CWA 14170 - Hoofdstuk 13] en omgezet in de technische specficaties [EID/READERS 2.7.3 - Hoofdstuk 2&3] - DISPLAY (User Output & Control Component - Component voor output van de gebruiker en controle) : deze component biedt beveiligde interactiefuncties waarmee de eindgebruiker de applicatie gebruikt om het uitvoeringsproces te controleren en waarover foutcodes en statusberichten worden verstuurd. In het algemeen kunnen we een onderscheid maken tussen lezers die over een specifiek display beschikken en lezers die gebruik maken van een algemeen scherm. Deze component moet voldoen aan de veiligheidsvereisten die worden beschreven in [CEN/CWA 14170 - Hoofdstuk 12] en omgezet in de technische specificaties [EID/READERS 2.7.3 - Hoofdstuk 2&3] - APPLI/F (Application Input/Output Interface Component - Interfacecomponent voor input/output met de applicatie) : deze component biedt beveiligde functies voor datamanipulatie waarmee de applicatie met de eID-lezer samenwerkt om op een genormaliseerde en beveiligde manier gegevens te verzenden en te ontvangen. Deze component beschikt meestal over een algemene interface naar de applicatie. Deze component moet voldoen aan de veiligheidsvereisten die worden beschreven in [CEN/CWA 14170 - Hoofdstuk 15] en omgezet in de technische specificaties [EID/CRYPTO 1.4.0] en [EID/IDENTITY 1.0.0]. - CARDI/F (Card Input/Output Interface Component - Interfacecomponent voor input/output met de kaart) : deze component biedt interactiefuncties waarmee de applicatie [ISO/IEC 7816] commando's uitwisselt met de kaart. Deze component moet voldoen aan de veiligheidsvereisten die worden beschreven in [CEN/CWA 14170 - Hoofdstuk 16] en omgezet in de technische specficaties [EID/READERS 2.7.3 - Hoofdstuk 1 & Hoofdstuk 2.1] 2.2. Vereisten voor de kaartinterface De kaartinterface dient te voldoen aan [ISO7816] met de parameters die worden beschreven in de specificaties [EID/READER 2.7.3 Hoofdstuk 1 & Hoofdstuk 2.1].

De interface dient tevens te voldoen aan : - de beveiligingsvereisten die worden beschreven in [EN60950]; - de algemene criteria betreffende elektromagnetische emissie die worden beschreven in [EN50081]; - de algemene criteria betreffende elektromagnetische immuniteit die worden beschreven in [EN50081]; - de algemene criteria betreffende radio-elektrische storing die worden beschreven in [EN55022].

Opmerking : als de lezer over een tweegleuvensysteem beschikt, dient dit te beantwoorden aan de SIS/SAM-kaartlezerspecificaties (zie www.ksz-bcss.fgov.be). 2.3. Vereisten voor de gebruikersinterface Het interactieproces met de gebruiker kan plaatsvinden in twee verschillende soorten fysieke omgevingen waarbij het eID-systeem door verschillende organisaties wordt gecontroleerd : Openbare plaats : het eID-systeem bevindt zich op een openbare plaats, zoals een station, een bankagentschap, een postkantoor of een andere plaats die wordt bediend door een dienstverlener die niet noodzakelijk een relatie heeft met, of onder controle staat van de eindgebruiker.

Zonder aanvullende technische veiligheidsmaatregelen is deze omgeving kwetsbaar voor een aantal gevaren (vb. vervanging door een vals eID-systeem). De technische vereisten voor eID-systemen in een dergelijke openbare omgeving zullen dus strenger moeten zijn.

Thuis- en werkomgeving : het eID-systeem bevindt zich thuis of op kantoor, waar de gebruiker directe controle heeft over het eID-systeem (vb. gsm). In dit geval kan aan de beveiligingsvereisten worden voldaan door organisatorische maatregelen van de gebruiker en kunnen de technische middelen om de beveiligingsvereisten te realiseren minder streng zijn.

Naargelang van het gebruik zal de kaartlezer ook moeten voldoen aan verschillende vereisten en specificaties die hieronder worden samengevat : - lezers die in een openbare plaats worden geïnstalleerd, dienen over een specifiek secure PINpad en display te beschikken die in de lezer zelf zijn geïntegreerd (het standaard-toetsenbord en -scherm mogen niet worden gebruikt voor gebruikersinteracties); - de lezers die thuis en/of in de werkomgeving worden geïnstalleerd, mogen gebruik maken van het algemene toetsenbord en scherm voor gebruikersinteracties. 2.4. Vereisten voor de applicatie-interface De federale overheid heeft een eID runtime-omgeving ontwikkeld die gratis ter beschikking wordt gesteld van elke eindgebruiker en die een set libraries, tools en executables bevat om een generieke interface te creëren voor applicaties die met een eID-kaart willen communiceren/interfacen.

Deze omgeving bestaat uit vier componenten : - de eID data-middleware die een gestandaardiseerde interface voor data-extractie biedt, die de applicaties in staat stelt om de functies voor datacaptatie van de kaart te gebruiken; - de eID crypto-middleware die een gestandaardiseerde interface voor cryptografische bewerkingen biedt, die de applicaties in staat stelt om de functies voor authenticatie en ondertekening van de kaart te gebruiken; - de eID access-middleware die door de twee andere componenten wordt gebruikt om veilig verbinding te maken en te communiceren met een eID-toegangsservice; - de eID-toegangsservice die door een eID access-middleware wordt gebruikt om verbinding te maken met de fysieke lezer (via een eenvoudige kabel of via een netwerk).

Voor de raadpleging van de tabel, zie beeld De eID runtime-omgeving is uiteraard platformspecifiek en er is een versie beschikbaar voor alle platformen die worden ondersteund. Er zullen verschillende releases van de eID-omgeving worden ontwikkeld om de releases van de eID-kaart in de loop der jaren te volgen.

Opmerking : afhankelijk van het platform kan de Crypto Middleware over verschillende interfaces beschikken om aan fabrikantspecifieke vereisten te voldoen : - Linux : alleen PKCS#11 is vereist; - Microsoft : PKCS#11 en Microsoft CryptoAPI zijn vereist; - MacOS : PKCS#11 en Apple CryptoAPI zijn vereist.

De Belgische overheid gaat ervan uit dat de eID runtime-omgeving voldoet aan alle eisen die aan de component applicatie-interface worden gesteld. De eID runtime-omgeving werd door de Belgische overheid bovendien beveiligd met een code zodat er alleen authentieke kopieën kunnen worden verspreid. Er is ook een gratis begeleidende kit voor softwareontwikkeling beschikbaar met voorbeelden van en richtlijnen voor het creëren van een interface met de eID runtime-omgeving.

De eID runtime-omgeving wordt beschouwd als een deel van de lezer, wat tot een van de volgende alternatieven leidt : - ofwel wordt de eID-lezer door de eindgebruiker als een aparte component aangeschaft (vb. connecteerbare lezer) en dan moet er met de lezer een set eID runtime-installatietools en gebruikers-/installatiehandleidingen worden geleverd. Het installatiepakket moet zowel de lezerspecifieke drivers als de eID runtime-omgeving bevatten (het gedeelte in verband met de eID runtime kan optioneel zodanig worden ingesteld dat de eindgebruiker zelf kan beslissen of hij het wil installeren); - ofwel wordt de eID-lezer aangeschaft als onderdeel van een ander product (vb. een pc met een SmartCard-lezer) en dan moet de eID runtime vooraf worden geïnstalleerd. Er moeten ook eID runtime-installatiepakketten en gebruikers-/installatiehandleidingen worden geleverd (voor het geval de eID runtime opnieuw moet worden geïnstalleerd).

Opmerking : als er geen runtime-omgeving beschikbaar is voor een specifieke lezer (platform niet ondersteund en/of identity middleware en crypto middleware direct geïnstalleerd in de firmware van het toestel), dan mag de aanvrager zelf een runtime-omgeving ontwikkelen (of de officiële runtime-omgeving aanpassen aan zijn omgeving). In een dergelijk geval behoudt de registratieautoriteit zich het recht voor de overeenstemming en de gelijkwaardigheid met de officiële eID runtime-omgeving te controleren. 2.5. Specifieke vereisten Het moet voor de eindgebruiker mogelijk zijn om de eID runtime-omgeving te installeren/opnieuw te installeren/te verwijderen/te upgraden als er een nieuwe versie beschikbaar is op de eID-website. Om die reden zal deze registratieprocedure geen runtime-omgevingen van derden en/of gewijzigde runtime-omgevingen ondersteunen tenzij dit contractueel met de registratieautoriteit werd overeengekomen.

Eens geïnstalleerd, moet het voor de eindgebruiker mogelijk zijn om de lezer fysiek los te koppelen/aan te koppelen in plug & play mode zonder het systeem te moeten herstarten en/of rebooten. Deze vereiste geldt enkel voor connecteerbare lezers die thuis of in de werkomgeving worden gebruikt.

Men moet gemakkelijk kunnen nagaan of de lezer werd geregistreerd volgens de in dit document beschreven procedure (vb. via een sticker).

Men moet ook gemakkelijk het merk en het type van de lezer kunnen controleren, vooral als de lezer in een ander toestel werd geïntegreerd. Het merk en het type moeten duidelijk worden vermeld in de documentatie en op de zichtbare delen van de behuizing. 3. Low-level testscenario's Deze scenario's dienen door de leverancier van de eID-lezer te worden uitgevoerd om de compatibiliteit met de eID-kaart te testen.Deze scenario's worden in twee delen georganiseerd naargelang van het platform : - Het eerste deel is een set ISO7816 commando's die moeten worden uitgevoerd en getest via de SendAPDU functie-call van de eID runtime-omgeving. - Het tweede deel is een set datacaptatiefuncties die moeten worden uitgevoerd en getest via de GetXXX functie-calls van de eID runtime-omgeving. - Het derde deel is een set Crypto-functies die moeten worden uitgevoerd en getest via de Crypto Middleware (PKCS#11 implementatie) van de eID runtime-omgeving. - Het vierde deel (alleen vereist voor Microsoft- en Apple-platformen) is een set Crypto-functies die moeten worden uitgevoerd en getest via de Crypto Middleware (CryptoAPI implementatie) van de eID runtime-omgeving.

De specificaties van de kaartinhoud en interfaces zijn beschikbaar in : - [EID/CRYPTO 1.4.0] voor de Crypto-elementen (sleutels, certificaten, PIN's, enz.) en Crypto Middleware-specificaties; - [EID/IDENTITY 1.0.0] voor de gegevenselementen (identiteit, adres, foto) en data middleware-specificaties; - [EID/CARD 2.0.0] voor de ondersteunde ISO7816 commando's en eID-kaart- interfacespecificaties. 3.1 ISO7816/APDU-scenario Precondities : - SmartCard-lezer correct geïnstalleerd en geconfigureerd - Identiteits-library correct geïnstalleerd en geconfigureerd - Testkaart in de lezer Voor de raadpleging van de tabel, zie beeld Postcondities : - alle assertions geslaagd - de volgende informatie moet in het registratieformulier worden gerapporteerd : - kaartrespons op de geselecteerde SGNID 3.2. Datacaptatiescenario 3.2.1. Kaartversie en RRN-certificaat Precondities : - SmartCard-lezer correct geïnstalleerd en geconfigureerd - Identiteits-library correct geïnstalleerd en geconfigureerd - Testkaart in de lezer Voor de raadpleging van de tabel, zie beeld Postcondities : - alle assertions geslaagd - de volgende informatie moet in het registratieformulier worden gerapporteerd : - informatie versie (serienummer, componentcode, nummer en versie OS, nummer en versie Softmask, versie Applet, versie Global OS, versie applet interface, PKCS#1 support, versie Key Exchange, levenscyclus applicatie, grafische personalisering, elektronische personalisering, elektronische personalisering interface) - RRN-certificaat 3.2.2. Identiteit, adres en foto Precondities : - SmartCard-lezer correct geïnstalleerd en geconfigureerd - Identiteits-library correct geïnstalleerd en geconfigureerd - Testkaart in de lezer Voor de raadpleging van de tabel, zie beeld Postcondities : - alle assertions geslaagd - de volgende informatie moet in het registratieformulier worden gerapporteerd : - identiteitsgegevens (nummer kaart en chip, geldigheid, gemeente, RRN, voor- en familienaam, geboorteplaats en -datum, nationaliteit, geslacht, adellijke titel) - adresgegevens (straat, nummer, busnummer, postcode, stad/gemeente, land) 3.2.3. PIN controleren Precondities : - SmartCard-lezer correct geïnstalleerd en geconfigureerd - Identiteits-library correct geïnstalleerd en geconfigureerd - Testkaart in de lezer Voor de raadpleging van de tabel, zie beeld Postcondities : - alle assertions geslaagd - de volgende informatie moet in het registratieformulier worden gerapporteerd : - als de lezer een secure pinpad-lezer is, werd de PIN in het pinpad ingegeven - als de lezer geen secure pinpad-lezer is, werd de PIN op het scherm ingegeven 3.3. Cryptoki/PKCS#11-scenario 3.3.1. Initialiseren library, slot en token Precondities : - SmartCard-lezer correct geïnstalleerd en geconfigureerd - Cryptoki/PKCS#11 library correct geïnstalleerd en geconfigureerd - Testkaart in de lezer Voor de raadpleging van de tabel, zie beeld ...

Postcondities : - alle assertions geslaagd - de volgende informatie moet in het registratieformulier worden gerapporteerd : - informatie over de library (versie cryptoki, id. producent, versie en beschrijving library) - informatie over slot/lezer (beschrijving slot, id. producent, hardwareversie, firmwareversie) - informatie over token/kaart (token label en model, id. producent, serienummer, hardwareversie, firmwareversie) 3.3.2. Handtekening aansturen met authenticatiesleutel Precondities : vorige test geslaagd (library, slot en token geïnitialiseerd) Voor de raadpleging van de tabel, zie beeld Postcondities : - alle assertions geslaagd - de volgende informatie moet in het registratieformulier worden gerapporteerd : certificaten, digest en handtekening 3.3.3. PIN wijzigen Precondities : vorige test geslaagd (sessie geïnitialiseerd) Voor de raadpleging van de tabel, zie beeld Postcondities : - alle assertions geslaagd 3.3.4. Handtekening aansturen met handtekeningsleutel Precondities : vorige test geslaagd (library, slot en token geïnitialiseerd) Voor de raadpleging van de tabel, zie beeld Postcondities : * alle assertions geslaagd * de volgende informatie moet in het registratieformulier worden gerapporteerd : certificaten, digest en handtekening 3.3.5. PIN wijzigen Precondities : vorige test geslaagd (sessie geïnitialiseerd) Voor de raadpleging van de tabel, zie beeld Postcondities : - alle assertions geslaagd 4. High-level valideringsscenario's Deze scenario's dienen door de leverancier van de eID-lezer te worden uitgevoerd om de compatibiliteit met de eID-kaart te testen.Deze scenario's worden georganiseerd in vier delen die achtereenvolgens worden uitgevoerd (het ene deel maakt gebruik van het resultaat van het vorige deel) : - Installatie, desinstallatie, update, herconfiguratie. - Sterke authenticatie. - Datacaptatie en wijzigen PIN. - Gekwalificeerde handtekening.

Voor elk valideringsscenario wordt een set precondities, controledoelstellingen en postcondities beschreven om de compatibiliteit van de lezer en de bijbehorende software te beoordelen.

Opmerking : het is mogelijk dat een gedeelte van deze scenario's niet moet worden toegepast, afhankelijk van : - pakket lezer (vb. desinstallatie/herinstallatie is uiteraard niet van toepassing op lezers die in een pc zijn geïntegreerd) - plug&play (vb. afkoppelen/opnieuw aankoppelen is uiteraard niet van toepassing op lezers die in andere hardwarecomponenten zoals een toetsenbord zijn geïntegreerd). - CryptoAPI (vb. ondersteuning van eigen/platformspecifieke middleware is alleen van toepassing op het overeenkomstige platform). 4.1. Scenario I : installatie/desinstallatie en Plug&Play 4.1.1. Precondities * Geactiveerde testkaart beschikbaar (met gekende PIN-codes) * Lokale pc vooraf geïnstalleerd (met het doelplatform/os), internet browser en aangepaste drivers voor de lezer en eID runtime-omgeving * Internetaansluiting geconfigureerd met port 80(http) & 443(https) beschikbaar. * Gebruikers-/installatiehandleiding beschikbaar 4.1.2. Controledoelstellingen * De kaartlezer installeren volgens de instructies in de gebruikershandleiding (vb. reboot, administratierechten, enz.) * [indien van toepassing] De kaartlezer desinstalleren en opnieuw installeren volgens de instructies in de gebruikershandleiding (vb. reboot, administratierechten, enz.) * [indien van toepassing] De kaartlezer aankoppelen en afkoppelen * eID-validering datacaptatie ==> CD1 : Applicatie voor datacaptatie opstarten ==> CD3 : eID-kaart in de lezer steken ==> CD2 : Data capteren ==> CD5 : eID-kaart verwijderen ==> CD6 : Data capteren ==> CD7 : eID-kaart in de lezer steken (op verzoek) * [indien van toepassing] Een tweede kaartlezer van hetzelfde type installeren * [indien van toepassing] De tweede kaartlezer aan- en afkoppelen * eID-validering datacaptatie (uit te voeren op beide lezers) ==> CD1 : Applicatie voor datacaptatie opstarten ==> CD3 : eID-kaart in de lezer steken ==> CD2 : Data capteren ==> CD5 : eID-kaart verwijderen ==> CD6 : Data capteren ==> CD7 : eID-kaart in de lezer steken (op verzoek) 4.1.3. Postcondities * Set versienummers configuratie (OS/lezer/runtime, enz.) * Screenshots van tool voor datacaptatie 4.2. Scenario II : sterke authenticatie 4.2.1. Precondities * Scenario I met succes uitgevoerd * eID-validerings-/testsite beschikbaar * Internet browsers vooraf geïnstalleerd (SSLv3-compatibele browser met PKCS#11-interface) * [indien van toepassing] Internet browsers vooraf geïnstalleerd (SSLv3-compatibele browser met CryptoAPI-interface) * Scenario II geselecteerd 4.2.2. Controledoelstellingen * Naar de testservice gaan via https met PKCS#11-compatibele browser : ==> CD1 : browser configureren om eID PKCS#11-interface te herkennen ==> CD2 : Server geauthenticeerd ==> CD3 : Client-certificaat "authenticatie" geselecteerd ==> CD4 : PIN-code gevraagd ==> CD5 : Authenticatie geslaagd * [indien van toepassing] Naar de testservice gaan via https met CryptoAPI-compatibele browser : ==> CD1 : browser configureren door certificaten eindgebruiker in de cert. store te laden ==> CD2 : Server geauthenticeerd ==> CD3 : Client-certificaat "authenticatie" geselecteerd ==> CD4 : PIN-code gevraagd ==> CD5 : Authenticatie geslaagd 4.2.3. Postcondities * Data met succes op de valideringssite gelogd (OS/browser/interface/kaart/enz.) * Berichten die op het display verschijnen moeten worden gerapporteerd. * Kaartnummer, gegevens en bij benadering de duur van de transactie naar de valideringssite moeten worden gerapporteerd * Screenshot van de laatste pagina van de eID-testsite 4.3. Scenario III : datacaptatie en wijziging PIN 4.3.1. Precondities * Scenario II met succes uitgevoerd * Beveiligde verbinding gemaakt met de valideringssite * ScenarioIII geselecteerd 4.3.2. Controledoelstellingen * Naar de testservice gaan via https met PKCS#11-compatibele browser : ==> CD1 : Server geauthenticeerd ==> CD2 : Client-certificaat "authenticatie" geselecteerd ==> CD3 : PIN-code gevraagd ==> CD4 : Authenticatie geslaagd ==> CD5 : Datacaptatie automatisch ingeroepen ==> CD6 : Gecapteerde data getoond ==> CD7 : Wijzigen PIN-code ==> CD8 : Wijziging geslaagd * [indien van toepassing] Naar de testservice gaan via https met CryptoAPI-compatibele browser : ==> CD1 : Server geauthenticeerd ==> CD2 : Client-certificaat "authenticatie" geselecteerd ==> CD3 : PIN-code gevraagd ==> CD4 : Authenticatie geslaagd ==> CD5 : Datacaptatie automatisch ingeroepen ==> CD6 : Gecapteerde data getoond ==> CD7 : Wijzigen PIN-code ==> CD8 : Wijziging geslaagd 4.3.3. Postcondities * Data met succes op de valideringssite gelogd (OS/browser/interface/kaart/enz.) * Berichten die op het display verschijnen moeten worden gerapporteerd. * Kaartnummer, gegevens en bij benadering de duur van de transactie naar de valideringssite moeten worden gerapporteerd * Screenshot van de laatste pagina van de eID-testsite 4.4. Scenario IV : elektronische handtekening 4.4.1. Precondities * Scenario III met succes uitgevoerd * Beveiligde verbinding gemaakt met de valideringssite * Scenario IV geselecteerd 4.4.2. Controledoelstellingen * Naar de testservice gaan via https met PKCS#11-compatibele browser : ==> CD1 : Server geauthenticeerd ==> CD2 : Client-certificaat "authenticatie" geselecteerd ==> CD3 : PIN-code gevraagd ==> CD4 : Authenticatie geslaagd ==> CD5 : Elektronische handtekening automatisch ingeroepen ==> CD6 : Client-certificaat "authenticatie" geselecteerd ==> CD7 : PIN-code gevraagd ==> CD8 : Handtekening geslaagd * [indien van toepassing] Naar de testservice gaan via https met CryptoAPI-compatibele browser : ==> CD1 : Server geauthenticeerd ==> CD2 : Client-certificaat "authenticatie" geselecteerd ==> CD3 : PIN-code gevraagd ==> CD4 : Authenticatie geslaagd ==> CD5 : Elektronische handtekening automatisch ingeroepen ==> CD6 : Client-certificaat "authenticatie" geselecteerd ==> CD7 : PIN-code gevraagd ==> CD8 : Handtekening geslaagd 4.4.3. Postcondities * Data met succes op de valideringssite gelogd (OS/browser/interface/kaart/enz.) * Berichten die op het display verschijnen moeten worden gerapporteerd. * Kaartnummer, gegevens en bij benadering de duur van de transactie naar de valideringssite moeten worden gerapporteerd * Screenshot van de laatste pagina van de eID-testsite

Art. 2.Specificaties van de kaartlezers 1. Compatibiliteit van de hardware met de chip De lezer moet voldoen aan de volgende normen of aanbevelingen : * ISO/IEC 7816-1 : fysieke kenmerken * ISO/IEC 7816-2 : afmeting en plaats van de contacten * ISO/IEC 7816-3 : elektronisch signaal en communicatieprotocols * ID1 kaartformaat * Asynchroon protocol T=0 (T=1 is optioneel) * Elektrische spanning VCC=5V,5% - maximaal 50 mA * Programmeerspanning VPP gelijk aan VCC, 5% * Initiële kloksnelheid van 3.5712 MHz (9.600 bps). De kloksnelheid in werking is gelijk aan of groter dan de initiële kloksnelheid. * Contacten : ? contactdruk ( 1 N ? contactweerstand ( 0.3 Ohm ? kracht insteken kaart ( 12 N ? kracht uitnemen kaart ( 1 N 2. Compatibiliteit van de software met de chip 2.1. Alle lezers * Alle lezers moeten voldoen aan de ISO/IEC 7816-4- en 7816-8-standaarden voor het formaat van de uitwisselingscommando's. 2.2. Lezers met pinpad Lezers met een pinpad moeten alle ISO 7816-4- en 7816-8 -commando's (APDU) implementeren die een PIN-input vereisen zonder de PIN door te geven buiten de lezer. 2.2.1. Te implementeren kaartcommando's (APDU) - PIN controleren Voor de raadpleging van de tabel, zie beeld - PIN wijzigen (referentiegegevens wijzigen) Voor de raadpleging van de tabel, zie beeld 2.2.2. Te implementeren lezercommando's (APDU) eze sectie beschrijft het APDU-commando dat de lezer moet implementeren om met de commando's die verband houden met de PIN van de kaart, in interactie te gaan. Als men naar de lezer gaat via de eID-standaardmiddleware, kan er een proprietary interface worden gebruikt, op voorwaarde dat de producent de DLL verstrekt die de juiste interface implementeert, zoals wordt beschreven in section 3.2.

Als men echter via andere middelen (vb. op maat ontwikkelde applicaties) naar de lezer gaat, dan moeten de voorgestelde commando's ter beschikking worden gesteld van de applicatieontwikkelaars.

Hoewel deze laatste oplossing technisch zal voldoen, is ze erg beperkt en kan ze door bepaalde instellingen en officiële goedkeuringsinstanties worden geweigerd.

De twee commando's die in sectie 2.1.1 worden beschreven, moeten automatisch worden opgeroepen met een PIN (of 2 PINs) die op het pinpad wordt gevraagd wanneer de parameter Lc van de bovengenoemde commando's gelijk is aan 0. In dit geval moet de firmware van de lezer eerst de PIN van het pinpad lezen en vervolgens de parameters Lc en Data vervangen door de juiste informatie die afkomstig is van de PIN die werd ingegeven. - Lezer PIN controleren Voor de raadpleging van de tabel, zie beeld - Lezer PIN wijzigen Voor de raadpleging van de tabel, zie beeld Om de PIN te wijzigen, moet de nieuwe PIN twee keer worden ingegeven (met vergelijking) om vergissingen te vermijden.

De return-code (status byte) moet de return-code van het kaartcommando zijn die is gedefinieerd in de ISO 7816-4- en 7816-8-standaarden, of een van de volgende : Voor de raadpleging van de tabel, zie beeld 2.2.3. PIN-formaat De PIN bestaat uit strings van 8-bytes met het volgende formaat (per nibble), zoals gedefinieerd in de sectie Global PIN in het document "Global Platform - Card Specification - version 2.0.1' - April 7, 2000" : Voor de raadpleging van de tabel, zie beeld 3. Compatibiliteit van de software met de middleware Deze sectie is bedoeld voor lezers die verbinding maken met een computer die de kaart zal gebruiken via de Microsoft CryptoAPI- of via de PKCS#11-interface. 3.1. PC/SC drivers Alle lezers moeten over een driver beschikken die compatibel is met PC/SC-versie 1.1 voor het doel-besturingssysteem. 3.2. Integratie met de middleware Voor de integratie met de middleware dient de producent van de lezer voor elk doel-besturingssysteem een Dynamic Linked Library (of gelijkwaardig) te ontwikkelen die de volgende functies implementeert : * SCR_Init() * SCR_VerifyPIN() * SCR_ChangePIN() Momenteel bevindt alleen de applicatie Belgian Identity (hieronder aangegeven met ID) zich op de kaart; met het oog op eventuele andere applicaties (die als aparte Data Files of Directories in de kaart worden geïntegreerd) in de toekomst, krijgen sommige functies een parameter, ApplicationID genoemd, die een string bevat die de applicatie die met een van zijn PIN's in interactie wil gaan, identificeert. Het is de bedoeling dat de lezer de applicatie toont die een PIN vraagt (zie 3.3). 3.2.1. SCR_Init( ) Deze functie wordt opgeroepen onmiddellijk na het laden van de DLL. Ze wordt gebruikt om de DLL te initialiseren en te controleren of hij de aangesloten lezer ondersteunt.

Voor de raadpleging van de tabel, zie beeld 3.2.2. SCR_VerifyPIN( ) Deze functie controleert de PIN die de gebruiker heeft ingegeven op het pinpad van de lezer.

Voor de raadpleging van de tabel, zie beeld 3.2.3. SCR_ChangePIN( ) Deze functie vervangt de PIN die de gebruiker heeft ingegeven op het pinpad van de lezer door een nieuwe PIN, die eveneens werd ingegeven op het pinpad van de lezer.

Voor de raadpleging van de tabel, zie beeld 3.3. Display De parameters Usage en ApplicationID vormen belangrijke informatie voor de burger.

Usage toont waarom aan de burger wordt gevraagd zijn PIN in te geven (om zich te identificeren, om een document te ondertekenen, enz.). Dit is de betekenis van de verschillende types : - 'A' : Authenticatie (logon) - 'S' : Handtekening (niet-verwerping) - 'E' : Encryptie - 'P' : Voorkeur bestandswijziging - 'M' : Onderhoud (administratieve actie) ApplicationID is een string die de applicatie identificeert. Momenteel is alleen de applicatie Belgian Identity (ID) op de kaart aanwezig, maar later kunnen er nog applicaties volgen (vb : geneesheren (doctors) : Doc, advocaten (lawyers) : LAW, enz.). Daarom moet deze informatie eveneens worden gegeven.

Dit is de informatie die de lezer op het display moet tonen als de bovenvermelde functies worden opgeroepen : 3.3.1. SCR_VerifyPIN( ) Als de ruimte op het display beperkt is, moet minimaal de volgende informatie worden getoond : Voor de raadpleging van de tabel, zie beeld Als er voldoende ruimte is op het display, moet de informatie worden vertaald in de taal die is gedefinieerd in de functie SCR_Init, zoals Voor de raadpleging van de tabel, zie beeld 3.3.2. SCR_ChangePIN( ) Als de ruimte op het display beperkt is, moet minimaal de volgende informatie worden getoond : Voor de raadpleging van de tabel, zie beeld Als er voldoende ruimte is op het display, moet de informatie worden vertaald in de taal die is gedefinieerd in de functie SCR_Init, zoals Voor de raadpleging van de tabel, zie beeld

Art. 3.Specificaties Identity Middleware 1. Inleiding 1.1. Matrix ontwikkelingsomgeving De eID Toolkit biedt verschillende interfaces voor dezelfde functionaliteiten en bijgevolg dient men de meest geschikte interface te kiezen.

Deze matrix geeft de aanbevolen interface voor verschillende gangbare ontwikkelingsomgevingen en talen.

Voor de raadpleging van de tabel, zie beeld Belangrijke opmerking : De ActiveX mag niet worden gebruikt om naar de eID-kaart te gaan vanuit een internetpagina omdat 1. hij uitsluitend met Microsoft Internet Explorer werkt;2. hij door de browser niet wordt vertrouwd en door de meeste programma's en gebruikers zal worden geweigerd;3. de Java applet een gebruikersinterface bevat om de gebruiker interactief te vragen de toegang te bevestigen. De huidige ActiveX is bovendien niet programmeerbaar omdat de scripts niet in staat zijn naar het geheugen te gaan dat door de component werd toegewezen; er moet een wrapper worden gemaakt die gebruik maakt van een door het script verstrekte buffer om hem te kunnen programmeren. 2. Functionele specificaties 2.1. Versies en compatibiliteit De Toolkit verwerkt automatisch alle verschillende versies van de kaarten. Bij het gebruik van de Toolkit hoeft men zich geen zorgen te maken over de manier waarop de gegevens in de kaart zijn opgeslagen omdat ze op een eenvormige manier ter beschikking worden gesteld via de API. Er bestaat een low-level functie om de verschillende versies van de kaartcomponenten op te roepen, maar ze is enkel bestemd voor technische ontwikkelaars die naar zeer specifieke eigenschappen van de kaart moeten gaan - voor een normale applicatie heeft de versie van de kaart geen belang. 2.2. Ingeven PIN Verschillende functies aanvaarden een inputparameter "PIN-referentie".

Als er een PIN- referentie wordt gegeven en het bericht "toegang geweigerd" verschijnt als de functie naar een bron van de kaart wil gaan, dan zal de functie automatisch de PIN aan de gebruiker vragen en opnieuw trachten naar de bron te gaan (na succesvolle controle van de PIN).

Dit is een "just-in-time" controle van de PIN, want de PIN wordt alleen gevraagd als dat nodig is. Misschien werd er bijvoorbeeld al een permanente PIN ingegeven die nog steeds geldig is. In dat geval zal de PIN niet opnieuw worden gevraagd.

Als de lezer een beveiligde invoer van de PIN toelaat, wordt het pinpad van de lezer gebruikt; in andere gevallen wordt het toetsenbord van de pc gebruikt. 2.3. Opmerking over de maximumlengte van de parameters De maximumlengte van de gegevens die de functies tonen, hangt af van het type parameter : * Bytes * ASCII-karakters * UTF-8-karakters Voor C-ontwikkelaars eindigen alle ASCII- en UTF-8-strings op nul.

Opgelet : in de opgegeven lengte is de '[0]' op het einde van op nul eindigende strings niet inbegrepen. 2.4. Multi-threaded applicatie De library is niet thread-safe. Het is de taak van de calling-applicatie om de library niet gelijktijdig in parallelle threads te gebruiken.

Opmerking : de CSP is thread-safe, maar het is niet mogelijk om de CSP in één thread en de Toolkit in een andere thread op te roepen. 2.5. API-organisatie De functies zijn ondergebracht in 4 categorieën : * Functies voor initialisatie en beëindiging, noodzakelijk voor de initialisatie en de beëindiging van de Toolkit. * Identiteitsfuncties, die worden gebruikt om de identiteitsgegevens (naam, adres, enz.) op de kaart op te vragen. * Algemene high-level functies, die worden gebruikt om op een algemene manier naar de informatie te gaan (bestanden, PIN), hoofdzakelijk in andere applicaties dan de identiteitsapplicatie. Deze functies hoeven niet naar de identiteitsgegevens te gaan. * Low-level functies, bestemd voor ontwikkelaars die zeer technische functies nodig hebben, of voor debugging. De gewone ontwikkelaars hebben deze functies niet nodig. 2.6. Functies voor initialisatie en beëindiging 2.6.1. BEID_Init Deze functie initialiseert de Toolkit.

Deze functie moet vóór elke andere functie worden opgeroepen.

Het principe voor de validering van het certificaat (hetzij door OCSP of CRL te gebruiken) wordt gegeven. Het geldt voor alle functie-calls totdat BEID_Exit( ) wordt opgeroepen. De OCSP en CRL Mandatory flags sluiten elkaar uit. Als zowel OCSP als CRL worden gebruikt, zal eerst OCSP worden geprobeerd; als dat lukt, wordt het proces stopgezet, anders wordt CRL gebruikt.

Voor de raadpleging van de tabel, zie beeld 2.6.2. BEID_Exit Deze functie verwijdert alle gegevens die door de Toolkit werden gebruikt.

Deze functie moet worden opgeroepen aan het einde van het programma.

Voor de raadpleging van de tabel, zie beeld 2.7. Identiteitsfuncties Alle identiteitsfuncties zijn onafhankelijk. Dat betekent dat er geen andere functie moet worden opgeroepen samen met een identiteitsfunctie (behalve de functies voor initialisatie en beëindiging).

Al deze functies kunnen worden opgeroepen ongeacht de huidige status van de kaart - ongeacht of er een andere DF (Data File) dan de identiteitsfunctie wordt geselecteerd, enz. 2.7.1. BEID_GetID Voor de raadpleging van de tabel, zie beeld 2.7.4. Offline identiteitsfuncties Soms kan het nodig zijn de gegevens van de kaart te archiveren om ze niet alleen nu te valideren, maar ze ook met hun handtekening te bewaren als bewijs. In dat geval hebt u twee functies nodig : een functie om de raw data van de kaart te lezen, en een functie om de raw data te geven die u hebt opgeslagen als input voor de identiteitsfuncties. 2.7.4.1. BEID_GetRawData Deze functie geeft de raw data files van de kaart. (ID, Address, Picture, RRN certificate, CardData, TokenInfo, Challenge/Response from internal authenticate). U moet deze data opslaan voor later gebruik.

Opmerking : de raw data worden niet gecontroleerd, enkel gelezen. U moet de gewone identiteitsfuncties oproepen om ze te valideren.

Voor de raadpleging van de tabel, zie beeld 2.7.4.2. BEID_SetRawData Deze functie gebruikt de raw data als input voor de volgende identiteitsfuncties. Dit maakt het mogelijk om bepaalde identiteitsgegevens die eerder al werden opgeslagen, te controleren.

De kaartlezer moet niet aanwezig zijn om deze functie te gebruiken.

Om de raw data te controleren moet u : * De functie BEID_Init( ) oproepen met de parameter reader op "VIRTUAL" * De functie BEID_SetRawData( ) oproepen De gewone identiteitsfuncties oproepen Voor de raadpleging van de tabel, zie beeld 2.8. Algemene high-level functies Deze functies geven toegang - geïntegreerd in de Toolkit - tot algemene functies voor applicaties die andere acties moeten uitvoeren dan het louter naar de identiteitsgegevens gaan. 2.8.1. BEID_BeginTransaction Deze functie begint de transactie en wacht tot alle andere transacties zijn beëindigd voor ze begint. Geen enkele andere applicatie zal toegang hebben tot de kaart totdat BEID_EndTransaction wordt opgeroepen.

De functie moet worden opgroepen vóór andere functies voor het gebruik van de kaart die moeten worden gegroepeerd. Deze functie is niet nodig om individuele functies of identiteitsfuncties op te roepen.

Meestal wordt er een transactie gebruikt om een applicatie te selecteren vooraleer naar een bestand of PIN te gaan.

Voor de raadpleging van de tabel, zie beeld 2.8.2. BEID_EndTransaction Deze functie beëindigt een eerder opgegeven transactie en laat de andere applicaties toe de interacties met de kaart te beëindigen.

Deze functie moet op het einde van bepaalde operationele kaartfuncties worden opgeroepen.

Voor de raadpleging van de tabel, zie beeld 2.8.3. BEID_SelectApplication Deze functie kiest een applicatie op de kaart.

Voor de raadpleging van de tabel, zie beeld 2.8.4. BEID_ReadFile Deze functie leest een bestand op de kaart. Als er een PIN-referentie wordt gegeven, zal de PIN worden gevraagd en zo nodig gecontroleerd (just-in-time checking).

Voor de raadpleging van de tabel, zie beeld 2.8.5. BEID_WriteFile Deze functie schrijft een bestand op de kaart. Als er een PIN-referentie wordt gegeven, zal de PIN worden gevraagd en zo nodig gecontroleerd (just-in-time checking).

Voor de raadpleging van de tabel, zie beeld 2.8.6. BEID_VerifyPIN Deze functie controleert een PIN. Voor de raadpleging van de tabel, zie beeld 2.8.7. BEID_ChangePIN Deze functie wijzigt een PIN. Voor de raadpleging van de tabel, zie beeld 2.8.8. BEID_GetPINStatus Deze functie haalt de pinstatus op. De resulterende informatie kan door de basissleutel van de kaart worden ondertekend (key '0x81' in de huidige DF-applicatie).

Voor de raadpleging van de tabel, zie beeld 2.9. Low-level functies Opmerking : de low-level functies zijn bestemd voor applicaties die naar specifieke technische functies willen gaan die niet beschikbaar zijn via de gewone functies, of voor debugging. De gewone applicaties hebben deze low-level functies niet nodig. 2.9.1. BEID_GetVersionInfo Deze functie geeft de versie van de verschillende componenten (applet, OS,...). De resulterende informatie kan worden ondertekend door de basissleutel van de kaart (key '0x81' in de huidige DF-applicatie).

Voor de raadpleging van de tabel, zie beeld 2.9.2. BEID_SendAPDU Deze functie stuurt een APDU-commando naar de kaart.

Opgelet : wanneer de APDU naar de kaart wordt gestuurd, kan de Toolkit de compatibiliteit tusen de applet-versies niet garanderen (behalve voor het communicatiegedeelte). Het is mogelijk dat de call niet werkt in een volgende versie van de applet.

Als er een PIN-referentie wordt gegeven, zal de PIN worden gevraagd en zo nodig gecontroleerd (just-in-time checking).

Opmerking : het commando zal eerst worden geprobeerd zonder de PIN te vragen; als het commando niet slaagt met status "toegang geweigerd", zal de PIN worden gevraagd en wordt het commando opnieuw uitgevoerd.

Voor de raadpleging van de tabel, zie beeld 2.9.3. BEID_FlushCache Deze functie flusht de gegevens die zich in het geheugen en op de schijf bevinden.

Voor de raadpleging van de tabel, zie beeld Als er een bepaald PIN-id aan de Toolkit wordt gegeven, kunt u ofwel de PKCS#15 PIN id, ofwel de PIN-referentie van het besturingsssysteem opgeven.

Als de PIN niet in de Toolkit is geregistreerd, dan moet u een string ingeven die beschrijft waarom de PIN vereist is (vb. : "Wijziging persoonlijke gegevens"). U moet ook een short string opgeven (max. 3 karakters) die op het display van de kaartlezer moet worden getoond als die aanwezig is (vb : "MOD").

Een PIN bestaat dus uit 4 velden : - Het type PIN : PKCS#15 of Operating System (zie 2.10.1). - De PIN OS referentie of : PKCS#15 id. - De gebruikscode (zie 2.10.2). - De lange beschrijving (in de taal van de gebruiker). - De korte beschrijving (in de taal van de gebruiker).

Om de beveiliging te verbeteren en de informatie op het display te standaardiseren, kan de beschrijving die door de applicatie wordt gegeven worden overschreven door de Toolkit als de Toolkit het juiste gebruik kan bepalen.

Als er geen PIN moet worden gecontroleerd, moet er een NULL-waarde worden gebruikt.

Opmerking : als er een PIN beschikbaar is in de PKCS#15-structuur, dan is het veiliger de PKCS#15-referentie te gebruiken dan de OS-referentie omdat het OS in de toekomst kan veranderen. 2.10.1. Types PIN Voor de raadpleging van de tabel, zie beeld 2.10.2. Gebruik PIN Voor de raadpleging van de tabel, zie beeld 2.11. OCSP en CRL input policy parameters Voor de raadpleging van de tabel, zie beeld 2.12. Status van de functies Elke functie geeft een algemene return-code die het type fout opgeeft.

In de meeste gevallen zal alleen deze return-code worden gebruikt. Om meer gedetailleerde informatie te verkrijgen over de technische oorzaken, kunnen ook de volgende status-codes worden gegeven : * De code systeemfout (lang). * De foutcode PC/SC (lang). * De smart card Status Word (dubbele byte). 2.12.1. Algemene return-codes Voor de raadpleging van de tabel, zie beeld 2.13. Controle handtekening en validering certificaten Elke functie die ondertekende gegevens geeft, controleert altijd de handtekening en de integrtiteit van de volledige certificaatketen.

De functie geeft * de status van de handtekeningcontrole (long); * de globale status van de certificaatvalidering (long); * voor elk certificaat - het certificaat, - het label van het certificaat, - de individuele controlestatus, - de individuele valideringsstatus, - de individuele policy : OCSP of CRL. Voor de raadpleging van de tabel, zie beeld Het onderstaande diagram beschrijft de werkstroom van de controle van de handtekening : Voor de raadpleging van de tabel, zie beeld 2.13.1. Controle handtekening Voor de raadpleging van de tabel, zie beeld 3. Programmeerinterfaces 3.1. C API Alle outputbuffers moeten worden toegewezen door de calling application.

Alle functies gebruiken de C calling convention, niet de Pascal convention.

Struct packing is ingesteld op 8. 3.1.1. Structures Voor de raadpleging van de tabel, zie beeld 3.1.2. Functions Voor de raadpleging van de tabel, zie beeld 3.2. Java API Om compatibel te blijven met de native code die de toegang tot de kaart implementeert, gebruikt de Java-implementatie geen exception handling; maar worden alle fouten weergegeven in de foutcodes, zoals beschreven in 2.12.

Voor de raadpleging van de tabel, zie beeld 3.2.1. Data Classes Voor de raadpleging van de tabel, zie beeld 3.2.2. Main Class Voor de raadpleging van de tabel, zie beeld Applet Parameter : Voor de raadpleging van de tabel, zie beeld HTLM snippet : Voor de raadpleging van de tabel, zie beeld 4.. Installatie 4.1. Installatiepakket Het installatiepakket2 bevat de volgende bestanden : Voor de raadpleging van de tabel, zie beeld 4.2. Run-time De run-time is vereist voor alle omgevingen.

Hij moet worden geïnstalleerd zoals beschreven in het document "Belgian eID Run-time Users guide". 4.3. C Library De applicatie moet het bestand "eidlib.h" van de Toolkit bevatten.

De applicatie moet worden verbonden met de gedeelde library "libeid.so" of "eidlib.dll" als de linker een directe link met de gedeelde library ondersteunt (zoals GCC), of met de toegangspunten van de library "eidlib.lib" of "libeid.a" als dat niet het geval is (zoals Visual C++). 4.4. Java De Toolkit is compatibel met alle Java Virtual Machines van Sun vanaf 1.2.

Art.3bis. Specificaties Crypto Middleware 1. Doel Dit document heeft tot doel de architectuur van de middleware-software te beschrijven en de applicatieprogrammeurs de noodzakelijke informatie te verschaffen voor het ontwikkelen van applicaties die gebruik maken van de Belgische elektronische identiteitskaart.Dit document is beperkt tot informatie voor de programmeurs betreffende de middleware van de Belgische kaart. 2. Architectuur 2.1. Interfaces Zoals beschreven in het vorige hoofdstuk werden er twee interfaces in de middleware-software geïmplementeerd : één interface die direct kan worden opgeroepen (de PKCS#11 interface) en één interface die indirect wordt opgeroepen (de CSP). 2.1.1. De Crypto API-interface De Microsoft(r) Cryptographic API 2.0 (CryptoAPI) stelt applicatieontwikkelaars in staat om authenticatie, codering en encryptie aan hun op Win32(r) gebaseerde applicaties toe te voegen. De applicatieontwikkelaars kunnen functies in de CryptoAPI gebruiken zonder iets af te weten van de onderliggende implementatie, zoals ze een grafische library kunnen gebruiken zonder op de hoogte te zijn van de specifieke configuratie van de grafische hardware.

Het CSP-gedeelte van de middleware legt de verbinding tussen de abstracte CryptoAP en de onderliggende PKCS#11-interface. De ontwikkelaar zal een functie van de CSP nooit direct oproepen maar altijd via de CryptoAPI. De Belgische identiteitskaart ondersteunt (momenteel) alleen operaties met digitale handtekeningen. Als de Belgische overheid later zou beslissen de gebruiker van de elektronische identiteitskaart toe te laten om sleutelmateriaal aan de kaart toe te voegen dat encryptie ondersteunt, dan zal de CSP worden uitgebreid om deze bijkomende functionaliteit mogelijk te maken. De Belgische identiteitskaart bevat ook twee sleutelparen die kunnen worden gebruikt voor digitale handtekeningen (zowel authenticatie als niet-verwerping).

Hoewel de CSP alleen digitale handtekeningen ondersteunt, is hij geregistreerd als een PROV_RSA_FULL type CSP om het gebruik van de CSP in Microsoft(r) standaardapplicaties toe te laten. 2.1.1.1. CSP high-level architectuur De Crypto application programming interface (API) van Microsoft is een abstracte interface voor cryptografische bewerkingen. Hij schermt de gebruiker van de API af, zodat hij niet hoeft te weten hoe de cryptografische functionaliteit op een lager (kaart-) niveau is geïmplementeerd. Deze CryptoAPI-interface is onafhankelijk van de onderliggende cryptografische implementatie. In het geval van de Belgische elektronische identiteitskaart is dit een smartcard. In andere applicaties kan dit zelfs een softwareoplossing zijn.

Onder de CryptAPI-interface werd een andere interface gespecificeerd voor de ontwikkelaars van beveiligingsimplementaties. Deze interface wordt CSPI (Cryptgraphic Service Provider Interface) genoemd. Deze interface scheidt het onderliggende cryptografische apparaat van de CryptoAPI-interface. Er kan een onbeperkt aantal CSPI-implementaties beschikbaar zijn op elk systeem. Elke CSPI-implementatie is (meestal) specifiek voor een bepaald type onderliggende hardware. De volgende figuur geeft een overzicht van deze architectuur : Voor de raadpleging van de tabel, zie beeld Elke CSP richt zich meestal op één specifiek type smartcard omdat de CSP meestal door de leverancier van de smartcard zelf ter beschikking wordt gesteld. De middleware van de Belgische identiteitskaart gaat anders te werk. Om de uitgever van de identiteitskaart (nl. de overheid) maximale flexibiliteit te verlenen met betrekking tot de keuze van het type smartcard dat wordt gebruikt, implementeert de CSP de proprietary interface van de smartcard niet direct, maar via een PKCS#11-interface (u vindt meer informatie over de PKCS#11-interface in sectie 2.1.2). De onderstaande figuur toont de relevante blokken : Voor de raadpleging van de tabel, zie beeld Als de overheid later zou beslissen naar een andere fysieke smartcard over te stappen, dan moet de CSP-implementatie dus niet worden aangepast (op voorwaarde dat de nieuwe smartcard compatibel is met de bestaande). 2.1.1.2.CSP low-level architectuur Op een lager niveau maakt de CSP-implementatie een vertaling tussen de CSPI-standaardinterface en de PKCS#11-interface. Deze architectuur wordt getoond in de onderstaande figuur : Voor de raadpleging van de tabel, zie beeld Intern implementeert de CSP een gedeelte van de PKCS#11-interface om de cryptografische bewerkingen met de publieke sleutel uit te voeren.

Deze bewerkingen zijn momenteel beperkt tot digitale handtekeningen, zowel authenticatie als niet-verwerping. Voor cryptografische bewerkingen die geen betrekking hebben op de publieke sleutel, zoals het berekenen van hash-waarden, wordt een basis-CSP gebruikt. Voor deze bewerking wordt meestal de standaard-PROV_RSA_FULL CSP gebruikt.

In de praktijk zal dat meestal de Microsoft CSP zijn.

De CSP houdt een configuratiebestand bij. Dat configuratiebestand bevat kaartonafhankelijke instellingen die gekoppeld zijn aan deze elektronische identiteitskaart. De naam (het label) van de verschillende sleutels wordt bijvoorbeeld opgeslagen met een link naar het sleutel-ID voor deze sleutel. Deze informatie is voor alle Belgische elektronische identiteitskaarten hetzelfde. Er wordt dus geen configuratiebestand per kaart gebruikt op een bepaald systeem.

De gebruikerscertificaten worden opgeslagen in de certificaat-stores van het besturingssysteem. Voor gebruikerscertificaten is dat de "MY" store. Voor elk certificaat wordt een friendly name gedefinieerd (authenticatiesleutel en handtekeningsleutel). In de Microsoft-omgeving worden er certificaatcontainers gebruikt om de verbinding te maken tussen een certificaat en de bijbehorende private sleutel. De naam van deze containers wordt buiten het label van de sleutel (authenticatie of handtekening) en het serienummer van de kaart samengesteld om meer dan één identiteitskaart op hetzelfde apparaat te kunnen gebruiken. 2.1.2. De PKCS#11-interface De PKCS#11 (v2.11)-interface wordt door niet-Microsoft-applicaties gebruikt, zoals bijvoorbeeld Netscape. Ook op maat ontwikkelde applicaties kunnen deze interface gebruiken in plaats van de CryptoAPI-interface. De PKCS#11-interface wordt soms ook Cryptoki genoemd.

Er is een gedetailleerde beschrijving van deze interface beschikbaar op de website van RSA Laboratories (http ://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/).

In overeenstemming met de wens van de overheid om zo een zo open mogelijk systeem te creëren, hebben we besloten de open source PKCS#11-implementatie van opensc (http ://www.opensc.org) te gebruiken. Deze implementatie biedt niet alleen de implementatie van de PKCS#11-interface maar ondersteunt ook de PKCS#15-kaartstructuur. 2.1.2.1. PKCS#11 high-level architectuur De cryptoki-interface biedt een abstracte interface naar de smartcard voor applicaties die cryptografische functionaliteit nodig hebben.

Deze interface wordt meestal door niet-Microsoft-applicaties gebruikt, zoals Netscape en Mozilla. Ook onafhankelijke solution providers kunnen deze interface gebruiken om cryptografische functionaliteit te implementeren in applicaties van andere leveranciers.

De figuur hieronder illustreert de PKCS#11-modules : Voor de raadpleging van de tabel, zie beeld Zoals aangeduid in de bovenstaande figuur, implementeert de bovenlaag de PKCS#11-standaardinterface. Het is deze interface die aan de applicaties wordt getoond. Onder deze interfacelaag wordt de verbinding gelegd met de kaartstructuur in PKCS#15 en worden de vereiste commando's (APDU) via de PC/SC-standaardinterfacefuncties verstuurd.

In de OpenSC-laag werd een specifieke kaart-driver geïmplementeerd voor het gebruik van de Belgische elektronische identiteitskaart. Als er later een andere kaart zou worden gebruikt, dan moet deze driver worden vervangen. 3. Programmeurshandleiding 3.1. Inleiding De middleware van de Belgische identiteitskaart is software die wordt aangebracht tussen de applicatie die beveiligingseigenschappen implementeert (digitale handtekeningen) en het apparaat dat de cryptografische operaties uitvoert (de smartcard).

De middleware zelf bestaat uit twee onafhankelijke interface-implementaties (zie figuur onderaan). Hoewel de implementaties onafhankelijk zijn, maken ze gebruik van elkaar. Voor de standaardapplicaties van Microsoft(r) (Office, Outlook...) wordt er een Cryptographic Service Provider (CSP) gecreëerd die de cryptografische bewerkingen van de smartcard implementeert. Een applicatie zal deze implementatie nooit direct oproepen maar via een standaardinterface, Crypto API genoemd. De CSP-implementatie maakt gebruik van de tweede geïmplementeerde interface, PKCS#11. Deze interface wordt gebruikt door standaardapplicaties die niet van Microsoft afkomstig zijn.

Als er een nieuwe applicatie wordt gecreëerd, is het aan de ontwikkelaar om te beslissen welke van de twee interfaces zal worden gebruikt om de gebruiker cryptografische functionaliteit ter beschikking te stellen.

Dit document beschrijft de programmeerinterfaces en de manier waarop een applicatieontwikkelaar ze kan gebruiken.

Voor de raadpleging van de tabel, zie beeld 3.2. De Crypto API-interface De Microsoft(r) Cryptographic API 2.0 (CryptoAPI) stelt applicatieontwikkelaars in staat om authenticatie, codering en encryptie aan hun op Win32(r) gebaseerde applicaties toe te voegen. De applicatieontwikkelaars kunnen functies in de CryptoAPI gebruiken zonder iets af te weten van de onderliggende implementatie, zoals ze een grafische library kunnen gebruiken zonder op de hoogte te zijn van de specifieke configuratie van de grafische hardware.

Het CSP-gedeelte van de middleware legt de verbinding tussen de abstracte CryptoAPI- en de onderliggende PKCS#11-interface. De ontwikkelaar zal de functies van de CSP nooit direct oproepen maar altijd via de CryptoAPI. De onderstaande secties geven een beschrijving van de API calls die CryptoAPI naar de CSP stuurt voor verdere verwerking. Dit document bevat geen gedetailleerde informatie over de werking van elke API call. Gelieve voor dit type informatie het Microsoft Developer Network te raadplegen.

De Belgische identiteitskaart ondersteunt alleen operaties met digitale handtekeningen. Niet alle functies die verband houden met deze cryptografische bewerkingen werden geïmplementeerd. Als de Belgische overheid later zou beslissen de gebruiker van de elektronische identiteitskaart toe te laten om sleutelmateriaal aan de kaart toe te voegen dat encryptie ondersteunt, dan zal de CSP worden uitgebreid om deze bijkomende functionaliteit mogelijk te maken. De Belgische identiteitskaart bevat ook twee sleutelparen die kunnen worden gebruikt voor digitale handtekeningen (zowel authenticatie als niet-verwerping). Dat heeft tot gevolg dat bepaalde parameters die aan de Crypto API-functies worden doorgegeven geen betekenis hebben. In de call CryptGetUserKey wordt bijvoorbeeld een parameter 'dwKeySpec' doorgegeven. Deze parameter wordt gebruikt om te definiëren welk type sleutel er wordt gevraagd, een AT_KEYEXCHANGE-sleutel of een AT_SIGNATURE-sleutel. In het geval van de CSP van de Belgische identiteitskaart volstaat deze parameter echter niet om te bepalen welke handtekeningsleutel er moet worden geladen. In dit geval moet de container die het juiste certificaat bevat naar CryptAcquireContext worden doorgegeven en dan zal een nieuwe call naar CryptGetUserKey met succes worden uitgevoerd.

Hoewel de CSP alleen digitale handtekeningen ondersteunt, is hij geregistreerd als een PROV_RSA_FULL type CSP om het gebruik van de CSP in Microsoft(r)-standaardapplicaties toe te laten. Crypto Het oproepen van API-functies die niet in de context van een digitale handtekening worden gebruikt, zal een foutwaarde genereren die aangeeft dat de API-functie niet werd geïmplementeerd.

De beschrijving in dit document heeft betrekking op versie 1.20 van de CSP. 3.2.1.CryptAcquireContext Voor de raadpleging van de tabel, zie beeld De parameter pszContainer bevat de naam van de sleutelcontainer die een specifieke sleutel op de identiteitskaart bevat. De namen van de containers op de identiteitskaart kunnen worden verkregen via een call naar CryptGetProvParam.

De parameter dwFlags kan worden ingesteld op de volgende waarden (volgens MSDN) : 0 (gelijk aan CRYPT_SCKEYSET) CRYPT_VERIFYCONTEXT CRYPT_NEWKEYSET CRYPT_MACHINE_KEYSET CRYPT_DELETEKEYSET Aangezien het sleutelmateriaal van de Belgische identiteitskaart op een smartcard is opgeslagen en de gebruiker niet over de autorisaties beschikt om nieuwe sleutelparen te creëren op de kaart, worden de parameterwaarden CRYPT_NEWKEYSET, CRYPT_MACHINE_KEYSET en CRYPT_DELETEKEYSET niet ondersteund. Het gebruik van deze waarden zal de fout NTE_BAD_FLAGS genereren.

Er werd een extra waarde gedefinieerd voor deze parameter, CRYPT_SCKEYSET. Met deze waarde bepaalt de ontwikkelaar dat er een context voor de sleutel is vereist zoals gedefinieerd in de pszContainer parameter.

Voor hashing-bewerkingen alleen wordt een basis-CSP gebruikt. Als het laden van de basis-CSP zou mislukken, dan wordt de volgende foutcode gegenereerd door SetLastError() : ERR_CANNOT_LOAD_BASE_CSP (0x1000) 3.2.2. CryptReleaseContext Voor de raadpleging van de tabel, zie beeld Deze API call is geïmplementeerd zoals gedefinieerd door MSDN. 3.2.3. CryptGenerateKey Voor de raadpleging van de tabel, zie beeld Aangezien het sleutelmateriaal op de Belgische identiteitskaart vooraf door de overheid werd geïnstalleerd en de gebruiker geen bijkomende sleutelparen kan creëren, is deze API call niet geïmplementeerd. Als deze functie toch wordt opgeroepen wordt de fout E_NOTIMPL gegenereerd door SetLastError (). 3.2.4.CryptDeriveKey Voor de raadpleging van de tabel, zie beeld Aangezien het sleutelmateriaal op de Belgische identiteitskaart vooraf door de overheid werd geïnstalleerd en de gebruiker geen bijkomende sleutelparen kan creëren, is deze API niet geïmplementeerd. Als deze functie toch wordt opgeroepen wordt de fout E_NOTIMPL gegenereerd door SetLastError (). 3.2.5.CryptDestroyKey Voor de raadpleging van de tabel, zie beeld Aangezien het sleutelmateriaal op de Belgische identiteitskaart vooraf door de overheid werd geïnstalleerd en de gebruiker geen bijkomende sleutelparen kan creëren, is deze API call niet geïmplementeerd. Als deze functie toch wordt opgeroepen wordt de fout E_NOTIMPL gegenereerd door SetLastError (). 3.2.6CryptSetKeyParam Voor de raadpleging van de tabel, zie beeld Aangezien het sleutelmateriaal op de Belgische identiteitskaart vooraf door de overheid werd geïnstalleerd en de gebruiker geen bijkomende sleutelparen kan creëren, is deze API call niet geïmplementeerd. Als deze functie toch wordt opgeroepen wordt de fout E_NOTIMPL gegenereerd door SetLastError (). 3.2.7. CryptGetKeyParam Voor de raadpleging van de tabel, zie beeld Aangezien het sleutelmateriaal op de Belgische identiteitskaart vooraf door de overheid werd geïnstalleerd en de gebruiker geen bijkomende sleutelparen kan creëren, is deze API call niet geïmplementeerd. Als deze functie toch wordt opgeroepen wordt de fout E_NOTIMPL gegenereerd door SetLastError (). 3.2.8.CryptSetProvParam Voor de raadpleging van de tabel, zie beeld Volgens de MSDN-documentatie kan de parameter dwParam op de volgende waarden worden ingesteld : PP_CLIENT_HWND PP_KEYSET_SEC_DESCR Deze laatste parameter heeft geen betekenis omdat het sleutelmateriaal in het geval van de Belgische identiteitskaart in de smartcard zelf wordt opgeslagen in plaats van in de registry. Deze parameter wordt bijgevolg genegeerd. 3.2.9.CryptGetProvParam Voor de raadpleging van de tabel, zie beeld Deze API call is geïmplementeerd zoals beschreven in de MSDN-documentatie met uitzondering van de parameter PP_KEYSET_SEC_DESCR die wordt genegeerd.

Voor de parameter PP_IMPTYPE wordt de waarde CRYPT_IMPL_MIXED gegenereerd omdat de handtekeningbewerking door de hardware (nl. de smartcard) wordt uitgevoerd en de hashing-bewerking door de base cryptografic provider wordt uitgevoerd. 3.2.10.CryptSetHashParam Voor de raadpleging van de tabel, zie beeld Deze API call is geïmplementeerd zoals beschreven in de MSDN-documentatie.

De parameter dwParam = HP_HASHVAL werd geïmplementeerd maar moet met de nodige voorzichtigheid worden gebruikt. Deze parameter werd gedefinieerd om applicaties de mogelijkheid te bieden hash-waarden te ondertekenen zonder dat ze toegang hebben tot de basisdata. Omdat de applicatie (en de gebruiker nog minder) onmogelijk kan weten wat er wordt ondertekend, is dit een inherent riskante bewerking. 3.2.11. CryptGetHashParam Voor de raadpleging van de tabel, zie beeld Deze API call is geïmplementeerd zoals beschreven in de MSDN-documentatie. 3.2.12. CryptExportKey Voor de raadpleging van de tabel, zie beeld Deze functie kan worden gebruikt om de publieke sleutel die met de parameter hKey is geassocieerd te exporteren. Er kan een handle voor een publieke sleutel worden verkregen via een call naar CryptGetUserKey. Aangezien de private sleutels op een smartcard zijn opgeslagen en het exporteren van private sleutels niet is toegelaten, kan alleen PUBLICKEYBLOB als dwBlobType worden gedefinieerd. Aangezien alleen publieke sleutels kunnen worden geëxporteerd, wordt de parameter hExpKey niet gebruikt en moet hij dus op NULL worden ingesteld. De publieke sleutel wordt gegeven door de parameter pbData.

Om de lengte van de data die worden gegeven te verkrijgen kan de parameter pbData op NULL worden ingesteld. De lengte van de data die worden gegeven, wordt dan in pcbDataLen geplaatst. Als de buffer die naar deze functie wordt doorgegeven niet voldoende groot is, wordt de fout ERROR_MORE_DATA gegeven en wordt de juiste bufferlengte in de parameter pcbDataLen geplaatst. 3.2.13. CryptImportKey Voor de raadpleging van de tabel, zie beeld Aangezien het sleutelmateriaal op de Belgische identiteitskaart vooraf door de overheid werd geïnstalleerd en de gebruiker geen bijkomende sleutelparen kan creëren, is deze API call niet geïmplementeerd. Als deze functie toch wordt opgeroepen wordt de fout E_NOTIMPL gegenereerd door SetLastError (). 3.2.14.CryptEncrypt Voor de raadpleging van de tabel, zie beeld Het gebruik van de sleutels zoals ze door de Belgische overheid werden gedefinieerd, ondersteunt momenteel geen encryptie. Daarom werd deze API call niet geïmplementeerd. Als deze functie toch wordt opgeroepen wordt de fout E_NOTIMPL gegenereerd door SetLastError ().

Als er in de toekomst sleutelmateriaal aan de elektronische identiteitskaart kan worden toegevoegd dat encryptie ondersteunt, dan zal deze functie eveneens worden geïmplementeerd. 3.2.15.CryptDecrypt Voor de raadpleging van de tabel, zie beeld Het gebruik van de sleutels zoals ze door de Belgische overheid werden gedefinieerd, ondersteunt momenteel geen encryptie. Daarom werd deze API call niet geïmplementeerd. Als deze functie toch wordt opgeroepen wordt de fout E_NOTIMPL gegenereerd door SetLastError ().

Als er in de toekomst sleutelmateriaal aan de elektronische identiteitskaart kan worden toegevoegd dat encryptie ondersteunt, dan zal deze functie eveneens worden geïmplementeerd. 3.2.16.CryptCreateHash Voor de raadpleging van de tabel, zie beeld Deze API call is geïmplementeerd zoals beschreven in de MSDN-documentatie. Er kan één bijkomende fout worden gegenereerd via SetLastError () : ERR_INVALID_PROVIDER_HANDLE (0x1001) Deze fout geeft aan dat de handle zoals hij door hProv wordt gespecificeerd, niet kon worden gevonden (vb. hij werd niet gecreëerd met CryptAcquireContext ()) De verwerking van deze call wordt gedelegeerd naar een basis-CSP. 3.2.17.CryptHashData Voor de raadpleging van de tabel, zie beeld Deze API call is geïmplementeerd zoals beschreven in de MSDN-documentatie. In de parameter dwFlags kan één waarde (behalve 0) worden gespecificeerd : CRYPT_USERDATA. Hij is al of niet geïmplementeerd afhankelijk van de basis-CSP die wordt gekozen. De Microsoft Base CSP implementeert deze parameter bijvoorbeeld niet.

De verwerking van deze call wordt gedelegeerd naar een basis-CSP. 3.2.18. CryptHashSessionKey Voor de raadpleging van de tabel, zie beeld Aangezien sommige van de onderliggende calls die vereist zijn om deze functie te gebruiken momenteel niet zijn geïmplementeerd door deze CSP, is deze call evenmin beschikbaar. Als deze functie toch wordt opgeroepen wordt de fout E_NOTIMPL gegenereerd door SetLastError (). 3.2.19.CryptSignHash Voor de raadpleging van de tabel, zie beeld Deze API call is geïmplementeerd zoals beschreven in de MSDN-documentatie. Als de functie wordt opgeroepen, wordt er een poging ondernomen om verbinding te maken met en in te loggen op de Belgische identiteitskaart (smartcard). Als een van deze bewerkingen faalt, dan kan de volgende fout worden gegenereerd via SetLastError () : ERR_CANNOT_LOGON_TO_TOKEN (0x1004) Om de opgegeven hash-data te ondertekenen, moet er bepaalde informatie (vb. lengte sleutel) worden gelezen van de smartcard. Als er tijdens deze bewerking een fout gebeurt, dan wordt de volgende fout gegenereerd via SetLastError () : ERR_CANNOT_GET_TOKEN_SLOT_INFO (0x1003) Het ondertekeningsmechanisme dat wordt gebruikt om digitale handtekeningen te produceren, is CKM_RSA_PKCS. In de PKCS#11-documentatie vindt u meer gedetailleerde informatie over dit mechanisme.

Momenteel kunnen de volgende hashing-algoritmen worden gebruikt om data te tekenen : MD2, MD4, MD5, SHA-1 en SSL3 SHAMD5. Hoewel de MDx hashing-algoritmen nog steeds beschikbaar zijn voor achterwaartse compatibiliteit, wordt het gebruik van SHA-1 aanbevolen voor nieuwe applicaties. 3.2.20.CryptDestroyHash Voor de raadpleging van de tabel, zie beeld Deze API call is geïmplementeerd zoals beschreven in de MSDN-documentatie. 3.2.21. CryptVerifySignature Voor de raadpleging van de tabel, zie beeld Deze functie is geïmplementeerd om praktische redenen. Deze call wordt gedelegeerd naar de basis-CSP. 3.2.22. CryptGenRandom Voor de raadpleging van de tabel, zie beeld Deze API call is geïmplementeerd zoals beschreven in de MSDN-documentatie. De data die via pbBuffer worden ingegeven, zullen worden gebruikt als basis voor random-generatie. 3.2.23. CryptGetUserKey Voor de raadpleging van de tabel, zie beeld Deze call geeft een handle voor de publieke sleutel van de sleutelcontainer die werd gedefinieerd via CryptAcquireContext. Het volstaat niet AT_SIGNATURE te specificeren voor de parameter dwKeySpec omdat de CSP met deze informatie nog steeds niet kan bepalen welke handtekeningsleutel hij moet geven. Daarom moet de te laden sleutel eerst worden gespecificeerd via CryptAcquireContext. 3.2. 24.CryptDuplicateHash Voor de raadpleging van de tabel, zie beeld Deze API call is geïmplementeerd zoals beschreven in de MSDN-documentatie. 3.2.25.CryptDuplicateKey Voor de raadpleging van de tabel, zie beeld Aangezien het sleutelmateriaal op de smartcard is opgeslagen en niet kan worden opgehaald, heeft deze functie geen zin en daarom werd deze API call niet geïmplementeerd. Als deze functie toch wordt opgeroepen wordt de fout E_NOTIMPL gegenereerd door SetLastError (). 3.3. De PKCS#11-interface De PKCS#11 (v2.11)-interface wordt gebruikt door niet-Microsoft-applicaties zoals bijvoorbeeld Netscape. Ook op maat ontwikkelde applicaties kunnen deze interface gebruiken in plaats van de CryptoAPI-interface. De PKCS#11-interface wordt soms ook Cryptoki genoemd.

Er is een gedetailleerde beschrijving van deze interface beschikbaar op de website van RSA Laboratories (http ://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/). 3.3.1. Geïmplementeerde API calls 3.3.1.1. Algemene functies C_Initialize, C_Finalize C_GetInfo C_GetFunctionList 3.3.1.2.Functies voor het beheer van slot en token C_GetSlotList C_GetSlotInfo C_GetTokenInfo C_GetMechanismList C_GetMechanismInfo C_WaitForSlotEvent C_SetPin 3.3.1.3. Functies voor het beheer van sessies C_OpenSession C_CloseSession C_CloseAllSessions C_GetSessionInfo C_Login C_Logout 3.3.1.4. Functies voor het beheer van objecten C_FindObjectsInit C_FindObjects C_FindObjectsFinal C_GetAttributeValue 3.3.1.5. Functies voor ondertekening C_SignInit C_Sign C_SignUpdate C_SignFinal 3.3.1.6. Digest-functies C_DigestInit C_Digest C_DigestUpdate C_DigestFinal 3.3.1.7. Functies voor random-generatie (worden binnenkort bevestigd) C_SeedRandom C_GenerateRandom 3.3.2. Ondersteunde handtekeningmechanismen Voor handtekeningen : - CKM_RSA_X_509 - CKM_RSA_PKCS : zowel ASN.1-wrapped als zuivere hashes (MD5, SHA1, SHA1+MD5, RIPEMD160, indien er 20 bytes worden gegeven, veronderstelt men een SHA-1 hash) - CKM_RIPEMD160_RSA_PKCS, CKM_SHA1_RSA_PKCS, CKM_MD5_RSA_PKCS - Als ze door de elektronische ID-kaart worden ondersteund, worden de volgende handtekeningmechanismen ook door de middleware ondersteund : CKM_RSA_PKCS_PSS, CKM_SHA1_RSA_PKCS_PSS Voor digests : CKM_SHA_1, CKM_RIPEMD160, CKM_MD5 3.3.3. Slot- en token-informatie Voor elke PIN zal er een virtueel slot/token zijn (in het geval van de Belgische elektronische identiteitskaart betekent dit dus 1 slot/token).

De publieke sleutels, private sleutels en certificaten die bij elkaar horen zullen hetzelfde CKA_ID-objectattribuut hebben. 3.3.4. Gedrag in het geval van een pinpad-lezer In dit geval zal CK_TOKEN_INFO over de flag CKF_PROTECTED_AUTHENTICATION_PATH beschikken en de applicatie moet een NULL PIN geven met C_Login. Als er een C_Login wordt opgeroepen, zal de PKCS#11 library de gebruiker een dialoogvenster voorstellen met het verzoek de PIN in te geven op het pinpad om een handtekening of identificatie te plaatsen. 3.3.5. Gedrag met een niet-verwerpingssleutel Als er met deze sleutel een handtekening wordt gevraagd, zal de PKCS#11 library zelf een GUI tonen om de gebruiker te vragen zijn PIN in te geven, of om de gebruiker te vragen zijn PIN in de pinpad-lezer in te geven. 4. Referenties [ISO/IEC 7816-1] Identification Cards - Integrated Circuit Cards with Contacts Part1 : Physical Characteristics [ISO/IEC 7816-2] Identification Cards - Integrated Circuit Cards with Contacts Part2 : Dimensions and Location of Contacts [ISO/IEC 7816-3] Identification Cards - Integrated Circuit Cards with Contacts Part3 : Electronic Signals and Transmission Protocols [ISO/IEC 7816-4] Identification Cards - Integrated Circuit Cards with Contacts Part4 : Inter-industry Commands for Interchange [ISO/IEC 7816-5] Identification Cards - Integrated Circuit Cards with Contacts Part5 : Numbering System for Application Identifiers [CEN/CWA 14170] Electronic Signature - Security Requirements Secure Signature Creation Applications [CEN/CWA 14171] Electronic Signature - Security Requirements Secure Signature Verification Applications [RSAS/PKCS#11] Public Key Cryptographic Standards Cryptographic Token Interface Standard [RSAS/PKCS#15] Public Key Cryptographic Standards Cryptographic Token Information Standard [EID/READERS 2.7.3] Belgian Electronic Identity Card Readers Technical Compatibility v 2.7.3 [EID/CRYPTO 1.4.0] Belgian Electronic Identity Card Security & Crypto Middleware v 1.4.0 [EID/IDENTITY 1.0.0] Belgian Electronic Identity Card Data & Identity Middleware v 1.0.0 [EID/CARD 2.0.0] Belgian Electronic Identity Card Card and Applet Specifications v 2.0.0 [EN45014] Conformity Assessment Generic Criteria (CE) [EN60950] Information Processing Equipment Security [EN50081] EMC (Electro-Magnetic Compatibility) Emission Generic Criteria [EN50081] EMC (Electro-Magnetic Compatibility) Immunity Generic Criteria [EN55022] REC (Radio-Electric Compatibility) Perturbations Generic Criteria Gezien om te worden gevoegd bij Ons besluit van 7 december 2006 tot vaststelling van de specificaties en registratieprocedure van de leesapparatuur voor de elektronische identiteitskaart en tot wijziging van het koninklijk besluit van 13 februari 1998 houdende specificaties van de leesapparatuur voor de sociale identiteitskaart.

ALBERT Van Koningswege : De Minister van Binnenlandse Zaken, P. DEWAEL De Minister van Economie, M. VERWILGHEN De Minister van Sociale Zaken, R. DEMOTTE De Minister van Middenstand en Landbouw, Mevr. S. LARUELLE De Minister van Werk, P. VANVELTHOVEN _______ Nota's (1) Sommige kaarten bevatten alleen de twee voornamen samen;in dat geval worden ze beide in dit veld opgegeven en zal het veld tweede voornaam leeg zijn. (2) Sommige kaarten bevatten alleen de twee voornamen samen;in dat geval worden ze beide in dit veld opgegeven en zal het veld tweede voornaam leeg zijn. (3) Dit pakket kan zich in een archief bevinden zoals een ZIP-, TAR- of GZ-bestand

Bijlage II MODELFORMULIER VOOR DE REGITSRATIE VAN EEN LEESAPPARAAT VOOR DE BELGISCHE ELEKTRONISCHE IDENTITEITSKAART (eID) Gebruiksaanwijzing Dit document bevat de inventaris van de verschillende documenten en de opgave van de gegevens die moeten worden ingevuld en aan de overheid moeten worden overgemaakt met het oog op het bekomen van een registratienummer voor een leesapparaat voor de Belgische elektronische identiteitskaart.Alle beschreven punten en gevraagde informatie moeten zo volledig mogelijk worden beantwoord.

Het model van het registratieformulier kan worden gedownload op de volgende URL : http ://eid.belgium.be Het volledig en duidelijk ingevuld registratieformulier met inbegrip van alle noodzakelijk bijlagen moet worden opgestuurd : a) per post naar het volgende adres : Federale Overheidsdienst Informatie-en Commnicatietechnologie Maria-Theresiastraat 1-3 1000 Brussel b) per e-mail : registratie@fedict.be Voor de raadpleging van de tabel, zie beeld In dit onderdeel moet worden aangeduid of de vereiste normen worden gerespecteerd en moet voor elke rubriek het bewijs daarvan als bijlage worden gevoegd, hetzij op grond van een gelijkvormigheidattest afgeleverd door een certificatie-instelling, hetzij op grond van een schriftelijke verklaring van eenvormigheid. * TABEL * IV. RESULTATEN VAN DE TESTSCENARIOS V. HANDBOEKEN Gedaan te, . . . . . op . . . . .

Naam : . . . . .

Handtekening : . . . . .

Gezien om te worden gevoegd bij Ons besluit van 7 december 2006 tot vaststelling van de specificaties en registratieprocedure van de leesapparatuur voor de elektronische identiteitskaart en tot wijziging van het koninklijk besluit van 13 februari 1998 houdende specificaties van de leesapparatuur voor de sociale identiteitskaart.

ALBERT Van Koningswege : De Minister van Binnenlandse Zaken, P. DEWAEL De Minister van Economie, M. VERWILGHEN De Minister van Sociale Zaken, R. DEMOTTE De Minister van Middenstand en Landbouw, Mevr. S. LARUELLE De Minister van Werk, P. VANVELTHOVEN

BIJLAGE III Labelmodel en gebruiksvoorwaarden. 1. Het label bedoeld in artikel 8 van dit koninklijk besluit : - is strikt en beperkend verbonden met een leesapparaat dat, voor wat de elektronische identiteitskaart betreft, heeft voldaan en voldoet aan de opgelegde functionele en technische normen en vereisten; - getuigt, op initiatief van de leverancier, van de conformiteit van het leesapparaat waarop het wordt aangebracht met bovenvermelde normen en vereisten; - neemt bij de gebruiker elke twijfel weg rond de compatibiliteit van de leesapparaten met de elektronische identiteitskaart; - heeft tot doel de voluntaristische houding te ondersteunen van de leveranciers die zich laten registreren. 2. Het label wordt afgebeeld door het logo dat hier wordt weergegeven : kleurenversie : monochrome versie : Voor de raadpleging van de tabel, zie beeld 2.1. De kleurenversie is, volgens bovenvermelde aanwijzingen, verplicht samengesteld uit de volgende specifieke kleuren : - (1) Pantone : Process Black CMYK : C 0, M 0, Y 0, K 100 RGB : R 0, G 0, B 0 - (2) Pantone : 115 CMYK : C 0, M 8,5, Y 79, K 0 RGB : R 255, G 233, B 0 - (3) Pantone : 032 CMYK : C 0, M 91, Y 87, K 0 RGB : R 246, G 0, B 0 - (4) Pantone : 338 CMYK : C 47, M 0, Y 32, K 0 RGB : R 135, G 207, B 163 - (5) Pantone : 343 CMYK : C 98, M 0, Y 72, K 61 RGB : R 2, G 56, B 37 - (6) Wit CMYK : C 0, M 0, Y 0, K 0 RGB : R 255, G 255, B 255 De kleurenversie geniet de voorkeur boven de monochrome versie; zij moet worden weergegeven op een witte achtergrond. 2.2. De monochrome versie, wanneer de kleurenversie niet mogelijk is, bestaat verplicht uit zwart en wit, met een raster à 35% van het zwart voor het grijze gedeelte.

Zij moet worden weergegeven op een witte achtergrond. 3. Het label moet, volgens bovenstaand model, als dusdanig worden weergegeven, zonder wijziging van vorm, kleuren, leesbaarheid en afmetingen.4. Het logo dat het label vormt wordt omringd door een vrije ruimte, waarin geen enkel element van om het even welke aard mag voorkomen;de reproductie ervan neemt deze ruimte in acht zoals hier omschreven : Voor de raadpleging van de tabel, zie beeld Indien het logo, in kleurenversie of monochrome versie, op een andere achtergrond wordt weergegeven dan een witte achtergrond dan is het aangewezen een vrije ruimte in het wit te voorzien.

Het kan bijvoorbeeld gaan om een zelfklever waar het logo wordt weergegeven op een witte achtergrond, die precies de vorm aanneemt van de vrije ruimte. 5. Het label wordt duidelijk zichtbaar en bij voorkeur op de voorkant van het betrokken leesapparaat aangebracht. Om de zichtbaarheid ervan te verzekeren moet het label (logo buiten vrije ruimte) een afmeting hebben die in verhouding is met het betrokken apparaat, met een waarde Y (zie schema) van minimum 10mm.

Het label mag visueel gezien het logo of de benaming van de leverancier of van het betrokken leesapparaat niet overheersen. 6. Het label mag ook, op dezelfde voorwaarden als hier beschreven, worden weergegeven op de reclame voor, de verpakking en de documentatie van het betrokken leesapparaat en dit voor zover deze elementen het label presenteren, rechtstreeks en uitdrukkelijk in verbinding met dit apparaat en enkel dit apparaat. Een leverancier kan zich dus niet beroepen op het bekomen van het label, los van het toestel waaraan het werd toegekend.

Wanneer het betrokken leesapparaat wordt verkocht in een verpakking, die belet dat men het label op het apparaat kan zien, dan moet het label op de verpakking worden weergegeven. 7. Het label en de elementen voor de reproductie ervan kunnen bekomen worden door elektronisch teleladen op het adres www.fedict.be.

Gezien om te worden gevoegd bij Ons besluit van 7 december 2006 tot vaststelling van de specificaties en registratieprocedure van de leesapparatuur voor de elektronische identiteitskaart en tot wijziging van het koninklijk besluit van 13 februari 1998 houdende specificaties van de leesapparatuur voor de sociale identiteitskaart.

ALBERT Van Koningswege : De Minister van Binnenlandse Zaken, P. DEWAEL De Minister van Economie, M. VERWILGHEN De Minister van Sociale Zaken, R. DEMOTTE De Minister van Middenstand en Landbouw, Mevr. S. LARUELLE De Minister van Werk, P. VANVELTHOVEN