Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 59
Скорость работы: с открытым разделом накопителя — до 3,2 Мбит/с, с закрытым разделом накопителя до 1,2 Мбит/с.
Это же меньше, чем те 12Мбит/с пропускной способности, которые есть почти во всех современных микроконтроллерах с USB. Как у вас получилось сделать так плохо с учётом того, что ГОСТ у вас параллелится?
Ничего не нашёл про используемый режим шифрования. В каком режиме используется ГОСТ 28147-89?
Такая скорость из-за периферийного USB 1.1, в то время мы не могли позволить себе строить устройство на базе только что появившегося на свет Multiclet R1.
Режим шифрования-гаммирование с обратной связью.
Режим шифрования-гаммирование с обратной связью.
Хочу дополнить по этому вопросу, что несмотря на пропускную способность необходимо учесть что данные проходят ещё процедуру шифрования(которая конечно занимает немного времени) плюс данные передаются между процессорами вместе с их контролем и ещё данные нужно записать на флешку или SD карту. В контроллерах есть USB, но вот, чтобы был хост, а не девайс, то это не везде.
Можно ли задавать свои 256 битные ключи и расшифровывать программно для проверки алгоритма?
В текущей версии прошивки эта функция недоступна.
Планируется ли эта функция в следующих версиях?
Это ведь наверняка реализовать проще, чем огород с пинами и синхронизациями.
Это ведь наверняка реализовать проще, чем огород с пинами и синхронизациями.
Да реализовать это можно в следующих версиях прошивки. А какой объём ключей вы считаете достаточным для такой функции?
Хотябы один.
Как реализуем данную функцию отпишусь в данной теме.
Можно сказать, что реализовали). Точнее уже это было реализовано, я совсем забыл, что в корпоративных ключах можно задать свой ключ, т.е. можно 512 таких ключиков задать, если поправить файл внешней базы корпоративных ключей. Хотя можем сделать и дополнительный функционал, когда пользователь смог бы задать прямо из приложения Key_P1 Менеджер свой ключ в 256 бит.
1) Что еще за «сохранить ключи в файл»? Ключи не эксклюзивно хранятся в устройстве?!
2) Чем гарантируется неизвлечение уже хранящихся ключей из устройства?
3) Проводили ли Fuzz-тестирование как на уровне USB так и API?
4) Восстановимы ли данные с носителя информации после извлечения ключей?
5) Читаем ли скрытый раздел после использования открытой части носителя без использования Ключ_П1?
6) Что предприняли для защиты от кражи паролей из устройства программными средствами? (то есть пользователь ввел пин, и сидящий троян скрытно спионерил все пароли из него)
7) Вопрос про точный алгоритм и использованные параметры (вектора инициализации, параметры кривой, режим применения и прочее) [с целью обеспечения совместимости с другим ПО, например, серверным, которое могло бы генерировать сообщения, читаемые пользователями через свою Ключ_П1ы].
8) Доступен ли Crypto API для вычисления хеша/шифрации/дешифрации используя КП1?
9) Сколько ключей было добавлено для спецслужб в процессе получения лицензии?
2) Чем гарантируется неизвлечение уже хранящихся ключей из устройства?
3) Проводили ли Fuzz-тестирование как на уровне USB так и API?
4) Восстановимы ли данные с носителя информации после извлечения ключей?
5) Читаем ли скрытый раздел после использования открытой части носителя без использования Ключ_П1?
6) Что предприняли для защиты от кражи паролей из устройства программными средствами? (то есть пользователь ввел пин, и сидящий троян скрытно спионерил все пароли из него)
7) Вопрос про точный алгоритм и использованные параметры (вектора инициализации, параметры кривой, режим применения и прочее) [с целью обеспечения совместимости с другим ПО, например, серверным, которое могло бы генерировать сообщения, читаемые пользователями через свою Ключ_П1ы].
8) Доступен ли Crypto API для вычисления хеша/шифрации/дешифрации используя КП1?
9) Сколько ключей было добавлено для спецслужб в процессе получения лицензии?
1) Ключи хранятся на устройстве, но сгенерировать их можно на ПК перед процессом инициализации
2) Ключи хранятся во флеш памяти второго процессора у которого закрыты встроенные загрузчики и установлен режим безопасности
3) Занимаемся этим
4) Если у Вас есть ключи и есть образ закрытого раздела, который этими ключами зашифрован по секторам и Вы знаете какой сектор каким ключом зашифрован, то да
5) Да конечно
6) Ключи из устройства не получить ни программно ни аппаратно, что касается паролей, то получение каждого пароля происходит по пин коду, пока программной защиты от этого не делали.
7) Пока для настройки стороннего ПО по типу Key_P1 мы не занимались, надо уточнить у руководства мнение по открытию алгоритмов
8) Нет
9) Пока нисколько, это бизнес версия. По профессиональной пока тоже ничего не добавляли для спецслужб.
2) Ключи хранятся во флеш памяти второго процессора у которого закрыты встроенные загрузчики и установлен режим безопасности
3) Занимаемся этим
4) Если у Вас есть ключи и есть образ закрытого раздела, который этими ключами зашифрован по секторам и Вы знаете какой сектор каким ключом зашифрован, то да
5) Да конечно
6) Ключи из устройства не получить ни программно ни аппаратно, что касается паролей, то получение каждого пароля происходит по пин коду, пока программной защиты от этого не делали.
7) Пока для настройки стороннего ПО по типу Key_P1 мы не занимались, надо уточнить у руководства мнение по открытию алгоритмов
8) Нет
9) Пока нисколько, это бизнес версия. По профессиональной пока тоже ничего не добавляли для спецслужб.
1) Но генерация ключа же на ПК это несекурно изначально!
2) То есть у второго процессора есть ТОЛЬКО функция «запомнить» ключ и «зашифровать»/«расшифровать» и всё? И его прошивка не обновляема? То есть при обнаружении ошибки в криптографии или для добавки нового алгоритма требуется отзыв всех устройств КП1?
4) Стоп. Разве таблица какой сектор каким ключом не хранится на самом носителе?
5) А сохраняет ли работоспособность раздел после его перемещения по диску физически, и/или изменению размера?
7) Если алгоритм скрыт, чем докажете что там правда ГОСТ без доп.закладок и без предварительной генерации ослабленных ключей?
9) И ГПСЦ не ослаблялся, и кривая не выбиралсь из списка рекомендованных для бизнес версий?
2) То есть у второго процессора есть ТОЛЬКО функция «запомнить» ключ и «зашифровать»/«расшифровать» и всё? И его прошивка не обновляема? То есть при обнаружении ошибки в криптографии или для добавки нового алгоритма требуется отзыв всех устройств КП1?
4) Стоп. Разве таблица какой сектор каким ключом не хранится на самом носителе?
5) А сохраняет ли работоспособность раздел после его перемещения по диску физически, и/или изменению размера?
7) Если алгоритм скрыт, чем докажете что там правда ГОСТ без доп.закладок и без предварительной генерации ослабленных ключей?
9) И ГПСЦ не ослаблялся, и кривая не выбиралсь из списка рекомендованных для бизнес версий?
1) Да, приходится доверять компьютеру на котором мы генерируем первый раз ключи.
Это необходимо для возможности восстановления устройства.
2) У нас в устройстве функционирует и процессор стм32, поскольку в Multiclet P1 нет USB host, у процессора стм32 есть режим безопасности (т.е. загрузчики встроенные недоступны, флеш память не считать, про пользователя Barsmonster пока не говорим). Шифрование информации происходит только на процессоре Multiclet P1. Прошивка устройства обновляема, но имеет нашу подпись, которая хранится в секретной комнате с ограниченным доступом. Устройство Key_P1 перед тем как запустить прошивку запускает наш загрузчик, который производит расчёт цифровой подписи прошивки и осуществляет её проверку. Загрузчик отдает управление прошивке только в случае её валидности.
4) Такая таблица не хранится на накопителе.
5) В принципе перемещение не должно влиять, а вот изменение размера зашифрованного раздела повлияет.
7) Есть документ в котором приведён исходный код алгоритма на ассемблере мультиклеточного процессора.
Пока разрешения на выкладывания в открытый доступ данного документа у меня нет.
9) Вопрос доверия
Это необходимо для возможности восстановления устройства.
2) У нас в устройстве функционирует и процессор стм32, поскольку в Multiclet P1 нет USB host, у процессора стм32 есть режим безопасности (т.е. загрузчики встроенные недоступны, флеш память не считать, про пользователя Barsmonster пока не говорим). Шифрование информации происходит только на процессоре Multiclet P1. Прошивка устройства обновляема, но имеет нашу подпись, которая хранится в секретной комнате с ограниченным доступом. Устройство Key_P1 перед тем как запустить прошивку запускает наш загрузчик, который производит расчёт цифровой подписи прошивки и осуществляет её проверку. Загрузчик отдает управление прошивке только в случае её валидности.
4) Такая таблица не хранится на накопителе.
5) В принципе перемещение не должно влиять, а вот изменение размера зашифрованного раздела повлияет.
7) Есть документ в котором приведён исходный код алгоритма на ассемблере мультиклеточного процессора.
Пока разрешения на выкладывания в открытый доступ данного документа у меня нет.
9) Вопрос доверия
2) То есть Multiclet, прошивка которого обновляема (с вашей подписью, разумется), имеет возможность из stm32 достать ключи. Соответственно, как минимум вы можете создать прошивку, которая выдаст все хранящиеся на нём ключи на хост. Верно?
4) То есть на ВСЕХ используемых носителях подключенных к КП1 одни и те же сектора шифруются одним и тем же ключом. Верно?
5) То есть алгоритм выбора используемого ключа для сектора представляет собой генератор, зависящий только от размера раздела?
7) То есть ничем :) Вся идея современной криптографии в том, что алгоритмы не просто не нужно скрывать, наоборот — их НУЖНО открывать :) и это безопасно. просто потому, что стойкость зависит от ключей, а не от секретности алгоритма.
Если же вы зависите от публичности алгоритма — вы что-то делаете не так.
9) Которому, очевидно, не откуда взяться.
4) То есть на ВСЕХ используемых носителях подключенных к КП1 одни и те же сектора шифруются одним и тем же ключом. Верно?
5) То есть алгоритм выбора используемого ключа для сектора представляет собой генератор, зависящий только от размера раздела?
7) То есть ничем :) Вся идея современной криптографии в том, что алгоритмы не просто не нужно скрывать, наоборот — их НУЖНО открывать :) и это безопасно. просто потому, что стойкость зависит от ключей, а не от секретности алгоритма.
Если же вы зависите от публичности алгоритма — вы что-то делаете не так.
9) Которому, очевидно, не откуда взяться.
2) Теоретически да, но доступ к подписи имеет ограниченный круг лиц, комната безопасности сертифицирована. Даже если вы потеряете все пароли, мы не будем писать такую прошивку. И сейчас её не существует.
4) Одни и те же сектора одного и того же раздела — да, сейчас количество случайных ключей статично 1024, в дальнейшем можем дать этот параметр пользователю на его усмотрение(от 1 до 1024).
5) От размера сектора -нет, от положения сектора в разделе — да
7) Я не сказал, что мы зависим от публичности алгоритма, я не против его выложить.
Но без разрешения начальства такой документ не могу разместить. Я согласен с идеей, что нужно открывать алгоритмы. Мы хотели выложить и исходники ПО, но пока не получили на это разрешения.
Разместить исходники алгоритма недолго.
4) Одни и те же сектора одного и того же раздела — да, сейчас количество случайных ключей статично 1024, в дальнейшем можем дать этот параметр пользователю на его усмотрение(от 1 до 1024).
5) От размера сектора -нет, от положения сектора в разделе — да
7) Я не сказал, что мы зависим от публичности алгоритма, я не против его выложить.
Но без разрешения начальства такой документ не могу разместить. Я согласен с идеей, что нужно открывать алгоритмы. Мы хотели выложить и исходники ПО, но пока не получили на это разрешения.
Разместить исходники алгоритма недолго.
Я правильно понимаю, что рандомный IV у вас отсутствует, таким образом залив весь раздел нулями после легко определить какие сектора шифровались одинаковыми ключами?
Используется ли предварительное сжатие и заполнение хвоста рандомом, для устранения подобной проблемы?
Если да, то как себя поведёт, если на входе несжимаемые данные?
Используется ли предварительное сжатие и заполнение хвоста рандомом, для устранения подобной проблемы?
Если да, то как себя поведёт, если на входе несжимаемые данные?
Вы не определите какие сектора шифровались одинаковыми ключами, т.к. есть синхропосылка, которая разная для каждого сектора. В текущей версии прошивки предварительное сжатие не используется.
По поводу ГПСЧ и выбора кривой могу дополнить, что мы гарантируем, что никаких ослаблений нами не сделано и нам никакие указания по ослаблению защиты никогда не поступали.
По поводу ГПСЧ и выбора кривой могу дополнить, что мы гарантируем, что никаких ослаблений нами не сделано и нам никакие указания по ослаблению защиты никогда не поступали.
ага, то есть IV у вас есть, используется псевдослучайный с инициалзитором, зависящим от сектора.
спасибо.
спасибо.
кстати, правильно говорить:
К текущему моменту получено требований
* ослабления алгоритмов: 0
* добавления спец-ключей: 0
* создания прошивок для взлома: 0
и потом убирать пункты, которые станут ложью.
К текущему моменту получено требований
* ослабления алгоритмов: 0
* добавления спец-ключей: 0
* создания прошивок для взлома: 0
и потом убирать пункты, которые станут ложью.
Я не против, добавил к основной статье эти пункты.
Есть шанс получить такие требования? Кто уже сталкивался с лицензированием в конторе?
в РФ я слышал только об ограничении длины ключа в сертифицированном софте, и то довольно давно
Если ширина ключа не более 56 бит, то можно использовать такое шифрование без лицензии, если больше, то нужно получать лицензию. По началу мы хотели использовать алгоритм шифрования AES, но оказалось, что на него проблематично получить лицензию. Поэтому у нас ГОСТ. А ширина у данного алгоритма 256 бит.
Если кому интересно, законы можно почитать тут base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=128739
Если кому интересно, законы можно почитать тут base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=128739
Правильно ли я понимаю, что вся ключевая информация (пины, пароли, таблицы замены итп) храняться в STM32, а сам шифратор в Мильтиклете?
кстати, вопрос. а как защищен протокол мультиклет<=>stm32? что помешает мне вскрыть корпус (растворить, например, в ацетоне); запитать, потом «сдуть» мультиклет и подключиться к stm32?
В бизнес версии:
Допустим вы растворили корпус и подключились, но откуда Вам известен ПИН код?
Без ПИН кода протокол не работает. А если Вам известен ПИН, то зачем вскрывать.
В профессиональной версии:
Тут ключи хранятся в ОЗУ памяти, есть батарейка которая поддерживает питание этой памяти, если корпус вскрываете, то сработает концевик. Плюс ко всему в критических местах идёт заливка компаундом.
Допустим вы растворили корпус и подключились, но откуда Вам известен ПИН код?
Без ПИН кода протокол не работает. А если Вам известен ПИН, то зачем вскрывать.
В профессиональной версии:
Тут ключи хранятся в ОЗУ памяти, есть батарейка которая поддерживает питание этой памяти, если корпус вскрываете, то сработает концевик. Плюс ко всему в критических местах идёт заливка компаундом.
Защита от перебора пин-кода на самой STM32 реализована?
А как концевик относится к растворению корпуса с одной из сторон?
А как концевик относится к растворению корпуса с одной из сторон?
На ввод пин-кода пользователя есть 10 попыток, если пин-код пользователя заблокирован, то для его разблокировки необходимо использовать пин-код администратора. На ввод пин-кода администратора есть также 10 попыток, после блокировки пин-кода администратора уже ничего не поделать, только отформатировать устройство удалив все ключевые данные.
На этот случай есть компаунд. В профессиональную версию пока ещё можно вносить коррективы, если посоветуете как поставить более мощную защиту от вскрытия будем только рады это применить. Хотя можно сделать проще и хранить данные на ОЗУ в зашифрованном виде.
На этот случай есть компаунд. В профессиональную версию пока ещё можно вносить коррективы, если посоветуете как поставить более мощную защиту от вскрытия будем только рады это применить. Хотя можно сделать проще и хранить данные на ОЗУ в зашифрованном виде.
то есть после 20 попыток ввода в STM32 автоматически будет стёрта память?
а если чип будет запитан не 3.3в а 2.6-2.7в? по идее, операция стирания проходить не будет.
либо питать импульсно — запитываем, подаём команду проверки пина и убираем питание — за время разряда внутренних ёмкостей ответ должен успеть пройти, а вот команда стирания/записи номера попытки уже нет.
в итоге получим бесконечное число попыток + возможность перебора.
вариант хранения в шифрованном виде — самое оптимальное, по-моему.
особенно, если ключ шифрования будет рандомный, хранящийся во внутренней ОЗУ процессора.
а если чип будет запитан не 3.3в а 2.6-2.7в? по идее, операция стирания проходить не будет.
либо питать импульсно — запитываем, подаём команду проверки пина и убираем питание — за время разряда внутренних ёмкостей ответ должен успеть пройти, а вот команда стирания/записи номера попытки уже нет.
в итоге получим бесконечное число попыток + возможность перебора.
вариант хранения в шифрованном виде — самое оптимальное, по-моему.
особенно, если ключ шифрования будет рандомный, хранящийся во внутренней ОЗУ процессора.
После 20 попыток память автоматически стёрта не будет, устройство будет заблокировано. Для стирания необходимо загрузить у нас утилиту.
Бесконечное число попыток не удастся получить, т.к. ответ не пройдёт до записи номера попытки.
Но у нас ещё есть тревожный пин-код, который в случае принудительного ввода можно ввести на любой запрос пин-пользователя или пин-администратора и ключевая информация будет стерта.
По ОЗУ согласен.
Бесконечное число попыток не удастся получить, т.к. ответ не пройдёт до записи номера попытки.
Но у нас ещё есть тревожный пин-код, который в случае принудительного ввода можно ввести на любой запрос пин-пользователя или пин-администратора и ключевая информация будет стерта.
По ОЗУ согласен.
Надо посмотреть на потребление процессора во время записи/стирания… Возможно, можно по графику потребления отличить.
Но это уже извращение, конечно :)
Но это уже извращение, конечно :)
Но функция у нас контролирует прошла ли запись.
Я к тому, что надо четко проследить, чтобы обе ветки (успех/не успех) не отличались ничем кроме собственно результата ответа.
То есть запись во флеш должна быть в обоих случаях, желательно писать одно и то же количество единиц-нулей, чтобы время до момента начала записи было буквально идентичным в тактах процессора.
То есть нам неважно же записали или нет, если есть разница между ними.
кстати, время не должно отличаться и от пина — а то будет возможен подбор посимвольно.
То есть запись во флеш должна быть в обоих случаях, желательно писать одно и то же количество единиц-нулей, чтобы время до момента начала записи было буквально идентичным в тактах процессора.
То есть нам неважно же записали или нет, если есть разница между ними.
кстати, время не должно отличаться и от пина — а то будет возможен подбор посимвольно.
>> Шифровальные флешки, функционал, ширина ключа.
Взрывная статья, спасибо!
Взрывная статья, спасибо!
Зачем в наше время что-то хранить на флешке, когда можно закриптовать и сохранить в нескольких местах в интернете/фринете. Когда гебня приедет, флешку заберут и информация исчезнет, интернет же лишен таких недостатков.
Как формировались S-блоки и есть ли возможность их заменить своими?
А какова пиковая скорость шифрации на мультиклете?
И получается что мультиклет только шифратор. Все функции по обеспечению безопасности (ограничение доступу к
пинам, паролям) итп лежит на STM32?
И получается что мультиклет только шифратор. Все функции по обеспечению безопасности (ограничение доступу к
пинам, паролям) итп лежит на STM32?
1,7 Мбит/сек при 100 МГц скорость шифрования, проверил ещё раз, прилично времени на него уходит. Конечно считаем, что текущая версия имеет право на существование. Но и не забываем о прогрессе, поскольку для увеличения скорости рассматривается вариант ревизии процессора Multiclet R1 с аппаратной реализацией ГОСТ89, с USB host, тогда будет только один процессор с повышением производительности более чем в 10 раз.
Для подключения закрытого раздела используется ПИН код пользователя.Я правильно понимаю, файлы на закрытом разделе становятся видны операционной системе после ввода ПИНа?
И вообще, может я просто пропустил что-то в статье, но опишите типичный сценарий работы с уже инициализированным устройством, хотя бы один абзац в стиле «пользователь втыкает устройство, в него втыкает флэшку, вводит пин, появляется диск, он копирует на него файлик ....»
Вы совершенно правы, всё именно так:
Вот кратко в картинках:
один абзац в стиле «пользователь втыкает устройство, в него втыкает флэшку, вводит пин, появляется диск, он копирует на него файлик ....»
Вот кратко в картинках:
Спасибо,
тогда вопрос:
если операционная система видит всё после ввода ПИНа, как же защитить информацию от выкачивания при втыкании в зараженный компьютер? Логи — я увидел, это ценно для «разбора полетов» в службе безопасности, но для Stuxnet-то где-то исходники гуляют, а смысл той атаки был именно такой — найти нужное специфическое устройство и что-то с ним сделать. Только там в него записывали данные, а тут будут читать.
Конкретно — как быть и что делать с личными компьютерами (ноутбуками) сотрудников с максимальными правами на чтение?
тогда вопрос:
если операционная система видит всё после ввода ПИНа, как же защитить информацию от выкачивания при втыкании в зараженный компьютер? Логи — я увидел, это ценно для «разбора полетов» в службе безопасности, но для Stuxnet-то где-то исходники гуляют, а смысл той атаки был именно такой — найти нужное специфическое устройство и что-то с ним сделать. Только там в него записывали данные, а тут будут читать.
Конкретно — как быть и что делать с личными компьютерами (ноутбуками) сотрудников с максимальными правами на чтение?
Кстати да. SD карту для логов во write-only режиме — было бы няшно-няшно.
Установив режим «только чтение» мы защитим накопители от вирусов. Если хотим ещё и обезопасить данные от вирусов, тогда придётся предварительно зашифровать информацию. Даже если вирус украдёт зашифрованные ранее файлы, они не сильно помогут злоумышленнику. Процедура шифрования файла не на закрытом разделе инициализированного накопителя, а в «любом месте» происходит схожим образом как и на закрытом разделе, т.е. один файл может быть зашифрован большим количеством ключей(шифровать случайными ключами мы можем не только на накопителе).
А про SD карту и логи я не совсем понимаю, логи у нас хранятся на устройстве.
Или Вы имеете ввиду установить режим «только запись» и сохранять в таком режиме файлы?
А про SD карту и логи я не совсем понимаю, логи у нас хранятся на устройстве.
Или Вы имеете ввиду установить режим «только запись» и сохранять в таком режиме файлы?
Логи доступа. Список файлов к которым был доступ на этом разделе во сколько, с какого компьютера.
После инициализации и ввода пина (см. картинки выше) и ввода команды «xcopy /E g: d:\CopyOfDriveG» мы в папке «d:\CopyOfDriveG» получаем расшифрованные файлы с носителя — все вообще. Так?
дополнительная SD для логов в write-only позволит потом посмотреть все операции с файлами, хотя бы определить, что был слив. Непонятно только как слив предотвратить.
дополнительная SD для логов в write-only позволит потом посмотреть все операции с файлами, хотя бы определить, что был слив. Непонятно только как слив предотвратить.
Можем например в логах устройства отметить, что происходило копирование какой-то информации в такое то время, такого то объёма. Устройство же не понимает какой файл копируется, допустим в логах будут сектора, но это мало информации даст. Если флешка пользователя то о каком сливе идёт речь, допустим файлы зашифрованы, тогда и вирусу они не сильно пригодятся. Компьютер рабочий можно защитить, если администратор жёстко установит для пользователя режим «только чтение» без права выключения этого режима пользователем.
сейчас внимательно:
0. Человек имеет права на чтение всех зашифрованных файлов. Берет свой домашний ноутбук. У сына своего только что отнял, хочет поработать в субботу днем.
1. Подключает устройство Key_P1
2. Подключает в него флэшку с зашифрованными данными
3. Инициализация, ввод пароля.
4. У него становится доступно все содержимое зашифрованного носителя [USB PRIVATE] G: (или я чего-то не понял?)
5. Тут появляется злобный хацкер и выполняет на ноутбуке удаленно команду «xcopy /E g: c:\CopyOfDriveG», производит слив всего содержимого в расшифрованном виде.
Такой сценарий возможен теоретически?
0. Человек имеет права на чтение всех зашифрованных файлов. Берет свой домашний ноутбук. У сына своего только что отнял, хочет поработать в субботу днем.
1. Подключает устройство Key_P1
2. Подключает в него флэшку с зашифрованными данными
3. Инициализация, ввод пароля.
4. У него становится доступно все содержимое зашифрованного носителя [USB PRIVATE] G: (или я чего-то не понял?)
5. Тут появляется злобный хацкер и выполняет на ноутбуке удаленно команду «xcopy /E g: c:\CopyOfDriveG», производит слив всего содержимого в расшифрованном виде.
Такой сценарий возможен теоретически?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Цифровой страж Key_P1: история создания и первые результаты