Аутентификация устройства и пользователя

Аутентификация устройства и пользователя

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ

Настоящее изобретение относится к способу и системе для аутентификации устройства и пользователя. Изобретение может использоваться для обеспечения улучшенной аутентификации пациента для медицинского обслуживания с использованием идентификатора (ID) устройства.

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

Все более важной тенденцией в здравоохранении является причастность потребителя/пациента на всех уровнях здравоохранения. Люди берут на себя более активную роль в своем собственном управлении здоровьем. Эта тенденция предоставления полномочий пациенту была уже широко поддержана. На рынок был введен ряд решений, которые позволяют пациентам собирать свою собственную связанную со здоровьем информацию и сохранять ее на портативных устройствах, PC и в онлайновых службах (например, CapMed, WebMD, MedKey). Эти решения часто упоминаются как службы персональной медицинской документации (PHR). Ряд продуктов на рынке уже позволяют пациентам автоматически вводить измерения и другие медицинские данные в их PHR (например, LifeSensor и Microsoft HealthVault). В такой системе шкала веса, например, будет посылать свою информацию через Bluetooth на PC, с которого данные затем загружаются в PHR пользователя. Это позволяет пациентам собирать и управлять своими собственными медицинскими данными, но что еще более важно, совместно использовать данные с различными работниками здравоохранения, вовлеченными в их обработку.

Другая важная тенденция в здравоохранении состоит в том, что доставка услуг здравоохранения постепенно расширялась от неотложного стационарного ухода до амбулаторного лечения и ухода на дому. Достижения в информационных и коммуникационных технологиях позволили развивать дистанционные услуги здравоохранения, включая телемедицину и дистанционный мониторинг пациента. Ряд услуг на рынке уже развертывают инфраструктуры дистанционного здравоохранения, где устройства измерения связаны через домашние концентраторы с удаленными серверами. Медицинские работники используют эту архитектуру, чтобы дистанционно получать доступ к данным измерения и помогать пациентам. Примерами являются услуги управления лечением заболевания (такие как Philips Motiva и PTS) или услуги экстренного реагирования (Philips Lifeline).

Способность к взаимодействию устройств измерения, домашних концентраторов и серверных служб становится очень важной для инициирования и дальнейшего роста этого рынка. Эта потребность признана медицинским союзом Continua. Как показано на фиг. 1, эта инициатива стандартизирует протоколы между устройствами измерения, устройствами домашнего концентратора (хостирование приложений), онлайновыми службами здравоохранения/хорошего здоровья (WAN) и устройствами медицинской документации (PHR/EHR). Наряду с форматом данных и вопросами обмена, Continua также обращается к проблемам безопасности и надежности.

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

В существующей практике идентификатор устройства (ID устройства) используется либо как идентификатор пользователя (ID пользователя), либо как средство для вывода ID пользователя (если многочисленные пользователи используют то же самое устройство). Например, в Continua, как описано в Continua Health Alliance, “Recommendations for Proper User Identification in Continua Version 1-PAN and xHR interfaces" (Draft v.01), декабрь 2007, на PAN интерфейсе (см. фиг.1), каждое устройство Continua обязано посылать свой собственный уникальный ID устройства. ID пользователя является опциональным (и может быть только простым как 1, 2, A, B). Действительный ID пользователя получают в устройстве концентратора (устройстве, хостирующем приложение), которое может обеспечить отображение между простым ID пользователя, ассоциированным с ID устройства, и действительным ID пользователя. Также могут быть устройства измерения, которые могут посылать действительный ID пользователя наряду с ID устройства. Тогда отображение не требуется.

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Поэтому целью изобретения ввести усовершенствование в известный уровень техники.

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

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

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

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг. 1 - схематичная диаграмма системы здравоохранения,

Фиг. 2 - другая схематичная диаграмма системы здравоохранения,

Фиг. 3 - схематичная диаграмма системы аутентификации устройства и пользователя,

Фиг. 4-9 - блок-схемы последовательности операций соответствующих процедур регистрации и аутентификации, и

Фиг. 10, включающая в себя Фиг. 10a и 10b, - схематичная диаграмма предпочтительных вариантов осуществления системы аутентификации.

Подробное описание предпочтительных вариантов осуществления

Пример системы здравоохранения показан на Фиг. 1. Показаны различные устройства 10 персональной сети (PAN), такие как наручные часы и прибор измерения кровяного давления, которые непосредственно измеряют физиологические параметры пользователя. Дополнительно предусмотрены устройства 12 локальной сети (LAN), такие как бегущая дорожка, которая может также использоваться, чтобы собирать дополнительную медицинскую информацию о пользователе. Устройства 10 PAN и устройства 12 LAN связаны через подходящие интерфейсы (проводные и/или беспроводные) с соответствующим устройством 14, хостирующим приложения, таким как компьютер или мобильный телефон, который будет локальным для PAN и LAN устройств 10 и 12, например, в доме пользователя. Хостирующее устройство 14 будет исполнять подходящее приложение, которое может собрать и организовать выводы от различных устройств 10 PAN и 12 LAN.

Устройство 14, хостирующее приложение, соединено с WAN (глобальная сеть) устройством 16, таким как сервер. WAN соединение может быть через сеть, такую как Интернет. Сервер 16 также связан через подходящий интерфейс с устройством 18 медицинской документации, которое поддерживает медицинскую документацию для пользователей системы. Каждый пользователь имеет сохраненную медицинскую документацию в устройстве 18. Как обсуждено выше, является первостепенно важным, что данные, зарегистрированные посредством отдельной медицинской документации, сохраненной устройством 18, назначены, во-первых, корректному пользователю, и дополнительно, что устройство 10 или 12, которое первоначально сделало запись данных, известно с абсолютной достоверностью. Также желательно, чтобы соответствующее PAN или LAN устройство 10 или 12 было также одобрено для использования в системе.

Фиг. 2 иллюстрирует систему по Фиг. 1, с пользователем 20, который проводит измерения с PAN устройством 10. Через домашний концентратор 14, данные могут быть сообщены удаленному записывающему устройству 18, которое поддерживает запись 22 пациента. Удаленное записывающее устройство 18 также осуществляет связь непосредственно с GP записью 24. В этом примере пользователь 20 неправильно идентифицировал себя по отношению к устройству 10, и также использует некорректное устройство 10 для измерения, которое он пытается сделать. В обычной системе это приведет к неправильному вводу, сделанному в запись 22, и могло бы вызвать неправильную сигнализацию, выданную относительно состояния пациента.

Чтобы предотвратить тип ошибки, которая иллюстрируется на Фиг. 2, система согласно данному изобретению имеет вид, показанный на Фиг. 3. На чертеже показаны PAN устройство 10, LAN устройство 12 и пользователь 20, осуществляющие связь с удаленным медицинским устройством 18. Существенный принцип состоит в том, что ключ выводят исходя из пользователя 20 и из информации от устройства 10 или устройства 12, и в одном варианте осуществления ключ используется, чтобы кодировать сенсорные данные от устройства 10 или 12, и кодированные данные передаются к удаленному серверу 18. Там выполняется биометрическое измерение пользователя 20 (например, отпечатка пальца), и ключ генерируется из этого биометрического измерения. Любое устройство 10 или 12, фактически выполняющее измерения, ни используется в комбинации с данными от пользователя 20 для создания ключа, чтобы защитить данные таким способом, что пользователь 20 и устройство 10 или 12 могут быть надежно идентифицированы.

ID пользователя, извлеченный из биометрического измерения, и ID устройства от соответствующего устройства 10 или 12, могут быть объединены в устройстве, хостирующем приложение, компоненте 14 на Фиг.1. Большинство устройств измерения (PAN устройства 10 и LAN устройства 12) не будут иметь датчиков отпечатка пальца на них из-за их ограниченных способностей, и датчики отпечатка пальца могут быть присоединены к устройству 14, хостирующему приложение. Когда пользователь выполняет измерение, ID устройства также посылается в хостирующее устройство 14 вместе с измерением, где биометрический ID и ID устройства объединяются, чтобы генерировать ключ, который затем используется, чтобы подписать (или аутентифицировать) данные, полученные от устройства 10 или 12.

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

Биометрическая информация, такая как отпечаток пальца человека или сканирование радужной оболочки, явно является не однородной случайной последовательностью и не становится воспроизводимой точно каждый раз, когда выполняется измерение. По этой причине используются нечеткие экстракторы, чтобы вывести почти однородную случайность R из биометрического входа. Извлечение является также толерантным к ошибкам в том смысле, что R будет тем же самым, даже если вход изменяется, пока он остается приемлемо близким к оригиналу. Таким образом, требуется нечеткий экстрактор или алгоритм вспомогательных данных, чтобы извлекать один (или более) безопасных ключей из зашумленных биометрических данных. Для получения дополнительной информации по этим вопросам см. J.-P. М. G. Linnarz and P. Tuyls, "New Shielding Functions to Enhance Privacy and Prevent Misuse of Biomertric Templates", Audio-and Video-Based Biometric Person Authentication, AVBPA 2003, ser. LNCS, J. Kittler, M. S. Nixon, Eds., vol.2688. Springer, June 9-11, pp. 393-402. и Y. Dodis, M. Reyzin and A. Smith, "Fuzzy extractors: How to generate strong keys from biometrics and other noisy data", Advances in Cryptology, EUROCRYPT, ser. LNCS, C. Cachin, J. Camenisch, Eds., vol. 3027. Springer-Verlag, 2004, pp. 523-540.

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

Во время фазы регистрации (выполняемой в доверяемой среде), выполняется вероятностная процедура, называемая Gen. Она принимает в качестве ввода зашумленное биометрическое измерение R, и формирует в качестве выхода ключ K и вспомогательные данные W: (K, W)<-Gen(R). Чтобы генерировать вспомогательные данные W, код С коррекции ошибок выбирается таким образом, что по меньшей мере t ошибок может быть исправлено. Число ошибок, которые будут исправлены, зависит от конкретного приложения и от качества биометрического измерения. Как только соответствующий код был выбран, вспомогательные данные W генерируются первым выбором случайного кодового слова Cs из C и вычислением W1=Cs+R. Кроме того, универсальная хэш-функция hi выбирается случайным образом из набора H, и ключ K определяется как K<-hi(R). Вспомогательные данные затем определяются как W=(W1, i).

Во время фазы реконструкции ключа выполняется процедура, называемая Rep. Она принимает в качестве входа зашумленный отклик R' и вспомогательные данные W и реконструирует ключ K (если R' происходит из того же самого источника, что и R), то есть K<-Rep(R', W). Реконструкция ключа достигается вычислением CS'=W1+R', декодированием CS' до Cs через алгоритм декодирования C, восстановлением R=Cs+W1 и, наконец, вычислением K=hi(R). Настоящий способ будет работать также с другими типами вспомогательных данных. Например, вместо выполнения операции XOR, также возможно выполнить перестановку.

Как ранее упомянуто, проблемой, которая решается в рассматриваемой системе, является аутентификация пациента 20 и устройства 10 или 12, которые выполнили измерение. Это достигается связыванием измерения как с ID устройства, так и с конкретным пользователем. Каждое медицинское устройство 10 и 12, которое сертифицировано посредством Continua, имеет уникальный глобальный ID. Предоставлены два основных метода для объединенной аутентификации пользователя и устройства. Во-первых, биометрическое измерение непосредственно отображается на код C коррекции случайных ошибок, и генерируется вспомогательные данные. Однако вместо непосредственного отображения биометрического измерения, биометрическое измерение и глобальный уникальный ID устройства 10 или 12 отображаются вместе на кодовое слово коррекции случайных ошибок.

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

Предполагается, что следующее доступно на устройстве 10 или 12, которое используется: алгоритм ReadID, который по вызову возвращает глобальный уникальный ID устройства (это записывается как DIDi<-ReadID(i); эта запись означает, что команда ReadID исполняется на устройстве i), алгоритм GenBio, который после получения биометрического измерения BMu от пользователя U выводит (Ku, Wu) (это записывается как (Ku, Wu)<-GenBio(BMu)), и алгоритм RepBio, который после получения биометрического измерения BMu' от пользователя U и вспомогательных данных Wu выводит ключ Ku, если BMu и BMu' достаточно близки (это записывается как Ku<-RepBio(BMu', Wu)).

В первом варианте осуществления система работала бы следующим образом, когда А группа пользователей U1, U2, U3… Un имеет устройство i, которое измеряет сигнал некоторых пользователей. Процедура регистрации варианта 1 осуществления показана на левой стороне Фиг. 4. Этап R1.1 означает первый этап в процессе регистрации варианта 1 осуществления. На правой стороне на чертеже показан соответствующий процесс аутентификации. Этап A1.1 означает первый этап в процессе аутентификации варианта 1 осуществления.

На этапе R1.1, если пользователь Uj использует устройство i впервые, то перед выполнением алгоритма GenBio, выполняется алгоритм ReadID как DIDi<-ReadID(i). Теперь после получения DID получают биометрические данные Bmuj на этапе R1.2 и исполняют алгоритм GenBio на BMuj плюс DIDi, такой как (Kuij, Wuij)<-GenBio(BMuj||DIDi). Здесь "||" может представить простую конкатенацию или операцию xor для BMu и DIDi. Выход алгоритма GenBio является почти однородным ключом Kuij и вспомогательными данными Wuij, которые зависят как от биометрического измерения BMu, так и от глобального уникального ID устройства-DIDi. Это является этапом R1.3.

Этапы R1.2 и R1.3 повторяются для каждого пользователя, который хочет использовать устройство i. База данных сохранена в устройстве с записями следующим образом: (Uj; Wuij), где Uj-последовательность, идентифицирующая пользователя. Это может быть имя, адрес электронной почты, генерируемый системой идентификатор, функция предыдущего (например, 16 наименее значимых битов намного более длинного идентификатора, идентифицирующего пользователя) и т.д. Альтернативно, вспомогательные данные могут быть индексированы, используя Kuij. Однако, это не желательно с точки зрения безопасности, поскольку ключ, используемый для аутентификации, сохраняется в открытом виде. Это является этапом R1.4.

Вычисленный симметричный ключ "Kuij" зависит как от биометрических данных пользователя, так и от глобального ID устройства, и затем передается безопасным образом провайдеру службы здравоохранения на этапе R1.5, вместе с ID устройства и идентичностью пользователя Uj. Отметим, что по причинам конфиденциальности Uj на различных этапах не должны быть теми же самыми идентификаторами, однако в этом случае требуется взаимно однозначное (один-к-одному) отображение между ними, сохраненное или в устройстве, или на сервере.

Процедура аутентификации для варианта 1 осуществления также показана на Фиг. 4. Когда пользователь Uj желает использовать устройство i, чтобы выполнить измерение, прежде чем иметь возможность управлять устройством, пользователь Uj выполняет DIDi<-ReadID(), показанное на этапе A1.1. После получения DIDi, Uj вызывает вспомогательные данные и получает там биометрические данные BMuj, этап А1.2. Затем выполняются Kuij<-RepBio(BMuj'||DIDi, Wuij) и восстанавливается Kuij, этап A1.3.

Пользовательские данные измеряются, и код аутентификации сообщения (MAC) вычисляется на данных с использованием Kuij, этап А.1.4. MAC может быть специализированным MAC или ключевой хэш-функцией. Данные и MAC посылаются провайдеру службы, этап А.1.5, вместе с идентификацией пользователя Uj (например, ID пользователя, адрес электронной почты и т.д.). Затем выполняется аутентификация пользователя и устройства, этап Al.6. Провайдер услуг осуществляет поиск в своей базе данных идентичности пользователя и проверяет MAC для всех ключей, зарегистрированных для этого пользователя. Если MAC успешно подтвержден для одного из этих ключей, данные принимаются и назначаются устройству, ключ которого был использован. В противном случае, данные отклоняются, и уведомление отсылается назад (опционально) к пользователю.

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

Альтернативный метод, использующий криптографию открытого ключа, второй вариант осуществления, показан на Фиг. 5. Система должна работать на той же основе, что группа пользователей U1, U2, U3,…, Un имеет устройство i, которое измеряет некоторый сигнал пользователей. Процедура регистрации второго варианта осуществления показана на левой стороне Фиг.5, а процедура аутентификации показана на правой стороне Фиг.5.

Если пользователь Uj использует устройство i впервые, то прежде, чем выполнять алгоритм GenBio, выполняется алгоритм ReadID таким образом, что DIDi<-ReadID(i), этап R2.1. Устройство этого пользователя выполняет вычисление для пользователя после инициализации или сигнала, указывающего, что вычисление должно быть выполнено. После получения DIDi получают BMuj (этап R2.2), и выполняется алгоритм GenBio на BMuj плюс DIDi, так что (Kuij, Wuij)<-GenBio(BMuj||DIDi). Здесь "||" может представлять простую конкатенацию или операцию xor над BMu и DIDi. Выход алгоритма GenBio представляет собой почти однородный ключ Kuij и вспомогательные данные Wuij, которые зависят как от биометрического измерения BMu, так и от глобального уникального ID устройства, DIDi. Это этап R2.3. Эти два этапа повторяются для каждого пользователя, который хочет использовать устройство. База данных сохранена в устройстве с записями в следующем виде: (Uj; Wuij), этап R2.4.

Вычисленный ключ Kuij зависит как от биометрических данных пользователя, так и от глобального ID устройства, и используется в качестве секретного ключа для пары пользователя j и устройства i. В зависимости от используемой криптосистемы открытого ключа, пользователь выполняет процесс генерации открытого ключа, который имеет в качестве входа секретный ключ Kuij и выводит открытый ключ Kuij_pub. Это этап R2.5.

Kuij_pub затем передается безопасным и аутентифицированным образом провайдеру службы здравоохранения, этап R2.6, вместе с ID устройства и идентичностью пользователя. Альтернативно, орган сертификации (или провайдер услуг) может создать сертификат открытого ключа для пользователя и его устройств в фазе регистрации (эти сертификаты будут содержать информацию идентичности пользователя, информацию идентичности устройства, открытый ключ для этой пары пользователя/устройства Kuij_pub и, возможно, другую информацию персональных данных, такую как возраст, адрес и т.д. Вся эта информация была бы тогда подписана секретным ключом органа сертификации. Если используется само-сертификация, то пользователь будет подписывать эти данные своим секретным ключом Kuij.

В процедуре аутентификации согласно варианту осуществления пользователь Uj желает использовать устройство i, чтобы выполнить измерение. Перед тем, как пользователь Uj сможет управлять устройством, пользователь Uj выполняет DIDi<-ReadID(), этап A2.1. После получения DIDi, Uj вызывает вспомогательные данные и получает биометрические данные BMuj, этап A2.2, и затем выполняет Kuij<-RepBio(BMuj'||DIDi,Wuij) и восстанавливает Kuij, этап A2.3. Сенсорные данные измеряются и снабжаются подписью с использованием Kuij, этап A2.4.

Данные и подпись посылают провайдеру услуг, вместе с сертификатом пользователя/устройства, содержащим открытый ключ Kuij_pub. Сертификат пользователя/устройства может посылаться только однократно и сохраняется в серверной системе. Это этап A2.5. Провайдер услуг выполняет поиск сертификата пользователя в своей базе данных и проверяет подпись. Если подпись верифицирована успешно, данные принимаются и назначаются паре «пользователь-устройство» или просто пользователю (так как мы заинтересованы в том, чтобы хранить пользовательские данные, если данные были правильно сгенерированы), ключ которого использовался. В противном случае, данные отклоняются, и уведомление отсылается назад к пользователю (опционально). Это этап A2.6.

В текущем варианте осуществления возможен альтернативный метод для объединенной аутентификации пользователя и устройства. Главная идея состоит в том, чтобы генерировать вспомогательные данные, основываясь на глобальном уникальном ID устройства - DID. Можно предположить, что каждое устройство имеет не модифицируемый глобальный уникальный ID (такой как МАС адрес и т.д.). Этот глобальный уникальный ID, конкатенированный с дополнительной новой случайной последовательностью, отображается на кодовое слово C, и вспомогательные данные для биометрических данных генерируются на основе кодового слова C. Эта альтернатива показана на Фиг. 6.

Предложенная процедура регистрации работала бы на основе группы пользователей, имеющих устройство i, которое измеряет некоторый сигнал пользователей U1, U2, U3,…, Un. На этапе R3.1 получают ID устройства-DIDi. Перед использованием устройства в первый раз пользователь Uj выполняет процедуру кодирования на ID устройства i и получает Ci<-кодировать(DIDi||γi), где "γi" является случайной последовательностью, и Ci-кодовое слово. Это этап R3.2. Случайная последовательность "γi" должна отличаться для каждого пользователя. Цель γi - сделать вспомогательные данные соответствующего размера для биометрических данных.

Пользователь Uj получает их биометрические данные, этап R3.3, и затем управляет процедурой GenHelperData(), чтобы генерировать вспомогательные данные. GenHelperData действует на кодовом слове "Ci", сгенерированном на этапе R3.2, и оцифрованном биометрическом измерении BMuj, чтобы генерировать (Kuij, Wuj, i)<-GenBio'(Ci, BMuj). Ci используется тогда как случайность, обычно используемая в генерации псевдо идентичности в биометрических системах. Это этап R3.4. Этот этап повторяется для каждого пользователя, который хочет использовать устройство. База данных сохраняется в устройстве с записями в следующем виде: (Uj; Wuj, i), этап R3.5. Значение Kuij посылается на сервер безопасным и аутентифицированным образом вместе с ID устройства DIDi и именем пользователя Uj, этап R3.6.

Процедура аутентификации по этой методологии также показана на Фиг. 6. Пользователь Uj желает использовать устройство i, чтобы выполнить измерение. Пользователь Uj считывает ID устройства как DIDi<-ReadID(), что является этапом A3.1. Пользователь Uj выполняет биометрическое измерение и восстанавливает вспомогательные данные, соответствующие ID устройства DIDi, из локальной базы данных, этап A3.2, и выполняет Kuij<-RepBio(BMuj', Wuj, i) и восстанавливает Kuij, этап A3.3. Во время процедуры RepBio кодовое слово Ci должно быть восстановлено. Таким образом, можно проверить, первая часть кодового слова Ci соответствует ли DIDi, этап A3.4. Если это не так, то процедура аутентификации могла бы быть прервана, или предупреждение послано пользователю.

Устройство i вычисляет код аутентификации сообщения (MAC) на данных, измеренных с секретным ключом Kuij, этап A3.5, и посылает данные и MAC провайдеру службы здравоохранения вместе с ID пользователя и (возможно) ID устройства, этап A3.6. Провайдер службы здравоохранения верифицирует MAC, извлекая ключ, соответствующий ID пользователя и устройства, и если верификация успешна, данные принимаются, этап A3.7. Те же самые процедуры регистрации и аутентификации могут быть легко изменены, как в первом варианте осуществления, чтобы использовать примитивы открытого ключа (подписи) вместо MAC.

Возможен более безопасный вариант. Вышеупомянутая процедура позволяет кому-либо получать частичную информацию о биометрии пользователя, если ID устройства DIDi становится известным. Чтобы избежать этого, можно выполнить следующее изменение, как показано на Фиг. 7.

В процедуре регистрации, как прежде, группа пользователей имеет устройство i, которое измеряет некоторый сигнал пользователей U1, U2, U3,…, Un. На этапе R4.1 получают ID устройства DIDi. Перед использованием устройства в первый раз, пользователь Uj выполняет процедуру кодирования на функции ID устройства i (эта функция может быть хэш-функцией, но также и поднабором битов, например, представляющих ID), словом, созданным для данного случая, и получает Ci<-кодировать(f(DIDi ||γi)), где "γi" является случайной последовательностью, и Ci - кодовое слово. Случайная последовательность "γi" должна отличаться для каждого пользователя. Назначение γi является двойным: (i) создание вспомогательных данных соответствующего размера для биометрических данных и (ii) создание Ci, непредсказуемого из знания ID устройства. Случайное созданное для данного случая слово γi должно поддерживаться в секрете. Функция f может быть любой функцией своих аргументов. Предпочтительно, это должна быть криптографически надежная односторонняя функция, такая как хэш-функция (SHA-1, SHA-2 и т.д.). Это этап R4.2.

Пользователь Uj получает свои биометрические данные, этап R4.3, и выполняет процедуру GenHelperData (), чтобы генерировать вспомогательные данные. GenHelperData работает на кодовом слове "Ci", сгенерированном на этапе 1 и преобразованном в цифровую форму биометрическом измерении, BMuj, следующим образом: (Kuij, Wuj,i)<-GenBio'(Ci, BMuj). Ci используется тогда как случайность, обычно используемая в генерации псевдо идентичности в биометрических системах. Это этап R4.3. Этот этап повторяется для каждого пользователя, который хочет использовать устройство. База данных сохраняется в устройстве с записями в следующем виде: (Uj; Wuj,i), этап R4.5.

Следующие значения затем посылаются в удаленную службу: (DIDi, γi, Uj) безопасным и аутентифицированным образом, как этап R4.6. Также возможно послать Kuij на сервер, хотя не обязательно. В некоторых ситуациях, посылка Kuij может привести к преимуществу в рабочих характеристиках для сервера, поскольку серверу не требуется вычислять новый ключ каждый раз, когда принимаются данные. Кроме того, выполнение этого препятствует утечке биометрического измерения пользователя. С другой стороны, посылка триплета (DIDi, γi, Uj) приводит к преимуществу по безопасности по двум причинам, во-первых, если атакующий временн