Android ujjlenyomat api csatolja az ujjlenyomat-hitelesítést

Üdvözlet!
Beletelt elég hosszú ideig, milyen volt ujjlenyomat API az Android, a hálózat sok különböző minta kódját annak végrehajtására és használatára, de ügyéről, valamilyen oknál fogva, ez a téma, hogy kerek. Véleményem szerint ideje megoldani ezt a félreértést.
Mindenki érdeklődik egy macskától.

Legrövidebb oktatási program

Tehát mi az ujjlenyomat-API?
Az API lehetővé teszi a felhasználó számára az ujjlenyomatának hitelesítését, nyilvánvalóan.
Az érzékelő API használatához FingerprintManager kínál. elég könnyű megtanulni.

Hogyan kell használni?
De ez érdekesebb.
Szinte mindenhol, ahol jelszó-hitelesítésre van szükség, az ujjlenyomat segítségével hitelesíthető.
Képzelj el egy alkalmazást, amely a LoginActivity és a MainActivity elemekből áll. Indításkor belépünk a bejelentkezési képernyőbe, írjuk be a PIN kódot, menjünk az adatokhoz. Az ujjlenyomattal azonban a bemenetet pin-kóddal kell helyettesíteni.
By the way, nem egészen kap egy csere, csak akkor tudjuk menteni a felhasználó manuálisan egy PIN kód beírása, hogy ebben az esetben a korábban tárolt PIN (azaz a kliens-szerver alkalmazás, amelyben azt szeretnénk, hogy elküldi a jelszót szerver).
Kezdjük.

Hol van az érzékelő?

Az új API használatának elkezdéséhez az első lépés, hogy engedélyt adjon a manifestben:

Természetesen az Ujjlenyomat-API csak az olyan eszközökön használható, amelyek támogatják őket: ennek megfelelően ezek az Android 6+ eszközök érzékelővel rendelkeznek.
A kompatibilitás a módszerrel könnyen ellenőrizhető:

Az FingerprintManagerCompat kényelmes csomagolóanyag a szokásos FingerprintManager számára. amely egyszerűsíti az eszköz kompatibilitási ellenőrzését, lezárva az API-verzió ellenőrzést. Ebben az esetben az isHardwareDetected () a false értéket adja vissza. ha az API 23 alatt van.

Ezután meg kell értenünk, hogy az érzékelő készen áll-e a használatra. Ehhez enum állapotokat definiálunk:

És használjuk a módszert:

A kód elég triviális. Egy kis félreértés okozhat egy pillanatot, amikor ellenőrizzük, hogy az eszköz zárolva van-e. Szükségünk van erre a tesztre, hiszen bár az Android nem engedélyezi az ujjlenyomatok védelem nélküli eszközhöz való hozzáadását, egyes gyártók megkerülik azt, ezért nem fog fájni.
Különböző állapotok használhatók arra, hogy a felhasználó megértse, mi történik, és irányítja az igazi utat.

A

Tehát, anélkül, hogy megpróbálnánk ellenőrizni az érvényességi PIN-kódot, a következő egyszerűsített műveletek logikáját becsüljük:

• A felhasználó PIN kódot ad meg, ha a SensorState.READY. akkor mentjük a PIN-kódot, futtassuk a MainActivity-ot.
• Indítsa újra az alkalmazást, ha a SensorState.READY. majd olvassa el az ujjlenyomatot, kapja meg a PIN-kódot, szimulálja annak bemeneteit, futtassa a MainActivity szolgáltatást.

A rendszer egyszerűbb lenne, ha nem egy dolog: a Google erősen javasolja, hogy ne tárolja magán felhasználói adatokat a tiszta. Ezért szükség van egy titkosítási és dekódolási mechanizmusra a megőrzéshez és a felhasználáshoz. Meg fogjuk csinálni.

Mit kell titkosítani és visszafejteni:

1. Védett kulcstartó.
2. Titkosítási kulcs.
3. Cipher Cipher

A nyomatokkal való együttműködés érdekében a rendszer saját kulcstartót biztosít - "AndroidKeyStore", és biztosítja a jogosulatlan hozzáférés elleni védelmet. Használjuk:

El kell fogadni, megérteni és megbocsátani, hogy a kulcstároló csak titkosítási kulcsokat tárol. A jelszavakat, a PIN-kódokat és egyéb privát adatokat nem lehet tárolni.

A kulcsok két lehetősége közül választhatunk: egy szimmetrikus kulcsot és egy pár nyilvános és privát kulcsot. Az UX megfontolásokból egy pár felhasználásával. Ez lehetővé teszi számunkra, hogy elválasszuk a nyomtatott bemenetet a PIN-kód titkosításától.

A kulcstól kapjuk a kulcstartót, de először meg kell adnunk őket. Kulcs létrehozásához használja a generátort.

Az inicializáláskor meg kell adnunk, hogy melyik kulcsstorm kapja meg a generált kulcsokat, és melyik algoritmussal rendelkezik a kulcs.
Ugyanaz a generáció a következőképpen alakul:

Itt két helyen kell figyelmet fordítani:

• A KEY_ALIAS a kulcs aliasja, amellyel kivonjuk a kulcstartóból, a szokásos psf-ekből.
• .setUserAuthenticationRequired (true) - ez a jelző azt jelzi, hogy minden alkalommal, amikor szükségünk van a kulcs használatára, meg kell erősítenünk magunkat, esetünkben ujjlenyomat használatával.

Ellenőrizze a kulcs jelenlétét az alábbiak szerint:

Cipher Cipher

A titkosítást és a dekódolást Java-ban a Cipher objektum kezeli. Inicializálja:

Az argumentum ad hoc hodge-podge az átalakítás sztringje, amely magában foglalja az algoritmust. keverési mód és hozzáadás.

Miután megkaptuk a Cipher-t. fel kell készíteni a munkára.
A kulcs létrehozásakor jeleztük, hogy csak titkosításra és dekódolásra fogjuk használni. Ennek megfelelően a Cipher is ebből a célból fog megvalósulni:

ahol az initDecodeCipher () és az initEncodeCiper () a következők:

Nem nehéz látni, hogy a titkosítási Cipher némileg nehezebb inicializálni. Ez maga a Google kósza, amelynek lényege, hogy a nyilvános kulcs felhasználói megerősítést igényel. Ezt a követelményt megkerüljük egy kulcs benyomás segítségével (mankó, igen).

Moment with KeyPermanentlyInvalidatedException - ha valamilyen oknál fogva a kulcs nem használható, akkor ez a kivétel érvénybe lép. Lehetséges okok közé tartozik az, hogy új nyomtatást ad hozzá egy meglévőhöz, megváltoztatva vagy teljesen eltávolítva a zárat. Ezután a kulcsnak már nincs értelme tárolni, és töröljük.

A teljes oktatási láncot összegyűjtő módszer:

Titkosítás és dekódolás

Lássunk egy olyan eljárást, amely titkosítja az argumentumkészletet:

Ennek eredményeképpen megkapjuk a Base64-et, amely az alkalmazás preferenciáin biztonságosan tárolható.

A dekódoláshoz ugyanazt a módszert használjuk:

Opa, a bemeneten nem csak a titkosított karakterláncot, hanem a Cipher objektumot is.
Ahol jött, később lesz látható.

Rossz ujj

Az érzékelő végleges használatához az FingerprintManagerCompat módszert kell használnia:

Hendler és zászlók, most nem kell a jelet használják, hogy megszünteti az ujjlenyomat-olvasó módban (ha minimalizált alkalmazások, például), visszahívások eredményét adja vissza egy adott olvasó, de több kriptoobektom részletesebben.
Ebben az esetben a CryptoObject a Cipher csomagolásaként használható. Ehhez használja a módszert:

Mint mondtam, az érzékelő olvasásának eredményei a visszacsatolási módszerekhez jutnak. Így néz ki:

Sikeres felismerés esetén az AuthenticationResult. ahonnan megkaphatjuk a "Cipher" objektumot a már ellenőrzött kulcsmal:

Köszönöm a figyelmet.