Индийский проект 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 номер будет блокирован. Число попыток аутентификации не фиксировано и зависит от целого ряда факторов.
Отдельный 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 скоро начнут присваивать и коровам))
Общее описание
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)
tmin10
10.05.2017 10:09Хм, любопытно. Получается на 1 человека приходится ~500 мегабайт данных. Сигнатуры радужки и отпечатков так много весят?
DrZlodberg
Mimizavr
Enrollment center — внешняя организация, которая работает по лицензии, поэтому все входящие данные проходят проверку.
DrZlodberg
Смущает, что проверяют на вирусы данные, а не код. Зачем им код то передавать?
tmin10
А какие вирусы могут быть в биометрических данных, это же не исполняемый код. Нужно проверять их валидности и отклонять неподходящие. Тоже самое и с фотографией и текстовыми данными.
Mimizavr
Да, тут я некорректно обрезал: после того, как пакеты загружены на сервер UIDAI, они проверяются на дублирование, фальсификацию и вредоносное ПО. Только после этого данные загружаются в систему.
tmin10
Дублирование и фальсификация это понятно, но откуда там вредоносное (да и вообще любое другое) ПО? Это же просто слепок, вроде хэша или чего-то подобного.
Mimizavr
Не совсем. Биометрические шаблоны можно сравнить с хэшем, но сам пакет состоит из: демографических данных (имя, адрес и т.д.), изображений идентификаторов и фото пользователя. А к графическим файлам можно много чего нехорошего присоединить.
Fedcomp
Нельзя. В нормальных сервисах картинку пересоздают.
dmitryus
Ну например в jpeg2k, часто использующемся для хранения фотографий в биометрических документах, есть неоднозначность («ошибка») вызывающая access violation у 99% декодеров этого формата. Так что и в фотографии может быть вирус, особенно если знать софт который используется на стороне декодера :)
QDeathNick
А вдруг у вас сетчатка глаза с SQL инъекцией или отпечатки пальцев совпадают с админскими да ещё с трояном встроенным в мизинец.
mihmig
Ну например Zip-бомба
DrZlodberg
Ну формально это во первых не вирус, а во вторых — случайно её получить (в отличие от вируса) сложно, а за специально будет легко узнать, кого по шапке бить.