Google Android - это несложно

Добрый день. Настал такой вопрос, после разработки мессенджера для вк, нужно внедрить AES шифрование. Может кто то уже использовал и может поделиться опытом. Сам принцип работы шифрования прекрасно понимаю в сетях, но как это будет в приложении, плохо представить. Сама передача ключа для дешифрования и само зашифрованное сообщение. Поскольку это не личный мессенджер, а на основе вк, но можно подойти к заданию очень примитивно. Допустим вывод зашифрованного сообщения с окна самой переписки с клиентом. А разшифрованное сообщение будет выходить в другом окне, или поле.

Само по себе шифрование сообщений бесполезно, если их не может прочитать никто, ровно на столько же, на сколько, когда их может прочитать любой правда?. Здесь важно определить авторизованного пользователя/устройство на котором должна сработать decrypt. Т.е. вам нужно использовать алгоритм с реализацией открытого и закрытого ключей, где открытый будет использован для чтения, а закрытый для редактирования, т.е. именно в качестве "пароля" при шифровании методом AES. Более того устройство клиента не должно иметь никакого представления о генерации ключей и тем более доступа к закрытому. Т.е. суть простая, используюя sha 256 (в java это все давно реализованно и есть стандартные библиотеки) вы генерируете ключи на сервере и выдаете пользователям, далее при шифровании сообщений именно эти ключи и используются и пользователь автоматом имеет доступ к своему контенту. Также он может поделиться открытым ключем с другом, т.е. предоставить ему доступ на чтение. Все сообщения и их обработка должна быть на сервере. А вообще литературы в сети куча, как и реализаций, потому это и относится к сфере безопастности, что придется самому думать, как это делать исходя из имеющихся инструментов(т.е. проверенных алгоритмов). Но основная задача ваша -это наиболее слабое место - пароль пользователя. Sha256 нужен не только для того. чтобы "усложнить" его пароль и сделать надежным, но и для того, чтобы все эти "махинации" были за кадром и пользователь один раз зарегестрировавшись просто получал результат, не вводя пароли и не паря себе мозг. И кстати о возможности востановления данных в случае потери доступа к устройству - лучше забыть иначе реальной безопастности не будет.

Поскольку это не личный мессенджер, а на основе вк, но можно подойти к заданию очень примитивно

и в чем проблема? - http://docs.oracle.com/javase/7/docs/ap ... ipher.html т.е. перед отправкой encrypt и перед прочтением decrypt. Главное ключи раздайте и все.

Кстати, если реализовать обмен ключами через NFC, вообще как в шпионских фильмах будет.

KamiSempai писал(а):Кстати, если реализовать обмен ключами через NFC, вообще как в шпионских фильмах будет.

На самом деле обмен не обязателен, достаточно сохранить на устройстве своего рода manifest file, который будет хранить информацию для запроса к серверу используя для идентификации к примеру уникальный IMEI девайса. Этот файл - простой xml, в который будет дописываться блок с ключем на чтение к конкретному файлу сгенерированный сервером, и при поторном обращении, которое происходит во время получения файла, ключ генерируется. Таким образом прочитать файл скачанный сейчас можно только имея ключ полученный с ним, послу подтверждения клиента о получении ключа, процесс передачи на сервере умирает и генератор сбрасывается.
Пользователи всего то должны быть зарегестрированны и иметь уникальные идентификаторы(это позволяют современные устройства). Далее мы просто работаем с нашими учетками на сервере, а девайс(привязанный к учеткам) получает лишь результат. В итоге для атаки необходимо уже не просто иметь доступ к девайсу, а базу сервера, которая к слову тоже зашифрованна и используется в односторонеем порядке, т.е. банально не доступна для decrypt и все данные бесполезны посути своей.

altwin, то-есть, по вашему, проще поднять и держать сервер, чем использовать передачу через NFC при личной встрече?
Человек использует Вконтакт, думаю, о личном сервере тут и не стоит говорить.

Ну а получение ключа от сервера самый лучший способ, только для большей секъюрности нужно не забыть про HTTPS.

Но мой вариант однозначно лучше. Я уже представляю как в переполненный автобус заходит девушка с телефоном в заднем кармане, к ней сзади прижимается парень с телефоном в переднем кармане. ПИК-ПИК! Есть контакт! Обмен секретными ключами произведен и никто ни чего не заметил

KamiSempai писал(а):altwin, то-есть, по вашему, проще поднять и держать сервер, чем использовать передачу через NFC при личной встрече?
Человек использует Вконтакт, думаю, о личном сервере тут и не стоит говорить.

Ну а получение ключа от сервера самый лучший способ, только для большей секъюрности нужно не забыть про HTTPS.

Но мой вариант однозначно лучше. Я уже представляю как в переполненный автобус заходит девушка с телефоном в заднем кармане, к ней сзади прижимается парень с телефоном в переднем кармане. ПИК-ПИК! Есть контакт! Обмен секретными ключами произведен и никто ни чего не заметил

Использование связки AES + SHA256 уже более 25 лет проверенно и доказало свою криптостойкость, атак возможных (кроме перебора) не существует, а если учесть возможность наличия ключа до 4 гб, перебор без доступа к квантовому компьютеру можно исключить, поскольку займет он не одно десятилетие, более того безопастность гаррантированна даже на том уровне, что владелец вашего провайдера(дающего сервис шифрования и обмена) тоже не сможет получить доступ к вашим файлам(если конечно сознательно не "запорол" алогритм и не добавил "закладки". Использование же nfc очень и очень не обдуманно, к примеру для начала - http://money.cnn.com/2012/07/26/technology/nfc-hack/. Но вообще тут все зависит от степени паранои, но как минимум Android не особо награжден качественным железом и стабильность гаррантировать не сможет никто.

P.S. более того NFC на сегодня более чем молода и неодин человек за нее не заплатит, платят люди за то, чтобы в случае проблем подать в суд или по крайней мере найти концы, NFC сегодня очень сырой и никто вас не застрахует, AES и SHA256 сегодня наоборот используются в крупнейших банковских системах по тому же принципу и это называется enterprise level security... Хотя коненчно в случае с java и дырами самой платформы все относительно. Но сегодня -это очень актуально для простых людей(спасибо Сноудену ) и все врачи/адвокаты/банкиры и т.д. в США хотят защитить личные данные, использование проверенных алгоритмах дает право это делать, поскольку эти алгоритмы утвержденны на уровне государства, как надежные и допустимые для использования при работе с конфедециальной информацией клиента. Ваш же NFC на уязвимости толком не тестировался, а уже найдено куча дыр не говоря о стабильности устройств и более того ниодин юрист или врач не сможет использовать для хранения документов к примеру облако, если оно не защищено алгоритмом утвержденным на уровне законодательства. Когда вопрос касается шифрования и безопастности, стоит забыть о доступности и открытости интернета, ровно как и о "новыъ технология", в этом мире время течет другим путем

и в чем проблема? - http://docs.oracle.com/javase/7/docs/ap ... ipher.html т.е. перед отправкой encrypt и перед прочтением decrypt. Главное ключи раздайте и все.

Как то легко звучит на словах. Шифровкой и дешифровкой понятно. Обмен самими ключами между пользователями как произвести. Сервера контакта и поэтому нет необходимости раздавать ключи всему списку контактов. К примеру я выбрал одного собеседника. Первое, что мы делаем, обмениваемся ключами в сообщении. Собеседник копирует ключ в специальное поле, далее просто передаем друг другу зашифрованное сообщение. По приходу сообщения нажимаем дешифровать. Или как по другому обмен ключами?

Sk_games писал(а):

и в чем проблема? - http://docs.oracle.com/javase/7/docs/ap ... ipher.html т.е. перед отправкой encrypt и перед прочтением decrypt. Главное ключи раздайте и все.

Как то легко звучит на словах. Шифровкой и дешифровкой понятно. Обмен самими ключами между пользователями как произвести. Сервера контакта и поэтому нет необходимости раздавать ключи всему списку контактов. К примеру я выбрал одного собеседника. Первое, что мы делаем, обмениваемся ключами в сообщении. Собеседник копирует ключ в специальное поле, далее просто передаем друг другу зашифрованное сообщение. По приходу сообщения нажимаем дешифровать. Или как по другому обмен ключами?

Ничего вы не копируете никуда. Когда вы создаете учетную запись данные о вас сохраняются, ровно как и о вашем собеседнике и происходит генерация ключей, закрытый ключ всегда остается на сервере, а открытый(либо путь к нему) прописывается в config файле(манифесте) вашего прилоежния. Закрытый ключ используется только для шифрования и вы ничего об этом не знаете, поскольку получаете уже зашифрованный файл. Открытый же ключ дает вам доступ на чтение к тем файлам, которые были зашифрованны вашим же ключем. Если необходимо редактироание, то открытый ключ игнорируется и идет запрос к закрытому. В свою очередь ваш собеседник получая доступ всеголишь получает копию вашего открытого ключа в свой манифест, но доступа к закрытому ключу у него нет. Это довольно просто для пользователя, потому, что он ничего не должен знать о ключах, как и то, что закрытый ключ никогда не должен попадать на клиент. Все это можно и нужно усложнять логированием, груповым доступом, уровнями доступа(но это уже решается на уровне сервера и фактическим владельцем вашего файла не вы будете а процесс на который у вас есть права владельца, у кого то администратора, а у кого то пользователя и т.д.) Вопрос этот ну очень объемный и довольно изученный, то, что я пытаюсь написать своими словами давно описанно и изученно, почитайте для начала о том, как в принципе реализуется RSA в java

http://www.javamex.com/tutorials/crypto ... tion.shtml
Сам процесс обмена ключами тоже хорошо описан, но это всеголишь примеры реализаций, в том числе на github есть масса проектов в которых можно посмотреть реализацию, но это именно ваша задача решить, как вы будете это делать. Можете посмотреть короткое видео где дядька объясняет как это в общем работает в реальном коммерческом проекте - http://youtu.be/sh8U7hgwLQg Тут не шифруется сообщение, а идет работа с файлами, но суть таже и общее представление должно сложиться
Но опять же нужно учитывать что действительно безопасная реализация на java в принципе своем не возможна и все эти opensource реализации самого Cipher мягко говоря кривые...