Recentemente comecei dar o meu email da USP, ewout@usp.br, em todas as circunstâncias em que era apropriado deixar claro a minha condição de "membro da comunidade USP". Como identificador este email é importante para mim e também gosto do fato que o servidor de email da USP é muito bem administrado (não vai sair do ar tantas vezes quanto o email da sua Unidade ou pior ainda, do departamento).

Mas não uso o sistema de ler email da USP. O novo webmail da USP é bem melhor do que o anterior mas prefiro a interface Web do Gmail, com a sua metáfora de conversas, funcionalidade de busca, etc. etc. 

No fundo, os nossos emails tem dois funcionalidades: primeiro como identificador e segundo como meio de receber mensagens. Felizmente, as funcionalidades de identificador e leitura de emails podem ser separadas. Veja como redirecionar email para @usp.br para o seu serviço de email preferido.

[Atualizado 14/32009: Nos comentários o Gabriel lembra que tem uma outra maneira de receber os seus emails da USP na interface do Gmail. Explico em baixo.]

Primeira alternativa: encaminhar

Primeiro, entre na sua conta do webmail e escolhe "Personalizar" (ou "Opções"):

Agora clique em "Redirecionamento":

Clique na frase "Encaminhamento...."

Preenche o email onde emails direcionados a seunome@usp.br serão encaminhados.

Segunda alternativa: buscar email usando POP

O Gmail (talvez outros serviços de webmail também) tem a possibilidade de carregar emails como se fossem o seu cliente no Desktop. Quando use o seu Outlook ou Thunderbird para buscar os seus email do servidor, está usando o protocolo POP. Pois bem, o Gmail pode funcionar como cliente do servidor de email da USP.

Na interface do Gmail, vá para Configurações / Contas / "Receber mensagens de outras contas". Clique no link "Adicionar uma conta de e-mail que você possui" e verá

Preenche o seu email da usp, e na próxima tela terá que preenher a sua senha do email da USP:

Pronto, agora o Gmail checará o seu email de tempos em tempos. 

Acho que prefiro usar primeiro método do redirecionamento, porque tenho a impressão que os meus emails chegam mais rápido. De um ponto de vista filosófico, me sinto melhor encaminhar email para Google do que dar as chaves da minha conta a Google que então vem fuçar na minha casa de tempos em tempos. Mas admito que é uma preocupação um tanto pedante.

Enviar e-mail como

Nos dois casos, e se usar Gmail, é interessante ainda fazer o seguinte passo. Em Settings / Accounts / "Send mail as" ("Enviar email como") adicione a mesma conta. Gmail vai mandar um email de confirmação a seunome@usp.br para você comprovar  que de fato é o dono deste email. A partir deste momento pode mandar emails usando o interface de Gmail, mas os destinatários vão achar que mandou usando o email da USP.

Comunicação a Distância

Desde que interações entre pessoas ocorrem a distância -- seja via sinais de fumaça, pombos, correios ou redes de computadores -- temos dificuldades de saber com quem estamos falando e para se assegurar da privacidade da comunicação. No mundo dos nosso ancestrais nas savanas de Africa era fácil manter uma mensagem confidencial, era só uma questão de falar baixo. Os nossos cérebros, os nossos comportamentos e as nossas intuições não evoluíram para viver num mundo de interações sociais a distância. Evoluímos para ser extremamente bons em reconhecer a identidade da pessoa com quem estamos interagindo, uma coisa essencial em todas as interações sociais. Mas em comunicação à distância não dispomos da rica linguagem corporal necessária para identificar alguém e estabelecer uma relação de confiância. Nas condições de comunicação a distância não podemos mais confiar nas nossas estratégias que evoluíram para avaliar a identidade e até honestidade do nosso interlocutor. Precisamos de tecnologia.

Criptografia pode ser usado para assegurar a privacidade, a integridade da comunicação e da autenticidade da identidade de quem está no outro lado do canal de comunicação. São três objetivos distintos. Para manter privacidade a comunicação deve ser encriptada. Existem outras técnicas criptográficas para se assegurar da proveniência da mensagem e prevenir que elas são alteradas por partes não autorizadas. Em geral a impressão que temos de criptografia é que encriptar é a função principal dela, mas na verdade na grande maioria dos casos é autenticação (da mensagem e da identidade) é muito mais importante. Deste texto, a lição mais importante é que encriptar sem autenticar não tem valor. Se você não sabe com quem está se comunicando, é melhor nem tentar encriptar as suas mensagens porque a sua segurança é ilusório.

Neste post somente discuto criptografia "simétrico", que supõe que uma chave secreta compartilhada existe entre as partes. A distribuição destas chaves hoje em dia muitas vezes é feito usando criptografia assimétrica (ou, "de chave pública") que talvez tratarei mais tarde.

Autenticação simples e segredos compartilhados

A maneira mais simples de convencer alguém no outro lado do canal da sua identidade é mostrar que vocês compartilham um segredo. Isto pode ser feito por meio de

1. uma coisa que você sabe: um senha como senha1 por exemplo;
2. uma coisa que você é: os seus impressões digitais por exemplo;
3. uma coisa que você possui: uma chave ou cartão por exemplo.

Para um segredo compartilhado se manter secreto obviamente este obviamente deve ser difícil de roubar ou adivinhar. Onde guardar os seus segredos? Um segredo guardado na sua cabeça é chamado de senha. A vantagem de senhas é que ninguém pode roubar e que sempre está contigo.

Para ser difícil de adivinhar o segredo tem que ser de uma certa complexidade. Mas senhas guardadas na sua cabeça sofrem das limitações gravíssimas do seu cérebro: como vai se lembrar de uma senha do tipo "@df$8hdghujtrffhced#$"? [Para especialistas: é impossível guardar os 128 bits de entropia (complexidade) necessários para segurança adequada na sua cabeça.] Por outro lado, senhas simples são muito fácil de adivinhar, é só começar com "senha", "1234", "senha1" e continuar tentando com todas as palavras do dicionário, com alguns pre- e pos-fixos até encontrar a senha correta.

Uma solução perfeita não existe, mas uma estratégica boa para guardar uma senha é guardar uma parte (simples) na sua cabeça e uma outra parte num papelzinho na sua carteira.

Segredos compartilhados em geral precisam ser mais complexos do que senhas. Para guardar um segredo de 128 bits como "2de1afe3b45b656eade98034daaa123a" o seu próprio computador parece um bom lugar. Infelizmente computadores são notoriamente inseguros, infestado por vírus, troianos, etc. que podem roubar o segredo. Um smartcard (como o seu cartão da USP) parece interessante, mas como fazer o interface entre o segredo guardado lá e o software que roda o algoritmo? Talvez precisamos colocar os algoritmos de criptografia na própria smartcard. Está ficando um dispositivo cada vez mais parecido com um computador, com todos os seus problemas. Também, um smartcard ou token é fácil de roubar ou perder.

Em suma, para ter um sistema seguro, todos as partes do sistema tem que ser seguro. Não adianta colocar uma grande porta de ferro para proteger uma barraca de lona. Seja com for, em seguida vou descrever como poderia construir a porta de ferro.

Encriptar: algoritmos e chaves

Se usar uma senha para se identificar através de um canal de comunicação, como vai evitar o roubo da senha por qualquer um que está monitorando este canal? De uma maneira geral, precisamos de encriptação para manter a confidencialidade da comunicação. Veja a Alícia querendo falar com Roberto.

O malvado Everton fica sabendo de tudo:

O que fazer se Alícia e Roberto precisam se comunicar sobre um canal não seguro como cartões postais ou a internet? Precisamos encriptar a mensagem por meio de uma cifra

Uma cifra é um algoritmo para encriptar uma mensagem. É uma receita, um conjunto de regras, que transformam a mensagem original. Segredos pequenos e simples são mais simples de guardar. É por isso que o conjunto de regras, os algoritmos de encriptação, sempre são públicos e a segurança somente depende da chave, um número pequeno que junto com o algoritmo determina a encriptação (veja também o Princípio de Kerckhoffs em baixo).

A chave, um segredo pequeno, é usado para guardar o segredo grande, a mensagem. É preciso saber a chave (e o algoritmo) para decifrar a mensagem encriptada. Para criptografia simétrico a mesma chave é usado tanto para encriptar a mensagem como para decriptar ela. Isto significa que tanto quem manda como o receptor da mensagem tem que ter acesso à chave e que temos que distribuir as chaves de uma maneira segura, por algum outro canal. Mas avançamos porque é mais fácil distribuir e guardar segredos pequenos (as chaves) do que segredos grandes (as mensagens).

Integridade da Mensagem

Encriptar a sua mensagem não é suficiente para manter um canal de comunicação seguro. O malvado Everton ainda pode mudar a mensagem, o que pode ser altamente prejudicial. O recipiente precisa se assegurar da integridade da mensagem e da identidade de quem mandou. A solução para ambas os problemas é um MAC ("Message Authentication Code"). É um código ou número, um espécie de impressão digital da mensagem, que é mandado junto com a mensagem. Somente quem está de posse da chave secreta pode fazer o MAC e somente quem está de posse da mesma chave pode verificá-lo.

Um MAC pode ser feito por exemplo usando um hash. Um hash é uma função que transforma uma mensagem numa seguência de bytes de uma maneira imprevisível. Veja por exemplo o hash chamado de SHA-1 de duas mensagens parecidas:

    sha1("senha")  = 7751a23fa55170a57e90374df13a3ab78efe0e99
    sha1("senha1") = adddc25f41289bb0e9da98742a94a861560c1c37

Ou seja, uma pequena mudança na entrada leva a saídas completamente differente. Um MAC simples podia então ser sha1(KM+mensagem). O malvado Everton não pode mudar nenhuma letra da mensagem sem que o MAC correto mude completamente. E para quem não conhece a chave secreta KM é inviável desbrobrir qual MAC corresponde à mensagem falsa. [Este MAC simples não deve ser usado em sistemas reais por razões complicadas ("length extension attacks", veja Ferguson e Scheier, 2003)]

Vale a pena ressaltar mais uma vez o fato talvez surpreendente que a confidencialidade e a autenticidade da mensagem são independentes e tem soluções (encriptação e o MAC) diferentes. A primeira vista parece suficiente encriptar a mensagem. Afinal, o malvado Everton pode mudar a mensagem encriptado, mas sem ter a chave secreta a mensagem decriptado não vai fazer sentido. Mas mesmo mensagens sem sentido podem fazer danos, se Roberto assume erroneamente que vem de Alícia. Uma outra razão porque é útil separar confidencialidade e autenticação é porque assim podemos usar algoritmos especializados e otimizados para cada função. Para uma terceira razão, imagine o caso onde encriptar a mensagem é indesejável (talvez por razões legais). Mesmo assim Roberto gostaria ser capaz de se assegurar que a mensagem veio de Alícia. Com as funções confidencialidade e autenticidade implementados por algorimos diferentes isto é possível.

Autenticação deve ser considerado mais importante do que a encriptação. Pense assim: que mal o malvado Everton pode fazer sabendo do conteúdo da comunicação? Agora, que maldades ele poderia fazer se pudesse manipular as mensagens?

O Canal Seguro

Um canal de comunicação que garante a privacidade, a integridade e a autenticidade da Alícia é chamado de "seguro". Basicamente combina as duas funcionalidades descritos acima. Primeiro a Alícia calcula um MAC (usando uma chave secreta KM) e depois encripta a mensagem e o MAC junto (usando uma outra chave secreta, geralmente). Roberto decripta e verifique a integridade da mensagem.

Não é nada trivial implementar um canal seguro. Por exemplo, para evitar ataques onde Everton usa mensagem antigos ("replay attacks") é necessário numerar as mensagens, ou usar um "nonce", um número usado exatamente uma vez durante a existência do canal. Um outro exemplo é que a chave compartilhada deve valer por uma duração limitado, primeiro para evitar que o Everton retransmite mensagens de uma sessão anterior e segundo porque chaves de uma maneira geral devem ter uma vida curta (se uma "chave de sessão" for comprometida, pelo menos as outras sessões se mantem seguras). Os algoritmos de encriptação e do MAC devem ser usados de uma determinada maneira. Assim tem muitas detalhes que podem comprometer a segurança do canal.

Princípio de Kerckhoffs

É um princípio básico de criptografia que a segurança do sistema deve depender somente do fato que a chave é segredo. O algoritmo deve ser público e transparente. Este princípio é atribuído a Auguste Kerckhoff, um estudioso Holandês de línguas, trabalhando na França no século 19. Uma razão é que um segredo de tamanho pequeno é muito mais fácil de guardar do que um segredo grande (o algoritmo). Quando um sistema criptográfico é usado por mais do que alguns poucos participantes, é ingênuo pensar que o algoritmo pode ficar um segredo. O fato é que é muito mais simples esconder (e distribuir entre os participantes) chaves do que sistemas de criptografia inteiros.

Mas a razão principal é que sistemas, protocolos e algoritmos públicos podem ser submetidas a revisão por pares para descobrir eventuais falhas. Sistemas e algoritmos secretos são revisados somente por um grupo necessariamente pequeno. Com exceção do NSA, é extrememamente improvável que um grupo particular vai produzir sistemas melhor do que os públicamente revisado e testados.

Segue que nunca deve inventar os seus próprios algoritmos ou sistemas de segurança. Sempre deve usar algoritmos públicos e bem-testados.

Distribuição das chaves

Nada falamos ainda sobre como Alícia e Roberto conseguiram o segredo compartilhado. O maior problema de criptografia simétrica é justamente a distribuição segura das chaves. Se temos N pessoas querendo se comunicar deve ter N(N-1)/2 chaves para que cada par de usuários possam se comunicar seguramente. Por exemplo, se um grupo de 10 pessoas querem organizar reuniões sem que as autoridades saibam é preciso distribuir de alguma forma segura 45 chaves secretas. Para 100 pessoas são 4950 chaves. Para computadores em rede, um possível solução é usar um servidor de confiânca e online que distribui chaves. Kerberos é um protocolo que faz isto.

Este tipo de solução requer uma coordenação prévia entre as partes. Existem soluções também para partes que nunca se encontraram ou conheceram antes. Por incrível que parece, existe uma sequência de troca de mensagens (agora conhecido como "Diffie-Hellman") que acaba com Alícia e Roberto tendo o mesmo número, sem que o malvado Everton, que escutou a conversa toda, fica sabendo. Também é possível fazer criptografia onde as chaves secretas não precisam ser as mesmas e compartilhadas. Em criptografia de chave pública Alícia pode manter um segredo e dar uma chave pública a Roberto que então pode ser comunicar seguramente com Alícia. Mas os mesmos problemas de autenticação e identidade surgem, como veremos num próximo post.

Referencias

Applied Cryptography, Bruce Schneier (1996) e Practical Cryptography, Niels Ferguson e Bruce Schneier (2003) são clássicos da área. O livro de Ross Anderson sobre engenharia de segurança é muito bom e o FAQ antigo do RSA vale a pena conferir. Veja também alguns links relacionados com criptografia que colecionei.

Este texto e o arquivo das imagens estão disponível para remix (cc-by).

Uma estratégia comprovada para incentivar a criação de aplicações inovadoras é identificar entidades de interesse, dar nomes a elas e permitir fazer conexões entre elas. A internet foi feito inicialmente em cima de redes telefônicas, a Web foi feito em cima da Internet. Estamos vendo nos últimos anos a construção de uma nova plataforma que poderíamos chamar de uma Web Social. As “entidades de interesse” neste caso são pessoas, identificadas por meio perfis em sites de rede social ou outras formas de expressão da identidade digital.

Esta nova camada de identidade para a Web ainda é incipiente mas já está tomando forma com a aceitação cada vez maior de serviços como Myspace, Facebook, Orkut [Boyd 2007]. É consenso que a questão da identidade digital vai tomar uma importância cada vez maior no futuro próximo. Por muitos anos a criação de identidades com alguma ligação real com pessoas no mundo real era muito difícil e até hoje a norma e expectativa é que identidade na Internet é basicamente inventada (“on the Internet nobody knows you are a dog” segundo o famoso quadrinho de Peter Steiner no The New Yorker.

Danah Boyd explica o processo de criação de uma identidade digital por adolescentes americanos no MySpace (o Orkut dos jovens americanos) e como a possibilidade de construir perfis anônimos ou “falsos” contribuiu ao sucesso de MySpace. Ainda segunda ela, jovens americanos não se importam trocar de perfil a cada poucos meses.

Mas cada vez mais, a tecnologia permite (e pessoas um pouco mais maduros querem) a criação de identidades virtuais com uma estreita ligação entre (alguma das) identidades da pessoa no mundo real. As novas aplicações que podem ser construídos podem ser de grande valor comercial e não é a toa que o mundo corporativo está tomando nota. MySpace foi vendido por meio bilhão de dólares e Facebook tem um valor avaliado de bilhões de dólares.

Mas instituições como governos e universidade podem também prover um ambiente que permite membros da sua comunidade consolidar (uma das) suas identidades profissionais online. Está na hora de todo mundo se conscientizar que a sua identidade digital é um recurso importante na sua vida, um recurso que deve ser administrado e controlado com muito cuidado. Segundo uma pesquisa recente somente 47% de usuários da Internet fez uma busca pelo próprio nome. Mas na medida que sua persona digital pública fica mais visível é mais importante de controlar ela.

É neste sentido que é importante que instituições como Universidades oferecam acesso fácil à criação de identidades digitais e incentivam a publicação e arquivamento da produção intelectual dos seus membros. Não podemos deixar estas facilidades na mão de corporações ou terceiros com interesses não necessariamente alinhados com as de instituições públicas. Estas devem usar protocolos e formatos abertos e padronizados na medida do possível para ter interoperabilidade horizontalmente (outras instituições) e verticalmente (o futuro). 

Já falei sobre uso de OpenID na USP e o próximo passo neste espaço é investigar outras maneiras de colocar o usuário no centro das atenções e em pleno controle da sua identidade digital. Talvez uma combinação de FOAF e OpenID pode ser usado como primeiro passo neste sentido.

Mais uma razão que algo tem que ser feito a respeito da questão de identidade no internet, já!

Estava feliz da vida escutando o meu rádio pessoal no last.fm quando, após músicas de The Velvet Underground, Captain Beefheart, Tom Waits, Talking Heads, Rage Against the Machine etc., de repente, tive que aquentar uma música de Juanes.

Juanes? Sim, Juanes. Normalmente last.fm é a melhor coisa que existe para quem está longe da sua coleção de música. Last.fm sabe das músicas que toco (o Amarok manda tudo para last.fm) e faz um monte de coisas tipo "Web2.0" com estas informações: rádio personalizado, um rede social, um wiki com informações geradas pelos usuários a respeito das músicas e artistas, recomendações, até um musical compatibility rating, onde um algorítmo avalie a sua compatibilida musical com um outro usuário. Melhor do que o signo astrológico, me parece.

Mas aí que está:  não sou o único que toco músicas no meu computador. A namorada tem gosto musical, digamos, complementar... Até que tem um overlap, Jarabe de Palo, Manu Chao (ou seja: pode ser espanhol, mas tem que ser Europeu... ). É claro que a mistura de gostos embaralha todos os algorítmos de last.fm. Em princípio deve ser possível para os algorítmos detetar uma distribuição bi-modal ou algo parecido e fazer ajustes, mas acredito que a solução mesmo é Amarok, last.fm e serviços similares implementar mecanismos de associar uma identidade às músicas que toco.

Alias, ainda tem gente que não usa Amarok? Integração com Wikipedia para exibir informações sobre a música que está tocando, integração com last.fm (mande músicas e toca radio last.fm), integração com Amazon para exibir arte de álbum, etc. etc.

Semana passada fiz uma apresentação sobre OpenID para a USP. A sua identidade na rede é um problema cada vez mais urgente. Usamos muitos serviços no google, yahoo, msn, flickr, terra, uol, etc. etc. e temos uma identidade em cada um destes serviços. Precisamos comprovar que somos nos no outro lado da rede por meio de uma senha e mesmo assim, o serviço não pode confiar que uma pessoa realmente é quem ele/ela diz que é: "no internet, ninquém sabe que é cachorro".

O problema

Uma maneira tradicional de resolver o problema de identidade e senhas no meio corporativo é via um serviço de autenticação como LDAP. Tem dois problemas com LDAP que devem ser resolvidos com um sistema complementar:

1. Para autenticar pessoas cada serviço (por exemplo Jupiter, o webmail da USP) pede a senha e autentica contra a base LDAP (central ou replicado) e isto significa que cada um dos serviços devem ser seguros e confiáveis: lidam com a senha única do usuário afinal. Isto implica numa barreira de entrada muito grande para serviços potencialmente inovadores e úteis oferecidos por grupos não diretamente ligado aos orgoes centrais. Estamos vivendo uma "democratização" do software de serviços. Qualquer um hoje em dia pode instalar um stack LAMP na sua máquina e começar desenvolver e oferecer serviços como blog, wiki, fóruns, etc. à comunidade USP. Estes desenvolvidores se beneficiaram muito se tivesse uma maneira de autenticar alguem como sendo da comunidade USP sem ter que passar pelos trâmites para obter acesso aos bases de dados corporativos da USP.
2. LDAP fornece uma senha única, mas não oferece single sign on (SSO): o usuário tem que se logar e fornecer os seus credenciais em cada serviço que ele usa.

A proposta

O protocolo OpenID se propõe resolver parcialmente estes problemas. Com OpenID uma pessoa se identifica com um URL, por exemplo http://openid.usp.br/155469 ou htt//ewout.org. O usuário escolha um Provedor de Identidade (IdP) que gerencia este identidade. Nunca mais vai dar uma senha a um serviço onde é preciso criar uma conta: se o serviço suporta OpenID, o usuário se loga com o seu OpenID, o serviço redireciona para o IdP que faz a autenticação no serviço por trás das cortinas. Veja este demo do Simon Willison para ver como funciona do ponto de vista do usuário.

Uma possibilidade é que a USP ofereça um OpenID do tipo http://openid.usp.br/155469 para todo mundo. Este servidor (provedor de identidade OpenID) seria simples de implementar e manter. Poderia ser ligado com o base de dados LDAP num lado e usar senha/passwd ou certificados no lado do usuário. O DI poderia implementar a certificação das pessoas, gerenciamento da senha, etc. O fato que alguém tenha um OpenID no IdP openid.usp.br comprovaria que este pessoa é da comunidade USP.

Assim,

• Desenvolvedores de serviços para a comunidade USP como stoa.usp.br, moodle.usp.br ou os serviços (por agora imaginários) wiki.fea.usp.br ou moodle.fe.usp.br podem configurar o seu software para usar OpenID como login. Para acertar que alguém é da comunidade USP estes serviços devem tratar os OpenID associdados com o IdP openid.usp.br como sendo da USP e tratar outros OpenID como "de fora".
• Os nossos usuários podem usar este OpenID dentro e fora da USP.
• Ou, usando delegação, os usuários podem configurar um OpenID deles mais amigável, por exemplo http://stoa.usp.br/ewout/ , continuando usando o servidor openid.usp.br

É uma solução SSO que pode estar pronto muito rapidamente, já que existem muitas bibliotecas e até servidores inteiros prontos.

Mais sobre OpenID

OpenID é um sistema onde o usuário pode controlar a sua identidade. Ao contrário de sistemas centralizados como o antigo Passport do Microsoft, o usuário escolha o seu IdP e pode mudar de provedor quando quiser. É importante que isto implica que um serviço do web não pode "confiar" num OpenID: qualquer um pode rodar o seu IdP e um OpenID pode ser associado a qualquer IdP. Em geral, a única coisa que um IdP faz é dizer: este pessoa que se cadastrou conosco controla esta URL. É só no caso do openid.usp.br que, na minha proposta, pode confiar que o DI cadastrou uma pessoa real com um determinado número usp, etc.

Do ponto de vista técnica, OpenID é uma tecnologia que faz pouco, mas faz bem. As principais vantagens são

• OpenID é uma solução usando tecnologias "light-weight" e "do web": DNS, HTTP, URLs, etc.
• É fácil de implementar (bibliotecas para PHP,Python, Ruby, Java, etc.)
• É uma padrão aberta, com suporte global: um OpenID é usável no internet inteiro. A sua identidade é dereferenciável, fácil de lembrar (o meu OpenID é http://ewout.org/).
• É um protocolo simples e são as aplicações desenvolvidos usando o protocolo que fornecem a "intelligência".

Porém, tem que ser claro que OpenID, do jeito que está, não implementa nenhum tipo de perfil ou papeis. Existem planos para extender o protocolo, mas hoje as únicas atributos que um serviço pode pedir de um IdP OpenID são somente os da extensão SREG: nome, email etc. Certamente a USP vai ter que implementar ou uma outra camada em cima de OpenID ou um outro protocolo SSO como Liberty ou Shibboleth para oferecer estes informações aos vários serviços.