Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | |
Нужен совет по ассиметрии, плиз! 09.01.02 15:23 Число просмотров: 1696
Автор: Artik Статус: Незарегистрированный пользователь
|
> > Дело в том, что если шифровать с помощью RSA ключ AES,
> > то не получиться разграничить доступ по чтению и изменению
> > данных, в чем собственно и задача. Так, получив один раз
> > открытый ключ AES можно им тут же и читать и писать.
> ключ AES - это сеансовый ключ и нигде не хранится.
Если я правильно понял, ты предлагал сделать так:
Зашифрование:
1) AESKey=RND
2) block=AESencrypt(block,AESKey)
3) AESKey=RSAencrypt(AESKey,WriteKey)
Результат зашифрования есть совокупность зашифрованного блока данных и зашифрованного сеансового ключа {block,AESKey}
Расшифрование:
1) AESKey=RSAdecrypt(AESKey,ReadKey)
2) block=AESdecrypt(block,AESKey)
Так вот, проблема в следующем:
Злобный Юзер, желая изменить данные, и не имея при этом ключа WriteKey прочитает зашифрованные данные, изменит их произвольным образом и запишет, используя старый ключ AESKey, вместо того, что бы генерить новый. Все будет выглядеть так, как будто так все и было.
Может я что не так понял, но тогда что ты предлагал?
> Заполучить его можно только внедрив в систему свой
> исполняемый код. Кто может внедрить в систему свой код,
> может перехватывать все твои ключи на раз плюнуть и
> соответственно к криптографии этот вопрос уже не имеет
> никакого отношения. Сервер должен быть защищен.
Ну это-то понятно. Речь идет исключительно о криптографической стороне дела.
<----- новая схема skipped----->
> да, приведенная схема вроде корректна.
>
> А теперь самый интересный момент - как ты будешь вручать
> ключ ReadKey юзерам.
Я хочу сделать так:
1) Каждый участник процесса - Админ, Юзер, ... имеют логин и пароль. (Гость может их и не иметь ;) Пароли пользователей - это не AccessKey, ReadKey и WriteKey из моей схемы, а отдельные Личные пароли, выбираемые самими пользователями
2) У каждого пользователя (в зависимости от его логина) есть таблица системных паролей AccessKey, ReadKey и WriteKey на каждый объект в системе (например, на каждую таблицу БД). Таблица эта зашифрована AES'ом c помощью Личного пароля пользователя. Содержание таблицы зависит от прав пользователя. Так в нашем случае в таблице Админа есть все пароли, в таблице Юзера есть только AccessKey и ReadKey.
Процесс управления пользователями и правами выглядит так:
1) По умолчанию есть один Админ с логином "Вася" и паролем "Пупкин", у него есть все права.
2) В начале работы с системой Вася меняет свой пароль на любой, какой хочет, скажем "Пупкин1", этим паролем шифруется его таблица системных паролей, сам же пароль "Пупкин1" нигде не хранится, даже зашифрованным, и знает его только Вася.
3) Дальше Вася может при желании добавить нового пользователя - Юзера, присвоить ему логин "Петя" и пароль "Маша", создать его таблицу системных паролей, закинуть туда только AccessKey и ReadKey, зашифровать ее паролем "Маша" и забыть этот пароль навсегда (не забыв сказать Пете ;)
4) И т.д...
Всего доброго,
С уважением, Artik.
|
|
<theory>
|
Нужен совет по ассиметрии, плиз! 05.01.02 14:27
Автор: Artik Статус: Незарегистрированный пользователь
Отредактировано 05.01.02 14:29 Количество правок: 1
|
Добрый день!
Нужен совет по реализации защиты данных раздельно по чтению и изменению. Т.е. есть "Админ", есть "Юзер", все остальные - "Гости". Нужно сделать так, что бы Админ мог читать и изменять блок данных, Юзер мог только читать, а "Гости" не могли ни читать ни писать.
Хочу сделать так: есть 2 ключа - ключ чтения ReadKey и ключ записи WriteKey. Блок данных - block.
Зашифрование:
1) block = RSAdecrypt(block, WriteKey)
2) block = AESencrypt(block, ReadKey)
Расшифрование:
1) block = AESdecrypt(block, ReadKey)
2) block = RSAencrypt(block, ReadKey)
Таким образом для изменения данных и зашифровки нужно знать 2 ключа, а для чтения данных - только ReadKey.
В зашифровании умышленно используется RSAdecrypt, в расшифровании - RSAencrypt, а не наоборот, для того, что бы, с точки зрения RSA, ReadKey интерплетировался как "открытый" ключ, а WriteKey - как "закрытый" и знание ReadKey не давало бы дополнительной информации о WriteKey.
Шифрование AES'ом введено для повышения устойчивости, т.к. зашифрование ведется алгоритмом RSAdecrypt и я боюсь, что это скажется на защищенности.
Насколько я прав? Будет ли все это устойчиво ко взлому? Или может шифрование еще и AES'ом - уже паранойя? Подскажите, плиз, кто что думает! С другой стороны, сколько информации об "открытом" ключе RSA можно получить по "закрытому"? Может все сделать гораздо проще, простой парой RSAencrypt - RSAdecrypt?
Заранее благодарен,
С уважением, Artik.
|
|
Нужен совет по ассиметрии, плиз! 08.01.02 10:38
Автор: paganoid Статус: Member
Отредактировано 08.01.02 10:48 Количество правок: 1
|
>
> Шифрование AES'ом введено для повышения устойчивости, т.к.
> зашифрование ведется алгоритмом RSAdecrypt и я боюсь, что
> это скажется на защищенности.
ну пока не взломали, чего бояться то. Самая главная свистопляска обычно с раздачей ключей, а при шифровке данных проверенными шифрами пока все как в танке, вроде бы...
> Насколько я прав? Будет ли все это устойчиво ко взлому? Или
> может шифрование еще и AES'ом - уже паранойя? Подскажите,
> плиз, кто что думает! С другой стороны, сколько информации
> об "открытом" ключе RSA можно получить по "закрытому"?
насколько я помню, информации нисколько нельзя получить, они симметричны в этом отношении.
> Может все сделать гораздо проще, простой парой RSAencrypt -
> RSAdecrypt?
мне тож так кажется. защиту от "гостей" все равно придется делать на уровне разграничения доступа. Ты все равно будешь раздавать людям ключи, так какая разница по сколько штук их выдавать?
если "гость" захватит ключи Юзера, ессна он захватит сразу два, то же самое и Админом. А если не видно разницы, зачем плодить больше?
но если у тебя большие блоки данных, которые шифруются, то для простоты реализации, возможно и симметричным шифром проще будет их укатывать, тогда твоя схема имеет смысл... Только с помощью RSA тебе надо шифровать не блок, а ключ симметричного шифра AES, которым ты шифруешь блок. И ключ AES нигде хранить не надо. Плюс, данная схема позволяет раздавать РАЗНЫМ людям доступ на ОДНИ И ТЕ ЖЕ зашифрованные данные.
|
| |
Нужен совет по ассиметрии, плиз! 08.01.02 18:05
Автор: Artik Статус: Незарегистрированный пользователь
|
> мне тож так кажется. защиту от "гостей" все равно придется
> делать на уровне разграничения доступа. Ты все равно будешь
> раздавать людям ключи, так какая разница по сколько штук их
> выдавать?
> если "гость" захватит ключи Юзера, ессна он захватит сразу
> два, то же самое и Админом. А если не видно разницы, зачем
> плодить больше?
Я хотел сделать так: Админ знает 2 ключа, Юзер -1, Гость - 0. Админ может и читать и изменять данные, Юзер только читать, Гость - ничего не может. Для этого и нужно два ключа.
> но если у тебя большие блоки данных, которые шифруются, то
> для простоты реализации, возможно и симметричным шифром
> проще будет их укатывать, тогда твоя схема имеет смысл...
> Только с помощью RSA тебе надо шифровать не блок, а ключ
> симметричного шифра AES, которым ты шифруешь блок. И ключ
> AES нигде хранить не надо. Плюс, данная схема позволяет
> раздавать РАЗНЫМ людям доступ на ОДНИ И ТЕ ЖЕ зашифрованные
> данные.
Дело в том, что если шифровать с помощью RSA ключ 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 смогут обнаружить этот факт и забить тревогу. Гость не может делать ничего.
Большое спасибо, всем кто ответил на мое сообщение и дочитал все это до конца ;)
С удовольствием приму любые комментарии.
Заранее благодарен,
С уважением, Artik.
|
| | |
Нужен совет по ассиметрии, плиз! 09.01.02 11:30
Автор: 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 юзерам.
|
| | | |
Нужен совет по ассиметрии, плиз! 09.01.02 15:23
Автор: Artik Статус: Незарегистрированный пользователь
|
> > Дело в том, что если шифровать с помощью RSA ключ AES,
> > то не получиться разграничить доступ по чтению и изменению
> > данных, в чем собственно и задача. Так, получив один раз
> > открытый ключ AES можно им тут же и читать и писать.
> ключ AES - это сеансовый ключ и нигде не хранится.
Если я правильно понял, ты предлагал сделать так:
Зашифрование:
1) AESKey=RND
2) block=AESencrypt(block,AESKey)
3) AESKey=RSAencrypt(AESKey,WriteKey)
Результат зашифрования есть совокупность зашифрованного блока данных и зашифрованного сеансового ключа {block,AESKey}
Расшифрование:
1) AESKey=RSAdecrypt(AESKey,ReadKey)
2) block=AESdecrypt(block,AESKey)
Так вот, проблема в следующем:
Злобный Юзер, желая изменить данные, и не имея при этом ключа WriteKey прочитает зашифрованные данные, изменит их произвольным образом и запишет, используя старый ключ AESKey, вместо того, что бы генерить новый. Все будет выглядеть так, как будто так все и было.
Может я что не так понял, но тогда что ты предлагал?
> Заполучить его можно только внедрив в систему свой
> исполняемый код. Кто может внедрить в систему свой код,
> может перехватывать все твои ключи на раз плюнуть и
> соответственно к криптографии этот вопрос уже не имеет
> никакого отношения. Сервер должен быть защищен.
Ну это-то понятно. Речь идет исключительно о криптографической стороне дела.
<----- новая схема skipped----->
> да, приведенная схема вроде корректна.
>
> А теперь самый интересный момент - как ты будешь вручать
> ключ ReadKey юзерам.
Я хочу сделать так:
1) Каждый участник процесса - Админ, Юзер, ... имеют логин и пароль. (Гость может их и не иметь ;) Пароли пользователей - это не AccessKey, ReadKey и WriteKey из моей схемы, а отдельные Личные пароли, выбираемые самими пользователями
2) У каждого пользователя (в зависимости от его логина) есть таблица системных паролей AccessKey, ReadKey и WriteKey на каждый объект в системе (например, на каждую таблицу БД). Таблица эта зашифрована AES'ом c помощью Личного пароля пользователя. Содержание таблицы зависит от прав пользователя. Так в нашем случае в таблице Админа есть все пароли, в таблице Юзера есть только AccessKey и ReadKey.
Процесс управления пользователями и правами выглядит так:
1) По умолчанию есть один Админ с логином "Вася" и паролем "Пупкин", у него есть все права.
2) В начале работы с системой Вася меняет свой пароль на любой, какой хочет, скажем "Пупкин1", этим паролем шифруется его таблица системных паролей, сам же пароль "Пупкин1" нигде не хранится, даже зашифрованным, и знает его только Вася.
3) Дальше Вася может при желании добавить нового пользователя - Юзера, присвоить ему логин "Петя" и пароль "Маша", создать его таблицу системных паролей, закинуть туда только AccessKey и ReadKey, зашифровать ее паролем "Маша" и забыть этот пароль навсегда (не забыв сказать Пете ;)
4) И т.д...
Всего доброго,
С уважением, Artik.
|
| | | | |
Нужен совет по ассиметрии, плиз! 09.01.02 17:04
Автор: paganoid Статус: Member
|
>
> Если я правильно понял, ты предлагал сделать так:
scippy
угу, именно так
>
> Так вот, проблема в следующем:
> Злобный Юзер, желая изменить данные, и не имея при этом
> ключа WriteKey прочитает зашифрованные данные, изменит их
> произвольным образом и запишет, используя старый ключ
> AESKey, вместо того, что бы генерить новый. Все будет
> выглядеть так, как будто так все и было.
ну КАК же, КАК он получит "старый" AESKey, когда у него имеется только ReadKey ? AESKey кеем владеет токма СИСТЕМА в момент шифровки и расшифровки ? Записать данные без знания WriteKey низзя (про целостность и защиту от подмены WriteKey мы не говорили - хоть бери от него хеш и храни на сервере. Твоя схема также контролирует целостность - но тк это детали. Допустим, в моей от исходного текста сразу на сервере берешь хеш и хранишь вместе с зашифрованным текстом)
и вообще как это все у тебя выглядит
(база (в худшем случае под контролем злоумышленника))
|
| (канал 1)
|
(безопасный сервер шифрования, никогда не содержащий вредоносного кода)
|
| (канал 2)
|
(сборище пользователей и потенциальных врагов партии и правительства)
---
или как?
в моем случае по каналу 1 никогда не передается ключ AES (там ездят только уже шифрованные данные ) и по каналу 2 тоже (там другие ключи). Так ГДЕ же он чтойнить зашифрует-то? (тут я снова умалчиваю про целостность каналов и перехват других ключей. Там можно и посередине вклиниться и т.п., но это отдельная песня, которую я дальше затяну)
> > Сервер должен быть защищен.
> Ну это-то понятно. Речь идет исключительно о
> криптографической стороне дела.
ну дк все зашифровано, комар носа не подточит :)
> <----- новая схема skipped----->
>
> > да, приведенная схема вроде корректна.
> >
> > А теперь самый интересный момент - как ты будешь
> вручать
> > ключ ReadKey юзерам.
>
> Я хочу сделать так:
> 1) Каждый участник процесса - Админ, Юзер, ... имеют логин
> и пароль. (Гость может их и не иметь ;) Пароли
> пользователей - это не AccessKey, ReadKey и WriteKey из
> моей схемы, а отдельные Личные пароли, выбираемые самими
> пользователями
> 2) У каждого пользователя (в зависимости от его логина)
> есть таблица системных паролей AccessKey, ReadKey и
> WriteKey на каждый объект в системе (например, на каждую
> таблицу БД). Таблица эта зашифрована AES'ом c помощью
> Личного пароля пользователя. Содержание таблицы зависит от
> прав пользователя. Так в нашем случае в таблице Админа есть
> все пароли, в таблице Юзера есть только AccessKey и
> ReadKey.
>
> Процесс управления пользователями и правами выглядит так:
> 1) По умолчанию есть один Админ с логином "Вася" и паролем
> "Пупкин", у него есть все права.
> 2) В начале работы с системой Вася меняет свой пароль на
> любой, какой хочет, скажем "Пупкин1", этим паролем
> шифруется его таблица системных паролей, сам же пароль
> "Пупкин1" нигде не хранится, даже зашифрованным, и знает
> его только Вася.
тебе все равно, видимо, надо будет хранить хеш от пароля, чтобы контролировать правильность его ввода. Или это будет делаться на фазе расшифровки ? Но тогда непонятно, как пароль будет передаваться по сети.. Если ты хранишь хеш - это схема challenge-response (атаку women-in-the-middle ;) не пока рассматриваю, ты свой вариант предложи, а я к нему привяжусь ;) ). Послал rnd , принял обратно rnd и hash(rnd + hash(password)) , достал из базы хранимое pwdhash (равное hash(password)), вычислил и сравнил значения, все. А как это будет у тебя, непонятно, хеша - то нет.... Не целую же строчку таблицы с Access+Write+... слать...
Ну и вообще, как ты думаешь этот пароль по сети пересылать в момент смены и ввода? это и имелось ввиду под "вручать ключ"
> 3) Дальше Вася может при желании добавить нового
> пользователя - Юзера, присвоить ему логин "Петя" и пароль
> "Маша", создать его таблицу системных паролей, закинуть
> туда только AccessKey и ReadKey, зашифровать ее паролем
> "Маша" и забыть этот пароль навсегда (не забыв сказать Пете
> ;)
> 4) И т.д...
то же самое, интересна фаза передачи Васей Пете "Маши" ;)
|
| | | | | |
Нужен совет по ассиметрии, плиз! 09.01.02 18:42
Автор: 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)), т.к. у него будет алгоритм, по которому ты будешь считать.
> Ну и вообще, как ты думаешь этот пароль по сети пересылать
> в момент смены и ввода? это и имелось ввиду под "вручать
> ключ"
Личные пароли передаются тоже лично ;)) Серьезно. Это вполне реально. Т.к. Админ Вася подходит к Юзеру Пете и всучает ему конверт с текстом "Маша", ну или наоборот. Можно использовать курьера с охраной.
Но дальше - проще. Пароли на доступ к самим данным - системные таблицы уже безопасно гуляют по сети.
|
| | | | | | |
Нужен совет по ассиметрии, плиз! 10.01.02 11:17
Автор: 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, апплет лез на сервер, читал шифрованный файл данных и т.п. Там правда записи не было, только чтение. Не доделал....
|
| | | | | | | |
Нужен совет по ассиметрии, плиз! 11.01.02 07:55
Автор: Artik Статус: Незарегистрированный пользователь
|
> > 2. Что конкретно делает "сервер шифрования" в ситуациях
> > чтения данных Юзером и записи данных Админом?
>
> запись админом:
>
> сервер берет plain данные,
А как он их берет? Прокачивает по каналу 2 От Админа?
> получает по каналу 2 ключ зашифровки (приватный ключ RSA), генерирует > ключ AES , шифрует plain данные этим ключом , шифрует ключ AES ключом
> RSA ,вставляет необходимые проверки целостности и
> отправляет по каналу 1 в базу зашифрованные блоки, хеши и
> шифрованный AES ключ.
>
> чтение данных юзером.
>
> сервер запрашивает по каналу 2 зашифрованные блоки, хеши,
Ты наверное имел ввиду канал 1, а не 2? Т.е. сервер запрашивает инфу в базе?
> шифрованный ключ AES. По каналу 1 получает от юзера
А тут, наверное, наоборот, канал 2?
> публичный RSA ключ. С помощью этого ключа расшифровывает
> зашифрованный ключ AES. С помощью полученного ключа AES
> расшифровывает зашифрованные блоки, получает plain текст. С
> помощью hash ф-й проверяет корректность расшифровки.
Ага, понятно. Но тут, как я понял, нужно, что-бы канал 2 (между сервером и сборищем пользователей) был полностью защищен (и от доступа и от изменения данных), ведь по нему передается:
1) Открытый текст при записи данных
2) Открытый текст при чтении данных
3) Оба ключа RSA
Я правильно понял?
<--- skip --->
> > > Послал rnd , принял обратно rnd и hash(rnd+hash(password)) ,
> > > достал из базы хранимое pwdhash
> > > (равное hash(password)), вычислил и сравнил значения, все.
> >
> > Понятно, о чем ты. Тут плохо то, что нужно что-то
> > сравнивать. Если злоумышленик достанет все алгоритмы на
> > обоих сторонах, он подделает hash(rnd+hash(password)),
> > т.к. у него будет алгоритм, по которому ты будешь считать.
>
> неважно. плюс криптографии в том, что при полном знании
> всех используемых алгоритмов стойкость системы определяется
> только стойкостью ключа.
> hash(rnd + hash(password)), подделать невозможно без знания
> password, т.к. это односторонняя ф-я по определению. Можно
> толькопосерединевклиниться, но это уже активный
> перехват и может быть закрыт физически.
Согласен. Я имел ввиду, что т.к. pwdhash хранится на сервере, то если злоумышленник достанет его, то не зная пароля он тем не менее получит искомое hash(rnd+hash(password)). Для сравнения, в моей схеме, если злоумымленник знает все алгоритмы + всю инфу с сервера, он сделать все равно ничего не сможет. Хотя, согласнен, что так, как ты предложил, во многих случаях вполне допустимо, и даже лучше.
> зы. Приятная беседа получилась. Кстати, я давно как-то
Мне тоже понравилось, спасибо ;)
> делал очень похожую на твою штуку на Java, там была защита
> web-страниц без использования CGI, апплет лез на сервер,
> читал шифрованный файл данных и т.п. Там правда записи не
> было, только чтение. Не доделал....
Удачи! Artik.
|
| |
Нужен совет по ассиметрии, плиз! 08.01.02 11:43
Автор: Wizard(2) Статус: Незарегистрированный пользователь
|
> ну пока не взломали, чего бояться то. Самая главная
> свистопляска обычно с раздачей ключей, а при шифровке
> данных проверенными шифрами пока все как в танке, вроде
> бы...
Насколько я знаю ключ в 1024 бит для "домашних" целей подходит с головой. (говорят, что 2048 бит не взламают еще в течении порядка 10 лет или больше - точно не помню)
>
> Только с помощью RSA тебе надо шифровать не блок, а ключ
> симметричного шифра AES, которым ты шифруешь блок. И ключ
> AES нигде хранить не надо. Плюс, данная схема позволяет
> раздавать РАЗНЫМ людям доступ на ОДНИ И ТЕ ЖЕ зашифрованные
> данные.
Согласен, так процесс шифрования и времени меньше займет.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
