EA012094B1

EA012094B1 - Средство защиты и способ аутентификации пользователя с помощью этого средства

Info

Publication number: EA012094B1
Application number: EA200870122A
Authority: EA
Inventors: Алайн Роллир; Лоренц Мюллер; Марсель Якомет; Роджер Каттин-Либл
Original assignee: Акссионикс Аг
Priority date: 2005-12-29
Filing date: 2006-12-20
Publication date: 2009-08-28
Also published as: CN101336436A; CA2650063A1; AU2006331310A1; US8341714B2; EP1811421A1; BRPI0621168A2; EP1966737A1; CN101336436B; KR20080087021A; BRPI0621168A8; CA2650063C; WO2007073609A1; EA200870122A1; US20090320118A1; AU2006331310B2

Abstract

Токен безопасности содержит память для персональных данных, предназначенную для хранения персонализированных данных пользователя в качестве цифровых мандатов (33, 34) идентификации. Для осуществления проверки указанных персональных данных предпочтительно для верифицирования идентификации с использованием двух или трех факторов аутентификации, используется входное устройство. Токен содержит также память (71, 75) для хранения записей ключей, в которой записаны мандаты идентификации, инициализированные органом сертификации и, возможно, присвоенные сервис-провайдерам. Токен, кроме того, содержит приемопередатчик для формирования защищенного канала прямой или непрямой связи с сервером аутентификации, оператором приложений или органом сертификации для взаимодействия с указанными записями (71, 75) ключей, соотнесенными с сервером аутентификации. Имеется блок управления для управления приемопередатчиком и памятью (71, 75) для хранения записей ключей в связи с указанным взаимодействием, предусматривающим действия, выбранные из группы, включающей, помимо других воздействий на записи ключей, интерпретацию, дешифрование, создание, проверку, возобновление и удаление. Это позволяет пользователю использовать федеративное управление идентификацией в надежно защищенной среде, используя биометрические данные, чтобы аутентифицировать себя перед токеном, не передавая эти биометрические данные третьим лицам.

Description

Изобретение относится к способу и устройству для аутентификации пользователя, для предоставления доступа к защищенной системе и для упрощения управления персональными цифровыми идентификаторами.

Предшествующий уровень техники

Существуют различные устройства и методы, позволяющие аутентифицировать пользователя в системе (которая может представлять собой строительную систему) или в компьютерной сети, или в удаленной информационной системе. Цель аутентификации может состоять в получении физического доступа в здание, например к открытой в нем двери, или логического доступа к сетевому сервису, например к вебстранице, или к извлечению информации, например, из удаленной компьютерной системы.

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

Типичный пользователь компьютерными системами и Интернет-сервисами должен запомнить и пользоваться более чем 50 ИД, паролями и ПИН-кодами, причем вся эта информация должна рассматриваться как реальные секреты, поскольку именно так она воспринимается современными системами аутентификации. Однако хорошо известно, что пользователи не обращаются с подобными идентификационными данными, как с ценными секретами. Пользователи выбирают либо простые пароли, либо простые правила их запоминания. Словарные атаки (атаки перебором по словарю) способны взломать предположительно секретные пароли в течение секунд. Чтобы усложнить аутентификацию, операторы, обеспечивающие защиту, выдают пассивные или активные аппаратные средства-токены (карты, списки одноразовых паролей, генераторы кодов, зависящих от времени, цифровых сертификатов и т.д.). Использование всех этих физических и виртуальных средств идентификации не облегчает жизнь их владельцам. Пользование многими Интернет-сервисами прекращается просто потому, что пользователи забывают порядок доступа к соответствующему сайту. Пользователи ограничивают свои бизнес-контакты небольшим количеством операторов, что, естественно, сужает возможности электронной коммерции. В то время как многие системы предлагают функции управления идентификацией для операторов, проблема управления идентификацией со стороны пользователей остается нерешенной.

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

В течение многих лет для уменьшения трудностей, связанных с необходимостью многократной аутентификации, предлагаются системы федеративного управления идентификацией (Ребега1еб ίάοηΐίΐν тападетепк ΡΙΜ) и системы единой регистрации (8тд1е-Цдп-оп, 880), а также системы с облегченным процессом регистрации. Однако у ΡΙΜ-систем имеется серьезная проблема, состоящая в необходимости координирования работы различных фирм или сервис-провайдеров, которые при этом должны принимать пользователей друг у друга. Такой подход представляется неработоспособным, а предпринимаемые в этом направлении попытки - неэффективными в плане решения указанной проблемы.

В международной заявке \¥0 02/15626 описано применение мобильного телефона в качестве аутентификационного устройства. Пользователь аутентифицируется перед мобильным телефоном одним или более способами, в том числе с применением биометрических характеристик, после чего мобильный телефон аутентифицируется перед соответствующим сервером. Данное решение стремится избежать передачи токена от пользователя к устройству. При этом единственная аутентификация может использоваться при условии, что все применяющие аутентификацию сервис-провайдеры используют одни и те же протоколы.

Сущность изобретения

Задача, на решение которой направлено изобретение, заключается в создании способа и устройства, обеспечивающих более безопасную аутентификацию пользователя, чем методы, известные из уровня техники.

Другая задача состоит в оптимизации взаимодействия пользователь-провайдер в терминах эффективности и безопасности.

- 1 012094

Следующей задачей является разработка более простых и эргономичных способа и устройства обеспечения доступа к защищенной системе.

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

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

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

Токен может быть дополнительно снабжен средством фиксации, позволяющим присоединять к нему дополнительный токен с настраиваемой информацией (как это будет описано далее), а также с источником питания и защищенным каналом для обновления специального программного обеспечения.

Токен безопасности может иметь форму смарт-карты, но может представлять собой и сотовый телефон или карманный компьютер. Его важным свойством является способность принимать и хранить персональные данные. Такими данными могут быть секрет или биометрические данные. Для обеспечения аутентификации память для хранения записей ключей используется для хранения мандатов идентификации одного или более серверов провайдеров аутентификации (далее именуемых также серверами аутентификации). После создания защищенного канала прямой или непрямой связи с сервером аутентификации осуществляется взаимодействие с этими записями ключей, включающее выполнение различных операций.

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

В предпочтительном варианте имеется множество записей ключей, причем каждая запись соотнесена с одним органом сертификации или провайдером аутентификации, или оператором. При этом с одним органом сертификации может быть соотнесено несколько таких записей, которые затем активируются различными провайдерами аутентификации. Это позволяет каждому органу сертификации независимо проводить аутентификацию идентичности пользователя внутри токена, тогда как пользователю достаточно иметь только этот токен. Кроме того, пользователь полностью контролирует свои персональные данные (его биометрические данные хранятся только в токене). При этом различные организации могут самостоятельно решать, как им обращаться с различными записями ключей, сделанными различными серверами аутентификации или операторами приложений. Пользователь может удобно для него аутентифицировать себя только перед единственным токеном безопасности и сертификатами различных провайдеров, безопасно записанными в данном токене. Если один из серверов аутентификации или операторов приложений решает обновить и изменить авторизацию, это можно сделать полностью независимо от записей ключей, сделанных другими организациями.

Предпочтительный вариант изобретения соответствует защищенному И8В-устройству, особенно мини-И8В устройству или другому физическому соединителю, который может быть использован для повторной зарядки внутреннего источника питания и для быстрой записи или обновления специального программного обеспечения. Такое устройство может быть также использовано для доставки сертифицированной информации (например, сертификата Х509), которая не может быть доставлена по другим дос

- 2 012094 тупным каналам.

Если лидирующие положения на рынке занимают несколько органов сертификации (ОС), имеется возможность создать два или более сегментов для хранения записей ключей, содержащих различные записи, которые могут активироваться и рассылаться различными органами сертификации различным серверам аутентификации или операторам приложений. При этом ОС или провайдер аутентификации, авторизованный ОС, может располагать порталом, дающим доступ к множеству сайтов и сервисов, требующих аутентификации своих пользователей, но не желающих использовать собственную систему аутентификации.

Токен и способ по изобретению, разумеется, предусматривают также позитивную аутентификацию токена безопасности, позволяющую пользователю производить различные действия, например получать доступ к прикладным программам, производить платеж, формировать билет или получать физический доступ, в частности, к открытой двери. Подобная персональная система управления идентификацией со стороны пользователя должна всегда находиться под контролем пользователя и должна быть защищена от любого злонамеренного манипулирования. Как следствие, персональная система управления идентификацией не должна быть реализована на терминальном оборудовании (типа персонального компьютера, мобильного телефона и т.д.), которое может подвергнуться атаке.

Изобретение основано на обнаружении его авторами того обстоятельства, что известные решения концентрировались не на оптимальной стороне взаимодействия пользователь-оператор. Только управление идентификацией со стороны пользователя способно обеспечить работу с множеством мандатов идентификации пользователя.

Изобретение позволяет пользователю реализовать федеральное управление идентификацией в хорошо защищенной среде, используя биометрические данные, чтобы аутентифицировать себя перед устройством в рамках используемого способа, но не предоставлять эти биометрические данные третьим лицам.

Перечень фигур чертежей

Далее изобретение будет подробно описано на примере вариантов его осуществления, рассматриваемых со ссылками на чертежи.

На фиг. 1 иллюстрируются способ и устройство по изобретению, реализованные в защищенной среде;

на фиг. 2 представлены релевантные компоненты и каналы связи для устройства по фиг. 1 в случае осуществления способа по изобретению;

на фиг. 3 схематично изображена карта для использования со способом и устройством по фиг. 1;

на фиг. 4 иллюстрируется архитектура управления сертификатами в рамках карты согласно изобретению;

на фиг. 5 - способ использования карты согласно изобретению;

на фиг. 6 - использование способа и устройства по изобретению пользователем;

на фиг. 7 - совместное использование карты-токена и смарт-карты в соответствии с изобретением;

на фиг. 8 - карта согласно изобретению;

на фиг. 9 - терминал-считыватель согласно изобретению;

на фиг. 10 - автономный режим работы;

на фиг. 11 - функционирование сервиса аутентификации;

на фиг. 12 - функционирование органа сертификации;

на фиг. 13 - федеративный режим функционирования.

Сведения, подтверждающие возможность осуществления изобретения

На фиг. 1 и 2 схематично иллюстрируется возможная реализация способа согласно одному из вариантов изобретения.

На фиг. 1 представлены три образующие систему 7 аутентификации функциональные подсистемы, которыми являются токен 8, 9, платформа 6 аутентификации и аутентификационные модули 12. Токен 8, 9 является токеном безопасности, который применяется в контексте многофакторной аутентификации в качестве того, что есть у пользователя. Токен 8, 9 может представлять собой смарт-карту (СМК) или сим-карту или содержать терминал-считыватель для такой карты (далее терминал). В последнем случае токен 8, 9 безопасности представляет собой комбинацию смарт-карты и терминала-считывателя. Следовательно, карманный компьютер или мобильный телефон могут рассматриваться в качестве такого токена 8, 9. В дальнейшем описании принимается, что основной вариант токена безопасности 8, 9 представляет собой карту.

Три функциональные подсистемы обеспечивают управление, ограничение и аутентификацию доступа к соответствующим защищенным приложениям 13. Специалистам в данной области будет понятно, что приложения 13 не ограничиваются представленными на фиг. 1. Следует также отметить, что сертификаты, представляемые организациями, реализующими приложения 13, могут представлять собой отдельные компоненты (которые соответственно должны загружаться в систему 7). Альтернативно, они могут вводиться в аутентификационные модули 12 посредством программного переноса в защищенную память, как это будет описано далее.

- 3 012094

Используемые далее в описании сокращения поясняются в списке обозначений, приведенном в конце описания.

Пример платформы 6 аутентификации иллюстрируется фиг. 2. Платформа 6 аутентификации содержит сервер 65 лицензий, сервер органа 64 сертификации (ОС), сервер провайдера 63 сервиса аутентификации (ПрСА), оптические компоненты 61 и/или средство передачи информации, например средство радиочастотной идентификации (табю Гтециеису Иеиййсайои, ΚΡΙΌ) с ΚΡΊΌ-считывателем 62 у клиента. Платформа 6 аутентификации может быть построена как цифровой портал, позволяющий провайдеру сервиса аутентификации (провайдеру аутентификации) открывать доступ к компьютерной системе, или как физический портал, контролирующий, например, доступ к зданию.

Компонент 61 может представлять собой подключаемую микропрограмму или клиентский браузер, или любую другую программу генерирования графики, которая генерирует мерцающий код, отображаемый на экране компьютера пользователя, например в окне браузера (в частности, как это описано в ЕР 1255178), и подлежащий считыванию оптическим каналом карты 8, 9. В качестве входной информации микропрограмма или программа получает сообщение от сервера аутентификации с адресом записи карты, сегмента и ключа и с зашифрованным сообщением (данное сообщение передается от сервера аутентификации на локальное терминальное оборудование по 1Шр- или Шрк-каналу или по другому безопасному каналу, защищенному соответствующим протоколом двухточечной связи, например 88Ьпротоколом). Во время сессии оператор может один или более раз аутентифицировать или верифицировать присутствие авторизованного пользователя, связывая такую аутентификацию с предоставлением определенной информации, которая доступна только через токен 8, 9. Канал от сервера к локальному терминалу обработки данных дополнительно защищен обычными защитными механизмами: νΡΝ (У1Г1иа1 Рйуа1е №1теогк, виртуальная частная сеть), кЦрк или другими протоколами, защищенными 88Ьпротоколом.

Средство ΚΡΙΌ 62 может представлять собой прикладную программу для ΚΡΙΌ-сервера, которая преобразует сообщение от сервера аутентификации в коммуникационный ΚΡΙΌ-диалог для считывающего терминала или карты 8, 9. Данное сообщение будет передаваться с использованием вышеупомянутых протоколов.

Кроме двух названных каналов связи, информация может передаваться акустическим путем или простым оптическим методом (по инфракрасному каналу) с присущими этим более медленным методам недостатками.

Сервер ПрСА 63 реализует базовый протокол аутентификации и генерирует по требованию сервера оператора 66 (т.е. пользователя сервисом аутентификации, ПСАу) соответствующее сообщение вызовответ, шифрует, подписывает и преобразует его в δΘΑΡ-сообщение (сообщение по протоколу 8ΘΑΡ). В случае необходимости (при первой или возобновляющей регистрации или постановке на учет в онлайновом режиме) он осуществляет связь с сервером ОС 64, чтобы получить необходимые ключи и коды активации и возобновления.

Сервер ОС 64 обеспечивает ОС возможность инициализировать карты 8, 9 посредством их секретных (закрытых) ключей, а также осуществить процесс постановки на учет.

Сервер 65 лицензий - это система управления картами, которая осуществляет администрирование всех используемых карт 8, 9, выдает коды доступа (КАС - код 53 активации сегмента, КАК - код 54 активации ключа) для сервера ОС 64 и информацию о возобновлении лицензии (КВЗ - код возобновления ключа и новую дату истечения срока действия (ДИСД) ключа). Коды управления лицензиями позволяют реализовать новые, гибкие и модульные, модели бизнеса с оплатой одного или нескольких актов аутентификации или рассчитанных на ограниченный или неограниченный период (с лицензиями за продажу токена 8, 9).

Базовая реализация способа согласно изобретению применима для приложений, предлагаемых через Интернет. При этом полная реализация способа аутентификации может использоваться для аутентификации в рамках операционных систем (\νίηάο\ν5. 8о1аг15. Ьших и т. д.) или в приложениях (8АР, 8есиге АбоЬе, СΚΜ, С8М и т.д.), которые требуют аутентификации пользователя. Если способ согласно изобретению используется применительно к операционным системам или приложениям, стандартный пароль и модуль аутентификации пользователя указанными приложениями должны быть заменены соответствующим аутентификационным модулем согласно изобретению.

Устройство согласно настоящему изобретению будет описано далее со ссылками на фиг. 3, 4, 8 и 9.

Физическое лицо (пользователь) 1 устанавливает связь с картой 8, 9 способом, который будет описан далее. Карта 8, 9 содержит персональные (биометрические) данные 31 (в многофакторной аутентификации это сертификат того, кто является пользователем), индивидуальные (персонализированные) цифровые данные (секретные ключи) 33 (записанные посредством операции 32) и сертифицированные мандаты 34, 34' идентификации для идентификации пользователей перед определенным провайдером аутентификации. Карта устанавливает постоянную, сильную и подтверждаемую связь 35, 35' с серверами 2, 2' в составе ПрСА. В совокупности персонализированные цифровые данные и сертифицированные мандаты 33, 34 идентификации составляют основное содержание записи 75 ключа. Указанная связь может устанавливаться однократно, без ограничения времени. Цифровые мандаты 33, 34 идентификации

- 4 012094 могут инициализироваться и предоставляться независимой системе управления идентификацией (СУИ) и ее серверам 2, 2' аутентификации. Однако указанные мандаты 33, 34, 33', 34' могут предоставляться также (как это известно специалистам в данной области) и любой другой системе. Фиг. 3 иллюстрирует также возможность хранения на карте 8 множества (1,.. п) различных цифровых мандатов идентификации. В дополнение, карта 8 может быть сделана способной верифицировать идентификационные данные СУИ-серверов 2, 2' посредством сертификатов 34, 34' и т.д.

Одним из достоинств устройства по фиг. 3 является то, что ввод персонализированных данных, например биометрических данных или секретного ключа, осуществляется через соединение (устройство) 10 и сохраняется в качестве фактора аутентификации. Указанные данные вводятся при создании секретных ключей 1-п, но они необязательно содержат такие данные в качестве части ключа. Преимущество такого решения состоит в том, что владелец карты 8 остается также физическим владельцем своих биометрических данных, т.е. не предусматривается никакое распространение биометрических данных за пределы карты 8. Тем самым исключается злоупотребление этими данными, например путем их мошеннического извлечения третьими лицами из мастер-сервера.

При этом возможно сохранение биометрических данных. Это важно, поскольку эти данные, в отличие от ПИН-кода, не могут быть заменены.

Карта 8, 9 верифицирует идентификацию авторизованного пользователя посредством двух- или трехфакторной аутентификации. Кроме того, она производит обработку запросов на удостоверение личности и цифровую аутентификацию, которые могут иметь различные формы. Примером выполнения картой функций аутентификации может служить ответ в рамках протокола вызов-ответ, как это предусмотрено в способе по ЕР 1480107, разработанном авторами настоящего изобретения, генерирование цифровой подписи, доставка сообщения с кодом аутентификации или с кодом активирования для программного сертификата. Соответствующий запрос цифровой аутентификации может содержать вызов, относящийся к тому, что известно пользователю. В зависимости от уровня безопасности одна из описанных проверок может быть опущена.

На карту 8 согласно настоящему изобретению предварительно загружается массив адресов 51, 52 и 73, ключи 33, 34, 72, 79 и коды 53, 54, 76, 77, как это показано для примера такой карты, представленного на фиг. 4, и примеров процессов 4, 5 изготовления такой карты (см. фиг. 5). Карта 8 представляет собой персональный цифровой ассистент управления идентификацией. Это означает, что на карте 8 хранится информация, относящаяся к идентификации пользователя, а также другие данные, связывающие ее с другими сервисами. Информация, относящаяся к идентификации пользователя, обычно содержится в разделе 55 сводный список постановки на учет, вместе с данными 74 о постановке на учет, темплетах, секрете и др., обозначенными на фиг. 3 как 31. Карта 8 содержит также несколько сегментов 71 хранения ключей, причем каждый такой сегмент может содержать записи 75 нескольких ключей. Это эквивалентно системе управления внутренними мандатами идентификации, которая содержит: секретные ключи (как части записей 34) в форме записей 75 ключей в сегменте 71 хранения ключей в качестве цифровых мандатов идентификации; соответствующие публичные (открытые) ключи ПрСА (в составе записей 34), которые используют секретные ключи; открытый ключ 79 ОС, который произвел загрузку секретных ключей, а также (в качестве опции) сегмент 78 записей постановки на учет и информации о лицензиях на доступ.

В каждом описанном сегменте имеются также секция 77 возобновления ключей и сегмент 53 активирования ключей. При этом все данные, записанные на карте, могут выводиться через соответствующий интерфейс при наличии соответствующих разрешений (лицензий или разрешений ОС) и/или обновляться посредством последующей загрузки. Таким образом, структура карты, показанная на фиг. 4, соответствует состоянию ее использования. При этом можно приписать первому ОС сегмент 71 с единственной записью 75 ключа, а второму ОС - другой сегмент 71, например, с пятью записями 75. Кроме того, всегда имеется возможность продолжить приписывание сегментов карты 8 дополнительным ОС (новому, третьему ОС может соответствовать новый созданный сегмент), а также ассоциировать существующие записи 75 ключей с указанными первым или вторым ОС или удалить эти записи. Физическая форма подобной информации в памяти карты контролируется идентификационными номерами для токена (ИДТ) и для сегмента (ИДС) 51, 52 соответственно и для адреса записи ключа (АЗК) 73.

На фиг. 8 показан первый вариант карты 8 согласно изобретению. Карта 8 имеет размеры, аналогичные размерам кредитной карты. Однако ее толщина обычно вдвое или втрое превышает толщину кредитной карты (на фиг. 8 и 9 толщина карты сильно преувеличена). Персональная информация 83 хранится в запоминающем средстве карты. Это средство может представлять собой простое изображение, штрих-код, КРШ-чип и т.д. Карта 8 дополнительно снабжена приемным карманом 81 для приема дополнительной чип-карты 84 данных, которая может вводиться и выводиться (как это показано стрелкой 82). Дополнительная чип-карта 84 может представлять собой аналог сим-карты, пригодной для ввода в карту 8. Чип-карта 84 может рассматриваться как дополнительный токен. Различные ОС, ПрСА и операторы могут выпускать различные чип-карты.

Помимо физического ввода дополнительного токена безопасности, можно также загрузить соответствующую информацию в память, как это будет описано со ссылкой на фиг. 7. ПрСА или оператор мо

- 5 012094 жет рассматривать подобную загрузку в качестве достаточного условия для предоставления доступа к своим сервисам или требовать наличия физического токена 84 или 94 в составе карты 8 или 9.

На фиг. 9 показан второй вариант карты по изобретению, реализованный в виде терминаласчитывателя 9. Терминал 9 по размерам аналогичен карте 8 в первом варианте ее выполнения. Персонализированная информация 93 хранится в запоминающем средстве терминала, которое может представлять собой простое изображение, штрих-код, ВЕШ-чип и т.д. У терминала 9 дополнительно имеется слот 91 для приема дополнительной карты 94 данных, снабженной запоминающим средством 96. Дополнительная карта может вводиться и извлекаться, как это обозначено стрелкой 92. Дополнительная карта 94 данных может представлять собой смарт-карту с электрическими контактами или ВЕГО-интрефейс. Альтернативно, эта карта 94 может присоединяться к терминалу 9 посредством механического соединения. Дополнительная карта 94 данных также может рассматриваться как дополнительный токен.

В третьем варианте карта 8 может представлять собой одиночную карту данных без дополнительных интерфейсов для чип-карты или смарт-карты.

Для облегчения изложения карта 8 и терминал 9 далее будут именоваться картой 8, 9, а чип-карта и дополнительная карта данных - дополнительным токеном 84, 94 соответственно.

Карта 8, 9 может дополнительно содержать несколько интерфейсов 85, 95, в качестве любого из которых может использоваться оптический, радиочастотный или электрический интерфейс, а также любой другой интерфейс, известный специалистам. Оптический интерфейс способен, например, считывать мерцающий код, который выводится клиентским браузером 61. Карта 8, 9 может содержать также средства индикации для того, чтобы отображать для клиента данные о статусе и другую информацию. Средство индикации может представлять собой набор светодиодов для выведения информации о статусе или жидкокристаллическое табло для отображения более сложной информации.

Чтобы передать данные от дополнительного токена 84, 94 на карту 8, 9, между токеном и картой устанавливается безопасное соединение, использующее защищенный канал 40 (например, канал связи с шифрованием). Такое соединение устанавливается в первый раз, когда токен 84, 94 вводится в контакт с картой 8, 9. В зависимости от политики издателя дополнительного токена, после его первого использования с картой 8, 9 его дальнейшее применение может быть ограничено этой картой.

Как показано на фиг. 4, карта 8 содержит внутреннюю систему управления мандатами идентификации, использующую в качестве мандатов идентификации секретные ключи, соответствующие открытые ключи ПрСА 63, которые используют конкретный секретный ключ, открытый ключ ОС 64, который осуществил загрузку секретных ключей, а также информацию о постановке на учет, лицензию на доступ и информацию для обновления программы.

Чтобы сделать возможными независимые отношения между различными операторами (провайдерами сервисов и т.д.) и пользователями (держателями карт), необходима система управления ключами и инициализацией.

Сервисы цифровой идентификации оперируют либо только с внутренними мандатами идентификации (содержащимися в сегментах 71 и в записях 75 ключей), либо с внутренними мандатами идентификации и какой-то специально принятой информацией, которая вводится в карту 8 через один из имеющихся интерфейсов (предпочтительно оптический, радиочастотный или электрический), либо с внутренними мандатами идентификации, специально принятой информацией, которая вводится в карту 8 через один из имеющихся интерфейсов, и дополнительной информацией, содержащейся на заменяемом и индивидуализируемом дополнительном токене 84, 94, присоединяемом к основному токену (карте 8).

Дополнительный токен 84, 94 может содержать информацию, которая задает тип сервиса аутентификации, необходимой для установления бизнес-отношений с издателем или поставщиком дополнительного токена 84, 94. Он может содержать также дополнительные мандаты идентификации, которые могут использоваться только конкретным владельцем карты 8. Как правило, дополнительный токен 84, 94 может выпускаться третьим лицом, например коммерческой организацией, такой как банк, онлайновый магазин, страховая компания. Альтернативно, какая-либо фирма может выдавать дополнительные токены своим сотрудникам для получения ими доступа к внутренней компьютерной системе. Дополнительный токен может также представлять собой токен, который был выдан пользователю до получения им карты 8, 9.

Пользователь 1 (см. фиг. 6, 7) использует токен 3 в форме карты 8 или 9. Обращение к провайдеру 63, 64' нового сервиса требует аутентификации 11. Данный сервис может быть первым сервисом или одним из множества уже существующих сервисов. Благодаря биометрической идентификации карта 8 непосредственно привязана к пользователю 1. Далее провайдер нового сервиса передает пользователю 1 дополнительный токен 84. Этот токен 84 может быть выпущен ПСАу, ОС или ИзгК. Необходимо лишь, чтобы сервис-провайдер доверял отправителю дополнительного токена 84. Доставка информации по дополнительному токену 94 обозначена как 47. Как это схематично изображено на фиг. 7, данный токен может представлять собой смарт-карту, чип-карту или сим-карту или их эквивалент, или одноразовый пароль, или контакт для доступа на защищенную веб-страницу. Важно лишь, что при первом использовании дополнительного токена 84 карта 8 активирует безопасный канал 41 между ней и ПСАу, а также безопасный доступ к новому сегменту 71 или записи 75, подлежащей активации. Разумеется, дополни

- 6 012094 тельный токен 84 может представлять собой смарт-карту; которая сама создает безопасный канал 40 между ней и картой 8 для передачи по нему сообщения с инструкциями 42. Однако может быть использован и одноразовый токен, функционирующий внутри карты 8 без применения каких-то внешних аппаратных компонентов.

При открытии канала 41 по нему карте 8 передается сообщение, связанное с новой идентификацией, после чего оно обрабатывается и подтверждается с использованием дополнительного токена 84 или прямо подтверждается вышеупомянутым одноразовым токеном. В результате инициализируются новый сегмент 71 и/или новая запись 75 внутри существующего сегмента 71.

В описанной выше платформе аутентификации мандаты идентификации могут являться парами подписанных асимметричных ключей. Секретный ключ такой пары всегда хранится в безопасной памяти того, кто использует его для собственной аутентификации. Соответствующий открытый ключ подписывается ОС и направляется всем, кто хочет произвести идентификацию владельца соответствующего секретного ключа. Все зашифрованные сообщения, передаваемые через инфраструктуру сети, шифруются открытым ключом получателя и подписываются секретным ключом отправителя. Система может использовать различные схемы асимметричного шифрования, включая К.8А, ЕСС и схему Эль-Гамаля (ΕΙСата1) с соответствующей длиной ключа, как это известно специалистам.

Архитектура данных платформы обеспечивает запись ключа для каждой бизнес-связи, которую владелец карты устанавливает с оператором 66 приложения (ПСАу), требующим аутентификации. Аутентификационный сервис обеспечивается провайдером 63 аутентификации (ПрСА), который либо интегрирован в СУИ, имеющуюся у ПСАу 66, либо является специализированным внешним сервисом. ПрСА 63 регистрирует конечного пользователя и активирует соответствующую запись ключа на карте 8, 9 с разрешения ОС 64, которому принадлежит сегмент 71 записи ключа на карте. Одновременно ПрСА 63 передает свой собственный мандат идентификации карте 8 для целей взаимной аутентификации. После регистрации карты 8 у ПрСА 63 запись 75 ключа инициализирует секретный ключ (в секции 76) в качестве мандата идентификации, а также (в качестве опции) открытый ключ ПрСА 63, который будет использован для аутентификации сервера ПрСА 63 картой 8. Применительно к терминалу 9 некоторые из записей ключей содержат дополнительные поля с информацией о ключах, необходимой для коммуникации с подсоединенной смарт-картой.

Как показано на фиг. 13, карта 8 выпускается изготовителем 67 карты (обозначенным так же, как ИзгК). Каждая карта 8, 9 может использоваться несколькими независимыми ОС 64, каждый из которых использует один сегмент 71 карты 8 после получения лицензии на такое использование. Каждый ОС 64 по запросу конечного пользователя может записать на карту комплект мандатов идентификации (инициализированных записей 75 ключей). Все мандаты идентификации от одного ОС 64 хранятся в одном выделенном для этого сегменте 71 хранения ключей с определенным количеством записей 75 ключей, которые могут быть активированы в заданный момент ОС 64 или ПрСА 63, связанным с соответствующим ОС 64. ОС 64, выпустивший карту 8, выдает ее с инициализированным первым сегментом 71 хранения ключей. Он также производит первую постановку на учет пользователя с картой 8. ОС 64, который впоследствии инициализирует еще один сегмент 71 хранения ключей, может запросить запуск нового протокола постановки на учет или принять такую постановку, выполненную ОС 64, выпустившим карту. Соответствующая информация (личный код постановки на учет, называемый ЕтдетСобе) для сегмента 71 и соответствующее ему картирование хранятся внутри сегмента 71 вместе с сертификатом ОС (открытым ключом). Инициализация другим ОС также может иметь место после выдачи карты пользователю. При этом достаточно, чтобы коды доступа были заданы сразу же после того, как ИзгК загрузит на карту специализированное программное обеспечение (операция 102).

Каждая запись ключа содержит дополнительную информацию, которая задает использованную длину ключа, криптографический алгоритм и обработку данных сообщения. Доступ к сегментам 71 и к каждой записи 75 ключа внутри сегмента находится под полным контролем соответствующего ОС 64. Однако для инициализации сегмента и записей ключей ОС 64 должен получить код активации сегмента (КАС) и код активации записи ключа (КАК), которые предоставляются изготовителем 67 карты (ИзгК). Для каждой активации записи ключа задается дата истечения срока действия (ДИСД) ключа. ДИСД устанавливается при активации записи ключа (при регистрации карты 8 у ПрСА 63). Запись ключа является активной, пока самая поздняя дата в журнале событий и времени предшествует ДИСД. После этого при следующем использовании сертификата записи ключа необходимо задать новое значение ДИСД. Для такого возобновления ДИСД необходим код возобновления ключа (КВЗ), который также выдается изготовителем карты. Наличие соответствующих механизмов деблокирования и возобновления делают возможным периодическую активацию лицензий для всех используемых мандатов идентификации. Аналогичный механизм позволяет отозвать конкретный сертификат без создания трудностей для использования карты и других записанных на нее сертификатов.

Параметры контроля и метаданных позволяют, без изменения базового программного обеспечения, реализовать с помощью одной карты 8 существенно различные варианты использования карты и бизнесмоделей.

Описанный выше способ формирования карты 8 и дополнительного токена 84 иллюстрируется фиг.

- 7 012094 и 5. Изготовление карты 8, 9 включает следующие операции:

операцию 100 изготовления материальной части (основы) карты 8 или терминала 9;

операцию 101 загрузки на карту специализированной программы;

операцию тестирования материальной части и программы.

Если все тесты успешны, карта 8, 9 (именуемая на данном этапе анонимной картой) готова к загрузке на нее различных идентификаторов, сертификатов и кодов.

Для индивидуализации карты выполняется операция 102 загрузки на нее кодов инициализации, активации и возобновления.

В процессе инициализации в базу данных мандатов идентификации вводятся данные о взаимосвязи идентификаторов, и карта 8, 9 инициализируется с идентификаторами (ИДТ, ИДС, АЗК) и кодами контроля лицензий (КАС, КАК, КВЗ), причем для каждой записи ключа устанавливается срок истечения его действия (ДИСД). После выполнения этой операции доступ к аппаратным и программным компонентам возможен только через стандартные каналы связи (например, ΚΕΙΌ-канал, оптический интерфейс и т.д.).

После выполнения операций изготовления и инициализирования индивидуализированные карты 8, 9 отправляются в ОС 64. ОС 64 проводит обработку каждой карты 8, 9 в соответствии со следующим протоколом загрузки ключей:

загрузка открытого ключа ОС из конкретного сегмента открытых ключей в сегмент карты, открытый КАС-кодом (операции 103, 104);

инициализация записей ключей в данном сегменте посредством секретного кода (адреса) записи ключа (АЗК), кода активации ключа (КАК) и команд, задающих операции над сообщениями.

После этого выполняется операция 105 постановки на учет и регистрация биометрических темплетов на карте.

ОС 64 инициализирует карту с использованием цифровых криптографических мандатов идентификации и выпускает соответствующие сертификаты. Он направляет карты (и, в качестве опции, сертификаты) ассоциированным центрам постановки на учет (ЦПУ). Каждый сертификат содержит информацию об уровне безопасности, который был использован для процесса постановки на учет центром ЦПУ соответствующего ОС 64. Предусмотрено три варианта постановки на учет с различными уровнями безопасности и с легкостью реализации, обратно пропорциональной уровню безопасности.

В качестве первого уровня используется модель распределения безопасности. Постановка на учет может производиться в любом месте после того, как пользователю по безопасному каналу будут посланы карта и специальный код, позволяющий осуществить постановку на учет (стандартный уровень безопасности, применяемый, например, при распространении кредитных карт). Карта посылается конечному пользователю по незащищенному, но надежному каналу распространения (наземная почта, отдел кадров организации и т.д.). Параллельно по безопасному каналу (например, сертифицированной почтой) пользователю посылается код постановки на учет. С помощью этого кода пользователь может запустить протокол постановки на учет на любом компьютере, подключенном к Интернету. Протокол постановки на учет обеспечивается сервером аутентификации ОС.

В качестве второго уровня безопасности при постановке на учет используется модель доверенного дерева, соответствующая постановке на учет в присутствии доверенного и уже поставленного на учет лица, которому поручено подбирать новых пользователей (повышенный уровень безопасности). Новый конечный пользователь получает свою карту 8, 9 от агента, который знает его лично и который уже имеет подобную карту. Новый конечный пользователь получает соответствующий код постановки на учет по тому же безопасному каналу, что и при использовании предыдущей модели. Чтобы запустить протокол постановки на учет для новой карты 8, 9, агент должен использовать собственную карту 8, 9 на любом компьютере, подключенном к Интернету. Затем новый пользователь осуществляет стандартный процесс постановки на учет на том же компьютере. Агент знает пользователя и тем самым гарантирует, что на учет ставится именно нужное лицо, т.е. агент действует как временный мобильный ЦПУ.

На третьем уровне безопасности при постановке на учет используется модель сертифицированной аутентификации. Постановка на учет производится в надежной зоне (в ЦПУ) под наблюдением соответствующего представителя и с представлением официального документа (пропуска). В качестве центра постановки на учет (ЦПУ) ОС назначает и сертифицирует конкретные безопасные зоны. Конечный пользователь получает в ЦПУ карту 8, 9 после верификации его личности сотрудником ЦПУ (например, при представлении пользователем своего паспорта). Затем новый конечный пользователь запускает протокол постановки на учет на выделенном для этого терминале в ЦПУ. Код постановки на учет передается ему сотрудником ЦПУ.

Пользователь 1, который впоследствии захочет повысить уровень безопасности своей карты 8, 9, должен пройти через новый процесс постановки на учет или верификации его данных, который совместим с желаемым уровнем безопасности.

Процесс инициализации и постановки на учет, применяемый ОС и ЦПУ, может быть сертифицирован в соответствии с признанными стандартами сертификации (СС, 1Р88ЕС, ΕΙΡ8), чтобы гарантировать взаимное доверие в случае, если карты и сертификаты выпускаются более чем одним ОС. Процесс постановки на учет является одинаковым для всех трех уровней безопасности. Он устанавливает сильную

- 8 012094 двух- или трехфакторную связь между пользователем как физическим лицом и картой 8, 9. По завершении постановки на учет каждый сертификат представляет независимый сертифицированный цифровой мандат идентификации пользователя.

Во всех системах аутентификации постановка на учет является критическим шагом, который использует априорные знания и уверенность в идентичности пользователя 1. В большинстве случаев первоначальная идентифицирующая информация поступает от государственной СУИ. Регистрация и управление идентификацией своих граждан является одной из наиболее важных задач любого государства. Все СУИ должны опираться на какой-то вариант официальных сертификатов, выпускаемых государством.

По завершении протокола постановки на учет на карту 8, 9 записывается уровень безопасности, который может запрашиваться при последующих процессах регистрации или аутентификации. После постановки на учет карту можно использовать. Для этого пользователь (держатель поставленной на учет карты) выполняет следующие две операции:

регистрацию у ПрСА (операция 106) при первом доступе к новому сервису или сайту;

аутентификацию (каждый раз, когда пользователю требуется подтвердить свою идентификацию для получения доступа к защищенным зонам или сервисам) (операция 107).

После выполнения названных операций карта 8, 9 становится функциональной картой для ПрСА 66. При этом, если срок действия сертификата истекает, карта может быть разблокирована кодом возобновления ключа (операции 108, 111). Точнее, карта разблокируется, если код действующий. Если нет, определенный ключ на карте будет заблокирован. Возможен также отзыв карты (операция 109).

В случае использования терминала 9 в комбинации с дополнительным токеном 94 необходима операция 110 инициализации терминала 9 и дополнительного токена 94 (в форме смарт-карты 110' от оператора).

Вариант с терминалом 9 позволяет провести постериорную настройку функциональности дополнительного токена 94. Для этого в дополнительном токене 94 (который может представлять собой смарткарту или другой съемный токен, присоединяемый к карте) производится обработка специфичного отклика на загруженное исходное сообщение. Терминал 9 (карта с механическим слотом 91 для приема смарт-карты) служит в качестве устройства аутентификации, которое передает расшифрованное сообщение смарт-карте (СМК) по безопасному каналу 40 между терминалом и СМК. Этот безопасный канал 40 устанавливается, когда дополнительный токен 94 в первый раз вводится в терминал 9. После такой инициализации дополнительный токен 94 может взаимодействовать только с данным терминалом 9. Данная операция инициализации не изменяет никаких каналов связи с другими устройствами (считывателями карт). Это справедливо и для случая, когда, с целью инициализации требуемого сегмента 71 или требуемой записи 75, указанное сообщение обрабатывается с помощью дополнительного одноразового программного токена.

Карта 8, 9 может быть зарегистрирована у ПрСА/ПСАу. Когда пользователь вступает в бизнес отношения с оператором (ПСАу/ПрСА), очередной сертификат, доступный на карте 8, 9 пользователя, должен быть доставлен серверу аутентификации оператора. Этот сертификат в дальнейшем предназначается только для аутентификации пользователя в сети данного конкретного оператора. Сервер аутентификации может составлять часть СУИ самого оператора, альтернативно, он может быть реализован у внешнего провайдера аутентификации (ПрСА).

При регистрации карты 8, 9 в сети она регистрируется в СУИ провайдера аутентификации (ПрСА). Эта регистрация активирует следующий неиспользованный ключ из списка первоначально записанных ключей. Соответствующее сообщение содержит также открытый ключ ПрСА, подписанный ОС. Это делает возможной взаимную аутентификацию сервера и карты 8, 9.

Секция возобновления ключа в каждой записи ключа соответствует полю контроля лицензии. Она содержит код возобновления ключа (КВЗ), который блокирует доступ к данному полю для нелегитимных сообщений. В этом поле имеется также код истечения срока действия ключа, который содержит дату прекращения действия данной записи. По истечении срока действия в запись должен быть внесен для хранения новый код возобновления ключа (присланный авторизованной инстанцией), а ДИСД должна быть соответственно обновлена.

Для всех выпущенных карт 8, 9 их поставщик поддерживает систему управления идентификацией. Эта система поставляет коды, необходимые для хранения на карте, инициализации и использования мандатов идентификации. Поставщик совместно с соответствующим ОС обеспечивает также репродуцирование потерянных или украденных карт без чрезмерного взаимодействия с пользователем (от которого требуется только повторная постановка на учет).

Как показано на фиг. 7, для реализации федеративного управления идентификацией не требуется наличия доверенной сети операторов. Множество различных организаций, пользующихся или не пользующихся взаимным доверием, могут использовать одну и ту же карту 8, 9 для аутентификации ее владельца. Единственное ограничение состоит в том, что организации должны верить или удостовериться, что карта находится в руках правомерного пользователя. Это может быть обеспечено проверкой при постановке на учет. Каждый оператор может провести такую проверку через Интернет в любое время (см. в

- 9 012094 этой связи протокол постановки на учет). Обычно достаточно, чтобы оператор имел доступ к конкретному сертификату, выпущенному соответствующим ОС и хранящемуся на карте 8, 9. В этом случае ОС гарантирует, на определенном уровне безопасности, что идентифицированная карта 8, 9 находится во владении легитимного пользователя. Это весьма облегчает установление новых бизнес-отношений. Пользователь просто регистрирует свою персональную карту 8, 9 в СУИ оператора. Оператор получает код доступа к одному из предварительно инициализированных мандатов идентификации, хранящихся на карте 8, 9, и устанавливает аутентичные взаимные отношения с пользователем на базе указанного мандата идентификации. Такая схема реализует неограниченные возможности федерализации идентификации между всеми операторами, принимающими аутентификацию.

Таким образом, карта 8, 9 использует одинаковые мандаты идентификации как для логического, так и для физического доступа. Разделение систем доступа на логические и физические частично связано с использованием двух различных концепций коммуникации. Для физического доступа часто применяются карты на интегральной схеме (смарт-карты), содержащие мандат идентификации, который должен быть представлен считывателю (контактному или бесконтактному) на контрольном пункте у входа. Для логического доступа в процессе аутентификации часто необходимо ввести через клавиатуру секретный код.

Применительно к устройству и способу согласно изобретению обе эти формы аутентификации интегрированы в одну схему. Те же самые мандаты идентификации используются для доставки требуемых доказательств идентичности через соответствующие каналы связи. Карта 8, 9 генерирует соответствующее подтверждение и представляет его через имеющееся жидкокристаллическое табло для логического доступа со стороны инфраструктуры. В случае физического доступа тот же самый мандат идентификации доставляет подтверждение идентичности через встроенный ΚΗΌ-канал связи (в соответствии со стандартом ИСО 14443) считывателю на контрольно-пропускном пункте. Таким образом, унификация логического и физического доступов может быть достигнута при минимальных изменениях инфраструктуры.

Согласно стандартам ИСО для обозначения всех устройств, в которых на идентификационной карте из пластика с размерами стандартной кредитной карты (формата ΙΌ-1) имеется интегральная схема, в стандартах ИСО используется термин Карта на интегральной схеме. Такие карты, обычно именуемые смарт-картами, изготавливаются в двух форматах: контактном и бесконтактном. Технология смарт-карт все шире применяется в приложениях, которые должны защищать персональную информацию или обеспечивать быстрые, надежные транзакции.

Карта 8, 9 по изобретению способна обеспечить возможность использования смарт-карт в любом месте. Это позволяет реализовать новые приложения для бизнеса. Обычно для применения смарт-карт требуется локальный считыватель, что ограничивает мобильность и области применения таких карт. Карта 8, 9 обеспечивает для смарт-карт возможность безопасных соединений и в некоторой степени служит в качестве персонального мобильного считывателя. Решение, заложенное в карты 8, 9, позволяет связывать с системой аутентификации новые сервисы даже после завершения их развертывания. Оператор просто рассылает смарт-карты, адаптированные для нового сервиса, пользователям, которые могут получить доступ к этому сервису, вводя эту смарт-карту (в качестве дополнительного токена 94) в свою карту 8, 9.

Для подключения к карте 8 вместо смарт-карты стандартного размера может быть использована только ее контактная зона (чип и контактные площадки, аналогично сим-карте). В этом случае упрощается концепция терминала, описанная выше.

Устройство и способ аутентификации согласно изобретению обеспечивают гибкое обслуживание различных операционных моделей в соответствии с потребностями оператора или сообщества операторов в аутентификации. Это достоинство изобретения будет проиллюстрировано на фиг. 10-13.

На фиг. 10 иллюстрируется работа устройства по изобретению в автономном режиме. В этом варианте одна организация объединяет в себе функции ОС, ЦПУ, ПрСА и ПСАу. Она имеет собственную СУИ, использующую аутентификацию для контроля физического и логического доступа авторизованных пользователей к своим объектам любого типа. Организация получает карты 8 и коды лицензий от изготовителя 67 и распространяет их среди пользователей.

Фиг. 11 иллюстрирует изобретение в режиме использования сервиса аутентификации. В этой модели организация 68 предоставляет сервис управления идентификацией и мандатами идентификации нескольким организациям 66. Основной функцией такого сервиса является аутентификация онлайновых пользователей для операторов бизнес-платформ. Организация 68 - провайдер аутентификации - сочетает роли ОС, ЦПУ и ПрСА. Она распространяет карты и осуществляет управление идентификацией для различных операторов, которые поддерживают бизнес-отношения с конечным пользователем карты. При этом ПрСА может поддерживать специальный веб-портал, чтобы объединить все предоставляемые доступы.

Фиг. 12 иллюстрирует использование изобретения в работе органа сертификации. В этой модели функции ОС 64 выполняет хорошо известная общественная или частная организация. Она имеет ЦПУ и обеспечивает другие организации 69 (ПрСА+ПСАу) сертифицированными открытыми ключами для кар

- 10 012094 ты, так что эти организации могут верифицировать идентичность конечных пользователей при каждом вступлении в контакт с ПСАу.

Фиг. 13 иллюстрирует использование изобретения применительно к федеративному режиму. В этой модели несколько ОС 64 могут инициализировать карту 8 своими сертифицированными ключами в качестве мандатов идентификации. Каждая карта 8 может содержать несколько независимых сегментов 71 хранения ключей (как мандатов идентификации), причем каждый сегмент выделен отдельному ОС 64. В этом случае каждый ОС 64 функционирует для своей клиентской организации 69 как независимый ОС 64 для того сегмента на карте 8, который был сертифицирован этим ОС 64. Каждый ОС 64 должен приобрести сегмент кода активации, который позволяет ему записать свои сертификаты в конкретном сегменте 71 карты. Подобная последующая загрузка ключей на карту 8 со стороны ОС 64 не создает помех для ранее загруженных сертификатов других ОС 64. Каждый ОС 64, в соответствии со своей политикой безопасности, может запросить у конечного пользователя верификацию его постановки на учет.

В варианте, обеспечивающем повышенную безопасность в отношении персональных данных, ОС передает конечному пользователю подписанные сертификаты на загруженные мандаты идентификации, после чего конечный пользователь предоставляет, в процессе регистрации, соответствующий сертификат ПрСА. ПрСА может верифицировать сертификат без обращения в ОС, так что ОС не в состоянии отслеживать бизнес-отношения пользователя, а ПрСА - верифицировать персональную информацию, кроме предоставленной вместе с сертификатом. Такая схема позволяет реализовать концепцию доверенного и сертифицированного псевдонима, который может быть различным для разных ПрСА. Это защитит пользователя от атак, направленных на группы сходных пользователей (ргоййид айаекк), и позволит ему сохранять максимальную анонимность в онлайновых транзакциях.

Система аутентификации способна поддерживать все описанные операционные модели без какойлибо модификации карты 8 или платформы аутентификации. Для этой цели, в частности, и была разработана описанная выше архитектура данных, предназначенная для виртуального хранения и управления мандатами идентификации.

Использованные обозначения

- физическое лицо, конечный пользователь

- сервер системы управления идентификацией (СУИ), модуль доступа в составе ПрСА

- токен, реализованный в форме карты или терминала

- способ изготовления и жизненный цикл карты

- способ изготовления и жизненный цикл терминала

- платформа аутентификации, включающая сервер ОС и сервер ПрСА

- система аутентификации с тремя функциональными подсистемами: персональным токеном; платформой аутентификации с необходимой инфраструктурой и модулем интерфейса для существующей СУИ и приложений

- карта

- терминал-считыватель

- входные устройства для биометрических данных и секрета

- встроенная двух- или трехфакторная аутентификация

- аутентификационный модуль с интерфейсами для существующих систем и приложений

- защищенные приложения

- персональные данные для аутентификации

- встраивание персональных данных (секретных ключей) в записи ключей

33, 33' - секретный ключ, персонализированные цифровые данные

34, 34' - запись цифрового мандата идентификации (запись ключа)

35, 35' - передача в ПрСА системы управления идентификацией

- защищенный/зашифрованный канал связи

- секретное сообщение и инструкции

- доставка токена

- идентификационный номер токена (ИДТ)

- идентификационный номер сегмента (ИДС)

- код активации сегмента (КАС)

- код активации ключа (КАК)

- сводный список постановки на учет

- клиентский браузер

- ВЕГО-считыватель

63, 63' - провайдер сервиса аутентификации (ПрСА)

- орган сертификации (ОС)

- сервер лицензий

- пользователь сервисом аутентификации (ПСАу, оператор приложений)

- изготовитель карты (ИзгК)

- 11 012094

- организация, выполняющая функции ОС + ПрСА

- организация, выполняющая функции ПрСА + ПСАу

- сегмент хранения ключей

- управляющие коды для шифра и обработки сообщения

- адрес записи ключа (АЗК)

- данные о постановке на учет, темплетах, секрете и др.

- запись ключа

- секция хранения ключей

- секция возобновления ключей

- сегмент записей постановки на учет

- открытый ключ ОС

- приемный карман

- направление ввода

- персональная информация

- чип-карта данных

- интерфейсы

- слот

- направление ввода

- персонализированная информация

- дополнительная карта данных

- интерфейсы

- запоминающее средство

Claims

...... ¹ г с инициализир. сегментом

Постановка на учет

Терминал, сертифицирован. ОС _г Терминал готов к отправке ОС инициализир. загружает сегмент

Персонализир. СМК в терминале

106

Карта, зарегистрир. ПрСА У^107

Функциональн. Карта

I Анонимный терминал Загрузка кодов θ2 юициализации и

102 ίΟΟ инициализир. \ и загружает сегмент 0 ί

Постановка на учет

Персонал изир. Карта

Ч Разблокирование 'Ύύ-χΙ 08 кодом возобновления

103

104

110

Персонализир^ терминал^

Инициализация парьг|^ ( СМК 10' терминал-СМК оператора

Терминал/СМК, зарегистрир. у ПрСА

107

Функциональн. терминал/СМК

Заблокирован. терминал/СМК

Фиг. 5

1. Токен (8, 9) безопасности, содержащий память для персональных данных, предназначенную для хранения цифровых мандатов идентификации на основе персональных данных (31) пользователя и/или персонализированных данных (33, 34; 33', 34'), входное устройство (10) для осуществления проверки указанных персональных данных, предпочтительно для верифицирования идентификации с использованием двух или трех факторов аутентификации, память (71, 75) для хранения записей ключей, предназначенную для хранения по меньшей мере одного мандата идентификации сервера провайдера (63) аутентификации или оператора (66) приложений, предпочтительно для хранения мандатов идентификации, инициализированных органом сертификации (ОС), приемопередатчик для формирования защищенного канала (41) прямой или непрямой связи с сервером провайдера (63) аутентификации, оператором (66) приложений или органом сертификации для взаимодействия с указанными записями ключей, соотнесенными с сервером провайдера (63) аутентификации, или оператором (66) приложений, или органом сертификации, блок управления для управления приемопередатчиком и памятью (71, 75) для хранения записей ключей в связи с указанным взаимодействием, предусматривающим действия, выбранные из группы, включающей, помимо других воздействий на записи ключей, интерпретацию, дешифрование, создание, проверку, возобновление и удаление.
2. Токен (8, 9) по п.1, отличающийся тем, что контент дополнительного токена (84, 94) является входной информацией для блока управления при проведении указанным блоком проверки идентичности после создания или активирования новой записи (71, 75) ключа или после использования активированной записи с новой загруженной инструкцией.
3-факторн. аутентифика: авторизированного пользе!

ч_

Фиг. 7

Доставка СМС с новым протоколом

Обработка сообщения с инструкциями Смарт-карта с каналом связи с терминалом конкретного пользователя

Фиг. 8

Фиг. 9

3. Токен (8, 9) по п.2, содержащий электронный контур, выполненный как дополнительный токен (84, 94) и содержащий дополнительное средство приема и передачи, формирующее дополнительный защищенный канал (40) к токену безопасности для получения сообщения (42) с инструкциями от сервера провайдера (63) аутентификации или оператора (66) приложений, и средство обработки для передачи обработанного сообщения в блок управления.
4. Токен (8, 9) по п.2, отличающийся тем, что входная информация для блока управления, имеющаяся на дополнительном токене (84, 94), представляет собой секрет.
5. Токен (8, 9) по любому из пп.1-4, отличающийся тем, что содержит множество записей (75) ключа, при этом блок управления содержит элементы для активации записей, обеспечивающие единственному органу (64) сертификации или серверу провайдера (63) аутентификации возможность обрабатывать все записи ключей и распределять авторизацию на взаимодействие с различными записями (75) ключа между различными серверами провайдеров (63) аутентификации или операторами (66) приложений.
6. Токен (8, 9) по п.5, отличающийся тем, что снабжен двумя или более сегментами (71) хранения ключей, по меньшей мере один из которых содержит множество записей (75) ключей, при этом блок управления содержит элементы активирования указанных сегментов, обеспечивающие единственному
7. Токен (8, 9) по любому из пп.1-6, отличающийся тем, что память для персональных данных и входное устройство выполнены с возможностью обеспечения хранения и проверки, в качестве персональных данных, биометрических данных и/или секрета.
8. Способ аутентификации пользователя с помощью токена безопасности, выполненного по любому из пп.1-7, включающий операции проверки хранящихся персональных данных пользователя с целью верификации авторизации пользователя для использования указанного токена безопасности, создания защищенного канала к токену безопасности для взаимодействия с записями ключа, относящимися к серверу провайдера (63) аутентификации или оператору (66) приложений, при этом указанное взаимодействие предусматривает действия, выбранные из группы, включающей, помимо других воздействий на записи ключей, интерпретацию, дешифрование, создание, проверку, возобновление и удаление.
9. Способ по п.8, отличающийся тем, что обеспечивает возможность неограниченного федеративного управления идентификацией за счет использования операции, в которой токен безопасности (8, 9) получает от сервера провайдера (63) аутентификации или оператора (66) приложений по защищенному каналу (41) сообщение с инструкциями и передает указанное сообщение по дополнительному защищенному каналу (40) на дополнительный токен (84, 94), обрабатывающий указанное сообщение и возвращающий обработанное сообщение токену безопасности (8, 9) для аутентификации пользователя посредством токена безопасности.
10. Способ по п.9, отличающийся тем, что дополнительный защищенный канал (40) устанавливают при первом вводе дополнительного токена (84, 94) в токен (8,9) безопасности для создания или активации записи (71, 75) ключа в памяти токена безопасности или для установления связи с этой записью.
11. Способ по любому из пп.8-10, отличающийся тем, что токен безопасности используют для сканирования мерцающего кода на табло или дисплее оператора (66) приложений для подтверждения правомочности интерфейса.
12. Способ по любому из пп.8-11, отличающийся тем, что позитивную аутентификацию токена безопасности используют для предоставления доступа к прикладной программе, для осуществления платежа, для формирования билета, для получения секретного сообщения или для получения физического доступа, в частности к открытой двери.

- 12 012094 органу (64) сертификации возможность обрабатывать все записи ключей одного сегмента (71) хранения ключей и распределять авторизацию на взаимодействие с различными записями (75) ключа между различными серверами провайдеров (63) аутентификации или операторами (66) приложений.
- 13 012094

Фиг. 2

Фиг. 3

13. Способ аутентификации пользователя с помощью токена безопасности по пп.1-7, обеспечивающего управление со стороны пользователя мандатами идентификации, подписанными органом сертификации, и выполненного с возможностью формирования защищенного и доверенного канала к одной из записей (71, 75) ключа на токене (8, 9).

Фиг. 1
- 14 012094

Возможная инициализация дополнительным ОС

Карта

Терминал

С

Основа карты

С

101

Анонимная карта

Карта готова к отправке

Карта, сертифицирован. ОС

Регистраци

Загрузка программы

Изготовление основы

Загрузка записей ключей

Загрузка записей ключей

Изготовление основы

ΖΙ

Загрузка программы

Г Загрузка кодов I инициализации и др

Основа терминала \х^101 у

Сертифицированный терминал
- 15 012094

Зашифрс

Фиг. 6

Терминал, активированный
- 16 012094

Фиг. 10

Фиг. 11

Фиг. 12

Фиг. 13