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, tal como o Linux, 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 compiladores[1] 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”)
[1] 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. ↩
