Причины отсутствия нормальной криптографии в противоугонных системах — это больная тема, достойная отдельной теории заговора. Видимо, там сошлись воедино инерция рынка, патентные коллизии пополам с синдромом "not invented here" и квалификацией разработчиков, традиционная для отрасли парадигма "security through obscurity", высокие затраты на разработку при жестокой конкуренции, агрессивный risk management а ля "в среднем и так сойдет", и т.д.
Вендоры скрывают код не от владельцев устройств, а от конкурентов и прочих игроков, которые могут использовать найденные в нем фичи и баги по собственному усмотрению. А тот факт, что те же ME/AMT/… обладают de facto функциональностью бэкдора, это, на минуточку, открытая информация, они для этого и создавались. Вот в смартфонах последнего поколения, помимо пользовательской ОС, присутствует ещё чуть ли не с полдесятка полноценных операционных систем, например, почему же никто не поднимает шум по этому поводу?
Проблема доверенной загрузки вызвана, в первую очередь:
реальными зловредами-буткитами;
реальными злоумышленниками с кратковременным физическим доступом к железу ("evil maid attack");
необходимостью обеспечения trusted path functionality для критически важных операций типа ввода пароля для полнодискового шифрования.
К паранойе и/или копирастии это отношения не имеет. Все серьезные вендоры давно уже не борются с опенсорсом, а всячески его приветсвуют, т.к. он прямо и косвенно экономит им деньги и повышает лояльность пользователей.
Реплику описанного в статье устройства в музее таки включают/выключают, но делают это очень медленно и контролируют температурный режим, см. материал, откуда позаимствованы фотографии: http://www.benryves.com/gallery/bletchley
Лампы очень не любят перепадов температуры, к примеру, из-за температурных напряжений в местах контакта стекла и металла. Перепады температуры во времени (на самом деле, любой серьезный градиент температуры, например, из-за неразумной системы охлаждения) — температурные напряжения — микротрещины — нарушение вакуума — раскаленные электроды реагируют с кислородом — отказ.
Для ламп даже специальные марки стекол и сплавов создавали в свое время, чтобы уравнять коэффициенты температурного расширения у элементов конструкции, регламентировали режимы прогрева-охлаждения при включении-выключении и т.д.
То же самое справедливо и для электродов ламп, особенно в местах их сварки с выводами (т.к. контакт двух металлов).
Кроме того, лампы чувствительны к перепадам напряжения (срок службы лампы накаливанияпропорционален напряжению в минус шестнадцатой степени). Учитывая зависимость электрического сопротивления проводников от температуры, получаем ещё одну проблему.
А так, однажды нагретый докрасна электрод в лампе, который никто не трогает, при постоянной температуре и без «протечек» ваккумной колбы может спокойно работать десятилетиями (сотни тысяч часов, рекорд у лампы в передатчике Би-би-си, 232 000 часов). Самой старой рабочей лампе накаливания больше ста лет непрерывной работы.
Боюсь, Вы просто не знакомы с темой защиты кода от реверсинга.
Язык высокого уровня тут вообще ни при чем, «вообще» — от слова «совсем».
Хакеры работают с машинным кодом.
Хоть Вы там вложенный интерпретатор Smalltalk'а на Smalltalk'е сто раз подряд реализуйте — это только несколько затруднит процесс разбора (придется написать кучу скриптов и их отладить на кошках).
1) Не первый десяток лет для защиты бинарников их код транслируют из машинного кода целевой архитекутры в машинные коды специальных обфусцированных VM. Самый известный пример: VMProtect (с 2000 года по наши дни).
2) Референсная реализация VM любого интерпретируемого языка заведомо проще, чем такие специализированные VM более-менее современных «пакеров»/«протекторов». Машина SmallTalk — детский лепет по сравнению с тем же VMProtect (у которого в последних версиях набор инструкций уникален для каждого бинарника, например).
3) Но и их, при всей их сложности, успешно исследуют и далее ломают с самого начала; ломали, ломают и ломать будут. Некоторый код в любом случае выполняется целевым железом, значит, его можно на уровне железа сдампить и вручную выполнить, а значит, и понять. Увидели там виртуальную машину? ОК, пошагово разобрали ее, ее архитектуру, набор инструкций и т.д. То, что долго делать руками, давно и успешно автоматизируется.
4) Единственный относительно надежный способ защиты кода от исследования — особая целевая архитектура с шифрованием «на кристалле».
Это реальная железная машина, напрямую выполняющая зашифрованный машинный код, ключи расшифрования для которого не покидают ее защищенную память. В идеале, ключи уникальны для каждого процессора и для каждого бинарника.
О защите кода начали задумываться еще в семидесятые-восьмидесятые, основные идеи можно найти в статьях того времени, да и этот вывод там тоже есть:
Best R. M. Preventing software piracy with crypto-microprocessors //Proceedings of IEEE Spring COMPCON. – 1980. – Т. 80. – С. 466-469.
На практике нечто отдаленно похожее сейчас массово (~миллиард штук) реализовано в банковских чиповых картах стандарта EMV. На карту от банка-эмитента может прийти зашифрованный issuer script, который содержит, на самом деле, не машинный код, а простенькие аппликационные команды вида «разблокировать оффлайн PIN» или «установить тег X в значение Y», но ключ шифрования, которым закрыты эти команды, знает только карта и банк.
Да, по рельсам течет ток. И в городском трамвае — тоже. Одного контактного провода сверху недостаточно.
Ток течет по кругу! Иначе никак. От источника до потребителя И от потребителя к источнику.
В классических отечественных сетях: где ходят электрички — там по обоим рельсам ток течет обратно к тяговой подстанции, которая питает данный участок пути.
В статье совершенно не встречаются термины «злоумышленник» или «нарушитель» или их аналоги, «угроза» упоминается всего один раз и без комментариев, а уязвимость, оказывается, сама по себе "… может нанести вред, то есть реализовать риск"!
Это настолько печально, что всё вместе начинающему скорее повредит, чем поможет.
Вот только несколько моментов:
1) Сначала всегда строится модель системы (в первую очередь, защищаемых активов) и модель нарушителя (и угроз), потом все остальное. Иначе о безопасности говорить бессмысленно. Совершенно естественная цепочка вопросов "ЧТО ЕСТЬ (у нас)? --> КТО ЕСТЬ (не у нас)? + ЗАЧЕМ (они нас будут атаковать)? --> КАК (это может произойти и через какие дыры у нас)? --> ЧТО ДЕЛАТЬ (чтобы меньше страдать)?" отлично описывает одну итерацию управления ИБ.
2) Вред наносит только злоумышленник или иная активная сущность/явление (да хоть бы и потоп). Уязвимость вреда не наносит (пример: пятка у Ахилла как изъян в его защите). Потенциально вредоносное воздействие — это угроза. Не путать с атакой (см. далее).
3) Риск — вероятность совмещения угрозы и уязвимости
4) Атака — реализация угрозы через уязвимость, т.е. факт осуществления риска в реальности.
Мы храним сертификаты на физическом токене. Чего и вам желаем.
Вот это грамотное решение, ведь преимущества использования токенов в подавляющем большинстве случаев перевешивают их недостатки.
Секретные ключи для сертификатов верхних уровней во внутренней иерархии PKI в организации вообще не должны покидать защищенных носителей (и подпись дочерних сертификатов тоже должна выполняться внутри самого криптоустройства).
А чтобы получить консоль на M92 по USB, коллеги любезно собрали под нее модуль ядра gadget serial: распаковать архив на SD, включить книжку с SD, запустить start_usb_serial.oar, затем при подключении USB к ПК в появившемся на книжке диалоге cказать «No»: www.mobileread.com/forums/showpost.php?p=1951689&postcount=5 (http://www.peeep.us/873412e5)
Дело не в плохом коде, а в архитектурных косяках и болезнях роста. Нет человеческих масштабируемости и многопоточности. Железобетонный MVC-каркас, который проще выкинуть и забыть, чем согнуть и допилить. Даже моей закаленной годами реверсинга и низкоуровневой отладки психике тяжело далось впервые наблюдать dependency hell из-за гемов с нативным кодом.
Ну и никто вообще не думал о безопасности года эдак до 2012, что удручает, мягко говоря.
Все плюсы рельсовой экосистемы становятся не такими уж и вкусными, когда посмотришь, как оно реализовано внутри, и как используется. Буэээ.
И конечно же жаль, что умер сайт www.didrailshaveamajorsecurityflawtoday.com/
Я просто сделал выжимку, а если мы с Вами будем дальше уточнять из нее каждый пункт, то ветка утонет в обсуждениях :)
2) см п.8. МПС может проверить криптовеличины или вообще авторизовать транзакцию. Подробности сервисов МПС едва ли кому-то интересны.
3) да, сплошные упрощения, а то можно еще вспомнить про TSP (Transformed Security Parameter) и найти какую-нибудь реализацию, в которой TSP всегда равен PIN-блоку, например.
5) эмитенту при определенных условиях, strong business needs и наличии адекватных compensating controls можно многое. При использовании HSM корректно зашированные значения почти любых данных на стороне эмитента можно смело печатать на столбах, и PCI SSC это прекрасно понимает.
Про упомнятуый «offset» — попробуйте набросать схему смены PIN по магнитным картам, при которой в БД не хранится ни PIN, ни старый, ни новый PVV для нового PIN. Ответом (рекомендуемым платежными системами) будет хранение некоторой функции-разности «offset», позволяющей посчитать новый PVV на стороне эмитента из хранящегося offset, входящего PVV с трека и входящего PIN-блока.
8) да, упростил.
Проверка PIN для эмитента карты — это один из методов проверки держателя карты (Cardholder Verification Method).
Для магнитных карт PIN всегда проверяет хост (процессинговое ПО на стороне эмитента).
Магнитные карты имеют на треке PVV — ключевой хэш от комбинации PAN и PIN на DES-ключе. 3-DES тут просто не нужен из-за длины PIN, длины PVV и ограничения на число ввода неверного PIN.
Передаваемый от терминала до эмитента карты PIN летит в виде зашифрованного (уже скорее под 3-DES, чем под DES) значения PIN Block (функция от PAN и PIN), коих встречается несколько форматов (от чистого PIN до PIN xor PAN и т.д.).
Эмитент, получив PIN Block, при помощи черного ящика HSM и зашифрованных данных в своей БД может сделать что-либо из:
посчитать по нему PVV и сравнить его с прилетевшим рядом либо хранящимся в БД значением PVV с трека;
сравнить его с тем PIN Block, что хранится в БД (или посчитать PIN Block по хранящемуся в БД PIN и сравнить с прилетевшим);
из него и прилетевшего рядом PVV с трека, и хранящегося в БД PIN Offset (не путать с IBM PIN Offset) проверить прилетевший PIN Block (по PAN и PIN Offset восстановить PIN нельзя, это некоторая разность);
Помимо этого, чиповые карты могут еще и проверять PIN сами, т.к. в защищенной памяти на чипе может быть записано много чего интересного.
Для этого чиповая карта запрашивает у терминала (проверяет то, что получила, а при случае или сразу сообщает об этом хосту эмитента):
или сам PIN в чистом виде;
или он же, но зашифрованный на её открытом ключе;
Роль эмитента при авторизации может брать на себя платежная система (если эмитент недоступен или не умеет проверять определенные данные), естественно, за деньги. Этот сервис называется STIP (STand-In Processing).
Процес смены PIN — это отдельная песня, упомянем только то, что по понятным причинам магнитный трек и PVV на нем никто не трогает, а у чиповых карт есть два потенциально разных PIN, онлайновый (проверяет эмитент при наличии связи с ним) и оффлайновый (проверяет сама карта)
Я готов реализовать схему из статьи «New Encryption System Architecture for Image Transmission» и затем провести на нее атаку, с публикацией всех исходников, тестовых ключей, шифртекстов под тестовыми ключами и т.д.
Я не вижу смысла при обсуждении данной темы скрывать хоть что-то, кроме конкурсного ключа.
Иначе любые слова (а тем более попытки решения) будут пустой тратой времени.
Здесь так много недопонимания, что в два слова не расплести.
1) На Ваших условиях едва ли кто будет пытаться сломать Вашу реализацию данного алгоритма. Т.к. в основе исходной криптосистемы лежит довольно странный, мягко говоря, подход. И у авторов после первого раунда в работе шифртекст от картинки почти не изменился. И синус всего лишь превратился в слегка зашумленный синус. У применяющихся на практике криптосистем число раундов только снижает криптостойкость на порядки, но не полностью, не позволяет извлекать полезную информацию из шифртекста невооруженным глазом!
2) Нельзя оправдывать стойкость криптосистем конкурсами. Вообще. Никогда. www.schneier.com/crypto-gram-9812.html#contests
Простите, не мог знать, что Вы ждали скорого ответа. Поясню, о чем я:
1) Атаковать just for fun неизвестную реализацию криптосистемы в одиночку никто в здравом уме не согласится. В реальности такие задачи решаются многими людьми. Или криптосистема открыта, или никто за нее не возьмется просто так.
2) Принцип Керкгоффса уже полтораста лет как гласит, что стойкость криптосистемы не должна основываться на ее неизвестности. Вы можете добавить к ключу еще стопятьсот параметров, чья энтропия помноженная на длину превышает размер исходного «ключа». Вот только и они сами тогда тоже будут ключом. А криптосистема должна быть практически применимой. Значит, ключ должен легко генерироваться, распространяться и т.д.
3) Если бы Вы действительно хотели бы доказать хотя бы себе сначала стойкость Вашей криптосистемы, Вы бы УЖЕ проделали описанные шаги до написания данного поста. И этой дискуссии сейчас бы не было. Потому что так положено — в процессе создания криптосистемы параллельно проводится доказательство ее эфективности/применимости, проводится ее криптоанализ и приводятся практические оценки ее стойкости и эффективности атак. Так делают все, чьи криптосистемы доживают до массового внедрения.
4) Иначе, нет ни единой причины полагать, что на исходную картинку не наложена гамма из пережатого стомегабайтного скана Вашего кота, севшего на сканер. Чтобы никто и никогда конкурс не выиграл, даже NSA.
Участвовать в этом развлечении имеет смысл только так:
1) Участник повторяет Вашу и Nagase сотоварищи работу на OpenCL (Я готов повторить, если мозг за пять лет после написания курсовой на нем не высох окончательно)
2) Участник публикует исходники, если считает, что понял условия конкурса.
3) Вы компилируете исходники участника и шифруете исходное изображение «flag.bmp» Вашим исходным ключом.
4) Если результат не совпадает с «flagE.bmp», участник снова уточняет у Вас детали формата, количество раундов алгоритма и т.д. и goto этап 1
5) Если результат совпадает с «flagE.bmp», то начинается собственно криптоанализ.
6) Участник получает/не получает результат.
Причины отсутствия нормальной криптографии в противоугонных системах — это больная тема, достойная отдельной теории заговора. Видимо, там сошлись воедино инерция рынка, патентные коллизии пополам с синдромом "not invented here" и квалификацией разработчиков, традиционная для отрасли парадигма "security through obscurity", высокие затраты на разработку при жестокой конкуренции, агрессивный risk management а ля "в среднем и так сойдет", и т.д.
Вендоры скрывают код не от владельцев устройств, а от конкурентов и прочих игроков, которые могут использовать найденные в нем фичи и баги по собственному усмотрению. А тот факт, что те же ME/AMT/… обладают de facto функциональностью бэкдора, это, на минуточку, открытая информация, они для этого и создавались. Вот в смартфонах последнего поколения, помимо пользовательской ОС, присутствует ещё чуть ли не с полдесятка полноценных операционных систем, например, почему же никто не поднимает шум по этому поводу?
Проблема доверенной загрузки вызвана, в первую очередь:
К паранойе и/или копирастии это отношения не имеет. Все серьезные вендоры давно уже не борются с опенсорсом, а всячески его приветсвуют, т.к. он прямо и косвенно экономит им деньги и повышает лояльность пользователей.
Лампы очень не любят перепадов температуры, к примеру, из-за температурных напряжений в местах контакта стекла и металла. Перепады температуры во времени (на самом деле, любой серьезный градиент температуры, например, из-за неразумной системы охлаждения) — температурные напряжения — микротрещины — нарушение вакуума — раскаленные электроды реагируют с кислородом — отказ.
Для ламп даже специальные марки стекол и сплавов создавали в свое время, чтобы уравнять коэффициенты температурного расширения у элементов конструкции, регламентировали режимы прогрева-охлаждения при включении-выключении и т.д.
То же самое справедливо и для электродов ламп, особенно в местах их сварки с выводами (т.к. контакт двух металлов).
Кроме того, лампы чувствительны к перепадам напряжения (срок службы лампы накаливания пропорционален напряжению в минус шестнадцатой степени). Учитывая зависимость электрического сопротивления проводников от температуры, получаем ещё одну проблему.
А так, однажды нагретый докрасна электрод в лампе, который никто не трогает, при постоянной температуре и без «протечек» ваккумной колбы может спокойно работать десятилетиями (сотни тысяч часов, рекорд у лампы в передатчике Би-би-си, 232 000 часов). Самой старой рабочей лампе накаливания больше ста лет непрерывной работы.
Язык высокого уровня тут вообще ни при чем, «вообще» — от слова «совсем».
Хакеры работают с машинным кодом.
Хоть Вы там вложенный интерпретатор Smalltalk'а на Smalltalk'е сто раз подряд реализуйте — это только несколько затруднит процесс разбора (придется написать кучу скриптов и их отладить на кошках).
1) Не первый десяток лет для защиты бинарников их код транслируют из машинного кода целевой архитекутры в машинные коды специальных обфусцированных VM. Самый известный пример: VMProtect (с 2000 года по наши дни).
2) Референсная реализация VM любого интерпретируемого языка заведомо проще, чем такие специализированные VM более-менее современных «пакеров»/«протекторов». Машина SmallTalk — детский лепет по сравнению с тем же VMProtect (у которого в последних версиях набор инструкций уникален для каждого бинарника, например).
3) Но и их, при всей их сложности, успешно исследуют и далее ломают с самого начала; ломали, ломают и ломать будут. Некоторый код в любом случае выполняется целевым железом, значит, его можно на уровне железа сдампить и вручную выполнить, а значит, и понять. Увидели там виртуальную машину? ОК, пошагово разобрали ее, ее архитектуру, набор инструкций и т.д. То, что долго делать руками, давно и успешно автоматизируется.
4) Единственный относительно надежный способ защиты кода от исследования — особая целевая архитектура с шифрованием «на кристалле».
Это реальная железная машина, напрямую выполняющая зашифрованный машинный код, ключи расшифрования для которого не покидают ее защищенную память. В идеале, ключи уникальны для каждого процессора и для каждого бинарника.
О защите кода начали задумываться еще в семидесятые-восьмидесятые, основные идеи можно найти в статьях того времени, да и этот вывод там тоже есть:
На практике нечто отдаленно похожее сейчас массово (~миллиард штук) реализовано в банковских чиповых картах стандарта EMV. На карту от банка-эмитента может прийти зашифрованный issuer script, который содержит, на самом деле, не машинный код, а простенькие аппликационные команды вида «разблокировать оффлайн PIN» или «установить тег X в значение Y», но ключ шифрования, которым закрыты эти команды, знает только карта и банк.
Ток течет по кругу! Иначе никак. От источника до потребителя И от потребителя к источнику.
В классических отечественных сетях: где ходят электрички — там по обоим рельсам ток течет обратно к тяговой подстанции, которая питает данный участок пути.
В результате возможны разные спецэффекты:
https://ru.wikipedia.org/wiki/Блуждающие_токи
Это настолько печально, что всё вместе начинающему скорее повредит, чем поможет.
Вот только несколько моментов:
1) Сначала всегда строится модель системы (в первую очередь, защищаемых активов) и модель нарушителя (и угроз), потом все остальное. Иначе о безопасности говорить бессмысленно. Совершенно естественная цепочка вопросов "ЧТО ЕСТЬ (у нас)? --> КТО ЕСТЬ (не у нас)? + ЗАЧЕМ (они нас будут атаковать)? --> КАК (это может произойти и через какие дыры у нас)? --> ЧТО ДЕЛАТЬ (чтобы меньше страдать)?" отлично описывает одну итерацию управления ИБ.
2) Вред наносит только злоумышленник или иная активная сущность/явление (да хоть бы и потоп). Уязвимость вреда не наносит (пример: пятка у Ахилла как изъян в его защите). Потенциально вредоносное воздействие — это угроза. Не путать с атакой (см. далее).
3) Риск — вероятность совмещения угрозы и уязвимости
4) Атака — реализация угрозы через уязвимость, т.е. факт осуществления риска в реальности.
Вот это грамотное решение, ведь преимущества использования токенов в подавляющем большинстве случаев перевешивают их недостатки.
Секретные ключи для сертификатов верхних уровней во внутренней иерархии PKI в организации вообще не должны покидать защищенных носителей (и подпись дочерних сертификатов тоже должна выполняться внутри самого криптоустройства).
www.mobileread.com/forums/showpost.php?p=1951689&postcount=5 (http://www.peeep.us/873412e5)
Ну и никто вообще не думал о безопасности года эдак до 2012, что удручает, мягко говоря.
И конечно же жаль, что умер сайт www.didrailshaveamajorsecurityflawtoday.com/
2) см п.8. МПС может проверить криптовеличины или вообще авторизовать транзакцию. Подробности сервисов МПС едва ли кому-то интересны.
3) да, сплошные упрощения, а то можно еще вспомнить про TSP (Transformed Security Parameter) и найти какую-нибудь реализацию, в которой TSP всегда равен PIN-блоку, например.
5) эмитенту при определенных условиях, strong business needs и наличии адекватных compensating controls можно многое. При использовании HSM корректно зашированные значения почти любых данных на стороне эмитента можно смело печатать на столбах, и PCI SSC это прекрасно понимает.
Про упомнятуый «offset» — попробуйте набросать схему смены PIN по магнитным картам, при которой в БД не хранится ни PIN, ни старый, ни новый PVV для нового PIN. Ответом (рекомендуемым платежными системами) будет хранение некоторой функции-разности «offset», позволяющей посчитать новый PVV на стороне эмитента из хранящегося offset, входящего PVV с трека и входящего PIN-блока.
8) да, упростил.
Я не вижу смысла при обсуждении данной темы скрывать хоть что-то, кроме конкурсного ключа.
Иначе любые слова (а тем более попытки решения) будут пустой тратой времени.
1) На Ваших условиях едва ли кто будет пытаться сломать Вашу реализацию данного алгоритма. Т.к. в основе исходной криптосистемы лежит довольно странный, мягко говоря, подход. И у авторов после первого раунда в работе шифртекст от картинки почти не изменился. И синус всего лишь превратился в слегка зашумленный синус. У применяющихся на практике криптосистем число раундов только снижает криптостойкость на порядки, но не полностью, не позволяет извлекать полезную информацию из шифртекста невооруженным глазом!
2) Нельзя оправдывать стойкость криптосистем конкурсами. Вообще. Никогда. www.schneier.com/crypto-gram-9812.html#contests
1) Атаковать just for fun неизвестную реализацию криптосистемы в одиночку никто в здравом уме не согласится. В реальности такие задачи решаются многими людьми. Или криптосистема открыта, или никто за нее не возьмется просто так.
2) Принцип Керкгоффса уже полтораста лет как гласит, что стойкость криптосистемы не должна основываться на ее неизвестности. Вы можете добавить к ключу еще стопятьсот параметров, чья энтропия помноженная на длину превышает размер исходного «ключа». Вот только и они сами тогда тоже будут ключом. А криптосистема должна быть практически применимой. Значит, ключ должен легко генерироваться, распространяться и т.д.
3) Если бы Вы действительно хотели бы доказать хотя бы себе сначала стойкость Вашей криптосистемы, Вы бы УЖЕ проделали описанные шаги до написания данного поста. И этой дискуссии сейчас бы не было. Потому что так положено — в процессе создания криптосистемы параллельно проводится доказательство ее эфективности/применимости, проводится ее криптоанализ и приводятся практические оценки ее стойкости и эффективности атак. Так делают все, чьи криптосистемы доживают до массового внедрения.
4) Иначе, нет ни единой причины полагать, что на исходную картинку не наложена гамма из пережатого стомегабайтного скана Вашего кота, севшего на сканер. Чтобы никто и никогда конкурс не выиграл, даже NSA.
1) Участник повторяет Вашу и Nagase сотоварищи работу на OpenCL (Я готов повторить, если мозг за пять лет после написания курсовой на нем не высох окончательно)
2) Участник публикует исходники, если считает, что понял условия конкурса.
3) Вы компилируете исходники участника и шифруете исходное изображение «flag.bmp» Вашим исходным ключом.
4) Если результат не совпадает с «flagE.bmp», участник снова уточняет у Вас детали формата, количество раундов алгоритма и т.д. и goto этап 1
5) Если результат совпадает с «flagE.bmp», то начинается собственно криптоанализ.
6) Участник получает/не получает результат.