Шифрование Java / C ++ и интерфейс JNI - PullRequest
Новая
       19

Шифрование Java / C ++ и интерфейс JNI

3 голосов
/ 05 ноября 2019

Сценарий

Мы разрабатываем приложение, которое использует внешний интерфейс Java и реализует более сложные математические алгоритмы на стороне C ++. Для этой цели существуют функции Java native, реализованные через JNI, для доступа к функциям C ++ через Java.

Проблема

Исторически у нас была проблема, когда все больше и больше учетных данных летали вокруг относительно большой кодовой базы. Почти все это на стороне Java, некоторые настраиваемые учетные данные в специфических файлах конфигурации приложения, последние можно игнорировать по . Сфера действия этого вопроса.

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

  • Сохраните пароли на стороне Java и используйте пакет crypto - все же, алгоритм шифрования может быть идентифицирован и пароль для шифрованиявсе еще должны храниться где-то открыто, так что это может быть относительно легко расшифровано. Кроме того, JAR-файлы относительно хорошо доступны.
  • Сохраните пароли на стороне C ++ и используйте функцию decryptKey, передав ей пароль, расшифровав его на стороне C ++ с помощью закрытого ключа, а затем вернув его в открытом виде. В этом случае JNI становится уязвимостью, потому что легко можно просто создать свой собственный JAR, включить нашу DLL и затем получить доступ к встроенной функции decryptKey для получения простых текстовых паролей.
  • Сдвиг всей логики, зависящей от ключана C ++. Это не имеет большого смысла, потому что мы должны были бы изменить логику там, где она не принадлежит. Кроме того, для некоторых реализаций требуются сторонние API-интерфейсы Java, которым необходимо предоставить учетные данные, поэтому, к сожалению, это не вариант.

Вопрос

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

1 Ответ

4 голосов
/ 05 ноября 2019

Во-первых, ваш продукт должен быть в состоянии интегрироваться с продуктами, которые могут обеспечить безопасность ваших личных ключей. Эти продукты включают TPM, HSM и KMS . Это очень полезно для локальных и облачных сред производства.

Во-вторых, вы должны реализовать механизм шифрование конвертов , где ключ шифрования данных шифруется с помощью мастер-ключа, который будет хранитьсяв TPM / HSM / KMS. Зашифрованный ключ шифрования данных может храниться вместе с данными.

В-третьих, вам следует реализовать поворот ключа , при котором вы время от времени заменяете свои основные ключи / ключи данных.

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

...