Utilizamos, para uma primeira aproximação, da técnica de abuse cases para a modelagem de ameaças à solução. Embora julguemos a técnica de "árvore de ataque", proposta por Schneier, no mínimo tão efetiva (e provavelmente mais precisa na descrição dos meios possíveis de serem utilizados num ataque), optamos pela modelagem de casos de abuso por sua consistência com a descrição adotada para os requisitos do projeto. Essa escolha tem a vantagem de não precisar ser definitiva. A medida que o design final do aplicativo se definir, é aconselhável a realização de novas análises de ameaças possíveis. Em cenários onde os procedimentos do sistema (o seu protocolo) estão bem definidos, a técnica de modelagem de ameaças de Schneier alcança seus melhores resultados. Assim, futuramente, podemos acrescentar árvores de ataque precisas e detalhadas ao modelo atual.
Para melhor visualização, dividimos o diagrama de casos de abuso levantado em duas figuras. Na primeira delas, a seguir, são ilustradas as ameaças ao caso de uso assinar documento.
De saída, um atacante pode simplesmente tentar falsificar o documento que será assinado. Para esta técnica de modelagem, ao contrário da técnica de Schneier, não importa os meios que serão usados. Essa foi uma das razões que nos levaram a adotá-la: a essa altura da engenharia do projeto, nem todos os meios que serão utilizados para assinar um documento estão definidos - e esses meios concretos poderão ser explorados por um atacante. Assim, neste momento nos basta saber que Mallory, o participante indesejado e malicioso do processo, pode, por algum meio à sua disposição, fornecer ao usuário um documento falso (digamos, um testamento transferindo todos os bens do usuário para ele) em lugar do documento que este pretende assinar. Para uma ameaça tão genérica, onde os meios efetivos de ataque não estão (ainda) descritos, a única contra-medida disponível é permitir ao usuário a visualização do documento que será assinado. Naturalmente, para que esta contra-medida seja eficaz contra à ameaça descrita, é necessário que a implementação assegure que o buffer de memória utilizado para exibir o documento ao usuário seja o mesmo buffer fornecido ao dispositivo criptográfico para assinatura. Do contrário, se as duas operações forem independentes, Mallory pode ter sucesso simplesmente se inserindo entre os dois casos de uso (View document e Sign document).
Um segundo ataque possível é a pura simples inspeção de memória do computador do usuário, destinadada a roubar informações confidenciais ali armazenadas. Não somos otimistas quanto à nossa capacidade de elaborar contra-medidas destinadas a mitigar essa ameaça. Nosso raciocínio é que, se um atacante tem acesso à memória física do computador da vítima, então não há nenhuma razão para que ele seja incapaz de elaborar um ataque bem sucedido contra os segredos ali armazenados. No entanto, diversos requisitos listados no MCT-4 se destinam a mitigar (em alguma medida, pelo menos) essa ameaça. Assim, precisamos considerá-la, mesmo sem muita esperança de sucesso.
Consideremos, portanto, o problema. Em primeiro lugar, é preciso assinalar que, do ponto de vista do domínio da nossa aplicação, a única informação confidencial a ser considerada é o PIN (o Personal Identification Number, a senha de acesso ao dispositivo criptográfico). Os documentos assinados podem ser, do ponto de vista do usuário, altamente sigilosos (pode se tratar, por exemplo, de uma ordem de pagamento a um espião altamente colocado em país estrangeiro); no entanto, a proteção dessa informação está fora do escopo da solução Signthing: se ela precisa ser protegida contra inspeção, uma outra aplicação deve ser utilizada em conjunto (digamos, uma hipotética solução Secrething). O segundo aspecto que precisa ser ressalvado refere-se ao fato de que, sob certas condições, nossa aplicação não tem como proteger o PIN. Por exemplo, se o usuário estiver usando um software de gerenciamento de smart-card que adote o padrão de acesso da CryptoAPI da Microsoft, ele deverá confiar que a solução adotada por aquela empresa proteja da melhor maneira possível o seu PIN. Isto porque é a própria CryptoAPI quem capta o PIN do usuário e não a aplicação de assinatura. Esta só é responsável pela captação dessa informação se estiver sendo utilizado software de suporte que atenda ao padrão PKCS#11. Neste último caso, o usuário não precisa confiar cegamente: ele pode simplesmente inspecionar o código fonte disponibilizado.
O primeiro meio de ataque possível ao PIN é a inspeção direta da memória física do computador. É essa uma das ameaças assumida pelo Requisito I.23 do MCT-4, que recomenda que o PIN não seja mantido em cache (para reduzir seu tempo de exposição à curiosidade maliciosa) e que, após sua utilização, a área de memória utilizada seja sobrescrita (a especificação FIPS 140-2 fala da zeroization das informações confidenciais). É preciso assinalar que este tipo de procedimento não elimina completamente a informação da memória: mesmo após o desligamento do computador, restam vestígios da informação alocada em RAM durante sua utilização. Não entanto, a inspeção desses vestígios requer recursos consideráveis, geralmente disponíveis somente a agências governamentais. A zeroization da memória, contudo, fornece aquilo que uma contra-medida defensiva fornece: aumenta o tempo gasto e os recursos necessários ao ataque.
Qualquer contra-medida elaborada deve, contudo, considerar o tempo de vida médio esperado para o segredo em memória. Informações confidenciais de longa duração em memória são ameaçadas pela estratégia de virtualização da memória adotada pelos sistemas operacionais modernos. Neste caso, há boa possibilidade de eventualmente a informação ser armazenada em disco, de modo inteiramente alheio à vontade da aplicação, pelo subsistema de gerenciamento de memória. Neste caso, é bem possível que a informação fique disponível em disco em claro durante longos períodos. No caso do uso presente, o ciclo de vida do PIN é bastante curto: ele precisa durar apenas até se realizar o logon no dispositivo criptográfico. Mesmo assim, esse risco precisa ser considerado no nosso contexto.
O risco é da virtualização do PIN é real mesmo no nosso contexto por conta de duas otimizações realizadas pela tecnologia de implementação adotada: a combinação da estratégia de cache de strings realizada implicitamente pelo Java e o insidioso (do ponto de vista da segurança) garbage collector. Uma string, uma vez atribuída, não pode mais ser modificada (pelo menos pelo uso legítimo da JVM, já que é existem técnicas ilegítimas de alteração do valor de uma variável string): uma nova atribuição à variável utilizada implica no descarte para o GC do seu valor corrente e pela atribuição do novo valor a uma nova área de memória. Portanto, não é possível sobrescrever uma variável string no Java! E pior: a área de memória com a informação sensível poderá ficar disponível por um longo tempo, até que o GC decida desalocá-la, tornando altamente provável sua virtualização em disco. Os bisbilhoteiros agradecem... Portanto, para uma implementação em Java, as contra-medidas à inspeção de memória devem incluir a não utilização de strings para armazenar temporariamente informações sensíveis.
Um outro meio de ataque ao PIN é obviamente a técnica do "papagaio de pirata": Mallory simplesmente se posta atrás da cadeira do usuário e vê o que está sendo digitado... Naturalmente, o MCT-4 obriga ao clássico mascaramento do valor digitado, evitanto o feedback ao usuário e ao indesejado Mallory. No entanto, Mallory, como um participante ativo embora indesejado, tem à disposição outros meios para "ver" o que está sendo digitado. Se ele tem acesso ao computador do usuário (e a ameaça de inspeção da memória assume esse fato implicitamente), pode simplesmente plantar um key logger para registrar e eventualmente transmitir o resultado. Entao, usamos um "teclado virtual", que aceita a entrada através do mouse. Com isso, Mallory passa a atacar "fotografando" os cliques do usuário. E contra-atacamos mascarando (e movendo de lugar) também a entrada do teclado virtual. Esse é o caminho adotado pelos bancos na Internet. No entanto, ele não tem fim: a vantagem está sempre com Mallory, se este tem acesso direto de algum modo ao computador do usuário. O próximo passo nesse jogo de gato e rato, no caso de applets Java, é simplesmente plantar um Cavalo de Tróia que se ligue à porta de depuração da JVM! É por isso que dizemos que não é possível elaborar contra-medidas eficazes contra ameaças decorrentes do acesso direto do atacante ao computador do usuário.
No entanto, os ataques ao PIN não devem ser considerados os de maior risco. Utilizando a técnica de Schneier, podemos concluir que este ramo da arvore de ataque não necessariamente é o de maior probabilidade de exploração bem sucedida. Para alcançar o objetivo de fazer-se passar pelo usuário utilizando suas chaves criptográficas em seu lugar, Mallory precisa obter o PIN e o próprio smart-card do usuário, que não são necessariamente objetivos triviais, em especial se tiver como requisito passar desapercebido pela vítima. Algumas contra-medidas simples, que pouco têm a ver como o software e o hardware envolvidos, podem ser bastante eficazes. Para proteger as chaves , o usuário pode trocar o PIN com freqüência e, se o software de suporte aceitar, utilizar passphrases de alta entropia mas fáceis de lembrar (para ele). No meu caso, uma boa senha poderia ser, por exemplo, HeradeCândidosBraçosPiedadeSentiudosAquivos, um dos milhares de versos de Homero (traduzidos), escolhidos dentre as centenas de poemas que recordo. Mesmo um atacante que me conheça bem terá dificuldade de descobrir qual verso, de que poema e de que poeta foi utilizado naquela semana. Embora o bloqueio de apenas um dos ramos obrigatórios da árvore seja suficiente para deter o ataque, um usuário cauteloso pode tomar medidas extraordinárias para proteger sua carteira (e seu smart-card). Ele deve, por exemplo, resistir à tentação de ser acariciado por uma garçonete bonita num cassino de Las Vegas, quando estiver portando seu smart-card (a técnica é cinematográfica e foi utilizada para roubar um crachá de identificação no filme Onze Homens e um Segredo). Tudo isso, torna o ataque à identidade do usuário através do roubo da chave criptográfica privada uma possibilidade com baixa probabilidade de sucesso, se o usuário colaborar (o que nunca acontece).
Uma outra ameaça ao caso de uso Assinar Documento consiste em Mallory modificar o comportamento do aplicativo, alterando o software. Neste caso, ele pode introduzir um comportamento auto-destrutivo, como forçar o aplicativo a assinar o que Mallory quer. Novamente, é requerido o acesso direto ao computador do usuário. Se este existir, o atacante pode substituir um dos componentes do aplicativo por um patch seu. A elaboração de um patch é ainda mais simples se, como no nosso caso, o aplicativo alvo do ataque for desenvolido em Java. É esta a ameaça assumida implicitamente no Requisito I.25 do MCT-4, que obriga o fornecimento de garantias de integridade e origem no caso de o aplicativo utilizar componentes de carga dinâmica. Naturalmente, os redatores daquele documento estão pensando na utilização de assinatura de código por certificados digitais (confiáveis), uma medida bastante simples de implementar (e de burlar). Lembre-se: não há nada que possamos fazer para deter um atacante determinado e cheio de recursos que tem de algum modo acesso direto ao computador alvo.
Um meio de contornar essa proteção é obter um certificado digital de assinatura de código em nome de uma fonte confiável. Isso permitirá o fornecimento de código malicioso como se fosse originado de uma fonte (supostamente) confiável. Isso de fato já aconteceu: há alguns anos, a Verisign (uma Autoridade Certificadora que sempre foi proclamada pelos fabricantes de browsers, mesmo os open source como o Mozilla, como confiável) emitiu um certificado de assinatura de código em nome da Microsoft entregando-o a duas pessoas que não eram funcionários daquela empresa. Quando o caso foi descoberto, a Microsoft teve que distribuir um patch de segurança para o MS Internet Explorer, de modo que ele recusasse código assinado com aquele certificado. Portanto, é forçoso admitir que este ataque é viável.
Por outro lado, se Mallory tem acesso ao computador alvo, ele pode introduzir seu patch também no aplicativo que realiza a validação do código assinado (o browser, por exemplo), de modo que ele dê como autenticado código malicioso. Portanto, o simples atendimento ao Requisito I.25 pode ser insuficiente para deter esse tipo de ataque. Não importa a contra-medida imaginada: se o atacante tem acesso direto ao computador-alvo, se ele é determinado e tem suficientes recursos à disposição, sempre é possível elaborar um ataque bem sucedido.
Uma contra-medida que talvez seja viável em ambientes corporativos é a auditoria externa do código executável, sobretudo se combinada com medidas operacionais. Suponha que, periodicamente, a própria aplicação obtenha na rede um código dinâmico de auditoria. O programa auditor deve conhecer previamente tanto o hash esperado dos arquivos da aplicação bem como a chave pública do assinante daquele código. Sua verificação é, então, comunicada a uma aplicação servidora, que sinaliza um oficial de segurança eventuais falhas de validação. Naturalmente, essa aplicação deve dispor de um cadastro prévio e independente de todas as instalações na rede corporativa; com isso, ela saberá qual estação foi atacada, permitindo reação (operacional) adequada.Claro que essa contra-medida é também ela mesma atacável. Se Mallory tem acesso ao computador-alvo, ele pode substituir o próprio programa auditor por um patch que sinalize normalidade ao servidor de auditoria. Isso significa que, a se implementar esse tipo de solução, deverá ser realizada exaustiva modelagem de ameaças, buscando determinar meios de contorná-la e, se necessário, elaborando contra-medidas apropriadas. Algumas dessas possíveis ameaças são discutidas sumariamente mais adiante. Por ora, basta assinalar o problema.