Não-Repudiação

Antes de entrar no assunto, um disclaimer: não conheço os detalhes casos mencionados pela reportagem e estarei falando aqui em termos genéricos. Não sou advogado e essa não é uma opinião legal, e de forma alguma representa a opinião da Microsoft Informática Ltda. ou da Microsoft Corporation.

Em Segurança da Informação, "não-repudiação" se refere à incapacidade de um dos participantes de uma transação em mais tarde negar que tenha participado dela. Para isso a transação deve conter algo que a ligue inequivocamente aos seus participantes, de forma que seja implausível pensar que algum deles não tenha efetivamente participação.

O que seria  "plausível" ou não é certamente muito subjetivo, e por isso o próprio conceito de não-repudiação é motivo de intensa controvérsia no mundo de SI. Não-repudiação é um conceito que extrapola a matemática e tem implicações inclusive legais, e cada observador faz a sua própria avaliação sobre se é plausível ou não alguém negar a sua participação. Por exemplo, o grupo da IETF que definiu o padrão de certificação digital PKIX incluiu na RFC 2459 um flag (no campo Key Usage) chamado "Non-Repudiation", que indica que aquele certificado garante a não-repudiação em transações. Só que nunca houve acordo sobre o que significa exatamente este flag e quando ele deve ser usado, até mesmo porque cabe às partes aceitar essa capacidade e não à Autoridade Certificadora, e hoje essa é uma opção praticamente morta dentro do PKIX.

Isso me veio a cabeça quando o jornal Valor Econômico noticiou ontem que, em alguns casos, a Justiça está dando de causa aos bancos quanto aos prejuízos causados por uma suporta fraude bancária:

O cliente de um grande banco acessa sua conta pelo seu computador pessoal e identifica uma transferência de R$ 50 mil não autorizada por ele. O banco se exime da responsabilidade, alegando que a transferência foi feita com o uso do login e senha do cliente, e o caso vai parar na Justiça. Pela jurisprudência do Judiciário brasileiro, cabe ao banco provar que o cliente fez a transferência, certo? Errado. A tendência dos juízes hoje tem sido a de, diante da prova feita pelo banco de que seu sistema de segurança é eficiente, exigir que o próprio cliente comprove que utilizou todas as medidas de segurança possíveis - como a atualização de antivírus - para evitar a ocorrência de fraudes virtuais em sua máquina pessoal. Se o acesso for feito de um cibercafé, por exemplo, a chance de o cliente perder a ação é grande.

Na verdade o juiz considerou que o cliente não tem como repudiar a transação, ou seja, seria implausível pensar que não tenha sido o cliente o seu autor. Mas essa conclusão se sustenta tecnicamente? Como toda a venia, acredito que não.

Para começar, vamos lembrar que as instituições financeiras utilizam em sua maioria senhas como forma de autenticação. Senhas na verdade são segredos compartilhados, que como o próprio nome diz são de conhecimento do cliente e da instituição. Se a única prova da participação do cliente na transação for o conhecimento de uma senha que a instituição também conhece, é perfeitamente plausível imaginar que a transação possa ter ocorrido sem a participação do cliente. Se ele não é o único que conhece a senha, então é plausível que tenha sido o outro. Transações autenticadas por senhas por definição podem ser repudiadas.

Bem diferente por exemplo é a situação das transações interbancárias feitas através do Sistema de Pagamentos Brasileiro (SPB). Dentro do SPB as mensagens enviadas entre os bancos, clearings e Banco Central são assinadas digitamente com uma chave privada de posse exclusiva da instituição, bem como suas confirmações de recebimento. Uma instituição não tem como repudiar o envio ou o recebimento de uma mensagem: é completamente implausível assumir que alguém conseguiu fazer um ataque a uma criptografia RSA de 1024 bits de tamanho de chave.

São as instituições financeiras que escolhem a forma de autenticação utilizada para suas transações, e cabe a elas assegurar que é efetivamente o correntista que está fazendo a transação. Ao escolher o uso na Internet de uma forma que permita não-repudiação como senhas, elas estão assumindo o ônus da prova em caso de fraude. Poderiam ter feito diferente, como fizeram no SPB, mas não fizeram. Por isso eu acho que o Augusto erra o alvo quando diz:

Eu concordo que bancos sejam responsabilizados quando há uma postura de tentativa de massificação do canal em detrimento da informações sobre seus riscos. Isso não acontece mais, por exemplo, com o Itaú. Eu, como cliente deste banco, fui muito bem avisado por eles sobre os riscos do canal. Se eu for lesado por conta de uma bobagem minha depois de todos esses avisos não acho que seja justo responsabilizar o banco.

A questão não é informar o cliente dos riscos. A questão é que estes riscos são do banco, não do cliente. Pode-se dizer o que o Internet Banking jamais teria o sucesso que tem hoje se fosse feito de forma diferente, mas nada muda o fato que o banco assumiu o risco ao criar um canal de negócios onde ele não é capaz de provar que foi o cliente que fez a transação.  E me parece muito mais sensato implementar formas de garantir a não-repudiação das transações do que tentar transferir o risco para o cliente.

P.S. André Fucs faz uma outra análise interessante da mesma notícia.