Comments 101
Хорошая статья, уязвимость действительно просто нубовая. Спасибо, что осветили её!
Когда пишите про тестирование, вспоминайте статью про подделку проездных документов.
Это которая? 327 не подходит, проездной не имеет признаков официального документа. 165 подходит, но ввиду 14.2 никто не будет связываться с отдельным зайцем. Вот если накрыть поточное производство левых билетов, тогда да.
Только суды различных глубинок думают по-своему: Как говорится в материалах дела, «билет, являющийся одним из оснований для осуществления проезда, является документом, свидетельствующим о заключении официального договора между пассажиром и компанией, осуществляющей перевозку». Таким образом, следует из постановления, билет — это официальный документ, подделка которого уголовно наказуема. Статья Шевцова о взломе проездной карты приравнивается к распространению информации о способах совершения уголовного преступления.
Это касаемо поста про Тройку: https://vc.ru/n/habrahabr-troika-court
Надо же… я был уверен, что баланс не хранится на самой карте, а валидация, списания и зачисления производятся на каком-то сервере. это же логично.
Что же получается, информация о балансе вообще нигде кроме как на карте не хранится?
Что же получается, информация о балансе вообще нигде кроме как на карте не хранится?
На самом деле, онлайн валидация очень затратная штука. Тот же Сбербанк в лице почившей УЭК решил сделать онлайн-проездной в Подмосковье (Стрелка). Только им пришлось частично отказаться от затеи, так как покрытие связью территория не 100-процентная, да и там, где она формально есть, всё равно время от времени лагает.
На самом деле, история карт с «хранимой стоимостью» не нова и обкатана в куче стран не только в роли проездных, но и в роли платёжных карт (Visa Cash, Mondex, тот же Сберкард, которого уже нет). Только использовать надо не уязвимые реализации с защитой транспортным ключём, а нормальные криптографические карты.
На самом деле, история карт с «хранимой стоимостью» не нова и обкатана в куче стран не только в роли проездных, но и в роли платёжных карт (Visa Cash, Mondex, тот же Сберкард, которого уже нет). Только использовать надо не уязвимые реализации с защитой транспортным ключём, а нормальные криптографические карты.
Цитируя klylex из позавчерашнего слитого поста, в котором НЛО, так же, как и вам, подарило инвайт автору:
Неплохо пишете, спасибо. Теперь давайте следующую статью про фронтенд. Только не вставляйте гендерные ремарки «обычная девушка» и «даже я, девушка», так будет лучше.
Хочет женщина программировать — программирует. Не хочет — не программирует.
Неплохо пишете, спасибо. Теперь давайте следующую статью про фронтенд. Только не вставляйте гендерные ремарки «обычная девушка» и «даже я, девушка», так будет лучше.
Если бы я, как разработчик, использовала старые версии фреймворков с известными уязвимостями, мне бы давно оторвал работодатель голову, но на разработчиков транспортных систем это, по-моему, не распространяется. Возможно, это связано с низкой подкованностью самих разработчиков… Складывается ощущение, что все транспортные системы, где используются транспортные карты, небезопасны. Не хочу рассуждать, почему так происходит (эта тема не для Хабра)
Ох уж эта уверенность, что обманул систему — значит, вокруг дураки. :) Тема-то вполне себе для Хабра, только уровень обсуждения вопроса совсем иной должен быть. Вы когда-нибудь в разработке подобного масштаба участвовали, причем не как рядовой винтик, а как человек, который деньгами распоряжается? Можете оценить, во сколько обойдутся работы по устранению уязвимости по сравнению с ущербом от пары(десяков/сотен) бесплатно ездящих гиков?
Т.е. чтобы решить проблемы уязвимости карт, стоит условно-бесплатно раздавать взломанные карты и/или мануалы по их взлому на улицах?
Максимально увеличить ущерб от подобных косяков, чтобы производитель наконец исправил их, а что, это идея.
Угу. Чтобы городу не наносился ущерб, надо нанести ему ещё больший ущерб. А в качестве финала сесть в колонию как безвинный борец с системой. :D Отличный пример мышления хакера-террориста с идеалистическими наклонностями.
Чтобы городу не наносился ущерб, надо нанести ему ещё больший ущерб.
Отличный пример мышления хакера-террориста с идеалистическими наклонностями.
Что-то вспомнилась статья про Тёмного рыцаря, в которой доказывается, что Джокер на самом деле герой, потому что своими поступками исправил ситуацию в городе.
А какие способы исправления ситуации предлагаете вы? Это пользователи должны упрашивать исправлять косяки разработчиков? Мало на хабре статей, когда в банки и другие структуры люди пытались достучаться, рассказать об уязвимости, а их мягко говоря посылали? И у меня есть пример со своим провайдером.
Я писала выше, что не наносила ущерб системе, но что-то подсказывает, что не все бывают таким сознательными
Я писала выше, что не наносила ущерб системе, но что-то подсказывает, что не все бывают таким сознательными
Это пользователи должны упрашивать исправлять косяки разработчиков?
В этом случае пользователя никак не затрагивают и не напрягают "косяки" разрабочика (причем даже не факт, что в этом конкретном случае имеет место косяк, а не осознанное решение). Пользователь спокойно покупает карту и без проблем по ней ездит, какие у него тут могут быть претензии?
Кто сказал что уязвимость карт это проблема?
Есть затраты на исправление софта и есть процент краж. Перемножаем процент краж на общее количество пассажиров, умножаем на цену билета и сравниваем с ценой исправления софта. Ничего личного, просто бабули которые ездят в метро не захотят платить за вашу криптографию и не объяснишь им. Оставить все как есть просто дешевле и выгоднее для всех.
Есть затраты на исправление софта и есть процент краж. Перемножаем процент краж на общее количество пассажиров, умножаем на цену билета и сравниваем с ценой исправления софта. Ничего личного, просто бабули которые ездят в метро не захотят платить за вашу криптографию и не объяснишь им. Оставить все как есть просто дешевле и выгоднее для всех.
Это всё чудесно, но как в вашу стройную систему вписывается тот факт, что покупаются дорогие карты с возможностью использовать нормальную защиту, а эксплуатируются они в ущербном режиме, который можно обеспечить и на картах с ощутимо более низкой ценой? Как раз те бабули и платят эту разницу и у них никто не спрашивает почему-то, хотят они этого или нет.
Я объяснил своей «стройной системой» почему уже существующая, конкретная уязвимость не будет исправляться (какое-то время), но не берусь судить почему ее вообще допустили. Скорее всего это называется или халатность или коррупция, нужно это расследовать отдельно.
нужно это расследовать отдельно
боюсь, до этого как раз не дойдет, проще гнобить авторов статей, обвиняя их во всех грехах. ну и закрывая потом эти статьи на хабре
ну уж нет, вы вначале стали объяснять, что это затратно, что бабули за это не хотят платить, а вам напомнили, что люди за это уже заплатили, и тут вы пошли на попятную
>> а вам напомнили, что люди за это уже заплатили
Я исхожу из того, что система сделана по ТЗ и принята заказчиком. Люди действительно заплатили за ЭТО, то есть за то, что сделано именно так.
Было ли это в ТЗ и были ли отклонения от ТЗ (на которые вы намекаете) я не знаю. Есть факты — система работает уже несколько лет, откуда можно сделать вывод, что она принята заказчиком. Если она принята, значит работа выполнена, с нарушениями или нет, с неустойкой или нет, неважно. Но она принята, а значит речь об исправлении — отдельная тема.
Возможно — есть саппорт на несколько лет со стороны разработчика — тогда само собой такие исправление должны делаться бесплатно. Но еще раз — я не об идеальной ситуации в которой «все как надо», я об этой ситуации и раз мы ничего не знаем о договоре саппорта, предполагаем, что его нет.
Если вы добавляете в ситуацию «подразумеваемые» условия, то понятно что мои рассуждения тут вообще никаким боком.
Я исхожу из того, что система сделана по ТЗ и принята заказчиком. Люди действительно заплатили за ЭТО, то есть за то, что сделано именно так.
Было ли это в ТЗ и были ли отклонения от ТЗ (на которые вы намекаете) я не знаю. Есть факты — система работает уже несколько лет, откуда можно сделать вывод, что она принята заказчиком. Если она принята, значит работа выполнена, с нарушениями или нет, с неустойкой или нет, неважно. Но она принята, а значит речь об исправлении — отдельная тема.
Возможно — есть саппорт на несколько лет со стороны разработчика — тогда само собой такие исправление должны делаться бесплатно. Но еще раз — я не об идеальной ситуации в которой «все как надо», я об этой ситуации и раз мы ничего не знаем о договоре саппорта, предполагаем, что его нет.
Если вы добавляете в ситуацию «подразумеваемые» условия, то понятно что мои рассуждения тут вообще никаким боком.
Проблема тут в другом. Описанные в статье дыры известны уже лет 5. Но разрабатываются новые системы, в которых эти дыры до сих пор не учтены. Что это? Некомпетентность разработчиков или пофигизм? Хотя, закрыть эти дыры при разработке нового проекта не стоит больших денег.
Как же мне объяснить свою мысль уже чтобы понятно было. Представьте, что вы пользуетесь зубной щеткой, который вас вполне устраивает. Зубная щетка выпадает изо рта при чистке не больше чем 1 раз из 1000. И остальных клиентов это тоже устраивает. Но вы так как сами работали на производстве щеток знаете, что за сущие копейки можно разработать щетку с крючком, из за которого щетка будет выпадать 1 раз из 1000 000. Но кроме вас (знающего) никто этим не интересуются, даже если знают что такие щетки теоретически возможны.
Почему? Потому что не видит никто проблемы, которая требует исправления. Ну не видит и все тут и пофиг им что иногда выпадает, это ни на что не влияет, погрешность. Вот если выпадала бы 100 раз из 1000, тогда это было бы проблемой, а так — все ок.
Вы профессионал — вы понимаете почему это плохо, у остальных — своя работа, когда такая доработка понадобится — они к вам обратятся. Дело не в компетентности заказчика, а в потребности, которой у него нет.
Почему? Потому что не видит никто проблемы, которая требует исправления. Ну не видит и все тут и пофиг им что иногда выпадает, это ни на что не влияет, погрешность. Вот если выпадала бы 100 раз из 1000, тогда это было бы проблемой, а так — все ок.
Вы профессионал — вы понимаете почему это плохо, у остальных — своя работа, когда такая доработка понадобится — они к вам обратятся. Дело не в компетентности заказчика, а в потребности, которой у него нет.
Точно так же можно задаться вопросом, почему карты поддерживающие нормальную защиту поддерживают и старый ущербный режим. Ответ на самом деле прост — еще живо оборудование поддерживающее только старый стандарт, стоит оно не дешево, и менять его только потому что сотня человек будет ездить бесплатно, просто не выгодно. А новые карты закупают, чтобы однажды, когда это оборудование отомрет естественным путем, начать наконец-то работать по более защищённому протоколу.
Диванная аналитика такая диванная.
Для нашей маленькой системки, технологически работающей с Mifare Classic, регулярно закупаем карты Mifare Plus и используем их в режиме совместимости. Просто потому что:
а) Быстрее поставляют
б) Стоят не дороже (а иногда и дешевле).
Дешевле стоят китайские клоны, но с ними иногда возникают проблемы в самых неожиданных местах.
Для нашей маленькой системки, технологически работающей с Mifare Classic, регулярно закупаем карты Mifare Plus и используем их в режиме совместимости. Просто потому что:
а) Быстрее поставляют
б) Стоят не дороже (а иногда и дешевле).
Дешевле стоят китайские клоны, но с ними иногда возникают проблемы в самых неожиданных местах.
Ничего личного, просто бабули которые ездят в метро не захотят платить за вашу криптографию и не объяснишь им
Вам уже указали на ошибку в рассуждениях. Бабули уже заплатили за нормальную криптографию (ну, не бабули, а пассажиры, бабулям, возможно, карты бесплатно выдаются), а по факту получили… crap (не мое название, утилита в статье так называется)
Если бы вы еще знали, сколько унижений пришлось испытать моей маме, чтобы получить льготную карту…
>> Бабули уже заплатили за нормальную криптографию
Из каких источников эта информация?
1) Что вы считаете «нормальной» криптографией? Абсолютной безопасности нет, есть некоторые уровни, причем каждый следующий стоит сильно бОльших денег.
2) Где вы вычитали что подразумевался иной уровень защиты? Кто сказал, что по ТЗ все было не так?
Это не ошибка в рассуждениях, просто вы внесли дополнительное условия, что криптография по заданию разработчикам была серьезнее, но не была реализована. Я такое условие не добавлял и подразумеваю, что работа была заказана именно такой и выполнена корректно, пока не известно иное. Поэтому люди заплатили (в лице метрополитена) именно на такую реализацию (хорошо это или плохо). Поэтому повышать криптографию до «нормального» уровня — вопрос отдельный.
Из каких источников эта информация?
1) Что вы считаете «нормальной» криптографией? Абсолютной безопасности нет, есть некоторые уровни, причем каждый следующий стоит сильно бОльших денег.
2) Где вы вычитали что подразумевался иной уровень защиты? Кто сказал, что по ТЗ все было не так?
Это не ошибка в рассуждениях, просто вы внесли дополнительное условия, что криптография по заданию разработчикам была серьезнее, но не была реализована. Я такое условие не добавлял и подразумеваю, что работа была заказана именно такой и выполнена корректно, пока не известно иное. Поэтому люди заплатили (в лице метрополитена) именно на такую реализацию (хорошо это или плохо). Поэтому повышать криптографию до «нормального» уровня — вопрос отдельный.
Бабули уже заплатили за нормальную криптографиюс чего вы взяли, что кто-либо уже заплатил за «нормальную криптографию»? С того, что карта Mifare Plus ?!?!? Да одинаково они с Classic стоят при равном объеме памяти.
А помимо карт для работы системы нужна еще куча разного оборудования и софт (который тоже денег стоит).
И 'нормальная криптография' в каких-то случаях затруднит атаки, но защищенной систему не сделает. У тройкй, например, ключи добыли другим способом, а далее совершенно безразлично какая там криптография.
Ну, когда Oyster в Лондоне или OpenCard в Праге ломанули, они как-то собрались с силами и пропатчили свои системы. Вроде как заменили Mifare Classic на Mifare Plus, а то и DesFire. И как-то не особо ворчали о паре десятков гиков, так как это в первую очередь репутационный факап. Причём это было ещё при царе Горохе.
Я не говорю, что проблема не решается в принципе. Я говорю, что решение лежит в областях, о которых люди, рассуждающие на уровне "хакер-идеалист", обычно вообще ничего не знают.
репутационный факап
Опять же подумайте, какие и для кого могут быть негативные последствия от публикации статей на Хабре. :)
Как минимум, репутационные потери компании-интегратора, а так же бенефицианта системы, в случае Ситикард это Сбербанк. Хотя ему падать-то уже особо некуда…
Сегодня на Хабре, завтра на других сайтах, вспомните историю Тройки. Хотя, конечно, масштабы разные.
Сегодня на Хабре, завтра на других сайтах, вспомните историю Тройки. Хотя, конечно, масштабы разные.
Тройке, между прочим, совершенно все равно, какая там криптография в карте. Ключи вытащены из приложения онлайн-пополнения карты телефоном с NFC.
Можем поиграть с вами в игру — вы придумываете, как безопасно реализовать такой функционал (весьма полезный и гиковый), я вам объясняю, почему ваша идея либо снижает удобство пользования системы, либо не безопасна, либо очень дорога в реализации (либо и то и другое сразу).
Можем поиграть с вами в игру — вы придумываете, как безопасно реализовать такой функционал (весьма полезный и гиковый), я вам объясняю, почему ваша идея либо снижает удобство пользования системы, либо не безопасна, либо очень дорога в реализации (либо и то и другое сразу).
Ну, будем честными, Mifare Plus не имеет никакой особо криптографии, обычные симметричные ключи, просто без коллизий, делающих возможным подбор методом перебора как на Mifare Classic. Это да.
Что мешает использовать асимметричное шифрование, с каким-нибудь ECDSA/SHA256 для скорости (или, о боже, ГОСТ)? Выстроить модель PKI, cделать что-то a-la PayPass с одноразовыми сессионными ключами, просто без онлайна.
Что мешает использовать асимметричное шифрование, с каким-нибудь ECDSA/SHA256 для скорости (или, о боже, ГОСТ)? Выстроить модель PKI, cделать что-то a-la PayPass с одноразовыми сессионными ключами, просто без онлайна.
за чей счет банкет?
За счёт того же Сбербанка, что там светится. Тем более как раз им некуда девать свой УЭК с ГОСТами и прочей криптографией. Вон, Стрелку в Подмосковье на этой платформе как раз и запилили. Карточка стоит 80 рублей для пассажира. С внедрением Стрелки тоже были свои сложности, но вроде систему причесали.
Вы представляете разницу между «купить и допилить напильником готовое решение» и сделать свой велосипед?
ps:
Рано или поздно естественно (массовые) карточные технологии придут к асимметричной криптографии. Mastercard тот же свой M-chip пытается пропихнуть по многим фронтам. Но пока что это непаханное поле.
pps: о том, как работает стрелка в московских электричках я помолчу, ибо за мат забанят.
ps:
Рано или поздно естественно (массовые) карточные технологии придут к асимметричной криптографии. Mastercard тот же свой M-chip пытается пропихнуть по многим фронтам. Но пока что это непаханное поле.
pps: о том, как работает стрелка в московских электричках я помолчу, ибо за мат забанят.
Вы представляете разницу между «купить и допилить напильником готовое решение» и сделать свой велосипед?
Представляю не по наслышке. Поэтому вопрос в том, почему сразу нельзя было сделать нормально. Тем более с нуля, без поддержки legacy. Это как: «можно поставить СКУД подешевле на Em-Marine, а можно подороже на HID iClass». А потом кто-то удивляется, что кто-то вламывается по клонированному пропуску в офис и тырит ноутбуки на стоимость несоизмеримую со стоимостью СКУД на несколько порядков. Причем, заказчик может даже не подозревать о наличии более защищённых систем, ему просто ставят самое дешёвое решение по-умолчанию.
ps:
Рано или поздно естественно (массовые) карточные технологии придут к асимметричной криптографии. Mastercard тот же свой M-chip пытается пропихнуть по многим фронтам. Но пока что это непаханное поле.
Вроде как как раз из-за M-chip и завернули Сберовский УЭК/ПРО100 из НСПК. Лицензии, санкции, все дела.
pps: о том, как работает стрелка в московских электричках я помолчу, ибо за мат забанят.
С точки зрения рядового пассажира как раз одинаково, что Стрелка, что Тройка, что РЖДшная БСК. Только что «чисто» Стрелку надо «заряжать» в автомате через контактный чип почему-то, хотя в Стрелко-Тройке уже норм.
Почему сразу нельзя было сделать «нормально» кому ?!? NXP !?!
Или дептрансу НН? Дептранс наверняка купил готовую систему. Работающую с Mifare. И с точки зрения антифрода она их вполне устраивает: клонированием карт конкуренцию билетным кассам не составить (а если кто найдет способ, например добыв ключ имитовставки, то проблему решат старым добрым нетехническим методом закупка->следствие->суд->зона), а на одиночных гиков можно наплевать. Будут сильно мешать — допилить механизмы обнаружения и блокировки.
Один рядовой пассажир пару раз подоказывал, что он не заяц, а пользователь передовых новых /хреново работающих/ технологий и затем забил на эти ваши стрелки и тройки на ржд и стал покупать олдскульные билетики с шк, благо езжу нечасто.
Это к вопросу о внедрении велосипедов.
Или дептрансу НН? Дептранс наверняка купил готовую систему. Работающую с Mifare. И с точки зрения антифрода она их вполне устраивает: клонированием карт конкуренцию билетным кассам не составить (а если кто найдет способ, например добыв ключ имитовставки, то проблему решат старым добрым нетехническим методом закупка->следствие->суд->зона), а на одиночных гиков можно наплевать. Будут сильно мешать — допилить механизмы обнаружения и блокировки.
Один рядовой пассажир пару раз подоказывал, что он не заяц, а пользователь передовых новых /хреново работающих/ технологий и затем забил на эти ваши стрелки и тройки на ржд и стал покупать олдскульные билетики с шк, благо езжу нечасто.
Это к вопросу о внедрении велосипедов.
А потом кто-то удивляется, что кто-то вламывается по клонированному пропуску в офис и тырит ноутбуки на стоимость несоизмеримую со стоимостью СКУД на несколько порядков. Причем, заказчик может даже не подозревать о наличии более защищённых систем, ему просто ставят самое дешёвое решение по-умолчанию.
Тут полностью согласен. То же самое, похоже, происходит и с транспортными системами.
Вон, Стрелку в Подмосковье на этой платформе как раз и запилили
На какой этой? От УЭК там только название. Обычная Java card с эмуляцией Mifare Classic. Без всякого ГОСТа
Ну, будем честными, Mifare Plus не имеет никакой особо криптографии, обычные симметричные ключи, просто без коллизий, делающих возможным подбор методом перебора как на Mifare Classic.
Ну, если для Вас AES-128 не криптография… Может расскажете, как тогда AES ломать?
Да, и прямой брут-форс ключей даже с классиком не работает
А Вы знаете, как решается это проблема? Чем Вы отличаетесь от «хакера-идеалиста»? Только тем, что Вы «эффективный менеджер, который якобы умеет считать деньги и репутационные риски »?
вы рассуждаете, как нерадивый разработчик, который накосячил, а потом начинает придумывать отговорки в стиле «вы ничего в этом не понимаете»
Вопрос накосячил лежит в различиях между тем что «должно быть» и «что есть». Чтобы говорить, что «накосячил» есть, вы пожалуйста сначала предъявите ТЗ и укажите на различия.
Не надо делать поспешных выводов. Бывает (и часто) что заказчику нужна система с более низкой защитой по разным причинам (например еслт это дешевле, или в случае как с дорогами — сделать херово, чтоб в следующем году опять денег на переделку выделили).
Не надо делать поспешных выводов. Бывает (и часто) что заказчику нужна система с более низкой защитой по разным причинам (например еслт это дешевле, или в случае как с дорогами — сделать херово, чтоб в следующем году опять денег на переделку выделили).
Бывает (и часто) что заказчику нужна система с более низкой защитой по разным причинам (например еслт это дешевле, или в случае как с дорогами — сделать херово, чтоб в следующем году опять денег на переделку выделили).
И Вы считаете, это нормально?
Нет, не считаю. Но речь не обо мне.
тогда я не понимаю, зачем вы встаете на защиту ущербной «логики», которую сами же считаете ненормальной?
меня, например, не интересует извращенная логика коррумпированных или некомпетентных заказчиков (как вы же пишете «сделать херово, чтоб в следующем году опять денег на переделку выделили»).
меня, например, не интересует извращенная логика коррумпированных или некомпетентных заказчиков (как вы же пишете «сделать херово, чтоб в следующем году опять денег на переделку выделили»).
Я не встаю на защиту «логики» — она в защите не нуждается. Я встаю на защиту любой стороны, относительно которой выносятся суждения ни на чем не основанные.
>> рассуждаете, как нерадивый разработчик, который накосячил
Еще раз — нельзя говорить, что накосячил разработчик, пока нет требований к работе. Вполне возможно, что требование не такие, какие мы подразумеваем. Нельзя осуждать людей, основываясь на своих предположениях.
>> меня, например, не интересует извращенная логика коррумпированных или некомпетентных
Что значит не интересует? Вы можете ей пользоваться, или не пользоваться (можете еще как-то относиться к тем, кто ее использует) — нет никакого интересует/не интересует. Я тоже не пользуюсь логикой "@як, @як и в продакшн", но это не значит что такую возможность надо исключать и сразу винить разработчика.
>> рассуждаете, как нерадивый разработчик, который накосячил
Еще раз — нельзя говорить, что накосячил разработчик, пока нет требований к работе. Вполне возможно, что требование не такие, какие мы подразумеваем. Нельзя осуждать людей, основываясь на своих предположениях.
>> меня, например, не интересует извращенная логика коррумпированных или некомпетентных
Что значит не интересует? Вы можете ей пользоваться, или не пользоваться (можете еще как-то относиться к тем, кто ее использует) — нет никакого интересует/не интересует. Я тоже не пользуюсь логикой "@як, @як и в продакшн", но это не значит что такую возможность надо исключать и сразу винить разработчика.
Тут вопрос вопрос не в устранении, а в том как вообще допустили выпуск продукта, реализованного на таком позорном уровне.
Как раз это очень просто.
1) Заранее «договорённый» разработчик с тендером задним числом
2) Отсутствие технической экспертизы решения (см. пункт 1)
3) Работает и ладно
4) «Все так делают, чего нам-то париться»?
5) Экономическое обоснование (стоимость железа и разработки)
1) Заранее «договорённый» разработчик с тендером задним числом
2) Отсутствие технической экспертизы решения (см. пункт 1)
3) Работает и ладно
4) «Все так делают, чего нам-то париться»?
5) Экономическое обоснование (стоимость железа и разработки)
Вы подгоняете ответ под исходный негативный настрой. А как вам такой вариант — исходная система проектировалась черти когда с расчетом на устаревшее оборудование и протоколы, а дальше просто клонировалась по городам. Борьба с возможностью подделки проездных документов заказчика интересует исключительно в экономическом плане — стоимость мер защиты против потенциального ущерба. Если затраты на повышение защиты (в т.ч. в виде оплаты доработки ПО) превышают потенциальный ущерб — доработка реально никому не нужна, ни заказчику системы (городу), ни потребителю (людям). При этом нельзя исключать, что исправления просто внесут в какой-нибудь план работ по поддержке и модернизации, и со временем проблема уйдет.
«Чёрти когда» были жетоны. А система проектировалась не так давно, когда уже из технологических решений всё было и кроме жетонов никаких legacy особо не было.
Это "не так давно" случилось ещё до того, как регулярно поминаемая тут всуе Mifare Plus вообще в природе появилась.
01.11.2014г. Вводится в действие Транспортная карта.
Протокол Mifare Classic был полностью подвергнут реверс инжинирингу в 2008 г. (за 6 лет до этого)
MIFARE Plus was publicly announced in March 2008 with first samples in Q1 2009
Оттуда же: MIFARE Plus is a replacement card for the MIFARE Classic. It provides an easy upgrade of existing infrastructures toward high security. Data management is identical to the MIFARE Classic; however, the security management requires the modification of the installed reader base (но installed base ведь нет при внедрении с нуля).
Так что, нестыковочка у Вас в рассуждениях.
Протокол Mifare Classic был полностью подвергнут реверс инжинирингу в 2008 г. (за 6 лет до этого)
MIFARE Plus was publicly announced in March 2008 with first samples in Q1 2009
Оттуда же: MIFARE Plus is a replacement card for the MIFARE Classic. It provides an easy upgrade of existing infrastructures toward high security. Data management is identical to the MIFARE Classic; however, the security management requires the modification of the installed reader base (но installed base ведь нет при внедрении с нуля).
Так что, нестыковочка у Вас в рассуждениях.
У меня нет никакой нестыковочки, а есть предположение, что система в Нижнем разрабатывалась не с нуля.
и где во фразе «Это „не так давно“ случилось ещё до того, как регулярно поминаемая тут всуе Mifare Plus вообще в природе появилась» предположение? звучит как самоуверенное утверждение.
Раньше много чего не было, и что теперь, всем продолжать топтаться на месте?
Раньше много чего не было, и что теперь, всем продолжать топтаться на месте?
Если вы хотите что-то обсуждать — держите в голове весь контекст разговора, пожалуйста. Это, как правило, больше одной фразы.
и что теперь, всем продолжать топтаться на месте?
Вы лично можете не топтаться, сделать, например, у себя дома СКУД на самых современных технологиях и гордиться уровнем технического совершенства. А когда речь идет о трате денег другими людьми, у них неизбежно встаёт вопрос "а за чей счет банкет и что мы от этого выиграем". То самое экономическое обоснование, необходимость которого вы никак не хотите понять.
Ну понятно, логика Д'Артаньяна, плюс переход на личности, что, как известно, признак отсутствия аргументов, плюс приписывание оппоненту неких качеств, недостаток понимания и т. п.
Поэтому дискуссию с ildarz прекращаю: у человека явно недостаток компетенции в вопросе. А надуманные, но яростные аргументы в пользу «зачем покупать новый замок и перестать оставлять ключ под ковриком — ведь ущерба пока не было, да и за чей счет банкет» позволяют задуматься о некой ангажированности (может, представитель того самого нерадивого поставщика?)
А вот другим объясню: эксплуатируемая в статье уязвимость обнаружена задолго до внедрения системы (лет этак за 6). Закрыть ее достаточно просто — буквально парой APDU команд. Никаких особенных серьезных затрат это не несет, тем более для заказчика: заказчик мог просто это в требованиях прописать. Вряд ли поставщик прописывал в документации на поставку, что поставляет «дырявый» продукт.
Зато даже гипотетического экономического ущерба это позволит избежать. А способы получения экономического ущерба описаны в статье.И они вполне реальны и легкодоступны
Простой пример: вы согласны покупать коммерческий продукт (связанный с финансами), в составе которого непропатченный openssl с Heartbleed? А зачем, ведь "а за чей счет банкет и что мы от этого выиграем"?
Поэтому дискуссию с ildarz прекращаю: у человека явно недостаток компетенции в вопросе. А надуманные, но яростные аргументы в пользу «зачем покупать новый замок и перестать оставлять ключ под ковриком — ведь ущерба пока не было, да и за чей счет банкет» позволяют задуматься о некой ангажированности (может, представитель того самого нерадивого поставщика?)
А вот другим объясню: эксплуатируемая в статье уязвимость обнаружена задолго до внедрения системы (лет этак за 6). Закрыть ее достаточно просто — буквально парой APDU команд. Никаких особенных серьезных затрат это не несет, тем более для заказчика: заказчик мог просто это в требованиях прописать. Вряд ли поставщик прописывал в документации на поставку, что поставляет «дырявый» продукт.
Зато даже гипотетического экономического ущерба это позволит избежать. А способы получения экономического ущерба описаны в статье.И они вполне реальны и легкодоступны
Простой пример: вы согласны покупать коммерческий продукт (связанный с финансами), в составе которого непропатченный openssl с Heartbleed? А зачем, ведь "а за чей счет банкет и что мы от этого выиграем"?
Я не автор, но немного в теме (считаю, некрасиво такое спрашивать, ведь ответ заранее известен — конечно, автор вряд ли участвовала в разработке подобного масштаба, но напасть-то на девушку легко). И с уверенностью могу сказать — чтобы закрыть уязвимость, вернее, использовать карты в более высоком режиме безопасности, потребуются, безусловно, доработки, но они настолько мизерные, что их, наверное, и не увидеть в общей стоимости системы. Грубо говоря, несколько APDU команд поддержать.
Вообще, у NXP есть много интересных продуктов, которые и защищены хорошо, и обратную совместимость поддерживают. И еще они настоятельно просят не использовать Classic, рассылая регулярно бюллетени. Вдумайтесь: уязвимости скоро 10 лет. Но воз и ныне там. Наверное, какой-нибудь «эффективный менеджер» так и считает: авось никто не заметит, пара сотен гиков — хрен с ними, а «ненужные» затраты на доработку лучше себе в виде премии выписать
Вообще, у NXP есть много интересных продуктов, которые и защищены хорошо, и обратную совместимость поддерживают. И еще они настоятельно просят не использовать Classic, рассылая регулярно бюллетени. Вдумайтесь: уязвимости скоро 10 лет. Но воз и ныне там. Наверное, какой-нибудь «эффективный менеджер» так и считает: авось никто не заметит, пара сотен гиков — хрен с ними, а «ненужные» затраты на доработку лучше себе в виде премии выписать
ну так расскажите, какой должен быть уровень обсуждения, а то как-то у вас расплавчато и не конкретно. Пока я вижу, как распорядились деньгами — купили подешевле, продали подороже.
почему вы приписываете мне то, чего я не говорила? а аргументированно можете сказать, в чем я не права?
Прошу прощения за некоторый сарказм в исходном комментарии, просто уж больно типичная картина. Насчет аргументов — я же прямо сказал — в самом первом приближении надо оценивать затраты на внесение изменений в систему и сравнивать их с потенциальным ущербом.
Вы считаете, что это уязвимость и её непременно должны исправить. Ок. Вот представьте себе, что вы каким-то чудом пробились на прием к лицу, принимающему решения "делать доработку/не делать доработку". Он вас спрашивает — а зачем? Вы готовы к подобному разговору? Что вы ему ответите? Попробуйте быть убедительной. :)
Надеюсь аккаунт создавался через Тор и статья была отправлена через него же, иначе возможен визит органов.
Вы меня немножко напугали. Возможно, я не оценила всю серьезность этого. Как тут написали, проще наехать на пассажира, чем искать реальных виновных
>> порой забывала карту то дома, то на работе и приходилось покупать новую
Хорошо шифруется «девушка». У нас тут как бы кроме карт, еще и жетоны в ходу. Более того, карт по сравнению с жетонами ничтожно мало.
Хорошо шифруется «девушка». У нас тут как бы кроме карт, еще и жетоны в ходу. Более того, карт по сравнению с жетонами ничтожно мало.
он содержал число 2147483647
Имейте привычку подобные данные сразу в хексе смотреть. Я своим намётанным глазом сразу вижу, что это 31 выставленных бит, в хексе это было бы очевидно любому, и мысль о том, что это что-то полезное была бы отброшена сразу.
UFO just landed and posted this here
Не знаю, как в Нижнем, но за день по Тройке в Москве можно наездить на приличную сумму. Стоимость карты (50 руб.) отбивается после нескольких поездок. Заблокировали — выкидываешь карту, покупаешь новую. Почему Вы решили, что это лишено смысла (народ вон боярышником догоняется, а тут обмануть систему «сам Бог велел»)?
Поймите правильно, я против подделок и безбилетного проезда, но для всяких люмпенов даже такая штука, как бесплатный разовый проезд, может иметь смысл
Автор писала, что «на работу с работы» блокировки не было. Или я не так понял
Поймите правильно, я против подделок и безбилетного проезда, но для всяких люмпенов даже такая штука, как бесплатный разовый проезд, может иметь смысл
Автор писала, что «на работу с работы» блокировки не было. Или я не так понял
Ничего нового в статье нет. Уязвимостям сто лет в обед, и о них не говорил разве только ленивый.
Да, уязвимости, действительно, очень простые для воспроизведения. Хотя в данном случае много условий совпало. С Тройкой чуть попроще было.
ps Хм… и ник не простой у девушки… но проверить не могу )
Да, уязвимости, действительно, очень простые для воспроизведения. Хотя в данном случае много условий совпало. С Тройкой чуть попроще было.
ps Хм… и ник не простой у девушки… но проверить не могу )
Я и не претендовала на новизну и сразу на это указала. Меня удивила простота взлома — ведь нам постоянно рассказывают о защищенности смарт-карт, что магнитка — это плохо, например. А тут не просто средний хабраюзер, а вообще чуть ли не рядовой юзер может это делать.
зы и да, у меня есть свой небольшойженский секретик )
зы и да, у меня есть свой небольшой
Уже давно проходил подобный путь, другой город, «классические» карты, ключи MCT подобрал без лишних телодвижений, но видимо существует общая база с не очень частой синхронизацией, и через 3 дня подобных экспериментов карту заблокировали.
Складывается ощущение, что все транспортные системы, где используются транспортные карты, небезопасны. Не хочу рассуждать, почему так происходит (эта тема не для Хабра), остается лишь задать вопрос: кто (какой город) следующий и когда ждать про это статью на Хабре?Что значит 'небезопасны'? Турникеты током бьются?
Задача транспортной системы — перевозить пассажиров, удобно для них и в прибыль себе. А не быть неломаемым crackme.
Мнение, что крутые криптографические алгоритмы сами по себе как-то увеличивают защищенность системы — на 100% дилетантское. Помимо крутости алгоритмов они должны быть еще правильно использованы. И это, увы, не всегда возможно. Причем зачастую причины кроются в удобстве и стоимости, а не в криворукости разработчиков.
В случае карт вашего города с точки зрения защищенности от фрода при конкретной реализации системы безразлично используются ли карты Mifare Plus в уязвимом режиме совместимости, или в 'безопасном' нативном с
Собственно многие исследователи изначально пошли бы вторым путем, ибо проще и не требует дополнительного оборудования. А ключи для записи в сектор через приложение в любом случае пролетают.
И здесь уже простого прикрытия дырки нет. Либо необходимо отказываться от реалтайм-пополнения карты телефоном (-удобство), либо переходить на 100% онлайн-валидацию на турникетах (+стоимость), либо переходить на существенно более дорогой стек карточных технологий, толком никем кроме банков не паханый.
Что значит 'небезопасны'? Турникеты током бьются?
Вы путаете safety и security. Видимо, автор имела ввиду второе, а Вы говорите про первое.
Мнение, что крутые криптографические алгоритмы сами по себе как-то увеличивают защищенность системы — на 100% дилетантское. Помимо крутости алгоритмов они должны быть еще правильно использованы. И это, увы, не всегда возможно. Причем зачастую причины кроются в удобстве и стоимости, а не в криворукости разработчиков.
Зачем эти пафосные гипотетические высказывания? Был бы уровень SL3 и простым сниффингом ничего бы не получилось сделать.
так вытащили бы (как в случае с Тройкой) из приложения пополнения баланса.
Использование правильной смарт-карточной технологии позволило бы не передавать ключи в открытом виде в приложение.
либо переходить на существенно более дорогой стек карточных технологий, толком никем кроме банков не паханый.
Снова неверно. Выше же писали, что плюсы даже дешевле классиков. И другие альтернативы есть.
Так что и стэк есть, и поле пахано уже давно. Просто в России из-за лени, а больше из-за жадности, «авось» и коррупции все продолжают пользоваться устаревшими технологиями.
Зачем эти пафосные гипотетические высказывания?Увы, это совершенно будничная практическая правда жизни. Которую вы активно доказываете.
Был бы уровень SL3 и простым сниффингом ничего бы не получилось сделать.Абсолютно верно, дыру в заборе Plus закроет. Но открытые ворота (в виде ключей в приложении) так и останутся открытыми. Вы действительно не понимаете, что защищенность системы состоит далеко не только из защищенности обмена с картой (и определяется самым слабым звеном) ?!?
Это я и писал. Только плюсы это ни разу не 'другой стек'. Плюсы ничем не помогут, если тем или иным образом будет скомпрометирован единственный ключ. А компрометация этого ключа, если вы хотите иметь возможности работы турникетов в оффлайне и пополнения карты телефоном, неизбежна.переходить на существенно более дорогой стек карточных технологийСнова неверно. Выше же писали, что плюсы даже дешевле классиков.
Из доступных технологий, обеспечивающих и плюшки и безопасность, мне известна только PayPass M/Chip (в части нефинансовых приложений). Но во-первых количество внедрений пока таково, что об обкатанности технологии говорить не приходится, во-вторых это придаток к платежной карте МПС, что далеко не всегда удобно и приемлемо.
Использование правильной смарт-карточной
И другие альтернативы есть.
Так что и стэк есть, и поле пахано уже давно.Расскажите нам об этих картах. Серьезно. Очень интересно и полезно будет послушать.
Только, пожалуйста, не о том, что теоретически наверное можно сделать, если захотеть (и наплевать на косты), а о том, что уже сделано и успешно внедряется т.е. о готовых, обкатанных рынком решениях.
Увы, это совершенно будничная практическая правда жизни. Которую вы активно доказываете.
Чего-чего? Очередной «специалист», который за отсутствием аргументов на личности переходит? Вы тут всех дилетантами обозвали, ярлыков навешали, а сами рассуждаете о вещах, в которых не смыслите, кроме mchip ничего не знаете, видимо (а ведь " за МКАДом тоже есть жизнь"). об этом ниже
Но открытые ворота (в виде ключей в приложении) так и останутся открытыми. Вы действительно не понимаете, что защищенность системы состоит далеко не только из защищенности обмена с картой (и определяется самым слабым звеном) ?!?
это вы не понимаете. Вам доступным языком пишу: использование нормальных карт, например, desfire и даже plus в sl3 не потребует хранить или передавать ключ в приложение. ключ не будет покидать карту вообще.
Расскажите нам об этих картах. Серьезно. Очень интересно и полезно будет послушать
Рассказываю: Mifare Plus (SL3) (желательно EV1), Mifare Desfire, даже Ultralight EV1, есть и другие варианты. Почитайте про то, как происходит аутентификация в картах, вы думаете, ключ плейнтекстом передается? Даже Mifare Classic не так уж и плох, просто из-за проприетарности ну и, наверное, из-за лени, в Android работа c классиком требует ключ плейнтекстом передавать. Но даже и тут есть варианты…
И это готовые, обкатанные рынком решения. Лондонский Oyster для Вас обкатанное решение? С классиков ушли еще в 2011 г. А еще Сидней, Торонто, Ванкувер, Хельсинки, Мадрид… достаточно примеров? Если вы чего-то не знаете, то это не значит, что этого не существует.
То, что в России интеграторы почему-то этого не знают, не умеют и не хотят пользоваться — уже не ко мне вопрос. Нормального специалиста по смарт-картам днем с огнем не сыщешь (я говорю про реальных, а не те, кто себя так называют).
И у Новакард (Ситикард), кстати, приложение лучше сделано, чем московский «Мой проездной», не так просто ключ расковырять.
Почитайте про то, как происходит аутентификация в картах, вы думаете, ключ плейнтекстом передается?
не потребует хранить или передавать ключ в приложение. ключ не будет покидать карту вообще.Понимаете, какое дело: несмотря на то, что сам ключ по воздуху ни в каком виде не летает, когда одна сторона аутентифицирует другую по обоим известному ключу симметричного криптоалгоритма, ключ этот, простите за тафтологию, должен быть известен обоим сторонам. Дальше весь вопрос — кто эти стороны.
Теоретически возможно сделать систему, в которой бы взаимно аутентифицировали друг друга карта и удаленный сервер, а вся остальная инфраструктура была эдаким TCP-удлинителем радиоканала. Mifare нечуствителен к таймингам (одна из фич EV1 как раз контроль таймингов, но пользоваться ей никто не заставляет), поэтому очень вероятно, что это бы работало. Это было бы годным хакерским (в самом хорошем смысле) решением.
Но в энтерпрайз-продуктах хакерские решения не в почете (и свои основания для этого есть). И в реально существующих системах друг друга аутентифицируют карта и локальное приложение. Причем в очень многих (а возможно — и в большинстве) промышленных решениях аутентификация возложена на считыватель карт. В него c помощью псевдо-APDU грузятся ключи, а дальше он сам общается с картой, скрывая от приложения всю криптографию.
Примерно то же и в телефонах: authenticateFirst() и понеслась.
Лондонский Oyster для Вас обкатанное решение?Понятия не имею, что и как сделано в лондонском Oyster. Беглое ознакомление с материалами в инете наталкивает на мысли о том, что там очень качественно сделана централизованная обработка данных о проходах: хитро обсчитываются составные поездки и есть личный кабинет, в котором помимо всего прочего видна история поездок с весьма небольшой задержкой. При такой оперативности централизованной обработки информации фактически не столь уж и критично на чем именно сделана карта: фрод оперативно ловится на сервере, сама карта ставится в блок-лист. Отличный вариант. Но дорогой.
Официального приложения пополнения баланса карты с помощью телефонного NFC я не нашел (особо не искал). Бросите ссылку — попробую посмотреть, что внутри.
И у Новакард (Ситикард), кстати, приложение лучше сделано, чем московский «Мой проездной», не так просто ключ расковырять.Чуть больше obscurity, увы, не добавляют security.
Рано, или поздно все упрется в вызов authenticateFirst(), или даже authenticateSectorWithKeyA().
Во втором случае ключ сразу передается плейнтекстом.
В первом — там конечно keystore и все такое, но даже в самый аппаратный из keystor'ов ключ должен сначала попасть. И в setEntry() он будет передаваться во вполне себе извлекаемом виде (чаще всего — плейнтекстом).
Но в энтерпрайз-продуктах хакерские решения не в почете (и свои основания для этого есть). И в реально существующих системах друг друга аутентифицируют карта и локальное приложение. Причем в очень многих (а возможно — и в большинстве) промышленных решениях аутентификация возложена на считыватель карт. В него c помощью псевдо-APDU грузятся ключи, а дальше он сам общается с картой, скрывая от приложения всю криптографию.
При чем здесь хакерские решения? То, что Вы про ридер описываете, как раз устаревший подход (для лентяев). Откройте, наконец, для себя, что такое SAM-модуль. Все это «хакерство», как Вы называете, разработчиками чипов смарт-карт поддерживается из коробки. И Classic не исключение.
Рано, или поздно все упрется в вызов authenticateFirst()
не знаю про такую функцию в nfc api android. И сам google, похоже, тоже не знает.
Чуть больше obscurity, увы, не добавляют security.
конечно, нет. Но и ключи по base64 тупо не передаются. То есть возни на порядок больше, проще сниффернуть протокол и не заморачиваться.
Поэтому я и писал выше — была бы в основе нормальная карточная технология, и не нужно было бы гонять ключи в открытом виде.
Вы же продолжаете спорить, что-то там придумывать, не зная принципов работы SAM-модулей. Ключи вообще неизвлекаемы и в открытом виде получить невозможно. На аппаратном уровне.
Да, забыл добавить: при правильно спроектированной системе ни разработчик, ни заказчик вообще могут не знать ключей (и так и должно быть) — они генерируются автоматически, хранятся в аппаратном устройстве и наружу вообще никак не «светятся».
Все это «хакерство», как Вы называете, разработчиками чипов смарт-карт поддерживается из коробки.«Хакерство» в смысле «не лишенное изящества недокументированное использование». Если на ваш взгляд этот функционал документирован — потрудитесь привести ссылку на любой whitepaper от NXP, описывающий реализацию (или хотя бы возможность реализации) Mifare-протокола over TCP/IP.
Откройте, наконец, для себя, что такое SAM-модульSAM модуль это немножко сильно про другое. Что в широком смысле, что в частном, NXP'шном: P5DF0xxx это как раз те чудесные приблуды к совместимым ридерам, в которые можно загрузить ключи, и не париться ни в прикладном приложении про работу с криптографией, ни про сохранность ключа при физическом похищении терминала.
Ключи вообще неизвлекаемы и в открытом виде получить невозможно. На аппаратном уровне.Повторяю вам: можно сделать ключи неизвлекаемыми, можно. Для этого даже Mifare SAM не нужен: достаточно хранения AES ключей в аппаратном keystore, имеющемся на многих андроид телефонах. Если mifare sdk внутри реализован правильно (в чем лично у меня сомнений нет) то наружу ключи при этом высовываться никак не будут и можем считать, что они действительно неизвлекаемы (методами доступными подавляющему большинству исследователей). Только толку с этого ноль.
Т.к. ключи эти должны в аппаратный keystore сначала как-то попасть.
Их ведь не будут зашивать туда при производстве телефона. И врядли кто-то согласится ценной бандеролью отсылать телефон в дептранс на загрузку ключей.
Увы, единственный реальный вариант — загрузить их туда тем самым приложением из плей-маркета, которое и будет дальше работать с картой.
И вот в этот момент их и нужно перехватывать во всей их незащищенности.
О чем собственно в предыдущем посте и написано.
Естественно не знает. Потому что ее там нет.Рано, или поздно все упрется в вызов authenticateFirst()не знаю про такую функцию в nfc api android. И сам google, похоже, тоже не знает.
Вы же вроде с SL3 работать хотели? А SL3 Android NFC API сам по себе не умеет. NXP'шный SDK нужен.
SDK и дока по нему доступны после регистрации в NXP, как разработчика Mifare-based решений. Раньше процедура была простой формальностью, сейчас думаю тоже.
Странно, что профессионал по смарт-картам и адепт SL3 об этом не в курсе.
Для себя делаю вывод, что вы либо тролль, либо. В обоих случаях дискуссию поддерживать бесполезно.
Да нет, тролль — это Вы. Рассказал про SAM — побежали, поизучали быстренько, вернулись, начали про другое говорить.
Я сразу писал — что Classic настолько проприетарен, что с ним все сложнее.
Попытка меня развести на witepaper — вот это и есть троллинг 80 левела. Ведь спеки NXP под NDA, и их раскрытие — раскрытие NDA.
Бгг. Ну что ж, продолжим ликбез. Про SAM я вас научил (в благодарность меня обозвали нелицеприятным образом, но этому я не удивлен — ведь признаться в своем невежестве мало кому хватает мужества), теперь идите учите, что такое eSE…
Вот и я про то же, а мне в ответ радостно — «а что ж ты не знаешь, что ли, про NXP Mifare SDK». А я-то говорил про нативное апи.
Мы делали реализацию как раз аутентификации по TCP/IP, нормальная карта умеет обмениваться данными с ридером, а ридеру все равно, какие команды выполнять — какие ему отправишь, те они и отправит на карту.
Поэтому ваш тезис о невозможности не грузить в ридер ключи разбит в пух и прах. В android-приложении ключа нет, и даже в keystore его грузить не надо. Конечно, при условии, что это нормальная карточная технология. А Вы мне все про Mifare Classic твердите, вскрыть ключи для которого можно, не имея самого ключа.
В общем, идите, учите матчасть лучше, чем обзываться («кому не хватает аргументов — переходят на личности»).
Я сразу писал — что Classic настолько проприетарен, что с ним все сложнее.
Попытка меня развести на witepaper — вот это и есть троллинг 80 левела. Ведь спеки NXP под NDA, и их раскрытие — раскрытие NDA.
Их ведь не будут зашивать туда при производстве телефона.
Бгг. Ну что ж, продолжим ликбез. Про SAM я вас научил (в благодарность меня обозвали нелицеприятным образом, но этому я не удивлен — ведь признаться в своем невежестве мало кому хватает мужества), теперь идите учите, что такое eSE…
Естественно не знает. Потому что ее там нет.
Вот и я про то же, а мне в ответ радостно — «а что ж ты не знаешь, что ли, про NXP Mifare SDK». А я-то говорил про нативное апи.
Мы делали реализацию как раз аутентификации по TCP/IP, нормальная карта умеет обмениваться данными с ридером, а ридеру все равно, какие команды выполнять — какие ему отправишь, те они и отправит на карту.
Поэтому ваш тезис о невозможности не грузить в ридер ключи разбит в пух и прах. В android-приложении ключа нет, и даже в keystore его грузить не надо. Конечно, при условии, что это нормальная карточная технология. А Вы мне все про Mifare Classic твердите, вскрыть ключи для которого можно, не имея самого ключа.
В общем, идите, учите матчасть лучше, чем обзываться («кому не хватает аргументов — переходят на личности»).
Вообще, Zolg забавный товарищ. Попросил привести примеры крупных обкатанных проектов, где не используется Classic — привел. Нет, недостаточно, начал рассказывать, что все равно ключи плейнтекстом передаются.
Рассказал, что это не так, что все нормальные проектировщики делают так, что ключи наружу вообще не выходят. Нет, тоже ему не понравилось. Про его конфуз со сторонней authenticateFirst я выше написал…
В общем, еще и троллем меня обозвал (стандартный прием троллей). Нет, тут я уже умываю руки. Бисера на всех не напасешься…
Рассказал, что это не так, что все нормальные проектировщики делают так, что ключи наружу вообще не выходят. Нет, тоже ему не понравилось. Про его конфуз со сторонней authenticateFirst я выше написал…
В общем, еще и троллем меня обозвал (стандартный прием троллей). Нет, тут я уже умываю руки. Бисера на всех не напасешься…
Раз в неделю black list пополняется номерами крякнутых карт и ваш трюк больше не сработает. Неделя — условный период, разный для разных городов.
Выбрасывается карта, покупается новая — и все по новой. Банквоские карты тоже блокируются при обнаружении кражи, только за это время злоумышленники часто успевают вывести деньги или их часть. Банки, наверное, примерно также рассуждают («black list пополняется номерами крякнутых карт и ваш трюк больше не сработает»)
И ни единого предложения выйти замуж.
Очень приятно было читать, написано грамотно, сейчас это редкость.
Очень приятно было читать, написано грамотно, сейчас это редкость.
UFO just landed and posted this here
Спасибо за статью, но удивляться тут не стоит. Заказчиком и оператором таких систем выступает, обычно, какой-нибудь ГУП, в котором работают люди очень мало понимающие в технике. К сожалению, они часто не понимают что у них написано в их собственном ТЗ и на простые вопросы отвечают неделями. Подобные системы, обычно строятся многими компаниями, кто-то делает вилидаторы, кто-то карты кодирует, кто-то софт пишет, т.е. каждый разработчик знает только свою часть системы. Координируют это сотрудники ГУП-ов и в итоге у них получаются дыры в разных частях, т.к. у них просто нет людей способных оценить безопасность системы в целом.
Удивляться стоит тому как вообще эти системы работают при тамошнем уровне бюрократического маразма.
Удивляться стоит тому как вообще эти системы работают при тамошнем уровне бюрократического маразма.
А каким смартфоном пользовались?
Sign up to leave a comment.
«Шо, опять?» или взлом транспортных карт «Ситикард» (Нижний Новгород)