Есть система, установленная на Windows. Работает на производстве и выполняет производственные задачи. Время от времени заливает отчёты на наш FTP.
Возникло требование отчёты шифровать и передавать по SFTP, для этого нужно как-то хранить в системе приватный ключ.
Сервис, который этим занимается дотнетовский, следовательно может быть легко декомпилирован. Пробовал обфуксацию, но на моём рабочем лаптопе его убивает антивирь при запуске, значит антивирь может сработать у клиента (антивирь клиента мы не можем контролировать, и не имеем права просить его добавлять нас в исключения).
Но всё равно не понятно: ключ, даже запротекченный надо где-то сохранять, чтобы сервис переживал перезагрузки, а значит зная где он лежит, можно вызвать тот же самый API и расшифровать ключ.
s_additionalEntropy = { 9, 8, 7, 6, 5 }; — можно узнать декомпилируя сервис. Просить юзера каждый запуск вводить пароль расшифровки нельзя. Система запускается с автологином (производство и производственные задачи).
Как же хранить этот ключ в таких условиях?
Или просто сделать на от***сь и не париться?
Для начала надо определиться с моделью угрозы и исходя из этого уже решать, что и как шифровать.
Если при загрузке компьютера не вводится пароль, то никакое шифрование тут не поможет. Можете сделать файл скрытым или зашифровать с xor 0xaa, чтобы защититься от совсем уж простых атак.
Если при загрузке компьютера вводится пароль для пользователя Windows, то имеет смысл использовать DPAPI (класс ProtectedData). По сути данные на диске будут зашифрованы с помощью пароля пользователя Windows. Если диск своруют, а пароль знать не будут, то извлечь закрытый ключ не смогут. Но судя по всему у вас пароль не вводится, поэтому такое шифрование ничем принципиально не будет отличаться от xor 0xaa.
Если вас будет пытаться взломать злой хакер с доступом к компьютеру и всеми паролями, шифрование не поможет.
Здравствуйте, vsb, Вы писали:
vsb>Для начала надо определиться с моделью угрозы и исходя из этого уже решать, что и как шифровать.
vsb>Если при загрузке компьютера не вводится пароль, то никакое шифрование тут не поможет. Можете сделать файл скрытым или зашифровать с xor 0xaa, чтобы защититься от совсем уж простых атак.
Формально пароль есть, просто настроен автологин.
vsb>Если вас будет пытаться взломать злой хакер с доступом к компьютеру и всеми паролями, шифрование не поможет.
Да, это я перемудрил. Подразумевал, что хацкер имеет физический доступ к системе, и может запускать там свои программы.
Считаю, что DPAPI вполне себе вариант.
Кстати, а что случится, при смене юзерского пароля?
Здравствуйте, Doom100500, Вы писали:
D>Кстати, а что случится, при смене юзерского пароля?
Если менять стандартным образом через ввод старого и нового, то ничего. Если сбросить пароль, то и данные перестанут расшифровываться. Возможно со всякими доменами будут нюансы, тут не знаю.
Здравствуйте, Doom100500, Вы писали:
D>Можно попробовать предложить, но эту идею откинут сразу. Мы не очень хотим рассылать всем запчасти.
А чем штатный механизм не нравиться? Устанавливаете сертификат с приватным ключом. Срок действия сертификата например год (для параноиков можно чаще).
Периодически его обновляете генерите приватный ключ на этом компе и запрос на сертификат, и потом получаете сертификат со своего сервера сертификатов и подписываете данные им пока он действует, по окончанию или отзыву по новый.
Приватный ключ, не покидает клиента и вам он не нужен и в случае компрометации можно отозвать сертификат и выпустить новый.
Здравствуйте, kov_serg, Вы писали:
_>Здравствуйте, Doom100500, Вы писали:
_>А чем штатный механизм не нравиться?
Да я за любой движняк
_>Устанавливаете сертификат с приватным ключом. Срок действия сертификата например год (для параноиков можно чаще).
Не очень понял. В теме ключей на винде опыта нет. Речь об этом? https://docs.microsoft.com/en-us/windows/win32/seccng/key-storage-and-retrieval
_>Периодически его обновляете генерите приватный ключ на этом компе и запрос на сертификат, и потом получаете сертификат со своего сервера сертификатов и подписываете данные им пока он действует, по окончанию или отзыву по новый.
Допустим... но что такое запрос на сертификат? Что такое сервер сертификатов? (если кошерно, то поднимем) Разве не надо аутенфицироваться перед сервером сертификатов для получения ключа (и тогда возвращаемся к исходной проблеме)?
Если честно, то вообще не понял это предложение. Для аутенфикации перед SFTP сервером нужен клиентский приватный ключ. Ну вот сгенерировали, теперь публичный ключ надо залить на SFTP сервер для конкетного пользователя (допустим, что у сервера есть API для этого). Причём здесь запрос на сертификат и сервер сертификатов (который ещё нужно поднять)?
Здравствуйте, Doom100500, Вы писали:
_>>Периодически его обновляете генерите приватный ключ на этом компе и запрос на сертификат, и потом получаете сертификат со своего сервера сертификатов и подписываете данные им пока он действует, по окончанию или отзыву по новый.
D>Допустим... но что такое запрос на сертификат? Что такое сервер сертификатов? (если кошерно, то поднимем) Разве не надо аутенфицироваться перед сервером сертификатов для получения ключа (и тогда возвращаемся к исходной проблеме)? D>Если честно, то вообще не понял это предложение. Для аутенфикации перед SFTP сервером нужен клиентский приватный ключ. Ну вот сгенерировали, теперь публичный ключ надо залить на SFTP сервер для конкетного пользователя (допустим, что у сервера есть API для этого). Причём здесь запрос на сертификат и сервер сертификатов (который ещё нужно поднять)?
Пользователь генерирует приватный ключ и затем формирует запрос на сертификат (туда можно добвать дополнительную информацию, например hash от мак адрес сетевухи, серийник винды и т.п.)
Потом этот запрос отправляется на ваш сервер, хоть по email он не является секретным.
Вы по этому запросу формируете сертификат подписанный вашим приватным ключом и можете дополнить информацию в сертификате. И отправляете её клиенту (этот сертификат тоже не секретный)
После получения этого сертификата, он вместе с приватным ключем може использоваться для сессии ssh через которую можно подключаться в чему угодно по шифрованному каналу. Можно и по https в обязательном порядке, требуя клиентский сертификат.
С помощью openssl делается в несколько строчек.
D>Что такое сервер сертификатов?
Обычно это несколько серверов (2 шт). Они выдают списки отозванных сертификатов, ну и создают новые по запросу и хранят выданные в базе.
D>Разве не надо аутенфицироваться перед сервером сертификатов для получения ключа
Вы можете предусмотреть автоматическое обновление с еще действующим сертификатом, и ручное по запросу если что-то пошло не так.
если как вы написали хакеры имеют полный доступ к системе, то они могут и скопировать и модифицировать и просто удалить
данные [до шифрования] (да и всю вашу программу уничтожить, да и винду залочить другим паролем или просто форматнуть), которые вы собираетесь шифровать и передавать.
мне кажется вы неправильно сформулировали задачу. Чрезмерно усилили изначальные требования.
вероятно от вас требовалось только защитить данные от прочтения и модификации при передаче по каналу связи,
а к исходному компу вероятно хакеры доступа по ТЗ не имеют, или ограниченный доступ в виде логина под ограниченным юзером, под которым и авто-ре-логин.
Здравствуйте, paradok, Вы писали:
P>Здравствуйте, Doom100500, Вы писали:
D>>Как же хранить этот ключ в таких условиях?
P>если как вы написали хакеры имеют полный доступ к системе, то они могут и скопировать и модифицировать и просто удалить P>данные [до шифрования] (да и всю вашу программу уничтожить, да и винду залочить другим паролем или просто форматнуть), которые вы собираетесь шифровать и передавать.
P>мне кажется вы неправильно сформулировали задачу. Чрезмерно усилили изначальные требования. P>вероятно от вас требовалось только защитить данные от прочтения и модификации при передаче по каналу связи, P>а к исходному компу вероятно хакеры доступа по ТЗ не имеют, или ограниченный доступ в виде логина под ограниченным юзером.
P>Так?
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Doom100500, Вы писали:
D>>Возникло требование отчёты шифровать и передавать по SFTP
W>С какой целью? Если для того, чтобы не перехватили по пути, то передавайте по HTTPS, вполне достаточно.
Мы не интернет компания, и не разрабатываем сервера. У нас есть купленный продукт (Serv-U) — это FTP/SFTP server, у него, кстати, нет никакого API для администрирования — только веб-морда и мышеводство. Уже много лет он принимает эти отчёты то протоколу FTP. И никто не будет выделять временной бюджет для разработки своего сервера с блэкджеком и поэтесами (к сожалению). Задача пришла от материнской компании зашифровать это соединение.
У меня возник вопрос как безопасно хранить ключ, и я немного перемудрил с вектором возможных атак.
Как мне кажется — вполне подходит DPAPI.
Здравствуйте, Doom100500, Вы писали:
D>Здравствуйте, paradok, Вы писали:
P>>Здравствуйте, Doom100500, Вы писали:
D>>>Как же хранить этот ключ в таких условиях?
P>>если как вы написали хакеры имеют полный доступ к системе, то они могут и скопировать и модифицировать и просто удалить P>>данные [до шифрования] (да и всю вашу программу уничтожить, да и винду залочить другим паролем или просто форматнуть), которые вы собираетесь шифровать и передавать.
P>>мне кажется вы неправильно сформулировали задачу. Чрезмерно усилили изначальные требования. P>>вероятно от вас требовалось только защитить данные от прочтения и модификации при передаче по каналу связи, P>>а к исходному компу вероятно хакеры доступа по ТЗ не имеют, или ограниченный доступ в виде логина под ограниченным юзером.
P>>Так?
D>Вё так, я уже выше признал, что перемудрил
тогда имхо вам надо вашу прогу инсталить под админом и иметь она должна права на чтение файла с паролем шифрования (сервисная часть),
а штатно она (юзерская часть) должна работать под ограниченным юзером
у которого просто нет доступа на чтение к файлу с паролем. тогда презагруз компа хакером под/в ограниченного юзера не даст ему доступа к паролю.
Юзерская часть проги будет запрашивать шифрование у вашей сервисной части одним способов, что есть док у микрософта по взаимодействию прог и сервисов.
Здравствуйте, Doom100500, Вы писали:
D>Мы не интернет компания, и не разрабатываем сервера. У нас есть купленный продукт (Serv-U) — это FTP/SFTP server, у него, кстати, нет никакого API для администрирования — только веб-морда и мышеводство. Уже много лет он принимает эти отчёты то протоколу FTP. И никто не будет выделять временной бюджет для разработки своего сервера с блэкджеком и поэтесами (к сожалению).
Зачем вам разрабатывать свой сервер? HTTP сервера бесплатны в большинстве своем, я даже не могу вспомнить ни одного живого коммерческого.
Бюджет нужен только разово на развертывание и настройку NGINX (например). А смотреть за ним админы у вас по-любому есть.
D>У меня возник вопрос как безопасно хранить ключ,
Безопасно — не хранить, а генерировать временный на каждый сеанс передачи. Например, как в HTTPS
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Doom100500, Вы писали:
W>Зачем вам разрабатывать свой сервер? HTTP сервера бесплатны в большинстве своем, я даже не могу вспомнить ни одного живого коммерческого. W>Бюджет нужен только разово на развертывание и настройку NGINX (например). А смотреть за ним админы у вас по-любому есть.
На текущем купленом SERV-U настроены пользователи, права и рабочие директории. Пользователи — в терминах FTP. На него смотрят различные утилиты внутри компании, и иногда снаружи. Повторить это разовой развёрткой nginx может быть и можно (хотя я считаю. что проще уже будет на гошке наколхозить), но менять всё инфраструктуру, которая расчитывает на FTP протокол (переписывать код), никто не даст.
D>>У меня возник вопрос как безопасно хранить ключ,
W>Безопасно — не хранить, а генерировать временный на каждый сеанс передачи. Например, как в HTTPS
D>Есть система, установленная на Windows. Работает на производстве и выполняет производственные задачи. Время от времени заливает отчёты на наш FTP. D>Возникло требование отчёты шифровать и передавать по SFTP, для этого нужно как-то хранить в системе приватный ключ.
Если ваш сервер пытается как-то аутентифицировать клиента по данным предоставляемым клиентом, то вы не сможете защитить данные клиента при неограниченно доступе к клиенту.
То есть если у вас все пользователи работают под одной учеткой (не дай бог с автовходом) и\или под учеткой с правами админа, то защитить данные нельзя.
Если можно:
создать несколько непривилегированных учеток не раздавать всем пароли от них
под одной из учеток запустить сервис, который будет передавать данные по FTP
Тогда учетные данные от этого сервиса можно достаточно надежно скрыть от других пользователей средствами DPAPI. А если диск защитить bitlocker, то вероятность угона учетных без знания пароля учетки, крайне мала.
D>Как же хранить этот ключ в таких условиях?
Попробуйте ключ не хранить.
Пусть сервер аутентифицирует клиента по IP например. В самом простом варианте FTP + анонимный вход + фильтр по ip на сервере.
Еще говорят встроенная windows\kerberos аутентификация помогает, но вероятнее всего не ваш случай.
D>Или просто сделать на от***сь и не париться?
Если вы серьезно рассматриваете такой вариант, то видимо он вам подойдет.
Здравствуйте, gandjustas, Вы писали:
G>Начнем с конца
G>То есть если у вас все пользователи работают под одной учеткой (не дай бог с автовходом) и\или под учеткой с правами админа, то защитить данные нельзя. G>Если можно: G>
G>создать несколько непривилегированных учеток G>не раздавать всем пароли от них G>под одной из учеток запустить сервис, который будет передавать данные по FTP G>G>Тогда учетные данные от этого сервиса можно достаточно надежно скрыть от других пользователей средствами DPAPI. А если диск защитить bitlocker, то вероятность угона учетных без знания пароля учетки, крайне мала.
Этот компютер — система оптической проверки для печатной индустрии. Установлен на вонючем и шумном заводе в кабинете (железный ящик) печатного преса. например как здесь (Опа, а там наши экраны ).
Клавиатура закрыта в кабинете вместе с системным блоком на ключ, и открывается только сервисным инженером (конечно и этот ключ можно подделать или хранить прямо на рабочем столе). Система заводится нажатием на зелёную кнопку, вмонтированную в рабочий стол. После инициакизации готова к работе и управляется мышью или тач скрином. Других задач у этого компютера нет. Отчёты — это статистистические данные и крэш дампы.
D>>Как же хранить этот ключ в таких условиях? G>Попробуйте ключ не хранить. G>Пусть сервер аутентифицирует клиента по IP например. В самом простом варианте FTP + анонимный вход + фильтр по ip на сервере.
IP далеко не статичный, и вообще NAT. И сервер коробочный, купленный и делает только то, что делает и ничего больше.
G>Еще говорят встроенная windows\kerberos аутентификация помогает, но вероятнее всего не ваш случай.
D>>Или просто сделать на от***сь и не париться? G>Если вы серьезно рассматриваете такой вариант, то видимо он вам подойдет.
Если принять во внимание то, что я выше описал, достаточно ли будет формально зашифровать с помощью DPAPI и не париться, или надо всё-же продавливать с нуля новое решение (не факт, что удачно при всём выше сказанном)
EDIT G>под одной из учеток запустить сервис, который будет передавать данные по FTP
Здравствуйте, Doom100500, Вы писали:
D>Как же хранить этот ключ в таких условиях?
Помимо того как хранить ключ стоит рассмотреть также как его инициализировать.
Да и при приведенных выше условиях, вам правильно сказали что xor или DPAPI будет достаточно.
И, кстати, непонятно какая может быть цель у атакующего. крешдампы? отчеты статистики?
Здравствуйте, pva, Вы писали:
pva>Здравствуйте, Doom100500, Вы писали:
D>>Как же хранить этот ключ в таких условиях? pva>Помимо того как хранить ключ стоит рассмотреть также как его инициализировать. pva>Да и при приведенных выше условиях, вам правильно сказали что xor или DPAPI будет достаточно.
pva>И, кстати, непонятно какая может быть цель у атакующего. крешдампы? отчеты статистики?
Так же, как и непонятно требование материнской компании шифровать канал.
Но раз уж шифруем, то глупо держать ключ в открытом виде.
Потому и: D>>>Или просто сделать на от***сь и не париться?
