Программно-аппаратная защита

← →
Jungle © (2009-05-26 09:49) [0]

Суть такова. Разграничить функционал программы с помощью аппаратных ключей примерно так:
1. без ключа работает в базовом режиме;
2. с ключом "администратора" работает в расширенном режиме;
3. с "сервис"-ключом - дополнительный функционал.

Приму советы, рекомендации.
Пока ориентируюсь на Guardant (http://www.guardant.ru)

← →
KilkennyCat © (2009-05-26 10:10) [1]

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

← →
DVM © (2009-05-26 10:58) [2]

> Jungle © (26.05.09 09:49)

Ну и в чем состоит вопрос? В ключе есть поля, пишешь в них какую угодно инфу, идентифицирующую тип ключа и вперед.

← →
KSergey © (2009-05-26 11:31) [3]

> DVM © (26.05.09 10:58) [2]
> какую угодно инфу, идентифицирующую тип ключа и вперед.

сломать ключ легко если в проге просто проверка типа ключа будет.

> KilkennyCat © (26.05.09 10:10) [1]
> Дополнительный функционал зашить в ключ.

А вот как именно? чета придумать у меня не выходит так, чтобы надежно именно в данном случае.
Если что б совсем не работало (или криво работало) без ключа - то понятно. А тут?
Ну разве что пункты меню прятать по условию типа ключа, фигня что легко ломается - толку от пунктов не будет, т.к. часть логики по функционалу этих доп. пунктов в ключе? наверное вариант.

← →
KilkennyCat © (2009-05-26 11:34) [4]

> А вот как именно?

Зависит от типа ключа. Возможно вплоть до выполнения функционала в самом ключе.

← →
KilkennyCat © (2009-05-26 11:38) [5]

> сломать ключ легко если в проге просто проверка типа ключа
> будет.

Обычно там не так все просто. Не if ключ_есть then работаем. Например, я с Аладдиновскими работаю... так у меня проверка на наличие ключа служит лишь для сообщения пользователю, что ключа нет и дальше прога работать не будет.

← →
KSergey © (2009-05-26 11:48) [6]

> KilkennyCat © (26.05.09 11:34) [4]

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

← →
KilkennyCat © (2009-05-26 11:51) [7]

> Хочется услышать вариантов

Зависит от ключа.
Сначала лучше посмотреть на сайтах производителей, определиться с несколькими, а потом уж выбирать. Иначе слишком много текста. Да вот я, например, и не все знаю-то. Особо крутые мне экономически невыгодны.

← →
KSergey © (2009-05-26 12:03) [8]

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

Или я чего-то недогоняю?

← →
Jungle © (2009-05-26 12:11) [9]

1.
"Защищаемый" продукт далеко не массовый (с очень большой долей уверенности можно утверждать, что ломать никто не будет), просто таково требование, ибо пароль можно выболтать или, а когда железка у ответственного лица под замком - понадёжнее.
Дело в том, что подобного рода задачами я не занимался, в области безопасности не специалист, и в качестве технического решения выбрал первое, что нашёл в интернете (ключи Guardant Stealth III). Возможно, есть, например, более простые и дешёвые аналоги, позволяющие решить поставленную задачу.

2.
Ключ ключом, а человеческий фактор исключать нельзя.
Например, пришёл "надзиратель" с админским ключом, оператор в его присутствии поработал, ключ отдал, а программу не закрыл, комп в спящий режим. Или срочно отлучиться надо "надзирателю", а ключ оставлять нельзя, но и работа стоять не должна. Или внезапно ключ испортился каким-то образом, а запасной недоступен.
Т.е. необходим какой-то дополнительный механизм проверки. Думается, что самое правильное - периодическая проверка наличия ключа и блокирование работы в случае его отсутствия, а причины отсутствия - проблема пользователя. Компромиссный вариант в голову не приходит

← →
KilkennyCat © (2009-05-26 12:18) [10]

Ну да, в принципе так. Только реализация у разных по-разному.
Вот http://www.aladdin.ru - аладдиновские.

← →
Сергей М. © (2009-05-26 12:34) [11]

> Jungle © (26.05.09 12:11) [9]

Может стоит обратить взор на

http://www.rutoken.ru/products/
http://www.rutoken.ru/buying/price/

?

← →
KSergey © (2009-05-26 13:05) [12]

> Сергей М. © (26.05.09 12:34) [11]
> Может стоит обратить взор на

Какая разница какой именно ключ? ну кроме цены.
Вопрос как реализовать конкретное поведение приложений.

К стати, у рутокенов чета уклон на шифрования всякие. Оно как бы хорошо, а как к конкретной описаной задаче прикрутить?

← →
Сергей М. © (2009-05-26 13:14) [13]

> KSergey © (26.05.09 13:05) [12]

> ну кроме цены

А разве это немаловажный фактор ? Ну, разумеется, при прочих равных условиях ?

> у рутокенов чета уклон на шифрования всякие

Нормальный уклон).. Идут, можно сказать, в ногу с Алладином и прочими ведущими брендами в этом секторе ..

А уклон, наверно, вполне объясним - РуТокен с неких пор находится в тесном бизнес-парнерстве с другим довольно известным брендом - CryptoPro

> как к конкретной описаной задаче прикрутить?

Так никто же не заставляет криптофичи ихние прикручивать в обязательном порядке .. Хочешь - прикручивай, не хочешь - не прикручивай ..

← →
KSergey © (2009-05-26 13:18) [14]

> Сергей М. © (26.05.09 13:14) [13]
> Так никто же не заставляет криптофичи ихние прикручивать

А что у них еще-то есть? Я вот пробежал по сайту и по докам (поверхностно) - везде про какое-то шифрование. Нифига не понял, если честно. А если росто похранить в нем что-то/зашит в него алгоритм свой? Я не смог понять возможно ли это.

← →
Сергей М. © (2009-05-26 13:40) [15]

> А если росто похранить в нем что-то/зашит в него алгоритм
> свой?

Нашиша в ключе какой-то "свой алгоритм" ?
Алгоритм там уже прошит:

http://ru.wikipedia.org/wiki/%D0%93%D0%9E%D0%A1%D0%A2_28147%E2%80%9489

Осталось только прошить ключ шифрования под конкретного конечного потребителя программно-аппаратного комплекса, использующего этот RuToken-ключ.

Все остальное с успехом делается средствами SDK ключа.

← →
KilkennyCat © (2009-05-26 14:25) [16]

> Нашиша в ключе какой-то "свой алгоритм" ?

Были такие ключики, в которых частично выполнялся код программы. Хотя, что-то сейчас я ссылку на них не нашел... наверное, неактуальны более.

← →
Сергей М. © (2009-05-26 14:39) [17]

> KilkennyCat © (26.05.09 14:25) [16]

> наверное, неактуальны более

Я даже рискну предположить почему ..

Программ без ошибок и без апдейтов, как известно, не бывает)
Если часть кода таких программ зашивать в ключи, то для перепрошивки, связанной с устранением багов или функциональными апдейтами, придется отзывать ключи у массовых потребителей (на которых ключи как продукт собссно и расчитаны в 1-ю очередь).

← →
KilkennyCat © (2009-05-26 15:00) [18]

> Сергей М. © (26.05.09 14:39) [17]

Ага. А если не отзывая, грош цена секьюрити...

← →
KSergey © (2009-05-26 15:54) [19]

чета я тогда не шарю как надежную защиту организовывать
производители РуТокенов какие-то криптовалы только предлагают
Правда авторизаторы тоже предлагают (что вроде и требуется в этой задаче), но я чета никак как не пойму как их прикручивать к своим софтинам.

← →
Jungle © (2009-05-26 16:19) [20]

Насколько я понимаю, РуТокены - это, в первую (да и в основную) очередь, средства криптографической защиты информации, что подтверждается сертификатами. И для защиты приложений они не предназначены. Хотя, может быть, их возможно для этой цели приспособить. Только имеет ли смысл?
Вот для HASP у aladdin"а и Stealth у Guardant - чётко написано, что в их функции входит защита программ. Так что, вероятно, нужно выбирать между ними

← →
Сергей М. © (2009-05-26 16:20) [21]

> не шарю как надежную защиту организовывать

Защиту от чего конкретно ? С этого следует начинать) ..

← →
Сергей М. © (2009-05-26 16:29) [22]

> средства криптографической защиты информации

Скажем, точка входа в процедуру, реализующую требуемый функционал - это информация.

Зашифровать адрес точки входа с возможностью его последующей расшифровки с целью передачи по нему управления только при наличии соотв.ключа - вот она и криптографическая защита информации)

Меж прочим, касаемо алладиновых решений, HASP HL5 совместно с соответсnвующим энвелопером в составе HASP HL SDK, как раз и позволяет проделывать именно такие штуки, причем как раз на базе аппаратного AES-128-шифровальшика на борту ключа.

← →
Jungle © (2009-05-26 16:46) [23]

Сергей М.

> Меж прочим, касаемо алладиновых решений, HASP HL5 совместно
> с соответсnвующим энвелопером в составе HASP HL SDK, как
> раз и позволяет проделывать именно такие штуки, причем
> как раз на базе аппаратного AES-128-шифровальшика на борту
> ключа.

Я тут смотрю их краткий курс (ПО нет) и мне неясен один момент.
В доке написано про Envelope:
При каждом запуске защищенное приложение обращается к определенному ключу HASP
SRM и запрашивает с него необходимые данные. Если в этот момент ключ HASP SRM
не подсоединен к компьютеру или запрашиваемые данные некорректны, приложение не
запускается или перестает работать.
Что значит "перестаёт работать"? А если надо, чтоб работало?

← →
Сергей М. © (2009-05-26 16:58) [24]

> Что значит "перестаёт работать"?

Ну упрощенно алгоритм работы кода, генерируемого энвелопером в этом режиме, можно проиллюстрировать в след.псевдокоде:

if not ПодсоединенЛиКлюч(КонкретноИнтересующийКлюч) then
begin
Сообщение("Караул ! Ключа нет !")
ЗавершитьРаботуПриложения;
end;

> А если надо, чтоб работало?

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

← →
KSergey © (2009-05-26 17:23) [25]

> Сергей М. © (26.05.09 16:20) [21]
> Защиту от чего конкретно ? С этого следует начинать) ..

Не защиту от чего, огранизацию ее в постановке автора, т.е. не надо перекидывать шарик, беспредметно задавая встречные вопросы, ответ на который четко обозначен выше.

> Сергей М. © (26.05.09 16:29) [22]
> Скажем, точка входа в процедуру, реализующую требуемый функционал - это информация.

Однажды "подсмотренная" точка заменяется джампом - и готово.

В этом смысле вынос функционала в ключ как-то предпочтительнее видится. Хотя "по простому" может if not ПодсоединенЛиКлюч и канает, но как-то...

← →
Тимохов_ (2009-05-26 17:35) [26]

я только с семинара гарданта)

1. используй SDK. без этого никуда.
2. используй алгоритмы в ключе. без этого тоже никуда. можешь держать для разных вариантов работы разные алгоритмы и при необходимости их активировать.
3. организуй плавающий трафик.
4. места обработки результата ключа:
а) покрывай каким-то обфускатором (vmprotect, например)
б) используй результаты работы ключа естественным образом - т.е. ты знаешь, что должна появицо (декриптоваться) единица, так умножай на нее смело что-то: если один, то все ОК.
в) откладывай обработку результата работы ключа.
г) путай и прятай все подряд. в общем думай.

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

пример реализации (большие буквы - 128 бит, малые - 32 бита).
это самый простой вариант, дальше думай сам.

а) определения:
A - пароль.
m - кол-во вопрсоов.
n=1..m - номер вопроса
Bn - вопрос номер n
F(n)=B - функция номер вопроса (32 бита)->вопрос (128 бит)
Сn - ответ алгоритма ключа на вопрос номер n
G(B)=C - алгоритм ключа вопрос (128 бит)->ответ (128 бит)
xor - любое взаимообратное софтовое (т.е. НЕ в ключе, а в программе) преобразование, т.е. X xor Y = Z, то X = Z xor Y. (таких алгоритмов можно придумать массу).

б) на этапе построения защиты для каждого значения n:
* придумать пароль А.
* вычислить Bn = F(n)
* вычислить Cn = G(Bn)
* вычислить Dn = Bn xor Cn xor A

В программу помещается:
* массив Dn (возможно покриптованный как-то).
* функция F(n) (возможно реализованная на виртуальной машине - машина тьюринга классная вещь, еще brainfuck хорошая штука)

в) на этапе работы программы:
* cгенерить n - это может быть что угодно: рандомное значение, значение зависящее от текущих данных - это отдельная тема.
* вычислить Bn = F(n)
* вычислить Cn = G(Bn)
* вычислить A = Dn xor Bn xor Cn

весь этап в) покрывай проверенным и надежным бинарным обфускатором. можешь сам написать виртуальную машину.

далее делай с А, что хочешь - это пароль, а как его использовать придумывай сам.

например, это может быть ноль. прибавляй его смело к чему-нибудь, если не ноль, то программу будет работать некорректно.

это только заготовка. дальше надо много думать: как это сделать так, чтобы кусок нельзя было просто выкинуть заменив на заглушку. я свое время где-то 2 месяца занимался вопросом защиты.

в общем, ломается все, главное что? чтобы это а) не было сделано автоматизировано без затрат людских ресурсов б) не было сделано быстро.
в общем вопрос - в экономической целесообразности взлома.

ЗЫ Хинты.
1. в A можно держать закодированное значение чего нибудь. идей тебе массу даст книга "Алгоритмические трюки для программистов". она есть на сайте розыча http://rouse.drkb.ru/.
2. не используй простых вызовов рандомов - используй хитрые, адреса объектов, хендлы, случайные места в памяти и т.д.
3. перемежай код защиты другим полезным кодом.

← →
Сергей М. © (2009-05-26 17:38) [27]

> KSergey © (26.05.09 17:23) [25]

Цитирую автора:

> с очень большой долей уверенности можно утверждать, что
> ломать никто не будет

Так что с учетом

> Однажды "подсмотренная" точка заменяется джампом - и готово

про "шарики" - это в твой огород, а не в мой)

Про свои же потребности защиты чего-то там посредством еще чего-то там - будь столь любезен, заведи отдельную ветку, чтобы не было недоразумений.

← →
Сергей М. © (2009-05-26 17:46) [28]

> KSergey © (26.05.09 17:23) [25]
> Однажды "подсмотренная" точка заменяется джампом - и готово.

Эк у тебя все просто да гладко)

Раз - подсмотрел, два - подменил, три - готово дело)

Вряд ли я ошибусь, если предположу, что в действительности ты никогда не трассировал код, сгенерирорванный алладиновым энвелопером, использующим ф-ции аппаратного AES-шифрования на борту HASP HL5, и даже не представляешь, насколько серьезную проблему для потенциальных взломщиков представляет исследование исполняемого кода, генерируемого и уничтожаемого прямо в ран-тайм при непосредственном тесном участии аппаратного шифровальщика, ключ к ф-ции шифрования которого заведомо не известен и м.б. получен лишь гипотетически)

Боюсь рутокен не подойдет, это средство аутентификации а не криптографической защиты. Хотя...
вообще судя по задаче как я понял идей именно разграничить функционал и открывать часть его аутентифицированному пользователю, тогда да...

Ключи могут быть постоянно в контакте с ридером во время работы проги, либо кратковременно - при запуске.
Если постоянно, как ХАСП, то его никто вытаскивать не будет. Все равно нужно использовать пароли.
Если юзер свалил курить, не закрыв прогу... пользуйся кто хочешь полным функционалом.
Если "ключ на старт", то пароли не нужны, но если пользователь свалил курить...
В любом случа полезно задавать некоротый интервал простоя, по истечении выдавать предупреждение, и если не проявиться активность, то еще через 10..60сек закрывать софтину с/без сохранения.
На практике суперкриптование бессмысленно из-за дыр в организационной части безопасности. Д.б. принцип разумной достаточности.

> [30] Нат © (28.05.09 03:33)
> В любом случа полезно задавать некоротый интервал простоя,
> по истечении выдавать предупреждение, и если не проявиться
> активность, то еще через 10..60сек закрывать софтину с/без
> сохранения.

Хреновая метода - ты навязываешь пользователю свой интервал/график курения, чайения, кофе-паузы ну и т.п..

> AndreyV © (28.05.09 03:48) [31]
> Хреновая метода - ты навязываешь пользователю свой интервал/график курения,

Магазины тоже работают от и до и у кассира регламентированные перерывы. Беды нет никакой.
Разумеется зависит от конкретной ситуации и потребностей заказчика. Сделат интервалы настраиваемыми - легко.

> Сергей М. © (26.05.09 17:38) [27]
> Про свои же потребности защиты чего-то там посредством еще
> чего-то там - будь столь любезен,

Не буду.
Постановка задачи автором топика меня вполне устраивает, как прикрутить к ней ру-токен - не понял.
Будь столь любезен, объясни. Заранее спасибо.

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

> Нат © (28.05.09 03:33) [30]
> В любом случа полезно задавать некоротый интервал
> простоя, по истечении выдавать предупреждение, и если не
> проявиться активность, то еще через 10..60сек закрывать
> софтину с/без сохранения.

На счёт периодического опроса - это, скорее всего, нужно делать.
Только вот закрывать без сохранения - это слишком радикально ИМХО. Что делать, если ключ сломался (крайность конечно, но вдруг)? Допустим, идёт длительный процесс вычислений, внезапно ключ выходит из строя (программа не может его обнаружить), программа говорит пользователю "Или даёшь ключ или я закрываюсь через ... сек. Про результаты можешь забыть." Можно понять, если отрубается электричество, но когда тебе намеренно такую хрюшку подкладывают - это нехорошо. Думаю, один разок (или N раз) нужно позволить таки сохранить результаты (ну или произвести ряд действий - в общем случае), а уж потом более жёсткие меры предпринимать, предупредив пользователя.
С другой стороны, если конкретных оговорок по части реализации "защиты" нет, то можно навязать свои ограничения. Вы хотели защиту - получите, только учтите, что необходимо выполнять следующие требования: ...

> KSergey © (28.05.09 08:27) [33]

RuToken есть ничто иное как отечественная реализация основной концепции и технологии, запатентованной в прошлом веке алладинами под маркой eToken USB

Здесь можно почитать сжато и на "огурцах":

http://mf.grsu.by/UchProc/livak/kursi/zaschita/aparzas.htm

см. "Аутентификация пользователя"

> [32] KSergey © (28.05.09 08:23)
> > AndreyV © (28.05.09 03:48) [31]
> > Хреновая метода - ты навязываешь пользователю свой интервал/график
> курения,
>
> Магазины тоже работают от и до и у кассира регламентированные
> перерывы. Беды нет никакой.

Магазин не твоя собственность, а если твоя и будет самостоятельно закрываться в час Ч, при отсутствии покупателей, или ещё по какой блажи разработчика магазаина?

> Разумеется зависит от конкретной ситуации и потребностей
> заказчика. Сделат интервалы настраиваемыми - легко.

Бесконечными?

Отличная метода.
Нечего оставлять секретные проги без присмотра,
нечего блокировать записи.
Ушел курить, ушла пить кофе - выходи из системы.
Обратите внимание, как выходить указан выбор:

> с/без сохранения

ибо в каждой задаче свои требования.
Первое время манагеры в ярости.
Так что ж. Не все сервисы и примочки для их удобства.
Им вообще не нужна база. Они клиентов в блокнотиках держат.
И уходят вместе с блокнотиками... если нет жестких рамок.

> Нат © (29.05.09 03:01) [38]
> Первое время манагеры в ярости.
> Так что ж. Не все сервисы и примочки для их удобства.

Все же надо всегда находить компромиссы и решать чья деятельность важнее для фирмы.
Если манагер приносит деньги - не стоит ему вставлять палки в колеса. Если директор хочет нажатием волшебной кнопки видеть все циферки на экране (мечта всех виденных мною директоров!) - значит надо нанять девочку, котрая будет из манагерских блокнотов перебивать данные в базу для подсчета директорских цифрь.
Но лучше - сделать в проге сервис на самом деле удобный манагерам, чтобы за набивание цифирек они получали полезную для себя инфу. И сразу их отношение изменится.
Но это не по теме.

> AndreyV © (28.05.09 11:07) [37]
> > заказчика. Сделат интервалы настраиваемыми - легко.
> Бесконечными?

Увы, количество энергии во вселенной - конечная величина. Шарики в подшипнике вентилятора тоже не вечны.
А вот достаточно большим (так, чтобы о нем и не догадывались) - запросто. Или отключить проверку.

Программно-аппаратная защита Найти похожие ветки