Так вот.
Абонент А начинает транзакцию. Вводит УНИКАЛЬНОЕ 14ти значное число, биллинг оператора отмечает это число как использованное и только тогда пополняет баланс абонента.
Допустим, только допустим что удалось перехватить код, но уже будет поздно и второго отшибут. И при этом запишут что была неудачная попытка. После N попыток номер блокируется и попадает на рассмотрение к группе специально подготовленных для борьбы с такими абонентами людей. Ну а в случае рецидивов то и к СБ.
Упреждая возможные догадки скажу что пусть у оператора 10 000 000 готовых к активации кодов оплаты. это всего 8 знаков. Шанс угадать минимален, см выше кто анализирует такую деятельность.
Кстати.
«IMEI у буржуев может к симке быть привязан (напрмер, если теелфон с тарифным планом и т.п.»
Оператору не выгодно ограничивать использование терминалов. Ну сломалась труба, абоненту надо ехать в офис, бороться с бюрократией и не приносить денег конторе. Буржуи конечно дураки но не настолько ))
Блокируют как раз терминалы для использования в какой то сети, вспомним айфон.
Опубликуйте гарантированный способ получения KI из современных сим-карт и есть шанс заработать денег на безбедную жизнь до самой смерти. Таких карт которые не сложно клонировать уже лет 5 как не выпускают.
Часть между BS и MS всегда шифрована. Можно почитать про алгоритмы A5/1 и A5/2.
Да и остальные участки шифруются в случае скажем передачи SMPP или сигналки через интернет.
Then, the firmware can be modified and information such as the IMEI (International Mobile Equipment Identity) number can be changed as well as the IMSI (International Mobile Subscriber Identity) number, which allows a phone to register itself with an operator.
IMSI в мобильных терминалах не хранится.
И зачем менять IMEI? Он виден только владельцу терминала и оператору. Другой стороне он никак попасть не может. Зачем анализировать? Возможно молучить mTAN только на определенную пару IMSI-IMEI? Сомневаюсь.
For the final step, the hacker must also clone a SIM (Subscriber Identity Module) card, which Becker said is technically trivial.
Это как? Склонировать симку нетривиальная задача. Да и при условии наличия доступа к ней это маловероятно. Для прочтения Ki требуется ввести ADM код. А в новых симках встроен механизм защиты от брутфорса. О перехвате данных необходимых для регистрации в сети «из воздуха» можно только мечтать, алгоритмы достаточно стойкие.
Как раз таки и не было. CBOSSу в этом случае зачет.
Версионность реализована была на undo сегментах, это так называемая «непротиворечивость считывания». Подробнее у дяди Кайта почитать можно. Для постоянного хранения данных этот механизм не подходит. Потому что при активной записи в базу старые данные затираюся.
Кстати, аналогичная технология используется в движке InnoDB, так что MySQL это давно умет.
«Нормальная» версионность, как в Interbase, появилась в 11й версии Оракла. И пока я не слышал о крупных продуктах мигрировавших на него. Если есть — подскажите.
В версиях 9 и 10 оно работает на undo сегменах. Ясно что совсем недолго данные хранятся.
С 11й версии оно заработало нормально под названием Flashback, судя по документации, сам не проверял.
Почитать можно здесь
Возможно к этому решению стоит добавить булево поле active_version и сделать по нему btree индекс.
Не факт, но может ускорить работу с актуальными версиями.
А так, предложенная схема вполне работоспособна.
Удобно.
С другой стороны. Дали питание, подождали 15 минут, отрубилось питание. И так несколько раз за ночь с промежутком в 15 минут к примеру )) Автоматизация — палка о двух концах.
Да. Могу привести пример продукты Alcatel-Lucent.
Они сделали биллинг(!) для GSM операторов на мускле. И до определенного объема данных оно работало. Посчастливилось некоторое время поадминить эту систему.
Кстати, в таблицах с типом InnoDB было до 125*10^6 записей.
>клиент-серверную архитектуру
имел в виду соединение через сокеты
>разделение прав пользователей
Гранты на базы для различных пользователей. Очень даже используются.
Вот еще пример не простого использования мускл.
Так вот для таких целей Embedded InnoDB не подойдет
Это больше ориентировано на минималистичные приложения, на те где не требуется клиент-серверная архитектура, разделение прав пользователей, и такие сложные элементы как триггеры, хранимые процедуры и прочее.
Абонент А начинает транзакцию. Вводит УНИКАЛЬНОЕ 14ти значное число, биллинг оператора отмечает это число как использованное и только тогда пополняет баланс абонента.
Допустим, только допустим что удалось перехватить код, но уже будет поздно и второго отшибут. И при этом запишут что была неудачная попытка. После N попыток номер блокируется и попадает на рассмотрение к группе специально подготовленных для борьбы с такими абонентами людей. Ну а в случае рецидивов то и к СБ.
Упреждая возможные догадки скажу что пусть у оператора 10 000 000 готовых к активации кодов оплаты. это всего 8 знаков. Шанс угадать минимален, см выше кто анализирует такую деятельность.
«IMEI у буржуев может к симке быть привязан (напрмер, если теелфон с тарифным планом и т.п.»
Оператору не выгодно ограничивать использование терминалов. Ну сломалась труба, абоненту надо ехать в офис, бороться с бюрократией и не приносить денег конторе. Буржуи конечно дураки но не настолько ))
Блокируют как раз терминалы для использования в какой то сети, вспомним айфон.
Да и остальные участки шифруются в случае скажем передачи SMPP или сигналки через интернет.
IMSI в мобильных терминалах не хранится.
И зачем менять IMEI? Он виден только владельцу терминала и оператору. Другой стороне он никак попасть не может. Зачем анализировать? Возможно молучить mTAN только на определенную пару IMSI-IMEI? Сомневаюсь.
Это как? Склонировать симку нетривиальная задача. Да и при условии наличия доступа к ней это маловероятно. Для прочтения Ki требуется ввести ADM код. А в новых симках встроен механизм защиты от брутфорса. О перехвате данных необходимых для регистрации в сети «из воздуха» можно только мечтать, алгоритмы достаточно стойкие.
Мутно и непонятно.
Версионность реализована была на undo сегментах, это так называемая «непротиворечивость считывания». Подробнее у дяди Кайта почитать можно. Для постоянного хранения данных этот механизм не подходит. Потому что при активной записи в базу старые данные затираюся.
Кстати, аналогичная технология используется в движке InnoDB, так что MySQL это давно умет.
«Нормальная» версионность, как в Interbase, появилась в 11й версии Оракла. И пока я не слышал о крупных продуктах мигрировавших на него. Если есть — подскажите.
С 11й версии оно заработало нормально под названием Flashback, судя по документации, сам не проверял.
Почитать можно здесь
Не факт, но может ускорить работу с актуальными версиями.
А так, предложенная схема вполне работоспособна.
С другой стороны. Дали питание, подождали 15 минут, отрубилось питание. И так несколько раз за ночь с промежутком в 15 минут к примеру )) Автоматизация — палка о двух концах.
А он может корректно гаснуть по команде от УПСа?
Они сделали биллинг(!) для GSM операторов на мускле. И до определенного объема данных оно работало. Посчастливилось некоторое время поадминить эту систему.
Кстати, в таблицах с типом InnoDB было до 125*10^6 записей.
>клиент-серверную архитектуру
имел в виду соединение через сокеты
>разделение прав пользователей
Гранты на базы для различных пользователей. Очень даже используются.
Вот еще пример не простого использования мускл.
Так вот для таких целей Embedded InnoDB не подойдет