Существуют ли веские причины для использования устройства аппаратного шифрования (например,USB-ключ шифрования/хранилище ключей) вместо использования библиотеки п
https://stackoverflow.com/questions/1200319
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Если вашему приложению необходимо шифровать/дешифровать данные (по разным причинам), есть ли причины, по которым вам следует использовать аппаратное устройство (например,USB-устройство шифрования — например, Marx CryptoBox) вместо использования библиотеки программного шифрования (например, .net Cryptography или написания собственной) и хранить свои ключи в безопасном хранилище ключей?
Я ищу объективные мнения по этому вопросу.
Чтобы сузить поставленный вопрос: Каково было бы ваше мнение, если бы система, использующая USB-ключ шифрования, находилась в физически защищенном серверном хранилище и существовала только одна система (т.это не программный продукт, который распространяется и запускается на многих настольных компьютерах)?Проще говоря, цель описанной выше системы — проверить (расшифровать и сравнить) часть входящих зашифрованных данных.
Спасибо за ваши отличные ответы!
Решение
Речь идет не о том, что безопаснее, потому что нет ничего стопроцентно пуленепробиваемого.Вопрос в том, «как сделать это как можно сложнее».
Вы могли видеть это с этой точки:Если вы храните ключи на компьютере, они будут там круглосуточно и без выходных.Если моя пара ключей находится на внешнем устройстве, ключи доступны только при подключении к устройству.==> Вы сокращаете время, в течение которого кто-то другой может скопировать ваши ключи.Гораздо проще получить доступ к чему-либо, если физический доступ не требуется.
Подумайте об онлайн-банкинге:Многие банки добавили «внешние» способы аутентификации, такие как Tan/Tac/tanSMS/генераторы токенов и т. д.и т. д.Ни один из них не является безопасным сам по себе:Я могу украсть ваш пароль для входа, я могу украсть ваш мобильный телефон, я могу украсть ваш список Tac/Tan и так далее.Но вероятность того, что я смогу украсть все необходимые элементы сразу, очень мала => Все части головоломки вместе создают вполне безопасное решение.
Также подумайте об этих факторах:
- деньги:Действительно ли вам нужна защита на основе токенов стоимостью 70 долларов для вашего приложения за 100 долларов?
- время:Я бы сказал, что программные системы быстрее.
- актуальность:Имеет ли смысл обеспечивать мои приложения такой сложной системой защиты?
Другие советы
Аппаратный ключ позволяет ограничить использование программного обеспечения машиной, к которой подключен ключ.
При программном шифровании было бы проще скопировать программное обеспечение на множество компьютеров и запускать его много раз параллельно.
Да это так.
Во-первых, это позволяет вам передавать закрытые ключи физически по защищенным каналам, а не доверять сети.
С другой стороны, если вам приходится перемещаться между множеством систем, которые не обязательно подключены к сети, USB-ключ намного удобнее.Именно поэтому военные используют очень похожую систему(ЭКМС).Они не используют USB, но используют маленькие переходники, похожие на большие пластиковые ключи.Идея та же, но USB еще не существовало в начале 90-х, когда они это разрабатывали.
(примечание:Немного пугает, насколько полной является эта статья в Википедии.Когда я работал над КП, мне сказали, что нам разрешено использовать такие аббревиатуры, как СВЕТЛЯК в наших резюме, но нам не разрешалось никому говорить, что они означают.)
Я думаю, это зависит от цели/использования вашего приложения.Если вы разрабатываете продукт для нужд с высоким уровнем безопасности, например, в банковских или государственных учреждениях, аппаратное дополнение к вашему решению может быть вполне уместным.Вы должны учитывать дополнительные затраты, которые аппаратное решение может добавить к проекту.Не только на первоначальной разработке, но и на текущих затратах на обслуживание оборудования, которые потребуются после завершения разработки.С моей точки зрения, поскольку в прошлом я работал в банковской сфере, было очень и очень мало решений, в которых мы чувствовали, что аппаратное решение стоит дополнительных затрат, которые оно повлечет за собой.
