Sledeće EF sadrže X.509 sertifikate sa javnim RSA ključem:

Na kartici bi trebalo da se uz oba lična X.509 sertifikata negde nalazi i izdvojen javni i tajni ključ u memoriji koja nije čitljiva spolja jer se ključevi generišu na samoj kartici i pristupa im se kroz crypto instrukcije. X.509 je standardni format za dostavljanje javnog ključa koji uključuje detalje o izdatom sertifikatu, njegovoj upotrebi i izdavaocu. Prvi par (gde je X.509 u 0F 10) se koristi za kvalifikovane potpise, dok se drugi koristi za obične potpise, na primer u e-pošti, i veb autentifikaciju. Planiram da dodam opciju u FreeSteel da izveze lični javni X.509 sertifikat sa kartice. FreeSteel 0.3 može da izveze kvalifikovani i obični lični X.509 sertifikat. Opcije su ./freesteel.py -q qualified.cer -s standard.cer.

Format je i ovde 6 bajtova za zaglavlje sa oznakom dužine. Blob počinje nekom rečju (4 bajta) kojoj ne znam značenje, nakon čega od petog bajta kreće sadržaj sertifikata.

Operativni sistem na kartici je Apollo OS izraelske firme SC². Na njihovom sajtu piše For generic private and open source middleware, Apollo OS is available with a PKCS#15 profile.. Naravno ovde se misli da je podrška (komercijalno) dostupna klijentima koji sprovode uvođenje rešenja, kod nas je to NetSet d.o.o. iz Beograda.

FreeSteel, višeplatformski Python skript za čitanje podataka sa elektronske lične karte je dogurao do izdanja 0.2 0.3. Ako ste preuzeli jutros, ponovite. Program sada uspešno izvozi i sliku sa lične karte i čuva je u posebnu datoteku. Željko je odlično primetio da je offset dva bajta koliki i mora da bude za dostupnu veličinu slike.

Za promenu pina koriste se 0F 13, 0F A1 i 0F A3. VERIFY (0x00 0x20) instrukcija radi nad prvim ključem za poređenje. Kada se pozove bez podataka, vraća broj preostalih pokušaja. Kasnije u procesu promene šalje joj se neki niz od 8 bajtova (izgleda da ne zavisi od samog pina več od kartice, nije mi to baš najjasnije) nakon čega sledi UPDATE BINARY (0x00 0xD6) instrukcija koja ažurira 0F 13 nizom od 6 bajtova zaglavlja EF i 54 bajtova nekih podataka. Od tih 54 bajtova prvih 4 i poslednjih 5 je fiksno između različitih promena, a 45 nosi informaciju o izabranom pinu. Nema nikakve magije, nakon promene sadržaja, čitanje pročita upravo prethodno upisano. Deluje da je uvek dužina 45 bajtova i da ne zavisi od izabrane dužine pina ali treba to još jednom da proverim. Pogledaću u PKCS#15 ima li šta zanimljivo na tu temu mada nisam siguran da je to pravo mesto za traženje informacija.

Pretpostavljam da je ideja da se pročitaju neki ključevi iz 0F A1 (6+20 bajtova) i 0F A3 (6+14 bajtova), zatraže ovlašćenja sa VERIFY i tim nekim osmobajtnim nizom pa onda novi pin šifruje i zapakuje u niz koji se upiše nazad u 0F 13. Na kraju se bira MF (koreni direktorijum) verovatno kako bi se prekinula ovlašćenja ili resetovalo nešto slično.