SMS получает все же телефон, передавая потом его приложению в команде:
public void processToolkit(byte event) {
…
if (event == EVENT_FORMATTED_SMS_PP_ENV) {
execInputSMS();
}
if (event == EVENT_MENU_SELECTION) {
…
Кусок кода для иллюстрации. И ничего более чем позволяет протокол, приложение в ответ не вернет.
Так что говорить о самостоятельно работающем приложении с потенциально деструктивным кодом на SIM карте — не корректно. Ничего особо деструктивного оно в принципе сделать не может
А много он не позволяет.
Что бы не было недоразумений, разберу цитату Карстен Ноль по фразам:
Мы можем дистанционно (через SMS) установить программу на мобильный телефон жертвы, причем эта программа будет работать полностью независимо от телефона.
Апплет устанавливается на SIM карту через OTA, а не телефон и этот апплет полностью пассивен, пока к нему телефон не обратится по протоколу SIMToolkit. А протокол весьма ограничен.
Так что врет.
Мы можем шпионить за вами.
Слушая RF и/или притворяясь базовой станцией — без проблем. В общем случае не врет, но в статье речь идет о другом.
Можем добыть ваши криптоключи, используемые для шифрования телефонных звонков.
Ага. если получить физический доступ к карте минут на 20. Пробовал гонять эту программку. Да и исходники где A5 то валяются. Только лишнее это все. Идешь в офис MTC и говоришь, что потерял/сломал карту. За мелкую взятку сотрудника офиса дают новую карту без паспорта.
Не доверяйте банк клиентам и пр. критичным вещам где аутентификация выполняется на основе SMS.
Так что с одной стороны не врет, но способ уж очень сомнительный.
Мы можем читать ваши SMS. Помимо же просто шпионажа, мы (так же через SMS)
Здесь не врет… без проблем. Трафик вскрывается быстро.
можем похищать из SIM-карты телефона критично важные данные о владельце — вашу мобильную личность — и снимать деньги с вашего счета
В общем случае врет (если аутентификация не на SMS).
Покажите мне хоть одну программу, общающуюся с сервером (интернет) по открытому протоколу. Как минимум SSL прикручивают.
В общем то это и не принципиально. Сессионный ключ A5 (голосовой и SMS трафик) взламывается в пределах 5 минут. Ток что вся разница — в режиме реального времени или с задержкой.
Честно — не разбирался и не задумывался.
Сказали когда то давно сервисные инженеры (был проект по банковскому приложению на SIM карте), что не шифруется — вот и запомнил.
Да и какая мне персонально разница.
Большой брат все равно слушает штатно (законодательно установлено) прямо у GSM оператора.
То что телефон показывает режим шифрования — интересно. Не знал и не интересовался о такой возможности.
«Мы можем дистанционно (через SMS) установить программу на мобильный телефон жертвы, причем эта программа будет работать полностью независимо от телефона. Мы можем шпионить за вами. Можем добыть ваши криптоключи, используемые для шифрования телефонных звонков. Мы можем читать ваши SMS. Помимо же просто шпионажа, мы (так же через SMS) можем похищать из SIM-карты телефона критично важные данные о владельце — вашу мобильную личность — и снимать деньги с вашего счета».
Это — пафосный бред расчитанный на журналистов и дилетантов. Либо вольный пересказ журналиста, того что он от него услышал.
Что не утверждение в этой цитате — то лож.
Стандарты (OTA, GSM SimToolkit и прочие GSM стандарты, определяющие что хранится на SIM карте) открытые и легкодоступные. Можно прочитать и убедится что это пафосный бред.
Что такое приложение на SIM карте я прекрасно знаю (разрабатывал их).
Про реверс инженеринг, который он якобы сделал по Mifare и GSM A5. Может быть..., но более вероятно утечка.
«Что знают двое — то знает и свинья».
Mifare карты китайского noname производства с возможностью заказа любого SN или вообще с динамическим прошиваемым SN появились еще в 2007 году. К NXP (Siеmens в девичестве) эти чипы никакого отношения не имели. Так что информация о Mifare алгоритмах утекла раньше…
Даже A5 предполагает работу с сессионным ключом. Это стандартная практика, когда мастер ключ из HSM наружу не выходит, а выдается в открытом виде сессионный ключ.
Хотя не удивлюсь, что у каких то операторов и software реализации с хранением мастер ключей в открытом виде.
Наверное мало кто знает, но в России трафик GSM обычно не шифрован даже на убогом ключе A5. По крайней мере так было 5 лет назад, когда мне демонстрировали приборчик (инженеры сотового оператора), перехватывающий протокол. Законодательство РФ, запрещающее шифровать голосовой трафик не изменилось.
Хотя 100% не поручусь. Тему не мониторил.
Завод, выпускающий карты для заказчика (банковские или SIM) обычно получает ключи от заказчика (или наоборот, но это не принципиально). И они загружаются сразу в HSM. Ни одна процедура не подразумевает появления ключей в открытом виде (кроме как на бумажных компонентах, уничтожаемых сразу после ввода в HSM, если не используются схемы с ассиметричными транспортными ключами).
Ключи у операторов хранятся с гораздо большей безалаберностью чем на заводе, занимающемся выпуском карт.
На заводах GemAlto (на которых я был), очень строго с безопасностью.
Разрекламированный взлом A5 требует наличия самой SIM карты и в 20% случаях приводит к ее сдыханию (количество обращений за ключом ограничено). Хотя да… A5 взламывается не bruteforce атакой, но все равно не так просто, как об этом пишут.
Уязвимость SIM Java карт через OTA — вообще бред. Приложение SimToolkit активируется, если явно выбрать его функционал на телефоне (попробуйте найти его в современном смартфоне… хотя на всех картах MTC оно есть).
И вообще, оно работает по строго ограниченному протоколу (показать что то на экране, послать SMS п т.п.). Древняя и уже морально устаревшая технология.
Да и 3DES ключи для формирования канала OTA — вообще то принадлежат оператору. Зачем оператору заниматься атаками для получения вашего A5 ключа и пр. данных SIM карты, которые он и так знает? (а больше ничего и не получить).
Особенно умиляет упоминание уязвимости DES, при том что DES на 56 битных ключах давно никто не использует. Стандарт для Java card — doubleDES(56*2). Что исключает bruteforce атаку (есть расчеты на энергетических затратах).
А если судить по бреду, с вкраплениями верной информации, в статьях, на которые есть ссылки на этой странице, то и в этом случае журналисты «слышали звон»…
Конечно SIM карты делают, обычно по более упрощенной технологии, чем банковские карты, но эта тема отдельная…
Поскольку имею дела с разными компиляторами, то настоятельно не рекомендовал бы использовать практику «спорных» интерпретаций стандартов.
Плохая эта практика.
Пример: на одном из типов процов, попытка обратится к элементу массива char «обманув» компилятор путем манипуляции с указателем приведет к segmentation fault. Поскольку char там (C/C++) один байт (8-бит). Но вот минимальный размер адресации 32 бита.
Вообще полезно заглядывать в ASM логи, порожденные компилятором.
Да, в результате мы указываем на память, которая находится за пределами массива (сразу после последнего элемента), но кого это волнует? Ведь в C всё равно не проверяется выход за границы массива.
Еще более плохая практика. Вероятность нарваться на границу защищенного сегмента памяти — просто.
Не надо переносить опыт работы в VisualStudio на весь мир.
Лично мне карта получается то же удобнее. По ряду причин не доверяю банк-клиентам. Но использование приложения, как отдельного приложения (без банк клиент), зарубили по маркетинговым причинам.
А так бы пользовался. В пределах лимита 2-3 тыс. в неделю — вполне нормально и относительно безопасно. Все транзакции on-line.
Для банка разница между приложением на телефоне и физической картой очень принципиально.
Стоимость вхождения в эмиссию бесконтактных карт для банка эмитента весьма высока.
Да и для клиента то же. Скачать новую версию приложения (банк-клиент)/активировать в существующей версии или просто отдельное приложение — проще, чем пойти куда то для получения физического пластика.
В принципе, ответы уже есть в других комментариях.
Причина выбора — $50-$60 стоимость на e-bay ГОТОВОЙ платы сразу с LCD экраном.
Я конечно могу развести такую плату протравить ее в домашних условиях. Но если есть готовый вариант — то зачем?
Да и решение в результате более тиражируемое.
Свой проц в ПЛИС! да еще периферию… Уж простите, не верю, что можно получить в свободное от основной работы время результат хотя чуть приближающийся к результату команд STM и NXP (например) по разработке контроллера. Ну если вы не гений с уникальной работоспособностью.
NFC это не платежный продукт. Это набор стандартов/спецификаций на интерфейсы, в частности, и пр… Не более.
Приложение на телефоне, эмулирующее бесконтактную карту с протоколом T=CL это просто один из вариантов бесконтактных «карт». Более простой и дешевый с точки зрения эмиссии и вхождения банка в бесконтактные технологии чем обычный contacless пластик.
Бесконтактные карты весьма распространены (не у нас). Определенную нишу они занимают и занимать будут.
Обычно это платежи на мелкие суммы, где схемы с обналичиванием и выводом крупных сумм неоправданно (для криминалов) сложны или вообще не возможны.
В Европе, расплачиваясь наличными в очереди на кассу в супермаркете чувствуешь себя «белой вороной».
А китайцы, кстати, вообще свой EMV без дуальных карт не видят. Все заводы у них ориентированы на производство сразу дуальных карт.
А мелкие потери от мелких пакосников со специальными знаниями (редкое сочетание) можно списать.
«Порядочный человек, из за мелкой выгоды, большой пакости не сделает».
Массово по бесконтактным картам воровство не организовать.
Расскажите пожалуйста подробнее про энкодер и обработку данных с него на stm32.
Довольно сложно рассказать программный код и аппаратную часть текстом. В файле encoder.c инициализация (всего 60 строк). В документации на STM32F103 — очень понятно изложен принцип работы на счетчиках при работе с экодером.
У вас еще не было проблем с помехами от силовой части и стабильностью работы?
Серия STM32 очень толерантна к питанию. К тому же запитан через DC-DC stepdown преобразователь.
Проблем не было ни разу. Работает стабильно. Это не Raspberry pi, который от громкого чиха в reset уходит.
Сам не экспериментировал, но читал, что с «правильными» драйверами меньше греются шаговики и в общем случае на 10-20% на большей скорости работают без потери шагов.
Но цена у них… Если бы у меня станок работал не для хобби, а для заработка и увеличение производительности было бы принципиально (это важно на резке рельефов), то тогда бы задумался.
Хотя высокая скорость нужна только для частных случаев. Например вырезания рельефов на дереве.
Нагрев поборол радиаторами. С ними больше 60С не греются. В общем… смирился. Меня вполне устраивают.
В ATMega нет ничего плохого. Я их тоже использую. Но там где им место (что то простое..).
В расчете траектории для 3D принтера или простой гравировке и т.п. 8-и разрядный контроллер на 16Мгц справится.
Хотя даже если справится, то ни на что большей ресурсов толком не останется.
Но вот в фрезеровке 3D рельефа на высокой скорости… не верю.
Да и зачем ужиматься в скудном объеме памяти и скудной периферии? Линейка STM32 не принципиально дороже стоит.
Энкодеры «no name», найденые на e-bay. Оптические, разрешение 512.
На фотке их видно. На валу шаговика стоят перед муфтой. Очень удобно. Как раз, похоже, под шаговики и сделаны.
public void processToolkit(byte event) {
…
if (event == EVENT_FORMATTED_SMS_PP_ENV) {
execInputSMS();
}
if (event == EVENT_MENU_SELECTION) {
…
Кусок кода для иллюстрации. И ничего более чем позволяет протокол, приложение в ответ не вернет.
Так что говорить о самостоятельно работающем приложении с потенциально деструктивным кодом на SIM карте — не корректно. Ничего особо деструктивного оно в принципе сделать не может
А много он не позволяет.
Апплет устанавливается на SIM карту через OTA, а не телефон и этот апплет полностью пассивен, пока к нему телефон не обратится по протоколу SIMToolkit. А протокол весьма ограничен.
Так что врет.
Слушая RF и/или притворяясь базовой станцией — без проблем. В общем случае не врет, но в статье речь идет о другом.
Ага. если получить физический доступ к карте минут на 20. Пробовал гонять эту программку. Да и исходники где A5 то валяются. Только лишнее это все. Идешь в офис MTC и говоришь, что потерял/сломал карту. За мелкую взятку сотрудника офиса дают новую карту без паспорта.
Не доверяйте банк клиентам и пр. критичным вещам где аутентификация выполняется на основе SMS.
Так что с одной стороны не врет, но способ уж очень сомнительный.
Здесь не врет… без проблем. Трафик вскрывается быстро.
В общем случае врет (если аутентификация не на SMS).
Покажите мне хоть одну программу, общающуюся с сервером (интернет) по открытому протоколу. Как минимум SSL прикручивают.
Сходу информацию не нашел. Если знаете — подскажите, pls.
Сказали когда то давно сервисные инженеры (был проект по банковскому приложению на SIM карте), что не шифруется — вот и запомнил.
Да и какая мне персонально разница.
Большой брат все равно слушает штатно (законодательно установлено) прямо у GSM оператора.
То что телефон показывает режим шифрования — интересно. Не знал и не интересовался о такой возможности.
Это — пафосный бред расчитанный на журналистов и дилетантов. Либо вольный пересказ журналиста, того что он от него услышал.
Что не утверждение в этой цитате — то лож.
Стандарты (OTA, GSM SimToolkit и прочие GSM стандарты, определяющие что хранится на SIM карте) открытые и легкодоступные. Можно прочитать и убедится что это пафосный бред.
Что такое приложение на SIM карте я прекрасно знаю (разрабатывал их).
Про реверс инженеринг, который он якобы сделал по Mifare и GSM A5. Может быть..., но более вероятно утечка.
«Что знают двое — то знает и свинья».
Mifare карты китайского noname производства с возможностью заказа любого SN или вообще с динамическим прошиваемым SN появились еще в 2007 году. К NXP (Siеmens в девичестве) эти чипы никакого отношения не имели. Так что информация о Mifare алгоритмах утекла раньше…
Даже A5 предполагает работу с сессионным ключом. Это стандартная практика, когда мастер ключ из HSM наружу не выходит, а выдается в открытом виде сессионный ключ.
Хотя не удивлюсь, что у каких то операторов и software реализации с хранением мастер ключей в открытом виде.
Хотя 100% не поручусь. Тему не мониторил.
Завод, выпускающий карты для заказчика (банковские или SIM) обычно получает ключи от заказчика (или наоборот, но это не принципиально). И они загружаются сразу в HSM. Ни одна процедура не подразумевает появления ключей в открытом виде (кроме как на бумажных компонентах, уничтожаемых сразу после ввода в HSM, если не используются схемы с ассиметричными транспортными ключами).
Ключи у операторов хранятся с гораздо большей безалаберностью чем на заводе, занимающемся выпуском карт.
На заводах GemAlto (на которых я был), очень строго с безопасностью.
Разрекламированный взлом A5 требует наличия самой SIM карты и в 20% случаях приводит к ее сдыханию (количество обращений за ключом ограничено). Хотя да… A5 взламывается не bruteforce атакой, но все равно не так просто, как об этом пишут.
Уязвимость SIM Java карт через OTA — вообще бред. Приложение SimToolkit активируется, если явно выбрать его функционал на телефоне (попробуйте найти его в современном смартфоне… хотя на всех картах MTC оно есть).
И вообще, оно работает по строго ограниченному протоколу (показать что то на экране, послать SMS п т.п.). Древняя и уже морально устаревшая технология.
Да и 3DES ключи для формирования канала OTA — вообще то принадлежат оператору. Зачем оператору заниматься атаками для получения вашего A5 ключа и пр. данных SIM карты, которые он и так знает? (а больше ничего и не получить).
Особенно умиляет упоминание уязвимости DES, при том что DES на 56 битных ключах давно никто не использует. Стандарт для Java card — doubleDES(56*2). Что исключает bruteforce атаку (есть расчеты на энергетических затратах).
А если судить по бреду, с вкраплениями верной информации, в статьях, на которые есть ссылки на этой странице, то и в этом случае журналисты «слышали звон»…
Конечно SIM карты делают, обычно по более упрощенной технологии, чем банковские карты, но эта тема отдельная…
Плохая эта практика.
Пример: на одном из типов процов, попытка обратится к элементу массива char «обманув» компилятор путем манипуляции с указателем приведет к segmentation fault. Поскольку char там (C/C++) один байт (8-бит). Но вот минимальный размер адресации 32 бита.
Вообще полезно заглядывать в ASM логи, порожденные компилятором.
Еще более плохая практика. Вероятность нарваться на границу защищенного сегмента памяти — просто.
Не надо переносить опыт работы в VisualStudio на весь мир.
А так бы пользовался. В пределах лимита 2-3 тыс. в неделю — вполне нормально и относительно безопасно. Все транзакции on-line.
Для банка разница между приложением на телефоне и физической картой очень принципиально.
Стоимость вхождения в эмиссию бесконтактных карт для банка эмитента весьма высока.
Да и для клиента то же. Скачать новую версию приложения (банк-клиент)/активировать в существующей версии или просто отдельное приложение — проще, чем пойти куда то для получения физического пластика.
Причина выбора — $50-$60 стоимость на e-bay ГОТОВОЙ платы сразу с LCD экраном.
Я конечно могу развести такую плату протравить ее в домашних условиях. Но если есть готовый вариант — то зачем?
Да и решение в результате более тиражируемое.
Свой проц в ПЛИС! да еще периферию… Уж простите, не верю, что можно получить в свободное от основной работы время результат хотя чуть приближающийся к результату команд STM и NXP (например) по разработке контроллера. Ну если вы не гений с уникальной работоспособностью.
ПЛИС, не для этого. Мое лично мнение…
Синтаксис g-code не поддерживает обратной связи.
Приложение на телефоне, эмулирующее бесконтактную карту с протоколом T=CL это просто один из вариантов бесконтактных «карт». Более простой и дешевый с точки зрения эмиссии и вхождения банка в бесконтактные технологии чем обычный contacless пластик.
Бесконтактные карты весьма распространены (не у нас). Определенную нишу они занимают и занимать будут.
Обычно это платежи на мелкие суммы, где схемы с обналичиванием и выводом крупных сумм неоправданно (для криминалов) сложны или вообще не возможны.
В Европе, расплачиваясь наличными в очереди на кассу в супермаркете чувствуешь себя «белой вороной».
А китайцы, кстати, вообще свой EMV без дуальных карт не видят. Все заводы у них ориентированы на производство сразу дуальных карт.
А мелкие потери от мелких пакосников со специальными знаниями (редкое сочетание) можно списать.
«Порядочный человек, из за мелкой выгоды, большой пакости не сделает».
Массово по бесконтактным картам воровство не организовать.
Просто показалось обидно и не корректно, что об этом в статье ни словом не упомянуто.
Только что по ней сходил с телефона… В архиве
CNC/cnc_workspace/cnc/src/application/encoder.c
HCE приложение по «Visa Cloud-Based Payments Contactless Specification V1.3» написать не проблема. Это MasterCard извратная спецификация на HCE.
Открытого ПО для CAM можно пересчитать по пальцам одной руки…
(а не встал ли станок… и не случилось ли чего..).
В 2-х метрах от работающего станка вполне нормально смотрится телевизор на обычной громкости.
Довольно сложно рассказать программный код и аппаратную часть текстом. В файле encoder.c инициализация (всего 60 строк). В документации на STM32F103 — очень понятно изложен принцип работы на счетчиках при работе с экодером.
Серия STM32 очень толерантна к питанию. К тому же запитан через DC-DC stepdown преобразователь.
Проблем не было ни разу. Работает стабильно. Это не Raspberry pi, который от громкого чиха в reset уходит.
Но цена у них… Если бы у меня станок работал не для хобби, а для заработка и увеличение производительности было бы принципиально (это важно на резке рельефов), то тогда бы задумался.
Хотя высокая скорость нужна только для частных случаев. Например вырезания рельефов на дереве.
Нагрев поборол радиаторами. С ними больше 60С не греются. В общем… смирился. Меня вполне устраивают.
В ATMega нет ничего плохого. Я их тоже использую. Но там где им место (что то простое..).
В расчете траектории для 3D принтера или простой гравировке и т.п. 8-и разрядный контроллер на 16Мгц справится.
Хотя даже если справится, то ни на что большей ресурсов толком не останется.
Но вот в фрезеровке 3D рельефа на высокой скорости… не верю.
Да и зачем ужиматься в скудном объеме памяти и скудной периферии? Линейка STM32 не принципиально дороже стоит.
На фотке их видно. На валу шаговика стоят перед муфтой. Очень удобно. Как раз, похоже, под шаговики и сделаны.