Проверка целостности j2me_domain_registry.sm, Два вопроса Поделиться Опции

[Ponemetski]

Меня уже месяц мучает вопрос. Есть несколько прошивок в которых используется новый формат файла j2me_domain_registry.sm Наиболее изученая наверное EOR от V360.
А теперь внимание вопрос можно ли выдраты из неё код проверки подписи файла j2me_domain_registry.sm?
И сразу еще один. Зная алгоритм проверки, почему мы не можем получить алгоритм подписывания? И сделать свой j2me_domain_registry.sm с правами для untrusted приложений?
Заранее спасибо за ответы

[UzAr]

В подписи RSA с ключом делаются необратимые перобразования, даже зная алгоритм преобразования и полученное из этого ключа с помощью алгоритма слово, мы не можем получить ключ. Для этого нужно факторизовать число, на что с нашим уровнем развития математики и высоких технологий уйдет несколько лет Ну может я и пербрал, но что-то около того... Да да, такие вот умные математики, что придумали алгоритм, который нельзя пустить в обратную сторону

[Ponemetski]

Прочитав десять раз первое предложение понял, алгоритм проверки один, а подписи другой... так?

вот как я думал:

функция, скажем, md5 - необратимое хеширование (просто для примера)
md5("123456") вернет скажем 52dd04eb6e0c52abf7c14be841509e52
md5("12345") вернет скажем abf7c14be841552dd04eb6e0c5209e52

подпись хранится в самом файле так? так, иначе операторам нельзя было бы их менять.

файл j2me_domain_registry.sm
[0, 255] подпись
[256, +oo] данные, табличка разрешений

как идет проверка?
boolean good_signature = md5(промежуток [256, +oo]) == промежуток [0, 255]

то есть не надо обращать алгоритм в обратную сторону, просто им же прогнать по данным и полученное записать в начало вместо подписи.

если я гоню, так и скажите, но пажуйста аргументированно

[UzAr]

Нет, алгоритм и проверки и подписи один. Берется исходный ключ и какой либо параметр, например время, который дописывается к ключу. Пототом две стороны пропускают их через алгоритм и получают некий набор символов. Этими символами сверяются и могут, проверить правильность ключа друг у друга, не передавая его. Третья же сторона заполучив сверяемое слово и зная алгоритм, ни коим образом не сможет получить ключ. Полученное же ею слово устаревает, в связи с меняющимся временем.
На самом деле, сейчас, я описал работу схемы "свой чужой", но, на сколько я знаю, это примерно похожие схемы. Просто криптографию на должном уровне нам еще не читали....

Сообщение отредактировал UzAr - 27.4.2007, 15:39

[UzAr]

Словом я обозвал набор символов, полученный преобразованием ключа и доп.параметра с помощью алгоритма. Время нужно, чтобы враги не могли подсунуть тупо скопированный набор символов. Дело в том, что этот набор меняется вместе со временем, причем высчитать зависимость невозможно... Еще раз повторяю, я описал схему работы системы "свой-чужой". Подробнее про RSA защиту ищи тут

[Ponemetski]

Я уже там. Но разве этот файл подписан с помощю РСА (не знаю как правильно сказать)? В лоб ломать не получится это я понимаю.
Ладно, иду RTFM

[lucrece]

UzAr, конечно, почти все неверно Шифрование несимметричное. Считается хэш (SHA-1 всего вероятнее) и затем шифруется закрытым ключом. Это и будет подпись, комплектуемая открытым ключом. Для проверки целостности подписанного файла она расшифровывается этим открытым ключом и полученный хэш сравнивается с хэшем проверяемого файла. Т.е., не зная закрытого ключа, нельзя получить корректную подпись. Взлом технически невозможен, но думается, возможен обход по типу отмены проверки подписи корелетов.

[UzAr]

Как я понимаю, взлом защиты RSA состоит в том, чтоб просто отключить эту проверку на уровне прошивки, над чем сейчас собственно и бьются... Я тока на первом курсе факультета мобильной радиосвязи и мультимедиа, поэтому многого не знаю Но к курсу 3 обещаю, что стану одним из самых упорных копателей Мотофана

[Ponemetski]

UzAr, lucrece, спасибо понял.
тему можно переместить в раздел взлом рса или закрыть