Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Нужен совет по ассиметрии, плиз! 10.01.02 11:17 Число просмотров: 1811
Автор: paganoid Статус: Member
|
> > > > (база (в худшем случае под контролем злоумышленника))
> > |
> > | (канал 1)
> > |
> > (безопасный сервер шифрования, никогда не содержащий
> > вредоносного кода)
> > |
> > | (канал 2)
> > |
> > (сборище пользователей и потенциальных врагов партии
> и
> > правительства)
> >
---
>
> Ну все, теперь я вообще запутался с твоей схемой. Как она
> работает?
> 1. Каким алгоритмом и с каким ключом зашифрованы данные,
> хранимые в "базе"?
данные в базе зашифрованы AES, ключ AES зашифрован приватным ключом Админа
> 2. Что конкретно делает "сервер шифрования" в ситуациях
> чтения данных Юзером и записи данных Админом?
запись админом:
сервер берет plain данные, получает по каналу 2 ключ зашифровки (приватный ключ RSA), генерирует ключ AES , шифрует plain данные этим ключом , шифрует ключ AES ключом RSA ,вставляет необходимые проверки целостности и отправляет по каналу 1 в базу зашифрованные блоки, хеши и шифрованный AES ключ.
чтение данных юзером.
сервер запрашивает по каналу 2 зашифрованные блоки, хеши, шифрованный ключ AES. По каналу 1 получает от юзера публичный RSA ключ. С помощью этого ключа расшифровывает зашифрованный ключ AES. С помощью полученного ключа AES расшифровывает зашифрованные блоки, получает plain текст. С помощью hash ф-й проверяет корректность расшифровки.
> 3. Где хранится AESKey и каково его время жизни?
шифрованный AES ключ хранится в базе. Расшифрованный AES ключ живет на сервере только в моменты шифровки - зашифровки
> Я-то хотел делать вот как:
> > (База)
> |
> | Незащищенный канал
> |
> (Точка)
>
---
>
> Где:
> "База" - полностью не отчего незащищенная станция, на
> которой хранится база данных, полностью зашифрованная.
> Каждая таблица в ней зашифрована постоянным ключом
> AccessKey (он может быть разным для разных таблиц - но это
> уже детали), ну и плюс извраты с подписью. База ничего не
> шифрует, и ничего не дефишрует, просто тупо принимает,
> хранит и передает данные без всяких изменений.
> "Точка" - одна из многих клиентских станций. Получает
> данные от Базы в зашифрованном виде.
а, вон оно как.
Расшифровывает их,
> использует, зашифровывает и передает в базу на хранение.
> Точка должна быть защищина от программных приколов. В
> начале сеанса точка считывает с Базы зашифрованные
> системные таблицы с паролями AccessKey, ReadKey, WriteKey.
> Затем пользователь вводит логин и пароль. По хэшу логина
> выбирается соответствующая строка системной таблицы
> паролей. Строка расшифровывается хэшем пароля пользователя
> (Личного пароля). В расшиврованной таблице проверяется
> какой-нибудь CRC. Заметь, что хэш личного пароля
> пользователя НИГДЕ не храниться, вообще никакая инфа о нем
> (пароле) нигде не хранится. Если пользователь прогнал и
> ввел левый пароль, то строка системной таблице расшифруется
> в чушь, CRC не сойдется и т.д.
теперь понятно. Просто у меня в голове не укладывалось, как это ты будешь по сети таблицы гонять.
>
> Да после расшифровки системной таблицы проверится ее CRC
> (CRC таблицы, а не пароля).
угу
>
> Пароли вообще не передаются по сети. Точнее передаются
> только как часть системной таблицы паролей (она
> зашифрована, см. выше). Причем в составе этой таблицы
> передаюся только AccessKey, ReadKey, WriteKey. Личные
> пароли вообще нигде не храняться и никуда не передаются,
> причем ни сами пароли, ни их хэши.
>
> > не пока рассматриваю, ты свой вариант предложи, а я к
> нему
> > привяжусь ;) ). Послал rnd , принял обратно rnd и
> hash(rnd
> > + hash(password)) , достал из базы хранимое pwdhash
> > (равное hash(password)), вычислил и сравнил значения,
> все.
>
> Понятно, о чем ты. Тут плохо то, что нужно что-то
> сравнивать. Если злоумышленик достанет все алгоритмы на
> обоих сторонах, он подделает hash(rnd + hash(password)),
> т.к. у него будет алгоритм, по которому ты будешь считать.
неважно. плюс криптографии в том, что при полном знании всех используемых алгоритмов стойкость системы определяется только стойкостью ключа.
hash(rnd + hash(password)), подделать невозможно без знания password, т.к. это односторонняя ф-я по определению. Можно толькопосерединевклиниться, но это уже активный перехват и может быть закрыт физически.
> Личные пароли передаются тоже лично ;)) Серьезно. Это
> вполне реально. Т.к. Админ Вася подходит к Юзеру Пете и
> всучает ему конверт с текстом "Маша", ну или наоборот.
> Можно использовать курьера с охраной.
после прочтения - съесть ;)
> Но дальше - проще. Пароли на доступ к самим данным -
> системные таблицы уже безопасно гуляют по сети.
всё, понятно. Удачи ;)
я еще подумаю над этим...
зы. Приятная беседа получилась. Кстати, я давно как-то делал очень похожую на твою штуку на Java, там была защита web-страниц без использования CGI, апплет лез на сервер, читал шифрованный файл данных и т.п. Там правда записи не было, только чтение. Не доделал....
|
|
|
подробно о проекте
Анализ криптографических сетевых...
