Som standard er pluss-kortet utstedt av nxp et ikke-initialisert kort på L0-nivå. På dette tidspunktet viser den aktive operasjonen at den støtter CPU-kortegenskapene til ISO1443-4 (ATQA: 02 00, SAK: 20 UID: CD 65 E5 03), når du utfører skriverelatert AES Etter at Nøkkel og datablokk er initialisert og begått, går det inn på L1-sikkerhetsnivået. Den aktive driften viser egenskapene til et M1S70-kort (ATQA: 02 00, SAK: 18 UID: CD 65 E5 03), men faktisk kan det fremdeles støtte ISO1443-4. Rotter er utført vellykket (det må også støttes, Ellers kan ikke switchL2- og switch3-operasjoner utføres). Etter at switchL2-autentisering er utført på L1-nivå og konvertert til L2-nivå, er returverdien etter den aktive operasjonen (ATQA: 02 00 SAK: 11, UID: CD 65 E5 03). For øyeblikket, hvis det ikke er noen slik samsvarende SAK i den eksisterende driveren, vil det være en ukjent korttype. Etter at switch3-autentiseringen er utført på L2-sikkerhetsnivået, oppgraderes kortet til L3-sikkerhetsnivået, og returverdien er (ATQA: 02 00, SAK: 20, UID: CD 65 E5 03).
Kjør L1- og L2-nivåoperasjoner i aktiv tilstand (ISO14443-3-lag); når kortet er på L1-nivå, kan M1-relaterte grensesnitt implementeres fullt ut, eller AES SL1-sertifisering kan utføres først, og deretter kan M1-sertifisering utføres. Etter å ha utført AES SL1-godkjenning, er det ikke nødvendig å generere en øktnøkkelbase og beregne med M1-tasten for å utlede den nye M1-nøkkelen som den virkelige M1-godkjenningsnøkkelen, bare bruk den originale M1-nøkkelen direkte (dette punktet er forskjellig fra L2 nivå).
På L0-nivå er returkoden til PICC etter utførelse ACK / NAK i samsvar med M1-kortet, det er en nippelreturkode uten CRC, så når CRC-sjekken er slått på, oppstår en CRC-feil;
Når LES-nivået AES SL1-autentiseringsprosess er korrekt, vil den returnere returkoden og informasjonen med CRC, og når det er en feil (AES-nøkkelfeil, RNDB-dekrypteringsfeil osv.), Vil den returnere NAK samsvarer med M1-kortet, som er en halv byte og det er ingen CRC-feil, så når CRC-kontroll er slått på, vil det oppstå en CRC-feil.
SwitchL2-instruksjonen utføres på ISO14443-4 nivå. Etter at utførelsen er vellykket, går PICC inn på L2-sikkerhetsnivået. På dette tidspunktet utføres switchL2-instruksjonen ved første overføring av Cmd + BNo + LenCap + PCDCap2, som returnerer to statusbyte 0x02, 0x09. 0x09 kan forstås som et ugyldig blokknummer, men 0x02 kan ikke forstås.
I L2-nivået, som angitt i håndboken, må AES-autentisering utføres før M1-autentisering, og de nedre 6 byte i øktnøkkelbasen generert av AES blir XORed med M1-nøkkelen til den faktiske blokken for å bli den virkelige M1-blokkgodkjenningen nøkkel. Etter testing må AES-nøkkeltypen være i samsvar med M1-nøkkeltypen (det vil si at begge er A eller B), ellers mislykkes M1-godkjenningen! Når nøkkeltypene og verdiene AES og M1av sektor A stemmer overens med sektor B, er tilgangen til sektor B etter autentisering av sektor A konsistent med tilgangen til sektor A, og det er ikke behov for tilgang til sektor B. Sertifisering.
Under feilsøking av mifPLAuthInPro på sikkerhetsnivå L2, når s_AESCbcEnDecrypt kalles, vil inngangen iv bli omskrevet etter at kryptering og dekryptering er fullført, noe som resulterer i neste kryptering og dekryptering iv endres og kryptering og dekryptering mislykkes! Må ta hensyn til verdien av iv!
På L2-sikkerhetsnivå må den obligatoriske AES + M1-nøkkelautentiseringen holde AES-nøkkeltypen i samsvar med M1-nøkkeltypen (dvs. AES TypeA-nøkkel + M1 TypeA-nøkkel eller AES TypeB-nøkkel {{6} } M1 TypeB-nøkkel, for eksempel AES TypeA-nøkkel + M1 TypeB-nøkkelautentisering mislykkes selv om nøklene er riktige!)
Etter å ha fullført feilsøking på L2-nivå, kan du utføre FirstAuth gjentatte ganger, og TI-verdien oppnådd av FirstAuth er forskjellig hver gang. Etter å ha utført en riktig FirstAuth-autentisering og få TI, kan riktig followAuth utføres (followAuth' s iv er basert på FirstAuth-autentisering). Etter at riktig FirstAuth er utført en gang, kan followAuth gjentas. Siden FirstAuth og followAuth kjøres i ISO14443-4-modus, forblir PICC i ISO14443-4-modus når det oppstår en feil, og det er ikke nødvendig å søke på kortet på nytt.
MultiWriteBlock- og MultiReadBlock-kommandoene på L2-sikkerhetsnivået støtter bare flere datablokk- og skriveoperasjoner i samme sektor! Kommandoene ReadBlock og WriteBlock på sikkerhetsnivået L3 støtter kontinuerlig lesing og skriving av datablokker på tvers av sektorer (bare innenfor denne sektoren !!!)
L3 sikkerhetsnivå followAuth-operasjon for å oppnå ENC KEY og MAC KEY-kryptering brukt iv vector er 0 i stedet for TI + W_ctr + R_ctr!
I ISO14443-4-modus, så lenge det er noen feil, må FirstAuth-operasjonen utføres!
Forståelse av M1-kortverdirelaterte operasjoner: Essensen av kommandoen Gjenopprett er å kopiere den tilsvarende verdien av den innkommende datablokken (må være i lommebokformat) til en 16-byte overføringsbuffer inne i M1-kortet, og essensen av Overføringskommando er til Overføringsbufferverdien inne i M1-kortet kopieres til den innkommende datablokken. Essensen av Increment-kommandoen er å legge til verdien av inngangslommebokblokken til merverdien og kopiere den til Transfer Buffer, så Transfer-kommandoen må kalles på nytt for å kopiere Transfer Buffer-verdien til den angitte datablokken.
https://www.szrcloud.com/card-reader/rfid-card-reader/rfid-card-reader-in-games.html