Es una herramienta que se usa para verificar la integridad de los datos que se transmiten entre el origen (quien firma) y el destinatario (quien verifica). Los certificados o firmas digitales son creadas y verificadas utilizando criptografía de llave pública. Quien firma posee una un par de llaves criptográficas: una llave publica, que es usada para verificar que el firmante conoce la clave privada y el mensaje.
En algunos casos (como el que estamos viendo aquí), con ayuda de más infraestructura, podemos usar los certificados para saber y corroborar el nombre del que firma los mensajes, y asegurarnos además que el mensaje no ha sido alterado luego de que el firmante creara la firma para ese mensaje. Entre todos los mecanismos que existen para implementar las firmas digitales, Microsoft .NET utiliza para sus Strong Name el algoritmo RSA de clave publica y el algoritmo hash SHA-1.
Hay certificados de prueba y hay certificados reales firmados por autoridades de certificación (CAs) como por ejemplo Verisign. También se puede crear un certificado de prueba y luego hacerlo firmar por un CA.
2. ¿Qué es un Strong Name?
Es un mecanismo de Microsoft .Net para darle a nuestros assemblies una identidad única. La identidad está compuesta por:
* una clave pública (RSA)
* un nombre (texto del nombre del archivo - sin extensión - que contiene el assembly)
* versión (compuesta por cuatro partes: Major.Minor.Build.Revision. Ej: 10.0.0.1)
* certificado digital (contiene la clave privada)
* cultura (opcional)
* arquitectura del procesador (opcional)
Para obtener un Strong Name válido, nuestro assembly es firmado (strong-name signed) durante el proceso de build usando la clave privada que corresponde a la clave publica en el Strong Name. De esta forma la firma Strong Name puede ser verificada con la clave pública. Hay varias técnicas distintas para crear una firma Strong Name y para manejar la clave privada durante el firmado que explicaré más adelante.
Cuando un assembly hace referencia a un strong-named assembly, captura la información del strong name del assembly referenciado. Cuando el framework de .net intenta cargar un strong-named assembly, verifica la firma strong-name, si no lo puede hacer, entonces directamente no lo carga.
Una excepción a este proceso se da con strong-named assemblies que están en el Global Assembly Caché (GAC). Estos assemblies no son verificados cada vez que .Net los carga porque ya fueron verificados cuando se instalaron en el GAC. El GAC es un repositorio restringido con solo acceso a Administradores, con lo cual si ya fueron ingresados se entiende que ya es suficiente con haberlos validado en ese momento.
3. ¿Cuando deberíamos firmar con Strong Name keys nuestros assemblies?
Cuando necesitemos que nuestros componentes (dlls) tengan una identidad única (que nadie los pueda falsificar) y garantizar que nuestras dependencias se mapean correctamente con las versiones correctas.
El tema de falsificar la identidad del assembly tiene que ver con que alguien obtenga la clave privada (que deberíamos mantener.. privada!) y firme cualquier otro assembly o el mismo modificado con nuestra strong-name key y se haga pasar por nosotros. Tener un strong-name nos permite tomar ciertas decisiones respecto a seguridad como confiar en todos los assemblies firmados con nuestro strong-name dentro de nuestra intranet. Digo intranet porque una firma strong-name no nos asegura nada respecto del que firma (publisher), con lo cual no podriamos confiar en un strong-name de un assembly externo o de internet (salvo que tengamos un canal seguro desde donde obtener la clave pública de ese assembly, o sea, un CA!).
Típicamente firmamos DLLs, no EXEs. Firmar un EXE implica que no podrá referenciar DLLs que no esten firmadas con strong-name, y esto complica las cosas. En vez de esto se firman los manifiestos del EXE que apuntan a las DLLs que no están firmadas. Lo mismo sucede con DLLs firmadas con strong-name que referencian a otras DLLs que no están firmadas (ya sea nuestras o peor, de terceros), esto es un problema porque sí o sí todas las DLLs deberán estar firmadas con strong-name, sino no compilará nuestro proyecto.
Por otro lado tener los assemblies firmados complica el deployment. Por ejemplo si necesitamos hacer un bug fix en uno de nuestros assemblies, incrementando el numero de versión para ese assembly, provocará que la aplicación luego no encuentre el assembly (buscará el anterior). Para solucionar esto deberemos compilar la solución completa para ese assembly, peor aún si es un assembly compartido entre varias aplicaciones. Una alternativa en el caso que el assembly esté en el GAC sería usar las publisher policy para redirecionar el cargado de la version 1.0.0.0 a la version 1.0.0.1 (la del bug fix), pero esto sería complicar aún más las cosas. Finalmente podríamos no cambiar el numero de versión y la aplicación encontraría el assembly.
Como ven, firmar con strong-name añade complejidades y deberíamos evitar firmar con strong-name nuestros assemblies salvo que vayan a ser instalados en el Global Assembly Cache (GAC) o salvo que vayan a ser recursos compartidos (DLL) de otras aplicaciones. Firmarlos porque sí solo agrega más esfuerzo y problemas.
Para más detalle ver: Strong-Name Signing for Managed Applications.
http://msdn.microsoft.com/en-us/library/xwb8f617(v=vs.110).aspx#bypassing_signature_verification
4. ¿Qué es un certificado .pfx?
Significa Personal Information Exchange y es una strong name key (.snk) protegida por contraseña.
5. ¿Cuando deberíamos firmar los manifiestos de ClickOnce?
En ClickOnce, debemos firmar obligatoriamente los manifiestos. Esto se hace utilizando un archivo .pfx o un certificado de nuestro personal certificate store.
Si usamos el archivo .pfx debermos ingresar la contraseña del mismo para que pueda ser importado al personal certificate store.
6. ¿Como se firman las librerías y manifiestos de ClickOnce de nuestros proyectos a través de Visual Studio?
En las propiedades del proyecto que queremos firmar, si vamos a la solapa "Signing" encontraremos la página de configuración para firmar el proyecto. Ésta tiene dos secciones: Sign the ClickOnce manifests y Sign the assembly.
Referencias:
- Using Strong Name Signatures: http://msdn.microsoft.com/en-us/magazine/cc163583.aspx#S8
- http://msdn.microsoft.com/es-ar/library/aa730868(v=vs.80).aspx
No hay comentarios:
Publicar un comentario