Auditoría de Seguridad (por Jean Philippe Aumasson)

Nos gustaría anunciar que Ergo ha pasado con éxito la auditoría de seguridad de ciertas partes (las más críticas) del código. Esta vez la auditoría fue realizada por Jean-Philippe Aumasson (también conocido como veorq, https://aumasson.jp/ ).

El informe detallado se encuentra a continuación. No se encontró nada crítico. Comentarios sobre los problemas encontrados:

1. Sobre la contraseña de la billetera, proporcionaremos una recomendación en las próximas versiones del cliente del protocolo. No estamos seguros de que se aplique una imposición estricta sobre la contraseña, pero haremos más consultas al respecto.
2. Cambiar los parámetros "n" y "k" tiene sentido solo al lanzar una nueva red. Cambiar estos parámetros en un nodo de minería hará que los bloques producidos sean inválidos para otros nodos. Cambiar estos parámetros en el cliente del protocolo significa ir a otro fork (los bloques provenientes de los participantes honestos del protocolo serán rechazados). Así que tal vez no sea necesario realizar verificaciones adicionales, ya que las personas que lanzan nuevas redes establecerán "n" y "k" correctamente.
3. Actualmente, el nodo de Ergo (así como otros clientes de protocolo de blockchain y billeteras de los que tenemos conocimiento, así como las bibliotecas criptográficas que estamos utilizando) no proporciona protección contra ataques de canal lateral que se ejecutan localmente (por ejemplo, ataques de temporización o inspección de memoria por malware o virus). ¡Así que por favor protejan las máquinas en las que están ejecutando billeteras!

==========================================================================================================

% Evaluación de seguridad de Ergo % Jean-Philippe Aumasson % 07/Dic/19

Resumen

Ergo nos solicitó realizar una evaluación de seguridad de varios componentes de su Plataforma Ergo:

• Creación y verificación de pruebas del protocolo Sigma
• Almacenamiento seguro de secretos de la billetera
• Validación de Prueba de Trabajo

​Este breve informe resume nuestra evaluación y describe nuestros hallazgos y recomendaciones de mitigación.

Pruebas del protocolo Sigma

​El protocolo Ergo se basa en ErgoScript, un lenguaje de scripting que soporta declaraciones sigma, que pueden ser probadas y verificadas a través de pruebas no interactivas de conocimiento.

Estas pruebas son declaraciones descritas como un árbol de condiciones AND, OR y de umbral, cuyas hojas son pruebas de conocimiento de un problema de logaritmo discreto.

La prueba de la declaración sigma se hace no interactiva gracias a la transformación de Fiat-Shamir.

Esta lógica está especificada en el documento de ErgoScript, y las rutinas específicas de prueba y verificación se describen en su Apéndice A.

​Los desafíos de implementación son:

• Definir la codificación de las pruebas que sean seguras y eficientes, e implementar la serialización y deserialización que siempre tenga éxito en el procesamiento de entradas válidas, y que siempre falle de manera controlada al procesar entradas inválidas.
• Implementar correctamente las funcionalidades de prueba y verificación, de acuerdo con la especificación, y lo más importante, de tal manera que ninguna declaración inválida pueda pasar la verificación con éxito.

Revisamos estos dos aspectos, basándonos en el código en el repositorio sigmastate-interpreter, y en el documento de ErgoScript, comparando cuidadosamente el comportamiento previsto (en el Apéndice A) con el comportamiento real tal como se implementó.

​Notablemente revisamos el código de los rasgos y objetos SigSerializer, Interpreter, y ProverInterpreter.

​Principalmente buscamos errores de las siguientes clases:

• ​Procesamiento inseguro de entradas malformadas
• Procesamiento inseguro de entradas inusualmente largas o cortas
• Comportamiento cuando hay una gran profundidad de árbol o nivel de recursión
• Uso inseguro de tipos y estructuras de Scala
• Tipos de variables inapropiados
• Desbordamientos de enteros
• Condiciones de carrera
• Errores lógicos

​A pesar de una revisión extensa, no identificamos ningún problema de seguridad.

La lógica y los internos del protocolo son, no obstante, relativamente complejos, y creemos que el mayor riesgo está en el análisis y verificación de pruebas. Para explotar tales problemas, sin embargo, un atacante tendría que crear un script semánticamente correcto que de alguna manera le beneficie, pero que pase la verificación cuando no debería.

En cuanto a la seguridad del software, Scala elimina ciertas clases de errores, pero el código de Scala aún puede sufrir errores debido al comportamiento específico de Scala o a errores no manejados.

Billetera

La funcionalidad de la billetera de Ergo permite a sus usuarios almacenar un secreto en el disco y recuperarlo, inicializando la billetera con una nueva semilla cuando se usa por primera vez.

​Esta lógica está principalmente definida en ErgoWalletActor, y un componente clave respecto al almacenamiento de secretos es JsonSecretStorage.

​La primera vez que se crea una billetera, el comando InitWallet hace lo siguiente:

• Generar settings.walletSettings.seedStrengthBits bits aleatorios, como entropía inicial. Por defecto, se generan 160 bits.
• Generar un BIP39 a partir de los bits aleatorios generados, que se puede ver como una codificación de los bits de entropía. Se utiliza la lógica estándar de BIP39, con contraseña opcional.
• Derivar una semilla de la mnemotecnia utilizando la lógica de derivación basada en PBKDF2 de BIP39.
• Cifrar esta semilla en el disco con AES-GCM, utilizando un nonce aleatorio, y una clave derivada de la contraseña utilizando PBKDF2-HMAC-SHA256 con 128000 iteraciones, utilizando una sal aleatoria.

Para desbloquear una billetera ya creada, un usuario proporciona la contraseña y la billetera intenta descifrar los datos almacenados.

​Para restaurar una cuenta existente a partir de una frase de paso BIP39, se realiza un proceso similar al de la inicialización, excepto que la billetera derivará la semilla de la mnemotecnia en lugar de elegir una mnemotecnia aleatoria.

​Los dos riesgos que identificamos aquí son:

• La ausencia de verificaciones sobre la longitud de la contraseña: dado que la contraseña es suficiente para acceder a la semilla dada la secreta almacenada en disco de la billetera, la contraseña debería en teoría tener al menos tanta entropía como la mnemotecnia, y en la práctica debería ser prácticamente difícil de romper. Por lo tanto, recomendamos imponer una longitud mínima de contraseña, por ejemplo, de 16 caracteres.
• Las copias de los valores secretos (contraseña, semilla y claves privadas derivadas) probablemente permanecerán en la memoria después de la ejecución del software de la billetera, lo cual es una limitación intrínseca de los lenguajes recolectados por basura como Scala.

Otro proceso o usuario que comparta el mismo espacio de direcciones de memoria podría potencialmente recuperar los secretos, y también podrían aparecer en volcado de memoria. Hasta donde sabemos, no hay una mitigación efectiva en Scala puro.

​

Validación de PoW

​Después de revisar previamente la seguridad de Autolykos PoW, realizamos otra ronda de revisión centrada en su lógica de verificación más reciente, y notablemente los cambios en el commit eb0f85a.

​El archivo principal relevante es AutolykosPowScheme, y otras operaciones importantes se implementan, por ejemplo, en HeadersProcessor y ModifierValidator.

​Verificamos que la lógica de verificación implementada es consistente con la especificada en las especificaciones de Autolykos, y que está correctamente integrada en la lógica de validación del encabezado del bloque.

​Creemos que los siguientes puntos deben ser abordados:

• Validación más estricta de k y n: aunque la clase impone k<=32 (número de elementos en la solución) y n<31 (log2 del número total de elementos), aún podrían crearse débiles a partir de los parámetros autorizados. Por lo tanto, la función validate() puede tener validaciones adicionales que n y k sean iguales a los valores previstos.
• Afirmar que k y n son valores positivos, ya que actualmente los negativos (como Ints) pasarían las declaraciones assert.