id: Гость   вход   регистрация
текущее время 02:34 20/04/2024
Автор темы: Гость, тема открыта 28/01/2014 18:46 Печать
Категории: криптография, криптоанализ, атаки
http://www.pgpru.com/Форум/ПрактическаяБезопасность/ЭлектронныйНосительИнформации
создать
просмотр
ссылки

Электронный носитель информации


Добрый вечер. Возник следующий вопрос. Возможно ли на практике реализовать носитель информации, реализованный в виде флешки со следующими свойствами:

  1. на носитель информации изначально записывается значение некоторй переменной счетчика равное нулю и какая-то другая информация.
  2. при каждом считывании информации с носителя значение счетчика увеличивается на единицу.
  3. при попытке изменить значение счетчика или сделать так, чтобы это значение не увеличивалось на единицу, вся информация уничтожается.

 
Комментарии
— Гость (28/01/2014 20:18)   <#>
А для чего вам это? Может быть, задача проще решается? Потенциально такое сделать, думаю, можно, но счётчик будет корректно увеличиваться только если пользователь будет передавать на носитель некоторый секретный правильный пароль или значение функции, зависящее от этого пароля.

Уничтожение информации возможно тремя способами:

  1. Хранение её в квантовых состояниях в хрупком виде. Уничтожение обеспечивается физическими свойствами таких состояний, в народе широко известными как «коллапс волновой функции». Это технологически дорого, тяжело, но потенциально, в перспективе, даёт удобство, независимость от подключения к какой-либо сети и очень высокий уровень безопасности. Правда, это всё равно требует разработки специального протокола под задачу и доказательства его безопасности (и это помимо собственно технологических трудностей создания такого прибора).
  2. Хранение информации на нодах анонимной сети, где считается, что вашему атакующему не всех из этих нод подконтрольны. Сами ноды управляются добровольцами-волонтёрами, которые тупо следуют протоколу, не зная вас лично. Вы все друг перед другом анонимны. Задача требует создания нетривиального криптографического протокола и доказательства его безопасности с последующим его развёртыванием и раскруткой. Плюс этого решения в том, что никакой носительно информации не требуется, всё реализовано программно; минус — в том, что требуется подключение к сети. К тому же есть риск потери информации, если много нод внезапно уйдёт в оффлайн.
  3. HSMомопдобная железяка. Уничтожение информации основано на сложности и запутывании, ограничениии по числу образцов, ограничении на число продаж каждой копии, или на уникальности каждой копии. Никакого формального обоснования того, что информация будет уничтожена нет, т.к. безопасность построена на незнании противником устройства и его обфускации.

Других способов надёжного уничтожения информации, за которой охотится очень сильный противник, мне неизвестно. Способ 2 иногда дорабатывают в народе до «на проводе в неизвестном месте сидит стражник, который включает систему по звонку». Это накладно организационно и не очень надёжно, но используется, особенно во всяких коммерческих системах безопасности.
— ressa (28/01/2014 22:01)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59
А есть ли готовые реализаци для хранения инфы именно на нодах или может в нескольких облаках?
— Гость (29/01/2014 07:28)   <#>
Нет, но скоро будут. По крайней мере, лично мне ни о чём таком неизвестно. Если покажете хотя бы одну работу по протоколу для работы такой (или хотя бы подобной) сети, я вам буду премного благодарен. Одно из самых нетривиальных требований — добиться того, чтобы атакующий, имеющий ноды в такой сети и хранящий кусок вашего секрета (ключа), не понимал, уничтожаете вы его или нет.
— Гость (27/02/2014 18:32)   <#>
Новость в тему:

With* respect to the Block Diagram, Schematics, Internal Photos, Parts List/Tune Up Information, and Boeing Black Purchase Agreement, pursuant to guidance issued by your office, such materials may be treated as confidential on a permanent basis if "the device is sealed and disassembly would destroy the product." 10 There are no serviceable parts on Boeing's Black phone and any attempted servicing or replacing of parts would destroy the product. The Boeing Black phone is manufactured as a sealed device both with epoxy around the casing and with screws, the heads of which are covered with tamper proof covering to identify attempted disassembly. Any attempt to break open the casing of the device would trigger functions that would delete the data and software contained within the device and make the device inoperable. // Стр. 3

В более доступной форме о том же: [1], [2], [3]. Интересно, есть ли обзор по всем попыткам создания разных приборы с «самоуничтожением»...

*См. ссылку «Request for Confidentiality». Прямая ссылка не сработает из-за завязки на referer.
— Гость (27/02/2014 18:49)   <#>

В вики на картинке изображён HSM производства компании Thales, которая занималась (продолжает заниматься?) QKD. В частности, именно от них выделилась в своё время SeQureNet. Вроде до сих пор какая-то связь прослеживается (по ссылке):

2011: SeQureNet and Thales announce partnership on quantum cryptography
— Гость (27/02/2014 19:35)   <#>
Интересно, что в требованиях fileFIPS 140-2 есть даже условия на уничтожение ключей в HSM'ах, которое называется обнулением (zeroization):

7.6 Key Zeroization

AS07.41: (Levels 1, 2, 3, and 4) The cryptographic module shall provide methods to zeroize all plaintext secret and private cryptographic keys and CSPs within the module.

Required Vendor Information

VE07.41.01: The vendor documentation shall specify the following plaintext secret and private cryptographic keys and CSPs zeroization information:

  1. Zeroization techniques
  2. Restrictions when plaintext secret and private cryptographic keys and CSPs can be zeroized
  3. Plaintext secret and private cryptographic keys and CSPs that are zeroized
  4. Plaintext secret and private cryptographic keys and CSPs that are not zeroized and rationale
  5. Rationale explaining how the zeroization technique is performed in a time that is not sufficient to compromise plaintext secret and prvate keys and CSPs

Required Test Procedures

TE07.41.01: The tester shall review the vendor documentation to verify that the information specified in VE07.41.01 is included. The tester shall determine the accuracy of any rationale provided by the vendor. The burden of proof is on the vendor; if there is any uncertainty or ambiguity, the tester shall require the vendor to produce additional information as needed.

TE07.41.02: The tester shall note which keys are present in the module and initiate the zeroize command. Following the completion of the zeroize command, the tester shall attempt to perform cryptographic operations using each of the plaintext secret and private cryptographic keys and CSPs that were stored in the module. The tester shall verify that each plaintext secret and private cryptographic keys and CSPs cannot be accessed.

TE07.41.03: The tester shall initiate zeroization and verify the key destruction method is performed in a time that is not sufficient to compromise plaintext secret and private keys and other unprotected CSPs.

TE07.41.04: The tester shall verify that all plaintext secret and private cryptographic keys and CSPs that are not zeroized by the zeroize command are either 1) encrypted using an Approved algorithm, or 2) physically or logically protected within an embedded validated cryptographic module (validated as conforming to this standard).

AS07.42: (Levels 1, 2, 3, and 4) Documentation shall specify the key zeroization methods employed by a cryptographic module. Note: This assertion is tested under AS07.41. // Стр. 78

И ещё fileтут есть о том же:

4.7.6 Key Zeroization

A cryptographic module shall provide methods to zeroize all plaintext secret and private cryptographic keys and CSPs within the module. Zeroization of encrypted cryptographic keys and CSPs or keys otherwise physically or logically protected within an additional embedded validated module (meeting the requirements of this standard) is not required. Documentation shall specify the key zeroization methods employed by a cryptographic module. // Стр. 33

Статус FIPS 140-3 так и не понял, вроде он до сих пор в стадии драфта.
— K10 (02/03/2014 23:48)   <#>
А в чем проблема сделать флешку на микроконтроллере с нужной логикой?
Будет считать количество включений у себя в флеш-памяти и в случае чего стирать информацию.
— Гость (03/03/2014 02:11)   <#>

Детская наивность. Кто сказал, что противник будет пользоваться стандартными интерфейсами? Заряд в конденсаторах может быть измерен лабораторными методами без внесения существенных возмущений. Короче, эта теорема в классической физике не выполняется: потенциально всё можно скопировать и склонировать.
— K10 (03/03/2014 13:30)   <#>
Гость
Это фантастика)
— Гость (04/03/2014 11:57)   <#>
дык https://tahoe-lafs.org/trac/tahoe-lafs же. Там правда забывание производится по таймеру, но допилить же ж можно и под себя.
— Гость (04/03/2014 19:14)   <#>

Люди работают, чтобы разнообразную фантастику сделать былью. Безопасно — это не тогда, когда ещё нет технологий, или ещё никто не продемонстрировал, а безопасно — это когда доказано, что таких технологий появиться не может (в рамках заранее оговоренных и осмысленных ограничений).


Что делать, если владельцы распределённого хранилища — ваш противник, который ничего не удаляет? Вот сговорятся все хостеры между собой под нажимом АНБ и не будут удалять, что тогда? Если АНБ может надавить на 7 из 10 хостеров, будет ли это работать? Есть ли доказательство безопасности? Это первые вопросы, которые возникают.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3