Segurança e programa de bug bounty

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.

O que está no escopo

Relate qualquer coisa que possa prejudicar a segurança ou a privacidade dos nossos usuários em:

• O mecanismo principal: identidade do dispositivo e armazenamento de chaves, pareamento por QR, sessões criptografadas, protocolo de comunicação, transportes (QUIC, TCP, WebRTC), descoberta, confiança e permissões, e todos os recursos (transferência de arquivos, área de transferência, links, Continue, MyDrop, SmartPrint, navegador de arquivos, notificações, entrada remota, câmera).
• Os aplicativos: a ferramenta de linha de comando pdb, o aplicativo para desktop Windows e seus instaladores, e o aplicativo Android.
• O serviço de rendezvous que operamos para conexões pela internet.
• Este site, personaldevicebridge.com.
• Nosso processo de publicação: workflows de build e publicação, assinatura de código, somas de verificação e procedência.

Temos interesse especial em: parear sem ver o código QR, quebrar a criptografia ou a autenticação de dispositivos, um dispositivo pareado fazendo mais do que foi permitido, ler ou gravar arquivos fora da pasta prevista, executar código por meio de dados recebidos e o serviço de rendezvous descobrir ou alterar o conteúdo das mensagens.

O que está fora do escopo

• Negação de serviço por puro volume de tráfego, testes de carga nos nossos serviços hospedados e spam.
• Engenharia social ou phishing contra a nossa equipe ou os nossos usuários, e ataques físicos.
• Ataques que exigem um dispositivo ou conta de usuário já comprometidos (por exemplo, malware rodando como o usuário), um celular com root ou jailbreak, ou acesso físico a um dispositivo desbloqueado.
• Informações visíveis na rede local por projeto, como a presença de um dispositivo ou o volume de tráfego.
• Limitações já descritas na nossa documentação de segurança, a menos que você demonstre um impacto maior.
• Falhas nas próprias plataformas de terceiros (Cloudflare, Railway, GitHub, Google) — relate-as ao fornecedor. A forma como nós as usamos está no escopo.
• Relatos sem impacto de segurança demonstrado: cabeçalhos ausentes em páginas estáticas, configurações SPF/DMARC de e-mail, self-XSS, números de versão ou saídas de scanners sem prova de conceito.

Como relatar

Envie um e-mail para [email protected] 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;
• se e como você gostaria de receber os créditos.

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.

Recompensas

As recompensas são discricionárias. Dependem do impacto, da qualidade do relato e de o problema ser novo para nós, e a primeira pessoa a relatar um problema é elegível. Avaliamos a gravidade com o CVSS (v3.1 ou v4.0) com base na versão mais recente e explicamos a nossa avaliação.

Duplicatas, problemas fora do escopo e relatos que violem esta política não são recompensados. Vários problemas encadeados contam como uma única descoberta, com a gravidade resultante.

As recompensas são pagas em won sul-coreano; os valores em dólares são aproximados. O pagamento exige os dados pedidos pela legislação tributária coreana e pelo nosso banco e não pode ser feito onde a lei ou sanções o proíbam. Você também pode nos pedir para doar a recompensa a uma instituição de caridade.

Porto seguro

Se você se esforçar de boa-fé para seguir esta política, consideramos a sua pesquisa autorizada. Não moveremos nem apoiaremos ações judiciais contra você e não o denunciaremos às autoridades por isso. Se um terceiro agir contra você por uma pesquisa que seguiu esta política, deixaremos claro que você tinha a nossa autorização.

Agir de boa-fé significa que você:

• testa apenas os seus próprios dispositivos, instalações, pareamentos e caixas do serviço de rendezvous;
• não acessa, altera nem guarda dados de outras pessoas — se encontrá-los, para, nos avisa e os apaga;
• não prejudica os nossos serviços nem deixa alterações permanentes;
• nos dá tempo para corrigir o problema antes de divulgá-lo;
• nunca pede pagamento em troca de não divulgar.

Não podemos autorizar testes em sistemas que não são nossos. Na dúvida, pergunte antes.

Divulgação coordenada

Dê-nos 90 dias a partir do seu relato — ou até a publicação de uma correção, se ocorrer antes — antes de divulgar detalhes. Para uma correção complexa, podemos pedir uma breve prorrogação e combinaremos a data com você.

Depois da correção, publicamos um aviso de segurança nas notas da versão e damos o crédito a você, a menos que prefira ficar anônimo. Se um problema estiver sendo explorado ativamente, podemos divulgá-lo antes, em conjunto com você.

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.

Hall da fama

Obrigado a todos que ajudam a manter nossos usuários seguros. Pesquisadores que relatam problemas válidos são listados aqui, com a permissão deles.

Ainda não há pesquisadores reconhecidos — o seu relato pode ser o primeiro.