Cómo el borrado de secretos puede generar fugas de datos

La práctica habitual de eliminar secretos de memoria tras su uso puede, paradójicamente, aumentar la superficie de ataque si no se implementa con precisión. El uso ciego de funciones de borrado, como memset() o funciones opacas, introduce copias no deseadas en la memoria que persisten tras la ejecución, ya que el compilador optimiza el código eliminando operaciones de borrado si no son visibles para el lector final. En el caso de memset(), el compilador elimina la instrucción de borrado si el valor intermedio no se lee después, pero si se fuerza el borrado mediante punteros volátiles, se generan instrucciones de almacenamiento (strb) que escriben ceros en la pila sin haber almacenado previamente el valor a borrar, dejando el registro original intacto. Al aislar el borrado en una función separada sin LTO, el compilador debe almacenar el valor en la pila para que la función opaca pueda leerlo y borrarlo, creando una copia adicional que el borrado no elimina si el compilador pospone la comparación hasta después de la llamada. Además, los registros de CPU son críticos para la seguridad: se copian en cada cambio de contexto y pueden contener claves completas o hashes. Las funciones de borrado tradicionales solo escriben en memoria y no gestionan los registros, que son visibles en core dumps, archivos de hibernación y vulnerabilidades microarquitecturales como Zenbleed. Por tanto, el borrado de memoria es insuficiente para proteger secretos que residen en registros, requiriendo estrategias más complejas que consideren el flujo de ejecución completo.