информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 И ещё раз об интернет-голосовании 
 Типовые уязвимости в драйверах... 
 Logitech готовится закрыть очередную... 
главная обзор 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
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Нужен совет по ассиметрии, плиз! 09.01.02 11:30  Число просмотров: 1152
Автор: paganoid Статус: Member
<"чистая" ссылка>
> А если не видно разницы,
> зачем
> > плодить больше?
>
> Я хотел сделать так: Админ знает 2 ключа, Юзер -1, Гость -
> 0. Админ может и читать и изменять данные, Юзер только
> читать, Гость - ничего не может. Для этого и нужно два
> ключа.

про что говорил я - Админ знает RSA Public + RSA Private, юзер знает
RSA Public, гость не знает ничего. Количество, как ты видишь, одно и то же.

>
> Дело в том, что если шифровать с помощью RSA ключ AES, то
> не получиться разграничить доступ по чтению и изменению
> данных, в чем собственно и задача. Так, получив один раз
> открытый ключ AES можно им тут же и читать и писать.

ключ AES - это сеансовый ключ и нигде не хранится. Заполучить его можно только внедрив в систему свой исполняемый код. Кто может внедрить в систему свой код, может перехватывать все твои ключи на раз плюнуть и соответственно к криптографии этот вопрос уже не имеет никакого отношения. Сервер должен быть защищен.

вобщем, предложенная мной схема имхо вполне надёжная и проверенная. Зачем ты удваиваешь нужный объем работы, пока не могу понять, но попытаюсь...

> С тех пор как исходное сообщение написал - сам немножко
> поразмыслил:
> Первичная схема, предложенная мной, плоха минимум по 3
> причинам:
> 1) Не годится для мало-мальски серьезных по объему блоков
> данных - RSA слишком медленный для шифрования целого блока
> данных.

естественно

> 2) Ни к чему использовать для RSA и AES один и тот же ключ,
> это может быть небезопасным.
> 3) При изменении данных с неверным ключом записи (скажем
> Юзером) данные попросту испортятся, а Админ не сможет
> определить (в общем случае) этот факт.
>
> Предлагаю новую схему :-)
>
> Зашифрование:
> 1) signature=RSAencrypt(hash(block),WriteKey)
> // Т.е. к блоку дописывается подпись - хэш, зашифрованный
> ключом записи
> 2)
> {block,signature}=AESencrypt({block,signature},AccessKey)
> // Блок данных с подписью шифруются AES'ом с ключом доступа
>
> Расшифрование:
> 1)
> {block,signature}=AESdecrypt({block,signature},AccessKey)
> // Данные уже расшифрованы, следующей операцией проверим
> подпись,
> // что бы убедиться, в правомерности записанной информации
> 2) if RSAdecrypt(signature,ReadKey)=hash(block) then OK
> // Расшифровываем подпись, вычисляем хэш блока и сравниваем
> их
> // Если они равны, то все ОК, если нет, то данные изменил
> тот, кто
> // не имел на это право (Юзер)
>
> Таким образом в схеме работает 3 ключа:
> AccessKey - ключ для доступа к данным
> ReadKey - для проверки валидности данных
> WriteKey для санкционированного изменения данных
> Админ знает все три ключа, Юзер знает AccessKey и ReadKey,
> Гость ни знает ничего.
>Введем еще Юзера2, который тоже
> знает AccessKey и ReadKey.
> Админ может читать данные, проверять их валидность и
> санкционированно изменять данные. Юзер и Юзер2 могут читать
> и проврять данные на валидность, но не могут
> санкционированно изменять данные. Если вдруг Юзер изменит
> данные, Админ и Юзер2 смогут обнаружить этот факт и забить
> тревогу. Гость не может делать ничего.

да, приведенная схема вроде корректна.

А теперь самый интересный момент - как ты будешь вручать ключ ReadKey юзерам.
<theory> Поиск 








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


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