Compartilhamento em equipe com criptografia de ponta a ponta
O compartilhamento em equipe com criptografia de ponta a ponta se apoia numa única ideia: o conteúdo fica trancado com chaves que só os dispositivos da equipe têm, e o trabalho do servidor é entregar cópias seladas dessas chaves às pessoas certas sem conseguir abri-las. Todo o resto — convidar alguém, remover alguém, recuperar uma senha perdida — é uma questão de quem sela uma nova cópia de qual chave para quem.
A resposta curta para a pergunta que a maioria das pessoas realmente tem: quando um membro é adicionado, alguém que já tem a chave de canal sela uma cópia dela para o recém-chegado. Quando um membro é removido, o servidor apaga a cópia dele, e o app de um membro que continua na equipe gera uma nova versão da chave que a pessoa removida nunca recebe. Esse segundo passo, chamado rotação de chaves, é o que separa a remoção criptográfica de simplesmente esconder uma pasta na interface.
Este artigo apresenta os conceitos no nível de que um líder de equipe ou um revisor de segurança precisa. Ele usa o Speak-Y Teams como exemplo prático, porque é o design que conseguimos descrever com precisão, e o compara com outros designs publicados nos pontos em que diferem.
Três camadas de chaves, e por que são três
Uma transcrição de reunião compartilhada num espaço de equipe criptografado de ponta a ponta é protegida por uma cadeia de chaves, e não por uma única senha:
- Uma chave de item. Cada item compartilhado recebe uma chave aleatória própria, que criptografa a transcrição, o resumo, os participantes e os itens de ação.
- Uma chave de canal. A chave de item é embrulhada — criptografada — com a chave do canal em que o item foi compartilhado. Uma única chave de canal cobre todos os itens do canal.
- Um par de chaves de membro. Cada pessoa tem uma chave pública, que os outros podem usar para selar dados destinados a ela, e uma chave privada que nunca sai dos dispositivos dela. A chave de canal é selada separadamente para cada membro com a chave pública desse membro.
As camadas existem para que as operações comuns continuem baratas. Compartilhar uma gravação nova mexe em apenas uma chave de item. Adicionar um membro significa selar uma chave de canal para mais uma pessoa, e não criptografar de novo cada transcrição. Fazer a rotação de uma chave de canal depois de uma remoção muda uma única chave e embrulha de novo as pequenas chaves de item abaixo dela, enquanto o volumoso conteúdo criptografado fica como está.
No Speak-Y, o par de chaves de membro é derivado da senha de criptografia da conta, então a mesma senha gera as mesmas chaves em todos os dispositivos. Os blocos de construção são «sealed boxes» padrão de chave pública e criptografia autenticada, e não criptografia caseira.
O que o servidor armazena e o que ele não consegue ver
O servidor é uma caixa de correio para texto cifrado. Ele guarda os itens criptografados, as cópias seladas das chaves de canal endereçadas a cada membro e estrutura suficiente para encaminhá-las.
Ele consegue ver a estrutura da equipe: quantos espaços de trabalho e canais existem, quem é membro de qual, se um canal é público ou privado, quando uma chave foi emitida ou revogada, e metadados básicos de cada item — tamanho, duração e horário. Ele não consegue ver o conteúdo das transcrições e dos resumos e, no Speak-Y, também não consegue ver os nomes dos espaços de trabalho e dos canais, que são criptografados com as mesmas chaves do conteúdo. Um canal chamado «Aquisição — Projeto Falcão» já é, por si só, informação.
Ser preciso sobre metadados faz parte de uma promessa honesta de ponta a ponta. O verbete do glossário sobre E2EE explica por que nenhum design esconde tudo.
O que acontece quando alguém entra
A dificuldade de adicionar um membro é que o servidor não consegue repassar uma chave que ele não consegue ler. Só um cliente que já tem a chave consegue selar uma cópia para a chave pública do recém-chegado, e essa chave pública só passa a existir depois que ele aceita o convite.
Há duas formas de contornar isso. A primeira é esperar que alguém da equipe abra o app e sele as chaves para o novo membro, o que funciona, mas deixa uma lacuna se quem convidou estiver de férias. O Speak-Y mostra essa lacuna como um estado próprio, Aguardando a chave do canal, e não como um erro de rede.
A segunda é fazer o convite levar o que o recém-chegado precisa. Um link de
convite do Speak-Y contém a chave do espaço de trabalho no fragmento, a parte
da URL depois de #, que nunca é enviada ao servidor. Os canais guardam uma
cópia da própria chave trancada com a chave do espaço de trabalho, então um
novo membro consegue abrir os canais do espaço de trabalho assim que aceita,
sem que mais ninguém esteja online. O custo é que o próprio link dá acesso, e
é por isso que os convites são de uso único, expiram e devem ser enviados do
jeito que você enviaria uma senha.
Canais privados acrescentam mais uma regra: a chave do espaço de trabalho não os abre. Um membro do canal privado adiciona alguém selando a chave desse canal diretamente para a pessoa.
O que acontece quando alguém é removido
É aqui que os designs mais diferem, e onde a pergunta «isso é mesmo de ponta a ponta?» ganha uma resposta concreta.
Revogação de acesso significa que o servidor para de entregar dados à pessoa removida. Ela é aplicada pela política do servidor, e as chaves não mudam. O white paper de segurança do 1Password descreve assim o próprio compartilhamento, afirmando com clareza que remover alguém de um cofre, grupo ou equipe não é aplicado criptograficamente e que as chaves não são trocadas. É uma troca documentada e deliberada; uma pessoa que tivesse guardado a chave antes ainda conseguiria ler dados do cofre que obtivesse mais tarde.
Rotação de chaves significa que a chave da pessoa removida para de funcionar. No Speak-Y, quando um membro é removido de um espaço de trabalho:
- O servidor apaga imediatamente as cópias seladas das chaves dessa pessoa.
- O app do membro que faz a remoção gera novas versões das chaves de canal e da chave do espaço de trabalho, e as sela só para as pessoas que ficam, além do Recovery Kit do espaço de trabalho.
- Os nomes dos canais e do espaço de trabalho são criptografados de novo com as novas versões.
- As cópias das chaves de canal trancadas com a antiga chave do espaço de trabalho são trancadas de novo com a nova, então um link de convite antigo não abre mais nada.
- Os itens existentes são embrulhados de novo com a nova versão da chave em segundo plano.
Remover alguém de um único canal privado faz a rotação da chave desse canal da mesma forma.
Os protocolos de mensagens seguem o mesmo princípio. A visão geral da criptografia do WhatsApp (edição de fevereiro de 2026) diz que, sempre que um membro sai de um grupo, todos os participantes apagam a chave do grupo e recomeçam. O padrão Messaging Layer Security do IETF, RFC 9420, publicado em julho de 2023, leva o grupo a uma nova época na remoção, com novo material de chave que o membro removido não conhece.
O que a rotação não consegue tomar de volta
A rotação protege o futuro, não o passado. Tudo o que a pessoa removida já abriu, baixou ou copiou no próprio dispositivo continua com ela — nenhum esquema de criptografia alcança a memória de alguém ou o disco dela. O que a rotação garante é mais restrito e, ainda assim, valioso: as novas gravações compartilhadas depois da remoção ficam ilegíveis para ela, e a chave antiga não abre nada que ela venha a baixar do servidor mais tarde.
Duas consequências para o modo de trabalhar de uma equipe:
- Compartilhe num canal o que todos nesse canal podem guardar. Um canal se parece mais com enviar um e-mail do que com emprestar uma pasta.
- A rotação não resolve nada diante de um membro que continua na equipe e encaminha conteúdo para outro lugar. Isso é uma questão de confiança, não de criptografia.
O guia sobre a base de conhecimento da equipe explica como decidir o que vai para cada canal.
Quando alguém esquece a senha
Num sistema em que o fornecedor não guarda nenhuma chave, o «esqueci a senha» não pode ser resolvido pelo suporte — e esse é justamente o ponto. Ele precisa ser resolvido por alguém da equipe.
O Speak-Y faz isso com um Recovery Kit: quando um espaço de trabalho é criado, o proprietário salva um arquivo com uma chave de recuperação, e cada chave de canal também é selada para ela. Se um membro perde a senha e define uma nova, quem tem o Kit consegue reemitir as chaves de canal para o novo par de chaves dele. O Kit restaura o acesso apenas aos canais da equipe; ele nunca cobre as gravações pessoais de ninguém. É também o arquivo mais sensível que a equipe tem, e deve ficar onde a equipe guarda os seus outros segredos críticos.
Compartilhar com alguém de fora da equipe
Às vezes uma transcrição precisa chegar a um cliente ou a um colega que não tem conta. Um link público de compartilhamento do Speak-Y criptografa uma cópia separada do item com uma chave nova própria e coloca essa chave no fragmento da URL. Qualquer pessoa com o link completo consegue ler o item num navegador; o servidor guarda apenas texto cifrado. Revogar o link o apaga do servidor. Assim como um convite, o link é o segredo, e uma cópia que alguém já abriu não é recolhida.
Quatro perguntas para fazer a qualquer fornecedor
- O que acontece com as chaves quando um membro é removido? «O acesso é revogado» é uma resposta de política; «a chave passa por rotação» é uma resposta criptográfica.
- O servidor consegue ler os nomes dos canais e dos espaços de trabalho? Os nomes muitas vezes dizem tanto quanto o conteúdo.
- Se um membro esquecer a senha, quem consegue restaurar o acesso? Se a resposta for o fornecedor, o fornecedor guarda uma chave.
- Um link de convite ou de compartilhamento leva material de chave, e ele expira? Qualquer uma das respostas pode ser aceitável, desde que o fornecedor saiba qual é a dele.
No Speak-Y, o compartilhamento em equipe está disponível no app para macOS. Criar um espaço de trabalho é possível a partir do plano Pro, e os colegas de equipe entram de graça em qualquer plano. A página do Speak-Y Teams mostra como os canais compartilhados funcionam no dia a dia, e por que as notas de reunião precisam de criptografia de ponta a ponta explica por que a transcrição precisa acontecer no seu dispositivo para que tudo isso seja possível.
FAQ
Como uma equipe compartilha arquivos criptografados de ponta a ponta se o servidor não consegue lê-los?
Cada item compartilhado é criptografado com uma chave aleatória própria, e essa chave é trancada com uma chave de canal. Depois, a chave de canal é selada separadamente para cada membro com a chave pública desse membro. O servidor armazena apenas essas cópias seladas, então consegue entregá-las às pessoas certas, mas não consegue abrir nenhuma delas.
O que acontece com as chaves de criptografia quando alguém é removido de um canal da equipe?
Num design que aplica a remoção de forma criptográfica, o servidor apaga a cópia da chave de canal da pessoa removida, e o app de um membro que continua na equipe gera uma nova versão da chave e a sela só para quem fica. Em seguida, os itens mais antigos são trancados de novo com a nova versão. O Speak-Y Teams funciona assim; alguns produtos conhecidos apenas revogam o acesso ao servidor e mantêm as mesmas chaves.
Um membro removido da equipe ainda consegue ler o que foi compartilhado antes?
Tudo o que a pessoa já abriu, baixou ou copiou continua com ela. Nenhum esquema de criptografia consegue tomar de volta um texto em claro que já passou pela tela de alguém. A rotação de chaves protege o que é compartilhado depois da remoção e impede que a chave antiga abra conteúdo baixado do servidor mais tarde.
E se um membro da equipe esquecer a senha num espaço de trabalho criptografado de ponta a ponta?
O fornecedor não consegue restaurar o acesso, porque nunca teve as chaves. O Speak-Y resolve isso com um Recovery Kit: um arquivo que o proprietário do espaço de trabalho salva ao criá-lo e que permite reemitir as chaves de canal para um membro que definiu uma nova senha. O Kit não cobre as gravações pessoais de ninguém.
Um link de convite para um espaço de trabalho criptografado é sensível?
Pode ser. No Speak-Y, o link de convite leva a chave do espaço de trabalho na parte da URL depois do #, que navegadores e apps nunca enviam ao servidor. Os convites são de uso único e expiram, e remover um membro faz a rotação da chave do espaço de trabalho, mas, enquanto não for usado, o link deve ser tratado como uma senha.