Проект за мобилна електронна идентификация

Електронната идентификация е ключът към електронното управление. Без нея, използването на електронни услуги е ограничено и трудно. Именно затова, паралелно с устройствената работа (законови изменения и устройствени правилници), в Министерство на електронното управление подготвихме техническа спецификация за мобилна електронна идентификация и я качихме за обществено обсъждане.

Не е практика за технически спецификации да се търси широко обществено обсъждане, но тъй като тази система е много важна, смятам, че е редно да дадем пример за прозрачност от първия ден. Още при номинирането ми за министър на електронното управление дадох това обещание и ще направя каквото е необходимо този екип продължава да дава този пример. Разчитам на професионалистите във всички области да дадат своята експертна и конструктивна обратна връзка и препоръки. Тази прозрачност ще продължи и на етапа на изпълнение (вкл. с изискването за отворен код на разработката).

Резултатът от проекта ще бъде мобилно приложение (за Android и iOS), с което да се идентифицираме за ползването на всички електронни услуги, т.е. държавата да знае кой стои отсреща, когато ползва услугите. До момента това се извършва с електронен подпис, с ПИК, с ПИН и др. Тези средства няма да отпаднат веднага, но малко по малко ще бъдат замествани с електронната идентификация.

След първоначалната регистрация, от гледна точка на потребителя, процесът ще бъде следния:

  1. отваря портал за електронни услуги
  2. избира „вход с eID“ и потвърждава с мобилния си телефон (или друго мобилно устройство)
  3. подава заявления за услуги, които са с предварително попълнени данни (тъй като системата вече знае кой стои отсреща)
  4. подписване на заявлението чрез повторно потвърждение с мобилния телефон

Проектът предвижда първа фаза за проекетиране, тъй като трябва да бъдат взети специфични технологични решения. Например дали потвърждението с телефона да стане с т.нар. push-нотификация или чрез сканиране на QR код от екрана (съответно с deep link, в случай, че потребителят използва мобилния телефон и за заявяване на услугата, вместо компютър). Трябва да бъде избран и методът за подписване, като целта е криптографските ключове да се разделят на няколко части, като една се съхранява в мобилния телефон, а друга – на сървъра (така че да се минимизират рискове от изтичане от едното от двете места).

Първоначалната регистрация е много важна за да може максимален брой хора да използват приложението. Затова предвиждаме първоначална регистрация по следните начини:

  • Квалифициран електронен подпис, в т.ч. облачен КЕП (чрез системата за електронна автентикация)
  • ПИК на НАП (отново през еАвт)
  • ПИК на НОИ (отново през еАвт)
  • международен паспорт, който разполага с чип, благодарение на който може да бъде идентифицирано лицето (чипът може да бъде прочетен с мобилен телефон)
  • снимане на лична карта

Към тези методи могат да бъдат добавени два компонента за повишаване на сигурността:

  • Отговор на въпроси, които държавата има, но не са публично достъпна информация (напр. във връзка с имена на роднини или данни за предходни постоянни адреси)
  • Т.нар. liveness detection, т.е. проверка чрез камерата на телефона дали отсреща действително стои лицето, което твърди, че стои (без да може да се използва негова снимка, за да „излъже“ системата). Това е стандартна практика в много приложения за онлайн идентификация

Всеки един от изброените механизми ще има съответното ниво на осигуреност („средно“ или „високо“), което ще дава достъп до различни услуги. Напр. само със сканирана лична карта (плюс отговори на въпроси/liveness detection), лицата няма да имат достъп до чувствителни данни, като здравното си досие. За да преминат от ниво на осигуреност „средно“ към „високо“ се предвижда опция за еднократно посещение на администрация или пощенски клон. Но дори с ниво „средно“ ще могат да се използват всички масови услуги. В бъдеще, когато чип се появи и в личната карта, той ще може да бъде използван за първоначална регистрация и то с ниво на осигуреност „високо“.

Ако човек няма мобилно устройство, той едва ли би ползвал електронни услуги. Има изключения от това твърдение, но те са твърде малко. В други държави се допуска идентификация с SMS код, но нивото на сигурност при този метод не е задоволително и преценихме, че няма нужда от такъв риск.

Докато се изгражда системата (в следващите няколко месеца), ще подготвим и нормативни изменения, за да може да функционира системата в съответствие със закона.

Освен самото приложение, в рамките на проекта ще бъдат пилотно надградени и системите на НАП, НОИ, МВР, както и портала за електронни услуги на Министерството на електронното управление, така че да има богат избор от услуги, които да бъдат използвани с новото средство за идентификация и подписване (подписването формално ще бъде чрез т.нар. „усъвършенстван електронен подпис“, което е допустимо за заявяване на услуги съгласно действащия Закон за електронното управление).

Смятам, че правилно се фокусирахме върху подготовката на този проект, за да можем да го стартираме в рамките на първите 100 дни от управлението.

24 comments

  1. Двуфакторна индентификация- 2FA , според мен ще е предимство.

  2. Разгледах документа подробно:

    – Първото ми впечатление е че е доста подробен и не съм напълно сигурен дали всички детайли за технологии и изисквания имат приложение тъй като може голяма част от тях да нямат общо с реалното изпълнение а от друга стара следенето за спазването им ще оскъпи нещата сериозно – и трябва да се очаква сериозна цена за вътрешен контрол от самия разработчик по проекта – като минимум моята оценка е за 2-ма постоянно заети които да проверяват всеки детайл дали отговаря на заданието.

    Нещо което липсва:

    – Хората си губят и сменят телефоните – и това се случва на най-неподходящите места – например на почивка в чужбина, командировка и т.н. – и не видях ( може да съм пропуснал) да има изискване за лесно преместване на приложението от един телефон на друг или на нов телефон и оторизирането му за работа на този нов телефон/устройство.

    За технологиите :

    Те са от две части :

    1. Идентификация ( Identity)

    2. Подпис (Sign)

    1. Идентификация

    – Машинно(вътрешно – уникално) ID – има си добре известен сигурен начин и той се нарича UUID ( GUID a windows потребителите) – всякакви други съчинения по темата могат да доведат до неприятни резултати ( например ако се налага издаването му на разпределени места а не от централно – другите технологии имат проблем с това)

    – Човешко ID (Human Readable) – стандартната практика е национален идентификационен номер + фамилия ( в нашия случай ЕГН и Фамилия)

    – Начини за първоначална идентификация : Съвременните са или с SMS/Vibre код или с токен (token/code) който се генерира на мобилно устройство на което се подава ПИН(pass-code) 5 цифри набрани от потребителя и то използвайки този ПИН + времето ( предполага се че мобилното устройство е със синхронизиран таймер) – и резултата обикновено 8 цифри се подава към сървъра като втората част от two-factor идентификация – алгоритъма е добре познат – HMACSHA на RSA като вече патента е паднал и свободен за използване

    2. Подписване

    – Използват се генерално три начина :

    I. chalenge-response подава се код от сървъра ( може да се сканира QR код или просто да се набере в телефона от екрана) + ПИН(pass-code) 5 цифри и използвайки HMACSHA се получава отговор който се навира на страницата и се проверява от сървъра и записва – това е прост ясен и добър начин

    II. SMS/Vibre код който се праща и се записва в страницата – не е много добър вариант но е достатъчно сигурен също

    III. Публичен/Частен ключ ( в момента обикновено се използва Elliptic-curve cryptography) като публичния стой в сървъра а частния в приложението – пак се отключва с ПИН и има проблем с предаването до сървъра тъй като не малък по обем и не може да се напише просто на уеб страницата ( ако услугата се достъпва от компютър а се оторизира от телефон) – има решение с fingerprint на подписа – но накрая пак стигаме до необходимост от Интернет на мобилното устройство в момента на подпис – което е сериозен проблем в много ситуации.

  3. Изключително важна стъпка и дано да стане по-скоро!
    От критична важност ще е да се обмислят вариантите за защита от кражба на идентичност. Телефон се краде лесно и след това могат да се нанесат бързи щети. Трябва да има ясни, лесни и сигурни начини за защита и реакция. Телефонът е техника и не винаги работи, така че трябва да има и алтернативни начини за идентификация.

  4. Докато 2FA има предимство като втори слой на защита, има вече изградени техники за прескачане на тази стъпка, като SIM Swap и чрез phishing. В допълнение, сканирнето на QR код не е перфектна защита защото на пръвпоглед не дава информация дали QR кода е легитимен, или подвеждащ.

    Поради това, според мен решението е в хардуерна защита. Токен който верифицира устройството като доверено пред сървъра с хардуерен токен удостоверяващ това, което в допълнение предпазва от второ устройство да иска достъп до информацията от сървъра. В същоти време, не пречи 2FA или QR код да се интегрира като допълнителна защита.

  5. Здравейте, интересно е как е защитено?

  6. Като допълнително ниво на сигурност може да се добави IP white list с възможност за активиране/деактивиране.

    Съхранение на критичните данни в secure storage предлаган от ос.

    Верификация на всяка заявка с хеш върху (споделена тайна и timestamp), отделно от jwt.

    Заключване на функциите при промяна на настройки за сигурност.

  7. Звучи добре,

    Аз имам няколко въпроса в тази връзка:

    1. Ще поддържа ли huawei у-ва без google services? Ако да, това добра идея ли е? HarmonyOS е open source, но ОС-то, което се слага на у-вата не е. Goolge имат конкретни изисквания към у-вата, които ще изпълняват тяхната ОС. За Huawei май не са известни такива изисквания.
    2. Коя ще е минималната поддържана версия на Android? Колкото по-стара е версията, толкова по-голям е компромисът със защитата.
    3. Не е пряко свързано с темата, но все пак ще попитам: очаква ли се възможност за интеграция с държавата, така че различни продукти да могат по-лесно да правят KYC за клиентите си?
    4. С отворен код ли ще е приложението?
    5. Понеже се спомена liveness detection: готов продукт ли ще се ползва или ще се направи от някого? Ако е готов продукт – кой и кой ще го плаща? Ако някой ще го прави, кой ще го поддържа?
    6. Native технологии ли ще се ползват или cross-platform?

  8. И понеже не мога да редактирам коментар, а не бях видял линка към заданието – сам ще си отговоря:
    1. Ще поддържа ли huawei у-ва без google services? Ако да, това добра идея ли е? HarmonyOS е open source, но ОС-то, което се слага на у-вата не е. Goolge имат конкретни изисквания към у-вата, които ще изпълняват тяхната ОС. За Huawei май не са известни такива изисквания.
    – ?
    2. Коя ще е минималната поддържана версия на Android? Колкото по-стара е версията, толкова по-голям е компромисът със защитата.
    – Android 9
    3. Не е пряко свързано с темата, но все пак ще попитам: очаква ли се възможност за интеграция с държавата, така че различни продукти да могат по-лесно да правят KYC за клиентите си?
    – ?
    4. С отворен код ли ще е приложението?
    – Да
    5. Понеже се спомена liveness detection: готов продукт ли ще се ползва или ще се направи от някого? Ако е готов продукт – кой и кой ще го плаща? Ако някой ще го прави, кой ще го поддържа?
    – ?
    6. Native технологии ли ще се ползват или cross-platform?
    – Native

  9. Без да съм обмислил негативи – идеята на Тома Велев за white list звучи много добре.

    Друго важно нещо, имайки предвид застарялото ни население – много добър UI + видео „уроци“ как се правят прости неща. (User testing с възрастни хора).

    Много за отделен, изцяло web базиран интерфейс, и заради гореспоменатото.

    Ако човек може да си потвърди самоличността пред полицаи с телефона, вместо да си носи лична карта и не му наложат глоба за не носене на такава – това ще е показателно. (Нека патрулиращите носят и камери и намалим КАТ – друга тема)

    Бонус, с изключение на неми хора, несигурен ли е варианта за voice authentication?

  10. Контрол и свободи?

    Със сигурност ще се извършва проследяване и локализиране на населението чрез приложението.

    Върнете си идеята с чипа.
    Поне защитата ще е хардуерна.

  11. Към 7.2.10. Изисквания за киберсигурност, пункт „За защита на уеб сървърите“, да се добавят подпунктове:

    1. Правилно конфигуриран Content Security Policy (CSP) хедър, според организацията на домейните и субдомейните, част от same origin на уеб приложениета, включително и с опция „frame-ancestors“ (забрана за вмъкване на текущата страница с HTML таг „iframe“ и „object“ в други страници с цел превенция на Clickjacking атаки).

    2. Всички „a“ тагове с параметър „target“ задължително да зъдържат и параметър „rel“ със стойност „noopener“ (rel=“noopener“), с цел превенция на Tabnabbing атаки.

    3. Всички автентицирани API заявки не трябва да позволяват HTTP метод TRACE (с цел превенция на опити за bypass на HttpOnly флага на бисквитките).

  12. Предполагам, че данните за идентифиацията, които ще се пазят на телефона ще са многокомпонетни. Добре е при всяка успешна идентификация, един от критичните компненти да се променя.

    Хубаво е също така да се помисли за облачен КЕП с възможност за подписване на документи, които да се удостоверяват и верифицират не само пред държавните институции, но и пред бизнеса.

  13. Според мен трябва да се гледа по-напред във времето. Създаване на държавен блокчейн и в него НФТ идентификация.

  14. Интеграцията на еАвт с ОКЕП доставчиците върши именно работата, на еИД през телефона.
    За банките е достатъчно, защо за егов да не е?!
    Само им уредете на ОКЕП доставчиците плащанията. Единият от тях е Борика – не съвсем частна компания, която доставя опорни услуги в държавата!

    Създаването на собствено приложение ще отнеме 2 години с процедурите, налагането му сред потребителите поне – 2-3, мандатът не стига!
    Уреждането на връзките с ОКЕП – 2 месеца. Има поне 3-400к текущи потребители! Реформата е факт още в първите дни на мандата!

  15. Телефона да може да се регистрира в портала с хардуерен токън. Потребителя трябва да може да изтрива и добавя нови телефони към профила си през портала. Така може да се реагира при загубен телефон и да се гарантира актуалност на push notifications.

  16. Съгласен съм с първите точки на Тома Велев изложени по-горе. Това е минималният стандарт за контрол на промяната на лични данни когато се отнася за допълнителна защита на личните данни.

  17. > Резултатът от проекта ще бъде мобилно приложение (за Android и iOS), с което да се идентифицираме за ползването на всички електронни услуги, т.е. държавата да знае кой стои отсреща, когато ползва услугите.

    Android (рекламната OS на Google) или Android Open Source Project – ако е само първото – жалко.

  18. Как ще могат да се ползват електронни държавни услуги без мобилно устройство, поддържащо мобилни приложения? Например, лаптоп, стационарен компютър …

  19. Ще може ли да се ползва от постоянно живеещи в чужбина (във или извън Европа) българи които нямат постоянен мобилен абонамент/телефонен номер от български оператор разполагащи единствено със закупен временен мобилен интернет достъп?

  20. Моля заложете изискване за съвместимост с Андроид 8. Има много хора с по-стари телефони, нека не ги блокираме.

  21. И като си счупиш телефона, ще се налагат ли глоби? Както при повредена лична карта :).

Вашият коментар

Вашият имейл адрес няма да бъде публикуван.