Днес мобилните ни устройства са практически дневник, в който съхраняваме всичко: от интимни снимки до данните на кредитните ни карти. Ето защо не можем да оставим сигурността на случайността. Що се отнася до защитата на чувствителни данни в Android, системата за съхранение на ключове Android се превръща в ключов инструмент за предотвратяване на кражба на криптографските ни ключове от злонамерени лица, което я прави основен стълб на сигурността на Android.
По принцип, тази система действа като дигитален сейф. Вместо да съхранява ключовете като прости текстови файлове в паметта на телефона (което би било катастрофа за сигурността), тя ги заключва в защитен контейнер . Най-хубавото е, че след като ключът е вътре, можете да го използвате за криптиране или подписване на неща, но той никога не може да бъде извлечен от устройството, дори ако операционната система е била компрометирана.
Как работи сигурността в основата на системата?
Keystore не се забърква и защитава ключовите данни по два много ясни начина. Първо, предотвратява кражбата на ключовите данни от всеки извън устройството, тъй като блокира извличането им от процесите на приложенията. Второ, гарантира, че дори някой да успее да получи достъп до системата, не може да използва ключа за каквото си поиска; приложенията трябва да дефинират оторизирани употреби, които системата стриктно прилага.
За да направи това наистина надеждно, Android разчита на хардуер. Ключовите данни не преминават през процесите на приложението; когато трябва да извършите операция, данните се изпращат към специализиран системен процес . Освен това, ако телефонът е модерен, ключовете са свързани с Trusted Execution Environment (TEE) или Secure Element (SE). Ако имате устройство със StrongBox , сигурността се издига на следващото ниво, тъй като този модул има собствен процесор, защитено хранилище и истински генератор на случайни числа, което го прави устойчив дори на физически атаки.
За да определят дали даден ключ е наистина защитен от хардуер, разработчиците могат да използват `getSecurityLevel()` в Android 10 и по-нови версии. Ако резултатът е `TRUSTED_ENVIRONMENT` или `STRONGBOX` , можем да бъдем сигурни, че ключът се намира в област, изолирана от главния процесор.
Контрол на достъпа и разрешения за ползване
Една от най-добрите характеристики на тази система е, че можете да зададете „правила“ на всеки ключ, когато го създавате. Тези правила са непроменими; веднъж зададени, те не могат да бъдат променяни . Например, можете да ограничите ключ до работа само с конкретни алгоритми , като AES или RSA, или да определите точен период от време, през който ключът е валиден.
Но най-силното нещо е удостоверяване на потребителяМожете да конфигурирате ключа да работи само ако потребителят наскоро се е удостоверил с помощта на своя ПИН код, шаблон или биометрични данни (пръстов отпечатък или лице)), като се има предвид, че 2D срещу 3D отключване с лицево разпознаване Предлага различни нива на защита. Има два режима: един, който оторизира всички ключове за определено време след удостоверяване, и друг, по-строг, при който всяка крипто операция трябва да бъде упълномощено индивидуално чрез BiometricPrompt.
Ключодържател срещу доставчик на хранилище за ключове за Android
Понякога може да се чудите кой да изберете. KeyChain API е идеалният вариант, когато имате нужда от системни идентификационни данни. Тук потребителят избира, чрез системен интерфейс, кои идентификационни данни иска да сподели с приложението. Това е много полезно за идентификационни данни, споделяни между множество приложения с изричното съгласие на собственика на мобилното устройство.
От друга страна, Доставчик на хранилище за ключове за Android Проектирано е така, че всяко приложение да управлява собствените си ключове частно. Това е предпочитаният вариант, когато искате само вашето приложение имат достъп до своите тайни, без потребителят да е необходимо ръчно да избира ключове от списък. За да се реализира това, се използват стандартни Java класове, като например KeyStore, KeyPairGenerator o KeyGenerator.
Техническа имплементация: Криптиране и подписи
За симетрично криптиране на данни, AES-GCM е най-препоръчителният метод . Този метод не само поддържа секретност, но и гарантира целостта на данните, като открива дали криптираните байтове са били подправени. Важно е да се помни, че всяка операция генерира уникален инициализационен вектор (IV) , който трябва да се съхранява заедно с криптираните данни, за да се обърне операцията.
Ако имате нужда от цифров подпис, най-добрият начин е да използвате RSA . В хранилището за ключове се генерира двойка ключове (публичен и частен). Частният ключ остава заключен в защитен хардуер, за да подпише информацията , докато публичният ключ може да бъде разпространен, за да се провери дали съобщението не е било променено и че идва от оригиналния източник.
Вътрешна архитектура и еволюция на системата
Под капака системата е сложна машина. AndroidKeyStore Това е видимото лице на приложението, но то комуникира с демон за съхранение на ключове чрез Binder. Този демон управлява keyblobs (криптирани ключове) и разчита на HAL на KeyMint (бивш Keymaster) за извършване на тежки задачи в света на сигурността.
Пътят е дълъг: от Android 6.0, който въведе контрол на достъпа и AES/HMAC примитиви, през Android 7.0 със сертифициране на ключове и свързване на версии (за да се предотврати понижаване на версията на операционната система до уязвима версия от страна на атакуващ), до Android 12. В тази последна версия демонът е пренаписан на Rust , за да се повиши сигурността, и е въведен HAL на KeyMint, който поддържа ECDH споразумения за ключове и ограничения за използване на ключове.
Съдебна перспектива и рискове при извличане
Въпреки че хранилището за ключове е много надеждно, в света на компютърната криминалистика има методи за извличане на информацията. Ключовете се съхраняват криптирани в /misc/keystore/ (или в SQLite база данни от Android 12 насам). За да ги защитите, a Ключ за криптиране на ключ (KEK) получени от фиксирани стойности на защитения хардуер.
Някои експерти по дигитална криминалистика се опитват да извършат офлайн декриптиране, като извличат хардуерни стойности чрез специфични за процесора уязвимости (като MTK или Qualcomm). Ако успеят да получат KEK (Keystore Key), те могат да декриптират ключовете в хранилището за ключове и впоследствие да получат достъп до криптирани бази данни на приложения като Signal или Element , които обикновено използват хранилището за ключове, за да защитят главния ключ на своите бази данни Realm.
