Os diagramas UML podem ser usados ​​para explicar a criptografia de uma solução de segurança empresarial. Eu sei porque contribuí para white papers de segurança e documentos explicativos semelhantes enquanto trabalhava no negócio de software empresarial.

Por que eu uso UML

Alguns anos atrás eu estava recebendo uma explicação verbal sobre as relações entre os recursos criptográficos de uma solução de um engenheiro de segurança. Eu estava fazendo perguntas e comecei a desenhar caixas e linhas em um quadro de limpeza. O engenheiro de segurança corrigiu meu entendimento apagando e redesenhando algumas caixas e linhas. Tirei uma foto com meu telefone e transcrevi os diagramas com uma ferramenta de desenho no meu computador.

Mais tarde, mas no mesmo trabalho, eu estava contribuindo para o white paper de segurança do produto em que trabalhei. Criei uma convenção, ad hoc, para representar em diagramas as relações entre seus recursos criptográficos.

Mais tarde ainda, em um trabalho diferente, eu estava novamente escrevendo um white paper de segurança com diagramas. Eu não poderia utilizar a mesma convenção ad hoc porque era propriedade intelectual do meu empregador anterior. Foi quando recorri a um padrão com o qual já estava familiarizado, a Unified Modeling Language (UML).

UML como um kit de ferramentas

Um grande valor do padrão UML é que ele fornece ferramentas e não é prescritivo. Minha UML não é rigorosa. Às vezes, faço uso de elementos padrão de maneira não padronizada. Mas meus diagramas obedecem ao que Martin Fowler descreveu como a “fração da UML que é mais útil”.

O padrão UML é uma ferramenta que vai me ajudar a explicar a criptografia de uma solução.

O que deve ser explicado

Eu explico todos os itens a seguir com UML.

• Quais são os principais recursos criptográficos da solução. Por exemplo, quais chaves de criptografia e valores salt existem.
• Quais algoritmos são usados.
• Quais valores de parâmetro são usados, como quanto tempo em bits são as chaves e os valores salt.
• Como cada recurso criptográfico é gerado.
• Quais dos recursos criptográficos são armazenados persistentemente e onde, e quais não são.
• Quais recursos são protegidos por quais chaves, em outras palavras, a hierarquia de chaves.

Uma explicação que eu der não permitirá realmente que um concorrente copie o produto, porque não será suficientemente detalhada. Você pode pensar de forma diferente e, nesse caso, pode exigir um contrato de não divulgação (NDA) de qualquer parte externa que queira ver sua explicação.

Exemplo de Requisitos do Produto

Para ilustrar como usar UML para explicar a criptografia, vou imaginar um produto com alguns requisitos de segurança. Em seguida, vou propor uma implementação e explicar a criptografia da implementação com diagramas UML.

Imagine que o produto é o Digital Encabulator for Enterprise (DEE) versão 1. O DEE pode estar disponível para usuários finais em dispositivos móveis e em laptops e computadores de mesa. Os requisitos de segurança são para fazer tudo o que se segue.

• Proteja os dados em repouso com criptografia baseada em senha ( PBE ). A senha será um valor secreto inserido pelo usuário final.
• Suporte a alteração de senha , sem interrupção na disponibilidade de dados protegidos.
• Oferece suporte à recuperação de dados caso o usuário final esqueça sua senha.
• Dar suporte à auditoria de dados pela empresa sem o conhecimento do usuário final.
• Use práticas conhecidas e padrão para criptografia.

• Uma senha é definida por cada usuário final ao instalar o aplicativo.
• Uma chave de senha (PK) é gerada a partir da senha por um processo PBKDF2 (função de derivação de chave baseada em senha versão 2) com esses parâmetros.
  - Função pseudo-aleatória de código de autenticação de mensagem baseada em hash (HMAC).
  - Função de hash SHA256.
  - 20.000 iterações.
• Um valor de sal de senha (PS) está incluído nas entradas PBKDF2. O PS será gerado por um gerador de números aleatórios seguro (RNG).
• O valor PS é armazenado persistentemente no dispositivo. Nem o valor PK nem a senha são armazenados.

• Proteja os dados do aplicativo com uma chave intermediária de criptografia de dados (DEK). DEK será um valor aleatório longo gerado por um RNG seguro. O DEK terá 256 bits de comprimento, para evitar que seja adivinhado pela força bruta em um período de tempo prático.
• Armazene DEK criptografado por PK no armazenamento persistente do dispositivo. Nunca armazene DEK em branco em qualquer armazenamento persistente. A criptografia usará o algoritmo AES Key Wrap.
• Quando o usuário alterar sua senha, criptografe novamente a DEK com o novo valor de PK. (Sem DEK, todos os dados do aplicativo teriam que ser criptografados novamente quando a senha fosse alterada.)

• Forneça um serviço de recuperação de dados (DRS).
• O DRS receberá uma solicitação de configuração (DRS-SU) quando um usuário final gerar DEK em seu dispositivo. O DRS-SU incluirá um identificador de usuário e exigirá autenticação de usuário fora de banda, por exemplo, redirecionando o usuário para um provedor de identidade (IDP).
• Quando o DRS recebe o DRS-SU, ele gera um par de chaves para criptografia assimétrica. O par de chaves possui uma chave privada (RIK) que é gerada e armazenada em um módulo de segurança de hardware (HSM) e uma chave pública correspondente (RUK). RIK terá 2048 bits de comprimento.
• O DRS responde ao DRS-SU enviando de volta RUK.
• O aplicativo do usuário armazena DEK criptografado por RUK no armazenamento persistente do dispositivo. A criptografia usará o algoritmo RSA com preenchimento PKCS1.
• O aplicativo do usuário final pode enviar uma solicitação de recuperação (DRS-RY) para o DRS. O DRS-RY incluirá um identificador de usuário e exigirá autenticação do usuário, igual ao DRS-SU, e incluirá DEK criptografado por RUK.
• Quando o DRS recebe o DRS-RY, o DEK é descriptografado pelo RIK no HSM. O DRS responde ao DRS-RY com DEK.

• O DRS pode receber uma solicitação de auditoria (DRS-AT). O DRS-AT incluirá os mesmos valores do DRS-RY e, além disso, um identificador de usuário de auditoria. O usuário de auditoria exigirá autorização.
• O processamento do DRS e a resposta ao DRS-AT são os mesmos do DRS-RY.

Este diagrama representa as funções criptográficas básicas na implementação como um diagrama de classe UML.

O diagrama expressa o seguinte.

Secure Random Number Generator é uma classe. Seu nome será abreviado para RNG.

• As instâncias RNG têm um atributo, comprimento, com um valor padrão de 256.
• As instâncias RNG têm uma operação, getNext, sem parâmetros que retornam bits de comprimento.

• As instâncias de cifra têm um atributo, algoritmo, com um padrão de AES-GCM (Advanced Encryption Standard in Galois/Counter Mode).
• As instâncias Cipher têm uma operação, encrypt, que usa dois parâmetros, Key e Plaintext, e retorna Ciphertext. Nenhum detalhe é fornecido sobre os tipos de dados.
• As instâncias de cifra têm uma operação, decrypt, que usa dois parâmetros, Key e Ciphertext, e retorna Plaintext. Nenhum detalhe é fornecido sobre os tipos de dados.

Exemplo de Diagrama de Implantação

Este diagrama representa o armazenamento e a proteção dos recursos criptográficos na implementação como um diagrama de implantação UML.

Desculpas interpostas: o diagrama se desvia do padrão UML, das seguintes maneiras.

• Artefatos, por exemplo Dados de Aplicativos, são mostrados como retângulos sem um marcador de documento.
  O marcador de documento parece supérfluo no padrão. Já está claro no retângulo plano que Application Data, por exemplo, não é um ambiente de execução.
• Os objetos, por exemplo, as instâncias RNG, são mostrados em um diagrama de implantação.
  O estilo usado aqui, retângulos com cantos quadrados e texto sublinhado, é obtido do padrão de diagrama de objeto UML.
  Desenhar um diagrama de objeto separado com as mesmas instâncias, mas sem seu contexto implantado, exigiria que o leitor olhasse para um diagrama extra.
• Os rótulos nas conexões não mostram exatamente a comunicação. Em vez disso, eles mostram nomes de parâmetros e, portanto, relacionamentos.
• A instância de cifra assimétrica é mostrada no ambiente de memória de tempo de execução do aplicativo. Isso é correto para criptografia, mas incorreto para descriptografia.
  Talvez isso possa ser resolvido expandindo o diagrama para mostrar ambientes ou documentos separados para uma solicitação de configuração de DRS e uma solicitação de recuperação de DRS.

• Esses dados são armazenados persistentemente pelo aplicativo.
  - PS.
  - DEK criptografado por PK.
  - Dados de aplicativos criptografados.
  - DEK criptografado por RUK.
• Nenhum outro dado é armazenado persistentemente pelo aplicativo.
• O RIK é armazenado em um HSM dentro do DRS.
• O RUK é gerado pelo DRS, mas não é armazenado lá.
• A DEK é armazenada criptografada por duas chaves diferentes, RUK e PK. Para a criptografia PK, o algoritmo AES-KW (Advanced Encryption Standard Key Wrap) é usado em vez do AES-GCM padrão.
• PS é um valor aleatório de comprimento padrão, 256. RIK e RUK são baseados em um valor aleatório de comprimento especificado, 2048.

• Os dados do aplicativo podem ser obtidos do armazenamento persistente somente se o DEK for obtido.
• A DEK pode ser obtida do armazenamento persistente se a senha for conhecida. O PS está em armazenamento persistente e o PK pode ser obtido executando o KDF no código de acesso e no PS.
• O DEK também pode ser obtido do armazenamento persistente se o RIK estiver acessível. A DEK criptografada por RUK é armazenada de forma persistente e pode ser descriptografada por RIK. O diagrama não expressa que o DEK criptografado por RUK deve ser enviado ao DRS para processar a descriptografia.

Exemplo de Diagrama de Atividades

Este diagrama representa o processamento para definir a senha como um diagrama de atividades UML.

Os seguintes elementos padrão são usados.

• As ações, como uma derivação de chave, têm cantos arredondados.
• Os nós de objeto, com cantos quadrados, são usados ​​para representar recursos criptográficos, como chaves e valores salt.
• Pinos, pequenos quadrados com rótulos de texto, indicam parâmetros para ações. Os pinos são usados ​​apenas no caso de haver mais de um parâmetro.
  - Os parâmetros de entrada para um processo encrypt () têm pinos porque existem dois, chave e texto simples.
  - A saída de um processo encrypt() tem apenas um parâmetro, texto cifrado, portanto não possui um pino.
• As barras grossas indicam o início e o fim do processamento independente. Por exemplo, o RNG getNext() para gerar PS é independente do Passcode ser um parâmetro para o processamento KDF. Isso pode não ser muito padrão, mas evita ter dois fluxos de um recurso, o que definitivamente não é padrão.

1. O processamento começa quando a senha é inserida.
2. Um gerador de número aleatório seguro (RNG) é executado com um comprimento padrão, conforme mostrado no diagrama de classes. A saída é o salt da senha (PS), que é armazenado persistentemente.
3. Uma função de derivação de chave é executada com a senha como o segredo, o valor PS como o sal e o algoritmo padrão e a contagem de iterações, conforme mostrado no diagrama de classes. A saída é a chave de senha (PK), que não é armazenada persistentemente.
4. Outro RNG é executado com um comprimento padrão, conforme mostrado no diagrama de classes. A saída é a chave de criptografia de dados (DEK), que não é armazenada de forma persistente.
5. Um processo de criptografia cifrada é executado com PK como chave, DEK como texto simples e algoritmo AES-KW. A saída é armazenada persistentemente.

• Configure a recuperação de dados.
• Alterar senha.
• Inicie o aplicativo, o que incluiria a recuperação da chave de criptografia de dados. A recuperação pode ser de armazenamento persistente, regenerando a chave de senha de uma senha digitada pelo usuário ou do serviço de recuperação de dados.
• Armazenar dados do aplicativo.

Os exemplos acima mostram que os diagramas UML podem ser usados ​​para explicar a criptografia. Diferentes tipos de diagrama UML podem ser usados ​​para explicar diferentes aspectos.

• Os diagramas de classe mostram quais padrões criptográficos e parâmetros são usados.
• Os diagramas de implantação mostram onde os recursos são armazenados, se são armazenados e quais recursos são protegidos por quais chaves.
• Os diagramas de atividades mostram sequências de processamento. Os nós de objeto mostram quais recursos estão envolvidos no processamento.

Para obter um exemplo de explicação da criptografia de uma solução real, consulte o white paper publicado aqui.
developer.vmware.com/…/MobileApplicationManagement.pdf
(Os diagramas UML estão na seção Workspace ONE Encryption of Data at Rest, sob o título Passcode-Based Encryption Diagrams.)

Os diagramas neste artigo e no white paper foram desenhados com a ferramenta diagrams.net , também conhecida como draw.io.

Para obter informações sobre o padrão Unified Modeling Language (UML), consulte ohttps://uml.orgwebsite e o livro UML Distilled Third Edition de Martin Fowler.

Para obter uma referência sobre padrões e termos de criptografia, consulte o livro Serious Cryptography de Jean-Philippe Aumasson.