Почему бы не зашифровать байт-код Java вместо того, чтобы его скрывать?

Question

Рассматривая усилия, предпринимаемые некоторыми организациями для обфускации байт-кода Java, чтобы другие не декомпилировали его и не извлекали секретную информацию из кода, принимая во внимание ограничения этой практики):

Не было бы этовозможно ли использовать асимметричное шифрование для решения этой проблемы?Я имею в виду, разве Oracle не сможет оснастить JVM сертификатом и ClassLoader, способным расшифровывать зашифрованные файлы классов, используя закрытый ключ этого сертификата?

Конечно, классы были бы зашифрованы с использованием открытого ключа этого "уникального сертификата оракула" .

Закрытый ключ будет находиться внутри JVM.

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

Answer 1

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

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

Answer 2

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

По сути, да.

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

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

В моем ответе о безопасности ИТ, касающемся эффективных методов защиты DRM, об этом рассказывается чуть подробнее.

Answer 3

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

Answer 4

Не забывайте, что Oracle JVM - не единственная JVM.каждая JVM должна придерживаться стандарта (спецификации виртуальной машины Java), чтобы обеспечить очень простой принцип Java: «пиши один раз, беги куда угодно».такой закрытый ключ может привести к тому, что oracle jvm будет вести себя иначе, чем все другие реализации

Answer 5

Чтобы схему подписи было трудно сломать, ключ должен быть недоступен.

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

Вам может показаться интересной история о получении личного ключа от Airport Express: http://mafipulation.org/blagoblig/2011/04/08#shairport

Answer 6

В любом случае невозможно защитить личный сертификат на клиентском компьютере (например, в JVM).Как вы себе это представляете?Если это был простой текстовый файл, очевидно, что его можно извлечь.Если он был зашифрован, ключ «второго уровня» также должен находиться на клиентском компьютере, чтобы JVM могла использовать частный сертификат для защиты кода.Таким образом, вы сможете извлечь этот ключ и, следовательно, частный сертификат.