Уровни доверия аутентификации как составная часть единого пространства доверия Алексей Сабанов,

Уровни доверия аутентификации
как составная часть единого
пространства доверия
Алексей Сабанов,
Заместитель генерального
директора
17 мая 2012г.
w w w. a l a d d i n
n.–r rud. r u
Терминология. Удаленная аутентификация
•
•
•
Идентификатор – уникальная метка, присвоенная
субъекту для того, чтобы отличить его от других.
Процесс идентификации – поиск в базе и сравнение
предъявленного субъектом идентификатора с
эталонным, занесенным в базу при присвоении
уникальной метки данному субъекту
Процесс аутентификации – подтверждение
подлинности субъекта. Производится с помощью
подтверждения владения секретом, изданным и
выданным субъекту в процессе регистрации после
тщательной проверки идентификаторов субъекта
(после полной идентификации).
w w w. a l a d d i n – r d. r u
2
Идентификация и аутентификация
с точки зрения применяемых технологий
$
0,2
w w w. a l a d d i n – r d. r u
10 - 15
25 - 40
50 - 100
3
Актуальность
• Постановлением Правительства РФ от 28 ноября 2011 г.
•
•
N977 предполагается создать федеральную
государственную информационную систему "Единая
система идентификации и аутентификации (ЕСИА) в
инфраструктуре, обеспечивающей информационнотехнологическое взаимодействие информационных
систем, используемых для предоставления
государственных и муниципальных услуг в электронной
форме".
Должна ли быть аутентификация одинаковой для всех
участников электронного взаимодействия?
Как аутентификация связана с электронной подписью?
w w w. a l a d d i n – r d. r u
4
Актуальность. Федеральные проекты
•
•
•
•
электронное правительство;
проект межведомственного электронного
документооборота (МЭДО). Из этого проекта вырастет
система межведомственного документооборота не
только федеральных органов власти, но и региональных;
проект строительства единой системы
межведомственного электронного взаимодействия
(СМЭВ);
проект создания ЕСИА
Везде нужны надежные сервисы безопасности.
Аутентификация является одним из БАЗОВЫХ сервисов
w w w. a l a d d i n – r d. r u
5
Участники электронного взаимодействия
•
•
•
•
•
граждане Российской Федерации;
организации;
федеральные органы государственной власти;
федеральные органы исполнительной власти;
органы государственной власти субъектов
Российской Федерации;
• государственные корпорации;
• иностранные граждане.
w w w. a l a d d i n – r d. r u
6
Идентификация и аутентификация
Участники электронного обмена
Идентификация
Аутентификация
граждане
да
да/нет
представители организаций
да
да
сотрудники ОГВ
да
да
иностранные граждане
да
да/нет
w w w. a l a d d i n – r d. r u
7
Важность аутентификации в мире
• “is a key element for the delivery of any e-services.”
– European Commission COM(2008) 798 final (28 Nov. 2008)
• “is a critical component of . . . national and global
economic, governmental and social activities [which] rely
more and more on the Internet.”
– OECD, The Role of Digital Identity Management in the Internet
Economy, June 2009
• “is a one of the most important security service of ecommerce and e-government”
APEC Guidance for E-commerce (December 2005)
w w w. a l a d d i n – r d. r u
8
Роль аутентификации за рубежом
• Declaration on Authentication for Electronic Commerce 7-9 October 1998
• CWA 14365 Guide of use of Electronic Signature. Jan.2003
• OMB Memorandum M-04-04 E-Authentication Guidance for Federal
•
•
•
•
•
•
Agencies December 16, 2003 & OMB Circular A-130 2003
Homeland Security Presidential Directive 12 (HSPD-12) Policy for a
Common Identification Standard for Federal Employees and Contractors.
August 27, 2004
ISO/IEC 10181-2, ITU-T Rec/x.811 Теоретические основы
аутентификации. 2004
NIST Special Publication 800-63 April 2006 (РД по использованию еаутентификации)
OECD Recommendation on Electronic Authentication/2007
FIPS PUB 201-1 Personal Identity Verification (PIV) of Federal Employees
and Contractors. March 2006, FIPS PUB 201-2. March 2011
ETSI draft SR 000 000 v0.0.2 Rationalised Framework for Electronic
Signature Standardization August 2011 & ETSI TS 1, 103173,…
w w w. a l a d d i n – r d. r u
9
w w w. a l a d d i n – r d. r u
10
Угрозы
• Регистрация
• «маскарад» – имитация конкретного пользователя
• Отрицание регистрации
• Токены (аутентификаторы)
• Программные и физические ключевые носители может быть украдены
или дублированы
• Известное (PIN) может быть раскрыто злоумышленником
• Обладаемое (отпечаток пальца) может быть скопировано
• Протоколы аутентификации
• Подслушивание
• Имитация (заявителя, проверяющей стороны, доверяющей стороны
• Перехват сеанса аутентифицированного пользователя (обращение от
имени пользователя к доверяющей стороне с целью получения
конфиденциальной информации или ввода ложной информации)
• Обращение от имени доверяющей стороны к проверяющей стороне с
целью получения конфиденциальной информации или ввода ложной
информации
w w w. a l a d d i n – r d. r u
11
Прочие угрозы
• Случайные и/или намеренные ошибки при издании Credentials,
•
•
•
•
•
•
связывании, делегировании прав, создании учетных записей
Злонамеренное ПО, направленное на компрометацию токенов
(аутентификаторов)
Вторжение в системы пользователей, CSP или проверяющих
сторон с целью получения цифровых удостоверений или
токенов
Угрозы компрометации токенов со стороны инсайдеров
Социальный инжиниринг с целью раскрытия пользователем
PINа, подглядывание
Атаки, при которых обманутый заявитель использует
небезопасный протокол, думая, что использует безопасный,
либо сам преодолевает средства защиты (например, принимая
сертификаты серверов, не прошедших проверку)
Явный отказ пользователей, сознательно
скомпрометировавших свои токены
w w w. a l a d d i n – r d. r u
12
Уровни доверия аутентификации
Административно-бюджетное управление для
федеральных ведомств и NIST разработали уровни
минимальных технических требований к:
• токенам (аутентификаторам);
• Процессам подтверждения подлинности, регистрации,
изданию и передаче цифровых удостоверений,
связыванию
• Механизмам удаленной аутентификации (комбинация
из цифровых удостоверений, токенов и протоколов
аутентификации)
• Механизмам подтверждения, используемой для
передачи результатов удаленной аутентификации
другим сторонам)
w w w. a l a d d i n – r d. r u
13
Пример Credentials из FIPS PUB 201-1
• Ключевая пара (открытый и закрытый ключи) и цифровой
•
•
•
•
сертификат аутентификации
Ключевая пара (открытый и закрытый ключи) и цифр.
сертификат электронной подписи. Подпись возможна
только с использованием ПИН-кода (волеизъявление)
Ключевая пара (открытый и закрытый ключи) и цифровой
сертификат для управления ключами
Ключи для системы управления жизненным циклом
смарт-карт с использованием контактного чипа
Возможность импортирования на чип смарт-карты
сертификатов X.509 для PKI - валидации
w w w. a l a d d i n – r d. r u
14
Схема организации PIV федер. служб США
w w w. a l a d d i n – r d. r u
15
FIPS PUB 201-1: стандарт смарт-карты
w w w. a l a d d i n – r d. r u
16
Несколько разных ЭП...
Принцип Кирхгофа
Простая ЭП + квалифицированная ЭП
=
простая ЭП
w w w. a l a d d i n – r d. r u
17
Три ключевые “Роли”
• Субъект
– Личность, подлинность которой устанавливается
– использует эл. удостоверение для организации online
транзакций
• Центр Доверия
– Отвечает за проверку субъекта и издание эл. удостоверений
– Отвечает за проверку эл. удостоверений для доверяющей
стороны
• Доверяющая сторона
– Использует эл. удостоверение для проверки подлинности
субъекта
– Полагается на подтвержденную идентификацию для
предоставлению авторизованного доступа/подтверждению
транзакций/ принятию подписи и т.д.
w w w. a l a d d i n – r d. r u
18
№63-ФЗ. Виды электронных подписей
квалифицированная
усиленная
неквалифицированная
простая
w w w. a l a d d i n – r d. r u
19
Федеральный закон №149-ФЗ
Государство
Граждане
простая
квалифицированная
Бизнес
Усиленная неквалифицированная.
Статья 6, п.3.: «Обладатель информации вправе разрешать или
ограничивать доступ к информации, определять порядок и
условия такого доступа»
w w w. a l a d d i n – r d. r u
20
Федеральный закон № 210-ФЗ
Федеральный закон
Российской Федерации
от 27 июля 2010 г. №
210-ФЗ "Об
организации
предоставления
государственных и
муниципальных
услуг"
w w w. a l a d d i n – r d. r u
21
Уровни последствий ошибок ААА
Применение средств ААА должно быть приведено в
соответствие с потребностями и уровнем риска
• Физические лица – как минимум, пара «логин/пароль»
• Организации (бизнес) - OTP + Защищенные ключевые
носители
• Государственные органы – строгая аутентификация,
секрет должны генерировать устройства класса SSCD
высокий
средний
низкий
w w w. a l a d d i n – r d. r u
22
Наши предложения
• Ввести 3 уровня доверия к аутентификации
• Связать их с требованиям к использованию трех видов
•
•
•
•
электронной подписи
Исследовать вопросы надежности процессов
автоматической идентификации и аутентификации
Обратить внимание на противодействие угрозам при
выполнении всех основных процессов (регистрация,
автоматическая идентификация, выпуск и передача
цифровых удостоверений, связывание, управление)
Привлекать к разработке требований к уровням
аутентификации и архитектуре Единой системы
аутентификации специализированные ассоциации (АЗИ) и
специалистов
Необходимо создать нормативной базу и инфраструктуру
w w w. a l a d d i n – r d. r u
23
Три уровня строгости аутентификации. Уровень 1.
В качестве токена рекомендуется применение
многоразового пароля или более строгой аутентификации.
Аутентификация признается успешной при доказательстве
владения токеном по одному из безопасных протоколов
аутентификации. Желательно соблюдать требования по
длине пароля (не менее 6 символов). Разрешается
использовать простую электронную подпись. Нет
требований по надежности ИА. Основными обладателями
информационных ресурсов на этом уровне являются
граждане, которые определяют риски проникновения на их
ресурсы мошенников самостоятельно. Также на их
ответственности лежит возможное производство
электронных удостоверений (ЭУ) и передача прав
доверительным сторонам.
w w w. a l a d d i n – r d. r u
24
Три уровня строгости аутентификации. Уровень 2.
Рекомендуется применение технологии ОТР или передачи
аутентификатора с использованием двух каналов. Издание
ЭУ разрешено не только аккредитованным УЦ. Передача
прав доверия третьим сторонам производится на основе
двухсторонних соглашений (договоров) или на основе кросссертификации. Приветствуется использование технологий
уровня 3. Основными обладателями информационных
ресурсов являются организации с развитой PKI. Для
аутентификации, предназначенной для внутренних нужд и
согласованного электронного взаимодействия с
контрагентами, разрешается использование RSA. Для
взаимодействия с государственными органами обязательно
применение аутентификации уровня 3 и криптоалгоритмов
ГОСТ 34.10-2001 и ГОСТ 34.11-2001.
w w w. a l a d d i n – r d. r u
25
Три уровня строгости аутентификации. Уровень 3.
Рекомендуется использование только строгой, как минимум,
двухфакторной взаимной (информационный ресурс претендент) аутентификации с применением токенов класса
SSCD (Secure Signature Creation Device). Особое внимание
следует уделять строгости процесса регистрации
заявителей, изданию ЭУ и передаче прав доверительным
сторонам. Рекомендуется использование только российских
криптографических алгоритмов при издании ЭУ для
электронной подписи и шифрования. При этом УЦ,
издающий ЭУ, должен быть аккредитован в Минкомсвязи
РФ.
w w w. a l a d d i n – r d. r u
26
Участники процесса аутентификации
• субъект доступа (апликант, претендент, заявитель)
• центр регистрации (ЦР) – его основной задачей является
установление и фиксация (закрепление) связи субъекта и его
уникального секретного признака – аутентификатора. В качестве
такого центра может выступать, например, удаленный центр
регистрации удостоверяющего центра (УЦ), связанный
доверительными отношениями с УЦ
• доверяющая сторона – владелец того ресурса, к которому претендует
получить доступ субъект доступа. Он проверяет по протоколу
аутентификации факт владения субъектом доступа соответствующим
аутентификатором – секретом, который выдан субъекту ЦР-ом
• проверяющая сторона (центр валидации, ЦВ), входит в состав ИОК, выполняет проверку наличия фиксированной ЦРом связи «субъект
доступа – аутентификатор. Например, проверяет, является ли ЭУ
действительным (валидным) на момент проверки.
w w w. a l a d d i n – r d. r u
27
Три основные процесса аутентификации
•
•
•
Регистрация
Криптографические протоколы аутентификации
Валидация
w w w. a l a d d i n – r d. r u
28
Процессы аутентификации. Регистрация
Регистрация – установление (идентификация) личности и
регистрация аутентификатора (секрета), а также издание
связанного с ним электронного удостоверения (ЭУ) аналог выдачи паспорта. Также обязательной процедурой
является привязка зарегистрированного и изданного для
данного субъекта ЭУ к его личности. По большому счету,
главная цель ЭУ - связать секрет (аутентификатор) с
личностью и ее предъявленными и проверенными
идентификаторами или с новыми идентификаторами,
которые выдает ЦР. Данная процедура подразделяется на
несколько связанных между собой последовательных
процессов, осуществляется в ЦР. Процедура может
производиться с личным присутствием субъекта или
удаленно, допускать анонимность или нет. Процедура
может проводиться по заданному Регламенту или нет.
w w w. a l a d d i n – r d. r u
29
Основные процессы аутентификации - 2.
•
•
Протокол аутентификации – процедура проверки факта
владения претендентом секретом (аутентификатором). Данная
процедура является аналогом предъявления паспорта и
сличения фотографии для идентификации личности. Эта
процедура осуществляется доверяющей стороной, может быть
с разделяемым секретом или нет. Может быть устойчивой к
атакам по каналу связи или нет. Наиболее сложным вариантом
является тот, когда аутентификатор состоит из нескольких
компонентов (факторов), и каждый компонент проверяется по
своему протоколу. Это - так называемая многофакторная
аутентификация.
Валидация (проверка действенности) – процедура проверки
подлинности и периода действия ЭУ (аналог проверки
действительности паспорта). Осуществляется в центре
валидации (ЦВ), может проводиться по заданному Регламенту
или нет.
w w w. a l a d d i n – r d. r u
30
Регистрация подробно. Процедуры 1- 3.
1.
2.
3.
Субъект (апликант) предъявляет в ЦР свои Credentials (ЭУ или
бумажные действующие удостоверения личности, содержащие
присвоенные ему идентификаторы. Примером идентификатора может
быть номер паспорта, номер удостоверения, СНИЛС, ИНН,…).
ЦР проверяет предъявленные бумажные или ЭУ на предмет
совпадения принадлежности предъявленных документов данному
субъекту. Например, паспорт на имя Иванова И.И. действительно
существует и не зарегистрирован в качестве потерянного, указанный
СНИЛС на имя Иванова И.И. зарегистрирован в реестре ПФР.
Фотография похожа на предъявителя. Заметим, что в отличие от США
[6] в настоящее время в РФ нет утвержденных и действующих
регламентов на проведение процедуры проверки наличия
регистрации и действительности на определенный момент даже
паспорта, не говоря о других идентификаторах…
На основании выполненной проверки ЦР создает учетную запись для
данного субъекта в базе данных ЦР для доступа к информационным
ресурсам (ресурсу).
w w w. a l a d d i n – r d. r u
31
Регистрация подробно. Процедура 4.
На основе записи для субъекта ЦР издает секрет (аутентификатор),
ассоциированный с конкретным субъектом. Простейшим секретом
может быть сформированный по тому или иному установленному
алгоритму пароль. Более строгим секретом может явиться одноразовый
пароль. Самым строгим секретом является секретный ключ. Далее для
данного секретного ключа на основе соответствующего открытого ключа
формируется сертификат ключа подписи (ЭУ, называемое Credentials),
связывающий секретный ключ (аутентификатор) с его владельцем. В
простейшем случае процесс издания Credentials сводится к регистрации
пары логин-пароль. В самых сложных случаях для одного субъекта
может быть издано несколько ЭУ (например, сертификаты ключа
подписи, ключа шифрования, ключа логического доступа, сертификат
ключа физического доступа и т.д.).Фактически ЭУ является своего рода
«электронным паспортом», имеющим реквизиты издателя, время, место
издания, срок действия, алгоритм формирования (издания), процедуру
проверки (цепочку доверия) и т.д.
w w w. a l a d d i n – r d. r u
32
Регистрация подробно. Процедуры 5 и 6.
5. Далее следует необязательная (иногда ее не требуется
создавать) процедура делегирования прав доступа
(фактически делегирование доверия к изданным
аутентификатору и ЭУ) другой (другим) информационной
системе (ИС) на основе доверительных отношений между
издающим УЦ (или представляющего данный УЦ
конкретного ЦР) к УЦ конкретной ИС, в которой данный
субъект по полученным аутентификатору и ЭУ имеет право
обращаться.
6. Последним процессом регистрации является выдача
изданных ЦР-ом аутентификатора и ЭУ на руки субъекту.
w w w. a l a d d i n – r d. r u
33
О способах хранения секрета
•
•
изданный ЦР на этапе 4 секрет субъект может хранить поразному. Ст.10 Федерального закона 63-ФЗ: «ответственность
за хранение ключа подписи лежит на его владельце». При
массовом использовании ЭП к описанным процедурам будут
привлечены разные слои населения, в т.ч., далекие от ИТ и ИБ.
С другой стороны, действительно важные ресурсы и самый
серьезный подход к изданию ключей подписи. В стандарте
FIPS, а также стандартах и рекомендациях ЕС существует
требование использования для формирования ключевой пары
квалифицированной подписи только SSCD-устройств.
В действующих на сегодня практике в регламентах УЦ
зачастую отсутствует элементарное требование активации
флага «неизвлекаемость закрытого ключа».
w w w. a l a d d i n – r d. r u
34
Способы хранения секрета, уровни 1-2
Пароль можно:
• Запомнить
• Записать на бумагу
• Записать на электронный носитель
ОТР можно:
• Хранить в бумажном блокноте (как это делал
Штирлиц в 17-ти мгновениях весны)
• Записать на скретч-карту (как это делают до сих пор
многие банки
• Сгенерировать по согласованному с сервером
алгоритму с последующей процедурой
синхронизации (пример – ОТР-токен Аладдина,
Васко…)
w w w. a l a d d i n – r d. r u
35
Способы хранения закрытого ключа
•
•
•
Запись и последующее хранение в реестре
компьютера
запись на электронный носитель (USB-ключ, смарткарту), например, в ЕЕРROM, в лучшем случае – с
взведенным флагом «Неизвлекаемость контейнера из
носителя» при любых манипуляциях (введение PINкода юзера, PIN-кода администратора,….)
генерация и гарантируемая неизвлекаемость в SSCDустройстве.
w w w. a l a d d i n – r d. r u
36
Аутентификация в «облаках»
•
•
•
•
•
Для удобства пользователей должны использоваться
механизмы однократной аутентификации при доступе к
различным облачным сервисам;
Для обеспечения взаимодействия облачных сервисов с
сервисом аутентификации должны использоваться
широко распространенные протоколы, стандарты и
модели контроля доступа;
Необходимо использовать мировой опыт и лучшие
практики;
Должна обеспечиваться информационная безопасность
сервисов ААА;
Сервисы аутентификации в облаках должны
пользоваться доверием пользователей и быть узнаваемы
w w w. a l a d d i n – r d. r u
37
Задачи аутентификации для «облаков»
• Обеспечение удаленной регистрации;
• Безопасное ведение учетных записей пользователей;
• Обеспечение безопасного делегирования полномочий и
•
•
доверия в облачные сервисы;
Управление доверием при взаимодействии облачных
сервисов;
Контроль доступа в привязке к методу аутентификации
пользователя, его роли и требований к уровню доверия в
облаке;
w w w. a l a d d i n – r d. r u
38
Регистрация к корпоративным облачным сервисам
w w w. a l a d d i n – r d. r u
39
Регистрация к облачным сервисам
w w w. a l a d d i n – r d. r u
40
Доступ к облачным сервисам
w w w. a l a d d i n – r d. r u
41
Выводы к разделу Аутентификация в облаках
•
•
•
Для задачи «делегирование полномочий» нельзя
использовать пароль (нельзя ограничить по времени) и
технологию ОТР (одноразовый пароль становится
многоразовым, или получим «отказ в обслуживании» изза невозможности сгенерировать следующий ОТР. При
использовании механизма ЭП делегирование успешно;
Для вычислений в облаках, требующих разделения
доступа, пароль и ОТР неприемлемы.
Для обеспечения аутентификации в «облаках»
необходимо применять только строгую двухстороннюю
аутентификацию на основе электронной подписи.
w w w. a l a d d i n – r d. r u
42
Спасибо за внимание!
a.sabanov@aladdin-rd.ru
w w w. a l a d d i n
n.–r rud. r u
43