Why Johnny Can't Encrypt

Machine Translated by Google
Em Segurança e Usabilidade: Projetando Sistemas Seguros que as Pessoas

Podem Usar, eds. L. Cranor e G. Simson. O'Reilly, 2005, pp.
CAPÍTULO TRINTA E QUATRO
Por que Johnny não consegue criptografar
Uma avaliação de usabilidade do PGP 5.0

ALMA WHITTEN E JD TYGAR
EM ERROS SER CAUSAM OU CONTRIBUEM PARA A MAIORIA DAS FALHAS DE SEGURANÇA DO COMPUTADOR, mas as interfaces de usuário
pois a segurança ainda tende a ser desajeitada, confusa ou quase inexistente. Isso se deve simplesmente
à falha na aplicação de técnicas padrão de design de interface de usuário à segurança? Argumentamos
que, pelo contrário, uma segurança eficaz requer um padrão de usabilidade diferente e que não será
alcançada através de técnicas de design de interface de utilizador adequadas a outros tipos de software
de consumo.1
Para testar essa hipótese, realizamos um estudo de caso de um programa de segurança que possui
uma boa interface de usuário para os padrões gerais: PGP 5.0. Nosso estudo de caso utilizou
uma análise cognitiva juntamente com um teste de usuário de laboratório para avaliar se o PGP 5.0
pode ser usado com sucesso por novatos em criptografia para obter segurança eficaz de correio
eletrônico. A análise encontrou uma série de falhas no design da interface do usuário que podem
contribuir para falhas de segurança, e o teste do usuário demonstrou que quando nossos participantes
do teste tiveram 90 minutos para assinar e criptografar uma mensagem usando PGP 5.0, a maioria
deles não conseguiu. faça isso com sucesso.
1 Este artigo foi publicado originalmente em Proceedings of the 8th USENIX Security Symposium
(Washington, DC, 23 a 36 de agosto de 1999), 169–184.
POR QUE JOHNNY NÃO PODE CRIPTOGRAFAR 679

Concluímos que o PGP 5.0 não é utilizável o suficiente para fornecer segurança eficaz para a maioria dos
usuários de computador, apesar de sua interface gráfica de usuário atraente, apoiando nossa hipótese de que
o design da interface de usuário para segurança eficaz permanece um problema em aberto. Encerramos com
uma breve descrição do nosso trabalho contínuo no desenvolvimento e aplicação de princípios e técnicas
de design de interface de usuário para segurança.
Introdução
Os mecanismos de segurança só são eficazes quando usados corretamente. Criptografia forte,
protocolos comprovadamente corretos e código livre de bugs não fornecerão segurança se as pessoas que
usam o software esquecerem de clicar no botão Criptografar quando precisarem de privacidade, desistirem
de um protocolo de comunicação porque estão muito confusas sobre quais chaves criptográficas eles precisam
usar ou configurar acidentalmente seus mecanismos de controle de acesso para tornar seus dados privados
legíveis. Problemas como estes já são bastante graves: pelo menos um investigador, Matt Bishop,2 afirmou
que os erros de configuração são a causa provável de mais de 90% de todas as falhas de segurança informática.
Como os cidadãos comuns são agora cada vez mais incentivados a utilizar computadores em rede para
transações privadas, a necessidade de tornar a segurança gerenciável mesmo para usuários não
treinados tornou-se crítica.3, 4
Este é inevitavelmente um problema de design de interface de usuário. Remédios legais, maior automação e
treinamento de usuários fornecem apenas soluções limitadas. Os usuários individuais podem não ter
recursos para perseguir legalmente um invasor e podem nem perceber que ocorreu um ataque. A
automação pode funcionar para proteger um canal de comunicação, mas não para definir uma política de
controle de acesso quando um usuário deseja compartilhar alguns arquivos e outros não. Os funcionários podem
ser obrigados a participar de sessões de treinamento, mas os usuários de computadores domésticos não.
Por que, então, existe tanta falta de um bom design de interface de usuário para segurança? Os princípios
gerais de design da interface do usuário existentes são adequados para a segurança? Para responder a essas
perguntas, devemos primeiro entender que tipo de usabilidade a segurança exige para ser eficaz.
Neste capítulo, oferecemos uma definição específica de usabilidade para segurança e identificamos diversas
propriedades significativas de segurança como um domínio de problema para o design de interfaces de
usuário. As prioridades de design necessárias para alcançar a segurança utilizável e os desafios
apresentados pelas propriedades que discutimos são significativamente diferentes daqueles do software de consumo geral.
Suspeitamos, portanto, que tornar a segurança utilizável exigirá o desenvolvimento de princípios e
técnicas de design de interface de usuário específicos do domínio.
Para investigar mais profundamente, analisamos o software existente para encontrar um programa
que representasse o melhor design de interface de usuário atual para segurança, um exemplo de design
de interface de usuário geral aplicado a software de segurança. Ao realizar um detalhado
2 Matt Bishop, UNIX Security: Threats and Solutions, apresentação ao SHARE 86.0 (março de 1996).
3 “O fim da privacidade”, The Economist (1º de maio de 1999), 21–23.
4 Stephen Kent, “Security”, More Than Screen Deep: Toward Every-Citizen Interfaces to the Nation's Information
Infrastructure (Washington, DC: National Academy Press, 1997).
680 CAPÍTULO TRINTA E QUATRO

estudo de caso da usabilidade de tal programa, focando no impacto das questões de usabilidade na eficácia da
segurança que o programa oferece, conseguimos obter resultados valiosos em diversas frentes. Primeiro,
nosso estudo de caso serve como um teste para nossa hipótese de que os padrões de design de interface de
usuário apropriados para software de consumo geral não são suficientes para segurança. Em segundo lugar,
uma boa avaliação de usabilidade para segurança é em si um problema em aberto, e nosso estudo de caso
discute e demonstra as técnicas de avaliação que consideramos mais apropriadas. Terceiro, o nosso estudo
de caso fornece dados reais nos quais podemos basear as nossas prioridades e conhecimentos para a
investigação de melhores soluções de design de interfaces de utilizador, tanto para o programa específico
em questão como para o domínio da segurança em geral.
Escolhemos PGP 5.05, 6, 7 como a melhor disciplina candidata para nosso estudo de caso. Sua interface de
usuário parece ser razoavelmente bem projetada para os padrões gerais de software de consumo, e sua
literatura de marketing8 indica que foi feito esforço no design, afirmando que a “interface gráfica de
usuário significativamente melhorada torna a criptografia matemática complexa acessível para
usuários de computador novatos”. Além disso, como o gerenciamento de chaves públicas é um componente
importante de muitos sistemas de segurança propostos e desenvolvidos atualmente, o problema de como
tornar a funcionalidade do PGP utilizável o suficiente para ser eficaz é amplamente relevante.
Começamos derivando um padrão de usabilidade específico para PGP a partir do nosso padrão geral de
usabilidade para segurança. Ao avaliar a usabilidade do PGP 5.0 em relação a esse padrão, optamos por
empregar dois métodos de avaliação separados: uma técnica de análise direta chamada passo a passo
cognitivo9 e um teste de usuário de laboratório.10 Os dois métodos têm pontos fortes e fracos
complementares. Os testes com usuários produzem resultados mais objetivos, mas são necessariamente de
escopo limitado; a análise direta pode considerar uma gama mais ampla de possibilidades e fatores, mas é
inerentemente subjetiva. A soma dos dois métodos produz uma avaliação mais exaustiva do que
qualquer um deles poderia sozinho.
Apresentamos uma discussão ponto a ponto dos resultados de nossa análise direta, seguida por uma breve
descrição do propósito, design e participantes de nosso teste de usuário e, em seguida, um resumo compacto
5 No momento em que este artigo foi escrito, o PGP 6.0 foi lançado recentemente. Alguns pontos levantados no nosso estudo
de caso podem não se aplicar a esta versão mais recente; entretanto, isso não diminui significativamente o valor do PGP
5.0 como assunto para análise de usabilidade. Além disso, nossa avaliação foi realizada usando a versão tosh do Apple
Macin, mas os problemas de interface do usuário que abordamos não são específicos de um sistema operacional específico
e são igualmente aplicáveis ao software de segurança Unix e Windows. [Nota adicionada em julho de 2005: Desde a
publicação original do nosso artigo em 1999, o PGP foi substancialmente modificado. A versão atual do PGP é PGP
Desktop 9.0.]
6 Simson Garfinkel, PGP: Privacidade muito boa (Sebastopol, CA: O'Reilly Media, 1995).
7 Pretty Good Privacy, Inc., Guia do usuário de PGP para privacidade pessoal, versão 5.0 para Mac OS. Pacote
envelhecido com software, 1997.
8 Jeffrey Rubin, Manual de testes de usabilidade: como planejar, projetar e conduzir testes eficazes (Nova York:
John Wiley & Sons, Inc., 1994).
9 Cathleen Wharton, John Rieman, Clayton Lewis e Peter Polson, “O método cognitivo passo a passo: um guia prático”,
Métodos de inspeção de usabilidade (Nova York: John Wiley & Sons, Inc., 1994).
10 Rubin.

discussão dos resultados do teste do usuário. Uma apresentação mais detalhada deste material, incluindo resumos de transcrições
de testes de usuários, pode ser encontrada em Whitten e Tygar.11
Com base nos resultados de nossa avaliação, concluímos que a interface de usuário do PGP 5.0 não chega nem perto de atingir
nosso padrão de usabilidade – ela não torna a criptografia de chave pública de correio eletrônico gerenciável para usuários comuns
de computador. Isto, juntamente com muitos dos detalhes dos nossos resultados de avaliação, apoia a nossa hipótese de que
são necessários princípios e técnicas de design de interface de usuário específicos para segurança. Em nosso trabalho
contínuo, usamos nosso padrão de usabilidade para segurança, as observações feitas em nossa análise direta e as
descobertas detalhadas de nossos testes de usuário como base para desenvolver e aplicar princípios e técnicas de design
apropriados.
Compreendendo o problema
Antes de descrever o teste do usuário, fornecemos uma definição específica de usabilidade para segurança, identificamos as
principais propriedades da segurança como um domínio de problema para o design da interface do usuário e definimos um padrão
de usabilidade para PGP.
Definindo Usabilidade para Segurança
Usabilidade tem necessariamente significados diferentes em contextos diferentes. Para alguns, a eficiência pode ser uma
prioridade; para outros, capacidade de aprendizagem; para outros ainda, flexibilidade. Num contexto de segurança, as nossas
prioridades devem ser aquelas que forem necessárias para que a segurança seja utilizada de forma eficaz.
Capturamos esse conjunto de prioridades na seguinte definição:
Definição: O software de segurança é utilizável se as pessoas que o utilizarão:
•São informados de forma confiável sobre as tarefas de segurança que precisam executar
•São capazes de descobrir como executar essas tarefas com sucesso
•Não cometa erros perigosos
•Estão suficientemente confortáveis com a interface para continuar a usá-la
Propriedades problemáticas da segurança A
segurança possui algumas propriedades inerentes que a tornam um domínio de problema difícil para o design da interface do
usuário. As estratégias de design para criar segurança utilizável precisarão levar essas propriedades explicitamente em
consideração, e o design generalizado da interface do usuário não faz isso.
Descrevemos cinco dessas propriedades aqui; é possível que existam outros que ainda não identificamos.
1. A propriedade do usuário desmotivado
A segurança geralmente é um objetivo secundário. As pessoas geralmente não se sentam em frente aos seus
computadores querendo gerenciar sua segurança; em vez disso, eles desejam enviar e-mails, navegar em páginas da Web ou
baixar software e desejam segurança para protegê-los
11 Alma Whitten e JD Tygar, Usabilidade de segurança: um estudo de caso, Carnegie Mellon University School
do Relatório Técnico de Ciência da Computação CMU-CS-98-155 (dezembro de 1998).

enquanto eles fazem essas coisas. É fácil para as pessoas adiarem a aprendizagem sobre segurança ou
assumirem de forma optimista que a sua segurança está a funcionar, enquanto se concentram nos seus
objectivos principais. Os projetistas de interfaces de usuário para segurança não devem presumir que os usuários
serão motivados a ler manuais ou procurar controles de segurança projetados para serem discretos.
Além disso, se a segurança for muito difícil ou irritante, os usuários poderão desistir completamente dela.
2. A propriedade de abstração
A gestão da segurança informática envolve frequentemente políticas de segurança, que são sistemas de regras
abstratas para decidir se deve conceder acesso aos recursos. A criação e gestão de tais regras é uma actividade
que os programadores consideram um dado adquirido, mas que pode ser estranha e não intuitiva para muitos
membros da população de utilizadores em geral. O design da interface do usuário para segurança precisará levar
isso em consideração.
3. A falta de propriedade de feedback
A necessidade de evitar erros perigosos torna imperativo fornecer um bom feedback ao usuário, mas fornecer um
bom feedback para o gerenciamento da segurança é um problema difícil. O estado de uma configuração
de segurança geralmente é complexo e as tentativas de resumi-lo não são adequadas. Além disso, a
configuração de segurança correta é aquela que faz o que o usuário “realmente deseja” e, como somente o usuário
sabe o que é isso, é difícil para o software de segurança realizar verificações de erros muito úteis.
4. A propriedade da porta do celeiro
O provérbio sobre a futilidade de trancar a porta do celeiro depois que o cavalo vai embora descreve uma
propriedade importante da segurança de computadores: uma vez que um segredo foi deixado acidentalmente
desprotegido, mesmo que por um curto período de tempo, não há como ter certeza de que ele foi descoberto. ainda
não foi lido por um invasor. Por causa disso, o design da interface do usuário para segurança precisa dar
alta prioridade à garantia de que os usuários entendam sua segurança bem o suficiente para evitar cometer
erros potencialmente de alto custo.
5. A propriedade do elo mais fraco
É bem sabido que a segurança de um computador em rede é tão forte quanto o seu componente mais fraco.
Se um cracker conseguir explorar um único erro, o jogo termina. Isso significa que os usuários precisam ser
orientados a cuidar de todos os aspectos de sua segurança, e não deixados para prosseguir através da exploração
aleatória, como fariam com um processador de texto ou planilha.
Um padrão de usabilidade para PGP
Pessoas que usam e-mail para se comunicar pela Internet precisam de um software de segurança que lhes permita
fazer isso com privacidade e autenticação. A literatura de documentação e marketing do PGP apresenta-o como uma
ferramenta destinada ao uso por este grande e diversificado grupo de pessoas, a maioria das quais não são profissionais
de informática. Referindo-nos novamente ao nosso

definição geral de usabilidade para segurança, derivamos a seguinte questão na qual concentrar nossa avaliação:
Se um usuário médio de e-mail sente necessidade de privacidade e autenticação, e
adquire o PGP com esse propósito em mente, o design atual do PGP permitirá que essa pessoa
perceber o que precisa ser feito, descobrir como fazê-lo e evitar erros perigosos,
sem ficar tão frustrado a ponto de decidir desistir de usar o PGP?
Colocando a questão com mais detalhes, queremos saber se essa pessoa irá, pelo menos
mínimo:
• Compreender que a privacidade é alcançada através da criptografia e descobrir como criptografar e-mails e
como descriptografar e-mails recebidos de outras pessoas
• Compreender que a autenticação é obtida por meio de assinaturas digitais e descobrir como assinar e-mails e
como verificar assinaturas em e-mails de outras pessoas
• Entenda que para assinar e-mails e permitir que outras pessoas enviem mensagens criptografadas
e-mail, um par de chaves deve ser gerado e descobrir como fazer isso
• Entenda que para permitir que outras pessoas verifiquem sua assinatura e lhe enviem e-mails criptografados, ele
deve publicar sua chave pública e descobrir uma maneira de fazer isso
• Entenda que para verificar assinaturas em e-mails de outras pessoas e enviar

e-mail criptografado para outras pessoas, ele deve adquirir as chaves públicas dessas pessoas e descobrir
uma maneira de fazer isso
• Conseguir evitar erros perigosos, como falha acidental na criptografia, confiança nas chaves públicas erradas,
falha no backup das chaves privadas e esquecimento das senhas
• Ser capaz de ter sucesso em tudo isso dentro de algumas horas de esforço razoavelmente motivado
Esta é uma lista mínima de itens essenciais para o uso correto do PGP. Não inclui
tarefas importantes como fazer com que outras pessoas assinem a chave pública, assinar as chaves públicas de
outras pessoas, revogar a chave pública e divulgar a revogação, ou avaliar a autenticidade de uma chave
pública com base nas assinaturas que a acompanham e fazer uso dos mecanismos integrados do PGP para tal
avaliação.
Métodos de Avaliação
Optamos por avaliar a usabilidade do PGP através de dois métodos: um passo a passo cognitivo informal12
no qual revisamos diretamente a interface do usuário do PGP e observamos aspectos de seu design que não
atendiam ao padrão de usabilidade descrito na seção anterior, e um teste de usuário13 realizado em laboratório com
participantes do teste selecionados para serem razoavelmente representativos da população geral de usuários
de e-mail. Os pontos fortes e fracos inerentes a cada um dos dois métodos tornaram-nos úteis de maneiras
bastante diferentes, e
12Wharton.
13 Rubino.

Foi mais realista para nós vê-los como estratégias de avaliação complementares14 do que tentar
usar o teste laboratorial para verificar diretamente os pontos levantados pelo walkthrough
cognitivo.
O passo a passo cognitivo é uma técnica de avaliação de usabilidade modelada a partir da

prática de engenharia de software de passeios de código. Para realizar um walkthrough
cognitivo, os avaliadores percorrem o uso do software como se fossem usuários novatos, tentando
simular mentalmente o que eles acham que seria a compreensão do software pelos novatos em
cada ponto, e procurando prováveis erros e áreas de problemas. confusão. Como ferramenta de
avaliação, o walkthrough cognitivo tende a focar na capacidade de aprendizagem da interface do
usuário (em oposição, digamos, à eficiência) e, como tal, é uma ferramenta apropriada para
avaliar a usabilidade da segurança.
Embora nossa análise seja descrita com mais precisão como um passeio cognitivo, ela também
incorporou aspectos de outra técnica, a avaliação heurística.15 Nessa técnica, a interface do
usuário é avaliada em relação a uma lista específica de princípios de usabilidade de alta prioridade;
nossa lista de princípios é composta por nossa definição de usabilidade para segurança (na
seção “Definindo usabilidade para segurança”) e sua reformulação especificamente para PGP (na
seção “Um padrão de usabilidade para PGP”). A avaliação heurística é idealmente realizada por
pessoas que são “especialistas duplos”, altamente familiarizadas tanto com o domínio da aplicação
quanto com as técnicas e requisitos de usabilidade (incluindo uma compreensão das habilidades,
mentalidade e experiência das pessoas que deverão usar o software). . Nossa avaliação baseia-se
em nossa experiência como pesquisadores de segurança e em conhecimentos adicionais em
treinamento e orientação de usuários de computador novatos, bem como em teatro, antropologia e psicologia.
Algumas das mesmas propriedades que tornam o projeto de segurança utilizável um problema
difícil e especializado também tornam o teste da usabilidade da segurança uma tarefa
desafiadora. Para realizar um teste de usuário, devemos pedir aos participantes que utilizem o
software para realizar alguma tarefa que incluirá o uso da segurança. Se, no entanto, os incitarmos
a executar uma tarefa de segurança diretamente, quando na vida real eles poderiam não ter
consciência dessa tarefa, então não conseguimos testar se o software foi concebido suficientemente
bem para lhes dar essa consciência quando precisarem. . Além disso, para testar se eles são
capazes de descobrir como usar a segurança quando quiserem, devemos ter certeza de que o
cenário de teste lhes dá algum segredo que eles consideram que vale a pena proteger, comparável
ao valor que esperamos que eles atribuam aos seus próprios segredos no mundo real. A
concepção de testes que tenham em conta estes requisitos de forma adequada é algo que deve
ser feito com cuidado e, com excepção de alguns trabalhos sobre testes da eficácia dos rótulos de
advertência,16 encontrámos pouco material existente sobre testes com utilizadores que aborde preocupações semelhantes.
14 BE John e MM Mashyna, “Evaluating a Multimedia Authoring Tool with Cognitive Walk through and Think-
Aloud User Studies”, Journal of the American Society of Information Science 48:9, 1997.
15 Jakob Nielsen, “Avaliação Heurística”, Métodos de Inspeção de Usabilidade (Nova York: John Wiley & Sons,
Inc., 1994).
16 MS Wogalter e SL Young, "Melhorando a Conformidade de Avisos Através de Produtos Alternativos
Label Designs", Ergonomia Aplicada 25 (1994), 3–57.

Passo a passo cognitivo

Como este capítulo se destina ao público de segurança e está sujeito a limitações de espaço, apresentamos
os resultados do nosso passo a passo cognitivo de forma resumida, concentrando-nos nos pontos que são
mais relevantes para os riscos de segurança.
Metáforas Visuais A
metáfora das chaves está embutida na terminologia criptológica, e a interface do usuário do PGP depende
fortemente de representações gráficas de chaves e fechaduras. A tela PGPtools, mostrada na Figura
34-1, oferece quatro botões ao usuário, representando quatro operações: Criptografar, Assinar, Criptografar e
Assinar e Descriptografar/Verificar, além de um quinto botão para invocar o aplicativo PGPkeys. As
etiquetas gráficas destes botões indicam a operação de criptografia com um ícone de um envelope lacrado que
possui uma alça de metal na parte superior para parecer um cadeado fechado e, para a operação de
descriptografia, um ícone de um envelope aberto com uma chave inserida em o fundo. Mesmo para um
usuário novato, estas parecem ser metáforas visuais simples que ajudam a usar chaves para criptografar e
descriptografar um conceito intuitivo.
FIGURA 34-1 . Exibição de ferramentas PGP
Ainda mais útil, contudo, seria uma extensão da metáfora para distinguir entre chaves públicas para
encriptação e chaves privadas para desencriptação; fechaduras normais usam a mesma chave para bloquear e
desbloquear, e a metáfora da chave levará as pessoas a esperar o mesmo para criptografia e descriptografia
se não for visualmente esclarecida de alguma forma. A intuição defeituosa, neste caso, pode levá-los a presumir
que sempre podem descriptografar tudo o que criptografaram, uma suposição que pode ter consequências
perturbadoras. Ícones diferentes para chaves públicas e privadas, talvez desenhados para indicar que elas
se encaixam como peças de um quebra-cabeça, podem ser uma melhoria.
As assinaturas são outra metáfora incorporada na terminologia criptológica, mas o ícone da caneta de pena
azul usado para indicar assinatura é problemático. Pessoas que não estão familiarizadas com criptografia
provavelmente sabem que penas são usadas para assinar e reconhecerão que a imagem indica a operação de
assinatura, mas o que elas também precisam entender é que estão usando suas chaves privadas para gerar
assinaturas. O ícone da caneta de pena, que não tem nada de chave, não os ajudará a entender isso e pode
até levá-los a pensar que, junto com os objetos-chave que usam para criptografar, eles também têm objetos de
caneta de pena que usam para assinar. Os ícones de caneta de pena encontrados em outras partes do programa
podem ser considerados esses objetos, em vez das assinaturas que eles realmente pretendem representar.
Um design de ícone melhor poderia manter a caneta de pena para representar a assinatura, mas modificá-la
para mostrar uma chave privada como a ponta da caneta e usar algum ícone totalmente diferente para

assinaturas, talvez algo que se pareça mais com uma caligrafia com tinta e incorpore o formato de um
buraco de fechadura.
A verificação de assinatura não é representada visualmente, o que é uma pena, pois seria fácil para as
pessoas ignorá-la completamente. O único botão para Descriptografar/Verificar, rotulado com um ícone que
apenas evoca a descriptografia, poderia facilmente levar as pessoas a pensar que “verificar” significa apenas
“verificar se a descriptografia ocorreu corretamente”. Talvez um ícone que mostrasse uma chave privada
desbloqueando o envelope e uma chave pública desbloqueando a assinatura interna pudesse sugerir um modelo
muito mais preciso para o usuário, ao mesmo tempo que permanece simples o suficiente para servir como um
rótulo de botão.
Diferentes tipos de
chaves Originalmente, o PGP usava o popular algoritmo RSA para criptografia e assinatura. O PGP 5.0 usa os
algoritmos Diffie-Hellman/DSS. Os algoritmos RSA e Diffie-Hellman/DSS usam tipos de chaves
correspondentemente diferentes. Os fabricantes do PGP prefeririam que todos os usuários de seu software
mudassem para o Diffie-Hellman/DSS, mas projetaram o PGP 5.0 para ser compatível com versões anteriores e
para lidar com as chaves RSA existentes quando necessário. A falta de compatibilidade futura, no entanto,
pode ser um problema: se um arquivo for criptografado para vários destinatários, alguns dos quais
possuem chaves RSA e outros possuem chaves Diffie-Hellman/DSS, os destinatários que possuem chaves
RSA não poderão para descriptografá-lo, a menos que tenham atualizado para o PGP 5.0; da mesma forma,
esses destinatários não poderão verificar assinaturas criadas com Diffie-Hellman/DSS sem uma
atualização de software.
O PGP 5.0 alerta seus usuários sobre esse problema de compatibilidade de duas maneiras. Primeiro, ele usa
ícones diferentes para representar os diferentes tipos de chaves: uma chave azul com formato antigo para
chaves RSA e uma chave de latão com formato mais moderno para chaves Diffie-Hellman/DSS, conforme
mostrado na Figura 34-2 . Segundo, quando os usuários tentam criptografar documentos usando tipos de chaves
mistas, uma mensagem de aviso é exibida informando que os destinatários que possuem versões anteriores
do PGP podem não conseguir descriptografar esses documentos.
PGP FIGURA 34-2 . Exibição de teclas

Infelizmente, é difícil encontrar informações sobre o significado dos ícones de teclas azuis e de latão, exigindo que
os usuários consultem o manual de 132 páginas ou descubram com base na presença de outros dados de tipo de
chave. Além disso, além da mensagem de aviso encontrada durante a criptografia, a explicação do motivo pelo
qual os diferentes tipos de chave são significativos (em particular, o risco de problemas de compatibilidade futura)
é fornecida apenas no manual. Clicar duas vezes em uma chave abre uma janela Propriedades da chave, que
seria um bom lugar para fornecer uma mensagem curta sobre o significado do ícone da chave azul ou de latão
e o significado do tipo de chave correspondente.
É muito importante que o usuário preste atenção aos tipos de chave ao escolher uma chave para criptografia de
mensagens, porque é nesse momento que tipos de chaves mistos podem causar problemas de compatibilidade.
Entretanto, a caixa de diálogo do PGP (veja a Figura 34-3) apresenta ao usuário a metáfora de escolher
pessoas (destinatários) para receber a mensagem, em vez de chaves para criptografar a mensagem. Esta não
é uma boa escolha de design, não apenas porque os ícones da cabeça humana obscurecem as informações
do tipo de chave, mas também porque as pessoas podem ter múltiplas chaves, e é contra-intuitivo que a caixa
de diálogo exiba múltiplas versões de uma pessoa em vez das múltiplas chaves que pessoa possui.
FIGURA 34-3 . Caixa de diálogo PGP
Servidor chave
Servidores de chaves são bancos de dados acessíveis ao público (através da Internet) nos quais qualquer
pessoa pode publicar uma chave pública associada a um nome. O PGP está configurado para acessar um servidor
chave no MIT por padrão, mas outros estão disponíveis, a maioria dos quais são mantidos atualizados como
espelhos uns dos outros. O PGP oferece três operações de servidor de chaves ao usuário no menu suspenso
Chaves mostrado na Figura 34-4: Obter chave selecionada, Enviar chave selecionada e Encontrar novas
chaves. Os dois primeiros simplesmente se conectam ao servidor principal e executam a operação. O terceiro pergunta ao usuário

para digitar um nome ou endereço de e-mail para pesquisar, conecta-se ao servidor de chaves e realiza a pesquisa
e, em seguida, informa ao usuário quantas chaves foram retornadas como resultado, perguntando se elas
devem ser adicionadas ao conjunto de chaves do usuário.
teclas FIGURA 34-4

. Menu suspenso de
O primeiro problema que encontramos com esta apresentação do servidor de chaves é que os usuários podem
não perceber que ele existe, porque não há representação dele no nível superior da exibição das chaves
PGP. Colocar as principais operações do servidor em um menu suspenso do Key Server seria uma escolha de
design melhor, especialmente porque vale a pena encorajar o usuário a fazer uma distinção mental entre
operações que acessam máquinas remotas e aquelas que são puramente locais. Pensamos também que
deveria ficar mais claro que uma máquina remota está a ser acedida e que a identidade da máquina remota deveria
ser exibida. Freqüentemente, a série de mensagens de status “conectando – recebendo dados – fechando conexão”
que o PGP exibia piscava quase rápido demais para ser lida.
Atualmente, PGPkeys não mantém registros de acessos a servidores de chaves. Não há nada que mostre se
uma chave foi enviada para um servidor de chaves, ou quando uma chave foi buscada ou atualizada pela última
vez, e de qual servidor de chaves a chave foi buscada ou atualizada. Estas são informações que podem ser
úteis ao usuário para gerenciamento de chaves e para verificar se as operações do servidor de chaves
foram concluídas com êxito. Adicionar esse registro às informações exibidas na janela Key Properties melhoraria
o PGP.
A revogação de chave, em que um certificado é publicado para anunciar que uma chave pública publicada
anteriormente não deve mais ser considerada válida, geralmente implica a utilização do servidor de chaves
para divulgar a revogação. A operação de revogação de chave do PGP não envia o certificado de revogação
resultante para o servidor de chaves, o que provavelmente é como deveria ser, mas há o risco de que alguns
usuários presumam que isso é feito e não tomem essa ação
eles mesmos. Seria apropriado um aviso de que o certificado de revogação criado ainda não foi divulgado.
Política de gerenciamento de chaves
O PGP mantém duas classificações para cada chave pública em um chaveiro PGP. Essas classificações podem
ser atribuídas pelo usuário ou derivadas automaticamente. A primeira dessas classificações é a validade, que indica
o quão certo o usuário tem de que a chave é segura para criptografar (ou seja, que ela pertence à pessoa cujo
nome está rotulado). Uma chave pode ser rotulada como

completamente válido, marginalmente válido ou inválido. As chaves que o usuário gera são sempre totalmente válidas. A
segunda dessas classificações é a confiança, que indica quanta fé o usuário tem na chave (e, implicitamente, no proprietário da
chave) como certificador de outras chaves.
Da mesma forma, uma chave pode ser rotulada como totalmente confiável, marginalmente confiável ou não confiável, e as
próprias chaves do usuário são sempre totalmente confiáveis.
O que os usuários podem não perceber, a menos que leiam o manual com muita atenção, é que existe uma política embutida
no PGP que define automaticamente a classificação de validade de uma chave com base no fato de ela ter sido assinada por um
certo número de chaves suficientemente confiáveis. Isso é perigoso.
Não há nada que impeça os usuários de atribuir inocentemente suas próprias interpretações a essas classificações e defini-las
de acordo (especialmente porque “validade” e “confiança” têm significados coloquiais diferentes), e é certamente possível que
algumas pessoas possam fazer uso mental da validade. classificação, ignorando e talvez modificando incautamente as
classificações de confiança. A capacidade do PGP de derivar automaticamente classificações de validade pode ser útil, mas o
fato de o PGP estar fazendo isso precisa ficar óbvio para o usuário.
Ações irreversíveis
Alguns erros do usuário são reversíveis, mesmo que exijam algum tempo e esforço para reconstruir o estado desejado. Os que
listamos aqui, entretanto, não o são e podem ter consequências desagradáveis para o usuário, que pode perder
dados valiosos:
Excluindo acidentalmente a chave privada
Uma chave pública, se excluída, geralmente pode ser obtida novamente de um servidor de chaves ou de seu proprietário.
Uma chave privada, se excluída e sem backup em algum lugar, desaparece para sempre, e qualquer coisa criptografada
com sua chave pública correspondente nunca poderá ser descriptografada, nem o usuário poderá fazer um
certificado de revogação para essa chave pública. . O PGP responde a qualquer tentativa de excluir uma chave com a
pergunta “Você realmente deseja excluir estes itens?” Isto é bom para uma chave pública, mas as tentativas de apagar
uma chave privada devem ser recebidas com um aviso sobre as possíveis consequências.
Divulgando acidentalmente uma chave
As informações só podem ser adicionadas a um servidor principal, não removidas. Um usuário que está experimentando
PGP pode acabar gerando vários pares de chaves que são permanentemente adicionados ao servidor de chaves, sem
perceber que são entradas permanentes. É verdade que o efeito disto pode ser parcialmente resolvido revogando as
chaves posteriormente (ou esperando que expirem), mas esta não é uma solução satisfatória. Primeiro, mesmo que uma
chave seja revogada ou expire, ela permanece no servidor de chaves. Em segundo lugar, as noções de revogação e expiração
são conceitos relativamente sofisticados: conceitos que provavelmente não serão familiares a um usuário novato. Por
exemplo, conforme discutido anteriormente, o usuário pode acidentalmente perder a capacidade de gerar um certificado de
revogação para uma chave. Isto é particularmente provável para um usuário que estava experimentando PGP e gerando
uma variedade de chaves de teste que pretende excluir. Uma forma de resolver esse problema seria avisar ao usuário,
quando ele envia uma chave para um servidor, que a informação enviada será um acréscimo permanente.

Revogação acidental de uma

chave Depois que o usuário revogar uma chave pública, a única maneira de desfazer a revogação é restaurar
o conjunto de chaves a partir de uma cópia de backup. A mensagem de aviso do PGP para a operação de
revogação pergunta “Tem certeza de que deseja revogar esta chave? Uma vez distribuída, outras
pessoas não conseguirão criptografar os dados com esta chave.” Esta mensagem não avisa ao usuário que,
mesmo que nenhuma distribuição tenha ocorrido, será necessário um backup prévio do chaveiro caso o
usuário queira desfazer a revogação. Além disso, pode contribuir para o equívoco de que a revogação da
chave distribui automaticamente a revogação.
Esquecendo a senha O PGP

sugere que o usuário faça um certificado de revogação de backup para que, se a senha for perdida, pelo menos
o usuário ainda possa usar esse certificado para revogar a chave pública. Concordamos que isso é útil,
mas também acreditamos que apenas usuários experientes de PGP entenderão o que isso significa e como
fazê-lo. No design atual do PGP, isso exige que o usuário crie um backup do chaveiro, revogue a chave pública,
crie outro backup do chaveiro que contém a chave revogada e, em seguida, restaure o chaveiro a partir do
backup original.
Falha ao fazer backup dos chaveiros

Vemos dois problemas na forma como o mecanismo de backup dos porta-chaves é apresentado. Primeiro, o
usuário não é lembrado de fazer backup dos conjuntos de chaves até sair do PGPkeys; seria melhor lembrar
assim que as chaves forem geradas, para não correr o risco de perdê-las devido a uma falha no sistema.
Segundo, embora a mensagem de lembrete diga ao usuário que é importante fazer backup das chaves em
algum meio diferente do disco rígido principal, a caixa de diálogo para backup apresenta a pasta PGP principal
como local de backup padrão. Como a maioria dos usuários simplesmente clica no botão OK e aceita o
padrão, esse não é um bom design.
Consistência
Quando o PGP está no processo de criptografia ou assinatura de um arquivo, ele apresenta ao usuário uma
mensagem de status informando que ele está atualmente “codificando”. Seria melhor dizer “criptografar” ou
“assinar” porque ver os termos que correspondem explicitamente às operações que estão sendo executadas
ajuda a criar um modelo mental claro para o usuário, e a introdução de um terceiro termo pode confundir o
usuário, fazendo-o pensar que há uma terceira operação tomando lugar. Reconhecemos que o uso do termo
“codificação” aqui pode ser simplesmente um erro de programação e não uma escolha de design em si, mas
achamos que isso é algo que deve ser detectado por testes de produtos orientados à usabilidade.
Muita informação
Nas implementações anteriores do PGP, as funções de suporte ao gerenciamento de chaves (criação de

porta-chaves, coleta de chaves de outras pessoas, construção de uma rede de confiança) tendiam a ofuscar as
funções primárias mais simples do PGP, assinatura e criptografia. O PGP 5.0 separa essas funções em dois
aplicativos: PGPkeys para gerenciamento de chaves e PGPtools para assinatura e criptografia. Isso limpa o
que antes era uma coleção bastante confusa de funções primárias e de suporte e fornece ao usuário uma interface
simples e agradável para as funções primárias. Acreditamos, no entanto, que a aplicação PGPkeys ainda
apresenta a

usuário com muitas informações para entender e que precisa fazer um trabalho melhor para distinguir entre
os níveis básico, intermediário e avançado de atividade de gerenciamento de chaves para não
sobrecarregar seus usuários.
Atualmente, a exibição das chaves PGP (veja a Figura 34-2) sempre mostra as seguintes informações para
cada chave no chaveiro do usuário: nome do proprietário, validade, nível de confiança, data de criação e
tamanho. O tipo de chave também é indicado pela escolha do ícone, podendo o usuário alternar a
exibição das assinaturas em cada chave. São muitas informações e não há nada que ajude o usuário a
descobrir quais partes da tela são mais importantes para prestar atenção. Acreditamos que isso
fará com que os usuários não reconheçam dados imediatamente relevantes, como o tipo de
chave; que aumentará as chances de atribuirem interpretações erradas a alguns dos dados, como confiança
e validade; e isso contribuirá para que os usuários se sintam sobrecarregados e inseguros de que estão
gerenciando sua segurança com êxito.
Acreditamos que, realisticamente, a grande maioria dos usuários do PGP deixará de enviar todos
os seus e-mails em texto simples para usar criptografia simples quando enviarem e-mails com algo
confidencial, e que estarão inclinados a confiar em todas as chaves que adquirirem, porque eles estão
à procura de protecção contra bisbilhoteiros e não contra o tipo de ataque que tentaria induzi-los a usar
chaves falsas Um design melhor das chaves PGP teria uma configuração de visualização inicial que se
concentrasse em dar ao utilizador o modelo correcto da relação entre o público e o privado chaves, o
significado dos tipos de chaves e uma compreensão clara das funções de aquisição e distribuição de
chaves. Remover a validade, o nível de confiança, a data de criação e o tamanho da exibição liberaria área
da tela para isso e ajudaria o usuário a se concentrar na compreensão do modelo básico. Alguns especialistas
em segurança podem achar alarmante a subestimação dessas informações, mas o objetivo aqui é
permitir que usuários inexperientes com criptografia entendam e comecem a usar o básico, e evitar
confusão ou frustração que possa levá-los a usar o PGP incorretamente ou não. de forma alguma.
Um grupo menor de usuários mais experientes provavelmente se preocupará mais com a

confiabilidade de suas chaves; talvez esses usuários tenham motivos para acreditar que o conteúdo
de seus e-mails é valioso o suficiente para ser alvo de um ataque planejado mais sofisticado, ou talvez
eles realmente precisem autenticar uma assinatura digital como proveniente de uma entidade
conhecida do mundo real. Esses usuários precisarão das informações fornecidas pelas assinaturas de
cada chave. Eles podem achar os rótulos de validade e confiança úteis para registrar suas
avaliações dessas assinaturas, ou podem preferir olhar sempre para as assinaturas reais. Valeria a pena
permitir que os usuários adicionassem os rótulos de validade e confiança ao display, se assim o desejassem,
e fornecer ajuda facilmente acessível aos usuários que estão fazendo a transição para esse nível de uso
mais sofisticado. Mas isto só faria sentido se a derivação automática de validade pela política interna do PGP
fosse desativada para esses usuários, pelas razões discutidas na seção “Política de Gerenciamento de
Chaves”.
O tamanho da chave só é realmente relevante para aqueles que realmente temem um ataque
criptográfico e certamente poderia ser deixado como informação para a caixa de diálogo Propriedades da
chave, assim como a data de criação. Os usuários sofisticados o suficiente para fazer uso inteligente dessas
informações certamente são sofisticados o suficiente para procurá-las.

Teste do usuário
Esta seção descreve o propósito, o design e os resultados do teste do usuário.
Objetivo
Nosso teste de usuário foi projetado para avaliar se o PGP 5.0 atende ao padrão de usabilidade
específico descrito na seção “Um padrão de usabilidade para PGP”. Fornecemos aos
nossos participantes um cenário de teste que era plausível e adequadamente motivador e
depois evitamos interferir nas suas tentativas de realizar as tarefas de segurança que lhes
atribuímos.
Descrição
Esta seção descreve as características do desenho do teste e dos participantes.
Projeto de teste
Nosso cenário de teste foi que o participante tivesse se voluntariado para ajudar em uma
campanha política e tivesse recebido o cargo de coordenador de campanha (a filiação partidária e
as questões de campanha foram deixadas à imaginação do participante, para não ofender ninguém).
A tarefa do participante era enviar atualizações do plano de campanha aos demais membros da
equipe de campanha por e-mail, usando PGP para privacidade e autenticação. Dado que
o voluntariado para uma campanha política implica presumivelmente um investimento pessoal no
sucesso da campanha, esperávamos que os participantes estivessem devidamente motivados para
proteger o sigilo das suas mensagens.
Como o PGP não lida com e-mail sozinho, foi necessário fornecer aos participantes um programa
de tratamento de e-mail para uso. Optamos por fornecer-lhes o Eudora, pois isso nos permitiria
avaliar também o sucesso do plug-in Eudora que está incluído no PGP.
Como não estávamos interessados em testar a usabilidade do Eudora (além do plug-in PGP),
demos aos participantes um breve tutorial do Eudora antes de iniciar o teste e intervimos com
assistência durante o teste se um participante ficasse preso em algo que tivesse nada a ver com
PGP.
Depois de informar os participantes sobre o cenário do teste e orientá-los sobre o uso do

Eudora, fornecemos a eles uma descrição inicial da tarefa, que lhes fornecia uma mensagem
secreta (um itinerário proposto para o candidato), os nomes e endereços de e-mail do gerente da
campanha e outros quatro membros da equipe de campanha, e um pedido para enviar a mensagem
secreta aos cinco membros da equipe em um e-mail assinado e criptografado. Para completar esta
tarefa, um participante tinha que gerar um par de chaves, obter as chaves públicas dos membros da
equipe, disponibilizar sua própria chave pública aos membros da equipe, digitar a (curta) mensagem
secreta em um e-mail, assinar o e-mail usando sua chave privada, criptografe o e-mail usando as
chaves públicas dos cinco membros da equipe e envie o resultado. Além disso, projetamos o teste
para que um dos membros da equipe tivesse uma chave RSA enquanto todos os outros tivessem
chaves Diffie-Hellman/DSS; assim, se um participante criptografasse uma cópia da mensagem
para todos os cinco membros da equipe (que era a interpretação esperada da tarefa), ele encontraria o

mensagem de aviso de tipos de chaves mistas. Os participantes foram informados de que, após realizarem
a tarefa inicial, deveriam aguardar o recebimento do e-mail dos membros da equipe da campanha e
seguir as instruções fornecidas.
Cada um dos cinco membros da equipe de campanha foi representado por uma conta de e-mail fictícia e
um par de chaves: estes eram acessíveis ao monitor de teste através de um laptop em rede.
A chave privada do gerente de campanha foi usada para assinar as chaves públicas de cada um dos membros
da equipe, incluindo a dela, e todas as cinco chaves públicas assinadas foram colocadas no servidor de chaves
padrão do MIT para que pudessem ser recuperadas pelas solicitações dos participantes.
Sob certas circunstâncias, o monitor de teste se passou por membro da equipe de campanha e enviou um e-
mail ao participante a partir da conta fictícia apropriada. Esses
circunstâncias foram:
1. O participante enviou um e-mail para aquele membro da equipe perguntando sobre como fazer algo.
Nesse caso, o monitor de teste enviou a resposta minimamente informativa consistente com o
cenário de teste (ou seja, a resposta mínima que não faria aquele membro da equipe parecer hostil ou
ignorante além dos limites da plausibilidade).17
2. O participante enviou o segredo por e-mail em texto simples. O monitor de teste então enviou um e-
mail se passando por gerente da campanha, contando ao participante o que aconteceu,
enfatizando a importância do uso de criptografia para proteger os segredos e pedindo ao participante
que tentasse enviar um e-mail de teste criptografado antes de prosseguir. Se o participante
conseguisse fazer isso, o monitor do teste (se passando por gerente da campanha) enviava um segredo
atualizado ao participante por e-mail criptografado e o teste prosseguia desde o início.
3. O participante enviou e-mail criptografado com a chave errada. O monitor de teste então enviou um e-mail
se passando por um dos membros da equipe que recebeu o e-mail, informando ao participante que o
membro da equipe não conseguiu descriptografar o e-mail e perguntando se o participante havia
usado a chave desse membro da equipe para criptografar.
4. O participante enviou um e-mail para um membro da equipe solicitando a chave desse membro. O monitor
de teste então se passou por esse membro da equipe e enviou a chave solicitada por e-mail.
5. O participante conseguiu realizar a tarefa inicial. Eles então receberam um e-mail criptografado e
assinado do monitor de teste, fazendo-se passar pelo gerente da campanha, com uma alteração
para a mensagem secreta, a fim de testar se eles poderiam descriptografar e
17 Este aspecto do teste pode incomodar o leitor, pois diferentes participantes do teste conseguiram extrair
diferentes quantidades de informações fazendo perguntas por e-mail, levando assim a resultados de testes que não
são tão padronizados quanto gostaríamos. No entanto, isto é, em certo sentido, realista; O PGP está sendo testado
aqui como um utilitário para comunicação segura, e as pessoas que o utilizam para esse propósito provavelmente
pedirão ajuda umas às outras com o software como parte dessa comunicação. Ressaltamos também que o objetivo
do nosso teste é localizar problemas extremos de usabilidade, não comparar o desempenho de um conjunto de
participantes com outro, e que, embora o desempenho melhorado de forma imprecisa por alguns participantes
possa fazer com que não consigamos identificar alguns problemas de usabilidade. problemas, certamente não nos
levaria a identificar um problema onde não existe.

leia com sucesso. Se naquele momento eles não tivessem feito isso por conta própria, eles receberiam
um e-mail solicitando que se lembrassem de fazer backup de seus chaveiros e de fazer um
certificado de revogação de backup, para ver se conseguiam executar essas tarefas. Se eles não
tivessem enviado uma versão criptografada separadamente da mensagem ao membro da equipe
com a chave RSA, eles também receberiam um e-mail do monitor de teste se passando por esse
membro da equipe e reclamando que não conseguia descriptografar a mensagem de e-mail.
6. O participante enviou um e-mail informando ao membro da equipe que possui a chave RSA que ele
deveria gerar uma nova chave ou atualizar sua cópia do PGP. Nesse caso, o monitor de teste continuou
enviando e-mails para aquele membro da equipe, dizendo que não podia ou não queria fazer
essas coisas e pedindo ao participante que tentasse encontrar uma maneira de criptografar uma
cópia que ele pudesse descriptografar.
Cada sessão de teste durou 90 minutos, desde o momento em que o participante recebeu a descrição inicial
da tarefa até o momento em que o monitor de teste interrompeu a sessão.
Foram fornecidos manuais para PGP e Eudora, juntamente com um disquete formatado, e os participantes
foram instruídos a usá-los tanto quanto quisessem.
Participantes
O teste do usuário foi realizado com 12 participantes diferentes, todos usuários experientes de e-mail, e
nenhum deles conseguiu descrever a diferença entre criptografia de chave pública e privada antes das
sessões de teste. Todos os participantes tinham frequentado pelo menos alguma faculdade e alguns
tinham pós-graduação. Suas idades variavam de 20 a 49 anos e suas profissões eram distribuídas de
forma diversificada, incluindo artistas gráficos, programadores, um estudante de medicina, administradores
e um escritor. Informações mais detalhadas sobre a seleção dos participantes e dados demográficos
estão disponíveis em Whitten e Tygar.18
Resultados
Resumimos os resultados mais significativos que observamos nas sessões de teste, novamente
focando no padrão de usabilidade para PGP que fornecemos na seção “Um padrão de usabilidade
para PGP”. Transcrições detalhadas das sessões de teste estão disponíveis em Whitten e Tygar.19
Evitando erros perigosos
Três dos doze participantes do teste (P4, P9 e P11) enviaram acidentalmente o segredo por e-mail aos
membros da equipe sem criptografia. Dois dos três (P9 e P11) perceberam imediatamente que o
tinham feito, mas P4 pareceu acreditar que a segurança deveria ser transparente para ele e que a
encriptação tinha ocorrido. Nos três casos, o erro ocorreu enquanto os participantes tentavam descobrir o
sistema por meio da exploração.
18 Whitten e Tygar.
19 Whitten e Tygar.

Um participante (P12) esqueceu sua senha durante a sessão de teste e teve que gerar um novo par
de chaves. Os participantes tenderam a escolher senhas que poderiam ser senhas padrão, com 8
a 10 caracteres e sem espaços.
Descobrindo como criptografar com qualquer chave
Um dos doze participantes (P4) não conseguiu descobrir como criptografar. Ele continuou tentando
encontrar uma maneira de “ativar” a criptografia e, a certa altura, acreditou que havia feito isso
modificando as configurações na caixa de diálogo Preferências em PGPkeys. Outro dos 12 (P2) levou
mais de 30 minutos20 para descobrir como criptografar, e o método que ele finalmente encontrou
exigiu uma reconfiguração do PGP (para fazê-lo exibir o PGPMenu dentro do Eudora). Outra (P3)
passou 25 minutos enviando repetidas mensagens de teste aos membros da equipe para ver se
havia conseguido criptografá-las (sem sucesso), e finalmente conseguiu somente após ser
solicitada a usar os botões do Plug-In PGP.
Descobrir a chave correta para criptografar
Entre os 11 participantes que descobriram como criptografar, a incapacidade de compreender o

modelo de chave pública foi generalizada. Sete participantes (P1, P2, P7, P8, P9, P10 e P11) usaram
apenas suas próprias chaves públicas para criptografar e-mails para os membros da equipe. Desses
sete, apenas P8 e P10 conseguiram enviar e-mails criptografados corretamente aos membros da
equipe antes do final da sessão de teste de 90 minutos (P9 descobriu que precisava usar a chave
pública do gerente de campanha, mas depois enviou e-mail para o toda a equipe criptografada apenas
com essa chave), e eles fizeram isso somente depois de terem recebido um e-mail bastante
explícito do monitor de teste se passando por membros da equipe. P1, P7 e P11 pareceram
desenvolver a compreensão de que precisavam das chaves públicas dos membros da equipe (para P1
e P11, isso também ocorreu depois de terem recebido um e-mail de solicitação), mas ainda não
conseguiram criptografar corretamente o e-mail. P2 nunca pareceu entender o que estava errado,
mesmo depois de receber duas vezes feedback de que os membros da equipe não conseguiam descriptografar seu e-mail.
Outro dos 11 (P5) entendeu tão mal o modelo que gerou pares de chaves para cada membro da
equipe e não para si mesmo, e então tentou enviar o segredo em um e-mail criptografado com as
cinco chaves públicas que havia gerado. Mesmo depois de receber feedback de que os membros
da equipe não conseguiram descriptografar seu e-mail, ele não conseguiu se recuperar do erro.
Descriptografando uma mensagem de e-mail
Cinco participantes (P6, P8, P9, P10 e P12) receberam e-mail criptografado de um membro da
equipe (após enviar e-mail criptografado com sucesso e divulgar suas chaves públicas).
P10 tentou por 25 minutos, mas não conseguiu descobrir como descriptografar o e-mail. P9
20 Isso é medido como o tempo que o participante gastou trabalhando na tarefa específica de criptografar uma
mensagem e não inclui o tempo gasto trabalhando na obtenção de chaves, na geração de chaves ou na
exploração de PGP e Eudora.

confundiu o bloco de mensagem criptografada com uma chave e enviou um e-mail ao membro da equipe
que o enviou para perguntar se era esse o caso; depois que o monitor de teste enviou uma resposta do
membro da equipe dizendo que nenhuma chave havia sido enviada e que o bloco era apenas a
mensagem, ela conseguiu descriptografá-la com sucesso. P6 teve alguma dificuldade inicial em
visualizar os resultados após a descriptografia, mas se recuperou com sucesso em 10 minutos. P8
e P12 conseguiram descriptografar sem problemas.
Publicando a chave pública
Dez dos doze participantes conseguiram disponibilizar com sucesso suas chaves públicas aos membros
da equipe; os outros dois (P4 e P5) tiveram tanta dificuldade com tarefas anteriores que nunca abordaram
a distribuição de chaves. Desses dez, cinco (P1, P2, P3, P6 e P7) enviaram suas chaves para o servidor de
chaves, três (P8, P9 e P10) enviaram suas chaves por e-mail para os membros da equipe, e P11 e
P12 fizeram ambos P3, P9 e P10 divulgaram suas chaves somente após serem solicitados a fazê-lo
por e-mail do monitor de teste se passando por gerente de campanha.
A principal dificuldade que os participantes pareceram enfrentar ao tentar publicar suas chaves
envolvia a representação icônica de seus pares de chaves em PGPkeys. P1, P11 e P12 expressaram
confusão sobre quais ícones representavam suas chaves públicas e quais suas chaves privadas, e ficaram
perturbados pelo fato de só poderem selecionar o ícone do par de chaves como uma unidade indivisível;
eles temiam que, se enviassem sua seleção ao servidor de chaves, publicariam acidentalmente suas
chaves privadas. Além disso, P7 tentou e não conseguiu enviar por e-mail sua chave pública aos
membros da equipe; ela ficou confusa com a diretriz de “colar sua chave na área desejada” da mensagem,
pensando que se referia a alguma área especificamente demarcada para esse fim que ela não
conseguiu encontrar.
Obtendo as chaves públicas de outras pessoas
Oito dos doze participantes (P1, P3, P6, P8, P9, P10, P11 e P12) obtiveram com sucesso as chaves
públicas dos membros da equipe; todos os oito usaram o servidor principal para fazer isso. Cinco dos
oito (P3, P8, P9, P10 e P11) receberam algum tipo de solicitação por e-mail antes de fazê-lo. Dos quatro
que não tiveram sucesso, P2 e P4 nunca pareceram ter consciência de que precisavam obter as chaves
dos membros da equipe; P5 ficou tão confuso com o modelo que, em vez disso, gerou chaves para os
membros da equipe; e P7 passaram 15 minutos tentando descobrir como conseguir as chaves, mas
falharam.
P7 desistiu de usar o servidor de chaves após uma tentativa fracassada em que tentou recuperar a chave
pública do gerente de campanha, mas não obteve nada de volta (talvez porque ela digitou o nome
incorretamente). P1 passou 25 minutos tentando, sem sucesso, importar uma chave de uma
mensagem de e-mail; ele copiou a chave para a área de transferência, mas continuou tentando
descriptografá-la em vez de importá-la. P12 também teve dificuldade ao tentar importar uma chave de
uma mensagem de e-mail: a chave era uma que ela já tinha em seu chaveiro, e quando copiar e colar a
chave não teve nenhum efeito na exibição das chaves PGP, ela presumiu que sua tentativa falhou e
continuou tentando. Eventualmente, ela ficou tão confusa que começou a tentar descriptografar a chave.

Lidando com o problema de tipos de chaves mistas
Quatro participantes (P6, P8, P10 e P12) conseguiram enviar e-mail criptografado corretamente para os
membros da equipe (P3 enviou um e-mail criptografado corretamente para o gestor da
campanha, mas não para toda a equipe). Para começar, P6 enviou uma mensagem criptografada
individualmente para cada membro da equipe, de modo que o problema dos tipos de chaves mistas
não surgiu para ele. Os outros três receberam um e-mail de resposta do monitor de teste se passando
por membro da equipe com uma chave RSA, reclamando que não conseguiu descriptografar o e-mail.
P8 empregou com sucesso a solução de enviar a esse membro da equipe um e-mail criptografado
apenas com sua própria chave. P10 explicou corretamente a causa do problema em um e-mail para
aquele membro da equipe, mas não conseguiu oferecer uma solução. P12 entendeu parcialmente,
inicialmente acreditando que o problema se devia ao fato de seu próprio par de chaves ser Diffie-Hellman/
DSS, e tentando gerar para si mesma um par de chaves RSA como solução. Quando ela se viu incapaz
de fazer isso, ela decidiu que talvez o problema fosse apenas que ela tinha uma cópia corrompida da
chave pública daquele membro da equipe e começou a tentar de várias maneiras obter uma boa cópia
dela. Ela ainda estava tentando fazer isso no final da sessão de teste.
Assinando uma mensagem de e-mail
Todos os participantes que conseguiram enviar uma mensagem de e-mail criptografada também
conseguiram assinar a mensagem (embora no caso de P5 ele tenha assinado usando pares de
chaves que havia gerado para outras pessoas). Não ficou claro se atribuíram muita importância a isso,
além do facto de ter sido solicitado como parte da descrição da tarefa.
Verificando uma assinatura em uma mensagem de e-mail
Novamente, todos os participantes que conseguiram descriptografar uma mensagem de e-mail também
verificaram, por padrão, a assinatura da mensagem, porque a única operação de descriptografia
disponível para eles inclui a verificação. Se eles estavam cientes de que estavam fazendo isso ou
prestaram atenção à mensagem do resultado da verificação, não foi algo que pudemos determinar neste
teste.
Criando um certificado de revogação de backup
Gostaríamos de saber se os participantes estavam cientes dos bons motivos para fazer um certificado
de revogação de backup e foram capazes de descobrir como fazê-lo com sucesso.
Lamentavelmente, isso foi muito difícil de testar. Decidimos pela solicitação direta para fazer um certificado
de revogação de backup, para os participantes que conseguiram enviar e-mail criptografado e
descriptografar uma resposta com sucesso (P6, P8 e P12).
Em resposta a esta solicitação, P6 gerou um par de chaves de teste e depois o revogou, sem enviar o
par de chaves ou sua revogação ao servidor de chaves. Ele parecia pensar que havia concluído a tarefa
com sucesso. P8 fez backup de seus chaveiros, revogou sua chave e depois enviou um e-mail ao
gerente de campanha dizendo que não sabia o que fazer a seguir. P12 ignorou a solicitação,
concentrando-se em outra tarefa.

Decidindo se confiará nas chaves do servidor de chaves
Dos oito participantes que obtiveram as chaves públicas dos membros da equipe, apenas três (P1, P6 e
P11) expressaram alguma preocupação sobre se deveriam confiar nas chaves. A preocupação do P1
foi expressa nos últimos cinco minutos da sua sessão de testes, por isso ele nunca ultrapassou esse ponto.
P6 observou em voz alta que as chaves dos membros da equipe foram todas assinadas pela chave do
gerente de campanha e tomou isso como prova de que eles eram confiáveis. P11 expressou grande
angústia por não saber se deveria confiar nas chaves e não avançou nos 10 minutos restantes da sessão
de teste. Nenhum dos três fez uso da rotulagem de validade e confiança fornecida pelas PGPkeys.
Conclusão
Esta seção resume as conclusões do nosso estudo de caso.
Falha no Design de Interface Padrão Os
resultados vistos em nosso estudo de caso apoiam nossa hipótese de que o modelo padrão de design de
interface de usuário, representado aqui pelo PGP 5.0, não é suficiente para tornar a segurança de
computadores utilizável por pessoas que ainda não têm conhecimento nessa área. Nossos 12 participantes
do teste eram geralmente educados e experientes no uso de e-mail, mas apenas um terço deles foi capaz
de usar o PGP 5.0 para assinar e criptografar corretamente uma mensagem de e-mail quando tiveram 90
minutos para fazê-lo. Além disso, um quarto deles expôs acidentalmente o segredo que deveriam proteger
no processo, enviando-o por e-mail que pensavam ter criptografado, mas não o fizeram.
Na seção anterior “Definindo usabilidade para segurança”, definimos usabilidade para segurança em
termos de quatro qualidades necessárias, que se traduzem diretamente em prioridades de design. A
interface de usuário do PGP 5.0 falha em permitir segurança eficaz quando não é projetada de acordo com
essas prioridades: os participantes do teste não entenderam o modelo de chave pública bem o suficiente
para saber que devem obter chaves públicas para as pessoas a quem desejam enviar mensagens
seguras. e-mail; muitos que sabiam que precisavam obter uma chave ou criptografar ainda tinham
dificuldades substanciais em descobrir como fazê-lo; alguns enviaram segredos erroneamente em
texto simples, pensando que haviam sido criptografados; e muitos expressaram frustração e insatisfação
com a experiência de tentar usar o PGP 5.0, a tal ponto que é improvável que continuassem a usá-lo no
mundo real.
Todo esse fracasso ocorre apesar do PGP 5.0 ser atraente, com operações básicas bem representadas
por botões com rótulos e ícones, e menus suspensos para o resto, e apesar de ser simples de usar
para quem já entende o modelos básicos de criptografia de chave pública e confiança baseada em
assinatura digital. Projetar uma segurança que seja utilizável o suficiente para ser eficaz para aqueles
que ainda não a entendem deve, portanto, exigir algo mais.

Avaliação de usabilidade para

segurança Como a segurança utilizável requer prioridades de design de interface de usuário que
não são as mesmas do software de consumo geral, ela também requer métodos de avaliação de
usabilidade que sejam apropriados para testar se essas prioridades foram suficientemente alcançadas.
Métodos padrão de avaliação de usabilidade, aplicados de forma simplista, podem tratar as funções de
segurança como se fossem objetivos primários e não secundários para o usuário, levando a conclusões
erradas. Um conjunto de trabalhos públicos sobre avaliação de usabilidade num contexto de segurança seria
extremamente valioso e quase certamente terá que provir de fontes de investigação, uma vez que os
desenvolvedores de software não estão ansiosos para tornar públicas as falhas de usabilidade que
encontram nos seus próprios produtos.
Em nosso próprio trabalho, que se concentrou em usuários de computadores pessoais que têm pouco
conhecimento inicial de segurança, atribuímos um alto valor à capacidade de aprendizagem e, portanto,
descobrimos que o walkthrough cognitivo é uma técnica de avaliação natural. Outras técnicas podem ser mais
apropriadas para utilizadores empresariais ou militares, mas provavelmente necessitarão de
adaptação semelhante às prioridades apropriadas para a segurança. Ao conceber testes de utilizador
apropriados, poderá ser valioso olhar para outros domínios em que existe uma responsabilidade
estabelecida pela segurança do consumidor; é mais provável que esses campos tenham um conjunto de
pesquisas sobre a melhor forma de estabelecer se os designs de produtos promovem com sucesso modos de uso seguros.
Rumo a melhores estratégias de

design As descobertas detalhadas em nosso estudo de caso sugerem diversas estratégias de
design para uma segurança mais utilizável, que estamos buscando em nosso trabalho contínuo.
Para começar, está claro que é necessário comunicar um modelo conceitual preciso de
segurança ao usuário o mais rápido possível. Quanto menor e mais simples for esse modelo
conceitual, mais plausível será que consigamos fazê-lo. Estamos, portanto, investigando formas
pragmáticas de reduzir a funcionalidade de segurança ao que é verdadeiramente necessário e
apropriado às necessidades de um determinado grupo demográfico, sem sacrificar a integridade
da segurança oferecida ao utilizador.
Depois que um modelo conceitual de segurança mínimo, porém válido, tiver sido estabelecido, ele deverá ser
comunicado ao usuário, de forma mais rápida e eficaz do que o necessário para modelos conceituais de
outros tipos de software. Estamos investigando diversas estratégias para conseguir isso, incluindo a
possibilidade de elaborar cuidadosamente metáforas de interface para combinar a funcionalidade de
segurança com um nível de precisão mais exigente.
Além disso, estamos analisando pesquisas atuais em software educacional para obter ideias sobre a melhor
forma de orientar os usuários no aprendizado do gerenciamento de sua segurança. Não acreditamos que
os usuários domésticos possam cooperar com tutoriais extensos, mas estamos investigando métodos mais
suaves para fornecer aos usuários a orientação certa no momento certo, incluindo a melhor forma de usar
mensagens de aviso, assistentes e outras ferramentas interativas. .

Trabalho relatado
Encontramos muito pouca pesquisa publicada até o momento sobre o problema da usabilidade
para segurança. Do que existe, o exemplo mais proeminente é o projecto Adage,21,22 que é
descrito como um sistema concebido para lidar com políticas de autorização para aplicações e
grupos distribuídos. A usabilidade foi um dos principais objetivos de design do Adage, mas destina-se
ao uso por administradores de sistemas profissionais que já possuem um alto nível de conhecimento
e, como tal, não aborda os problemas colocados para tornar a segurança efetivamente utilizável por
uma população mais geral. Também foi feito trabalho sobre a questão relacionada da usabilidade de
sistemas críticos de segurança,23 como aqueles que controlam aeronaves ou fábricas, mas podemos
esperar que, ao contrário dos usuários de segurança de computadores pessoais, os usuários desses
sistemas sejam cuidadosamente selecionados e treinados .
Ross Anderson discute os efeitos da não conformidade do usuário na segurança,24 e Don Davis
analisa as expectativas irrealistas que os sistemas de segurança baseados em chave pública muitas
vezes colocam sobre os usuários.25 Além disso, conhecemos apenas um artigo sobre testes de
usabilidade de uma rotina de autenticação de banco de dados, 26 e uma breve discussão sobre
as questões de segurança e privacidade inerentes ao trabalho colaborativo apoiado por computador.27
A tese de John Howard28 fornece análises interessantes dos incidentes de segurança relatados ao
CERT29 entre 1989 e 1995, mas concentra-se mais nos tipos de ataques do que nas causas. das
vulnerabilidades exploradas por esses ataques e representa apenas incidentes vivenciados
por entidades sofisticadas o suficiente para relatá-los ao CERT.
Agradecimentos
Agradecemos a Robert Kraut pelos conselhos úteis sobre o design do nosso teste de usuário. Este
trabalho foi apoiado em parte pela National Science Foundation e pelo United States Postal
Serviço.
O conteúdo desta publicação é de exclusiva responsabilidade dos autores.
21 Instituto de Pesquisa do Grupo Aberto, Visão Geral do Sistema Adage; publicado na Web em julho de 1998.
22 Mary Ellen Zurko e Richard T. Simon, Segurança Centrada no Usuário, Workshop sobre Novos Paradigmas de Segurança
(1996).
23 Nancy G. Leveson, Safeware: Segurança do Sistema e Computadores (Reading, MA: Addison Wesley, 1995).
24 Ross Anderson, “Por que os criptosistemas falham”, Communications of the ACM 37:11, 1994.
25 Don Davis, “Defeitos de Conformidade na Criptografia de Chave Pública”, Procedimentos da 6ª Conferência de Segurança USENIX
Simpósio (1996).
26 Clare-Marie Karat, “Teste de Usabilidade Iterativa de uma Aplicação de Segurança”, Proceedings of the Human Factors Society
33rd Annual Meeting (1989).
27 HongHai Shen e Prasun Dewan, “Controle de acesso para ambientes colaborativos”, Procedimentos de
CSCW '92.
28 John D. Howard, Uma Análise de Incidentes de Segurança na Internet 1989-1995, Ph.D. Tese, Carnegie
Universidade Mellon (1997).
29 CERT é a Equipe de Resposta a Emergências Informáticas formada pela Defense Advanced Research
Agência de Projetos, localizada na Carnegie Mellon University.

sobre os autores
Alma Whitten agora trabalha para o Google.
Doug Tygar é professor de Ciência da Computação na UC Berkeley, onde ocupa

cargos conjuntos no Departamento de Engenharia Elétrica e Ciência da
Computação (EECS) e na Escola de Gestão e Sistemas de Informação (SIMS). Ele
também é professor adjunto de Ciência da Computação na Carnegie Mellon
University. Dr. Tygar trabalha amplamente em problemas de
segurança e privacidade de computadores e é um dos criadores do NSF Science and
Technology Center TRUST: Team for Research on Ubiquitous Security Technologies. Dr.
Tygar atuou como presidente do Grupo de Estudos de Ciência e Tecnologia da Informação
sobre Segurança com Privacidade do Departamento de Defesa. Ele escreveu três livros e vários
artigos. Ele recebeu seu doutorado pela Universidade de Harvard e seu bacharelado pela UC Berkeley.
http:// www.tygar.net

Why Johnny Can't Encrypt

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Why Johnny Can't Encrypt

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Em Segurança e Usabilidade: Projetando Sistemas Seguros que as Pessoas

CAPÍTULO TRINTA E QUATRO

Por que Johnny não consegue criptografar

Uma avaliação de usabilidade do PGP 5.0

POR QUE JOHNNY NÃO PODE CRIPTOGRAFAR 679

680 CAPÍTULO TRINTA E QUATRO

POR QUE JOHNNY NÃO PODE CRIPTOGRAFAR 681

de testes de usuários, pode ser encontrada em Whitten e Tygar.11

de usabilidade para PGP.

Definindo Usabilidade para Segurança

Capturamos esse conjunto de prioridades na seguinte definição:

Definição: O software de segurança é utilizável se as pessoas que o utilizarão:

•São capazes de descobrir como executar essas tarefas com sucesso

•Não cometa erros perigosos

•Estão suficientemente confortáveis com a interface para continuar a usá-la

Propriedades problemáticas da segurança A

consideração, e o design generalizado da interface do usuário não faz isso.

1. A propriedade do usuário desmotivado

baixar software e desejam segurança para protegê-los

682 CAPÍTULO TRINTA E QUATRO

3. A falta de propriedade de feedback

4. A propriedade da porta do celeiro

5. A propriedade do elo mais fraco

Um padrão de usabilidade para PGP

POR QUE JOHNNY NÃO PODE CRIPTOGRAFAR 683

Se um usuário médio de e-mail sente necessidade de privacidade e autenticação, e

sem ficar tão frustrado a ponto de decidir desistir de usar o PGP?

• Entenda que para verificar assinaturas em e-mails de outras pessoas e enviar

684 CAPÍTULO TRINTA E QUATRO

O passo a passo cognitivo é uma técnica de avaliação de usabilidade modelada a partir da

POR QUE JOHNNY NÃO PODE CRIPTOGRAFAR 685

Passo a passo cognitivo

FIGURA 34-1 . Exibição de ferramentas PGP

686 CAPÍTULO TRINTA E QUATRO

PGP FIGURA 34-2 . Exibição de teclas

POR QUE JOHNNY NÃO PODE CRIPTOGRAFAR 687

FIGURA 34-3 . Caixa de diálogo PGP

688 CAPÍTULO TRINTA E QUATRO

teclas FIGURA 34-4

Política de gerenciamento de chaves

POR QUE JOHNNY NÃO PODE CRIPTOGRAFAR 689

chave) como certificador de outras chaves.

próprias chaves do usuário são sempre totalmente confiáveis.

certo número de chaves suficientemente confiáveis. Isso é perigoso.

Excluindo acidentalmente a chave privada

Divulgando acidentalmente uma chave

690 CAPÍTULO TRINTA E QUATRO

Revogação acidental de uma

Esquecendo a senha O PGP

Falha ao fazer backup dos chaveiros

Nas implementações anteriores do PGP, as funções de suporte ao gerenciamento de chaves (criação de

POR QUE JOHNNY NÃO PODE CRIPTOGRAFAR 691

Um grupo menor de usuários mais experientes provavelmente se preocupará mais com a

692 CAPÍTULO TRINTA E QUATRO

Esta seção descreve o propósito, o design e os resultados do teste do usuário.

Depois de informar os participantes sobre o cenário do teste e orientá-los sobre o uso do

POR QUE JOHNNY NÃO PODE CRIPTOGRAFAR 693

694 CAPÍTULO TRINTA E QUATRO

Evitando erros perigosos

POR QUE JOHNNY NÃO PODE CRIPTOGRAFAR 695

Descobrindo como criptografar com qualquer chave

Descobrir a chave correta para criptografar