Что вы думаете о защите клиент-серверного приложения хаспом?
То есть приложение распространяется в виде комплекта сервера и клиента. Оба написаны на java. Оба должны быть защищены.
Насколько безопасно можно защитить приложение таким способом?
Какие еще решение вы видите?

Спасибо

А>Что вы думаете о защите клиент-серверного приложения хаспом?
А>То есть приложение распространяется в виде комплекта сервера и клиента. Оба написаны на java. Оба должны быть защищены.
А>Насколько безопасно можно защитить приложение таким способом?
А>Какие еще решение вы видите?

А>Спасибо

Прилоежние клиент-сервеное. И клиент и сервер будут доступны пользователю в виде jar файлов.

Здравствуйте, Аноним, Вы писали:

А>Что вы думаете о защите клиент-серверного приложения хаспом?
А>То есть приложение распространяется в виде комплекта сервера и клиента. Оба написаны на java. Оба должны быть защищены.

Хасп позволяет защищать программы на Яве?

Последний раз смотрел на него в 2009-м году, тогда он поддерживал только .NET-овские языки и C++ (если мне не изменяет память).

А>Какие еще решение вы видите?

а) Привязка Ява-программы к аппаратным номерам компа
б) Электронная подпись джарника (signed JAR), программа при каждом запуске проверяет, не было ли попыток взломать/изменить джарник
в) Обфускация кода

Пункт а) может потребовать больших затрат при распространении:

1) Компания-разработчик посылает клиенту утилиту для определения аппаратных номеров
2) Клиент запускает утилиту на компах, где будет установлена программа и отправляет компании-разработчику эти номера
3) Компания-разработчик делает дистрибутив софта, в который вшиты эти номера.
4) Компания-разработчик отправляет клиенту этот дистрибутив.

Естественно, что компания-разработчик должна вести учёт всех аппаратных номеров (у какого клиента какой номер).

Всё это реально сделать (говорю по опыту), но важно просчитать — оправданы ли эти издержки на такую защиту?

Пункт б) относительно прост. И позволяет выдавать временные сертификаты, т. е. клиентское приложение работает только полгода (например).

Успехов

Дмитрий

Дополнения:

1) Теоретически, можно и сам джарник зашифровать.
2) Можно сделать нативный загрузчик классов (classloader) и в него встроить средства защиты Хаспа.

В отличии от предложенных ранее вариантов я это на практике не пробовал.

Успехов

Дмитрий

Здравствуйте, Аноним, Вы писали:

А>Что вы думаете о защите клиент-серверного приложения хаспом?

Лучше использовать SenseLock. У него в нутрях защищённый микропроцессор + память.
Внутрь ключа выносите ЧАСТЬ ваших алгоритмов, что бы их нельзя было ВЫКУСИТЬ из программы.
Иначе вся защита отламывается на раз в джаве с помощью декомпилятора и замены пары инструкций.

Здравствуйте, kuaw26, Вы писали:

K>Здравствуйте, Аноним, Вы писали:

А>>Что вы думаете о защите клиент-серверного приложения хаспом?

K>Лучше использовать SenseLock. У него в нутрях защищённый микропроцессор + память.
K>Внутрь ключа выносите ЧАСТЬ ваших алгоритмов, что бы их нельзя было ВЫКУСИТЬ из программы.
K>Иначе вся защита отламывается на раз в джаве с помощью декомпилятора и замены пары инструкций.

True. Программа ценой в 15к$ ломалась за 2 часа.

Здравствуйте, kuaw26, Вы писали:

K>Здравствуйте, Аноним, Вы писали:

А>>Что вы думаете о защите клиент-серверного приложения хаспом?

K>Лучше использовать SenseLock. У него в нутрях защищённый микропроцессор + память.
K>Внутрь ключа выносите ЧАСТЬ ваших алгоритмов, что бы их нельзя было ВЫКУСИТЬ из программы.
K>Иначе вся защита отламывается на раз в джаве с помощью декомпилятора и замены пары инструкций.


А разве у хаспа нет возможности задавать алгоритм внутренний?

Здравствуйте, m.victor, Вы писали:

MV>Здравствуйте, kuaw26, Вы писали:

K>>Здравствуйте, Аноним, Вы писали:

А>>>Что вы думаете о защите клиент-серверного приложения хаспом?

K>>Лучше использовать SenseLock. У него в нутрях защищённый микропроцессор + память.
K>>Внутрь ключа выносите ЧАСТЬ ваших алгоритмов, что бы их нельзя было ВЫКУСИТЬ из программы.
K>>Иначе вся защита отламывается на раз в джаве с помощью декомпилятора и замены пары инструкций.


MV>А разве у хаспа нет возможности задавать алгоритм внутренний?

чем собственно SenseLock лучше хаспа?

Здравствуйте, kuaw26, Вы писали:

K>Здравствуйте, Аноним, Вы писали:

А>>Что вы думаете о защите клиент-серверного приложения хаспом?

K>Лучше использовать SenseLock. У него в нутрях защищённый микропроцессор + память.
K>Внутрь ключа выносите ЧАСТЬ ваших алгоритмов, что бы их нельзя было ВЫКУСИТЬ из программы.
K>Иначе вся защита отламывается на раз в джаве с помощью декомпилятора и замены пары инструкций.


В senselock можно вынести алгоритм шифрования, а не часть алгоритма приложения.
В итоге получается одно и тоже, условно, в программе есть if проверка на значение в ключе (не важно хасп или senselock), которую достаточно просто убрать при декомпиляции приложения.

Я не прав?

Здравствуйте, Дмитрий Писаренко, Вы писали:


ДП>б) Электронная подпись джарника (signed JAR), программа при каждом запуске проверяет, не было ли попыток взломать/изменить джарник

Спасибо за совет.

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

Здравствуйте, m.victor, Вы писали:

MV>Насколько я понимаю, проверку подписанного jar-ника легко убрать из приложения, путем декомпиляции и удаления проверки даже кода, прошедшего через обфускатор.

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

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

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

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

Можно перенести клиентскую часть в веб (преобразовать свинговое приложение в апплет).

Можно встроить в клиент и/или сервер "заднюю дверь", через которую при необходимости можно выключить это ПО дистанционно. Допустим, у Вас есть перечень клиентов и оплаченные ими сроки пользования Вашим ПО. Если оплаченный срок вышел, а клиент не обратился к Вам за продлением договора, Вы отключаете ему кислород посредством этой задней двери.

Успехов

Дмитрий

Здравствуйте, Дмитрий Писаренко, Вы писали:

ДП>Возможно и так. Лично мне не удавалось разобраться в коде, который прошёл обфускацию.

Скажите, тогда, пожалуйста, что это был за обфускатор?

Здравствуйте, m.victor, Вы писали:

MV>Здравствуйте, Дмитрий Писаренко, Вы писали:

ДП>>Возможно и так. Лично мне не удавалось разобраться в коде, который прошёл обфускацию.

MV>Скажите, тогда, пожалуйста, что это был за обфускатор?

ProGuard

Дмитрий

Здравствуйте, Дмитрий Писаренко, Вы писали:

ДП>Здравствуйте, m.victor, Вы писали:

MV>>Здравствуйте, Дмитрий Писаренко, Вы писали:

ДП>>>Возможно и так. Лично мне не удавалось разобраться в коде, который прошёл обфускацию.

MV>>Скажите, тогда, пожалуйста, что это был за обфускатор?

ДП>ProGuard

ДП>Дмитрий

Спасибо за помощь.

Здравствуйте, m.victor, Вы писали:

MV>В senselock можно вынести алгоритм шифрования, а не часть алгоритма приложения.
MV>В итоге получается одно и тоже, условно, в программе есть if проверка на значение в ключе (не важно хасп или senselock), которую достаточно просто убрать при декомпиляции приложения.

MV>Я не прав?

Совершенно не правы.
В для ключа SenseLock вы можете создавать приложения, которые в ключе хранятся и в нем же выполняются.
Приложения для ключа пишутся на языке Cи, компилируются в бинарник и загружаются в энергонезависимую память ключа.
Senselock является высокозащищенным устройством, и обеспечивает высокую надежность хранения исполняемых модулей внутри себя.
Прочитать исполняемый модуль из ключа без знания 24 байтового PIN кода разработчика невозможно. Перебрать PIN код разработчика не получится. Есть 15 попыток перебора, после которого доступ к ключу по PIN коду разработчика блокируется навсегда.

А>То есть приложение распространяется в виде комплекта сервера и клиента. Оба написаны на java. Оба должны быть защищены.
А>Насколько безопасно можно защитить приложение таким способом?
А>Какие еще решение вы видите?

Возникала похожая задача. Сделал так: использовал WinRun4J — внедрил jar в ресурсы исполняемого файла (конфиг туда же), потом исполняемый exe файл обернул в CodeCover(Shell) от Sentinel SHK. Хотя эта ветка ключей загнулась.

+ Еще есть такая идея:
переопределить класслоадер из WinRun4J, чтобы он сначала расшифровывал jar-файлы логики, шифрованные, скажем DES'ом, а пароль доставать из ключа.