c# - generar - ¿Cuál es el rol del token de clave pública?
token visual basic (5)
¿Cuál es el rol del token de clave pública?
El token de clave pública es un número pequeño que es un "token" conveniente que representa una clave pública. Las claves públicas son bastante largas; el propósito del token de clave pública es permitirle referirse a las claves sin decir toda la clave. Algo así como decir "El señor de los anillos" son cinco palabras que representan una novela de medio millón de palabras. Sería bastante inconveniente si cada vez que quisieras hablar sobre ello, tuvieras que decir esas medio millón de palabras.
¿Tiene alguna función para descifrar el hash firmado?
No. El token de clave pública no tiene "información". Es solo un número que representa una clave pública. No es en sí mismo una clave pública.
¿Por qué hay tantas asambleas de Microsoft con el mismo token de clave pública?
Porque todos estaban firmados con la misma clave privada (la clave privada de Microsoft) y, por lo tanto, todos se verifican con la misma clave pública, y por lo tanto todos tienen el mismo token de clave pública.
¿Cuál es el rol del token de clave pública? ¿Tiene alguna función para descifrar el hash firmado? En GAC, ¿por qué hay tantos ensamblados de Microsoft con el mismo token de clave pública ?.
De Wikipedia
"El token de clave pública se utiliza para hacer único el nombre del ensamblado. Por lo tanto, dos ensamblajes con nombre fuerte pueden tener el mismo nombre de archivo PE y, sin embargo, .NET los reconocerá como diferentes ensamblajes. El sistema de archivos de Windows (FAT32 y NTFS) solo reconoce el Nombre de archivo PE, por lo que dos ensamblados con el mismo nombre de archivo PE (pero diferente cultura, versión o token de clave pública) no pueden existir en la misma carpeta de Windows. Para resolver este problema .NET presenta algo llamado GAC (Global Assembly Cache) que es tratado como una sola carpeta por .NET CLR, pero en realidad se implementa utilizando carpetas anidadas NTFS (o FAT32).
Para evitar ataques de suplantación de identidad, donde un cracker intentaría hacer pasar un ensamblaje que aparecía como algo diferente, el ensamblaje se firmó con una clave privada. El desarrollador del ensamblaje previsto mantiene la clave privada en secreto, por lo que un cracker no puede tener acceso a ella ni simplemente adivinarla. Por lo tanto, el cracker no puede hacer que su conjunto se haga pasar por otra cosa, ya que no tiene la posibilidad de firmarlo correctamente después del cambio. Firmar el ensamblado implica tomar un trozo de partes importantes del ensamblaje y luego encriptar el hash con la clave privada. El hash firmado se almacena en el conjunto junto con la clave pública. La clave pública descifrará el hash firmado. Cuando el CLR carga un ensamblado con un nombre fuerte, generará un hash del ensamblaje y luego lo comparará con el hash descifrado. Si la comparación tiene éxito, significa que la clave pública en el archivo (y, por lo tanto, el token de clave pública) está asociada a la clave privada utilizada para firmar el ensamblado. Esto significará que la clave pública en la asamblea es la clave pública del editor de la asamblea y, por lo tanto, se frustra un ataque de suplantación. "
El hash es una especie de "huella dactilar". Se firma utilizando una clave privada de propiedad (y solo conocida) por el firmante. Si conoce la clave pública del firmante, puede verificar si el hash es realmente del firmante y, por lo tanto, si los datos / archivos realmente se originan del firmante (y no se modifican). Las mismas claves públicas para algunos archivos en el GAC significan "todas firmadas por el mismo firmante".
El token de clave pública es un extracto algo legible de la clave pública real. La clave pública completa se almacena dentro de un ensamblaje firmado y se usa para descifrar la firma (= hash cifrado). El cargador lo usa para verificar que los contenidos no estén alterados (o dañados). El hash original fue cifrado por el autor usando una clave privada y solo alguien que posea esa clave puede generar una firma válida.
Cada empresa (o departamento) solo debe usar 1 par de claves, es por eso que ve grupos de PKT idénticos en el GAC.
Me gustaría agregar a las respuestas anteriores (especialmente a la que tiene la cita de Wikipedia) que la fuerte denominación a través de clave pública / privada no lo protege de obtener un ensamblaje modificado o evitar que alguien manipule sus ensamblajes.
En primer lugar , el nombre fuerte no garantiza que se pueda confiar en el ensamblaje. Solo tiene un token de clave pública / clave pública, pero no conoce a la persona que lo firmó (excepto si de algún modo anuncian que poseen la clave pública de los ensamblajes).
Por ejemplo, el pirata informático podría tomar su ensamblaje, quitarle un nombre fuerte (hay herramientas que lo hacen) y firmarlo con su propio nombre seguro. Para la confianza, hay un tipo diferente de firma de código digital con el certificado. Implica que un tercero lo compruebe a usted y a su empresa, y no es gratuito. Mira la tecnología Authenticode:
https://msdn.microsoft.com/en-us/library/ms537359(v=vs.85).aspx
En segundo lugar , en la siguiente discusión se describió brevemente un método de ataque de fuerza bruta para obtener un par de claves público / privado con el mismo token de clave pública que produciría el mismo hash para un ensamblado manipulado:
https://groups.google.com/forum/?hl=en#!topic/microsoft.public.dotnet.security/Jo6PqypxJN8
Debo señalar que esto podría haber sido abordado por la fuerte denominación mejorada https://docs.microsoft.com/en-us/dotnet/framework/app-domains/enhanced-strong-naming
También se mencionó un error en la discusión que permitió omitir la validación del ensamblaje y cargar un ensamblado manipulado en el tiempo de ejecución. La investigación detallada está aquí, el error se corrigió en las versiones posteriores de .Net framework (por lo que el error presente para .Net 1 anterior):
http://www.grimes.nildram.co.uk/workshops/fusionWSCrackThree.htm
En tercer lugar , iniciar .Net 3.5 sp1 para aumentar el rendimiento de la carga de los ensamblados no se valida de forma predeterminada para ensamblajes de plena confianza.
La condición para los ensamblados: https://blogs.msdn.microsoft.com/shawnfa/2008/05/14/strong-name-bypass/
La discusión sobre esto en : ¿Los ensambles .net firmados se verifican completamente cuando se cargan, para verificar que no se hayan modificado?
Según tengo entendido, esto significa que el ensamblaje no es hash durante la carga para verificar si
Por último , me gustaría mencionar que existe un debate sobre los pros y los contras de los nombres fuertes ya que requieren que especifique una versión de ensamblaje. Microsoft elimina el nombre fuerte de algunos de sus productos: https://www.pedrolamas.com/2016/03/01/still-strong-naming-your-assemblies-you-do-know-its-2016-right/
En conclusión , quería resumir todos los puntos mencionados. Cuando me encontré con una fuerte denominación, MSDN y Wikipedia me desaconsejaron de que pudiera proporcionar algún tipo de defensa para los ensamblajes. Pensé "Genial" y el fuerte nombre permaneció en mi memoria como un mecanismo de protección. Hasta el momento tuve que pensar en la seguridad de mi archivo snk con clave privada y luego mi colega me dijo que no es tan "genial". Así que investigué un poco. Lo primero que aprendí fue que el nombre fuerte no significa confianza, debes usar el certificado para ello. Aún así, pensé que si mantengo segura mi clave privada, el ensamble manipulado no será firmado por mí, lo que significa que si alguien modificará mi ensamblaje, entonces él también tendrá que modificar el letrero y el ensamblaje modificado no será cargado por el CLR. Ahora no creo que un nombre fuerte lo garantice. Por lo tanto, debe confiar en él solo para garantizar la singularidad del ensamblaje.
PD. Perdón por la publicación larga con muchas referencias.