HotXLS escribe un bloque dataIntegrity conforme dentro de los paquetes XLSX cifrados con Agile, y lo verifica al abrirlos. El HMAC-SHA-512 cubre el stream EncryptedPackage completo, incluido su prefijo StreamSize de ocho bytes, y se comprueba sobre el texto cifrado antes de descifrar cualquier segmento, de modo que una contraseña incorrecta o un paquete modificado se detecta en lugar de descifrarse en datos ilegibles
Cifrar sin integridad es media respuesta, y los formatos de archivo de Office hacen que ese vacío sea fácil de pasar por alto, porque el cifrado luce muy sólido desde afuera. Entender qué promete cada capa es lo que mantiene corta una revisión de seguridad
¿Qué promete en realidad un libro cifrado?
El cifrado Agile, definido en [MS-OFFCRYPTO], le da confidencialidad mediante AES en modo CBC con una clave derivada de un hash de contraseña SHA-512 iterado. La confidencialidad es toda la promesa de esa construcción. CBC no es un modo autenticado: no dice nada sobre si el texto cifrado que usted está descifrando es el mismo que se escribió
La consecuencia práctica es específica. Invierta bits en un paquete cifrado y CBC los descifrará felizmente en un texto plano distinto. Por lo general obtendrá un error de análisis ZIP en algún punto más adelante, porque un stream deflate corrupto rara vez sobrevive, pero ese "por lo general" carga con mucho trabajo en esa frase, y un error de análisis más adelante es un lugar terrible para enterarse de que un archivo fue modificado. El elemento dataIntegrity existe para responder esa pregunta directamente, antes del descifrado, con un MAC sobre los bytes exactos
Cómo se ejecuta la verificación, y en qué orden
El orden es la parte interesante. HotXLS deriva la clave intermedia a partir de la contraseña, descifra la clave HMAC cifrada y el valor HMAC cifrado desde los atributos de dataIntegrity usando IVs derivados de la clave de bloque, calcula HMAC-SHA-512 sobre el paquete cifrado tal como está almacenado, y compara. Solo entonces comienza el descifrado de segmentos
Verificar el MAC sobre el texto cifrado en lugar del texto plano es la disciplina estándar de cifrar-y-luego-MAC, y es lo que hace significativa la verificación: un paquete manipulado se rechaza sin que ningún byte controlado por un atacante haya pasado por el camino de descifrado e inflado. Ambas comparaciones en la ruta de apertura, el hash verificador de contraseña y el valor HMAC, acumulan diferencias con XOR y OR a lo largo de todo el digest en lugar de retornar temprano ante el primer byte no coincidente, de modo que ninguna filtra la posición de un byte a través de temporización
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
// Funciona con archivos planos, cifrados con Standard y cifrados con Agile
if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
ProcessWorkbook(Book)
else
// Contraseña incorrecta, o un paquete cuyo HMAC de dataIntegrity no coincidió
Quarantine('incoming.xlsx');
except
on E: Exception do
Quarantine('incoming.xlsx: ' + E.Message);
end;
Book.Free;
end;En el lado de la escritura nada cambia en su código. SaveAsEncrypted emite el bloque automáticamente, y las sales, la entrada del verificador y la clave HMAC provienen de CryptGenRandom. Si esa llamada falla, HotXLS genera una excepción en lugar de recaer en una fuente más débil. Un CSPRNG de fallo cerrado no es paranoia; una degradación silenciosa a una fuente aleatoria predecible produce archivos que parecen cifrados, pasan cada prueba funcional, y no valen nada
¿Por qué los archivos sin el bloque igual abren?
Porque una gran cantidad de libros cifrados con Agile en circulación fueron escritos por productores que omiten dataIntegrity por completo, y rechazarlos rompería mucho más trabajo legítimo del que protegería. HotXLS trata la integridad como presente solo cuando ambos atributos, la clave HMAC cifrada y el valor HMAC cifrado, están ahí y bien formados. En caso contrario, la verificación se omite y el archivo abre como antes
Esta es una decisión de compatibilidad con una consecuencia de seguridad que usted debería nombrar explícitamente en su propio modelo de amenazas: la ausencia del bloque no se puede distinguir de un atacante que lo eliminó, porque esos atributos quedan fuera del MAC que llevarían. Si usted controla ambos extremos de un pipeline, trate un bloque faltante como una falla de política a nivel de aplicación. Si está aceptando archivos del mundo exterior, trate la verificación como lo que es, una señal valiosa cuando está presente y ninguna señal en absoluto cuando no lo está
Contraseña para modificar es una convención, no una barrera
Los libros XLS clásicos admiten un mecanismo aparte que se confunde rutinariamente con el cifrado: la reserva de escritura, el aviso de "contraseña para modificar" de Excel. HotXLS la expone mediante SetModifyPassword, que recibe la contraseña, un indicador de recomendar solo lectura y el nombre del usuario que reserva, y reporta el estado a través de IsWriteReserved. Pasar una contraseña vacía elimina la reserva
Lo que se escribe es un par de registros WRITEPROT y FILESHARING que llevan el indicador de recomendar solo lectura, un hash de contraseña heredado de 16 bits y el nombre de usuario como una cadena Unicode BIFF8. Ese hash de 16 bits es una suma de verificación, no un digest criptográfico, y el contenido del documento no está cifrado en absoluto. Cualquiera que abra el archivo con otra herramienta lee todo. El trabajo real de esta función es la coordinación: le dice a la siguiente persona que alguien considera que este archivo es suyo para editar, en la misma categoría que los controles a nivel de hoja cubiertos en protección de hoja y opciones allow en XLSX
var
Book: IXLSWorkbook; // referenciado por interfaz: no llamar a Free
begin
Book := TXLSWorkbook.Create;
if Book.Open('shared-model.xls') = 1 then
begin
// Recomendar solo lectura, reservado por el servicio de reportes
Book.SetModifyPassword('edit-me', True, 'Reporting Service');
if Book.IsWriteReserved then
Book.SaveAs('shared-model.xls', xlExcel97);
end;
end;Use ambas capas para lo que cada una hace bien. La confidencialidad real proviene de SaveAsEncrypted con una contraseña que nadie fuera de la audiencia posee, lo que produce la salida AES-256 descrita en salida XLSX protegida con AES. La reserva de escritura se agrega encima cuando el libro es un artefacto de edición compartida y usted quiere que Excel pregunte antes de que alguien lo sobrescriba
Qué verificar en una ruta de ingesta no confiable
La verificación de integridad protege la carga cifrada, no el contenedor que la rodea. Un archivo XLSX es un archivo ZIP, y la estructura del archivo se analiza antes de que se ejecute cualquier lógica de cifrado, así que la validación a nivel de contenedor pertenece primero en la cadena; los modos de falla específicos se cubren en validación EOCD de ZIP para XLSX no confiables. Después de eso, trate una falla de integridad y una contraseña incorrecta como el mismo evento operativo, porque desde su lado son indistinguibles por diseño, y ambas significan que no se puede confiar en que el archivo sea lo que el remitente cree que es
Registre qué archivos llevaban un bloque dataIntegrity, incluso si no lo tenían. A lo largo de unos cuantos miles de documentos, esa estadística le dice algo útil sobre las herramientas de sus remitentes, y convierte una verificación por archivo en una observación a nivel de flota sobre la que puede actuar
HotXLS lee y escribe XLS, XLSX y ODS desde Delphi y C++Builder sin instalación de Excel, implementando en Pascal las rutas de cifrado Standard y Agile de [MS-OFFCRYPTO]. Las API de cifrado, protección y libro de trabajo están documentadas en la página del componente de hojas de cálculo HotXLS Delphi