Windows Hello Windows Hello

В этой статье описывается новая технология Windows Hello, входящая в состав операционной системы Windows 10, и обсуждается, как разработчики могут реализовать эту технологию для защиты своих приложений универсальная платформа Windows (UWP) и серверных служб. This article describes the new Windows Hello technology that ships as part of the Windows 10 operating system and discusses how developers can implement this technology to protect their Universal Windows Platform (UWP) apps and backend services. Здесь рассматриваются определенные возможности этих технологий, помогающие снизить угрозы от использования стандартных учетных данных, и содержит рекомендации по разработке и развертыванию этих технологий в рамках внедрения Windows 10. It highlights specific capabilities of these technologies that help mitigate threats that arise from using conventional credentials and provides guidance about designing and deploying these technologies as part of a Windows 10 rollout.

Учтите, что эта статья посвящена разработке приложений. Note that this article focuses on app development. Дополнительные сведения об архитектуре и подробности реализации Windows Hello см. в разделе Руководство по Windows Hello на веб-сайте TechNet. For information on the architecture and implementation details of Windows Hello, see the Windows Hello Guide on TechNet.

Пошаговое руководство по созданию приложения UWP с использованием Windows Hello и фоновой службы проверки подлинности см. в статьях Приложение для входа с использованием Windows Hello и Служба входа Windows Hello. For a step-by-step walkthrough on creating a UWP app using Windows Hello and the backing authentication service, see the Windows Hello login app and Windows Hello login service articles.

1. Введение 1 Introduction

Что касается информационной безопасности, предполагается, что система способна определить, кто ее использует. A fundamental assumption about information security is that a system can identify who is using it. Идентификация пользователя позволяет системе решить, правильно ли пользователь идентифицировал себя (процесс называется проверкой подлинности), а затем решить, что прошедший проверку подлинности пользователь будет способен делать (авторизация). Identifying a user allows the system to decide whether the user is identified appropriately (a process known as authentication), and then decide what a properly authenticated user should be able to do (authorization). Подавляющее большинство компьютерных систем, развернутых по всему миру, полагается на учетные данные пользователя при принятии решений проверки подлинности и авторизации, что означает, что безопасность данных систем зависит от повторно используемых создаваемых пользователем паролей. The overwhelming majority of computer systems deployed throughout the world depend on user credentials for making authentication and authorization decisions, which means that these systems depend on reusable, user-created passwords as the basis for their security. Часто цитируемая формула, что при проверке подлинности используется «нечто, что вы знаете, имеете или чем вы являетесь», прекрасно описывает проблему: успешность проверки подлинности всецело зависит от повторно используемого пароля, и любой, кто знает этот пароль, может выдать себя за пользователя-владельца. The oft-cited maxim that authentication can involve «something you know, something you have, or something you are» neatly highlights the issue: a reusable password is an authentication factor all by itself, so anyone who knows the password can impersonate the user who owns it.

1.1. Проблемы с традиционными учетными данными 1.1 Problems with traditional credentials

Еще с середины 1960-х гг., когда Фернандо Корбато (Fernando Corbató) и его рабочая группа в Массачусетском технологическом институте отстояли внедрение паролей, пользователям и администраторам приходилось использовать пароли для проверки подлинности и авторизации. Ever since the mid-1960s, when Fernando Corbató and his team at the Massachusetts Institute of Technology championed the introduction of the password, users and administrators have had to deal with the use of passwords for user authentication and authorization. Со временем технологии хранения и использования паролей несколько продвинулись вперед (например, с помощью безопасного хэширования и отложения), но мы по-прежнему сталкиваемся с двумя проблемами. Over time, the state of the art for password storage and use has advanced somewhat (with secure hashing and salting, for example), but we are still faced with two problems. Пароли легко клонируются и их несложно украсть. Passwords are easy to clone and they are easy to steal. Кроме того, ошибки реализации могут делать их незащищенными, и пользователям все время приходится с трудом балансировать между удобством и безопасностью. In addition, implementation faults may render them insecure, and users have a hard time balancing convenience and security.

1.1.1. Похищение учетных данных 1.1.1 Credential theft

Самый большой риск с паролями прост: злоумышленник может легко украсть пароль. The biggest risk of passwords is simple: an attacker can steal them easily. Уязвимо любое место, где пароль вводится, обрабатывается или хранится. Every place a password is entered, processed, or stored is vulnerable. Например, злоумышленник может украсть коллекцию паролей или хэши с сервера проверки подлинности путем перехвата сетевого трафика на сервер приложений, внедряя вредоносные программы в приложение или на устройство, регистрируя нажатие клавиш или кнопок на устройстве, подсматривая вводимые пользователем символы. For example, an attacker can steal a collection of passwords or hashes from an authentication server by eavesdropping on network traffic to an application server, by implanting malware in an application or on a device, by logging user keystrokes on a device, or by watching to see which characters a user types. Это только наиболее распространенные методы атак. These are just the most common attack methods.

Другой связанный с этим риск — воспроизведение учетных данных, когда злоумышленник перехватывает учетные данные в незащищенной сети и воспроизводит их позднее, чтобы представиться допустимым пользователем. Another related risk is that of credential replay, in which an attacker captures a valid credential by eavesdropping on an insecure network, and then replays it later to impersonate a valid user. Большинство протоколов проверки подлинности (в том числе Kerberos и OAuth) защищают от атак с воспроизведением, добавляя отметку времени в процедуру обмена учетными данными, но эта тактика защищает только маркер, выдаваемый системой проверки подлинности, но не пароль, который пользователь в первую очередь предоставляет для получения маркера. Most authentication protocols (including Kerberos and OAuth) protect against replay attacks by including a time stamp in the credential exchange process, but that tactic only protects the token that the authentication system issues, not the password that the user provides to get the ticket in the first place.

1.1.2. Повторное использование учетных данных 1.1.2 Credential reuse

Общепринятая практика использования электронного адреса в качестве имени пользователя только усугубляет проблему. The common approach of using an email address as the username makes a bad problem worse. Злоумышленник, который успешно извлек пару «имя пользователя-пароль» из уязвимой системы, может попытаться подставить эту пару в других системах. An attacker who successfully recovers a username–password pair from a compromised system can then try that same pair on other systems. Этот прием срабатывает на удивление во многих случаях, что позволяет злоумышленникам переходить из пораженной системы в другие системы. This tactic works surprisingly often to allow attackers to springboard from a compromised system into other systems. Использование адреса электронной почты в качестве имени пользователя может приводить к другим проблемам, которые будут рассмотрены далее в этом руководстве. The use of email addresses as usernames leads to additional problems that we will explore later in this guide.

1.2. Устранение неполадок с учетными данными 1.2 Solving credential problems

Решить проблему, создаваемую паролями, непросто. Solving the problems that passwords pose is tricky. Ее не решить лишь более строгой политикой паролей: пользователь всегда может просто сбросить пароль, сообщить его кому-то или где-то записать. Tightening password policies alone will not do it; users may just recycle, share, or write down passwords. Хотя обучение пользователей чрезвычайно важно для безопасности проверки подлинности, само по себе оно не устраняет проблему. Although user education is critical for authentication security, education alone does not eliminate the problem either.

Windows Hello заменяет пароли надежной двухфакторной проверкой подлинности (2FA) путем проверки имеющихся учетных данных и создания учетных данных для каждого конкретного устройства, защищаемых пользовательским жестом (биометрическим или на основе PIN-кода). Windows Hello replaces passwords with strong two-factor authentication (2FA) by verifying existing credentials and by creating a device-specific credential that a biometric or PIN-based user gesture protects.

2. Что такое Windows Hello? 2 What is Windows Hello?

Windows Hello — это название, которое корпорация Майкрософт дала новому биометрическому входу в систему, встроенному в Windows 10. Windows Hello is the name Microsoft has given to the new biometric sign-in system built into Windows 10. Функция напрямую встроена в операционную систему, поэтому Windows Hello позволяет разблокировать пользовательские устройства с помощью идентификации лиц или отпечатков пальцев. Because it is built directly into the operating system, Windows Hello allows face or fingerprint identification to unlock users’ devices. Проверка подлинности происходит, когда пользователь предоставляет свой биометрический идентификатор для доступа к учетным записям на данном устройстве, то есть злоумышленник, похитивший устройство, не сможет выполнить вход, если ему неизвестен PIN-код. Authentication happens when the user supplies his or her unique biometric identifier to access the device-specific credentials, which means that an attacker who steals the device can’t log on to it unless that attacker has the PIN. Защищенное хранилище учетных данных Windows защищает биометрические данные на устройстве. The Windows secure credential store protects biometric data on the device. Разблокируя устройство с помощью Windows Hello, авторизованный пользователь получает доступ ко всем функциям, приложениям, данным, веб-сайтам и службам Windows. By using Windows Hello to unlock a device, the authorized user gains access to all of his or her Windows experience, apps, data, websites, and services.

Проверка подлинности Windows Hello известна также как Hello. The Windows Hello authenticator is known as a Hello. Функция Hello уникальна для сочетания отдельного устройства и конкретного пользователя. A Hello is unique to the combination of an individual device and a specific user. Она не перемещается между устройствами, не используется совместно с сервером или вызывающим приложением, и ее невозможно легко извлечь из устройства. It does not roam across devices, is not shared with a server or calling app, and cannot easily be extracted from a device. Если устройство совместно используется несколькими пользователями, каждый пользователь должен настроить свою учетную запись. If multiple users share a device, each user needs to set up his or her own account. Каждая учетная запись получает уникальный идентификатор Hello для этого устройства. Every account gets a unique Hello for that device. Hello можно считать маркером, который можно использовать для разблокировки (или выпуска) сохраненных учетных данных. You can think of a Hello as a token you can use to unlock (or release) a stored credential. Идентификатор Hello сам по себе не выполняет проверку вашей подлинности в приложении или службе, но он выдает учетные данные, которые могут это сделать. The Hello itself does not authenticate you to an app or service, but it releases credentials that can. Другими словами, Hello не является учетными данными пользователя, но является вторым фактором процесса аутентификации. In other words, the Hello is not a user credential but it is a second factor for the authenticating process.

2.1 Проверка подлинности Windows Hello 2.1 Windows Hello authentication

В Windows Hello реализован надежный способ распознавания отдельного пользователя устройством. Так проходится первая половина пути между пользователем и запрошенной услугой или элементом данных. Windows Hello provides a robust way for a device to recognize an individual user, which addresses the first part of the path between a user and a requested service or data item. После того как пользователь распознан устройством, необходимо по-прежнему выполнить для него проверку подлинности, прежде чем предоставлять этому пользователю доступ к ресурсу. After the device has recognized the user, it still must authenticate the user before determining whether to grant access to a requested resource. В Windows Hello реализована полностью интегрированная в Windows надежная двухфакторная проверка подлинности, которая заменяет повторно используемые пароли сочетанием конкретного устройства и биометрического жеста или PIN-кода. Windows Hello provides strong 2FA that is fully integrated into Windows and replaces reusable passwords with the combination of a specific device, and a biometric gesture or PIN.

Однако Windows Hello — это не просто замена традиционных систем двухфакторной проверки подлинности. Windows Hello is not just a replacement for traditional 2FA systems, though. Эта система в принципе аналогична смарт-картам: проверка подлинности выполняется с использованием криптографических примитивов вместо сравнения строк, а материал ключа пользователя надежно хранится внутри устойчивого к взлому оборудования. It is conceptually similar to smart cards: authentication is performed by using cryptographic primitives instead of string comparisons, and the user’s key material is secure inside tamper-resistant hardware. Windows Hello также не требует дополнительных инфраструктурных компонентов для развертывания. Windows Hello does not require the extra infrastructure components required for smart card deployment, either. В частности, вам не нужна инфраструктура открытых ключей (PKI) для управления сертификатами, если ее у вас нет. In particular, you do not need a Public Key Infrastructure (PKI) to manage certificates, if you do not currently have one. Windows Hello сочетает в себе основные достоинства технологии смарт-карт — гибкость в развертывании виртуальных смарт-карт и высокую безопасность физических, однако без присущих им недостатков. Windows Hello combines the major advantages of smart cards—deployment flexibility for virtual smart cards and robust security for physical smart cards—without any of their drawbacks.

2.2. Как работает Windows Hello 2.2 How Windows Hello works

После того как пользователь настроит Windows Hello на компьютере, функция создаст новую пару из открытого и закрытого ключей на устройстве. When the user sets up Windows Hello on his or her machine, it generates a new public–private key pair on the device. Доверенный платформенный модуль (TPM) создает и защищает этот закрытый ключ. The trusted platform module (TPM) generates and protects this private key. Если на устройстве нет микросхемы TPM, закрытый ключ шифруется и защищается программным обеспечением. If the device does not have a TPM chip, the private key is encrypted and protected by software. Кроме того, устройство с поддержкой TPM создает блок данных, который можно использовать, чтобы убедиться, что ключ привязан к TPM. In addition TPM-enabled devices generate a block of data that can be used to attest that a key is bound to TPM. Эти данные аттестации можно использовать в вашем решении, чтобы решить, например, предоставить ли пользователю другой уровень авторизации. This attestation information can be used in your solution to decide if the user is granted a different authorization level for example.

Чтобы включить Windows Hello на устройстве, пользователю необходимо иметь учетную запись Azure Active Directory или учетную запись Майкрософт, подключенную в параметрах Windows. To enable Windows Hello on a device, the user must have either their Azure Active Directory account or Microsoft Account connected in Windows settings.

2.2.1 Принципы защиты ключей 2.2.1 How keys are protected

Каждый раз при формировании материала ключа его необходимо защищать от атак. Any time key material is generated, it must be protected against attack. Самым надежным способом обеспечения такой защиты является использование специализированного оборудования. The most robust way to do this is through specialized hardware. У использования аппаратных модулей безопасности для создания, хранения и обработки ключей для приложений, безопасность которых имеет важнейшее значение, длительная история. There is a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Смарт-карты представляют собой особый тип аппаратных модулей безопасности, как и устройства, совместимые со стандартом TPM организации TCG. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. При любой возможности реализация Windows Hello пользуется для создания, хранения и обработки ключей имеющимся оборудованием TPM. Wherever possible, the Windows Hello implementation takes advantage of onboard TPM hardware to generate, store, and process keys. Тем не менее функции Windows Hello и Windows Hello for Work не требуют наличия оборудования TPM. However, Windows Hello and Windows Hello for Work do not require an onboard TPM.

Майкрософт рекомендует всегда использовать оборудование TPM. Whenever feasible, Microsoft recommends the use of TPM hardware. TPM защищает от множества известных и потенциальных атак, в том числе атак методом подбора ПИН-кода. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. Кроме того, TPM обеспечивает дополнительный уровень защиты после блокировки учетной записи. The TPM provides an additional layer of protection after an account lockout as well. После того, как TPM заблокирует материал ключа, пользователю будет необходимо сбросить PIN-код. When the TPM has locked the key material, the user must reset the PIN. Сброс PIN-кода означает, что все ключи и сертификаты, зашифрованные с использованием материала старого ключа, будут удалены. Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed.

2.2.2 Проверка подлинности 2.2.2 Authentication

Если пользователь хочет получить доступ к материалу защищенного ключа, процесс проверки подлинности начинается с ввода пользователем PIN-кода или биометрического жеста для разблокировки устройства. Этот процесс иногда называют «освобождением ключа». When a user wants to access protected key material, the authentication process begins with the user entering a PIN or biometric gesture to unlock the device, a process sometimes called «releasing the key».

Приложение не может использовать ключи из другого приложения, а кто-либо не может применять ключи другого пользователя. An application can never use the keys from another application, nor can someone ever use the keys from another user. Эти ключи используются для подписания запросов, отправляемых поставщику удостоверений или IDP для получения доступа к определенным ресурсам. These keys are used to sign requests that are sent to the identity provider or IDP, seeking access to specified resources. Приложения могут использовать определенные API для запроса операций, которым требуется материал ключа для определенных действий. Applications can use specific APIs to request operations that require key material for particular actions. Для доступа через эти API-интерфейсы требуется явная проверка с помощью жеста пользователя, а материал ключа не предоставляется запрашивающему приложению. Access through these APIs does require explicit validation through a user gesture, and the key material is not exposed to the requesting application. Вместо этого приложение запрашивает указанное действие (например, подписать фрагмент данных), а уровень Windows Hello выполняет саму работу и возвращает результаты. Rather, the application asks for a specific action like signing a piece of data, and the Windows Hello layer handles the actual work and returns the results.

2.3 Подготовка к реализации Windows Hello 2.3 Getting ready to implement Windows Hello

Теперь, когда мы имеем общее представление о работе Windows Hello, рассмотрим, как реализовать функцию в собственных приложениях. Now that we have a basic understanding of how Windows Hello works, let us take a look at how to implement them in our own applications.

Существуют различные сценарии, которые можно реализовать с помощью Windows Hello. There are different scenarios we can implement using Windows Hello. Например, просто вход в ваше приложение на устройстве. For example, just logging on to your app on a device. Другим часто используемым сценарием будет проверка подлинности в службе. The other common scenario would be to authenticate against a service. Вместо использования имени и пароля для входа используется Windows Hello. Instead of using a logon name and password, you will be using Windows Hello. В следующих главах мы обсудим реализацию нескольких различных сценариев, в том числе проверку подлинности в службах с помощью Windows Hello и способы перехода от существующей системы имени пользователя и пароля для входа к системе Windows Hello. In the following chapters, we will discuss implementing a couple of different scenarios, including how to authenticate against your services with Windows Hello, and how to convert from an existing username/password system to a Windows Hello system.

3. Реализация Windows Hello 3 Implementing Windows Hello

В этой главе мы начинаем с исходного сценария с несуществующей системой проверки подлинности, и рассмотрим, как реализовать Windows Hello. In this chapter, we begin with a greenfield scenario with no existing authentication system, and we explain how to implement Windows Hello.

В следующем разделе описано, как перейти от существующей системы с именем пользователя и паролем. The next section covers how to migrate from an existing username/password system. Но даже если эта глава вам более интересна, вы можете просмотреть с этой главой, чтобы получить базовое понимание процесса и требуемого кода. However, even if that chapter interests you more, you may want to look through this one to get a basic understanding of the process and the code required.

3.1 Регистрация новых пользователей 3.1 Enrolling new users

Начнем с совершенно новой службы, которая будет использовать Windows Hello, и выдуманного пользователя, который готов зарегистрироваться на новом устройстве. We begin with a brand new service that will use Windows Hello, and a hypothetical new user who is ready to sign up on a new device.

Сначала необходимо убедиться, что пользователь может использовать Windows Hello. The first step is to verify that the user is able to use Windows Hello. Приложение проверяет параметры пользователя и возможности компьютера, чтобы убедиться в возможности создания ключей идентификации пользователя. The app verifies user settings and machine capabilities to make sure it can create user ID keys. Если приложение определит, что пользователь еще не включил Windows Hello, оно предложит пользователю настроить его перед использованием приложения. If the app determines the user has not yet enabled Windows Hello, it prompts the user to set this up before using the app.

Чтобы включить Windows Hello, пользователю необходимо просто настроить PIN-код в параметрах Windows, если он этого не сделал при первом включении компьютера. To enable Windows Hello, the user just needs to set up a PIN in Windows settings, unless the user set it up during the Out of Box Experience (OOBE).

Следующие строки кода показывают простой способ проверить, настроен ли пользователь в службе Windows Hello. The following lines of code show a simple way to check if the user is set up for Windows Hello.

Следующим шагом является запрос у пользователя данных для регистрации в службе. The next step is to ask the user for information to sign up with your service. Можно запросить у пользователя имя, фамилию, адрес электронной почты и уникальное имя пользователя. You may choose to ask the user for first name, last name, email address, and a unique username. Вы можете использовать адрес электронной почты в качестве уникального идентификатора. Выбор за вами. You could use the email address as the unique identifier; it is up to you.

В этом сценарии мы используем адрес электронной почты в качестве уникального идентификатора пользователя. In this scenario, we use the email address as the unique identifier for the user. После регистрации пользователя необходимо отправить проверочное сообщение, чтобы убедиться в действительности адреса. Once the user signs up, you should consider sending a validation email to ensure the address is valid. Таким способом предоставляется механизм для сброса учетной записи в случае необходимости. This gives you a mechanism to reset the account if necessary.

Если пользователь задал PIN-код, приложение создаст KeyCredential пользователя. If the user has set up his or her PIN, the app creates the user’s KeyCredential. Приложение также получает дополнительные сведения об аттестации ключа для получения криптографического подтверждения, что данный ключ создан в модуле TPM. The app also gets the optional key attestation information to acquire cryptographic proof that the key is generated on the TPM. Созданный открытый ключ и, при необходимости, аттестация, отправляются на внутренний сервер для регистрации используемого устройства. The generated public key, and optionally the attestation, is sent to the backend server to register the device being used. Каждая пара ключей, создаваемая на каждом устройстве, будет уникальной. Every key pair generated on every device will be unique.

Код для создания KeyCredential выглядит следующим образом. The code to create the KeyCredential looks like this:

Метод RequestCreateAsync — это часть, которая создает открытый и закрытый ключи. The RequestCreateAsync is the part that creates the public and private key. Если устройство оснащено правильной микросхемой TPM, API-интерфейсы отправят запрос TPM на создание открытого и закрытого ключа и сохранят результат. Если микросхема TPM недоступна, операционная система создает пару ключей в коде. If the device has the right TPM chip, the APIs will request the TPM chip to create the private and public key and store the result; if there is no TPM chip available, the OS will create the key pair in code. Для приложения отсутствует способ получить доступ к созданным закрытым ключам напрямую. There is no way for the app to access the created private keys directly. Частью создания пар ключей также является итоговые сведения аттестации. Part of the creation of the key pairs is also the resulting Attestation information. (Дополнительные сведения об аттестации см. в следующем разделе.) (See the next section for more information about attestation.)

После создания пары ключей и данных аттестации на устройстве, открытый ключ, дополнительные данные аттестации и уникальный идентификатор (например, адрес электронной почты) должны быть отправлены во внутреннюю службу регистрации и сохранены на внутреннем сервере. After the key pair and attestation information are created on the device, the public key, the optional attestation information, and the unique identifier (such as the email address) need to be sent to the backend registration service and stored in the backend.

Чтобы позволить пользователю получать доступ к приложению на нескольких устройствах, внутренней службе понадобится сохранить несколько ключей для одного пользователя. To allow the user to access the app on multiple devices, the backend service needs to be able to store multiple keys for the same user. Поскольку каждый ключ уникален для каждого устройства, мы сохраним все эти ключи подключенными к одному пользователю. Because every key is unique for every device, we will store all these keys connected to the same user. Идентификатор устройств используется, чтобы помочь оптимизировать серверную часть при проверке подлинности пользователей. A device identifier is used to help optimize the server part when authenticating users. Мы поговорим об этом подробнее в следующей главе. We talk about this in more detail in the next chapter.

Пример схемы базы данных для хранения этих сведений на внутреннем сервере выглядит так: A sample database schema to store this information at the backend might look like this:

Логика регистрации может выглядеть следующим образом: The registration logic might look like this:

В собираемых вами сведениях о регистрации может содержаться значительно больше идентифицирующих данных, чем мы включили в этот простой сценарий. The registration information you collect may of course include a lot more identifying information than we include in this simple scenario. Например, если ваше приложение получает доступ к защищенной службе, в частности для банковских операций, вам необходимо будет запросить подтверждение личности и другие данные в контексте процесса регистрации. For example, if your app accesses a secured service such as one for banking, you would need to request proof of identity and other things as part of the sign-up process. После выполнения всех условий, открытый ключ этого пользователя будет сохранен на внутреннем сервере и будет использоваться для проверки в следующий раз, когда пользователь будет использовать данную службу. Once all the conditions are met, the public key of this user will be stored in the backend and used to validate the next time the user uses the service.

3.1.1 Аттестация 3.1.1 Attestation

При создании пары ключей также существует возможность запросить данные аттестации, которые создаются микросхемой TPM. When creating the key pair, there is also an option to request the attestation information, which is generated by the TPM chip. Эти необязательное сведения можно отправить на сервер в рамках процесса входа. This optional information can be sent to the server as part of the sign-up process. Аттестация ключа TPM — это протокол, который криптографически доказывает, что ключ связан с TPM. TPM key attestation is a protocol that cryptographically proves that a key is TPM-bound. Этот тип аттестации можно использовать, чтобы гарантировать, что определенная криптографическая операция произошла в TPM конкретного компьютера. This type of attestation can be used to guarantee that a certain cryptographic operation occurred in the TPM of a particular computer.

Когда сервер получает созданный ключ RSA, оператор аттестации и сертификат AIK, он проверяет перечисленные ниже условия. When it receives the generated RSA key, the attestation statement, and the AIK certificate, the server verifies the following conditions:

• Подпись сертификата AIK действительна. The AIK certificate signature is valid.
• Сертификат AIK восходит по цепочке к доверенному корню. The AIK certificate chains up to a trusted root.
• Сертификат AIK и его цепочка включены для идентификатора объекта по умолчанию для «EKU 2.23.133.8 .3» (понятное имя «Сертификат ключа удостоверения подлинности»). The AIK certificate and its chain is enabled for EKU OID «2.23.133.8.3» (friendly name is «Attestation Identity Key Certificate»).
• В сертификате AIK указано верное время. The AIK certificate is time valid.
• Все выдаваемые сертификаты ЦС в цепочке действительны в данный период времени и не отозваны. All issuing CA certificates in the chain are time-valid and not revoked.
• Оператор аттестации сформирован правильно. The attestation statement is formed correctly.
• Подпись на большом двоичном объекте KeyAttestation использует открытый ключ AIK. The signature on KeyAttestation blob uses an AIK public key.
• Открытый ключ, включенный в большой двоичный объект KeyAttestation, соответствует открытому ключу RSA, который клиент отправил наряду с оператором аттестации. The public key included in the KeyAttestation blob matches the public RSA key that client sent alongside the attestation statement.

В зависимости от этих условий, ваше приложение может назначить пользователю другой уровень авторизации. Your app might assign the user a different authorization level, depending on these conditions. Например, если одна из этих проверок заканчивается неудачей, оно может не регистрировать пользователя или ограничивать действия пользователя. For instance, if one of these checks fail, it might not enroll the user or it might limit what the user can do.

3.2 Выполнение входа с помощью Windows Hello 3.2 Logging on with Windows Hello

После регистрации пользователя в системе он может использовать приложение. Once the user is enrolled in your system, he or she can use the app. В зависимости от сценария можно попросить пользователей выполнить проверку подлинности перед тем, как они смогут начать использование приложения или просто попросить их пройти проверку подлинности когда они начинают использовать ваши внутренние службы. Depending on the scenario, you can ask users to authenticate before they can start using the app or just ask them to authenticate once they start using your backend services.

3.3 Принудительный повторный вход 3.3 Force the user to sign in again

Для некоторых сценариев, возможно, пользователю необходимо будет доказать, что он является человеком, который в данный момент вошел в систему, прежде чем получать доступ к приложению, а иногда — перед выполнением определенного действия внутри приложения. For some scenarios, you may want the user to prove he or she is the person who is currently signed in, before accessing the app or sometimes before performing a certain action inside of your app. Например, прежде чем приложение для банковских операций отправит серверу команду на перевод денег, необходимо убедиться, что запрос отправлен пользователем, а не лицом, нашедшим подключенное устройство и пытающимся выполнить транзакцию. For example, before a banking app sends the transfer money command to the server, you want to make sure it is the user, rather than someone who found a logged-in device, attempting to perform a transaction. Можно принудить пользователя выполнить вход в приложение еще раз, используя класс UserConsentVerifier. You can force the user to sign in again in your app by using the UserConsentVerifier class. Следующая строка кода заставит пользователя ввести свои учетные данные. The following line of code will force the user to enter their credentials.

Следующая строка кода заставит пользователя ввести свои учетные данные. The following line of code will force the user to enter their credentials.

Конечно, вы можете также использовать механизм ответа на запрос от сервера, который требует, чтобы пользователь ввел свой PIN-код или биометрические учетные данные. Of course, you can also use the challenge response mechanism from the server, which requires a user to enter his or her PIN code or biometric credentials. Это зависит от сценария, который вам, как разработчику, необходимо реализовать. It depends on the scenario you as a developer need to implement. Описание данного механизма приведено в следующем разделе. This mechanism is described in the following section.

3.4 Проверка подлинности на внутреннем сервере 3.4 Authentication at the backend

Если приложение пытается получить доступ к защищенной внутренней службе, данная служба отправляет запрос приложению. When the app attempts to access a protected backend service, the service sends a challenge to the app. Данное приложение использует закрытый ключ от пользователя, чтобы подписать запрос, и отправляет его обратно серверу. The app uses the private key from the user to sign the challenge and sends it back to the server. Так как сервер содержит сохраненный открытый ключ для этого пользователя, он использует стандартные API шифрования, чтобы убедиться, что сообщение действительно было подписано правильным закрытым ключом. Since the server has stored the public key for that user, it uses standard crypto APIs to make sure the message was indeed signed with the correct private key. На клиенте вход выполняется с помощью API Windows Hello. У разработчика никогда не будет доступа к закрытому ключу пользователя. On the client, the signing is done by the Windows Hello APIs; the developer will never have access to any user’s private key.

Кроме проверки ключей служба может также проверять аттестацию ключей и различать, есть ли ограничения, наложенные на то, как ключи хранятся на устройстве. In addition to checking the keys, the service can also check the key attestation and discern if there are any limitations invoked on how the keys are stored on the device. Например, если устройство использует TPM для защиты ключей, это будет более безопасно, чем устройства, хранящие ключи без TPM. For example, when the device uses TPM to protect the keys, it is more secure than devices storing the keys without TPM. Логика внутреннего сервера для уменьшения рисков может решить, например, что пользователю разрешено только переводить определенную сумму денег, если не используется TPM. The backend logic could decide, for example, that the user is only allowed to transfer a certain amount of money when no TPM is used to reduce the risks.

Аттестация доступна только для устройств с микросхемой TPM версии 2.0 или более поздних версий. Attestation is only available for devices with a TPM chip that’s version 2.0 or higher. Поэтому вам необходимо учитывать то, что эти сведения могут быть доступны не на каждом устройстве. Therefore, you need to take into account that this information might not be available on every device.

Рабочий процесс клиента может выглядеть, как показано на следующей схеме. The client workflow might look like the following chart:

Сервер отправляет задачу, когда приложение вызывает службу на внутреннем сервере. When the app calls the service on the backend, the server sends a challenge. Задача подписывается с помощью следующего кода: The challenge is signed with the following code:

Первая строка, KeyCredentialManager.OpenAsync, отправит запрос операционной системе на открытие дескриптора ключа. The first line, KeyCredentialManager.OpenAsync, will ask the OS to open the key handle. Если он будет выполнен успешно, вы сможете подписать сообщение запроса с помощью метода KeyCredential.RequestSignAsync, который заставит операционную систему запросить PIN-код или биометрические данные пользователя с помощью Windows Hello. If that is done successfully, you can sign the challenge message with the KeyCredential.RequestSignAsync method will trigger the OS to request the user’s PIN or biometrics through Windows Hello. Ни в один момент времени у разработчика не будет доступа к закрытому ключу пользователя. At no time will the developer have access to the private key of the user. Они все защищаются с помощью API. This is all kept secure through the APIs.

API отправляют запрос операционной системе на подпись задачи с помощью закрытого ключа. The APIs request the OS to sign the challenge with the private key. Затем система просит пользователя ввести PIN-код или выполнить настроенный биометрический вход. The system then asks the user for a PIN code or a configured biometric logon. После ввода правильных сведений система может запросить у микросхемы TPM выполнить криптографические функции и подписать задачу. When the correct information is entered, the system can ask the TPM chip to perform the cryptographic functions and sign the challenge. (Или использовать программное решение резервирования, если TPM недоступен). (Or use the fallback software solution, if no TPM is available). Клиенту необходимо отправить подписанную задачу обратно на сервер. The client must send the signed challenge back to the server.

Базовый поток ответа на запрос показан в данной схеме последовательности: A basic challenge–response flow is shown in this sequence diagram:

Далее сервер должен проверить подпись. Next, the server must validate the signature. Когда вы запрашиваете открытый ключ и отправляете его на сервер, чтобы использовать его для будущей проверки, он находится в Публиккэйинфоном BLOB-объекте ASN. 1. When you request the public key and send it to the server to use for future validation, it is in an ASN.1-encoded publicKeyInfo blob. Если взглянуть на пример кода Windows Hello на GitHub, вы увидите, что существуют вспомогательные классы для упаковки функций crypt32 для преобразования большого двоичного объекта ASN. 1 в кодировке CNG в большой двоичный объект, который чаще всего используется. If you look at the Windows Hello code sample on GitHub, you will see that there are helper classes to wrap Crypt32 functions to translate the ASN.1-encoded blob to a CNG blob, which is more commonly used. Большой двоичный объект содержит алгоритм открытого ключа, который является RSA, и открытый ключ RSA. The blob contains the public key algorithm, which is RSA, and the RSA public key.

В примере причина преобразования большого двоичного объекта в кодировке ASN. 1 в BLOB-объект CNG заключается в том, что его можно использовать с CNG (/Виндовс/десктоп/секкнг/КНГ-портал) и API BCrypt. In the sample, the reason we convert the ASN.1-encoded blob to a CNG blob is so that it can be used with CNG (/windows/desktop/SecCNG/cng-portal) and the BCrypt API. При поиске большого двоичного объекта CNG он указывает на связанную структуру BCRYPT_KEY_BLOB. If you look up the CNG blob, it will point you to the related BCRYPT_KEY_BLOB structure. Эта поверхность API может использоваться для проверки подлинности и шифрования в приложениях Windows. This API surface can be used for authentication and encryption in Windows applications. ASN. 1 — это документированный стандарт для взаимодействия структур данных, которые могут быть сериализованы и обычно используются в криптографии с открытым ключом и с сертификатами. ASN.1 is a documented standard for communicating data structures that can be serialized, and it’s commonly used in public key cryptography and with certificates. Именно поэтому сведения об открытом ключе возвращаются таким образом. That’s why the public key information is returned in this manner. Открытый ключ — это ключ RSA; и это алгоритм, который Windows Hello использует при подписывании данных. The public key is an RSA key; and that’s the algorithm that Windows Hello uses when it signs data.

После получения большого двоичного объекта CNG необходимо проверить подписанную задачу с помощью открытого ключа пользователя. Once you have the CNG blob, you need to validate the signed challenge against the public key of the user. Поскольку каждый разработчик использует собственную технологию системы или внутреннего сервера, не существует универсального способа реализовать эту логику. Since everyone uses his or her own system or backend technology, there is no generic way to implement this logic. Мы всегда используем SHA256 в качестве алгоритма хэширования и Pkcs1 для SignaturePadding, поэтому убедитесь, что вы используете именно их, когда проверяете подписанный ответ от клиента. We are using SHA256 as the hash algorithm and Pkcs1 for SignaturePadding, so make sure that’s what you use when you validate the signed response from the client. Напоминаем, что образец способа, которым можно сделать это, содержится на сервере на .NET 4.6, но обычно он будет выглядеть примерно так: Again, refer to the sample for a way to do it on your server in .NET 4.6, but in general it will look something like this:

Считываем сохраненный открытый ключ, который является ключом RSA. We read the stored public key, which is an RSA key. Проверяем подписанное сообщение задачи с помощью открытого ключа, и, если проверка успешна, авторизуем пользователя. We validate the signed challenge message with the public key and if this checks out, we authorize the user. Если пользователь прошел проверку подлинности, приложение может вызывать внутренние службы в обычном режиме. If the user is authenticated, the app can call the backend services as normal.

Полный код может выглядеть примерно следующим образом: The complete code might look something like the following:

Реализация правильного механизма ответа на запрос выходит за рамки данного документа, но это тема, которой необходимо уделить внимание, чтобы успешно создать безопасный механизм, предотвращающий такие возможности, как атака с повторением или атака с перехватом. Implementing the correct challenge–response mechanism is outside the scope of this document, but this topic is something that requires attention in order to successfully create a secure mechanism to prevent things like replay attacks or man-in-the-middle attacks.

3.5. Регистрация другого устройства 3.5 Enrolling another device

В настоящее время пользователи часто используют несколько устройств с одними и теми же установленными приложениями. Nowadays, it is common for users to have multiple devices with the same apps installed. Как выглядит использование Windows Hello с несколькими устройствами? How does this work when using Windows Hello with multiple devices?

При использовании Windows Hello каждое устройство создает уникальный набор из открытого и закрытого ключа. When using Windows Hello every device will create a unique private and public key set. Это означает, что если вы хотите, чтобы пользователь мог использовать несколько устройств, внутренний сервер должен иметь возможность сохранять несколько открытых ключей от этого пользователя. This means that if you want a user to be able to use multiple devices, your backend must be able to store multiple public keys from this user. Пример структуры таблицы см. в схеме базы данных в разделе 2.1. Refer to the database diagram in section 2.1 for an example of the table structure.

Регистрация другого устройства почти не отличается от регистрации пользователя в первый раз. Registering another device is almost the same as registering a user for the first time. Вам по-прежнему необходимо убедиться в том, что пользователь, регистрирующийся в новом устройстве, действительно является тем пользователем, которым он представляется. You still need to be sure the user registering for this new device is really the user he or she claims to be. Вы можете сделать это с помощью любого механизма двухфакторной проверки подлинности, используемого сегодня. You can do so with any two-factor authentication mechanism that is used today. Существует несколько способов выполнить это безопасно. There are several ways to accomplish this in a secure way. Все зависит от вашего сценария. It all depends on your scenario.

Например, если вы все еще используете имя пользователя и пароль для входа, вы можете использовать их для проверки подлинности пользователя и отправить запрос на использование одного из доказательств (например, SMS-сообщение или сообщение электронной почты). For example, if you still use login name and password you can use that to authenticate the user and ask them to use one of their verification methods like SMS or email. Если у вас нет имени пользователя и пароля для входа, вы можете также использовать одно из уже зарегистрированных устройств и отправить уведомление в приложение на этом устройстве. If you don’t have a login name and password, you can also use one of the already registered devices and send a notification to the app on that device. Примером этого является приложение для проверки подлинности учетной записи Майкрософт. The MSA authenticator app is an example of this. В двух словах, вам необходимо использовать типовой механизм 2FA для регистрации дополнительных устройств для пользователя. In short, you should use a common 2FA mechanism to register extra devices for the user.

Код для регистрации нового устройства точно такой же, как и для регистрации пользователя впервые (из приложения). The code to register the new device is exactly the same as registering the user for the first time (from within the app).

Чтобы упростить для пользователя определение зарегистрированных устройств, можно отправить ему имя устройства или другой идентификатор в рамках регистрации. To make it easier for the user to recognize which devices are registered, you can choose to send the device name or another identifier as part of the registration. Это также удобно, если вы, например, хотите создать службу на внутреннем сервере, в которой пользователи могут отменить регистрацию устройства, если устройство потеряно. This is also useful, for example, if you want to implement a service on your backend where users can unregister devices when a device is lost.

3.6. Использование нескольких учетных записей в приложении 3.6 Using multiple accounts in your app

Кроме поддержки нескольких устройств для одной учетной записи, распространенной практикой также является поддержка нескольких учетных записей в одном приложении. In addition to supporting multiple devices for a single account, it is also common to support multiple accounts in a single app. Например, возможно, вы подключаетесь к нескольким учетным записям в сети Twitter со своего приложения. For example, maybe you are connecting to multiple Twitter accounts from within your app. С помощью Windows Hello можно создать несколько пар ключей и поддерживать несколько учетных записей в приложении. With Windows Hello, you can create multiple key pairs and support multiple accounts inside your app.

Одним из способов сделать это является сохранение имени пользователя или уникального идентификатора, описанного в предыдущей главе, и сохранение его в изолированном хранилище. One way of doing this is keeping the username or unique identifier described in the previous chapter in isolated storage. Поэтому каждый раз при создании новой учетной записи вы сохраняете идентификатор учетной записи в изолированном хранилище. Therefore, every time you create a new account, you store the account ID in isolated storage.

В пользовательском интерфейсе приложения вы позволяете пользователю выбрать одну из ранее созданных учетных записей или зарегистрировать новую. In the app UI, you allow the user to either choose one of the previously created accounts or sign up with a new one. Процесс создания новой учетной записи идентичен описанному ранее. The flow of creating a new account is the same as described before. Выбор учетной записи — это вопрос создания списка сохраненных учетных записей на экране. Choosing an account is a matter of listing the stored accounts on the screen. После того, как пользователь выберет учетную запись, используйте идентификатор учетной записи для входа пользователя в приложение. Once the user selects an account, use the account ID to log on the user in your app:

Остальной процесс идентичен описанному ранее. The rest of the flow is the same as described earlier. Естественно, все эти учетные записи защищены одинаковым PIN-кодом или биометрическим жестом, так как в этом сценарии все они используются на одном устройстве с одной учетной записью Windows. To be clear, all these accounts are protected by the same PIN or biometric gesture since in this scenario they are being used on a single device with the same Windows Account.

4. Перенос существующей системы в Windows Hello 4 Migrating an Existing System to Windows Hello

В этом коротком разделе мы рассмотрим существующее приложение UWP и внутреннюю систему, использующую базу данных, которая хранит имя пользователя и хэшированный пароль. In this short section, we will address an existing Universal Windows Platform app and backend system that uses a database that stores the username and hashed password. Эти приложения собирают учетные данные от пользователя во время запуска приложения и используют их, когда внутренняя система возвращает запрос проверки подлинности. These apps collect credentials from the user when the app starts and use them when the backend system returns the authentication challenge.

Здесь описываются элементы, которые необходимо будет изменить или заменить, чтобы функция Windows Hello работала. Here, we will describe what pieces need to be changed or replaced to make Windows Hello work.

Мы уже описывали большинство методов в предыдущих главах. We have already described most of the techniques in the earlier chapters. Добавление Windows Hello в существующую систему предусматривает добавление нескольких разных потоков в части регистрации и проверки подлинности кода. Adding Windows Hello to your existing system involves adding a couple of different flows in the registration and authentication part of your code.

Одним из подходов является разрешение пользователю выбрать момент обновления. One approach is to let the user choose when to upgrade. После того, как пользователь войдет в приложение и вы определите, что приложение и операционная система могут поддерживать Windows Hello, можно задать пользователю вопрос желает ли он обновить учетные данные, чтобы использовать эту современную и безопасную систему. After the user logs on to the app and you detect that the app and OS are capable of supporting Windows Hello, you can ask the user if he or she wants to upgrade credentials to use this modern and more secure system. Вы можете использовать следующий код, чтобы убедиться, что пользователь может применять Windows Hello. You can use the following code to check whether the user is capable of using Windows Hello.

Пользовательский интерфейс может выглядеть примерно так: The UI might look something like this:

Если пользователь решает начать работать с Windows Hello, вы создаете KeyCredential, как описано выше. If the user elects to start using Windows Hello, you create the KeyCredential described before. Внутренний сервер регистрации добавляет открытый ключ и дополнительный оператор аттестации в базу данных. The backend registration server adds the public key and optional attestation statement to the database. Так как пользователь уже прошел проверку подлинности с помощью имени пользователя и пароля, сервер может привязать новые учетные данные к данным о текущем пользователе в базе данных. Because the user is already authenticated with username and password, the server can link the new credentials to the current user information in the database. Модель базы данных может быть такой же, как описана в примере выше. The database model could be the same as the example described earlier.

Если приложение может создавать KeyCredential пользователей, оно сохраняет идентификатор пользователя в изолированном хранилище, чтобы пользователь мог выбрать эту учетную запись из списка, когда приложение будет запущено снова. If the app was able to create the users KeyCredential, it stores the user ID in isolated storage so the user can pick this account from the list once the app is started again. С этого момента и далее поток полностью следует примерам, описанным в предыдущих главах. From this point on, the flow exactly follows the examples described in earlier chapters.

Последним этапом в переходе к полному сценарию Windows Hello является отключение функции имени пользователя и пароля для входа в приложении и удаление сохраненных хэшированных паролей из вашей базы данных. The final step in migrating to a full Windows Hello scenario is disabling the logon name and password option in the app and removing the stored hashed passwords from your database.

5. Резюме 5 Summary

Windows 10 представляет более высокий уровень безопасности, который также просто очень реализовать на практике. Windows 10 introduces a higher level of security that is also simple to put into practice. Windows Hello предоставляет новую биометрическую систему входа, которая распознает пользователя и активно предотвращает попытки обойти надлежащую идентификацию. Windows Hello provides a new biometric sign-in system that recognizes the user and actively defeats efforts to circumvent proper identification. Она может предоставить несколько уровней ключей и сертификатов, которые ни при каких обстоятельствах не могут быть раскрыты или использованы за пределами доверенного платформенного модуля. It can then deliver multiple layers of keys and certificates that can never be revealed or used outside the trusted platform module. Кроме того, дальнейший уровень безопасности обеспечивается с помощью дополнительного использования ключей удостоверения подлинности и сертификатов. In addition, a further layer of security is available through the optional use of attestation identity keys and certificates.

Как разработчик, вы можете использовать эти рекомендации по проектированию и развертыванию этих технологий для простого добавления безопасной проверки подлинности в развертывания Windows 10 для защиты приложений и внутренних служб. As a developer, you can use this guidance on design and deployment of these technologies to easily add secure authentication to your Windows 10 rollouts to protect apps and backend services. Требуемый код минимален и прост для восприятия. The code required is minimal and easy to understand. Windows 10 выполняет всю сложную работу. Windows 10 does the heavy lifting.

Гибкие варианты реализации позволяют Windows Hello заменить собой или работать вместе с вашей существующей системой проверки подлинности. Flexible implementation options allow Windows Hello to replace or work alongside your existing authentication system. Процесс развертывания максимально комфортен и экономичен. The deployment experience is painless and economical. Для развертывания безопасности Windows 10 не требуется дополнительная инфраструктура. No additional infrastructure is needed to deploy Windows 10 security. С помощью функции Microsoft Hello, встроенной в операционную систему, Windows 10 предлагает самое безопасное решение проблем проверки подлинности, стоящих перед современным разработчиком. With Microsoft Hello built in to the operating system, Windows 10 offers the most secure solution to the authentication problems facing the modern developer.

Миссия выполнена! Mission accomplished! Вы только что повысили безопасность в Интернете! You just made the Internet a safer place!