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

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

 

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

Настоящее изобретение относится к способу и системе для аутентификации устройства и пользователя. Изобретение может использоваться для обеспечения улучшенной аутентификации пациента для медицинского обслуживания с использованием идентификатора (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) приводит к преимуществу по безопасности по двум причинам, во-первых, если атакующий временно ставит под угрозу сервер, ключ Kuij не компрометируется, и, во-вторых, ключ вычисляется снова для каждого нового набора данных, что приводит к системе, более толерантной к ошибкам. Однако этот вариант имеет неудобство, состоящее в том, что биометрическая информация пользователя подвергается утечке, то есть этот метод не сохраняет конфиденциальность.

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

Устройство i вычисляет код аутентификации сообщения (MAC) на измеренных данных с секретным ключом Kuij, этап A4.4, и посылает данные и MAC провайдеру службы здравоохранения вместе с ID пользователя и ассоциированными вспомогательными данными Wuj,i, этап A4.5. Провайдер службы здравоохранения верифицирует MAC, повторно вычисляя ключ Kuij из (DIDi, γi, Uj) и вспомогательных данных Wuj,i, соответствующих ID пользователя и устройства, верифицирует MAC, и если верификация успешна, то данные принимаются. Это этап A4.6. Провайдер услуг узнает ID устройства посредством поиска ID, который соответствует вспомогательным данным Wuj,i, посланным пользователем в процедуре аутентификации. Если ключ Kuij уже был сохранен в базе данных сервера (как предложено в процедуре 4 регистрации), тогда не требуется повторно вычислить Kuij.

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

В этой процедуре регистрация и аутентификация показаны на Фиг. 8. Группа пользователей U1, U2, U3,…, Un имеет устройство i, которое измеряет некоторый сигнал пользователей. В этапе R5.1 считывается ID устройства DIDi. Пользователь Uj измеряет свои биометрические данные, этап R5.2, и формирует вспомогательные данные и ключ как (Kuj, Wuj)<-GenBio(BMuj), этап R5.3. Вспомогательные данные Wuj сохраняются везде, где будет иметь место восстановление биометрических данных, например, в домашнем концентраторе, который собирает все измерения от устройств и посылает их на сервер. Это этап R5.4.

Пользователь Uj посылает Kuj и DIDi, соответствующий ID устройства i на сервер, на этапе R5.5. Этап R5.3 повторяется для каждого пользователя, который хочет использовать устройство. Для каждого пользователя следующая информация посылается на сервер: (Kuj; DIDi, Uj). База данных сохраняется на сервере с записями следующим образом: (Kuj; DIDi, Uj), где Uj-идентификация пользователя.

Соответствующая процедура аутентификации показана на правой стороне Фиг. 8. Пользователь Uj желает использовать устройство i, чтобы выполнить измерение. На этапе A5.1 ID устройства DIDi считывается. Пользователь затем выполняет биометрическое измерение, а также получает сохраненные вспомогательные данные, на этапе A5.2. Прежде чем иметь возможность управлять устройством, пользователь Uj выполняет Kuj<-RepBio(BMuj, Wuj) и восстанавливает Kuj. ID устройства, DIdi, зашифровывается с использованием Kuj, чтобы генерировать yi<-EncKuj(DIDi) или любую функцию DIDi и Kuj в общем, которая не может быть инвертирована без знания Kuj. Это этап A5.3. Критерий необратимости важен, поскольку в большинстве случаев DIDi является общедоступным значением. Чтобы сделать его менее восприимчивым к атакам методом записи и повторной передачи блоков шифрованного текста, можно вычислить yi<-f(Kuj, DIDi, γi), где γi-случайное слово или счетчик для некоторой соответствующей функции f. Функция f может быть, например, подписью, хэш-функцией или функцией шифрования.

Устройство i затем вычисляет код аутентификации сообщения (MAC) на измеренных данных и зашифрованном yi с секретным ключом Kuj, этап A5.4, и посылает данные, yi и MAC провайдеру службы здравоохранения вместе с последовательностью, идентифицирующей пользователя Uj. Это этап A5.5. Может использоваться эквивалентный метод открытого ключа. Провайдер службы здравоохранения верифицирует MAC, дешифрует yi с помощью его знания Kuj и верифицирует, соответствует ли результат DIDi устройства в его базе данных, и если верификация успешна, то данные принимаются, на этапе A5.6.

Менее эффективный вариант также возможен. Также можно управлять аутентификацией устройства и пользователя, используя вычисленные вспомогательные данные. Это описано ниже в отношении Фиг 9. Процесс регистрации, левая сторона Фиг. 9, описывается сначала. Группа пользователей U1, U2, U3,…, Un имеют устройство i, которое измеряет некоторый сигнал пользователей. Сначала считывается ID устройства, этап R6.1. Пользователь Uj измеряет свои биометрические данные, этап R6.2, и генерирует вспомогательные данные и ключ как (Kuj, Wuj)<-GenBio(BMuj), этап R6.3. Вспомогательные данные Wuj сохраняются на этапе R6.4 везде, где будет иметь место восстановление биометрических данных, например, в домашнем концентраторе, который собирает все измерения с устройств и посылает их на сервер.

Следующий этап в регистрации-этап R6.5, на котором генерируется секрет и случайное значение Ki. Дополнительные вспомогательные данные Wi,uj генерируются следующим образом: Wi,uj=Ki+Kuj, где "+" обозначает операцию XOR над Ki и Kuj. Данные Wi,uj сохраняются в устройстве, выполняющем измерение, или в концентраторе. Эти этапы повторяются для каждого пользователя, который хочет использовать устройство. И для каждого пользователя следующая информация посылается на сервер: (f(Kuj, Ki, DIDi); DIDi, Uj), на этапе R6.6. Здесь f-некоторая функция Kuj и Ki (и, возможно, случайного слова или не повторяющего счетчика), как в предыдущих вариантах осуществления. База данных сохранена в сервере с записями следующим образом: (f(Kuj, Ki, DIDi); DIDi, Uj), где Uj-идентичность пользователя.

Соответствующая процедура аутентификации работает следующим образом. Пользователь Uj желает использовать устройство i, чтобы выполнить измерение, и получает ID устройства в этапе A6.1. Перед тем как иметь возможность управлять устройством, пользователь Uj получает свои биометрические данные, этап A6.2, и выполняет Kuj<-RepBio(BMuj, Wuj) и восстанавливает Kuj. Значение Ki восстанавливается путем вычисления Ki=Wi,uj+Kuj, что является этапом A6.3. Ключ Kuj,i выводится как Kuj,i<-f(Kuj, Ki, DIDi). Затем выполняются операции, как в предыдущих вариантах осуществления (вычисление MAC на данных, посылка данных и MAC на сервер и верификация на стороне сервера соответствующих значений), как детализировано на этапах A6.4-A6.6.

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

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

Предпочтительный вариант осуществления изобретения показан на Фиг. 10. На этом чертеже устройство 14, хостирующее приложение, домашний концентратор, связано с сенсорным устройством 10, а также с биометрическим измерительным прибором 26. Устройство 10 является устройством для измерения сенсорных данных 40 (в этом примере кровяного давления) пользователя 20, и биометрический измерительный прибор 26 является устройством для измерения отпечатка пальца пользователя 20, когда пользователь 20 помещает свой палец в устройство 26. Система на этом чертеже предполагает, что процесс регистрации уже имел место, и пользователь 20 выполнил измерение своего кровяного давления с помощью устройства 10. Пользователь 20 желает аутентифицировать полученные сенсорные данные 40 до посылки этих полученных данных 40 провайдеру службы здравоохранения третьей стороны.

Фиг. 10b иллюстрирует действия, выполняемые процессором 28, который является частью хостирующего устройства 14. Биометрическое измерение 30 отпечатка пальца пользователя принимается процессором 28 от биометрического измерительного прибора 26. ID 32 устройства также принимается по запросу, введенному в устройство 10. В системе присутствует компонент запроса, который запрашивает устройство 10. Этот компонент (не показан) может быть встроен в устройство 10. Биометрическое измерение 30 объединяется с вспомогательными данными 34 пользователя и в этом предпочтительном варианте осуществления также объединяется с ID 32 устройства, чтобы генерировать ключ 36, и ключ 36 затем используется, чтобы составить сообщение 38, которое включает в себя сенсорные данные 40, которые затем передаются в удаленную службу. Аутентификация пользователя 20 и устройства 10 затем выполняется, и на данные 40, содержащиеся в сообщении 38 можно полагаться, поскольку пользователь 20 и устройство 10 были надежно идентифицированы.

1. Способ для аутентификации воспринимающего устройства (10, 12) и пользователя (20) в системе, содержащей воспринимающее устройство (10, 12) для измерения данных для пользователя и удаленную службу (18), причем способ содержит:
регистрацию воспринимающего устройства (10, 12) и пользователя (20) в системе посредством:
получения ID (32) устройства для воспринимающего устройства (10, 12),
выполнения биометрического измерения (30) пользователя (20),
генерирования ключа (36) и вспомогательных данных (34) для пользователя (20) из биометрического измерения (30), причем вспомогательные данные предназначены для извлечения одного или более ключей из биометрических измерений,
сохранения вспомогательных данных (34),
передачи ID (32) устройства и идентификационных данных пользователя в удаленную службу (18), и
аутентификацию воспринимающего устройства (10, 12) и пользователя (20) посредством:
получения ID (32) устройства для устройства (10, 12),
выполнения биометрического измерения (30) пользователя (20),
извлечения вспомогательных данных (34) для пользователя (20),
генерирования ключа (36) из биометрического измерения (30) и извлеченных вспомогательных данных (34),
измерения данных (40) для пользователя (20),
генерирования сообщения (38), содержащего измеренные данные (40) и либо код аутентификации сообщения, выведенный из измеренных данных (40) и ключа (36), либо подпись для измеренных данных (40), выведенную из ключа (36),
передачи сообщения (38) в удаленную службу (18) и
в удаленной службе (18) аутентификации воспринимающего устройства (10, 12) и пользователя (20) с помощью сообщения (38) и ID (32) устройства и идентификационных данных пользователя, переданных во время этапа регистрации.

2. Способ по п.1, в котором:
этап генерирования ключа (36) и вспомогательных данных (34) для пользователя (20) из биометрического измерения (30) содержит генерирование ключа (36) и вспомогательных данных (34) для пользователя (20) из биометрического измерения (30) и ID (32) устройства;
этап сохранения вспомогательных данных (34) содержит сохранение вспомогательных данных (34) в устройстве (10, 12) вместе с идентификационными данными пользователя;
этап передачи ID (32) устройства и идентификационных данных пользователя в удаленную службу (18) дополнительно содержит передачу ключа (36) в удаленную службу (18); и
этап аутентификации устройства (10, 12) и пользователя (20) в удаленной службе (18) содержит аутентификацию устройства (10, 12) и пользователя (20) с помощью сообщения (38) и ID (32) устройства, идентификационных данных пользователя и ключа (36), переданных во время этапа регистрации.

3. Способ по п.2, в котором этап генерирования ключа (36) и вспомогательных данных (34) для пользователя (20) из биометрического измерения (30) и ID (32) устройства содержит генерирование кодового слова из ID (32) устройства и случайной строки и генерирование ключа (36) из кодового слова и биометрического измерения (30).

4. Способ по п.2 или 3, дополнительно содержащий включение в сообщение (38) ID (32) устройства и/или ID пользователя.

5. Способ по п.1, в котором:
регистрация устройства (10, 12) и пользователя (20) в системе дополнительно содержит этап генерирования кодового слова из ID (32) устройства и случайной строки;
этап генерирования ключа (36) и вспомогательных данных (34) для пользователя (20) из биометрического измерения (30) содержит генерирование ключа (36) и вспомогательных данных (34) для пользователя (20) из биометрического измерения (30) и кодового слова;
этап сохранения вспомогательных данных (34) содержит сохранение вспомогательных данных (34) в устройстве (10, 12) вместе с идентификационными данными пользователя;
этап передачи ID (32) устройства и идентификационных данных пользователя в удаленную службу (18) дополнительно содержит передачу случайной строки в удаленную службу (18); и
этап аутентификации устройства (10, 12) и пользователя (20) в удаленной службе (18) содержит аутентификацию устройства (10, 12) и пользователя (20) с помощью сообщения (38) и ID (32) устройства, идентификационных данных пользователя и случайной строки, переданных во время этапа регистрации.

6. Способ по п.1, в котором:
этап передачи ID (32) устройства и идентификационных данных пользователя в удаленную службу (18) дополнительно содержит передачу ключа (36) в удаленную службу (18);
аутентификация устройства (10, 12) и пользователя (20) с помощью удаленной службы (18) дополнительно содержит этап шифрования ID (32) устройства с использованием ключа (36);
сообщение, генерируемое на этапе генерирования, дополнительно содержит зашифрованный ID устройства; и
этап аутентификации устройства (10, 12) и пользователя (20) в удаленной службе (18) содержит аутентификацию устройства (10, 12) и пользователя (20) с помощью сообщения (38) и ID (32) устройства, идентификационных данных пользователя и ключа (36), переданных во время этапа регистрации.

7. Способ по п.1, в котором:
регистрация устройства (10, 12) и пользователя (20) в системе дополнительно содержит этапы генерирования случайного значения и генерирования дополнительных вспомогательных данных из случайного значения и ключа (36);
этап сохранения вспомогательных данных (34) дополнительно содержит сохранение дополнительных вспомогательных данных;
этап передачи ID (32) устройства и идентификационных данных пользователя в удаленную службу (18) дополнительно содержит передачу функции ключа (36), случайного значения и ID устройства в удаленную службу (18);
извлечение вспомогательных данных (34) дополнительно содержит извлечение дополнительных вспомогательных данных (34);
аутентификация устройства (10, 12) и пользователя (20) с помощью удаленной службы (18) дополнительно содержит этапы получения случайного значения из дополнительных вспомогательных данных и ключа (36) и генерирования дополнительного ключа из функции ключа, случайного значения и ID устройства;
код аутентификации сообщения, генерированный на этапе генерирования, выводят из измеренных данных (40) и дополнительного ключа; и
этап аутентификации устройства (10, 12) и пользователя (20) в удаленной службе (18) содержит аутентификацию устройства (10, 12) и пользователя (20) с помощью сообщения (38) и ID (32) устройства, идентификационных данных пользователя и функции ключа (36), случайного значения и ID устройства, переданных во время этапа регистрации.

8. Система аутентификации устройства (10, 12) и пользователя (20), содержащая:
устройство (26) измерения, скомпонованное для выполнения биометрического измерения (30) пользователя (20),
процессор (28),
воспринимающее устройство (10, 12) для измерения данных (40) для пользователя (20), причем воспринимающее устройство (10, 12) имеет ID устройства, сохраненный в нем, и
удаленную службу (18),
при этом во время процедуры для регистрации воспринимающего устройства (10, 12) и пользователя (20) с помощью удаленной службы (18) процессор (28) скомпонован для:
получения ID (32) устройства для воспринимающего устройства (10, 12) от воспринимающего устройства (10, 12);
получения биометрического измерения (30) пользователя (20) от устройства (26) измерения;
генерирования ключа (36) и вспомогательных данных (34) для пользователя (20) из биометрического измерения (30), причем вспомогательные данные предназначены для извлечения одного или более ключей из биометрических измерений;
сохранения вспомогательных данных (34);
передачи ID (32) устройства и идентификационных данных пользователя в удаленную службу (18);
и при этом во время процедуры для аутентификации воспринимающего устройства (10, 12) и пользователя (20) с помощью удаленной службы (18) процессор (28) скомпонован для:
получения ID (32) устройства для устройства (10, 12) от воспринимающего устройства (10, 12);
извлечения вспомогательных данных (34) для пользователя (20);
генерирования ключа (36) из биометрического измерения (30) и извлеченных вспомогательных данных (34);
генерирования сообщения (38), содержащего измеренные данные (40) и либо код аутентификации сообщения, выведенный из измеренных данных (40) и ключа (36), либо подпись для измеренных данных (40), выведенную из ключа (36); и
передачи сообщения (38) в удаленную службу (18);
при этом удаленная служба (18) скомпонована для аутентификации воспринимающего устройства (10, 12) и пользователя (20) с помощью сообщения (38) и ID (32) устройства и идентификационных данных пользователя, принятых во время процедуры регистрации.

9. Система по п.8, в которой процессор скомпонован для:
генерирования ключа (36) и вспомогательных данных (34) для пользователя (20) из биометрического измерения (30) и ID (32) устройства;
сохранения вспомогательных данных (34) в устройстве (10, 12) вместе с идентификационными данными пользователя;
передачи ключа (36) в удаленную службу (18) вместе с ID (32) устройства и идентификационными данными пользователя; и
при этом удаленная служба (18) скомпонована для аутентификации воспринимающего устройства (10, 12) и пользователя (20) с помощью сообщения (38) и ID (32) устройства, идентификационных данных пользователя и ключа (36), переданных во время процедуры для регистрации.

10. Система по п.9, в которой процессор (28) дополнительно скомпонован для генерирования ключа (36) и вспомогательных данных (34) для пользователя (20) из биометрического измерения (30) и ID (32) устройства посредством генерирования кодового слова из ID (32) устройства и случайной строки и генерирования ключа (36) из кодового слова и биометрического измерения (30).

11. Система по п.9 или 10, в которой процессор (28) дополнительно скомпонован для включения в сообщение (38) ID (32) устройства и/или ID пользователя.

12. Система по п.8, в которой:
во время процедуры для регистрации воспринимающего устройства (10, 12) и пользователя (20) в системе процессор дополнительно скомпонован для генерирования кодового слова из ID (32) устройства и случайной строки;
процессор скомпонован для генерирования ключа (36) и вспомогательных данных (34) для пользователя (20) из биометрического измерения (30) и кодового слова;
процессор скомпонован для сохранения вспомогательных данных (34) в устройстве (10, 12) вместе с идентификационными данными пользователя;
процессор скомпонован для передачи случайной строки в удаленную службу (18) вместе с ID (32) устройства и идентификационными данными пользователя; и
при этом удаленная служба (18) скомпонована для аутентификации воспринимающего устройства (10, 12) и пользователя (20) с помощью сообщения (38) и ID (32) устройства, идентификационных данных пользователя и случайной строки, переданных во время процедуры для регистрации.

13. Система по п.8, в которой:
процессор скомпонован для передачи ключа (36) в удаленную службу (18) вместе с ID (32) устройства и идентификационными данными пользователя;
во время процедуры для аутентификации воспринимающего устройства (10, 12) и пользователя (20) с помощью удаленной службы (18) процессор дополнительно скомпонован для шифрования ID (32) устройства с использованием ключа (36);
процессор скомпонован для генерирования сообщения, включающего в себя зашифрованный ID устройства; и
при этом удаленная служба (18) скомпонована для аутентификации воспринимающего устройства (10, 12) и пользователя (20) с помощью сообщения (38) и ID (32) устройства, идентификационных данных пользователя и ключа (36), переданных во время процедуры для регистрации.

14. Система по п.8, в которой:
во время процедуры для регистрации воспринимающего устройства (10, 12) и пользователя (20) в системе процессор дополнительно скомпонован для генерирования случайного значения и дополнительных вспомогательных данных из случайного значения и ключа (36);
процессор скомпонован для сохранения дополнительных вспомогательных данных;
процессор скомпонован для передачи функции ключа (36), случайного значения и ID устройства в удаленную службу (18) вместе с ID (32) устройства и идентификационными данными пользователя;
процессор скомпонован для извлечения дополнительных вспомогательных данных;
во время процедуры для аутентификации воспринимающего устройства (10, 12) и пользователя (20) с помощью удаленной службы (18) процессор дополнительно скомпонован для получения случайного значения из дополнительных вспомогательных данных и ключа (36) и генерирования дополнительного ключа из функции ключа, случайного значения и ID устройства;
процессор скомпонован для генерирования кода аутентификации сообщения из измеренных данных (40) и дополнительного ключа; и
при этом удаленная служба (18) скомпонована для аутентификации воспринимающего устройства (10, 12) и пользователя (20) с помощью сообщения (38) и ID (32) устройства, идентификационных данных пользователя и функции ключа (36), случайного значения и ID устройства, переданных во время процедуры для регистрации.