#c# #file #storage #checksum
#c# #файл #Хранение #контрольная сумма
Вопрос:
У нас есть веб-служба на основе C #, которая получает документы от политических организаций, которые являются юридически обязательными документами.
В настоящее время мы предоставляем отправителю файла квитанцию, содержащую контрольную сумму полученного файла, чтобы позже мы могли доказать отправителю файла, что файл, хранящийся в нашей системе, соответствует их первоначальной отправке. Квитанция отправляется по электронной почте отправителю файла.
Однако мы не можем доказать стороннему аудитору, что файл и контрольная сумма, хранящиеся в нашей системе, никогда не изменялись (т. е. вредоносный администратор базы данных мог изменить значение контрольной суммы, чтобы оно соответствовало содержимому какого-либо поддельного документа для замены).
В настоящее время я думаю о «файле журнала», доступном только для записи, размещенном где-то в облаке (предположительно, у поставщика, которому сторонний аудитор сочтет достаточно надежным, например, AWS), что мы можем записывать каждый идентификатор файла и контрольную сумму по мере их возникновения. В идеале этот удаленный файл журнала должен вести себя как бухгалтерский журнал старой школы — вы пишете только ручкой, поэтому вы никогда не сможете стереть предыдущую запись!
Другим вариантом может быть отправка этих квитанций по электронной почте стороннему поставщику архивов электронной почты? (объем нашей истории сообщений настолько мал, что это может не стоить разговора с поставщиком архивов)
У кого-нибудь есть предложения?
Комментарии:
1. Похоже, вам нужна криптографическая подпись.
2. » мы предоставляем отправителю файла квитанцию […], чтобы позже мы могли доказать отправителю файла, что файл […] соответствует их первоначальной отправке» — если эта квитанция на самом деле не подписана криптографически вашим опубликованным открытым ключом, этот протокол не работает: либосторона может изменить отправку и подделать соответствующую квитанцию, утверждая, в свою очередь, что квитанция другой стороны подделана.
3. Вы можете получить ответы на security.stackexchange.com тоже, поскольку они специализируются на информационной безопасности..
4. @HannoBinder Вы абсолютно правы. Существующий процесс не является защитой от преднамеренно вредоносного файла. Спасибо, что указали на это.
5. @woliveirajr не знал, что он существует!
Ответ №1:
Самым безопасным решением для обеих сторон было бы заставить ваших клиентов подписывать свои материалы действительным криптографическим сертификатом, чтобы они могли без каких-либо разумных сомнений убедиться, что материалы не были подделаны.
Существуют также способы процедурной подписи и проверки их на C #, это может дать вам представление об этом: http://blogs.msdn.com/b/alejacma/archive/2008/06/25/how-to-sign-and-verify-the-signature-with-net-and-a-certificate-c.aspx?pageIndex=1
Комментарии:
1. После небольшого чтения это определенно кажется правильным путем, но мы никак не можем потребовать, чтобы у файла был свой собственный сертификат — это стало бы «неоправданным бременем» для файла. (Нам не помогает то, что эти филеры — те же люди, которые пишут законы, регулирующие подачу!) Я думаю, что окончательный ответ для нас заключается в найме эксперта по безопасности, как рекомендовано @david.pfx.
2. Обратите внимание, что могут быть особые юридические требования к любому криптографическому протоколу, который должен быть принят властями в качестве доказательства чего-либо. Эти требования обычно включают сертификацию официальными сторонами всех технических и организационных мер, связанных с процессом, на что в большинстве случаев пойдут только специализированные компании, чтобы иметь возможность предлагать свое криптографическое решение в качестве продукта, поскольку оно сопряжено с большими затратами и усилиями. Так что, если вы ищете что-то (несколько) серьезное, вероятно, нет способа обойтись без профессиональной внешней поддержки.
Ответ №2:
Хорошей новостью является то, что эта проблема (и может понравиться) может быть решена с помощью криптографии с открытым ключом. Плохая новость заключается в том, что разработка протокола — это работа для экспертов. В прошлый раз, когда у меня была такая проблема, я попросил парня по имени Брюс Шнайер помочь, но вокруг полно других экспертов.
По сути, то, что вы делаете, примерно так. Сначала вы готовите crytographic digest документа. Это своего рода контрольная сумма, но она гарантированно уникальна и не поддается взлому. Никто не может создать другой документ с тем же дайджестом.
Затем вы и файлер, каждый, шифруете этот дайджест своим собственным открытым ключом и обмениваетесь зашифрованными ключами (и, конечно, сохраняете исходный дайджест в файле). Если возникает проблема, вы создаете зашифрованный дайджест файла и требуете, чтобы он расшифровал его, используя свой закрытый ключ. Если он расшифровывается правильно и соответствует дайджесту, который у вас есть в файле, тогда он правильный и не может быть отменен. Он может сделать то же самое с вами.
Сертификат — это просто особый вид открытого ключа, для которого существуют различные инструменты. Вы можете использовать сертификат или просто ключи и набор инструментов, таких как PGP.
Это очень упрощенная версия. Существуют гораздо более сложные системы, но я думаю, что это будет стоить вам денег, чтобы заставить один работать.
Комментарии:
1. Спасибо, это действительно помогает мне визуализировать, как может быть построен процесс. Конечно, это также показывает мне, как мало я знаю! Безусловно, потребуется внешний эксперт.