Александр Ефремов, Начальник управления развития розничных электронных каналов, Банк Москвы WECON - Мобильные платежи 2016 (3 марта, Москва)

1. Новый подход к аутентификации клиентов для каналов ДБО
- как сделать сервис безопасным и одновременно удобным
для клиентов
Александр Ефремов
Март 2016

2. Приложение «Мобильный банк»
•Динамика оборотов, %
100%
122%
145%
167%
199%
240%
276%
334%
373%
562%
414%
526%
0%
100%
200%
300%
400%
500%
600%
Март
2015
Апрель
2015
Май
2015
Июнь
2015
Июль
2015
Август
2015
Сентябрь
2015
Октябрь
2015
Ноябрь
2015
Декабрь
2015
Январь
2016
Февраль
2016
•Динамика оборотов, %

3. Требования к системе аутентификации
Бизнес-требования Функциональные требования
Удобство : • Отсутствие дополнительных аутентификационных устройств.
• Отсутствие необходимости вводить одноразовые пароли
Массовость.. • Решение должно охватывать массовый сегмент клиентов Банка, работать на всех
типах мобильных устройств
• Удаленная регистрация и персонализация аутентификационного приложения
• Мобильное приложение устанавливается через официальные магазины:
GooglePlay, AppStore, Windows Store.
Стоимость • Возможность использования в качестве аутентификационного сервиса для
единой платформы дистанционного банковского обслуживания
• Независимость от поставщиков аутентификационных решений
• Поддержка средств аутентификации различных вендоров: мобильные устройства,
дисплейные банковские карты, CAP ридеры для банковских карт
Безопасность . • 2-х факторная строгая аутентификация.
• Верификация транзакций пользователем (принцип безотзывности)
• Целостность и конфиденциальность информации
 Замена канала передачи аутентификационных данных по SMS и протокола SSL
 Защита от копирования чувствительных данных

4. Аутентификационный сервер
SDK
MAA
CTGS
Сервис
защищён-
ного
канала SCS
Proxy
Приложение
мобильного
банка
Мобильное устройство
Решение по аутентификации
2-х факторная
аутентификация
Модель аутентификации
с использованием приложения
на банковской карте
Модель аутентификации
с использованием приложения
на мобильном устройстве
Что я имею карте
Что я знаю PIN Passcode
1. EMV приложение банковской карты переносится на мобильное устройство
3. Ключи приложения хранятся в программном криптоконтейнерел.
4. End-to-end шифрование. Между мобильным аутентификационным приложением и системой
аутентификации используется защищенный кана
2. Концепция PLA (PIN less Authentication). Вместо проверки PIN, значения которого хранится на
устройстве или хосте банка, вводится Passcode, значение которого знает только пользователь.
•SSL
•SC

5. Решение по аутентификации
2-х факторная аутентификация
Что я знаю
Мобильное устройство
SDK
CTGS
Приложение
мобильного
банка
Аутентификационный сервер
Proxy
Сервис
защищён-
ного
канала SCS
•SSL
•SC
Модель аутентификации
с использованием приложения
на мобильном устройстве и на карте
Passcode
Что я имею
CAA
•SC

6. Система аутентификации в канале ДБО
Канал коммуникации
приложения
•SSL/TLS
•SSL Pinning
Защищенный канал
коммуникации
системы
аутентификации
•VPN
MAA
ДБО

7. Система аутентификации в мобильном банке
Двухфакторная верификация транзакции в без OTP - SMS
АБС направляет запрос
на верификации
операции
Клиент инициирует
выполнение операции
в приложении
мобильного банка
5
Клиент подтверждает
операцию
Maa формирует CAP
токен
2
1
3
4
Система аутентификации
возвращает результат
верификации операции
6
АБС
выполняет
операцию
7
•Система аутентификации
(SCS) направляет команду
(APDU) на верификацию
транзакции по
защищенному каналу
CTVS проверяет CAP
токен

8. Система аутентификации в канале ДБО
CTVS проверяет CAP токен
АБС направляет запрос на
верификации операции
Клиент инициирует
выполнение операции
5
Клиент подтверждает
операцию
Maa формирует CAP
токен (mode 3 TDS)
2
1
Система аутентификации
(SCS) направляет команду
(APDU) на верификацию
транзакции по
защищенному каналу
3
4
Система аутентификации
возвращает результат
верификации операции6
Двухфакторная верификация транзакции в канале ДБО без OTP - SMS
АБС
выполняет
операцию
7

9. Аутентификация. Как это работает

10. Верификация. Как это работает
БАНК Защищенный канал SС
1. Клиент инициирует операцию в канале ДБО
2. АБС выполняет запрос в систему аутентификации на проведение
верификации операции
3. Система аутентификации направляет зашифрованную команду в
МАА
4. МАА на защищенной экранной форме отображает детали операции
и предлагает подтвердить или отказаться, введя Passcode
5. MAA расшифровывает ключ аутентификационного приложения
6. МАА рассчитывает криптограмму АС
7. MAA (CTGS) формирует CAP токен с использованием криптограммы
АС и TDS, (mode 3 TDS)
8. Приложение на смартфоне отправляет в систему аутентификации
зашифрованное значение CAP токена
9. СА выполняет вычисления п.п.6-7
10. СА сравнивает полученное и рассчитанное значения CAP токена
11. Верификация выполнена
12. После подтверждения операция исполняется банком
Защищенная экранная форма

13. СПАСИБО ЗА ВНИМАНИЕ!
Вопросы?
Александр Ефремов
м.т. 916 674 6291
Март 2016
Новый подход к аутентификации клиентов для каналов ДБО - как
сделать сервис безопасным и одновременно удобным для клиентов

14. Регистрация приложения мобильного банка

15. Аутентификация

16. Верификация

17. Требования к SDK
Функциональные требования Техническое решение
•Защищенный канал •Аутентификационные данные передаются между SDK
и сервером аутентификации по защищенному каналу
•Между приложением мобильного банка и
платформой устанавливается TLS соединение с
использованием SSL pinning
•Защита от реверс-инжиниринга Обфускация исполняемого кода
•Защита чувствительных данных на
мобильном устройстве
•Используется шифрование на значениях Passcode и
Device Fingerprint
•Используется защищенные клавиатура и экранные
формы
•Защита пароля клиента Значение Passcode не хранится на мобильном
устройстве и сервере аутентификации
•Jailbreak и Root Detection Отслеживание джейлбрейка (jailbreak) и Root – прав
перед вводом Passcode и извлечением ключей
мобильного аутентификационного приложения из
защищенного хранилища

18. Защита от атак
Функциональные требования Техническое решение
Brute Force Контроль значений Passcode осуществляется на сервере
аутентификации.
Man-in-the-middle Для установки защищенного соединения между maa
(SDK) и сервером аутентификации сессионные ключи
генерируются параллельно на знании общего секрета
без обмена критической информацией. .
Phising & Pharming
Man-in-the-browser
URL мобильной платформы зашит в исполняемом коде
и все аутентификационные данные генерируются на
уникальном ключе MAA.
Копирование чувствительных данных на
другое устройство
Чувствительные данные хранятся в защищенном
хранилище.