Após as acusações feitas por Edward Snowden de conluio entre NSA e as fabricantes de chips para enfraquecer a criptografia disponível aos cidadãos, o FreeBSD também decidiu que não vai mais permitir que os geradores de números aleatórios oferecidos internamente nas CPUs da Intel e da Via (RDRAND e Padlock, respectivamente) sejam usados diretamente para fornecer (via /dev/random) números aleatórios para os aplicativos, incluindo os de criptografia – caso em que eventuais desvios no grau de aleatoriedade podem ser especialmente danosos, facilitando o acesso de terceiros ao material criptografado que venha a ser interceptado.
A bordagem escolhida pelo FreeBSD é similar à do Linux: os geradores via hardware continuarão em uso quando disponíveis, mas o acesso a eles via chamadas do sistema não retornará diretamente o número aleatório gerado, e sim o processará por meio de um algoritmo que acrescente outras fontes de entropia, de modo a reduzir a possibilidade de que desvios intencionais sejam preservados.
Entretanto, quando se fala de ausência de confiança na CPU, vale lembrar que o controle que o sistema operacional exerce sobre ela tem limites práticos. Assim como ocorre no caso dos compiladores1 as possibilidades de manipulação por parte do fornecedor da ferramenta podem ser mais amplas do que o que pode ser inspecionado pelos meios usuais. (via arstechnica.com - ““We cannot trust” Intel and Via’s chip-based crypto, FreeBSD developers say | Ars Technica”)
- O link sobre o caso dos compiladores é especialmente interessante: é um texto escrito em 1984 por Ken Thompson – ele mesmo, co-criador do Unix – demonstrando como é possível alterar compiladores de maneiras difíceis de detectar, e mencionando os microcódigos das CPUs na sua conclusão, como parte do mesmo grupo no qual não se pode confiar sem inspecionar, e nem sempre se pode inspecionar. ↩
O artigo "Criptografia: FreeBSD decide que também não pode confiar nos recursos embutidos nas CPUs Intel e Via" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.
Nenhum comentário:
Postar um comentário