Введение

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

1. зашифровать файл / массив байт

2. расшифровать файл / массив байт

3. поставить «электронную подпись» на файл (обьясню, почему в кавычках) / массив байт

4. проверить «электронную подпись» файла / массив байт

Массив байт присутсвует в требованиях, потому что часто приходится информацию хранить не в виде файлов, а виде массива байтов в каком‑нибудь хранилище, которое не файловая система( например специальное поле записи базы данных).

Шифрование

Сам термин шифрование описывать подробно не буду, так как он понятен. Само шифрование должно быть стойким. Это означает: расшифровка информации занимает огромное время, чтобы после расшифровки пропала ценность этой информации. Т.е теоретически расшифровать можно всё, вопрос стоит только в потраченном на этот процесс времени. В самой JAVA есть спецификации по этой теме: Java Cryptography Architecture (JCA) и Java Сryptography Extension (JCE) и удобные библиотеки, реализующие эти спецификации, например bouncycastle.

Существуют два основных алгоритма шифрования:

• симметричный алгоритм шифрования (AES)

• ассиметричный алгоритм шифрования (RSA)

В AES используется один ключ, в RSA два ключа(закрытый и публичный) и области применения этих алгоритмов разные.

Хэш-функция, сигнатура, электронная подпись

Тема электронных подписей очень обширная, так как здесь и связь с владельцем подписи. Здесь же появляется и тема сертификатов и много чего другого. Но глобально суть электронных подписей проста. Начнем с понятия хэш‑функции.

Свойства хэш‑функции:

• фиксированный результат длины хэша, независимо от размера источника данных;

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

Самые известные алгоритмы реализации хэш‑функций: MD5, SHA, KeydHashAlgorithm и др. MD5 в настоящее время для серьезных задач практически не используется, так как уязвим и имеет самую высокую вероятность среди подобных алгоритмов по получению одинаковых хеш‑сумм для разных объектов.

Реализация

Сервис будем реализовать на Kotlin и Micronaut. Далее в статье будут описания и мои личные субьективные предпочтения, которые совсем не претендуют на абсолютную правоту.

Почему Kotlin

Недавно пришлось исследовать реализацию ГОСТ‑подписей. Все примеры были на JAVA. Код, который я потом переписал на Kotlin, был раза в полтора‑два меньше по обьему кода на Java и, на мой взгляд, более «чистый». Еще раз напомню, что это моё личное предпочтение и прошу не начинать в комментариях «религиозных» дискусий на тему какой язык программирования лучше. Моё субьективное мнение — самый лучший язык програмирования — это С++ ?, но так как на нём очень немногие программисты умеют писать безопасные программы, были придуманы языки со сборщиками мусора за программистами ? Прошу извинить за небольшое отклонение от темы.

Возвращемся к Kotlin. У Kotlin масса незаметных удобств, к тому же он null‑безопасен как язык программирования из «коробки». Надеюсь этот раздел подвинет Java‑разработчиков «попробовать» Kotlin. В IntelliJ IDEA есть мастер, который великолепно умеет конвертировать Java в Kotlin.

Почему Micronaut

Столкнулся с огромной проблемой на Spring Boot при подготовке дистрибутивов, где сборка нативная (не байт‑код, а уже целевой исполняемый код). Наверное, многие слышали что у нас, любителей разных JVM теперь есть такая возможность. Например, GraalVM нам в помощь. В нативный вид приложения Spring Boot хоть и собираются, но частенько собираются чисто «символически», т. е. крашатся в разных местах во время своей работы. Попробуйте разные варианты сборки в нативный вид Spring Boot, работающие с БД на JPA. Спасибо глабольному использованию чудо техник рефлексии в SpringBoot. Кто еще не интересовался, полюбопытсвуйте как интерфейсы JPA без реализующих их классов волшебным образом имплементируются в классы и объекты в runtime SpringBoot.

Обнаружил, что у Micronaut нет этих проблем, потому что здесь архитектурно другой принцип. При необходимости можем получить и сборку в нативном коде, которая работает прямо из «коробки». Самые сложные конструкции работы с разными БД (PostgreSql, MySQL) тоже работают. При этом Micronaut почти близнец Spring Boot по конструкциям, всё интуитивно понятно. А такой структурированной документации с примерами и описаниями API я ранее не встречал нигде.

Основная часть 

Для Micronaut есть соответсвующий инициализатор в трех видах: 1) командная строка 2) https://micronaut.io/launch 3) Плагины в средах разработки ( я использую IntelliJ IDEA)

Ссылка на рабочий проект в конце статьи.

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

Основные зависимости проекта создаются автоматически инициализатором:

dependencies {
    ksp("io.micronaut.data:micronaut-data-processor")
    ksp("io.micronaut:micronaut-http-validation")
    ksp("io.micronaut.openapi:micronaut-openapi")
    ksp("io.micronaut.serde:micronaut-serde-processor")
    ksp("io.micronaut.validation:micronaut-validation-processor")
    implementation("io.micronaut.reactor:micronaut-reactor-http-client")
    implementation("io.micronaut.kotlin:micronaut-kotlin-runtime")
    implementation("io.micronaut.serde:micronaut-serde-jackson")
    implementation("io.micronaut.validation:micronaut-validation")
    implementation("jakarta.validation:jakarta.validation-api")
    implementation("org.jetbrains.kotlin:kotlin-reflect:${kotlinVersion}")
    implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8:${kotlinVersion}")
    implementation("org.bouncycastle:bcprov-jdk18on:1.77")
    implementation("org.bouncycastle:bcpkix-jdk18on:1.77")
    compileOnly("io.micronaut:micronaut-http-client")
    compileOnly("io.micronaut.openapi:micronaut-openapi-annotations")
    runtimeOnly("ch.qos.logback:logback-classic")
    runtimeOnly("com.fasterxml.jackson.module:jackson-module-kotlin")
    runtimeOnly("org.yaml:snakeyaml")
    testImplementation("io.micronaut:micronaut-http-client")
    testImplementation("org.mockito:mockito-core")
    testImplementation("org.assertj:assertj-core:3.25.3")
}

Обратите внимание, что для работы с криптографией используется библиотеки bouncycastle. Bouncycastle имеет реализацию и наших ГОСТ-овских криптоалгоритмов.

Проект выглядит так:

application.yml:

Для ассимитричных алгоритмов интерфейс:

interface CryptoAsymmetricSigner {
    fun generateKeyPair()
    fun getPublicKey(): PublicKey
    fun getPrivateKey(): PrivateKey
    fun exportKeyPair(fileKeyPem: String, filePublicPem: String)
    fun exportKeyPair(fosKeyPem: FileOutputStream, fosPublicPem: FileOutputStream)
    fun exportPublicKey(fosPublicPem: FileOutputStream)
    fun exportPrivateKey(fosKeyPem: FileOutputStream)
    fun importKeyPair(fileKeyPem: File?, filePublicPem: File?)
    fun importKeyPair(private: ByteArray?, public: ByteArray?)
    fun importPrivateKey(fileKeyPem: File)
    fun importPrivateKey(private: ByteArray)
    fun importPublicKey(filePublicPem: File)
    fun importPublicKey(public: ByteArray)
    fun encrypt(fis: FileInputStream, fos: FileOutputStream)
    fun encrypt(data: ByteArray): ByteArray
    fun decrypt(fis: FileInputStream, fos: FileOutputStream)
    fun decrypt(data: ByteArray): ByteArray
    fun sign(fis: FileInputStream, fos: FileOutputStream)
    fun sign(data: ByteArray): ByteArray
    fun verify(fis: FileInputStream, sig: FileInputStream): Boolean
    fun verify(data: ByteArray, sig: ByteArray): Boolean
}

Специфицировано:

1. генерация ключевой пары

2. экспорт разных комбинаций ключевой пары и элементов

3. импорт разных комбинаций ключевой пары и элементов

4. шифрование файла, массива в памяти

5. дешифпования файла, массива в памяти

6. получение сигнатуры(подписи) на файл, массив в памяти

7. проверка сигнатуры(подписи) на файл, массив в памяти

   Обратите внимание на возможность «комбинаций». Нет необходимости иметь полную пару ключей. Для некоторый операций используется только публичный ключ (шифрование), только приватный ключ(расшифровка).

Для симетричных алгоритмов интерфейс:

interface CryptoSymmetricSigner {
    fun generateKey(size: Int, mode: ModeIv = ModeIv.SIMPLE): SecretKey
    fun getKey(): SecretKey?
    fun exportKey(fos: FileOutputStream)
    fun exportKeyToByteArray(): ByteArray
    fun importKey(fis: FileInputStream)
    fun importIvParameterSpec(bytes: ByteArray)
    fun import(keyFis: FileInputStream, ivFis: FileInputStream)
    fun import(keyBytes: ByteArray, ivBytes: ByteArray)
    fun exportIvParameterSpec(fos: FileOutputStream)
    fun exportIvParameterSpecToByteArray(): ByteArray
    fun importIvParameterSpec(fis: FileInputStream)
    fun importKey(bytes: ByteArray)
    fun encrypt(fis: FileInputStream, fos: FileOutputStream)
    fun encrypt(data: ByteArray): ByteArray
    fun decrypt(fis: FileInputStream, fos: FileOutputStream)
    fun decrypt(data: ByteArray): ByteArray
}

Специфицировано:

1. генерация секретного ключа

2. экспорт секретного ключа и IV

3. импорт секретного ключа и IV

4. шифрование файла, массива в памяти

5. дешифпования файла, массива в памяти

Функция шифрования:

override fun encrypt(data: ByteArray): ByteArray {
        if (publicKey == null) {
            throw CryptoSignerException("The publicKey is uninitialized!")
        }
        val encryptCipher = Cipher.getInstance(DEFAULT_ALGORITHM)
        encryptCipher.init(Cipher.ENCRYPT_MODE, publicKey)
        return encryptCipher.doFinal(data)
    }

Функция дешифрования:

override fun decrypt(fis: FileInputStream, fos: FileOutputStream) {
        if (privateKey == null) {
            throw CryptoSignerException("The privateKey is uninitialized!")
        }
        val data = fis.readAllBytes()
        val decData = decrypt(data)
        fos.write(decData)
    }

Функция расчета подписи/сигнатуры:

override fun sign(data: ByteArray): ByteArray {
        if (privateKey == null) {
            throw CryptoSignerException("The privateKey is uninitialized!")
        }
        val signature = Signature.getInstance(DEFAULT_SIGNATURE_ALGORITHM)
        signature.initSign(privateKey)
        signature.update(data)
        return signature.sign()
    }

Функция проверки подписи/сигнатуры:

override fun verify(data: ByteArray, sig: ByteArray): Boolean {
        if (publicKey == null) {
            throw CryptoSignerException("The publicKey is uninitialized!")
        }
        val signature = Signature.getInstance(DEFAULT_SIGNATURE_ALGORITHM)
        signature.initVerify(publicKey)
        signature.update(data)
        return signature.verify(sig)
    }

Реализация Controller-а 

В реализации контроллера, на мой взгляд, тоже много чего интересного. Особенно с входными и выходными стримами(файлами). Например, прием конкретно двух файлов на обработку (не массива файлов, а именно конкретного количества). И чтобы при этом «swagger» эту ситуацию корректно визуализировал. Для SpringBoot и его «swagger» довольно проблемная ситуация.

@Post(
        value = "/import/key-pair",
        consumes = [MediaType.MULTIPART_FORM_DATA],
        produces = [MediaType.TEXT_PLAIN]
    )
    @Operation(
        summary = "Import Key Pair",
        description = "Attention! Dangerous operation! Shown for educational purposes!"
    )
    @Tag(name = "import")
    fun importKeyPair(
        @Part("public") public: CompletedFileUpload,
        @Part("private") private: CompletedFileUpload
    ): HttpResponse<Any> {
        cryptoService.importKeyPair(private.inputStream.readAllBytes(), public.inputStream.readAllBytes())
        return HttpResponse.ok()
    }

@Post(
        value = "/verify-sign",
        consumes = [MediaType.MULTIPART_FORM_DATA],
        produces = [MediaType.APPLICATION_JSON]
    )
    @Operation(
        summary = "Verify file signature",
    )
    @Tag(name = "sign")
    fun verify(
        @Part("data") data: CompletedFileUpload,
        @Part("sig") sig: CompletedFileUpload
    ): HttpResponse<Boolean> {
        val verify = cryptoService.verify(data.bytes, sig.bytes)
        log.debug("verify is $verify")
        return HttpResponse.ok(verify)
    }

Возврат результата в виде выходного стрима:

@Post(
        value = "/sign-file",
        consumes = [MediaType.MULTIPART_FORM_DATA],
        produces = [MediaType.APPLICATION_OCTET_STREAM]
    )
    @Operation(
        summary = "Calculate file signature",
    )
    @Tag(name = "sign")
    fun sign(data: CompletedFileUpload): StreamedFile {
        val inputStream = cryptoService.sign(data.bytes).inputStream()
        return StreamedFile(inputStream, MediaType.APPLICATION_OCTET_STREAM_TYPE)
    }

Работа сервиса 

Запуск сервиса в обычном режиме:

Я откомпилировал приложение в нативный вид и упаковал в докер‑образ «pawga777/crypto:latest». Докер образ можете скачать из docker‑hub.

Запустим приложение:

Обратите внимание на разницу времени старта: 85 ms нативно откомплированной версии против 1390 ms JVM‑версии Micronaut. Впечатляет? Аналогичная версия на JVM‑версии SpringBoot стартует еще дольше (порядка 2000 ms), так как SpringBoot по своей «природе» медленнее Micronaut.

Давайте немного потестируем.

Зашифруем файл размеров 8 М

Аналогично, расшифруем:

curl -X 'POST' \
  'https://localhost:8443/crypto/symmetric-decrypt-file' \
  -H 'accept: application/octet-stream' \
  -H 'Content-Type: multipart/form-data' \
  -F 'data=@Cryptography_and_Cryptanalysis_in_Java.enc'

Cryptography_and_Cryptanalysis_in_Java.pdf — оригинал

Cryptography_and_Cryptanalysis_in_Java.enc — зашифрованный файл

Cryptography_and_Cryptanalysis_in_Java_enc.pdf — дешифрованная версия

Теперь давайте получим сигнатуру(электронную подпись) файла.

curl -X 'POST' \
  'https://localhost:8443/crypto/sign-file' \
  -H 'accept: application/octet-stream' \
  -H 'Content-Type: multipart/form-data' \
  -F 'data=@Cryptography_and_Cryptanalysis_in_Java.pdf;type=application/pdf'

Проверим полученную электронную подпись:

Эпилог

Код приложения можно скачать отсюда: код приложения на github.

Кому любопытно, посмотрите тесты из bouncycastle для гостовских криптоалгоритмов, тесты перевел на Kotlin и добавил в раздел «тесты» приложения (к самому приложению эти тесты отношение пока не имеют).

Если у кого будет время, или есть уже такая информация, а именно как «отторгнуть» гостовские криптоалгоритмы от их контейнерной среды (КРИПТО ПРО...) — поделитесь. На эту тему нашел интересную реализацию: esia‑crypto. Но повторить «подвиг» в виде «keystore.jks», в котором гостовские ключи хранятся в отдельном контейнере, мне не удалось.

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

По теме Micronaut планирую описать опыт работы с базами данных (PostgreSQL) в реактивном исполнении, в том числе и на корутинах. Все работает замечательно и в нативно откомпилированном виде, и в обычном. Но есть нюансы настроек такого «нативного» приложения для работы из среды докер‑образов. Постараюсь рассказать.

Всем прочитавшим до конца мою статью — спасибо.

Happy Coding!