Свой-чужой. Как работает биометрия и Secure Enclave в современных телефонах

Ес­ли ты дела­ешь при­ложе­ния с аутен­тифика­цией или прос­то хочешь понять, почему Face ID безопас­нее четырех­знач­ного пина, — эта статья для тебя. Пос­ле проч­тения ты смо­жешь гра­мот­но интегри­ровать биомет­рию в свои про­екты и объ­яснить кли­ентам, почему их дан­ные в безопас­ности.

Эра доверенного устройства

Лет семь назад я работал над финан­совым при­ложе­нием. Мы хра­нили хеши паролей в базе — SHA-256, соль, все по учеб­нику. И все рав­но спа­ли пло­хо. Потому что база мог­ла утечь, радуж­ные таб­лицы сущес­тво­вали, а поль­зовате­ли упор­но ста­вили password123 или свою дату рож­дения. Каж­дый новый дамп из оче­ред­ного взло­ман­ного сер­виса добав­лял нер­вознос­ти.

Об­лачная биомет­рия казалась спа­сени­ем. Ска­ниру­ешь лицо, отправ­ляешь на сер­вер, там срав­нива­ешь с эта­лоном. Но доверие к такому под­ходу испа­рилось мгно­вен­но, как толь­ко начали появ­лять­ся новос­ти об утеч­ках шаб­лонов отпе­чат­ков. Пред­ставь: твой пароль мож­но сме­нить, а вот отпе­чаток паль­ца или скан лица — нет. Если они утек­ли, ты ском­про­мети­рован нав­сегда.

В Apple и Google решили проб­лему радикаль­но: устрой­ства сде­лали зам­кну­тым, физичес­ки защищен­ным кон­туром для аутен­тифика­ции. Твой отпе­чаток паль­ца или скан лица никог­да не покида­ют этот кон­тур. Не переда­ются в при­ложе­ние, не уле­тают на сер­вер, даже не попада­ют в обыч­ную опе­ратив­ную память телефо­на.

Даль­ше я под­робно покажу, как тех­ничес­ки устро­ена эта изо­ляция, почему это дей­стви­тель­но работа­ет и как исполь­зовать эти механиз­мы в сво­их при­ложе­ниях.

Основа основ: песочницы, TEE и Secure Enclave

Песочница приложения (App Sandbox)

Нач­нем с базы. Каж­дое при­ложе­ние на iOS и Android живет в сво­ей изо­лиро­ван­ной песоч­нице. Это озна­чает:

• У при­ложе­ния есть собс­твен­ная дирек­тория для фай­лов, куда дру­гие при­ложе­ния не име­ют дос­тупа.
• Оно работа­ет в отдель­ном про­цес­се с собс­твен­ным адресным прос­транс­твом в памяти.
• ОС стро­го кон­тро­лиру­ет, к каким сис­темным ресур­сам при­ложе­ние может обра­щать­ся.

На iOS песоч­ница реали­зова­на через механиз­мы sandbox-exec и entitlements. Каж­дое при­ложе­ние из App Store запус­кает­ся с огра­ничен­ным набором прав. Хочешь получить дос­туп к камере? Нужен соот­ветс­тву­ющий entitlement и явное раз­решение поль­зовате­ля. Хочешь про­читать фай­лы дру­гого при­ложе­ния? Забудь, это физичес­ки невоз­можно без джей­лбрей­ка.

На Android песоч­ница осно­вана на механиз­мах Linux: каж­дое при­ложе­ние получа­ет уни­каль­ный UID и работа­ет в собс­твен­ном про­цес­се. SELinux (Security-Enhanced Linux) добав­ляет допол­нитель­ные пра­вила ман­датно­го кон­тро­ля дос­тупа.

Но вот что важ­но понять: песоч­ница защища­ет при­ложе­ния друг от дру­га, но не защища­ет от самой ОС. Опе­раци­онная сис­тема име­ет пол­ный дос­туп ко всей памяти и всем про­цес­сам. Если в ядре iOS или Android есть уяз­вимость, зло­умыш­ленник с root-дос­тупом может читать память любого при­ложе­ния.

Для биомет­рии это­го недос­таточ­но. Нужен еще один уро­вень изо­ляции — уро­вень, который защищен даже от опе­раци­онной сис­темы.

Уровни доверия в процессоре

Сов­ремен­ный про­цес­сор ARM в смар­тфо­не — это не монолит­ный чип, где все выпол­няет­ся в одном кон­тек­сте. Это слож­ная архи­тек­тура с нес­коль­кими изо­лиро­ван­ными вычис­литель­ными кон­турами, у каж­дого из которых свой уро­вень при­виле­гий.

Rich OS (обычная операционная система)

Здесь живут iOS или Android, все при­ложе­ния, бра­узе­ры, игры, мес­сен­дже­ры. Это «обыч­ный мир» (Normal World в тер­миноло­гии ARM), где кру­тит­ся весь поль­зователь­ский код. Здесь работа­ет основное ядро Linux (на Android) или XNU (на iOS).

TEE (Trusted Execution Environment) — доверенная среда выполнения

TEE — это изо­лиро­ван­ная сре­да выпол­нения, физичес­ки отде­лен­ная от Rich OS на уров­не про­цес­сора. Реали­зова­на через тех­нологию ARM TrustZone.

Как это работа­ет? Про­цес­сор может перек­лючать­ся меж­ду дву­мя режима­ми: Normal World и Secure World. Перек­лючение про­исхо­дит через спе­циаль­ную инс­трук­цию SMC (Secure Monitor Call), которая вызыва­ет Secure Monitor — мик­рояд­ро, управля­ющее перехо­дами меж­ду мирами.

В Secure World выпол­няет­ся собс­твен­ная мик­роОС (нап­ример, Trusty на Android или sepOS на iOS). Эта ОС име­ет дос­туп к защищен­ной области памяти, которая не­дос­тупна для Normal World. Даже если хакер получит root в Android или iOS, он не смо­жет про­читать память Secure World.

В Android TEE называ­ется прос­то TrustZone. Но в топовых устрой­ствах (нап­ример, Google Pixel с чипом Titan M или Samsung с Knox) добав­ляет­ся StrongBox Keymaster — отдель­ный аппа­рат­ный модуль безопас­ности. Это физичес­ки отдель­ный чип, который работа­ет как уси­лен­ный TEE и хра­нит крип­тогра­фичес­кие клю­чи в еще более защищен­ной сре­де.

Apple Secure Enclave

Ин­женеры Apple пош­ли даль­ше. Вмес­то того что­бы исполь­зовать TrustZone как режим основно­го CPU, они соз­дали отдель­ный крип­тогра­фичес­кий соп­роцес­сор — Secure Enclave. Это физичес­ки отдель­ный кусок крем­ния на том же чипе A-серии (или M-серии в Mac).

Secure Enclave — это пол­ноцен­ный компь­ютер внут­ри iPhone:

• собс­твен­ный про­цес­сор (модифи­циро­ван­ный ARM);
• собс­твен­ная зашиф­рован­ная память (обыч­но 4 Мбайт);
• собс­твен­ная опе­раци­онная сис­тема (sepOS — Secure Enclave Processor OS, осно­ван­ная на L4 microkernel);
• собс­твен­ный генера­тор слу­чай­ных чисел;
• собс­твен­ная заг­рузоч­ная ROM, которая про­веря­ет под­пись sepOS при стар­те.

Secure Enclave обща­ется с основным про­цес­сором через пре­рыва­ния, но это обще­ние стро­го рег­ламен­тирова­но. Основной CPU может отпра­вить зап­рос в Enclave (нап­ример, «про­верь биомет­рию»), но не может про­читать его память или вме­шать­ся в его работу.

Secure Enclave / StrongBox — «сейф в сейфе»

Да­вай под­робнее раз­берем, что дела­ет Secure Enclave и StrongBox такими защищен­ными.

Уникальный аппаратный идентификатор (UID)

Внут­ри каж­дого Secure Enclave (или StrongBox) есть уни­каль­ный 256-бит­ный ключ, который вши­вает­ся в чип на эта­пе про­изводс­тва. Этот UID (на iOS) или PUID (на Android):

• ге­нери­рует­ся слу­чай­ным обра­зом для каж­дого устрой­ства;
• за­писы­вает­ся в энер­гонеза­виси­мую память чипа один раз и нав­сегда;
• не­извле­каем прог­рам­мны­ми метода­ми. Даже код, работа­ющий внут­ри Secure Enclave, не может про­читать UID целиком, он может толь­ко исполь­зовать его для крип­тогра­фичес­ких опе­раций;
• не­извле­каем аппа­рат­ными метода­ми без раз­рушения чипа.

Я видел иссле­дова­ния, где пытались извлечь UID через декап­суляцию чипа (сня­тие вер­хних сло­ев под мик­роско­пом) и чте­ние содер­жимого памяти с помощью элек­трон­ного мик­роско­па. Тех­ничес­ки это воз­можно, но тре­бует обо­рудо­вания сто­имостью в сот­ни тысяч дол­ларов и месяцы работы, не говоря уже о том, что при­водит к раз­рушению устрой­ства. Для мас­совых атак это нерен­табель­но.

Иерархия ключей

UID никог­да не исполь­зует­ся нап­рямую. Вмес­то это­го он слу­жит кор­нем для дерева про­изводных клю­чей:

Та­кая иерар­хия поз­воля­ет:

• за­щитить дан­ные от копиро­вания на дру­гое устрой­ство (так как UID уни­кален);
• при­вязать рас­шифров­ку дан­ных к зна­нию пас­ско­да;
• быс­тро уда­лить все дан­ные, прос­то сбро­сив Class Keys (не нуж­но переза­писы­вать каж­дый файл).

Физическая изоляция памяти

Па­мять Secure Enclave зашиф­рована встро­енным движ­ком AES, ключ от которо­го хра­нит­ся в энер­гозави­симой SRAM. При отклю­чении питания ключ исче­зает, и вся память ста­новит­ся бес­полез­ным набором бай­тов. Даже если ты смо­жешь выпа­ять чип Secure Enclave, под­клю­чишь его к дру­гому устрой­ству и попыта­ешь­ся про­читать — получишь зашиф­рован­ные дан­ные, ключ от которых уте­рян.

Защита от отладки

Secure Enclave не име­ет отла­доч­ных интерфей­сов. Нет JTAG, нет воз­можнос­ти под­клю­чить отладчик, нет логов, которые мож­но было бы перех­ватить. Это чер­ный ящик, который при­нима­ет зап­росы и воз­вра­щает резуль­таты, но не поз­воля­ет заг­лянуть внутрь.

Закрытые API и биометрические датчики

Почему API биометрии — закрытые?

Пред­ставь, что любое при­ложе­ние мог­ло бы нап­рямую обра­щать­ся к ска­неру отпе­чат­ка или камере Face ID. Что мешало бы вре­донос­ному при­ложе­нию незамет­но снять скан тво­его лица, пока ты игра­ешь в игру? Ничего. И это было бы катас­тро­фой!