Индийский проект Aadhaar – крупнейшая биометрическая система в мире, в которой уже зарегистрированы более 1,1 миллиарда пользователей. В предыдущей статье я рассказал об этапах развития проекта, теперь перейду к тому, как система устроена.



Общее описание


Aadhaar – это индийский онлайн-сервис аутентификации, предоставляемый государственным агентством UIDAI. Организации (банки, правительственные учреждения и т.д.) передают Aadhaar-номер и считанные биометрические данные пользователя (один или несколько шаблонов отпечатка пальца либо радужки глаза). В ответ сервис выдаёт ответ «да/нет». Дополнительно (сервис Aadhaar e-KYC) с обязательного согласия могут быть проверены личные данные пользователя.

Всего в систему заведено более 1,1 миллиарда пользователей, на каждую учётную запись приходится: 10 биометрических шаблонов отпечатков пальцев, 2 шаблона радужки, фотография и личные данные (адрес, пол, дата рождения). Всего база данных занимает ~25 Пб.

Текущая нагрузка на систему составляет до 20 млн. запросов в день (в среднем 100 запросов в секунду с пиковым значением в 500 запросов — в начале и конце рабочего дня госслужащих), система расчитана на 40 млн. запросов. Планируется модернизировать оборудование с расчётом до 100 млн. запросов в день.

Добавление пользователей




На начальном этапе, когда база данных была «всего» на 84 миллиона человек, UIDAI проанализировало работу системы. Начну с цифр:

Failure to Enroll Rate (FTE) – 0%. Ошибка добавления в систему. Aadhaar получают все.
Biometric Failure to Enroll Rate (B-FTE)- 0.14%. Это количество пользователей, которые не могут быть однозначно идентифицированы с помощью биометрических данных, их надо проверять вручную. По предварительным расчётам система была бы работоспособна при B-FTE<15%.
False Positive Identification Rate (FPIR) — 0.057%. Процент ошибочно найденных дубликатов. Это значит, что при максимальной нагрузке в 1 млн. новых пользователей в день, 570 человек необходимо проверять вручную.
False Negative Identification Rate (FNIR) – 0.0352%. Процент пропущенных дубликатов.
Poor quality fingerprints — 2.9%. Процент пользователей с низким качеством отпечатков. У данных пользователей предпочтительно использовать идентификацию по радужке глаза.
Poor quality fingerprint and poor quality irises: 0.23% — Процент пользователей, которые из-за низкого качества биометрических шаблонов (и отпечатка пальца, и радужки глаза) подвержены ошибкам при аутентификации.

На схеме ниже процесс обработки данных нового пользователя:



Архитектура этой подсистемы

Сбор биометрических и личных данных пользователей осуществляется сертифицированными организациями (Enrollment Center) на рабочих станциях специально надрессированных операторов, где установлено offline приложение. Из полученных от пользователя данных формируется пакет (Enrollment package), который дополняется данными об операторе, времени сбора данных и шифруется. Размер одного пакета составляет до 5 Мб (в основном 2-3), максимальная нагрузка составляла 1 млн. новых пользователей в день.

Все пакеты передаются в CIDR (Central Identities Data Repository). Синхронизация с CIDR должна производиться минимум раз в два дня. Все данные с рабочих станций удаляются после того, как от CIDR получен ответ об успешном создании Aadhaar. По завершению проверки оригинальные изображения отпечатка пальца и радужки сохраняются в CIDR и хранятся отдельно.



Длительность каждого шага


В CIDR сначала осуществляется проверка на дублирование, фальсификацию и вредоносное ПО, затем данные поступают в обработку: проверяются личные, а затем биометрические данные. Для этого используют 3 автоматические биометрические системы (ABIS — Automatic Biometric Identification System) от разных разработчиков, объединённые в одну Multi-ABIS. ABIS работают параллельно, но подозрительные регистрации или данные низкого качества дополнительно пропускаются через все ABIS. Когда находится дубликат, он обрабатывается сначала специальным SDK на предмет ошибки при сканировании, а затем передаётся для ручной проверки. Для 97% пользователей процесс добавления в БД занимает менее 5 минут.

Было выявлено, что 20% правильно определённых дубликатов – результат смешанной идентификации, вызванный ошибками операторов. Ещё 20% от дубликатов пришлось на совпадение шаблонов от разных человек. Чтобы снизить эти показатели UIDAI скорректировало клиентское ПО так, чтобы уменьшить роль операторов.

Процесс аутентификации





Для того, чтобы получить услугу, пользователь вводит свой Aadhaar-номер или локальный идентификатор и идентифицируется на биометрическом терминале. Из полученных данных (биометрический шаблон + номер) формируется XML-запрос, который отправляется на сервер организации, предоставляющей услугу (AUA — Authentication User Agency). На сервере запрос дополняется данными самого AUA и через сервер ASA (Authentication Service Agency) отправляется в CIDR. Здесь происходит верификация биометрических данных (в режиме 1 к 1) и выдается ответ «да/нет», который возвращается на сервер AUA и подтверждает/запрещает услугу. Верификация в 98% случаев занимает менее 1 секунды. При большом количестве ложных операций Aadhaar номер будет блокирован. Число попыток аутентификации не фиксировано и зависит от целого ряда факторов.

Aadhaar e-KYC



Отдельный API описывает работу Aadhaar e-KYC. С его помощью, при успешной аутентификации пользователя можно проверить личные данные, хранящиеся в CIDR – адрес, дату рождения, получить фотографию пользователя и электронную копию письма о выдаче Aadhaar. Таким образом, банк, сотовый оператор и т.д. могут быстро и точно заполнить и проверить данные о клиенте.
К этому сервису доступ ограничен: нужно сначала зарегистрироваться в качестве AUA, осуществить 300 000 транзакций за 3 месяца и получить отдельное разрешение UIDAI. Доступ к CIDR осуществляется через сервера KYC Service Agency (KSA).

Безопасность



Вопрос безопасности – один из самых болезненных при обсуждении подобных проектов. UIDAI за неё критикуют чуть ли не с первого дня. Ниже представлена схема уровней защиты системы:



Безопасность данных до серверов ASA находится в зоне ответственности AUA и описана отдельным документом. Из обязательных пунктов:

— Введённые данные должны быть зашифрованы уже на устройстве и должны хранится только пока совершается транзакция;
— Внутри систем AUA пользователи должны пользоваться локальными идентификаторами (водительское удостоверение, одноразовый пароль, студенческий билет и т.д.), которые и сопоставляется с Aadhaar-номером.
— Если операция осуществляется оператором, он обязательно должен пройти идентификацию, например, с помощью своего Aadhaar-номера;
— Полученные биометрическое данные для аутентификации вообще запрещается хранить где-либо;
— Для связи с ASA должен использоваться выделенный и защищённый канал связи либо SSL.
Непосредственно к CIDR имеют доступ только ASA. Крупные AUA могут себе позволить свои ASA, а вот более мелкие обязаны подключаться через кого-то ещё.

ASA обязаны соответствовать следующим требованиям:

— Подключение к CIDR только через выделенный и защищённый канал,
— Данные о транзакции должна храниться не менее 6 месяцев,
— Идентификаторы пользователей, ключи шифрования, применяемые при аутентификации, вообще запрещается хранить где-либо.

В начале года появились новость, что были заведены уголовные дела против нескольких организаций, допустивших нелегальные аутентификации по сохранённым биометрическим данным. Нарушение было вскрыто, когда выяснилось, что один человек совершил 397 биометрических транзакций в период с 14 июля 2016 года по 19 февраля 2017 года. А в марте UIDAI анонсировало обновление ключей шифрования на всех устройствах к 1 июня.

Человеческий фактор



В самом начале можно было добавляться в систему повторно, или под вымышленным именем. Так свой Aadhaar-номер появился у нескольких индуистских Богов: Брахмы, Ханумана. UIDAI эту лазейку прикрыло и теперь за подобные шутки, как на примере с хозяином собаки, можно пойти под суд. Также уже есть прецеденты, когда в суд отправляли за повторную регистрацию.

Сбор биометрических данных и выдача Aadhaar-номера – процедура бесплатная. Иногда операторы самоотверженно борются с этой несправедливостью, отказываясь работать с пользователями без взятки. Их либо вообще нет на рабочем месте, либо «извините, у нас нет связи с сервером». Остап Бендер был бы доволен.

А вот UIDAI нет. За последние 3 месяца было выявлено, а затем уволено и оштрафовано около 1000 недобросовестных операторов. А один из Aadhaar-центров был заблокирован на 10 лет за то, что оттуда утекли личные данные популярного игрока в крикет.

P.S. На этом пока всё, и небольшой бонус тем, кто дочитал до конца. Немного национального юмора о том, что Aadhaar скоро начнут присваивать и коровам))
Поделиться с друзьями
-->

Комментарии (16)


  1. DrZlodberg
    10.05.2017 09:43
    +1

    В CIDR сначала осуществляется проверка на вирусы,
    Не понял, на какие вирусы проверяют собственный пакет с данными? На имя зарегистрировавшегося 'drop table ...'?


    1. Mimizavr
      10.05.2017 09:52
      +1

      Enrollment center — внешняя организация, которая работает по лицензии, поэтому все входящие данные проходят проверку.


      1. DrZlodberg
        10.05.2017 09:57

        Смущает, что проверяют на вирусы данные, а не код. Зачем им код то передавать?


      1. tmin10
        10.05.2017 10:37

        А какие вирусы могут быть в биометрических данных, это же не исполняемый код. Нужно проверять их валидности и отклонять неподходящие. Тоже самое и с фотографией и текстовыми данными.


        1. Mimizavr
          10.05.2017 11:48
          +2

          Да, тут я некорректно обрезал: после того, как пакеты загружены на сервер UIDAI, они проверяются на дублирование, фальсификацию и вредоносное ПО. Только после этого данные загружаются в систему.


          1. tmin10
            10.05.2017 12:18

            Дублирование и фальсификация это понятно, но откуда там вредоносное (да и вообще любое другое) ПО? Это же просто слепок, вроде хэша или чего-то подобного.


            1. Mimizavr
              10.05.2017 13:18
              +1

              Не совсем. Биометрические шаблоны можно сравнить с хэшем, но сам пакет состоит из: демографических данных (имя, адрес и т.д.), изображений идентификаторов и фото пользователя. А к графическим файлам можно много чего нехорошего присоединить.


              1. Fedcomp
                10.05.2017 22:18
                -1

                Нельзя. В нормальных сервисах картинку пересоздают.


        1. dmitryus
          10.05.2017 21:17
          +1

          Ну например в jpeg2k, часто использующемся для хранения фотографий в биометрических документах, есть неоднозначность («ошибка») вызывающая access violation у 99% декодеров этого формата. Так что и в фотографии может быть вирус, особенно если знать софт который используется на стороне декодера :)


    1. QDeathNick
      10.05.2017 13:09

      А вдруг у вас сетчатка глаза с SQL инъекцией или отпечатки пальцев совпадают с админскими да ещё с трояном встроенным в мизинец.


    1. mihmig
      10.05.2017 14:37
      +2

      Ну например Zip-бомба


      1. DrZlodberg
        10.05.2017 14:53

        Ну формально это во первых не вирус, а во вторых — случайно её получить (в отличие от вируса) сложно, а за специально будет легко узнать, кого по шапке бить.


  1. tmin10
    10.05.2017 10:09

    Хм, любопытно. Получается на 1 человека приходится ~500 мегабайт данных. Сигнатуры радужки и отпечатков так много весят?


    1. Mimizavr
      10.05.2017 10:18
      +4

      Проверьте расчёт ещё раз, получается ~20-30 Мб на человека) Сам пакет с данными (биометрический шаблон, данные о пользователе, изображения отпечатка/радужки) — 5 Мб, больше набегает за счёт резервных копий.


      1. tmin10
        10.05.2017 10:36

        Ваша правда, вероятно запутался с нулями…


  1. mr_grom
    10.05.2017 11:30

    вспомнил фильм «Я начало», где как раз описывалась эта тема в Индии