id: Гость   вход   регистрация
текущее время 06:30 20/04/2024
Автор темы: rd384762, тема открыта 10/10/2013 04:47 Печать
Категории: софт, приватность, инфобезопасность, атаки, исходные тексты, защита im, человек посередине, otr
https://www.pgpru.com/Форум/ПрактическаяБезопасность/ЗащищенныйМобильныйOpenSouceJavaJ2MEМессенджерCipherJ2meMessenger
создать
просмотр
ссылки

(?) Защищенный мобильный OpenSource Java (J2ME) мессенджер "Cipher j2me messenger"


Всем привет!


Не так давно нашел интересный проект (интернет-мессенджер) с открытыми исходными кодами (OpenSource) под названием "Cipher j2me messenger" для мобильной платформы Java (J2ME). Разработчик программы – jangozo (Vladimir Stariradev).


В описании на официальном сайте проект характеризуется как: "Программа, которая призвана обеспечить решение проблемы безопасной связи в мобильной среде для всех мобильных устройств.". И тут же следом указано: "Он был подготовлен во время программного проекта и функционал на эмуляторе Java WTK, однако многое еще предстоит сделать." (не силен в английском, это автоматический перевод, оригинал – "It was produced during a software project and is functional on the Java WTK emulator, however more work is needed.").


Насколько мне известно, до сих пор не было создано ни одного открытого (OpenSource) интернет-мессенджера для мобильной Java (J2ME), который бы поддерживал шифрование от клиента до клиента, без возможности чтения сообщений сервером. Думаю, многие знают такой OpenSource проект как Bombus для J2ME c поддержкой протокола Jabber (XMPP) и наверное тут можно еще привести другие мессенджеры для J2ME с открытым исходным кодом – Open Source Softwares for Mobile Phone. Но во всех этих мессенджерах, даже если где-то и есть шифрование сообщений (как на том же Bombus можно настроить SSL для джаббера), не смотря на защиту на канале связи, любой сервер (тот же Jabber XMPP) может читать все передаваемые сообщения.


В проекте же, который я указал в названии темы (Cipher j2me messenger) вроде бы как раз реализуется шифрование от клиента до клиента (видимо наподобие OTR (Off-the-Record messaging)), исключая возможности прослушки сообщений на канале связи (включая и сервер). Мой английский к сожалению подходит лишь для наиболее общего представления о тексте.


На странице с файлами мессенджера https://sourceforge.net/projects/cipherj2memsgr/ можно скачать архив, в котором лежит презентация проекта в ".pptx" и файл "Диссертация" в PDF. Диссертация содержит около 60 страниц текста с подробным описанием проекта, включая формулы. На русском языке найти что-то по данному проекту я не смог (видимо о нем просто пока еще мало кто знает). Насколько я понял, используется система с открытыми и закрытыми ключами (как уже говорил, напоминает всем известный OTR (Off-the-Record messaging)).


Процитирую еще момент из файла "Диссертация" насчет атаки полным перебором (Brute-force attack) применительно к этому проекту (Гугл-переводчик):


"5.8.4.5 Атака полным перебором
Эта система была разработана, чтобы сделать попытку перебора любую клавишу вычислительно
неосуществимым. Два симметричных шифров, используемых в системе (RC4 SSL Люкс и AES) оба используют 128
битными ключами. Это означает, 2128 попытки должны быть сделаны для того, чтобы опробовать все возможные 128 битным ключом комбинаций, которые, как полагают, в недоступном для современных вычислительных возможностей.
Кроме того, нарушение такого ключевого бы раскрыть только один клиент-клиент или клиент-серверной сессии.
Арьен К. Ленстре и Эрик Р. Verheul (Ленстре, А. & Verheul, E. (2010)) заявили, что в машине
2009 стоимостью $ 250 млн будет в состоянии сломать асимметричной 1024-битного ключа RSA в день. В то время как стоимость таких машин снизилась на сегодня, затраты на разрыв такой ключ все еще
чрезвычайно высока. Если клиент хотел дополнительной безопасности, он / она может зарегистрировать новую учетную запись периодически, поэтому возобновить RSA ключ, используемый."


Оригинал этой цитаты на английском:
"5.8.4.5 Brute-force attack
The system has been designed to make the attempt of brute-forcing any key computationally
unfeasible. The two symmetric ciphers used in the system (SSL suite’s RC4 and AES) both use 128
bit keys. This means 2128 attempts would have to be made in order to try out all possible 128 bit key
combinations, which is considered to be out of reach for modern computing capabilities. In
addition, breaking such a key would uncover only a single client-client or client-server session.
Arjen K. Lenstra and Eric R. Verheul (Lenstra, A. & Verheul, E. (2010)) have stated that a machine in
2009 costing $250 million would be able to break an asymmetric 1024-bit RSA key in a day. While
the cost of such a machine has dropped by today, the cost towards breaking such a key is still
extremely high. If a client would like extra security, he/she could register a new account periodically,
therefore renew the RSA key used."


В общем, хотелось бы услышать мнения знающих людей, в том числе хорошо владеющих английским языком, кто мог бы ознакомиться с текстами диссертации и презентации и дать оценку проекту. Учитывая, что подобных проектов для мобильной Java (J2ME) (именно с открытыми исходными кодами) видимо просто нет, данный проект можно сказать просто уникален. А мобильных телефонов, где поддерживается только мобильная Java (J2ME) еще очень много, думаю у всех найдутся близкие, друзья, знакомые, которые до сих пор консервативно не желают переходить на какой-нибудь из новых телефонов под Андроидом, iPhone или тем более WindowsMobile и т.п., или даже многие из нас до сих пор пользуются такими телефонами, потому что просто удобно и нет желания переходить на скажем так не очень защищенный и популярный для хакеров Андроид или не очень защищенный iPhone, учитывая еще и их закрытость (проприетарность; для Андроида конечно в меньшей степени) (хотя причины самые разные конечно бывают). Кроме того, J2ME – это почти народная экосистема для практически всех мобильных устройств. Еще помниться, читал здесь же на форуме кто-то писал (не смогу привести ссылку на посты), чтобы было бы классно иметь PGP/GPG на мобильной Java (J2ME) и даже вроде бы кто-то хотел заняться реализацией. Ну а здесь мы возможно имеем один из возможных уже готовых вариантов обеспечения защиты онлайн сообщений на J2ME.


Пробовал запускать мессенджер (файл SecureIM_MIDP.jar из папки Cipher Messenger/SecureIM_MIDP/dist) на компьютере через эмулятор J2ME MicroEmulator, но пока ничего толком не понял, выходит сообщение о попытке соединения с сервером. Как настраивать, как использовать программу на телефоне пока не понятно.


Я попытался сегодня связаться с разработчиком на странице комментариев:


"Hi! Very interested in your program. Poor understand English and not everything is clear from the presentation and Dissertation. Were the tests of your program on real J2ME phones? What models of phones with J2ME support only supported? As I understand it, the principle is similar to the OTR encryption ( see Off-the-Record Messaging )? What is used as an intermediate server? Some common public server? Could you write a simple guide to what to do to use the program on J2ME-phone? Which file from the archive should be placed in a J2ME-phone, how to set up and everything else with illustrations. Of course we would like to ensure that your development has become popular because many more mobile devices in the world, continue to use the medium where possible to run J2ME applications only (not iPhones and phones with Android OS), and your development is quite unique in this way. "


с вопросами и просьбой более простой инструкции, но может быть кто-то, кому интересно, могли бы подключиться к обсуждению этого мессенджера на основе информации, представленной в диссертации и презентации из архива файлов проекта. И думаю, есть смысл поддержать данный проект.


 
Комментарии
— SATtva (10/10/2013 11:30)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
The two symmetric ciphers used in the system (SSL suite’s RC4 and AES)

Какой-то очень странный выбор. Чем он обусловлен? Если разработчик использует в системе ненадёжный алгоритм, не приводя исчерпывающего обоснования такого решения, — это дурной знак о надёжности дизайна в целом.
— тестерТьюринга (11/10/2013 07:59)   профиль/связь   <#>
комментариев: 301   документов: 8   редакций: 4

Как Вы уже заметили, нет выбора приложений с таким функционалом. Даже если б их было много, то вопрос доверия к реализации/автору остается. Если готовы нужную прогу собирать на коленке, то ройте в следующих направлениях.
1. пример тривиального клиент-серверного обмена данными, думаю, найдете сами.
2. примеры шифрования для J2ME: тыц, тыц
3. если провайдер использует NAT: тыц
резюме: адрес абонента имеет вид _http://статический_ip_адрес/динамически_присваиваемый_порт
трудность заключается в определении этой текущей комбинации.
4. для решения проблемы предыдущего пункта нужен сервер со статическим ip-адресом или с зарегистрированным доменным именем. Варианты трехстороннего взаимодействия(два клиента и сервер) очень разные. Возможно, например, оставлять сообщение с текущей комбинацией ip-адрес/порт в зашифрованном виде. Но это не исключат необходимости узнавать ее клиентом самостоятельно. Поэтому стандартным решением для ip-телефонии является sip-сервер. Важно понимать, что спецификация SIP-протокола предусматривает разделение протокола установления соединения и протокола передачи данных. В сторонней реализации могут появиться ошибки, приводящие к различным атакам. Моё мнение: лучше иметь собственную простенькую реализацию, о которой не знают посторонние.

ps где-то читал, что появилась контора, которая заявила свои права на sip-протокол и требует отчислений
— Гость (14/10/2013 14:18)   <#>
MidletPascal если чо.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3