2. O problema central: proteger o dado não basta; é preciso legitimar o dispositivo

A discussão sobre criptografia em saúde costuma concentrar-se no dado em repouso 
e no dado em trânsito. Essa preocupação é correta, mas incompleta. 

Antes de perguntar se o dado foi cifrado, é necessário perguntar se o emissor do dado
é autêntico. Essa diferença é fundamental.

Um resultado laboratorial, um traçado fisiológico, uma imagem de Dúplex Scan, um alerta 
de deterioração clínica ou um score produzido por IA só podem ser considerados clinicamente 
confiáveis quando a instituição possui evidência técnica de que:

1.	o dispositivo emissor é legítimo;
2.	o certificado utilizado ainda é válido;
3.	a chave privada correspondente não foi comprometida;
4.	o firmware em execução corresponde à versão autorizada;
5.	a atualização mais recente foi autenticada;
6.	a comunicação se deu por canal íntegro e autenticado;
7.	os registros produzidos podem ser auditados posteriormente.

É exatamente isso que transforma criptografia em segurança assistencial concreta.

3. Assinaturas digitais e certificados: a identidade clínica do dispositivo

A assinatura digital é um dos mecanismos mais elegantes da segurança moderna porque 
responde, ao mesmo tempo, a duas perguntas essenciais:
1.	quem enviou,
2.	o que exatamente foi enviado.

No âmbito técnico, a assinatura digital utiliza criptografia assimétrica aliada à função hash. 
O emissor gera um resumo criptográfico do objeto, assina esse resumo com sua chave privada 
e o verificador pode, por meio da chave pública correspondente, confirmar tanto a autenticidade 
quanto a integridade do conteúdo.
    
No contexto hospitalar, isso implica que um DMIA é capaz de comprovar a autoria de mensagens, 
atualizações, laudos estruturados, pacotes de telemetria ou artefatos de software, assegurando 
que tais informações sejam provenientes do dispositivo e não tenham sido alteradas.

É importante ressaltar que a chave pública isoladamente não garante confiabilidade, já que
qualquer entidade pode gerar um par de chaves. O elemento que efetivamente atribui confiança 
à identidade é o certificado digital, pois vincula a chave pública a uma entidade específica — 
seja pessoa, servidor, equipamento, domínio, serviço ou dispositivo — e essa vinculação 
é validada por uma autoridade certificadora reconhecida.

No contexto da IoMT hospitalar, o certificado digital serve como uma identificação criptográfica do dispositivo.
Sem o certificado, existe apenas comunicação; com ele, estabelece-se confiança entre as partes envolvidas.

4. Cadeia de confiança: por que um certificado vale o que vale

A credibilidade dos certificados digitais é resultado de uma construção em cadeia, não ocorre espontaneamente. 

1. O Certificado Raiz
Ocupa o topo desta hierarquia, com papel institucional fundamental ao fornecer a base da confiança para todo
o ecossistema.

2. Os Certificado Intermediário
São responsáveis por assinar os certificados finais que viabilizam operações cotidianas, compondo uma 
arquitetura projetada para mitigar riscos operacionais:

3. A Chave Privada 
A chave privada do certificado raiz deve ser mantida sob máxima segurança, enquanto os intermediários
suportam as rotinas de emissão.

Esse modelo de confiança é especialmente relevante para o setor da saúde. 
Hospitais que realizam milhares de interações entre máquinas, por meio de gateways, estações de imagem, 
APIs, microserviços e dispositivos embarcados, necessitam tratar certificados como ativos críticos para a 
continuidade assistencial. A governança adequada desses ativos é essencial.

Comprometimento ou expiração não gerenciada de um certificado raiz acarreta colapso de toda a cadeia. 

Caso um certificado intermediário seja afetado, o impacto pode ser significativo, embora limitado em sua 
abrangência. 

Se um certificado final for aceito após revogação, existe o risco de autenticação indevida de emissores que 
já não deveriam integrar o ecossistema.

No contexto clínico, essa questão transcende burocracia, representando uma falha estrutural de confiança.

5. PKI hospitalar: infraestrutura de confiança, não apenas tecnologia

    A PKI não é simplesmente um software, um diretório ou um serviço de certificados. 
Ela é uma infraestrutura de confiança composta por elementos técnicos, regras, políticas, 
procedimentos e decisões institucionais.

Em um hospital de alta complexidade, uma PKI madura deve responder a perguntas como:
1.	Quem emite os certificados dos dispositivos?
2.	Qual é o processo para admissão de um novo equipamento à IoMT?
3.	O que acontece quando um DMIA retorna da manutenção?
4.	Como se faz a revogação de seu certificado anterior?
5.	Quem válida a nova identidade?
6.	Com que frequência se verifica revogação?
7.	Onde ficam armazenadas as chaves?
8.	Quem pode acessar as chaves?
9.	Como ocorre a rotação?
10.	Como se registra auditoria?
11.	Como se reage ao comprometimento?

Percebe-se, assim, que a PKI em saúde não deve ser pensada apenas como 
ferramenta de TI.  Ela precisa estar em conformidade com:

1.	a engenharia clínica, 

2.	a segurança da informação, 

3.	a governança institucional, 

4.	a regulamentação sanitária,

5.	a rastreabilidade documental,

6.	os fluxos assistenciais reais.

6. Firmware, boot seguro e atualização autenticada

Um dos maiores equívocos contemporâneos é imaginar que a segurança do dispositivo se 
resume ao canal criptografado. Não se resume.
Um canal seguro transportando software ilegítimo continua sendo um problema grave. 
Por isso, em DMIA e equipamentos médicos embarcados, o eixo da confiança precisa 
alcançar também:
1.	o firmware, 

2.	o processo de inicialização, 

3.	a cadeia de atualização;

4.	os mecanismos de verificação de integridade do software executado.

6.1 Secure boot

O boot seguro parte de uma ideia simples e poderosa: o dispositivo só deve iniciar componentes 
cuja integridade e legitimidade possam ser verificadas. Isso estabelece uma cadeia interna de 
confiança desde o carregador inicial até módulos mais altos do sistema.

Em ambiente hospitalar, isso é decisivo. Um equipamento que inicializa software adulterado pode
continuar “funcionando” de maneira normal, enquanto produz:
1.	comportamento não confiável, 

2.	resultados enviesados, 

3.	telemetria falsa,

4.	portas inseguras invisíveis à operação clínica.

6.2 Assinatura de firmware

Atualizações de firmware, drivers, patches e componentes embarcados precisam ser assinados 
digitalmente pelo fabricante ou por autoridade legitimamente reconhecida no contexto institucional. 

O dispositivo, antes de instalar ou executar a atualização, deve verificar a assinatura.
Sem isso, a instituição corre o risco de aceitar:
1.	firmware modificado, 
2.	pacote malicioso, 
3.	binário trocado, 
4.	atualização não autorizada 
5.	rollback inseguro para versão vulnerável.

6.3 Atualização segura

A atualização segura garante::
1.	origem, 
2.	integridade, 
3.	versão, 
4.	autorização, 
5.	rastreabilidade,
6.	possibilidade de reversão controlada.

# Atualização de Software
Em setores críticos, a atualização de software precisa:
1. obedecer a janela definida, 
2. validação prévia, 
3. trilha de auditoria, 
4. segregação de ambiente,
5. verificação criptográfica,
6. registro formal. 

Em outras palavras: a atualização de DMIA não é evento trivial de manutenção; 
é intervenção com potencial repercussão assistencial.

7. CRL e OCSP: a importância de saber quando não confiar mais

Certificados não falham apenas por expiração. 
Eles podem precisar ser revogados antes disso. As causas são variadas: 
1.	comprometimento de chave privada, 
2.	troca de domínio, 
3.	substituição de dispositivo,
4.	manutenção externa, 
5.	perda de controle sobre a identidade, 
6.	erro de emissão, 
7.	incidente de segurança.
8.	alteração de escopo operacional.

Como o certificado não “carrega” em si um campo dinâmico de revogação, 
a validação depende de mecanismos externos.

7.1 CRL

A CRL funciona como uma lista de certificados revogados..
É útil em ambientes que exigem consulta local, toleram atualização periódica e 
desejam reduzir chamadas externas em massa.

No hospital, isso pode ser interessante para segmentos específicos da rede, 
sobretudo quando há equipamentos com restrições operacionais, baixa 
conectividade externa ou necessidade de checagem em lote. 
A limitação é conhecida: entre duas atualizações, pode existir uma janela de 
desatualização.

7.2 OCSP

O OCSP permite consulta mais dinâmica, quase em tempo real, sobre o status 
do certificado. 
Em tese, oferece resposta mais atual sobre revogação, mas também impõe maior 
dependência operacional de conectividade, disponibilidade e desempenho.
Em ambiente hospitalar, a escolha entre CRL e OCSP não deve ser ideológica.
Deve ser arquitetural.
O mais maduro, muitas vezes, é um modelo híbrido:
•	OCSP para fluxos críticos e sensíveis à atualidade do status;
•	CRL para camadas específicas onde a verificação local é mais eficiente ou mais resiliente.
•	Essa decisão precisa considerar perfil dos dispositivos, criticidade clínica, latência 
admissível e estratégia institucional de continuidade.

8. TLS 1.3 e mTLS: confiança na comunicação entre máquina e máquina

Quando um DMIA, um gateway clínico, uma estação de imagem ou um serviço de 
IA precisa se comunicar com o ecossistema hospitalar, não basta criptografar a conexão. 
É preciso estabelecer confiança verificável no handshake. 
É nesse ponto que o TLS 1.3 assume papel central. 
Durante o handshake, o servidor apresenta seu certificado, e a outra ponta valida:

1.	o período de validade, 
2.	a autoridade emissora,
3.	a correspondência do domínio ou identidade, 
4.	a assinatura da autoridade certificadora,
5.	o status de revogação.

Quando falamos em mTLS, o princípio se fortalece: ambas as partes apresentam certificados 
e ambas precisam ser autenticadas.
Isso é especialmente valioso para ambientes em que dispositivos, gateways e serviços internos 
trocam dados sensíveis continuamente. Em saúde, o mTLS é particularmente importante quando:
1.	um equipamento retorna da manutenção;
2.	um novo DMIA é incorporado à rede;
3.	um gateway edge passa a conversar com o data lake clínico;
4.	uma API institucional dialoga com motor de IA;
5.	um equipamento externo precisa provar sua legitimidade à infraestrutura hospitalar.

Após a fase de autenticação, o TLS 1.3 utiliza mecanismos modernos de proteção da 
sessão, com especial destaque para algoritmos AEAD, que unem confidencialidade e 
autenticidade de maneira muito mais eficiente.

9. Assinatura digital não é HMAC: por que a distinção importa

Um ponto crucial do módulo — e muito relevante para o ambiente hospitalar —
é a diferença entre assinatura digital e HMAC.

# A assinatura digital é assimétrica.
Ela oferece autenticidade forte, integridade e, em contexto adequadamente certificado, 
não repúdio. É a tecnologia certa quando as partes não compartilham a mesma chave 
secreta e quando a prova de autoria importa institucionalmente.

# O HMAC é simétrico. 
Ele é excelente para integridade e autenticação em ambientes fechados, com alto 
desempenho, quando os sistemas compartilham um segredo comum. 
Porém, não substitui a assinatura digital em cenários que exigem prova externa 
de autoria ou cadeia formal de confiança. Traduzindo isso para a prática hospitalar
:
•	Para admissão de um DMIA à rede, validação de firmware, autenticação mútua 
institucional e prova de procedência, o mecanismo adequado é o ecossistema de certificados 
e assinaturas digitais.

•	Para comunicação interna de alta cadência entre serviços já confiáveis, especialmente 
quando velocidade e eficiência importam enormemente, HMAC pode ser útil como mecanismo 
complementar em fluxos fechados e controlados.

Confundir esses dois planos pode levar a arquitetura a exigir de um mecanismo simétrico 
aquilo que só a confiança assimétrica consegue oferecer.

10. Edge computing e DMIA: por que curvas elípticas e eficiência importam

Em ambientes de borda, o problema da segurança não desaparece; ele se torna mais exigente. 
DMIA e equipamentos conectados frequentemente operam com:
1.	restrição de energia, 
2.	limitação de processamento, 
3.	menor capacidade de armazenamento, 
4.	necessidade de baixa latência,
5.	janelas de indisponibilidade .
    
Por isso, a arquitetura criptográfica precisa ser tecnicamente sofisticada e operacionalmente 
realista. 
Não adianta desenhar uma segurança perfeita no papel e impraticável no equipamento real. 
Também não adianta simplificar tanto a ponto de transformar o edge em elo fraco da instituição. 
Nesse contexto, é decisivo:
1.	o uso de algoritmos e certificados adequados ao perfil embarcado, 
2.	a gestão eficiente do handshake, 
3.	a validação assíncrona bem desenhada, 
4.	a rotação controlada de segredos,
5.	a manutenção de uma cadeia de confiança enxuta, porém robusta.

11.1 DMIA retornando da manutenção preventiva

Um monitor, ultrassom portátil ou dispositivo de imagem retorna de manutenção
externa e precisa ser reintegrado à IoMT. A instituição não pode simplesmente 
religá-lo à rede. O correto é:
1.	revogar o certificado anterior, 
2.	validar a legitimidade do equipamento, 
3.	emitir ou provisionar nova identidade criptográfica, 
4.	verificar firmware, 
5.	checar integridade do boot,
6.	estabelecer autenticação mútua com a infraestrutura central.
Sem isso, a manutenção vira ponto cego de segurança.

11.2 Atualização OTA de bomba de infusão inteligente

O fabricante disponibiliza nova atualização crítica.
Antes da instalação, o sistema precisa verificar:
1.	assinatura digital do pacote, 
2.	versão esperada, 
3.	compatibilidade, 
4.	trilha de auditoria, 
5.	autorização institucional,
6.	possibilidade de rollback seguro.
Atualizar sem essas etapas é tecnicamente equivalente a convidar código de origem
insuficientemente verificada para o coração da operação clínica.

11.3 Gateway edge consolidando sinais vitais de UTI

Múltiplos dispositivos enviam dados a um gateway local, que por sua vez repassa informação 
ao prontuário e a motores analíticos. Nesse cenário, a instituição precisa garantir:
 1. identidade dos emissores, 
 2. integridade dos fluxos, 
 3. segregação de credenciais, 
 4. autenticação forte do gateway,
 5. resiliência frente a revogação ou substituição de dispositivos.

11.4 Serviço de IA recebendo dados de dispositivo médico

Um equipamento de imagem ou monitoramento envia artefatos a um pipeline de IA para
priorização, categorização ou apoio à decisão. Se a origem do dado não for confiável, 
toda a cadeia posterior — inclusive a inferência — estará contaminada. 
Em outras palavras: IA não corrige dado ilegítimo. Apenas processa, com velocidade ampliada, o risco já introduzido.

12.1 Política mínima de identidade criptográfica para DMIA

JSON
{
  "dispositivo": "ultrassom_vascular_dm_07",
  "categoria": "DMIA",
  "criticidade": "alta",
  "estado_operacional": "retorno_manutencao",
  "identidade_criptografica": {
    "certificado_x509": true,
    "status_certificado": "pendente_validacao",
    "validacao_revogacao": {
      "crl": true,
      "ocsp": true
    },
    "mtls_obrigatorio": true
  },
  "firmware": {
    "versao": "5.4.2",
    "assinatura_digital_valida": true,
    "secure_boot": true,
    "rollback_bloqueado": true
  },
  "requisitos_para_reintegracao": [
    "revogar_certificado_anterior",
    "emitir_novo_certificado",
    "validar_boot",
    "registrar_auditoria",
    "aprovar_janela_de_reentrada"
  ]
}

12.2 Validador conceitual de admissão segura do dispositivo

Python
def validar_admissao_dispositivo(cert_valido, nao_revogado, mtls_ok,
                                 firmware_assinado, secure_boot_ok,
                                 auditoria_registrada):
    if not cert_valido:
        return "NEGAR: certificado inválido ou expirado."
    if not nao_revogado:
        return "NEGAR: certificado revogado."
    if not mtls_ok:
        return "NEGAR: autenticação mútua não estabelecida."
    if not firmware_assinado:
        return "NEGAR: firmware sem assinatura confiável."
    if not secure_boot_ok:
        return "NEGAR: cadeia de inicialização não confiável."
    if not auditoria_registrada:
        return "NEGAR: ausência de rastreabilidade institucional."
    return "AUTORIZAR: dispositivo apto para reintegração controlada na IoMT.

12.3 Fluxo lógico de atualização segura

INÍCIO
↓
Receber pacote de atualização
↓
Verificar assinatura digital do fabricante
↓
Confirmar cadeia de certificação
↓
Checar CRL/OCSP
↓
Validar versão e compatibilidade
↓
Aplicar em janela autorizada
↓
Executar teste de integridade pós-instalação
↓
Registrar log e hash da versão implantada
↓
Liberar operação clínica
↓
FIM

13. Benefícios institucionais de uma arquitetura madura

Quando a cadeia de confiança do dispositivo é tratada com seriedade, o hospital conquista 
ganhos que vão muito além da TI. Há melhora de:	

1. segurança assistencial,
2. rastreabilidade regulatória,
3. legitimidade documental,
4.resiliência operacional,
5.governança de atualização,
6.controle de superfície de ataque,
7. confiabilidade dos dados usados por IA,
8. capacidade de resposta a incidentes.
Em síntese, a criptografia deixa de ser “camada invisível” e passa a atuar como componente
real de qualidade clínica.

14. Desafios

Ainda assim, não se trata de campo simples.
Hospitais convivem com:
1. equipamentos legados,
2. fabricantes heterogêneos,
3. limitações de interoperabilidade,
4. janelas curtas de parada,
5. pressão assistencial constante,
6. equipes clínicas sem formação técnica aprofundada,
7, governança fragmentada entre engenharia clínica, TI, segurança, compras e fornecedores.
    
Isso faz com que o tema exija:
1.	tecnologia,
2.	cultura institucional, 
3.	processos bem definidos,
4.	liderança técnica capaz de integrar segurança da informação, engenharia de sistemas e 
responsabilidade assistencial.

15. Perspectivas futuras

O futuro próximo aponta para ecossistemas hospitalares com:
1. identidade criptográfica nativa por dispositivo,
2. atualização segura automatizada,
3. atestado remoto de integridade,
4. segmentação dinâmica por risco,
5. PKI mais especializada para IoMT,
6. edge computing com validação local,
7. auditoria contínua do ciclo de vida criptográfico,
8. integração entre segurança cibernética, tecnovigilância e governança de IA.

Nesse cenário, o médico que compreende esses fundamentos deixa de ser 
mero usuário terminal 
da tecnologia. Ele passa a ter condições de dialogar com profundidade sobre segurança do cuidado 
em um mundo onde o risco clínico e o risco computacional tornaram-se inseparáveis.

Considerações Finais

O terceiro artigo desta série mostra que a maturidade criptográfica real na saúde digital vai muito além 
de apenas criptografar bancos de dados ou proteger canais externos. Ela está em algo mais desafiador: 
garantir a legitimidade técnica dos dispositivos que participam diretamente do cuidado. 
Dispositivos médicos inteligentes, redes IoMT, firmware, gateways de borda, certificados, boot seguro, 
PKI, CRL, OCSP, TLS 1.3 e mTLS não são detalhes periféricos da computação, mas sim peças centrais 
da segurança assistencial. 

Um hospital só pode confiar plenamente em seu ecossistema digital quando consegue responder com 
clareza: quem é este dispositivo, por que confio nele, qual software ele executa, quem validou sua identidade, 
qual cadeia o sustenta e porque ele tem direito legítimo de estar na rede hoje. 

Na medicina atual, essa resposta não é apenas responsabilidade da TI, mas também parte do compromisso
institucional de quem cuida da vida em um ambiente cada vez mais mediado por máquinas, dados, algoritmos
e decisões sustentadas por criptografia.