Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Security
Code

Mga Keys, Credentials at Storage sa Android

by
Difficulty:IntermediateLength:LongLanguages:

Tagalog (Wikang Tagalog) translation by Anna Nelson (you can also view the original English article)

Sa nakaraang post tungkol sa seguridad ng Android user data, tinignan natin ang pag-eencrypt ng datos sa pamamagitan ng passcode na binigay ng user. Ililipat ng pagtuturong ito ang focus sa credential at key storage. Sisismulan ko sa pamamagitan ng pagpapakilala ng mga account credentials at tatapusin ito sa pamamagitan ng isang halimbawa ng paprotekta ng data gamit ang KeyStore.

Kadalasan, kapag gumagamit ng isang third-party service, mangangailangan ng ilang uri ng authentication. Maaaring kasingsimple lang ito ng isang /login endpoint na tumatanggap ng isang username at password.

Sa una, mukhang ang pinaksimpleng solusyon ay bumuo ng isang UI na nanghihingi sa user na maglog-in, pagkatapos ay kunin at iimbak ang kanilang mga login credentials. Gayunpaman, hindi ito ang pinakamahusay na kasanayan sapagkat hindi dapat kailanganing alamin ng ating app ang ating mga credentials para sa isang third-party account. Sa halip, maaari nating gamitin ang Account Manager, na nagtatalaga ng pag-aasikaso ng sensitibong kaaalaman na ito para sa atin.

Ang Account Manager

Ang Account Manager ay isang sentralisadong taga-alalay para sa mga credentials ng user account para hindi na tuwirang alalahanin ng iyong app ang pag-aasikaso ng mga password. Kadalasan itong nagbibigay ng isang token kapalit ng tunay na username at password na maaaring gamitin upang gumawa ng mga authenticated na mga requests sa isang service. Ang isang halimbawa ay kapag nag-rerequest ng isang token ng OAuth2.

Minsan, ang kinakailangan lang na impormasyon ay nakalagay na sa device, at sa ibang pagkakataon naman ay kakailanganin ng Account Manager tumawag sa server para sa isang na-refresh na token. Maaaring nakita mo na ang Accounts section sa Settings ng iyong device para sa sari-saring mga apps. Maaari tayong makakuha ng listahan ng mga available accounts na gaya nito:

Ang code ay mangangailangan ng permission ng android.permission.GET_ACCOUNTS Kung may isang tiyak na account kang hinahanap, maaari mo itong hanapin sa ganitong paraan:

Kapag nasa iyo na ang account, makakakuha ka ng isang token para sa account sa pamamagitan ng pagtawag sa getAuthToken (Account, String, Bundle, Activity, AccountManagerCallback, Handler) method. Ang token ay maaaring gamitin upang gumawa ng mga authenticated na API requests sa isang service. Maaari itong maging isang RESTful na API, kung saan ipinapasa mo ang isang token parameter habang ginagawa ang HTTPS request, ng hindi inaalam ang pribadong account details ng user.

Dahil ang bawat serbisyo ay may iba-ibang paraan ng pag-aauthenticate at pag-iimbak ng mga pribadong credentials, binibigay ng Account Manager ang mga authenticator modules para maipatupad ang isang third-party service. Habang ang Android ay mayroong mga pagpapatupad para sa maraming popular na mga serbisyo, nangangahuluhan iyong maaari kang magsulat ng sarili mong authenticator upang asikasuhin ang account authentication at pag-iimbak ng credential ng iyong app. Binibigyan ka nito ng kakayahang siguruhing ang mga credentials ay encrypted. Tandaan, nangangahulugan din ito na ang mga credentials sa Account Manager na ginagamit ng ibang mga serbisyo ay maaaring iimbak sa clear text, na ginagawa itong madaling makita sa sinumang naka-root ang device.

Sa halip na simpleng credentials lang, may mga panahong kakailanganin mong gumamit ng isang key o isang certificate para sa isang indibidwal o entity-halimbawa, kapag ang isang third party ay nagpadala sa iyo ng isang certificate file na kailangan mong itago. Ang pinakamadalas na scenario ay kapag ang app ay kailangang mag-authenticate sa server ng isang pribadong organisasyon.

Sa susunod na pagtuturo, tatalakayin natin ang paggamit ng mga certificates para sa authentication at ligtas na komunikasyon, ngunit gusto ko munang talakayin kung papaano iimbak ang mga items na ito. Ang Keychain API ay orihinal na binuo para sa tiyak na gamit na ito-pag-iinstall ng isang pribadong key o pares ng certificate mula sa isang PKCS#12 na file.

Ang Keychain

Ipinakilala sa Android 4.0 (API_Level 14), ang Keychain_API ay tumatalakay sa pamamahala ng mga keys. Sa katiyakan, gumagana ito sa mga PrivateKey at X509Certificate na objects at nagbibigay ng isang mas ligtas na lalagyan kaysa sa paggamit ng imbakan ng datos ng iyong app. Ito’y dahil ang mga permissions para sa pribadong keys ay nagbibigay lang ng kakayahan sa iyong sariling app upang maaccess ang mga keys, matapos ang authorization ng user. Ibig sabihin nito ay kailangang magsetup ng lock screen sa device bago kayo makagamit ng imbakan ng mga credentials. Higit pa riyan, ang mga objects sa keychain ay maaaring nakatakdang bigyang-seguridad ang hardware, kung available.

Ang code para mag-install ng isang certificate ay gaya ng sumusunod:

Ang user ay hihingan ng isang password upang ma-access ang pribadong key at isang pagkakataong pangalanan ang certificate. Upang mabawi ang key, ang sumusunod na code ay nagpapakita ng isang UI na hinahayaan ang user na mamili mula sa isang listahan ng mga naka-install nang mga keys.

Kapag nakapili na, isang pangalan ng string alias ang ibabalik sa alias(final String alias) na callback kung saan maaari ninyong tuwirang maaccess ang pribadong key o certificate chain.

Taglay ang kaalamang ito, tignan natin kung papaano natin pwedeng gamitin ang imbakan ng mga credentials upang i-save ang sarili ninyong sensitibong datos.

Ang KeyStore

Sa nakaraang pagtuturo, tinalakay natin ang pagprotekta ng datos sa pamamagitan ng passcode na binigay ng user. Ang ganitong uri ng setup ay mabuti, ngunit ang mga pangangailangan ng app ay madalas umiiwas sa pangangailangang maglog-in ng user kada oras at umalala ng karagdagang passcode.

Dito maaaring magamit ang Keystore_API. Mula sa API 1, ginagamit na ny system ang KeyStore upang mag-imbak ng mga credentials ng WiFi at VPN. Sa 4.3 (API 18), binibigyan ka nito ng kakayahang kumilos gamit ang sarili mong app-sepcific na mga keys, at sa Android M (API 23) naman ay maaari itong mag-imbak ng AES symmetric na key. Kaya habang hindi pa pinapayagan ng API ang tuwirang pag-iimbak ng mga sensitibong strings, maaaring iimbak ang mga keys na ito at pagkatapos ay gamitin ito upang mag-encrypt ng mga strings.

Ang benepisyo ng pag-iimbak ng isang key sa KeyStore ay hinahayaan nito ang mga keys na mapatakbo ng hindi ibinubunyag ang lihim na laman ng key na ito; hindi pumapasok sa app space ang key data. Tandaan na ang mga keys ay protektado ng mga permissions upang tanging ang app ninyo lang ang makaka-access sa mga ito, at karagdagang maaaring maging maging secure hardware-backed kung kaya ng device. Gumagawa ito ng isang lalagyan na pinapahirap ang pag-eextract ng mga keys mula sa isang device.

Lumikha ng Bagong Random Key

Para sa halimbawang ito, sa halip na lumikha ng isang AES key mula sa isang passcode na binigay ng passcode, maaari tayong mag auto-generate ng isang random key na magiging protektado sa isang KeyStore. Magagawa natin ito sa pamamagitan ng paglikha ng isang KeyGenerator na instance, na naka-set sa "AndroidKeyStore".

Ang mahahalagang bahaging makita dito ay ang mga .setUserAuthenticationRequired(true) at .setUserAuthenticationValidityDurationSeconds(120) na specifications. Nangangailangan ang mga ito ng isang lock screen upang mai-setup at ang key na kailangang mai-lock hanggang ang user ay ma-authenticate.

Kapag tinignan natin ang documentation para sa .setUserAuthenticationValidityDurationSeconds(), makikita ninyo na nangangahulugan itong ang key ay available lamang sa loob ng iilang Segundo mula sa password authentication, at ang pagpapasa ng -1 ay nangangailangan ng fingerprint authentication sa bawat pagkakataong gusto mong i-access ang key. Ang pag-eenable ng pangangailangang mag-authenticate ay taglay din ang effect ng pagbawi ng key kapag tinanggal o binago ng user ang kanyang lock screen.

Dahil ang pag-iimbak ng isang di-protektadong key kasabay ng encrypted na datos ay gaya ng paglalagay ng susi ng bahay sa ilalim ng doormat, ang mga pagpipiliang ito ay sinusubukang protektahan ang naka-tenggang key sa oras na ang isang device ay makompromiso. Isang maaaring maging halimbawa ay ang isang offline data dump ng device. Kung wala ang password na kilala para sa device, ang datos na ito ay walang silbi.

Ang .setRandomizedEncryptionRequired(true) na option ay ine-enable ang requirement na mayronng sapat na randomization(isang bagong random IV kada panahon) para kung ang parehong datos ay na-encrypt sa ikalawang pagkakataon, ang encrypted output ay magiging iba parin. Pinipigilan nito ang isang attacker sa pagkamit ng mga palatandaan tungkol sa ciphertext batay sa pag-feed sa parehong datos.

Ang isa pang pagpipiliang maaaring isaalang-alang ay ang setUserAuthenticationValidWhileOnBody(boolean remainsValid), na ikinakandado ang key kapag napag-alaman nitong ang device ay wala na sa tao.

Pag-eencrypt ng Datos

Ngayon na ang key ay nakaimbak na sa KeyStore, maaari na tayong gumawa ng isang method na nag-eencrypt ng datos gamit ang Cipher object, kapag mayroon nang SecretKey. Magbabalik ito ng isang HashMap na nilalaman ang encrypted na datos at isang randomized IV na kakailanganin upang i-decrypt ang datos. Ang encrypted na datos, kasama ng IV, ay maaaring iimbak sa isang file o tungo sa nakabahaging mga preferences.

Pag-dedecrypt patungo sa isang Byte Array

Para sa decryption, ginagamit natin ang kabaliktaran Ang Cipher object ay ini-initialize gamit ang DECRYPT_MODE constant, at ang decrypted byte na byte[] array ay ibinabalik.

Pagsubok sa Halimbawa

Maaari na nating subukin an gating halimbawa!

Gamit ang Asymmetric Keys ng RSA para sa Mga Mas Lumang Devices

Ito ay isang magandang solusyon para mag-imbak ng datos para sa bersyong M at mas mataas pa, ngunit papaano naman kung suportado ng iyong app ang mga naunang mga bersyon? Habang ang mga symmetric keys ng AES ay hindi suportado sa ilalim ng M, ang symmetric keys ng RSA ay suportado naman. Ibig sabihin nito ay maaari nating gamitin ang mga RSA keys at encryption upang magawa ang parehong bagay.

Ang pinakapinagkaiba nito ay ang isang asymmetric keypair ay naglalaman ng dalawang keys, isang pribado at publikong key,kung saan ang pampublikong key ay ine-encrypt ang datos at ang pribadong key ay dine-decrypt ito. Ang AKeyPairGeneratorSpec ay ipinapasa tungo sa KeyPairGenerator na ini-initialize gamit ang provider ng KEY_ALGORITHM_RSA at "AndroidKeyStore".

Upang mag-encrypt, kukunin natin ang RSAPublicKey mula sa keypair at gamitin ito kasama ang Cipher object.

Ang decryption ay ginagawa gamit ang RSAPrivateKey object.

Ang isang bagay mula sa RSA ay ang encryption ay mas mabagal kaysa sa AES. Kadalasan ay ayos lang ito para sa kakaunting dami ng impormasyon, gaya ng kapag nagse-secure ng mga strings para sa shared preference. Kung mapapagalaman mong mayroong isang problema sa performance habang nag-eencrypt ng malalaking dami ng datos, maaari mong gamitin sa halip ang halimbawang ito at mag-imbak lang ng AES key. Matapos ito, gamitin ang mas mabilis na AES encryption na tinalakay sa nakaraang pagtuturo para sa kabuuan ng iyong datos. Maaari kang mag-generate ng isang bagong AES key at i-convert ito sa isang byte[] array na compatible sa halimbawang ito.

Upang makuha ang key pabalik mula sa mga bytes, ito ang kailangang gawin:

Andaming code noon! Upang mapanatiling simple ang lahat ng mga halimbawang ito, tinanggal ko na ang masinsinang exception handling. Ngunit tandaan na para sa iyong production code, hindi inirerekumenda na i-catch ang lahat ng Throwable na mga cases sa loob ng isang catch statement.

Konklusyon

Dito nagtatapos ang pagtuturo sa pag-asikaso ng mga credentials at mga keys. Karamihan sa kalituhan sa mga keys at pag-iimbak ay may kinalaman sa ebolusyon ng Android OS, ngunit maaari mong piliin ang solusyon ang gusto mong gamitin kung alam mo ang antas ng API na suportado ng iyong app.

Ngayong natalakay na natin ang lahat ng pinakamahusay na kasanayan sa pagse-secure ng datos at ang iba pa, ang susunod na pagtuturo ay tututok sa pagse-secure ng datos habang inihahatid ito.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.