Las llamadas al sistema que suministran entropía son llamadas al sistema en núcleos de sistemas operativos tipo Unix a través de las cuales los procesos pueden obtener datos entrópicos o aleatorios. La primera de ellas fue , introducida en el sistema operativo OpenBSD en la versión 5.6 (noviembre de 2014), como una refactorización del enfoque sysctl(3) KERN_ARND utilizado desde 1997. [1] Linux ofrece una llamada al sistema muy similar, , que se basaba en . [2] Estuvo disponible por primera vez en Linux 3.17, publicada en octubre de 2014. [3] En julio de 2015, Solaris introdujo versiones ligeramente modificadas de y . [4] En agosto de 2015, FreeBSD introdujo la llamada al sistema para obtener datos aleatorios del núcleo. [5]getentropygetrandomgetentropygetentropygetrandomread_random
Estas llamadas al sistema permiten que los procesos accedan a datos aleatorios de calidad sin tener que abrir ni leer desde pseudodispositivos de aleatoriedad .
Las API de Microsoft Windows y CryptGenRandomApple iOS son muy similares, pero no se implementan como llamadas del sistema.SecRandom
Tradicionalmente, los sistemas operativos tipo Unix suministran datos aleatorios a través de dos pseudodispositivos : /dev/randomy /dev/urandom. Sin embargo, leer de forma segura y fiable datos aleatorios de estos dispositivos puede ser difícil y complicado. Por ejemplo, un atacante podría interferir en el acceso de un proceso a los pseudodispositivos abriendo todos los descriptores de archivos disponibles o mediante una forma similar de ataque de agotamiento de recursos . El uso de estos dispositivos también interfiere en la revocación de privilegios . A los procesos sin privilegios a menudo se les niega la capacidad de abrir y leer archivos y dispositivos, y los dispositivos aleatorios ni siquiera son visibles para los procesos chrooteados .
La dificultad de utilizar pseudodispositivos de aleatoriedad a menudo lleva a los desarrolladores a utilizar en su lugar funciones de biblioteca estándar. Algunas de ellas, como las del lenguaje de programación Crand() , POSIX y random(), drand48()son muy inseguras cuando se utilizan para criptografía o aplicaciones similares, porque estos algoritmos son en realidad deterministas, ya que se han modificado intencionalmente para satisfacer los requisitos de reutilización de semillas a través de las interfaces srand(), srandom()y srand48().
Existe una diferencia significativa entre estas llamadas: getentropy()garantiza que se devolverán números aleatorios inmediatamente, sin ningún bloqueo. Requiere soporte operativo que garantice la inicialización de flujos de datos aleatorios lo antes posible. Para alentar a otros sistemas operativos a seguir este modelo, getentropy()no puede indicar errores a la aplicación. Otras llamadas descritas aquí pueden devolver errores en su lugar o bloquearse indeterminadamente. Esta semántica de bloqueo ha estado implicada en problemas importantes. [6]
A medida que la seguridad se convierte en una prioridad cada vez más extendida en el desarrollo de software, la aleatoriedad de calidad se utiliza con más frecuencia y en más contextos. Debido a esto, proporcionar aleatoriedad de calidad se considera cada vez más una responsabilidad central del núcleo. Las llamadas del sistema son la interfaz tradicional a través de la cual un proceso utiliza los servicios básicos del núcleo y, por lo tanto, los núcleos admiten el acceso a la aleatoriedad a través de llamadas del sistema.
Debido a que es más rápido y agrega otra capa de mezcla de entropía, generalmente se sugiere que los procesos usen los datos de estas llamadas al sistema a través de un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG) en lugar de asignar los datos recuperados directamente a las variables. Para este propósito, la biblioteca estándar C de OpenBSD incluye la función arc4random, que se espera que los programas llamen cuando necesiten datos aleatorios. [1] Al igual que getentropy, arc4randomtambién puede no bloquear ni devolver un error.
Este enfoque permite que un programa obtenga menos entropía del núcleo sin reducir la solidez de sus datos aleatorios. La getentropyllamada al sistema está diseñada en base a este supuesto, y no proporciona más de 256 bytes por llamada. [1] [7]