DeathAndTaxes: Lets закрутить идеи и улучшить ее тогда.

Мы могли бы зашифрованы хранения за пределами HSM таким образом:
Все счета хранятся вне HSM, но шифруется с помощью ключа ТОЛЬКО HSM знает. Назовём этот зашифрованный фрагмент данных для "капля", Эта "капля" сохраняется в строке пользователя в базе данных сайта.

Тогда каждый раз, когда нужен счету, который будет использоваться, его кормили в HSM и HSM обновляет учетную запись и возвращает зашифрованные блобы счета.

НО нам нужно каким-то образом проверить мы не используем "старый" зашифрованная блоб с "старый" баланс. У меня идея: Пусть каждый счет есть п-разрядный идентификатор. Каждый зашифрованный двоичный объект содержит идентификатор и небольшое случайное значение.
Случайное значение хранится внутри зашифрованного сгустка вместе с идентификатором.

Каждый раз, когда что-либо в зашифрованном сгустке обновляется, новый зашифрованный блоб будет иметь новое случайное значение. (Но тот же идентификатор).
ИМП не будет принимать зашифрованный двоичный объект, содержащий удаление информации случайное значение.

Пользователя закрытые ключи и такие могут быть сохранены в этой кляксы тоже.

Случайное значение и идентификатор хранятся во внутренней памяти HSM. Допустим, 14 битный идентификатор и 18 битный Random.
14 бит ID будет приходиться 16384 пользователей.
Каждый пользователь будет "израсходовать" 4 байта
Это будет в общей сложности 64 КБ встроенной флэш-памяти используется.

И вам потребуется 262 144 транзакций на одном USER перед тем случайными числами начинают повторяться. И это только позволило бы злоумышленнику дублировать баланс РАЗ. Простая перезарядка между каждой командой отправляется в HSM с возможностью сказать 1-2 секунды замедлит нападавшего значительно.
Дублирование баланса потребует этого от злоумышленника: Отправить небольшую транзакцию с использованием blob1. Получение blob2 от HSM. Отправить blobOLD и посмотреть, если HSM принять его. Отправить небольшую транзакцию с использованием blob2. Получение blob3 от HSM. Отправить blobOLD и посмотреть, если принять. Отправить транзакцию с использованием blob3 и получить blobN от HSM и так далее и так далее.

Перезарядка 2 секунды между каждой командой потребуется 6 дней работы от злоумышленника до того, как злоумышленник может добиться успеха, и до 6 дней, атака будет Guranteed заметила.



>>"Если мы предположим, что злоумышленник имеет полный контроль над хозяином они могли бы просто записать поддельный депозит, а затем запросить вывод."
Неа.
HSM должен, конечно, требует, чтобы кормить его действительные блоки. Вы кормите его блоками, как только вы найдете его в сети Bitcoin, и устройство сохраняет 6 блоков по хешу "вспышка" и сохраняет весь последний блок в оперативной памяти во время обновления баланса. После того, как хозяин показал его сделали с подачей сгустками, блок будет удален из памяти.

Хозяин должен был бы отслеживать, какие пользователи скормить ОЗМ для обновления баланса, когда он получает блок оплаты для одного из нее АДРЕСА пользователя.
Таким образом, для того, чтобы ПОВЫШЕНИЯ баланса, ему потребуется злоумышленник фактически depoist денег на счет пользователя.

Таким образом, хозяин делает это, когда он видит блок оплачиваемого позволяет говорить BitCoinUSER на Bitcoinia:
Хост посылает блок в HSM. HSM обрабатывает блок, и теперь он ожидает блобо для обновления.
Хозяин в настоящее время отвечает сгусток, соответствующей BitCoinUSER.
HSM расшифровывает блоб, увеличивает баланс и случайное значение, reencrypts его, вернуться к хозяину.
хост сохраняет этот новый блоб в строке базы данных для BitCoinUSER.

Хост может указывать на HSM, если хост имеет больше сгустков кормить, например, если транзакция имеет несколько выходов, указывающих на одного пользователя каждого.
Или если блок не имеет никакого отношения к рассматриваемому участку, хозяин может указывать как "0 сгустки кормить",


Таким образом, зашифрованные блобо (ТОЛЬКО дешифровать с помощью HSM) будет содержать:
Имя пользователя - пароль Хэшировано - Баланс - Получение адреса - UserPrivate Key - Идентификатор_пользователя - случайный Nonce

И база данных хоста будет содержать:
Имя пользователя - пароль Хэшировано - Баланс - Получение адреса - (некоторые другие детали) - Последние зашифрованное блоб из HSM.

Обратите внимание, что база данных хоста теперь содержит имя пользователя, hashedpassword, баланс, ПРИЕМ Адрес 2 раза, один в незашифрованном формате и один в зашифрованном формате. Открытый текст формат поэтому сайт может самому проверить баланс и другие детали, прежде чем беспокоить HSM. Конечно открытый текст значение не передаются HSM и не влияет на HSM в любом случае.

Depoist из, например, USD -> BTC затем требует ручного вмешательства оператора сайта.
Но BTC -> USD затем будет прямым.
Это также встраивать с политикой сайта, так как сайт будет хотеть проверить USD depoist действительно трудно перед отправкой биткойны, поскольку USD depoist может быть chargebacked.


RJK: Конечно блоки подаются через последовательный порт, а не через Интернет.



ПРИОРИТЕТ IDEA:
Вы говорите о ключе 128bit / 256bit. Не нужно вообще.
Просто есть momentarly кнопки на HSM. Эта кнопка должна удерживаться вниз при загрузке нового "правила" или переопределения правил.
Злоумышленник, "Косоглазый" сервер в Интернете не может достичь физической кнопки и не может обойти HSM.


Но проблема с "правила" является то, что пользователь, владеющий счет 1000 BTC не может быть в состоянии в полной мере использовать свой счет без сайта оператора, имеющего для подтверждения операции.
Нам нужен способ для хранения / процесс indivual пользователей в системе, в некотором роде, так что пользователь, владеющий 1 BTC будет только в состоянии отправить 1 BTC, пользователь, владеющий 1000 BTC будет только в состоянии отправить 1000 BTC.