Habilitando a segurança da ligação para o remoting holográfico

Se é novo no Remoting Holográfico, pode querer ler a nossa visão geral.

Nota

Esta orientação é específica para o remomento holográfico em HoloLens 2 e Windows PCs em execução Windows Mixed Reality.

Esta página dá-lhe uma visão geral da segurança da rede para o Remoting Holográfico. Encontrará informações sobre

  • segurança no contexto de Remoting Holográfico e por que você pode precisar dele
  • medidas recomendadas com base em diferentes casos de utilização
  • implementando a segurança na sua solução holográfica de remoting

Segurança holográfica de remoing

O Remoting Holográfico troca informações através de uma rede. Se não houver medidas de segurança, os adversários na mesma rede podem comprometer a integridade da comunicação ou aceder a informações confidenciais.

As aplicações de amostra e o Jogador holográfico de remoing na loja Windows vêm com desativação de segurança. Fazê-lo torna as amostras mais fáceis de entender. Também ajuda a começar mais rapidamente com o desenvolvimento.

Para testes de campo ou produção, recomendamos fortemente permitir a segurança na sua solução holográfica de remoting.

A segurança no Remoting Holográfico, quando configurado corretamente para o seu caso de utilização, dá-lhe as seguintes garantias:

  • Autenticidade: tanto o jogador como a app remota podem ter a certeza que o outro lado é quem eles afirmam ser
  • Confidencialidade: nenhum terceiro pode ler as informações trocadas entre o jogador e a aplicação remota
  • Integridade: jogador e remoto podem detetar quaisquer alterações em trânsito na sua comunicação

Importante

Para poder utilizar funcionalidades de segurança, terá de implementar tanto um leitor personalizado como uma aplicação remota personalizada utilizando Windows Mixed Reality ou APIs OpenXR.

Nota

A partir da versão 2.4.0 podem ser criadas aplicações remotas que utilizem a API OpenXR. Uma visão geral sobre como estabelecer uma ligação segura num ambiente OpenXR pode ser encontrada abaixo.

Planejando a implementação da segurança

Quando ativa a segurança no Remoting Holográfico, a biblioteca de remoing permitirá automaticamente verificações de encriptação e integridade para todos os dados trocados através da rede.

Garantir a autenticação adequada requer algum trabalho extra. O que precisa fazer depende do seu caso de uso, e o resto desta secção é sobre descobrir os passos necessários.

Importante

Este artigo só pode fornecer orientação geral. Se se sentir inseguro, considere consultar um perito em segurança que lhe possa dar orientações específicas para o seu caso de utilização.

Primeiro, alguma terminologia: ao descrever ligações de rede, os termos cliente e servidor serão usados. O servidor é o lado que escuta as ligações recebidas num endereço de ponto final conhecido, e o cliente é o que está a ligar ao ponto final do servidor.

Nota

As funções do cliente e do servidor não estão ligadas ao facto de uma aplicação estar a agir como um jogador ou como um controlo remoto. Embora as amostras tenham o leitor no papel do servidor, é fácil reverter as funções se se encaixar melhor no seu caso de utilização.

Planejando a autenticação servidor-a-cliente

O servidor utiliza certificados digitais para provar a sua identidade ao cliente. O cliente valida o certificado do servidor durante a fase de aperto de mão de ligação. Se o cliente não confiar no servidor, terminará a ligação neste momento.

A forma como o cliente valida o certificado do servidor e que tipos de certificados de servidor podem ser utilizados depende do seu caso de utilização.

Use o estojo 1: O nome de anfitrião do servidor não é fixo, ou o servidor não é endereçado pelo nome de anfitrião.

Neste caso de utilização, não é prático (ou mesmo possível) emitir um certificado para o nome de anfitrião do servidor. Recomendamos que valide a impressão digital do certificado. Como uma impressão digital humana, a impressão digital identifica um certificado.

É importante comunicar a impressão digital ao cliente fora da banda. Isso significa que não podes enviá-lo pela mesma ligação de rede que é usada para a remoissar. Em vez disso, pode inseri-lo manualmente na configuração do cliente, ou fazer com que o cliente digitalize um código QR.

Use o caso 2: O servidor pode ser alcançado sobre um nome de anfitrião estável.

Neste caso de utilização, o servidor tem um nome de anfitrião específico, e você sabe que este nome não é suscetível de mudar. Em seguida, pode utilizar um certificado emitido para o nome de anfitrião do servidor. A confiança será estabelecida com base no nome do anfitrião e na cadeia de confiança do certificado.

Se escolher esta opção, o cliente precisa de saber antecipadamente o nome de anfitrião do servidor e o certificado de raiz.

Planeamento da autenticação cliente-servidor

Os clientes autenticam-se contra o servidor utilizando um token de formulário livre. O que este token deve conter dependerá novamente do seu caso de utilização:

Use o estojo 1: Basta verificar a identidade da aplicação do cliente.

Neste caso de utilização, um segredo partilhado pode ser suficiente. Este segredo deve ser complexo o suficiente para não ser adivinhado.

Um bom segredo partilhado é um GUID aleatório, que é introduzido manualmente na configuração do servidor e do cliente. Para criar um pode, por exemplo, utilizar o New-Guid comando em PowerShell.

Certifique-se de que este segredo partilhado nunca seja comunicado através de canais inseguros. A biblioteca de remoing garante que o segredo partilhado é sempre enviado encriptado, e apenas para pares de confiança.

Use o caso 2: Também é necessário verificar a identidade do utilizador da aplicação do cliente.

Um segredo partilhado não será suficiente para cobrir este caso de uso. Em vez disso, pode utilizar fichas criadas por um fornecedor de identidade. Um fluxo de trabalho de autenticação utilizando um fornecedor de identidade seria assim:

  • O cliente autoriza contra o fornecedor de identidade e pede um token
  • O fornecedor de identidade gera um símbolo e envia-o ao cliente
  • O cliente envia este símbolo para o servidor através de Remoting Holográfico
  • O servidor valida o símbolo do cliente contra o fornecedor de identidade

Um exemplo de um fornecedor de identidade é o plataforma de identidades da Microsoft.

Como no caso de utilização anterior, certifique-se de que estes tokens não são enviados através de canais inseguros ou expostos de outra forma.

Implementação de segurança de remoagem holográfica

Lembre-se que precisa de implementar aplicações personalizadas remotas e de jogadores se quiser ativar a segurança da ligação. Pode utilizar as amostras fornecidas como pontos de partida para as suas próprias aplicações.

Para ativar a segurança, ligue ListenSecure() em vez de , e em vez de estabelecer a Listen()ConnectSecure()Connect() ligação de remoing.

Estas chamadas exigem que forneça implementações de determinadas interfaces para fornecer e validar informações relacionadas com a segurança:

  • O servidor precisa de implementar um fornecedor de certificados e um validador de autenticação
  • O cliente precisa de implementar um fornecedor de autenticação e um validador de certificados.

Todas as interfaces têm uma função que lhe pede para tomar medidas, que recebe um objeto de retorno como parâmetro. Utilizando este objeto, pode implementar facilmente o manuseamento assíncrodo do pedido. Mantenha uma referência a este objeto e chame a função de conclusão quando a ação assíncronea estiver completa. A função de conclusão pode ser chamada de qualquer fio.

Dica

Implementar interfaces WinRT pode ser facilmente feito usando C++/WinRT. As APIs de autor com capítulo C++/WinRT descrevem-no em detalhe.

Importante

O build\native\include\HolographicAppRemoting\Microsoft.Holographic.AppRemoting.idl pacote NuGet contém documentação detalhada para a API relacionada com ligações seguras.

Implementação de um fornecedor de certificados

Os fornecedores de certificados fornecem a aplicação do servidor com o certificado a utilizar. A implementação consiste em duas partes:

  1. Um objeto de certificado, que implementa a ICertificate interface:

    • GetCertificatePfx() deve devolver o conteúdo binário de uma loja de PKCS#12 certificados. Um .pfx ficheiro contém PKCS#12 dados, para que o seu conteúdo possa ser utilizado diretamente aqui.
    • GetSubjectName() deve devolver o nome amigável que identifica o certificado a utilizar. Se não for atribuído nenhum nome amigável ao certificado, esta função deverá devolver o nome do sujeito do certificado.
    • GetPfxPassword() deve devolver a palavra-passe necessária para abrir a loja de certificados (ou uma cadeia vazia se não for necessária nenhuma senha).
  2. Um fornecedor de certificados que implementa a ICertificateProvider interface:

    • GetCertificate() deve construir um objeto de certificado e devolvê-lo chamando CertificateReceived() o objeto de retorno.

Implementação de um validador de autenticação

Os validadores de autenticação recebem o token de autenticação enviado pelo cliente e respondem com o resultado da validação.

Implementar a IAuthenticationReceiver interface da seguinte forma:

  • GetRealm() deve devolver o nome do reino da autenticação (um reino HTTP utilizado durante o aperto de mão de ligação de remoting).
  • ValidateToken() deve validar o token de autenticação do cliente e ligar ValidationCompleted() para o objeto de retorno com o resultado da validação.

Implementação de um fornecedor de autenticação

Os fornecedores de autenticação geram ou recuperam o token de autenticação a enviar para o servidor.

Implementar a IAuthenticationProvider interface da seguinte forma:

  • GetToken() deve gerar ou recuperar o sinal de autenticação a enviar. Assim que o sinal estiver pronto, ligue para o TokenReceived() método no objeto de retorno.

Implementação de um validador de certificados

Os validadores de certificados recebem a cadeia de certificados enviada pelo servidor e determinam se o servidor é de confiança.

Para validar certificados, pode utilizar a lógica de validação do sistema subjacente. Esta validação do sistema pode suportar a sua própria lógica de validação ou substituí-la completamente. Se não passar o seu próprio validador de certificado ao solicitar uma ligação segura, a validação do sistema será usada automaticamente.

No Windows, a validação do sistema verificará:

  • Integridade da cadeia de certificados: os certificados formam uma cadeia consistente que termina num certificado de raiz fidedigno
  • Validade do certificado: o certificado do servidor está dentro do seu prazo de validade e é emitido para autenticação do servidor
  • Revogação: O certificado não foi revogado
  • Partida de nome: O nome do anfitrião do servidor corresponde a um dos nomes do anfitrião para o qual o certificado foi emitido

Implementar a ICertificateValidator interface da seguinte forma:

  • PerformSystemValidation() deve voltar true se for efetuada uma validação do sistema, tal como acima descrito. Neste caso, o resultado da validação do sistema é passado como uma entrada para o ValidateCertificate() método.
  • ValidateCertificate() deve validar a cadeia de certificados e, em seguida, recorrer CertificateValidated() à chamada passada com o resultado final da validação. Este método aceita a cadeia de certificados, o nome do servidor com o qual a ligação está a ser estabelecida e se deve ser forçada uma verificação de revogação. Se a cadeia de certificados contiver vários certificados, o primeiro é o certificado de assunto.

Nota

Se o seu caso de utilização necessitar de uma forma diferente de validação (ver caso de utilização do certificado #1 acima), validação do sistema de bypass inteiramente. Em vez disso, utilize qualquer API ou biblioteca que possa manusear certificados X.509 codificados pela DER para descodificar a cadeia de certificados e efetuar as verificações necessárias para o seu caso de utilização.

Ligação segura utilizando a API OpenXR

Ao utilizar a API OpenXR,toda a API relacionada com a ligação segura está disponível como parte da extensão OpenXR.

Importante

Para saber mais sobre a extensão Holográfica de Remoting OpenXR API, consulte a especificação que pode ser encontrada no repositório de remoagem holográfico github.

Os elementos-chave para uma ligação segura utilizando a XR_MSFT_holographic_remoting extensão OpenXR são as seguintes chamadas.

  • xrRemotingRequestAuthenticationTokenCallbackMSFT, gera ou recupera o token de autenticação a ser enviado.
  • xrRemotingValidateServerCertificateCallbackMSFT, valida a cadeia de certificados.
  • xrRemotingValidateAuthenticationTokenCallbackMSFT, valida o token de autenticação do cliente.
  • xrRemotingRequestServerCertificateCallbackMSFT, forneça a aplicação do servidor com o certificado a utilizar.

Estas chamadas podem ser fornecidas ao tempo de funcionamento do OpenXR de remoting através xrRemotingSetSecureConnectionClientCallbacksMSFT e xrRemotingSetSecureConnectionServerCallbacksMSFT . Além disso, a ligação segura deve ser ativada através do parâmetro secureConnection na XrRemotingConnectInfoMSFT estrutura ou na XrRemotingListenInfoMSFT estrutura, dependendo se está a usar xrRemotingConnectMSFT ou xrRemotingListenMSFT .

Esta API é semelhante à API baseada no IDL descrita na implementação da segurança holográfica de remoagem. No entanto, em vez de implementar interfaces, é suposto fornecer implementações de retorno. Pode encontrar um exemplo detalhado na aplicação de amostras OpenXR.

Consulte também