Как стать автором
Обновить

ATSHA204A: маленький гигант большого крипто. Часть 1: ой, какой он у вас маленький

Время на прочтение8 мин
Количество просмотров15K
Всего голосов 75: ↑70 и ↓5+65
Комментарии46

Комментарии 46

Так что запасайтесь микросхемами.

Забавно звучит, вкупе с прогнозом поставок в середине 2022 и начале 2023г на mouser :)

В директе в наличии 200 тыс штук в соик и дфн. Маузер — всего лишь реселлер.

Спасибо, не знал, что они напрямую продают. А вы не знаете, как у них с мелкими партиями?

От 1 шт, но выйдет слишком дорогая доставка. И растамаживать приходится. Попробуйте через питерскую Гамму, у них могут быть в наличии или привезут под заказ.

Спасибо. Я не в России

В том же DigiKey есть в SOIC и UDFN.

Ну, там речь шла именно об ATSHA204A с её специфической процедурой неотменяемой блокировки — если чего-то не учли — чип остаётся только выбросить на помойку (а что-то не учесть очень легко из-за сложности криптографии и конфигурации ATSHA204A).

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

Под IoT лучше подходит STSAFA110 — у неё есть поддержка TLS и вшит заводской CA сертификат. И есть много примеров под STM32, которые в IoT гораздо популярней PIC.

А что лучше всего для аппаратного токена?

Что-нибудь, совместимое со стандартом JavaCard. J3H145, например, но найти такие микросхемы именно в формате микросхем (а не карточки) - это надо потрудиться. Второй вариант - защищенный МК общего назначения.

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

То есть, если каждое устройство имело бы уникальные ключи, его реверс-инжиниринг же не катастрофа в большинстве случаев?

Дело в том, что ATSHA204A — это что-то вроде универсального криптографического комбайна — она позволяет как безопасно хранить ключи и данные (и регламентировать доступ к ним), так и работать с ними на основе SHA-256 в различных сценариях.

Что и как вы будете (сможете) использовать — зависит только от вас (от уровня вашей квалификации).

Сами по себе ключи можно в прошивке фиксануть, нужно именно данные/код туда писать, тем более что там OTP, и делать это грамотно, так как флеш и RAM процессора основные зоны уязвимости.

А как осуществляется обмен по I2С без сигнала SCL в трехногом корпусе ? И какие скорость щифрования у микросхмы ?

Обмен осуществляется по однопроводному SWI интерфейсу, у SparkFun есть соответствующая библиотека для Ардуино SparkFun_ATSHA204_Arduino_Library (там можно посмотреть все подробности реализации).

Специально скорость работы я не замерял, но учитывая, что это аппаратная реализация, то со скоростью проблем не должно быть (можно подробнее посмотреть в даташите).

(Всё это я подробно разберу в последующих статьях цикла.)

А рассказать-то как обмен осуществляется, тут можете в трех словах?

Чипы такого типа мне всегда казались решением в поисках проблемы.

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

Да, проблема микроконтроллера, который принимает решения, остаётся и об этом я специально упомянул в статье. Но это не умаляет достоинств специализированных микросхем и решений на их основе.

«Один ключ на все устройства» — это только гипотетический пример (и об этом тоже специально упомянуто в статье).

Тут всё зависит от задачи. Например, для удалённой аутентификации каких-либо мелких устройств без возможности организовать TLS-канал, вполне достаточно внутренней логики SHA256/HMAC - т.к. запрос каждый раз разный, ломать микроконтроллер нет смысла. А если симметричный ключ прописан в рядом стоящий МК, то и криптостойкость системы тут определяется криптостойкостью МК.

В качестве аппаратного хранилища секретов лучше присмотреться к АТЕСС608 - там и защита канала с микроконтроллером, и ECDH/ECDSA, и более продуманная система аутентификации со счётчиками (например, можно организовать ограниченное число попыток ввода пин-кода для разблокировки нужного ключа, с ATSHA204 такое не сделаешь).

с ATSHA204 такое не сделаешь

А вы хорошо знакомы с ATSHA204? Там же есть аппаратные ячейки с конфигурацией только на уменьшение значений.

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

Да, тут вы правы — OTP ячейки одноразовые и подходят скорее для того, чтобы что-то «заблокировать» окончательно.

Точно не скажу, но насколько я помню, в ATSHA204A есть и возможность произвольно изменять значения битов некоторых слотов.

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

 

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

Raspberry pi ставит этот чип на свои picamera для проверки, что это не китайский клон.

Тоже не очень понятно, в чем смысл использования данной микросхемы?

Хранилище ключей? Так взламают мк или отснифают передачу между ними - канал-то не шифруется.

Логику в нее не перенести.

Транспорт через нее не сделать - вот эта фича была бы самой классной.

Как аутстафф рандомного генератора и криптофункций? А зачем? Скорость разве что, но, обычно, она не сильно важна в ИОТ.

Можно реальный пример применения данной микросхемы?

Смысл и в безопасном хранении ключей и данных и в настраиваемых правилах и в качественном RNG и в OTP зоне и во множестве SHA-ассоциированных функций и т. д. Вот что пишет об этом сам производитель:

The Microchip SHA-based CryptoAuthentication crypto element devices have been architected to provide flexible user-configured security to enable a wide range of authentication models. Secure Hash Algorithm (SHA) algorithms are widely used in most cryptographic systems and remain an important component in most modern authentication protocols. CryptoAuthentication devices in the SHA mode include client and host security capabilities that offload key storage and algorithm execution from the microcontroller, significantly reducing system cost and complexity.

Проблема взлома самого микроконтроллера остаётся, её никто не отменял, но в сочетании с ATSHA204A система будет надёжнее в любом случае.

НЛО прилетело и опубликовало эту надпись здесь

Едва ли не всё, что вы перечислили, есть даже в каком-нибудь бюджетном STM32G0С1

Тут есть 2 момента: во-первых, я не всё перечислил, что есть в ATSHA204A :) , а во-вторых, ATSHA204A — это универсальное решение, которое может использоваться с любыми микроконтроллерами, даже теми у которых нет встроенных развитых криптографических модулей.

Но спорить не буду — я не проводил специального исследования на тему «STM32 vs ATSHA204A», возможно свет на этот вопрос прольёт компетентное хабр-сообщество.

Крипто функции есть во многих микроконтроллерах, но не везде есть NIST RNG, защищенное храниение ключей, тамперы, Active shield across multiple layers, механизмы предотвращения атак по "сторонним" каналам, и пр. Ширпотребовские МК как правило не имеют механизмов предотвращения Microprobe, Timing, Emissions, nvalid command, Power cycling, clock glitches и др. атак. Если погуглить, то найдете сервисы по предоставлению прошивки из МК, но вскрыть чип, например из банковской карты, .. видимо стоит совсем других денег и дешевле осуществить "звонок из фин.мониторинга банка" или применить "терморектальный криптоанализ".

1."Проблема взлома самого микроконтроллера остаётся, её никто не отменял, но в сочетании с ATSHA204A система будет надёжнее в любом случае."
2."даже если в составе в вашего устройства присутствует специализированный крипточип, то уязвимыми по-прежнему остаются как коммуникации этого чипа с микроконтроллером."
Не будет надежнее.
Если в периметре охраняемого объекта присутствует дыра в заборе, шириной 100 метров, то высота и укрепленность остального забора вообще не имеет никакого значения. То ли это будет плетень по пояс, то ли бетонный забор 6 метров высотой с колючкой и током. Защищенность объекта в целом определяется самым слабым участком ограды.
А раз так, то смысл применения этой девайсины не просто нулевой, а отрицательный - она может создать иллюзию повышения безопасности у невнимательного проектировщика.

Смысл в том, что ключ записывается в крипточип один раз производителем и потом достать его оттуда или подменить нереально - интерфейса нет, от физического взлома и записи он защищен.

А дальше - используй ключ, например для подписи запросов. Создавай случайные сессии с RNG, подписывай SHA. Защита в том, что даже если у нас есть точная копия устройства и возможность модификации прошивки, без крипточипа доступ к внешним серсвисам невозможен (например, обновление прошивки). Но как его использовать, если нужно надежно защитить именно саму прошивку - не знаю, надеюсь будут еще примеры в следующих статьях.

Между МК и крипто-чипом не передаются ключи, поэтому снифить там нечего.

ATSHA204A - в основном предназначена для аутентификации расходников, аксессуаров и т.п.

Типовой пример. Путь "принтер" (П) хочет распознать свой "картридж" (К).

В (П) и (К) стоят ATSHA204A с прописанным Secure Key.

По запросу МК в (П) генерируется случайное число (Challenge), отсылает его в (К).

в (К) на основе Challenge и SecureKey вычисляется Hash, который отсылается обратно в (П).

(П) в свою очередь так же вычисляет Hash и сравнивает с Hash из (К).

Микроконтроллер в (П) получает ответ - совпал Hash или нет.

В данном случае в протоколе нет передачи "чувствительной" информации. из Крипто чипа после Lock нет возможности считать ключи.

Вы можете взломать МК в конкретном "Принтере", и заставить (П) принимать любые (К). Но подделать (К), для того чтобы они подходили к любым (П) - это уже challenge ))

Для более сложных use cases есть ATECC506(608).

А в картридже вычислением хэша от challenge и securekey не мк занимается? Т.е. мк скармливает пришедшее в данный микрочип, он вычисляет хэш и отдаёт его мк, и таким образом securekey мк не знает?

Да. Более того, МК в картридже вообще не нужен. Подобные крипто-элементы выпускаются в 3-х выводном корпусе (см. картинку в статье, 3 Lead Contact), он как бы не для монтажа на плату, а для интергации в корпус "расходника". Т.е. в этом случае команды передает МК из "принтера" и верифицирует расходник.

Для расходников еще можно установить счетчик, с каждым обращением счетчик уменьшается и при ==0 расходник блокируется. Например если расходник это картридж с лекарством на N доз. Исчерпали расходник - перезалить лекарство/чернила/etc. уже нельзя, ресурс картриджа/чипа исчерпан.

Спасибо за реальный юзкейс, наверное примерно такое стоило добавить в статью.

Кроме того, этот вариант предназначен для применения в однопроводной схеме, что позволяет экономить (всегда) дефицитные выводы микроконтроллера.

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

Спасобо за статью, жду продолжения!

Очень интересно продолжение: сейчас как раз начинаю разработку IoT для транспорта, где надо будет уделить дополнительное внимание аутентификации модулей системы и информационной безопасности каналов связи. Хочется понять, насколько специализированные криптомикросхемы полезнее того, что предоставляеют криптомодули контроллеров stm32 и nrf52.

Спасибо за информацию о микросхеме. В самом начале чтения ощущалось лёгкое дежавю: где-то я такое уже видел… Точно! DS1961s. Читаю дальше и прихожу восторг — это даже не следующий этап развития, а небо и земля: «Больше! Дальше! Выше!». Уделывает «дедушку» по всем параметрам

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

В варианте с принтером/картриджем это означает, что если кто-то расковыряет ключ, то читай всё пропало.

Для более рельной истории с IoT всё же лучше чтоб криптомодуль умел работать с ассиметричным шифрованием. Тогда Private Key в каждом устройстве уникальный, сертификат подписан приватным ключом, который есть только у производителя девайсов. И даже если кто-то расковыряет один из девайсов и достанет оттуда все ключи, просто отзываем этот сертификат и клонов уже не получится наделать.

Так это и не самый "продвинутый" вариант. Крипточип ATECC608 умеет ассиметричную криптографию

  • Protected storage for up to 16 Keys, certificates or data

  • ECDH: FIPS SP800-56A Elliptic Curve Diffie-Hellman

  • NIST standard P256 elliptic curve support

  • SHA-256 & HMAC hash including off-chip context save/restore

  • AES-128: encrypt/decrypt, galois field multiply for GCM

  • Turnkey PRF/HKDF calculation for TLS 1.2 & 1.3

  • Ephemeral key generation and key agreement in SRAM – Small message encryption with keys entirely protected

  • Full ECDSA code signature validation, optional stored digest/signature – optional communication key disablement prior to secure boot

  • Encryption/Authentication for messages to prevent on-board attacks

  • Internal high-quality FIPS 800-90 A/B/C Random Number Generator (RNG)

  • Two high-endurance monotonic counters

  • Guaranteed unique 72-bit serial number

Мне кажется самый главный вопрос: это технология на которой сделаны OTP. Если там antifuse, которые сложно считать всякими электронными микроскопами, то вот и причина ставить это микруху: часто в чипах OTP идет на обычных пережигаемых перемычках, которые прекрасно видно в электронный микроскоп.

Но быстро пробежав по даташиту я чето вообще не увидел какой-то инфы по поводу антифьюз там или нет.

В микроскоп не увидите. Это не "простой микроконтроллер". Верхние слои рандомизированы слоем активного шилда.

Вот в моей плисине в мануале по OTP(efuse) в таблице сравнения с хранением ключа в BBRAM (микропотребляющая память с питанием от батарейки) среди минусов efuse есть пункт "оставляют доказательства" ("Less secure than BBRAM solution (i.e., the device level evidence remains)"). Возможно конкретно в этой микрухе сделано по-другому. Вы в мануале на нее вычитали, что верхние слои рандомизированы и предприняты меры, чтобы нельзя было увидеть перемычки? Я вот этого там не нашел.

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

Там есть интересная возможность вычисления хэша с учётом уникального серийного номера. У себя в устройствах сделал такую схему защиты от копирования. Несложный rest сервис на java, который получает серийник от устройства при подключении, в ответ генерит челлендж и ждёт хэш. Потом сравнивает и принимает решение, отдавать обновления, блочить устройство итд.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий