Una firma digital "suficientemente buena", con tecla corta

Ningún esquema como este evitará que un atacante determinado active la "función de depuración", por el simple expediente de ingeniería inversa del código para ubicar la parte que, en el código del software, se verá así:

if (is_good_password(password)) {
    activate_debug();
}

y convertirlo en:

if (true) {
    activate_debug();
}

que generalmente es solo una cuestión de convertir un salto condicional en un salto incondicional, o un salto no condicional (es decir, un código de operación nop ). Ni siquiera es difícil de hacer, incluso en grandes piezas de software (por ejemplo, lo hice una vez para Windows 2000, para permitir una prueba personalizada CSP : CSP debe estar firmado, y la solución provista por Microsoft para desactivar la verificación de firmas en plataformas de desarrollo era válida solo para Win2k SP2 o WinXP, mientras tenía un Win2k SP4, así que tuve que hackear el advapi32.dll , que me tomó 3 horas).

Dicho esto, si solo desea verificar una contraseña, la forma más fácil es almacenar en su software un token de verificación de contraseña, es decir, un valor de hash calculado sobre la contraseña. ¡No es necesario traer toda la parafernalia de las firmas digitales! Solo un simple hash, y esto puede acomodar contraseñas de cualquier longitud. El software incorpora el valor de hash; cuando se ingresa la URL de "depuración", la clave aparece después del " debug/ " y ve si coincide con el valor de hash registrado. Por lo tanto, la contraseña no aparece en el código del software (ni en texto claro, o simplemente "codificado"), y puede usar una "contraseña" lo suficientemente corta como para escribirla.

Las firmas digitales son buenas aquí solo si tiene un número ilimitado de "Debbies", y desea poder dar una "contraseña de depuración" a cada Debbie, de modo que cada Debbie tenga su propia contraseña distinta de las contraseñas dadas a los demás Debbies, y desea hacer que sea imposible para una Debbie malvada, independientemente de la ingeniería inversa que haga, para volver a calcular las otras contraseñas de la que ella ya tiene (si solo tiene, por ejemplo, 20 Debbies, solo puede incluir 20 valores hash en su código; por "ilimitado" quiero decir "potencialmente millones"). Este es un escenario bastante específico. Un ejemplo son las "claves de producto": las firmas digitales teóricamente podrían frustrar los generadores de clave de producto. Sin embargo, la firma digital más fuerte no funcionará mejor que un hash de contraseña contra un atacante que realiza algunas horas de ingeniería inversa en el código para localizar el código de operación de salto condicional correcto. La firma no protegería contra el acceso ilícito al código de depuración; protege solo contra la extensión de un acceso ilícito a una escala industrial, dándole a muchos otros clientes sin requerir una modificación local del código, lo que se denomina "pirateo" .

Para la función hash, si tiene dudas, use SHA-256 - si (y solo si) la "contraseña" es lo suficientemente larga y aleatoria (por ejemplo, 128 bits aleatorios). Si se le permite a Debbie elegir una contraseña "significativa" (una que un ser humano podrá recordar, en lugar de tenerla escrita en un pedazo de papel), entonces debe usar una función hash que resista los ataques de diccionario, p.ej PBKDF2 or bcrypt .

No utilice la forma de "cifrar con la clave privada" para describir una firma; Es una explicación terrible, que no funciona para todos los algoritmos de firma. Es solo una forma histórica con la que RSA se presentó por primera vez, pero incluso para RSA es incorrecta: no tiene en cuenta el relleno , y el relleno es esencial para la seguridad (consulte PKCS # 1 ). Solo olvídalo. No hay nada de malo en "usar la clave privada para firmar algunos datos" y "usar la clave pública para verificar algunos datos".

Factorizar una clave rsa de 74 bits se puede hacer con wolfram alpha , 256 bits por lo general toma aproximadamente alrededor de una hora, incluido el cumplimiento del código, por lo tanto, estarás haciendo una clave rápida para cambiar un montón de cosas.

Lo que sugiero hacer es usar un sistema de firmas muy diferente, ya sea ECDSA o idealmente BLS. ECDSA todavía 4t longitud de hash. Sin embargo, la longitud de la clave cambia la longitud de la firma. Su otro gran problema es que, a menos que use RSA-PSS, tendrá que lidiar con todo un conjunto de dolores de cabeza, sobre cómo rellenar correctamente sus mensajes.

Sin embargo, hay algo un poco diferente que en realidad se llama BLS, es un esquema de firma basado en el emparejamiento. Si no tiene que preocuparse por los molestos sistemas heredados, probablemente sea su mejor opción, enlace es una biblioteca que tiene bls implementado. Como ejemplo y hace la vida bastante fácil.

También le permitiría no tener que cambiar las claves, ya que siempre que gire alrededor de una clave de 384 bits, tendrá una clave privada muy sólida, ya que se basa en un problema diferente. RSA es factorización de enteros aquí, en una curva con diferentes métricas de fuerza.

ECDSA le dará un margen de seguridad mucho mayor, ya que es aleatorio y las claves son mucho más difíciles de encontrar. Es un poco más complejo, pero las predicciones actuales del tamaño de tu clave son demasiado pequeñas.

Lo mejor que puedes hacer si quieres hacer algo como esto es usar un esquema de firma corto como BLS, que es raro y un poco difícil de entender al principio, pero es la forma en que se está moviendo la criptografía.

Si desea firmas compactas, debe consultar ECDSA. RSA es bastante horrible si key & El tamaño de la firma es importante. No tengo idea de qué fuerza clave tendría una clave RSA de 256 bits, pero incluso una clave de 1.024 bits solo tiene una fuerza de 80 bits y se necesita una clave de 15.360 bits para lograr una resistencia de 256 bits.

Las firmas ECDSA sin procesar son 2 veces la longitud de la clave como r & s son iguales a la longitud de la clave privada. Se requiere una longitud de clave de 2x la fuerza de la broca. Entonces, para la seguridad de 80 bits, está buscando una firma de 320 bits.

Para evitar un ataque de repetición, el mensaje firmado no debe ser un número estático sino una fuente aleatoria. Si lo está haciendo por urls, podría ser sencillo, ya que acceder / depurar hará que el software devuelva un mensaje único para que Debbie lo firme.

Si realmente se necesita un tamaño de firma más pequeño, puede intercambiar bits por el tiempo de verificación, pero no le ahorrará mucho, ya que las verificaciones de firmas de ECDSA ya son lentas (puede obtener algo del orden de 2 ^ 16 verificaciones por segundo por núcleo en la cpu moderna).

Puede usar una firma larga (por ejemplo, de 256 bits), ¡pero solo haga que el humano ingrese una firma corta (por ejemplo, de 128 bits)!

Simplemente genere la firma de bits N (por ejemplo, 256) como de costumbre, luego muestre al humano los primeros bits M (por ejemplo, 128). Luego, el programa de verificación puede recorrer todas las combinaciones de colas de bits (N-M) anexadas a los M bits que ingresó el humano. Por supuesto, el programa de verificación tardará más tiempo en comprobarlo, pero está bien (quizás incluso sea bueno).