O HotXLS escreve um bloco dataIntegrity conforme em pacotes XLSX com encriptação Agile e verifica-o na abertura. O HMAC-SHA-512 cobre todo o fluxo EncryptedPackage, incluindo o seu prefixo StreamSize de oito bytes, e é verificado sobre o texto cifrado antes de qualquer segmento ser desencriptado, pelo que uma palavra-passe errada ou um pacote modificado é detetado em vez de desencriptado para dados sem sentido
Encriptação sem integridade é apenas meia resposta, e os formatos de ficheiro do Office tornam essa lacuna fácil de ignorar porque a encriptação parece tão sólida vista de fora. Compreender o que cada camada promete é o que mantém uma revisão de segurança breve
O que promete efetivamente uma pasta de trabalho encriptada?
A encriptação Agile, definida em [MS-OFFCRYPTO], garante confidencialidade através de AES em modo CBC, com uma chave derivada de um hash de palavra-passe SHA-512 iterado. A confidencialidade é toda a promessa dessa construção. O CBC não é um modo autenticado: nada diz sobre se o texto cifrado que está a desencriptar é o texto cifrado que foi originalmente escrito
A consequência prática é específica. Inverta bits num pacote encriptado e o CBC desencifra-os alegremente para um texto simples diferente. Normalmente obterá um erro de análise ZIP algures a jusante, porque um fluxo deflate corrompido raramente sobrevive, mas o "normalmente" está a fazer muito trabalho nessa frase, e um erro de análise a jusante é um péssimo local para descobrir que um ficheiro foi modificado. O elemento dataIntegrity existe para responder diretamente a essa pergunta, antes da desencriptação, com um MAC sobre os bytes exatos
Como decorre a verificação, e por que ordem
A ordem é a parte interessante. O HotXLS deriva a chave intermédia a partir da palavra-passe, desencripta a chave HMAC e o valor HMAC encriptados a partir dos atributos dataIntegrity usando IVs derivados por bloco de chave, calcula o HMAC-SHA-512 sobre o pacote encriptado tal como está armazenado, e compara. Só depois começa a desencriptação de segmentos
Verificar o MAC sobre o texto cifrado em vez do texto simples é a disciplina padrão de encriptar-depois-autenticar, e é o que torna a verificação significativa: um pacote adulterado é rejeitado sem que qualquer byte controlado por um atacante tenha passado pelo caminho de desencriptação e de inflação. Ambas as comparações no caminho de abertura, o hash verificador da palavra-passe e o valor HMAC, acumulam diferenças com XOR e OR ao longo de todo o resumo em vez de regressarem antecipadamente ao primeiro byte não coincidente, pelo que nenhuma delas revela a posição de um byte através da temporização
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
// Funciona para ficheiros simples, encriptados em Standard e encriptados em Agile
if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
ProcessWorkbook(Book)
else
// Palavra-passe errada, ou um pacote cujo HMAC dataIntegrity não coincidiu
Quarantine('incoming.xlsx');
except
on E: Exception do
Quarantine('incoming.xlsx: ' + E.Message);
end;
Book.Free;
end;No lado da escrita, nada muda no seu código. SaveAsEncrypted emite o bloco automaticamente, e os sais, a entrada verificadora e a chave HMAC provêm de CryptGenRandom. Se essa chamada falhar, o HotXLS gera uma exceção em vez de recuar para uma origem mais fraca. Um CSPRNG que falha de forma fechada não é paranoia; um recuo silencioso para uma origem aleatória previsível produz ficheiros que parecem encriptados, passam todos os testes funcionais e não valem nada
Porque abrem os ficheiros sem o bloco?
Porque muitas pastas de trabalho com encriptação Agile em circulação foram escritas por produtores que omitem dataIntegrity por completo, e rejeitá-las quebraria muito mais trabalho legítimo do que protegeria. O HotXLS trata a integridade como presente apenas quando ambos os atributos, a chave HMAC encriptada e o valor HMAC encriptado, estão presentes e bem formados. Caso contrário, a verificação é ignorada e o ficheiro abre como antes
Esta é uma decisão de compatibilidade com uma consequência de segurança que deve nomear explicitamente no seu próprio modelo de ameaça: a ausência do bloco não pode ser distinguida de um atacante que o removeu, porque os atributos estão fora do MAC que os deveria transportar. Se controla ambas as extremidades de um pipeline, trate um bloco em falta como uma falha de política ao nível da aplicação. Se está a receber ficheiros vindos do exterior, trate a verificação pelo que é, um sinal valioso quando presente e nenhum sinal quando ausente
Palavra-passe para modificar é uma convenção, não uma fronteira
As pastas de trabalho XLS clássicas suportam um mecanismo separado que é frequentemente confundido com encriptação: a reserva de escrita, o pedido do Excel "palavra-passe para modificar". O HotXLS expõe-a através de SetModifyPassword, que recebe a palavra-passe, uma flag de recomendação de apenas leitura e o nome do utilizador reservante, e reporta o estado através de IsWriteReserved. Passar uma palavra-passe vazia limpa a reserva
O que é escrito é um par de registos WRITEPROT e FILESHARING que transportam a flag de recomendação de apenas leitura, um hash de palavra-passe de 16 bits legado e o nome do utilizador como uma string Unicode BIFF8. Esse hash de 16 bits é uma soma de verificação, não um resumo criptográfico, e o conteúdo do documento não é encriptado de forma alguma. Quem abrir o ficheiro com qualquer outra ferramenta lê tudo. A verdadeira função desta funcionalidade é a coordenação: diz à pessoa seguinte que alguém considera esse ficheiro seu para editar, na mesma categoria dos controlos ao nível da folha abordados em proteção de folha XLSX e opções allow
var
Book: IXLSWorkbook; // contado por interface: não use Free
begin
Book := TXLSWorkbook.Create;
if Book.Open('shared-model.xls') = 1 then
begin
// Recomendar apenas leitura, reservado pelo serviço de relatórios
Book.SetModifyPassword('edit-me', True, 'Reporting Service');
if Book.IsWriteReserved then
Book.SaveAs('shared-model.xls', xlExcel97);
end;
end;Utilize cada camada para aquilo em que é boa. A confidencialidade real vem de SaveAsEncrypted com uma palavra-passe que ninguém fora do público-alvo possui, o que produz a saída AES-256 descrita em saída XLSX protegida por AES. A reserva de escrita acrescenta-se por cima quando a pasta de trabalho é um artefacto de edição partilhada e se quer que o Excel pergunte antes de alguém a gravar por cima
O que verificar numa via de admissão não fiável
A verificação de integridade protege o conteúdo encriptado, não o contentor à sua volta. Um ficheiro XLSX é um arquivo ZIP, e a estrutura do arquivo é analisada antes de qualquer lógica de encriptação ser executada, pelo que a validação ao nível do contentor tem de vir primeiro na cadeia; os modos de falha específicos são abordados em validação do fim do diretório central ZIP para XLSX não fiáveis. Depois disso, trate uma falha de integridade e uma palavra-passe errada como o mesmo evento operacional, porque do seu lado são indistinguíveis por conceção, e ambas significam que o ficheiro não pode ser confiado como sendo aquilo que o remetente pensa que é
Registe quais ficheiros transportavam um bloco dataIntegrity de todo. Ao longo de alguns milhares de documentos, essa estatística diz-lhe algo útil sobre as ferramentas dos seus remetentes, e transforma uma verificação por ficheiro numa observação ao nível do conjunto sobre a qual pode agir
O HotXLS lê e escreve XLS, XLSX e ODS a partir do Delphi e do C++Builder sem qualquer instalação do Excel, implementando em Pascal os caminhos de encriptação Standard e Agile de [MS-OFFCRYPTO]. As APIs de encriptação, proteção e pasta de trabalho estão documentadas na página do componente HotXLS para Delphi