Почему-то принято писать о «бинарных SMS» как о каком-то простом деле, которое труда не составляет. В действительности такой вектор стоит упоминания только при совпадении нескольких факторов:
Оператор имеет в сети уязвимые карты и не контролирует трафик бинарных SMS (что маловероятно после репорта Карстена Ноля)
Атакующему-таки удалось подобрать все необходимые ключи к карте
Атакуемая карта поддерживает Java *
* — Без этой поддержки картой Java единственное направление атаки — это DoS, что тоже очень плохо, но, по крайней мере, сразу заметно.
Остроумно, как раз наткнулся на нее, пока писал статью и смотрел, что еще есть по теме. Но не вижу смысла добавлять внешние зависимости в свои скрипты, пока не столкнулся с реальными ограничениями стандартной библиотеки.
Не проще, чем PC в корпусе размером меньше спичечной головки. С OC, JVM и/или другим рантаймом (опционально), с файловой системой, в которой, в среднем, сконфигурировано порядка 100 файлов.
Судя по патетическому описанию, карта будет в формфакторе MFF2 и «профиль оператора» будет грузиться на нее динамически, в зависимости от страны пребывания устройства (для этого придется использовать централизованную платформу и предварительную договоренность множества операторов всего мира). Других решений на сегодня не изобрели, насколько мне известно.
Насчет смены поставщика услуг связи — это маловероятно — если Вы купите некое устройство с внедренной картой, то, скорее всего, клиентом оператора будете не Вы, а производитель или импортер устройства.
RUIM не пробовал, а USIM — да. Здесь я принципиально не стал касаться USIM, чтобы избежать ненужных усложнений, поскольку кардинально нового (по сравнению с изложенным) в них нет, просто эволюционные изменения, более системный подход к разработке спецификаций.
Но и самих спек больше и прыгать между ними нужно чаще (это в минусы).
С точки зрения операторов она не лишняя.
Это возможность предложить всем своим абонентам VAS и предоставить доступ к своим сервисам. Основное преимущество карточных Java апплетов для операторов в контролируемости этих преложений и возможности донести их до максимального числа абонентов.
Кроме того Java позволяет унифицировать приложения — однажды разработанный апплет может, в общем случае, работать на картах разных вендоров. По сравнению с этим, нативные (не Java, а C или ASM) приложения, которые разрабатываются, как правило, самими вендорами, представляют, как правило, много больший геморой по срокам внедрения.
Кроме того Java, как раз, не обязательный атрибут карты — надо смотреть на рыночное предназначение карт.
* — Без этой поддержки картой Java единственное направление атаки — это DoS, что тоже очень плохо, но, по крайней мере, сразу заметно.
не такая уж маята по-моему.
Насчет смены поставщика услуг связи — это маловероятно — если Вы купите некое устройство с внедренной картой, то, скорее всего, клиентом оператора будете не Вы, а производитель или импортер устройства.
К примеру,
сам раньше использовал только %, сейчас перехожу на .format() — для меня тут больше гибкости.
Но и самих спек больше и прыгать между ними нужно чаще (это в минусы).
Это возможность предложить всем своим абонентам VAS и предоставить доступ к своим сервисам. Основное преимущество карточных Java апплетов для операторов в контролируемости этих преложений и возможности донести их до максимального числа абонентов.
Кроме того Java позволяет унифицировать приложения — однажды разработанный апплет может, в общем случае, работать на картах разных вендоров. По сравнению с этим, нативные (не Java, а C или ASM) приложения, которые разрабатываются, как правило, самими вендорами, представляют, как правило, много больший геморой по срокам внедрения.
Кроме того Java, как раз, не обязательный атрибут карты — надо смотреть на рыночное предназначение карт.