информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetВсе любят медСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Sophos открывает Sandboxie 
 Большой вторник патчей от MS 
 И ещё раз об интернет-голосовании 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Нужен совет по ассиметрии, плиз! 10.01.02 11:17  Число просмотров: 1317
Автор: 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, апплет лез на сервер, читал шифрованный файл данных и т.п. Там правда записи не было, только чтение. Не доделал....
<theory> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2019 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach