Arduino.ru

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

uint8_t nonce[32]; // случайное число
uint8_t signature[64]; // сигнатура, подписанная микрухой

uint8_t status = atcab_random((uint8_t*)&nonce); // получаем хэш случайного числа

CHECK_STATUS(status);

printf("Random from host\r\n");
print_bytes((uint8_t*)&nonce, sizeof(nonce) );

status = atcab_init( &cfg_ateccx08a_i2c_remote );

uint8_t slot = 4; // номер слота, где хранится закрытый ключ?

status = atcab_sign(slot, (const uint8_t*)&nonce, (uint8_t*)&signature); // получаем сигнатуру

CHECK_STATUS(status);

printf("Signature from remote\r\n");

print_bytes((uint8_t*)&signature, sizeof(signature));


uint8_t public_key[] = { // публичный ключ

0x6c, 0x27, 0x16, 0x53, 0xd5, 0xe8, 0x95, 0x35,

0x77, 0x6d, 0xeb, 0x0b, 0x70, 0xc1, 0xbc, 0xd0,

0x8c, 0xfe, 0x06, 0x5e, 0xb0, 0xe6, 0x45, 0x73,

0x81, 0xf4, 0x85, 0x0a, 0x15, 0xe6, 0xfa, 0xc9,

0xbe, 0xf1, 0x00, 0xf4, 0x18, 0xeb, 0xfc, 0x3f,

0x17, 0xa6, 0xb3, 0x27, 0x9b, 0x3f, 0x22, 0x6c,

0xad, 0x85, 0x83, 0xae, 0xd1, 0x7c, 0x74, 0xb8,

0x06, 0x65, 0x6f, 0x1a, 0xc0, 0xc2, 0xee, 0x34,

};

// проверяем публичный ключ
bool verify = false;
status = atcab_verify_extern((const uint8_t*)&nonce,

(const uint8_t*)&signature,

(const uint8_t*)public_key, &verify);

CHECK_STATUS(status);

if(verify)
{
	printf("GOOD!");
}
else
{
	printf("BAD!");
}

Вроде, судя по алгоритму - никакой утечки данных на строну - нет, т.к. идёт обмен хэшами, а закрытый ключ - недоступен, ибо микруха залочена.

Тут есть кто-нибудь, кто работал с этой бестией?

Ну, тут только три человека, которые работали со всем в мире: NMi, rkit и онкель. От кого из них трёх желаешь получить консультацию? ;)

PS. Забыл, что Скиф ещё есть. Но ему МС придётся выслать.

Чота ржу, как конь :))) Блин, реально - уже туплю, а так не хочется целиком даташит читать, аж до зубовного скрежета... Но, видимо, придётся, и будет у мну занятий онанизма ещё на недельку :)

Если под слить имеется в виду скопировать из флеш-памяти МК, то никак. Может только защитить от прошивки неавторизованным кодом.

Вы работали с atsha204a? Можете ответить - я правильно понимаю последовательность действий?

То, что перешьют сам МК другой прошивкой - да пожалуйста, не жалко. Мне просто нужно убедиться, что оригинальная прошивка стоит на той плате, куда вкорячена atsha204a, и всё. Для этого желательно как можно меньше телодвижений, т.е: один публичный ключ, прописанный жёстко в прошивке, и всё. А сами микрухи будут прошиваться отдельно, в них будет вкорячиваться один приватный ключ.

Насколько я понимаю механизм (он изложен кусками кода чуть выше) - то весь алгоритм проверки состоит из нескольких этапов, где:

1. мы просим atsha204a сгенерировать nonce (при этом в нечитаемую секцию TempKey микрухи сохраняется сгенерированный nonce);

2. затем мы для этого nonce получаем от микрухи сигнатуру;

3. затем уже, передавая микрухе наш nonce, сигнатуру, и публичный ключ - мы проверяем, что она нам ответит. Если она сказала, что всё зашибись - можно работать.

Это - что касается проверки на стороне микроконтроллера. Задачу по генерации закрытого ключа и прописывании его в микрухи - специально опустил, это отдельная песня, решаемая отдельным МК со своей прошивкой. Мне главное на данном этапе - понять, в правильном ли направлении двигаюсь.

Что касается "слития" прошивки на сторону - постулируем так: допустим, у вас есть бинарник прошивки (он рассылается клиентам). И вкорячив его на левую плату, сделанную по образу и подобию (даже с atsha204a на борту) - надо добиться неработоспособности прошивки, т.к. проверка на закрытый ключ atsha204a - не пройдёт в этом случае.

Чтобы было более понятней: сейчас защита привязана к уникальному ID МК, и самопальная. Вследствие этого - головняк, когда для каждого МК надо сначала получить его ID (прошить отдельной прошивкой), а потом уже - не забыть, какому клиенту какой ключ назначен. Короче - мутота, сложно, хочется проще, аппаратными средствами, без ввода всяких ключей: продали фирменную плату - на ней работает прошивка, клиент получает обновы. Захотел клиент бинарник закачать на левую плату - отсоси-подвинься, как-то так.

Заранее благодарен за комментарий по теме.

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

Не, не подписка - просто обновы прошивки, и всё. Хай шарят бинарники, не жалко - главное, чтобы они на левых платах не работали. 

Нашёл тут аппноут: http://ww1.microchip.com/downloads/en/Appnotes/doc8753.pdf

Вот шо там пишут:

Since the boot secret is in ROM, it cannot be changed in the field, so its compromise can be published. Nonetheless, it is not the important validation secret, and its publication only permits a certain kind of hardware modification to take place. The ATSHA204 must be preconfigured in the following manner:

1. Store the validating secret in Slot 0 to 7. Set the CheckOnly bit in the configuration section for this slot.
2. Store a boot secret in an odd slot directly after the temp Signature slot. For example, the boot secret is stored in Slot 1 if the Signature will be stored in Slot 0.
3. Enable single use for the slot holding the boot secret and set the corresponding UseFlag to 0, preventing its use for any other purpose.
4. Set ReadKey for the slot holding the boot secret to zero.

The boot program would use the following procedure to take advantage of this capability:

1. The boot program sends the code digest to the NONCE command of the ATSHA204 with mode=3 (pass through).
2. The boot program sends a DeriveKey command to the even Signature slot directly in front of the Boot Secret slot.
   1. The boot program will pass in the Signature slot and the Validating Secret slot.
   2. This will cause the Signature slot to store the Signature of the Hashed code.
3. The boot program sends a random NONCE command to the ATSHA204.
4. The boot program will calculate the random number based on the seed returned from the ATSHA204.
5. The boot program will calculate a MAC command based on the calculated random number and the Signature.
6. The boot program then runs the CheckMac command with mode=1 and ClientResp=MAC response on the Signature slot. If the ATSHA204 returns an affirmative response, then the boot secret is loaded into TempKey. Continue with the following steps to validate this response without putting the device in IDLE or SLEEP.
   1. Generate some type of Challenge that is different for every boot. This could be the current time, a random number, the least-significant bits from an A/D converter, or any other varying value, or a combination of the above. It should be combined in some manner with a system-specific number, such as a serial number.
   2. Execute the MAC command, specifying that the inputs to the digest should include TempKey (the temporary storage location to which the boot secret has been transferred) and the Challenge (generated in the preceding step), which should be passed as the input challenge. The resulting digest calculated by the ATSHA204 is then passed back to the system.
   3. The boot program, which has the boot secret compiled into the code, computes the expected response in hardware or software using the SHA-256 algorithm. If the result of this computation matches the one from the ATSHA204, then normal operation proceeds. Otherwise, the boot code can assume the hardware has been compromised and can take the appropriate actions.

Ппц, теперь всё это надо переварить :)

Получается, что я жёстко тупанул, и ATSHA204 может только в симметричное шифрование (кто бы мог догадаться, если бы посмотрел на SHA в названии :))). Ок, рою дальше, буду оставлять здесь информацию, по мере накопления понимания.

Нашёл статейку: http://ecworld.ru/media/bip/pdfs/krivchenko_ct1015a.pdf

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

Вырезать в корне работу с этой микросхемой из открытого незашифрованного бинарника уже совсем не сложно. Дизассемблируем, заливаем в МК в режиме отладки, находим момент условно return result, после которого система отключается, заменяем на return true. Это не защита.

Это про защиту от неавторизованной прошивки. "method of ensuring that the operating program for a system is authorized, typically by the OEM that designed and built the system"

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

Короче, в голове пока каша с этой микрухой, как её грамотно применить при всех вводных - пока хз. Вот чего точно не хочется - это свой загрузчик шпарить :(

Эмм, недопонял, сорри. Что есть "неавторизованная прошивка"? Как я понял - это как раз про моё применение: убедиться, что программа запускается в окружении, которое спроектировал и сделал автор. Что я неправильно понял - поясните, пж. Видимо, речь в аппноте идёт о системе "загрузчик - авторизованная прошивка", так?Хреново - загрузчик нам не нать сейчас, совсем не в жилу такое.

Прекрасно. А как тебе такой вариант:

В хедере только инициализация стэка, более ничего. В криптере (ну сто комманд на асме) собираем ключик из флешь,еепром или ещё откуда, допустим 8 байт, ни контролек, никаких проверок на валидность. Раскриптовываем ЧАСТЯМИ и тут-же пишем через процедуру в RWW области.

Уотт каг ты такой "кексик" аткусишь, зубастенький ты наш???

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

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

Короче, я пока в ужасе.

На Марс тоже опасно. Россиянское законодательство обязано наказать кого попало и им чаще бывает тот, у кого больше денег, а не воровщик прошивок

Ну вот и у меня щас так: в качестве "кого попало" - оказался я :) Пока не понимаю, чем поможет эта микруха в плане защиты, все примеры - какие-то мутные, безопасности в них - я не вижу ни на йоту, ибо всё сводится к банальным проверкам - либо возвращаемый сигнал с микрухи (ломается кнопочкой железянной, для начала), либо - банальные if, которые тоже откусываются аж за здрасьте.

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

В общем, я попал :)

Я пробежался по аппнотам на микрочипе, общее впечатление, что эта микра для организации канала связи больше. Но сам МК должен находится в контролируемом сегменте. Т.е. если Боб или Алиса просрали девайс, то микросхема им не помощница.

Ну вот что это за пример? https://github.com/sparkfun/SparkFun_ATSHA204_Arduino_Library/blob/V_1.0.0/examples/atsha204_simple_example/atsha204_simple_example.ino

Что я там должен увидеть? Есть challenge жёстко прошитый, есть вот такое:

Serial.println("Sending a MAC Challenge. Response should be:");
Serial.println("23 6 67 0 4F 28 4D 6E 98 62 4 F4 60 A3 E8 75 8A 59 85 A6 79 96 C4 8A 88 46 43 4E B3 DB 58 A4 FB E5 73");

И? Дальше что? Ну ок - выяснил я, что микруха вкорячена и отзывается, провернул я все эти MAC challenge, с рандомными nonce и т.п. Суть где? В конечном итоге - в тупых проверках в прошивке? Смысл тогда во всей этой пляске?

Либо я чего-то не понимаю, либо - одно из двух.

Воот! И у меня складывается подобное впечатление, что реальная применимость этого дела - когда на двух сторонах канала связи - две микры, в которых прошит одинаковый секрет, и всё это дело юзается для подтверждения подлинности сторон.

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

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

они не могут не работать, у вас там момент принятия решения, его быть не должно

Поясните, пж, я сегодня тугой. Это про проверки в прошивке? Если да, то, как писал выше - полностью с этим согласен, это не защита. Осталось донести это до коллеги ;)

Так-то он так, но зачем код расшифровывать? Очередное слабое звено.

Вот когда увидишь в обработчиках интов чототипа LSL, RETI и так много раз, уотт тогда да, ужоснах... а оно работает!

Короче - малой кровью не обойтись, как я понял. Буду думать, как быть - забить на неуловимого Джо, или да :))

В качестве иллюстрации: чтобы сменить прошивку в аппарате SONY, пользователь должен принести его в авторизованный сервис-центр, где специальной программой, которая работает только год и только при наличии HASP-ключа, так же периодически обновляемого, производится заливка этой сраной прошивки )) Если нет хотя-бы одного звена этой цепочки - пользователь идёт лесом.

А как по другому?   Ну давай нахалтай прошивки к ойфонам раздавать?   Этт фсё нитак проста, брЭнд, вот и фсё этим сказано.

Этт вы тут к дурдуинам за 0х00 семечек софты пишете, анинадо.

да, вы выкладываете прошивку, прошивка выполняет функцию по проверке истинности девайса на котором развёрнута и далее ПРОШИВКА принимает решение, это ломается враз...
Принятия решения быть не должно, ключ должен возвращать исполнимые участки кода (функции) и чем их больше тем лучше, знаменитый Cerber я на этом поймал )))

Должно, должно.

Как тебе такой вариант: два ключа по 8 байт. Итого 16, правда?

Берём старшую половину от первого ключа и младшую от второго, ксорим их как хотим, андим по маске b#00001111 и ВЫПИСЫВАЕМ условие, больше или равно СЕМЬ. ДогадайсО, валиден ли ключ???

Да какая разница - валиден он или нет, если результат проверки можно игнорировать.

ВООТТ оно, самое главное!!!

а контроллер какой?

у мну? Их два разных - SAM3X8E и семейство STM32F407. Зоопарк, короче :)

Зоопарк зачётный. Но, помому, там есть OTP ROM AREA , кои позволяют сделать привязку к процу, + там есть CPU_ID_NUMBER, шо позволяет изголяццо над софтом хоть вдоль, хоть поперёк. Прикинем байт к флоат... 256 OTP+CPU_ID= нехилый ключик для крипта, не находите ли?

Не поделитесь ссылочками, что почитать по теме? Оно, конечно, я в гугль умею, но вдруг у вас есть наколки на хороший материал?

З.Ы, На SAM3X8E простенькая привязка к процу реализована, на STM32 - пока вообще голяк с защитой.

вопрос не по теме, а на STM много фукнкций на ассемблер переписали?

я бы добавил в устройство к примеру простенькую пикушку с неизменяемыми функциями, которую залочил, туда основной проц передаёт переменные, оттуда получает результат

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

Нисколько. Так, местами, конечно, секс был, но - без присядки :) Юзаю STM32GENERIC, поставленный с гитхаба - конечно, не без вопросов к этому пакету, но в целом - жить можно, HAL - искаропки, если что. Больше всего проблем с портированием доставила работа с TFT. Ну и OneWire без плясок не заработала.

A у STM-а прошивка не лочица?  Чтоб внешним программатором не прочесть? 

Да, это старая истина, когда шароварил - ей и руководствовался, наряду с поговоркой про неуловимого Джо.

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

Короче - пока думаю, как быть с Джо :) Опять же - исходя из принципа разумной достаточности, чтобы трудозатраты на реализацию защиты не превысили стоимость взлома :))

Деда, прошивка высылается клиентам в виде бинарника, который они ST-Link'ом (разъём на плате есть) шьют на плату, всё. При этом купленную плату - они могут использовать так, как им хочется - хоть гвоздём на стену прибить. А задача стоит следующая: чтобы прошивка работала на купленной плате, а будучи закачана на левую - ругалась. 

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

Ну, если прошивка лочица, я бы клиентам сразу камень продавал, пусть сами вставляют в плату или гвоздём на 200 к стене прибивают.  А вот если плата сама является объектом интеллектуальной собственности, тогда да, нада думать. 

А так, када-то давно, када IQ у меня был больше 50, я защиту по всему .exe тонким слоем по разным местам размазывал.  

Тут дело в механизме обновлений. Пока - реализован только механизм "в лоб", как видишь. В идеале, конечно - через веб с валидацией, https и прочей хероборой - но оно мне точно не надо сейчас, не стоит та овчинка выделки в моих реалиях.

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

Как вариант - использовать в схемотехнике что-то редкое, что не смогут достать 90% целевой аудитории. Какой-нить нестандартный EEPROM для хранения настроек, к примеру, или внешний RAM.

Но это так, идея. На практике я пока не представляю такой микрухи. 

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

На STM32хххх ТОЧНО есть номер у каждого процессора, и он уникален (с даташита). Опять-же за всё семейство не скажу, но, у STM32f4хх есть OTP (One Time Programm) область, куда можно писать всё что вздумывается. Обычно и как правило связка номер проца + дампик с OTP Area используется программистами для защиты ПО. Оно в принципе и описано так в датащах от STM - типа уникальный и тд и тп.

Про "голяк" - я имел в виду, что портирование механизма защиты - не сделано. А применяется как раз уникальный ID проца. Но, как писал выше - это неудобно поставщику плат - каждый раз надо вытаскивать ID проца, прогонять данные через прогу, получать ключи - короче, именно от этого секаса автор плат хочет избавиться. Собственно, поэтому и родилась эта тема.

Ооо... здеся есть место для развернуцца.

ЕЕпром есть в схеме внешний или датчики какие с такой функцией?

Можешь прямо из кода FB вычитывать? То-же неплохой вариант защиты "отдурачка"

Деда, щас так буржуи и делают. Цифравайя потписЪ ща это па саврименному называццо. Уотт.

Внешний EEPROM есть, на I2C. Ваши предложения?