Capítulo 17 — Conceitos de criptografia

Mapa da aula

Aula 17 publicada. Mapa, exemplo, EX049.

flowchart TD
  N0["17.1 Primitivas básicas"]
  N1["17.2 Proteção de artefatos de IA"]
  N2["17.3 O que a criptografia não pode fazer"]
  N3["17.4 Chaves"]
  N4["17.6b Verificação de assinaturas na prática"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX049"]

Desenho lógico

flowchart LR
  N0["17.1 Primitivas básicas"]
  N1["17.2 Proteção de artefatos de IA"]
  N2["17.3 O que a criptografia não pode fazer"]
  N3["17.4 Chaves"]
  N4["17.6b Verificação de assinaturas na prática"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX049"]

[17.1 Primitivas básicas]
    |
    v
[17.2 Proteção de artefatos de IA]
    |
    v
[17.3 O que a criptografia não pode fazer]
    |
    v
[17.4 Chaves]
    |
    v
[17.6b Verificação de assinaturas na prática]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX049]

Objetivos de aprendizagem

Você vai (1) explicar hashing, criptografia simétrica e de chave pública e assinaturas digitais; (2) aplicá-los para proteger artefatos e dados de IA; (3) explicar o que a criptografia não pode fazer pela segurança de IA; e (4) verificar a integridade de modelos com manifestos assinados.

17.1 Primitivas básicas

Funções de hash (como a SHA-256) mapeiam dados para um resumo curto; mudar um bit muda o resumo. A criptografia simétrica (como o AES) protege dados com uma chave compartilhada. A criptografia de chave pública permite que qualquer pessoa cifre para o detentor de uma chave, ou verifique assinaturas dele. Assinaturas digitais provam quem criou os dados e que eles não foram alterados. Nos sistemas da LCH, hashes verificam os arquivos de modelo, a criptografia simétrica protege os logs de conversas armazenados, a criptografia de chave pública protege o TLS até o provedor do modelo, e assinaturas provam que as versões do DocSort vêm do fornecedor. Cada primitiva responde a uma pergunta diferente, e usar a errada deixa uma lacuna: um hash sozinho mostra que um arquivo não mudou, mas não quem o produziu.

17.2 Proteção de artefatos de IA

Cifre dados de treinamento e pesos de modelos em repouso; use TLS em trânsito. Publique os resumos SHA-256 dos arquivos de modelo num manifesto e assine o manifesto, para que os destinatários possam verificar a integridade e a origem antes de carregar. Isso trata riscos da cadeia de suprimentos (OWASP LLM03), como modelos adulterados ou com backdoor (Gu et al., arXiv:1708.06733).

"""Lab H: integrity of model artefacts with SHA-256 manifests (stdlib only).
Creates synthetic 'artefact' bytes, records a manifest, then detects a
one-byte tampering and a swapped file. No real models are involved."""
import hashlib, json
files = {"model.bin": bytes(range(256)) * 40, "tokenizer.json": b'{"vocab": ["a", "b"]}',
         "config.yaml": b"layers: 4\nheads: 8\n"}
manifest = {n: hashlib.sha256(b).hexdigest() for n, b in files.items()}
print(json.dumps({k: v[:16] for k, v in manifest.items()}, indent=1))
received = dict(files)
tampered = bytearray(received["model.bin"]); tampered[5000] ^= 1
received["model.bin"] = bytes(tampered)
received["config.yaml"] = b"layers: 4\nheads: 8\ntrust_remote_code: true\n"
for n, b in sorted(received.items()):
    ok = hashlib.sha256(b).hexdigest() == manifest[n]
    print(f"{n:15s} {'OK' if ok else 'MISMATCH'}")

Saída esperada:

{
 "model.bin": "e96760a87768717b",
 "tokenizer.json": "f63d2ddabc61f2d9",
 "config.yaml": "e5bbb570ca0fcb87"
}
config.yaml     MISMATCH
model.bin       MISMATCH
tokenizer.json  OK

O Lab H verifica a integridade, mas não a origem, porque um atacante capaz de alterar os arquivos também poderia alterar um manifesto não assinado. A assinatura fecha essa lacuna, já que a chave não está no servidor.

17.3 O que a criptografia não pode fazer

A cifragem não impede que uma consulta autorizada extraia informação de um modelo, não previne a injeção de prompt e não torna limpo um conjunto de dados envenenado — apenas prova que os dados envenenados são os dados que você assinou. A criptografia protege dados e artefatos; o comportamento precisa de outros controles. No Ask Lumen, toda mensagem trafega cifrada e todo arquivo de modelo é verificado, e ainda assim um paciente pode digitar uma injeção e um documento de parceiro pode carregar texto hostil. Esses riscos exigem o ponto de política, a rotulagem e o monitoramento. A nota de arquitetura de Rina lista quais ameaças cada camada trata, para que ninguém suponha que a cifragem cobre mais do que cobre.

17.4 Chaves

A segurança depende das chaves: guarde-as em serviços de gerenciamento de chaves, restrinja o acesso, faça sua rotação e nunca as coloque em prompts ou em repositórios de código. A chave de API do provedor de modelo da LCH é um exemplo claro: quem a possui pode executar consultas cobradas da LCH e possivelmente ler logs. A LCH a guarda no serviço de gerenciamento de chaves da nuvem, dá acesso apenas ao servidor de aplicação, faz sua rotação a cada trimestre e varre os repositórios em busca de commits acidentais. Uma chave vazada é primeiro revogada, depois investigada, e os logs são revisados.

17.5 Exemplo resolvido (caso sintético da LCH)

O fornecedor do DocSort passou a assinar suas versões. Rina configurou o script de implantação para buscar a chave pública do fornecedor no repositório confiável da própria LCH (e não no servidor de versões), verificar a assinatura do manifesto e depois verificar o resumo de cada arquivo. Uma versão de teste com um arquivo modificado foi rejeitada. Buscar a chave no repositório da própria LCH importa porque, do contrário, um atacante que controlasse o servidor de versões poderia fornecer tanto um arquivo malicioso quanto uma chave correspondente. A versão de teste rejeitada confirma que a verificação funciona de ponta a ponta.

17.6 Erros e limites

Três erros são comuns: buscar resumos e chaves no mesmo lugar que os arquivos; supor que a cifragem impede o vazamento pelo modelo; e chaves no código-fonte. Buscar resumos e chaves no mesmo lugar que os arquivos significa que um único comprometimento derrota a verificação, e é por isso que a LCH guarda a chave do DocSort em seu próprio repositório. A cifragem não impede que um modelo revele dados de treinamento por meio de suas respostas. Chaves no código-fonte acabam em repositórios e backups que muitas pessoas podem ler, por isso são procuradas e trocadas quando encontradas.

17.6b Verificação de assinaturas na prática

Assinar o arquivo de modelo do DocSort só ajuda se o carregador verificar a assinatura toda vez e se recusar a iniciar em caso de falha. A LCH testou isso carregando uma cópia com um byte alterado: o serviço recusou, registrou o evento e continuou executando a versão verificada anterior. Manter a versão verificada anterior em execução evitou uma indisponibilidade enquanto o problema era investigado, o que tornou a recusa segura. O fornecedor então reemitiu uma versão corretamente assinada. Os funcionários não notaram nenhuma mudança no DocSort enquanto a versão antiga continuava classificando os documentos.

Exercícios

• EX049 — Primitivas. Associe: integridade de um arquivo; origem de um manifesto; confidencialidade de dados armazenados. Rubrica: 3 = hash, assinatura, cifragem; 2 = duas; 1 = uma; 0 = nenhuma.
• EX050 — Origem da chave. Por que buscar a chave pública do fornecedor no repositório da própria LCH? Rubrica: 3 = um atacante que controlasse o servidor de versões poderia substituir arquivos e chave; 2 = parcial; 1 = vago; 0 = errado.
• EX051 — Limites. Nomeie dois riscos de IA que a criptografia não trata. Rubrica: 3 = injeção de prompt, extração por consultas, envenenamento de dados assinados, evasão; 2 = um; 1 = vago; 0 = errado.

Síntese

A criptografia torna os artefatos e dados de IA verificáveis e confidenciais, mas não consegue fazer um modelo se comportar; é uma camada entre muitas.

Continue estudando — capítulo 17 de 40

← Capítulo 16 (rascunho) · Índice de capítulos do curso · Capítulo 18 (rascunho) →