Segurança

Como seus dados são protegidos, em palavras simples

O pareamento começa com um código QR no seu PC. Ele contém um segredo de uso único que expira em dois minutos, então só um dispositivo que realmente viu a sua tela consegue parear. Depois, as duas telas mostram o mesmo código de 6 dígitos e você confirma que eles coincidem.

• Toda conexão é criptografada de ponta a ponta com o protocolo Noise (X25519, ChaCha20-Poly1305, BLAKE2s). Cada dispositivo tem uma chave própria que nunca sai dele, e os dispositivos se reconhecem por essa chave — não por endereço IP, nome ou conta.
• Cada conexão e cada fluxo de dados usa chaves novas (sigilo direto): uma chave roubada no futuro não consegue decifrar o tráfego gravado antes.
• A criptografia fica acima da rede, então protege você da mesma forma no Wi-Fi, pela internet (QUIC, TCP ou WebRTC) e pelo nosso serviço de rendezvous, que apenas repassa mensagens lacradas que não consegue ler.
• Estar pareado não significa poder tudo: cada dispositivo recebe só as permissões que você concede, e a entrada remota e a câmera pedem seu consentimento a cada sessão.
• Arquivos, links e dados da área de transferência recebidos são verificados antes do uso: não podem sair da pasta de downloads, tipos de link perigosos são recusados e os tamanhos são limitados.

A especificação técnica completa e o modelo de ameaças estão na nossa documentação de segurança, que compartilhamos com pesquisadores e auditores.

Status da auditoria

Preferimos ser precisos a ser impressionantes:

• Revisão de segurança interna: concluída. O projeto, o pareamento, a criptografia de sessão, as permissões e a validação de entradas foram revisados com base em um modelo de ameaças por escrito, e as regras de segurança são cobertas por testes automatizados executados a cada alteração.
• Verificações automatizadas: alertas de segurança e licenças das dependências são checados a cada alteração, e as partes que leem entradas não confiáveis passam por fuzzing toda semana.
• Auditoria externa: planejada para antes da versão 1.0 e ainda não realizada. Quando for concluída, publicaremos aqui o auditor, o escopo e um resumo das constatações.

Até lá, o Personal Device Bridge é uma versão de prévia. Leve isso em conta antes de usá-lo com dados muito sensíveis.

Verifique o que você baixa

Você não precisa confiar apenas na nossa palavra para saber que um download é autêntico:

• Somas de verificação: toda versão inclui um arquivo SHA256SUMS que cobre todos os seus arquivos, para você confirmar que a sua cópia é exatamente a que publicamos.
• Builds reproduzíveis: a ferramenta de linha de comando para Linux é compilada de forma determinística. Qualquer pessoa com o código-fonte da tag da versão pode recompilá-la e obter um arquivo idêntico bit a bit; uma verificação automática a compila duas vezes em ambientes diferentes e falha se um único byte for diferente.
• Procedência do build: nosso fluxo de publicação está preparado para anexar a cada arquivo um atestado de procedência SLSA assinado (Sigstore), registrando qual workflow e qual commit o geraram; você pode conferi-lo com o comando “gh attestation verify”. O GitHub habilita isso quando o repositório de código é público, e avisaremos aqui quando estiver ativo.
• Assinatura de código: nosso pipeline de publicação assina os programas e instaladores do Windows com Authenticode (Azure Artifact Signing); antes de executar um arquivo, você pode conferir o editor em Propriedades → Assinaturas Digitais.

Os builds para Windows e Android ainda não são reproduzíveis; esse trabalho está planejado. As instruções de verificação passo a passo para bash e PowerShell estão no nosso guia de builds reproduzíveis, disponível mediante solicitação.

Testes contínuos

Todo decodificador que lê dados de outro dispositivo ou da rede — envelopes de mensagens, links de pareamento, beacons de descoberta, nomes de arquivos e mensagens de cada recurso — passa toda semana por fuzzing com o libFuzzer, que o alimenta com milhões de entradas malformadas para encontrar travamentos e verificações de segurança falhas.

Além disso, testes unitários, de integração e de ponta a ponta rodam no Windows e no Linux a cada alteração, incluindo testes em que dois processos reais se pareiam e transferem arquivos pela rede.

Como relatar

Envie um e-mail para projectteamforyou@gmail.com com o assunto “[SECURITY] título curto”, em coreano ou inglês. Inclua, por favor:

• o aplicativo ou componente afetado e a versão;
• qual é o problema e o que um invasor poderia fazer com ele (um vetor CVSS é bem-vindo);
• os passos para reproduzir ou uma prova de conceito, e a plataforma em que você testou.

Não relate vulnerabilidades por issues públicas nem por redes sociais.

Criptografia: ainda não publicamos uma chave PGP. Quando publicarmos, ela ficará na pasta /.well-known/ deste site e constará em personaldevicebridge.com/.well-known/security.txt. Até lá, se o seu relato tiver detalhes sensíveis de exploração, envie primeiro uma mensagem curta sem eles e combinaremos um canal seguro com você.

Nosso código-fonte é proprietário. Se você precisar de acesso a ele para pesquisar ou confirmar uma descoberta, peça; analisamos cada pedido individualmente.

O que acontece depois do seu relato

• Confirmamos o recebimento do seu relato em até 72 horas.
• Fazemos a triagem — validade, gravidade e versões afetadas — em até 7 dias e atualizamos você pelo menos a cada 14 dias até a resolução.
• Metas de correção a partir da triagem: Crítica em até 30 dias (com uma mitigação em até 7 dias, quando possível), Alta em até 60 dias, Média em até 90 dias, Baixa em uma versão programada posterior.

Somos uma equipe pequena. Se não conseguirmos cumprir uma meta, explicaremos o motivo e quando esperar a correção.

Contatos para ferramentas

Nossos contatos também são publicados no formato padrão legível por máquina (RFC 9116) em personaldevicebridge.com/.well-known/security.txt, que aponta para esta página. Respondemos em coreano ou inglês.