Revista MSDN Magazine Edição 14 - Criptografia forte nos aplicativos

Clique aqui para ler todos os artigos desta edição

Criptografia forte nos aplicativos

por Michael Stuart  e J Sawyer

Todos nós já fomos alertados para não armazenarmos informações em nossos computadores. Você sabe que armazenar senhas, números de cartões de crédito ou de CPF no sistema é arriscado, e pode abrir as portas para alguém que queira roubar essas informações. Contudo, é bem possível que você precise armazenar esse tipo de informação crítica em sistemas de computadores.

Vamos supor que você esteja executando um sistema bancário de processamento de pagamentos. Tal sistema precisa armazenar números de cartão de crédito para processar cobranças recorrentes, para estornar cobranças e realizar auditorias de contas. Nesse caso, uma metodologia não reversível (como um algoritmo hash aplicado a uma senha) simplesmente não é apropriada. Além disso, ambos os cenários exigem criptografia e decriptografia em várias máquinas independentes.

Neste artigo, examinaremos algumas das questões envolvidas no desenvolvimento de componentes de criptografia forte para aplicativos. Os componentes poderão ser usados em casos como o que descrevemos. Além disso, temos alguns outros objetivos para um programa que criamos, chamado CryptoUtility. Primeiro, queremos o nível mais alto possível de segurança que seja prático para aplicativos de servidores Web. Segundo, a instalação deve ser relativamente fácil, do ponto de vista do administrador, de modo a permitir a implementação de diversos servidores sem precisar passar por dez páginas de instruções de instalação. Terceiro, a criptografia reversível (que abordaremos mais tarde) deve estar disponível, com as chaves protegidas e armazenadas em segurança. É claro que, como se trata de um aplicativo de servidor, este deverá ser altamente expansível e funcionar durante meses sem a necessidade de cuidados administrativos ou de reinicialização. Finalmente, esse componente deve ser acessível a aplicativos COM de legado (como ASP clássico) assim como a aplicativos baseados no .NET (como Web Services e aplicativos executados no ASP.NET).

Todo aplicativo apresenta algum tipo de possível vulnerabilidade. No caso de aplicativos que lidam com informações extremamente críticas, esses perigos são ainda maiores e você deverá ter o conhecimento mais completo possível sobre eles. Você deve determinar como as ameaças identificáveis interagem umas com as outras e como diversos problemas independentes podem se combinar para formar uma vulnerabilidade. De posse dessas informações, você poderá identificar riscos de segurança, definir a prioridade dos riscos possíveis e decidir sobre os níveis aceitáveis de risco.

Vamos explorar ameaças usando os modelos STRIDE e DREAD, conforme descritos por Michael Howard em Writing Secure Code, Second Edition (Microsoft Press®, 2003). O STRIDE é um modelo para categorizar ameaças; significa Spoofing (falsificação de identidade), Tampering (violação), Information disclosure (liberação de informações), Denial of service (negação de serviço) e Elevation of privilege (elevação de privilégio). DREAD é um modelo para cálculo do risco total associado a uma ameaça; significa Damage potential (potencial de danos), Reproducibility (reprodutibilidade), Exploitability (possibilidade de exploração), Affected users (usuários afetados) e Discoverability (possibilidade de descobrimento). A modelagem e a análise de ameaças estão além dos objetivos deste artigo, mas faremos referência aos termos associados aos modelos STRIDE e DREAD ao descrevermos as medidas de segurança de sistemas.

Arquitetura do CryptoUtility

As decisões de arquitetura afetam todas as soluções. Nosso primeiro ponto de decisão é se vamos implementar o CryptoUtility como uma DLL em processo, um serviço do Windows® ou um Serviced Component utilizando Enterprise Services. O desenvolvimento do componente como uma DLL em processo apresenta diversos problemas de segurança. Primeiro, o CryptoUtility é executado como a conta do ASP.NET. Muito embora ainda não tenhamos decidido sobre uma estratégia básica de gerenciamento, sabemos que não devemos fazer com que a conta do ASP.NET tenha acesso à chave. Isso criaria a possibilidade de um agressor explorar uma vulnerabilidade e obter informações confidenciais por meio do Web site. Enquanto houver probabilidades contra nós, os dados que deveremos proteger são de tal nível que o potencial de danos é extremamente alto. Esse tipo de invasão poderia afetar todos os usuários, então sempre tentamos evitar essa opção. ...