Uma identidade verificável para toda a sua organização.

Não apenas a empresa: cada departamento, dispositivo, serviço e agente, verificável pelas instituições com quem trabalha, sem um fornecedor partilhado no meio.

Discuta esta arquitetura para a sua organização

Quatro limitações estruturais das ferramentas de identidade padrão

O OpenID Connect, o OAuth e a infraestrutura de chave pública (PKI) são ferramentas excelentes dentro da fronteira de uma única organização. A federação não elimina essa fronteira, desloca-a: para acordos negociados previamente entre cada par de organizações, ou para um intermediário central que nenhuma delas controla. Não são falhas. São restrições arquitetónicas que se tornam visíveis no momento em que a confiança tem de abranger várias organizações.

Confiança nos tokens

Onde as ferramentas padrão param

Os tokens de acesso são fiáveis dentro da fronteira de quem os emitiu. Entre organizações, essa fronteira quebra-se: a organização recetora não tem forma de verificar a autoridade da organização emissora.

Solução DKMS / Verimesh

O DKMS estabelece uma identidade criptográfica autocertificante: a identidade de cada organização é verificável por qualquer outra organização, sem depender de uma autoridade de certificação partilhada.

Granularidade do acesso

Onde as ferramentas padrão param

Os scopes são grosseiros, concebidos para permissões ao nível da aplicação. O consentimento ao nível do grafo de recursos, quando atravessa fronteiras organizacionais, exige um modelo diferente.

Solução DKMS / Verimesh

O motor de políticas do Verimesh (Open Policy Agent, OPA) permite um controlo de acesso programável e granular que opera através das fronteiras de confiança organizacionais.

Auditabilidade

Onde as ferramentas padrão param

Os registos de autenticação param na organização que os escreveu. As pistas de auditoria interorganizacionais (quem acedeu a quê, quando e autorizado por quem) exigem um encadeamento criptográfico que a autenticação local nunca foi concebida para fornecer.

Solução DKMS / Verimesh

O KERI (Key Event Receipt Infrastructure) fornece pistas de auditoria que tornam evidente qualquer adulteração. Cada evento de identidade é criptograficamente encadeado e verificável de forma independente, criando auditabilidade interorganizacional.

Arquitetura de confiança

Onde as ferramentas padrão param

Estes modelos pressupõem uma autoridade central: um fornecedor de identidade em quem todos confiam. A confiança institucional distribuída entre organizações soberanas não pode depender de uma única autoridade.

Solução DKMS / Verimesh

O DKMS permite a gestão soberana da identidade: cada organização controla as suas próprias raízes criptográficas. A confiança é estabelecida bilateralmente, não delegada num coordenador central.

Mantenha o seu fornecedor de identidade. Acrescente confiança entre instituições.

KERI identity infrastructure architecture diagram showing key event log, witnesses, watchers, and cross-organisational trust establishment
Infraestrutura de identidade KERI: identificadores autocertificantes, recibos de eventos de chave e confiança bilateral sem autoridade central

Trata-se de uma capacidade nova. O seu fornecedor de identidade, e os protocolos que o sustentam (OpenID Connect, OAuth, SAML), estão comprovados para a autenticação dentro de uma única organização, e permanecem onde estão. O DKMS (Decentralized Key Management System) faz aquilo para que estes nunca foram construídos: dá a cada organização uma identidade autocertificante que qualquer outra instituição pode verificar diretamente, sem um fornecedor partilhado entre ambas. O Verimesh entrega o DKMS e comunica com os sistemas que já utiliza, pelo que amplia o que já tem em vez de o abandonar.

Construir sobre os programas nacionais de identidade eletrónica

O programa swiyu é a infraestrutura federal suíça de identidade eletrónica. A sua primeira credencial, a licença eletrónica de aprendizagem de condução, está ativa em todos os cantões desde dezembro de 2025, com cerca de 27.000 emitidas. A entrada em funcionamento da infraestrutura de confiança da e-ID está prevista para o primeiro semestre de 2027, enquanto a introdução da própria e-ID foi adiada, sem que tenha sido anunciada uma nova data. Os identificadores dos emissores e as declarações de confiança são publicados em registos federais centrais, e a credencial fica no dispositivo do próprio cidadão. Espera-se que a mesma infraestrutura suporte credenciais de cantões, universidades e empregadores quando abrir a emissores em geral.

A Vereign está envolvida no processo suíço da e-ID desde o início, através de reuniões de participação e intercâmbios bilaterais, e Georg Greve foi membro do Technical Advisory Circle, que a fedpol convocou e que contribuiu para a decisão tecnológica de janeiro de 2024.

A União Europeia segue o mesmo caminho. O Regulamento (UE) 2024/1183 exige que cada Estado-Membro disponibilize pelo menos uma Carteira de Identidade Digital Europeia (EUDI), e a credencial de identidade fundamental da pessoa provém de entidades designadas pelo Estado. Ambos os programas respondem à mesma pergunta, e respondem-lhe bem: como é que uma pessoa prova quem é perante uma instituição. Nenhum deles especifica a identidade dos departamentos, dispositivos, serviços e agentes que uma organização realmente opera, e ambos ancoram a confiança em registos centrais, razão pela qual nenhum mantém um registo das partes confiantes que verificam credenciais: à escala da União seriam demasiadas para listar.

Para as organizações que implementam o Verimesh, o swiyu e o EUDI tornam-se pontos de partida sobre os quais pode construir. Hoje, a ponte está concebida, não entregue: quando esses sistemas chegarem à produção, aceita uma e-ID estatal no onboarding, usa-a como raiz de confiança, deixa o Verimesh levar essa confiança através das instituições, jurisdições e sistemas que um fluxo de trabalho real atravessa, e emite as suas próprias credenciais de volta para a mesma carteira.

O Verimesh implementa esta arquitetura

O Verimesh (anteriormente o projeto Stargate) é a implementação em produção da arquitetura de confiança descrita acima. Funciona com a autenticação que já utiliza e acrescenta aquilo que essa camada nunca foi construída para fazer: identidade organizacional ancorada em DKMS para a confiança entre instituições, um motor de políticas programável (Open Policy Agent), significado partilhado dos dados através da Overlays Capture Architecture (OCA) e entrega de mensagens com evidência de adulteração através do SEAL.

O Verimesh está em produção no sistema de saúde suíço: o gateway e a CA central na HIN funcionam em produção, as primeiras instituições estão migradas e a utilizá-las, e a migração na rede HIN está prevista para concluir antes do final de 2026.

Descubra o Verimesh

Uma identidade organizacional, até à camada de rede.

O Verimesh transporta o seu tráfego sobre WireGuard, e a chave do túnel está ancorada na mesma identidade organizacional que as aplicações acima dela. As chaves de túnel Curve25519 de cada organização derivam do seu próprio material de Decentralized Key Management (DKMS): nenhuma autoridade central as emite, e não existe lacuna entre a identidade ao nível da rede e ao nível da aplicação. A rotação de chaves é coordenada com o DKMS (pré-rotação construída sobre KERI), e cada estabelecimento de túnel é auditável face ao Key Event Log. Nenhum intermediário detém o fluxo de dados.

Silencioso por conceção

Os pacotes não autenticados não recebem resposta. A mesh é invisível a uma análise de portas: não há superfície de ataque pública para sondar.

Cerca de 4.000 linhas que se podem ler

O WireGuard tem aproximadamente 4.000 linhas de código, contra cerca de 100.000 do OpenVPN e 400.000 do IPsec. A auditabilidade é, em si mesma, uma propriedade de segurança.

Sem negociação, sem downgrade

Primitivas modernas fixas: Curve25519, ChaCha20-Poly1305, BLAKE2s, o handshake Noise_IKpsk2. O perfect forward secrecy com renovação de chaves a cada cerca de dois minutos e a ocultação de identidade são integrados, não configurados.

Soberano até ao fio

Open Source de ponta a ponta, self-hosted, sem plano de controlo SaaS no percurso. A soberania estende-se da aplicação até ao próprio transporte.

Infraestrutura comprovada, sem surpresas

No kernel principal do Linux desde 2020. Nada aqui é criptografia inédita, e sustenta hoje a implementação do Verimesh com a HIN.

Pronto para a migração quântica

A camada de chave pré-partilhada do WireGuard já protege o tráfego de hoje contra ataques de «armazenar agora, decifrar depois». E porque as chaves de túnel derivam do DKMS, a passagem para algoritmos pós-quânticos é uma rotação de chaves de rotina sobre o Key Event Log existente, e não uma reemissão massiva de uma só vez.

Veja o ciclo de vida completo da ligação

A aplicação do consentimento é o propósito central do DKMS

O artigo 71(8) do EHDS cria uma restrição estrutural que nenhuma autoridade central pode satisfazer: quando uma pessoa retira o consentimento para uso secundário, essa retirada deve propagar-se a cada instituição que detém ou derivou dados da fonte original. Nenhum CA pode co-assinar a retirada; nenhum fornecedor de identidade pode cascadear a revogação. Esta restrição é arquitetonicamente incompatível com a identidade centralizada.

O DKMS satisfaz cinco requisitos exigidos pelo artigo 71 do EHDS: identificadores vinculados à pessoa que sobrevivem a uma nova inscrição; registos de retirada verificáveis e com carimbo de data/hora, ancorados no Key Event Log; reversibilidade sem re-identificação; propagação entre responsáveis pelo tratamento sem acordos bilaterais entre cada par de instituições; e impossibilidade de ligar o registo do consentimento aos dados que cobre.

Depois de os dados terem sido divulgados (partilhados numa rede hospitalar, num consórcio de investigação ou numa cadeia de pagadores), um opt-out subsequente tem ainda de chegar a cada responsável pelo tratamento a jusante. Os Key Event Logs do DKMS propagam a revogação criptograficamente: o KEL de cada responsável é append-only e atestado por testemunhas, pelo que uma revogação acrescentada na periferia da pessoa se torna verificável em cada instituição que detém um registo derivado.

Ler a tese sobre arquitetura de consentimento

Comprovado no sistema de saúde suíço, escolhido para implementação à escala nacional

A HIN (Health Info Net) é a rede suíça de informação de saúde, que liga hospitais, consultórios de medicina geral e prestadores especializados através das fronteiras cantonais. O SEAL, o produto de entrada nesta camada de confiança, já transporta mais de 800.000 entregas verificadas por mês. O Verimesh está em produção no sistema de saúde suíço: o gateway e a CA central na HIN funcionam em produção, as primeiras instituições estão migradas e a utilizá-las, e a migração na rede HIN está prevista para concluir antes do final de 2026.

HIN (Health Info Net)

800.000+

entregas verificadas por mês

Arquitetura de confiança: perguntas frequentes

O que é DKMS?
O DKMS (Decentralised Key Management) é a categoria de infraestrutura de identidade em que a confiança criptográfica é ancorada no limite organizacional, e não numa autoridade de certificação central. Cada organização controla o seu próprio material criptográfico e o seu próprio Key Event Log (KEL) append-only. A Vereign co-fundou a DKMS Alliance para formalizar o DKMS como categoria ao lado do PKI e do OAuth.
Em que é que o DKMS é diferente do PKI?
O PKI ancora a confiança em autoridades de certificação centrais, pelo que o comprometimento de uma única CA afeta todos os sujeitos que essa CA assinou. O DKMS ancora a confiança no Key Event Log próprio de cada organização: uma falha fica limitada a um único controlador, a rotação de chaves é nativa e atómica através de compromissos de pre-rotation, e a confiança entre jurisdições não exige tratados de reconhecimento entre CAs. O DKMS é PKI na periferia, sem o ponto único de falha.
O DKMS substitui o OAuth?
Não. O OAuth é correto para fluxos de token locais dentro de uma única organização e deve continuar a ser usado aí. O DKMS resolve um problema para o qual o OAuth nunca foi concebido: estabelecer confiança verificável entre organizações sem um intermediário partilhado. Mantenha o seu fornecedor de identidade e acrescente o DKMS para a confiança entre instituições.
O DKMS está pronto para pós-quântico?
Sim. O DKMS trata a rotação de chaves como uma operação de primeira classe. Quando são necessários algoritmos pós-quânticos, a migração torna-se uma rotação de chaves de rotina sobre o Key Event Log existente, em vez de uma reemissão massiva de certificados. A propriedade de pre-rotation do KERI significa que a próxima chave pode ser qualquer algoritmo a que o controlador se comprometa (incluindo esquemas pós-quânticos) sem quebrar as relações de confiança existentes.
Quem mantém o DKMS?
O DKMS é uma especificação aberta. A DKMS Alliance, cofundada pela Vereign, coordena a especificação. A implementação de referência do KERI (o protocolo subjacente ao DKMS) é mantida como Open Source pela comunidade KERI mais ampla. O Verimesh da Vereign é uma implementação AGPLv3+ da camada DKMS: o seu gateway e a sua CA central estão em produção na HIN, com os primeiros clientes migrados. O SEAL é o sistema de entrega cifrada em enxame da Vereign, sob AGPLv3+, e é, no plano arquitetónico, independente do DKMS.
O DKMS requer blockchain?
Não. O DKMS usa Key Event Logs (KELs) encadeados por hash para integridade append-only, mas não existe camada de consenso, nem token, nem ledger distribuído. A decisão de evitar a blockchain é deliberada: a infraestrutura regulada exige verificação determinística, não finalidade probabilística.
A Vereign pode ajudar-me a integrar a carteira swiyu ou EUDI?
Sim, ao nível da conceção, mas ainda não em produção: os componentes da ponte são hoje arquitetónicos, não entregues. Quando esses sistemas estiverem em funcionamento, aceita uma e-ID estatal (swiyu, EUDI) no onboarding e usa-a como raiz de confiança; depois, o Verimesh leva essa confiança mais além: através das instituições, jurisdições e sistemas que um fluxo de trabalho real atravessa, incluindo as pessoas, funções e agentes que atuam neles, e através do que acontece a uma decisão de consentimento depois de os dados já terem sido partilhados.
A Vereign é concorrente das carteiras nacionais?
Não. Uma carteira nacional dá a uma pessoa uma identidade verificável. O Verimesh dá essa identidade verificável a uma organização, abrangendo os departamentos, dispositivos, serviços e agentes que esta opera, pelo que os dois funcionam em camadas diferentes e compõem-se em vez de se sobreporem. O Verimesh mantém a sua própria camada de confiança e foi concebido para falar os protocolos das carteiras na periferia.
A ponte do Verimesh para o swiyu ou EUDI está em produção?
Não. Os componentes da ponte (um fornecedor OID4VCI/VP, a exportação de credenciais, o mapeamento de identificadores) são arquitetónicos, demonstrados ao nível do design, não entregues. O próprio Verimesh está em produção no sistema de saúde suíço: o gateway e a CA central na HIN funcionam em produção, as primeiras instituições estão migradas e a utilizá-las, e a migração na rede HIN está prevista para concluir antes do final de 2026.

Reserve uma revisão arquitetónica. Mapeamos isto para as suas fronteiras de confiança.

Esta arquitetura está implementada no sistema de saúde suíço à escala nacional. Quer esteja a avaliar alternativas à identidade centralizada ou a planear a troca de dados interorganizacional, mapeá-la-emos para o seu ambiente numa chamada de 30 minutos.

Reserve uma revisão arquitetónica
Proteção de dados suíça Conformidade com o RGPD Open Source AGPLv3+ Alojamento suíço
Veja como a arquitetura funciona passo a passo