Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Нужен совет по ассиметрии, плиз! 09.01.02 18:42 Число просмотров: 1750
Автор: Artik Статус: Незарегистрированный пользователь
|
> > (база (в худшем случае под контролем злоумышленника))
> |
> | (канал 1)
> |
> (безопасный сервер шифрования, никогда не содержащий
> вредоносного кода)
> |
> | (канал 2)
> |
> (сборище пользователей и потенциальных врагов партии и
> правительства)
>
---
Ну все, теперь я вообще запутался с твоей схемой. Как она работает?
1. Каким алгоритмом и с каким ключом зашифрованы данные, хранимые в "базе"?
2. Что конкретно делает "сервер шифрования" в ситуациях чтения данных Юзером и записи данных Админом?
3. Где хранится AESKey и каково его время жизни?
Я-то хотел делать вот как:
(База)
|
| Незащищенный канал
|
(Точка)
---
Где:
"База" - полностью не отчего незащищенная станция, на которой хранится база данных, полностью зашифрованная. Каждая таблица в ней зашифрована постоянным ключом AccessKey (он может быть разным для разных таблиц - но это уже детали), ну и плюс извраты с подписью. База ничего не шифрует, и ничего не дефишрует, просто тупо принимает, хранит и передает данные без всяких изменений.
"Точка" - одна из многих клиентских станций. Получает данные от Базы в зашифрованном виде. Расшифровывает их, использует, зашифровывает и передает в базу на хранение. Точка должна быть защищина от программных приколов. В начале сеанса точка считывает с Базы зашифрованные системные таблицы с паролями AccessKey, ReadKey, WriteKey. Затем пользователь вводит логин и пароль. По хэшу логина выбирается соответствующая строка системной таблицы паролей. Строка расшифровывается хэшем пароля пользователя (Личного пароля). В расшиврованной таблице проверяется какой-нибудь CRC. Заметь, что хэш личного пароля пользователя НИГДЕ не храниться, вообще никакая инфа о нем (пароле) нигде не хранится. Если пользователь прогнал и ввел левый пароль, то строка системной таблице расшифруется в чушь, CRC не сойдется и т.д.
<----- про Васю, Петю и Машу skipped----->
> тебе все равно, видимо, надо будет хранить хеш от пароля,
> чтобы контролировать правильность его ввода. Или это будет
> делаться на фазе расшифровки ?
Да после расшифровки системной таблицы проверится ее CRC (CRC таблицы, а не пароля).
> Но тогда непонятно, как
> пароль будет передаваться по сети.. Если ты хранишь хеш -
> это схема challenge-response (атаку women-in-the-middle ;)
Пароли вообще не передаются по сети. Точнее передаются только как часть системной таблицы паролей (она зашифрована, см. выше). Причем в составе этой таблицы передаюся только AccessKey, ReadKey, WriteKey. Личные пароли вообще нигде не храняться и никуда не передаются, причем ни сами пароли, ни их хэши.
> не пока рассматриваю, ты свой вариант предложи, а я к нему
> привяжусь ;) ). Послал rnd , принял обратно rnd и hash(rnd
> + hash(password)) , достал из базы хранимое pwdhash
> (равное hash(password)), вычислил и сравнил значения, все.
Понятно, о чем ты. Тут плохо то, что нужно что-то сравнивать. Если злоумышленик достанет все алгоритмы на обоих сторонах, он подделает hash(rnd + hash(password)), т.к. у него будет алгоритм, по которому ты будешь считать.
> Ну и вообще, как ты думаешь этот пароль по сети пересылать
> в момент смены и ввода? это и имелось ввиду под "вручать
> ключ"
Личные пароли передаются тоже лично ;)) Серьезно. Это вполне реально. Т.к. Админ Вася подходит к Юзеру Пете и всучает ему конверт с текстом "Маша", ну или наоборот. Можно использовать курьера с охраной.
Но дальше - проще. Пароли на доступ к самим данным - системные таблицы уже безопасно гуляют по сети.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
