Windows Hello

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

Примечание.

В этой статье рассматривается разработка приложений. Сведения об архитектуре и реализации Windows Hello см. в статье "Планирование Windows Hello для бизнеса развертывания".

Пошаговое руководство по созданию приложения WinUI с помощью Windows Hello и резервной службы проверки подлинности см . в статьях о приложении входа Windows Hello и службе входа Windows Hello.

Введение

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

Проблемы с традиционными учетными данными

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

Кража учетных данных

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

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

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

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

Решение проблем с учетными данными

Решение проблем, с которыми создаются пароли, является сложной задачей. Ужесточение политик паролей только не будет делать это; пользователи могут просто перезапустить, предоставить общий доступ или записать пароли. Хотя обучение пользователей имеет решающее значение для обеспечения безопасности проверки подлинности, только образование не устраняет проблему.

Windows Hello заменяет пароли строгой двухфакторной проверкой подлинности (2FA), проверяя существующие учетные данные и создавая учетные данные для конкретного устройства, которые защищает биометрический или ПИН-код пользователя.

Что такое Windows Hello?

Windows Hello — это имя, которое корпорация Майкрософт предоставила новой системе биометрического входа, встроенной в Windows. Так как он встроен непосредственно в операционную систему, Windows Hello позволяет идентификации лиц или отпечатков пальцев разблокировать устройства пользователей. Проверка подлинности происходит, когда пользователь предоставляет ему уникальный биометрический идентификатор для доступа к учетным данным для конкретного устройства, что означает, что злоумышленник, который украл устройство, не может войти в него, если злоумышленник не имеет ПИН-кода. Хранилище безопасных учетных данных Windows защищает биометрические данные на устройстве. С помощью Windows Hello для разблокировки устройства авторизованный пользователь получает доступ ко всем своим приложениям, приложениям, данным, веб-сайтам и службам.

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

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

Windows Hello предоставляет надежный способ распознавания отдельного пользователя устройства, который обращается к первой части пути между пользователем и запрошенной службой или элементом данных. После того как устройство распознало пользователя, он по-прежнему должен пройти проверку подлинности пользователя, прежде чем определить, следует ли предоставлять доступ к запрошенным ресурсам. Windows Hello обеспечивает надежную 2FA, которая полностью интегрирована в Windows и заменяет многократно используемые пароли сочетанием определенного устройства и биометрическим жестом или ПИН-кодом.

Windows Hello — это не просто замена традиционных систем 2FA, хотя. Это концептуально похоже на смарт-карты: проверка подлинности выполняется с помощью криптографических примитивов вместо сравнения строк, а материал ключа пользователя обеспечивает безопасность внутри небезопасного оборудования. Windows Hello не требует дополнительных компонентов инфраструктуры, необходимых для развертывания смарт-карт. В частности, для управления сертификатами не требуется инфраструктура открытых ключей (PKI), если у вас нет. Windows Hello объединяет основные преимущества смарт-карт — гибкость развертывания виртуальных смарт-карт и надежную безопасность для физических смарт-карт без каких-либо недостатков.

Как работает Windows Hello

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

Чтобы включить Windows Hello на устройстве, пользователь должен иметь учетную запись идентификатора Майкрософт или учетную запись Майкрософт, подключенную к параметрам Windows.

Защита ключей

Каждый раз, когда создается материал ключа, он должен быть защищен от атаки. Самый надежный способ сделать это — через специализированное оборудование. Существует длинная история использования аппаратных модулей безопасности (HSM) для создания, хранения и обработки ключей для критически важных для безопасности приложений. Смарт-карты — это особый тип HSM, как и устройства, соответствующие стандарту доверенного платформенного модуля группы вычислений. По возможности реализация Windows Hello использует преимущества подключения оборудования доверенного платформенного модуля для создания, хранения и обработки ключей. Однако windows Hello и Windows Hello for Work не требуют подключения доверенного платформенного модуля.

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

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

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

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

Подготовка к реализации Windows Hello

Теперь, когда у нас есть базовое представление о том, как работает Windows Hello, давайте рассмотрим, как реализовать их в собственных приложениях.

Существуют различные сценарии, которые можно реализовать с помощью Windows Hello. Например, просто войдите в приложение на устройстве. Другой распространенный сценарий — проверка подлинности в службе. Вместо использования имени входа и пароля вы будете использовать Windows Hello. В следующих разделах мы обсудим реализацию нескольких различных сценариев, включая проверку подлинности в службах с помощью Windows Hello и преобразование из существующей системы имени пользователя и пароля в систему Windows Hello.

Реализация Windows Hello

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

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

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

Начнем с новой службы, которая будет использовать Windows Hello, и гипотетический новый пользователь, готовый зарегистрироваться на новом устройстве.

Первым шагом является проверка того, что пользователь может использовать Windows Hello. Приложение проверяет параметры пользователя и возможности компьютера, чтобы убедиться, что он может создавать ключи идентификатора пользователя. Если приложение определяет, что пользователь еще не включил Windows Hello, он предложит пользователю настроить это перед использованием приложения.

Чтобы включить Windows Hello, пользователю нужно просто настроить ПИН-код в параметрах Windows, если только пользователь не настроит его во время интерфейса out of Box (OOBE).

В следующих строках кода показан простой способ проверить, настроен ли пользователь для Windows Hello.

var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();
if (!keyCredentialAvailable)
{
    // User didn't set up PIN yet
    return;
}

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

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

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

Код для создания KeyCredential выглядит следующим образом:

var keyCreationResult = await KeyCredentialManager.RequestCreateAsync(
    AccountId, KeyCredentialCreationOption.ReplaceExisting);

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

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

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

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

Логика регистрации может выглядеть следующим образом:

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

using System;
using System.Runtime;
using System.Threading.Tasks;
using Windows.Storage.Streams;
using Windows.Security.Credentials;

static async void RegisterUser(string AccountId)
{
    var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();
    if (!keyCredentialAvailable)
    {
        // The user didn't set up a PIN yet
        return;
    }

    var keyCreationResult = await KeyCredentialManager.RequestCreateAsync(AccountId, KeyCredentialCreationOption.ReplaceExisting);
    if (keyCreationResult.Status == KeyCredentialStatus.Success)
    {
        var userKey = keyCreationResult.Credential;
        var publicKey = userKey.RetrievePublicKey();
        var keyAttestationResult = await userKey.GetAttestationAsync();
        IBuffer keyAttestation = null;
        IBuffer certificateChain = null;
        bool keyAttestationIncluded = false;
        bool keyAttestationCanBeRetrievedLater = false;

        keyAttestationResult = await userKey.GetAttestationAsync();
        KeyCredentialAttestationStatus keyAttestationRetryType = 0;

        switch (keyAttestationResult.Status)
        {
            case KeyCredentialAttestationStatus.Success:
                keyAttestationIncluded = true;
                keyAttestation = keyAttestationResult.AttestationBuffer;
                certificateChain = keyAttestationResult.CertificateChainBuffer;
                break;
            case KeyCredentialAttestationStatus.TemporaryFailure:
                keyAttestationRetryType = KeyCredentialAttestationStatus.TemporaryFailure;
                keyAttestationCanBeRetrievedLater = true;
                break;
            case KeyCredentialAttestationStatus.NotSupported:
                keyAttestationRetryType = KeyCredentialAttestationStatus.NotSupported;
                keyAttestationCanBeRetrievedLater = true;
                break;
        }
    }
    else if (keyCreationResult.Status == KeyCredentialStatus.UserCanceled ||
        keyCreationResult.Status == KeyCredentialStatus.UserPrefersPassword)
    {
        // Show error message to the user to get confirmation that user
        // does not want to enroll.
    }
}

Аттестация

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

Когда он получает созданный ключ RSA, оператор аттестации и сертификат AIK, сервер проверяет следующие условия:

• Допустима подпись сертификата AIK.
• Сертификат AIK объединяется с доверенным корнем.
• Сертификат AIK и его цепочка включены для EKU OID "2.23.133.8.3" (понятное имя — "Сертификат ключа удостоверения аттестации").
• Сертификат AIK является допустимым временем.
• Все выданные сертификаты ЦС в цепочке являются допустимыми во времени и не отозваны.
• Инструкция аттестации формируется правильно.
• Подпись в BLOB-объекте KeyAttestation использует открытый ключ AIK.
• Открытый ключ, включенный в большой двоичный объект KeyAttestation , соответствует открытому ключу RSA, который клиент отправляет вместе с оператором аттестации.

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

Вход с помощью Windows Hello

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

Принудительное повторное вход пользователя

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

Следующая строка кода приведет пользователя к вводу учетных данных.

UserConsentVerificationResult consentResult = await UserConsentVerifier.RequestVerificationAsync("userMessage");
if (consentResult.Equals(UserConsentVerificationResult.Verified))
{
    // continue
}

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

Проверка подлинности на серверной части

Когда приложение пытается получить доступ к защищенной серверной службе, служба отправляет запрос приложению. Приложение использует закрытый ключ от пользователя для подписывания задачи и отправляет его обратно на сервер. Так как сервер сохранил открытый ключ для этого пользователя, он использует стандартные API шифрования, чтобы убедиться, что сообщение действительно было подписано с правильным закрытым ключом. На клиенте подписывание выполняется API Windows Hello; Разработчик никогда не будет иметь доступа к закрытому ключу пользователя.

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

Аттестация доступна только для устройств с микросхемой TPM версии 2.0 или более поздней. Поэтому необходимо учитывать, что эти сведения могут быть недоступны на каждом устройстве.

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

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

var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

if (openKeyResult.Status == KeyCredentialStatus.Success)
{
    var userKey = openKeyResult.Credential;
    var publicKey = userKey.RetrievePublicKey();
    var signResult = await userKey.RequestSignAsync(message);

    if (signResult.Status == KeyCredentialStatus.Success)
    {
        return signResult.Result;
    }
    else if (signResult.Status == KeyCredentialStatus.UserPrefersPassword)
    {

    }
}

Первая строка KeyCredentialManager.OpenAsync попросит Windows открыть дескриптор ключа. Если это успешно, вы можете подписать сообщение о вызове с помощью метода KeyCredential.RequestSignAsync , что приводит к запросу ПИН-кода пользователя или биометрических данных через Windows Hello. В то время разработчик не получит доступ к закрытому ключу пользователя. Это все обеспечивает безопасность через API.

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

Основной поток ответа на вызовы показан на схеме последовательности:

Затем сервер должен проверить подпись. Когда вы запрашиваете открытый ключ и отправляете его на сервер для последующей проверки, он находится в blob-объекте publicKeyInfo в кодировке ASN.1. Если вы изучите пример кода Windows Hello на GitHub, вы увидите, что вспомогательные классы можно упаковать функции Crypt32 для перевода большого двоичного объекта в кодировке ASN.1 в большой двоичный объект CNG, который чаще всего используется. Большой двоичный объект содержит алгоритм открытого ключа, который является RSA и открытый ключ RSA.

В примере мы преобразуем большой двоичный объект в кодировке ASN.1 в большой двоичный объект CNG, чтобы его можно было использовать с CNG и API BCrypt. Если вы ищете большой двоичный объект CNG, он указывает на связанную BCRYPT_KEY_BLOB структуру. Эту область API можно использовать для проверки подлинности и шифрования в приложениях Windows. ASN.1 — это документируемый стандарт для передачи структур данных, которые могут быть сериализованы, и обычно используется в криптографии открытого ключа и с сертификатами. Именно поэтому данные открытого ключа возвращаются таким образом. Открытый ключ — это ключ RSA; и это алгоритм, который Windows Hello использует при подписи данных.

После получения большого двоичного объекта CNG необходимо проверить подписанный запрос на открытый ключ пользователя. Так как каждый использует свою собственную систему или серверную технологию, не существует универсального способа реализации этой логики. Мы используем SHA256 в качестве хэш-алгоритма и Pkcs1 для SignaturePadding, поэтому убедитесь, что это то, что вы используете при проверке подписанного ответа от клиента. Опять же, ознакомьтесь с примером, чтобы сделать это на сервере в .NET 4.6, но в целом это будет выглядеть примерно так:

using (RSACng pubKey = new RSACng(publicKey))
{
    retval = pubKey.VerifyData(originalChallenge, responseSignature, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
}

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

Полный код может выглядеть примерно так:

using System;
using System.Runtime;
using System.Threading.Tasks;
using Windows.Storage.Streams;
using Windows.Security.Cryptography;
using Windows.Security.Cryptography.Core;
using Windows.Security.Credentials;

static async Task<IBuffer> GetAuthenticationMessageAsync(IBuffer message, String AccountId)
{
    var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

    if (openKeyResult.Status == KeyCredentialStatus.Success)
    {
        var userKey = openKeyResult.Credential;
        var publicKey = userKey.RetrievePublicKey();
        var signResult = await userKey.RequestSignAsync(message);
        if (signResult.Status == KeyCredentialStatus.Success)
        {
            return signResult.Result;
        }
        else if (signResult.Status == KeyCredentialStatus.UserCanceled)
        {
            // Launch app-specific flow to handle the scenario 
            return null;
        }
    }
    else if (openKeyResult.Status == KeyCredentialStatus.NotFound)
    {
        // PIN reset has occurred somewhere else and key is lost.
        // Repeat key registration
        return null;
    }
    else
    {
        // Show custom UI because unknown error has happened.
        return null;
    }
}

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

Регистрация другого устройства

Обычно у пользователей есть несколько устройств с одинаковыми приложениями, установленными сегодня. Как это работает при использовании Windows Hello с несколькими устройствами?

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

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

Например, если вы по-прежнему используете имя входа и пароль, вы можете использовать его для проверки подлинности пользователя и попросить их использовать один из методов проверки, таких как SMS или электронная почта. Если у вас нет имени входа и пароля, вы также можете использовать одно из уже зарегистрированных устройств и отправить уведомление приложению на этом устройстве. Примером этого является приложение проверки подлинности MSA. Короче говоря, следует использовать общий механизм 2FA для регистрации дополнительных устройств для пользователя.

Код для регистрации нового устройства точно такой же, как регистрация пользователя в первый раз (из приложения).

var keyCreationResult = await KeyCredentialManager.RequestCreateAsync(
    AccountId, KeyCredentialCreationOption.ReplaceExisting);

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

Использование нескольких учетных записей в приложении

Помимо поддержки нескольких устройств для одной учетной записи, часто поддерживается несколько учетных записей в одном приложении. Например, возможно, вы подключаетесь к нескольким учетным записям Twitter из приложения. С помощью Windows Hello можно создать несколько пар ключей и поддерживать несколько учетных записей в приложении.

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

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

var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

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

Перенос существующей системы в Windows Hello

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

Здесь мы рассмотрим, какие части необходимо изменить или заменить для работы Windows Hello.

Мы уже описали большинство методов в предыдущих разделах. Добавление Windows Hello в существующую систему включает добавление нескольких различных потоков в часть кода регистрации и проверки подлинности.

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

var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();

Пользовательский интерфейс может выглядеть примерно так:

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

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

Последний этап миграции на полный сценарий Windows Hello — отключение имени входа и пароля в приложении и удаление сохраненных хэшированных паролей из базы данных.

Итоги

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

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

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

Миссия выполнена! Вы только что сделали Интернет более безопасным местом!

Дополнительные ресурсы

Статьи и пример кода

• Обзор Windows Hello
• Планирование развертывания Windows Hello для бизнеса
• Пример кода Windows Hello UWP на GitHub

Терминология

Термин	Определение
AIK	Ключ удостоверения аттестации используется для предоставления такого криптографического подтверждения (аттестация ключа доверенного платформенного модуля), подписав свойства не переносимого ключа и предоставив свойства и подпись проверяющей стороне для проверки. Результирующая подпись называется "оператор аттестации". Так как подпись создается с помощью закрытого ключа AIK, который можно использовать только в доверенном платформенный модуль, который создал его, проверяющая сторона может доверять тому, что проверяемый ключ действительно не переносится и не может использоваться за пределами этого доверенного платформенного модуля.
Сертификат AIK	Сертификат AIK используется для проверки наличия AIK в TPM. Он также используется для того, чтобы подтвердить, что другие ключи, сертифицированные AIK, были получены из этого конкретного доверенного платформенного модуля.
Поставщик удостоверений	Поставщик удостоверений — это поставщик удостоверений. Примером является сборка поставщика удостоверений майкрософт для учетных записей Майкрософт. Каждый раз, когда приложению требуется пройти проверку подлинности с помощью MSA, он может вызывать поставщика удостоверений MSA.
PKI	Инфраструктура открытых ключей обычно используется для указания среды, размещенной самой организацией, и отвечает за создание ключей, отзыв ключей и т. д.
TPM (Доверенный платформенный модуль)	Доверенный модуль платформы можно использовать для создания пар криптографических открытых и закрытых ключей таким образом, чтобы закрытый ключ никогда не отображался или использовался за пределами доверенного платформенного модуля (т. е. ключ не переносится).
Аттестация ключей доверенного платформенного модуля (TPM Key) Attestation	Протокол, который криптографически доказывает, что ключ привязан к TPM. Этот тип аттестации можно использовать для гарантии того, что определенная криптографическая операция произошла в доверенном модулем определенного компьютера.

См. также

• Приложение для входа в Windows Hello
• Служба входа Windows Hello