
Эксперт
  
Профиль
Группа: Комодератор
Сообщений: 1214
Регистрация: 18.3.2005
Где: St.Petersburg
Репутация: 19 Всего: 27
|
Цитата | Данная статья особенно будет полезна для новичков, а так же для тех кто не работал с сертификацией мидлетов или не использовал способы передачи данных через защищенные соединения в j2me. (примечание javastic) |
Вопрос: (Zamuta)Цитата | 1. Каким вы считаете наиболее безопасный метод передачи информации до сервера (пароли, логины, ключи):
1. Телефон->посредством технологии sms->оператор моб.связи->интернет->сервер ? 2. Телефон->ssl защита->оператор моб.связи->интернет->сервер ?
2. Какой сертификат просит телефон перед запуском моего приложения?
3. Можно ли сделать так чтобы приложение по умолчанию имело доступ к gprs соединеню и не запрашивала разрешения пользователя? |
Ответ: (Dancer)Цитата | Значить так, как и обещал. (наконец то руки добрались) Приложение может использовать API для соединения с каким либо ресурсом и т.д. используя GPRS, посылать SMS ну и много чего ещё подобного, но кто убережёт простого пользователя от нехорошего Васи Пупкина? Василий, котырй в своё приложение каждый раз при запуске вставляет отправку SMS на какой нибудь номер, отчего этому Васи на какой-нить его счёт бабки приходят, ну или просто парень так развликается, нравиться ему людей "на бабки разводить" (по приколу это ему). Вот для это и существует такая система, что мидлет, который не прошёл сертификацию у производителя (то есть не получил ключа, который помещается в JAD, а это не что иное как CRC SHA кодированный для манифеста по размеру приложения; кстати, по этой причине и должны совпадать значения переменных в манифесте и JAD, если JAD подписывается), будет использовать API с ограничениями. Например, неподписанное приложение всегда будет требовать от пользователя разрешения на соединение с каким либо ресурсом HTTP (причём на выбор давая пользователю: разрешать в течении работы всего приложения; всегда спрашивать; запретить на данный запуск; запретить навсегда, ну и т.д. для некоторых API списочек другой) Если мидлет подписан (то есть ключ на данный мидлет предоставлен производителем телефона, и подходит под определёные сертификаты, которые производитель зашил жёстко в телефон), то такому мидлету можно доверять и можно запускать API без запроса разрешения от пользователя.
Как происходит подписание: это ни что иное, как и подписание Java Applet. В мидлетах механизм тот же. используя keytool генерируется некий файлик (keytool -genkey и куча всяких параметров), далее при помощи этого файлика мы и подписываем наш мидлет передавая команде keytool наши JAD и JAR и файлик сгенирированный ранее. В данном файлике мы как раз и указываем, кто у нас и где. В мидлете, мы в JAD прописываем в поле "MIDlet-Permissions:" навания классов, которые будут использоваться без запроса нотификации от пользователя, при условии что мидлет будет подписан. В этом поле могут быть так же и классы, которые используются лишь конкрентым производителем, и чтобы ихнее API нельзя было это использовать кому попало, есть сертификат (прошитый в телефон на заводе, ну или сам положешь , если знаешь куда и знаешь какой ) на основании этого сертификата разрешаем коду выполняться, а если мидлет будет не подписан, то данный код выоплняться не сможет будет возникать ошибка времени выполнения (ну, или как уж её будут обрабатывать в самой операционки телефона)
Так же при помощи сертификата можно выполнять проверку на срочность (то есть проверку на дату, и например после определённой даты не давать запускать мидлет, или пользовать API)
!!!! SSL и HTTPS можно использовать лишь на подписаных мидлета (по крайней мере на Мотороле и Нокии - это так)
Да, про 1 пункт, простым смертным придётся использовать не SSL, но можно самому шифровать данные на стороне мидлета (ключ к шефрации/дешифрации выдавать на картах, вроде пополнения счёта, для каждой выпущенной карты имеется информация в БД на сторне сервера) и ещё, сначала в сообщение даётся нешифрованное имя пользователя, ну или ID для определения выбора ключа на стороне сервера, так же имя пользователя должно быть и в шифрованной записи, чтобы определить, дешифровалось ли нормально на стороне сервера, к тому же проверочное имя пользователя можно или даже лучше ставить в конец шированного сообщения, чтобы при получении быть точно уверенным что сообщение целиком доставлено; или использовать шифрацию с открытым ключом. Для всего выше описнного не обязательно использовать SMS можно и поверх HTTP это организовать или использовать Socket.
|
Автор: DancerЭто сообщение отредактировал(а) javastic - 15.8.2007, 10:27
--------------------
01101010 01100001 01110110 01100001 01110011 01110100 01101001 01100011 scjp, mcp
|