Электронная подпись в IoT

К 2020 году Gartner обещает 26 миллиардов "умных устройств", построенных, в большинстве своём, на проприетарных копеешных аппаратных платформах и лишенных возможности установки обновлений безопасности. Как мы будем обеспечивать защиту каналов связи в таком зоопарке?


Цели защиты канала связи может быть две: обеспечение целостности и конфиденциальности.

Конфиденциальность обеспечивается с помощью симметричного шифрования (например, AES256). Даётся она практически бесплатно за счёт аппаратной реализации AES, при этом трафик растёт незначительно, криптостойкость высокая, технология обкатанная. Симметричное шифрование сводит проблему защиты канала связи к проблеме обеспечения секретности ключа, которая, к сожалению, в мире IoT не решаема. Если секретный ключ один на все устройства, то велик шанс его утечки. Даже лицензионное соглашение и NDA не спасут.

Поэтому необходим обмен сессионными ключами и электронная подпись для защиты от MITM.

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



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

Чтобы обойти эти ограничения, изобретают новые варианты криптоалгоритмов:

• Патентованный Algebraic Eraser, который на днях раскритиковали и который значительно экономит клиентские ресурсы;
• ISO/IEC 9796-2:2002, который используется в банковских чипах EMV. Главная его особенность - размер подписи ~22 байта (правда подпись неотчуждаема от сообщения);
• TESLA Broadcast Authentication Protocol, который использует перевернутые цепочки хэшей для подписи (интересная идея!);
• и другие...

Проще всего, правда, использовать ECDSA из самого популярного стека протоколов OpenSSL. Это популярная криптобиблиотека, которая используется почти везде, начиная от отечественных криптошлюзов и заканчивая криптовалютами. Кроме того, ECDSA с набором популярных кривых реализована во многих HSM.

Базовый синтаксис для командной строки выглядит так:
Сгенерировать приватный ключ
openssl ecparam -out private.pem -name prime256v1 -genkey
Сгенерировать публичный ключ
openssl ec -in private.pem -pubout -out public.pem
Подписать
openssl dgst -ecdsa-with-SHA1 -sign private.pem test.txt > signature.bin
Проверить подпись
openssl dgst -ecdsa-with-SHA1 -verify public.pem -signature signature.bin test.txt

Замерить скорость:
openssl speed ecdsap256

Размер подписи зависит напрямую от выбранной кривой (посмотреть все доступные кривые можно командой openssl ecparam -list_curves) и уменьшить его нельзя (можно сэкономить 1-2 байта на кодировке, потеряв совместимость).

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

• Эллиптическая кривая secp109 (109 бит) была взломана в 2002 (10 000 PC, 549 дней);
• Кривая 112бит была взломана в 2009 (3.5 месяца на кластере из 200 PS3);
• Чтобы взломать 131 бит необходимо 4 * 10^5 ядролет для AMD Phenom 9500 (с возможным сокращением времени на 25% для некоторых кривых);
• Эллиптическая кривая secp160k1 считается достаточной по стойкости до 2020 года;
• Кривая secp256k1 (openssl обзывает её prime256k1) является стандартом де-факто в мире ECDSA (биткоин активно ее использует);
• Кривая secp384 рекомендована NSA для защиты до уровня "сов.секретно".

Если размер подписи является определяющим параметром - то криптопротоколы типа TESLA, использующие хэш в качестве подписи, являются привлекательным решением, так как хэш может быть обрезан до любой необходимой вам длины (потеряв при этом, естественно, в стойкости). RSA/ECDSA подпись, к сожалению, обрезана/архивирована быть не может.

Ещё одна проблема ECDSA (да и многих других алгоритмов ЭП в т.ч. ГОСТ 34.10-2012) - наличие правильного генератора случайных чисел (PRNG, ГСЧ), который в IoT взять проблематично. В ECDSA генератор случайных чисел используются не только при генерации ключевой пары, но и при каждой подписи. Причём известно, как минимум, уже две атаки, которые серьезно подорвали доверие к ECDSA (хотя косяк то был на стороне программистов): взлом PS3, кража биткоинов с Android кошельков. Существует модификация ECDSA (RFC6979), которая обходится без случайных чисел при подписи сообщений, но она в настоящий момент не распространена.

Большой вопрос касательно электронной подписи - это устойчивость к квантовому криптоанализу. Это, к счастью, неактуально ещё сегодня, но может быть актуальным (а может и не быть) через лет эдак 50, но про это в следующий раз.