информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Phrack #70/0x46 
 Возможно, Facebook наступил на... 
 50 лет электронной почте 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Вообще имеется целое направление в криптографии, которое... 13.12.05 19:53  Число просмотров: 3433
Автор: netcipher Статус: Незарегистрированный пользователь
Отредактировано 14.12.05 10:30  Количество правок: 4
<"чистая" ссылка>
> При создании и использовании средств шифрования данных
> (криптографической защиты данных), важнейшим вопросом
> является реализация ключевой политики, включающей в себя
> правила хранения и ввода ключевой информации, используемой
> для преобразования данных и, как правило, для идентификации
> пользователей, с целью получения ими доступа к данным (если
> в системе реализуется разграничение прав доступа к файловым
> объектам на основе ключевой информации).

Вообще имеется целое направление в криптографии, которое занимается управлением ключевым материалом и связанными политиками. Более того давно прошел процесс стандартизации (см. например ISO 11568-2:2005, где достаточно подробно рассмотрены вопросы управления ключами для симметричных алгоримов, или ISO/IEC 11770-2). Там рассматривается не только правила хранения и ввода ключевого материала, а его полный жизненный цикл.


> Ключ
> шифрования не должен храниться вместе с закодированными
> (зашифрованными) им данными;

Вообще ключ шифрования может, а зачастую должен, храниться с зашифрованными на нем данными, в защищенном виде.

> - Ключ шифрования не должен храниться вместе с закодированными (зашифрованными) им данными;
> - Ключ шифрования должен принадлежать пользователю для его ввода при доступе к зашифрованным данным;
> - Ключ шифрования должен быть не известен пользователю, в противном случае невозможно воспрепятствовать пользователю в хищении конфиденциальных данных

Имеются разнообразные подходы связанные с использованием иерархий ключей, а также криптографические модули (смарткарты, специализированные HSM, где пользователь может только активировать ключевой материал, хранимый на них, для использования, но не иметь доступа к нему) совместное использование которых с легкостью решает подобные задачи.

>Предлагаемое нами запатентованное решение (Патент № 2207619) состоит в следующем. В общем случае
>при управлении доступом к ресурсам следует различать два самостоятельных субъекта доступа -
>"пользователь" и "процесс". При этом предлагается управлять доступом (разграничивать права доступа) не
>только для субъекта пользователь, но и для субъекта процесс, причем могут быть выделены следующие
>схемы задания разграничительной политики доступа к ресурсам:
>Разграничение прав доступа к объектам процессов вне разграничений пользователей (эксклюзивный >режим обработки запросов процессов - доступ к объекту разрешается, если он разрешен процессу - права >доступа пользователя, запустившего процесс не учитываются. Данная схема разграничений может >использоваться в том случае, когда процессу следует расширить права доступа к ресурсам, по сравнению с >пользователем, запустившим процесс);
>Разграничение прав доступа к объектам пользователей, вне разграничений процессов (эксклюзивный
> режим обработки запросов пользователей - доступ к объекту разрешается, если он разрешен >пользователю >- права доступа процесса не учитываются. Это обычная схема разграничений прав доступа, >используемая >современными ОС, не позволяющая учитывать свойства отдельных процессов, в частности, >уровень >доверия к ним);
>Комбинированное разграничение прав доступа - разграничение прав доступа к объектам процессов в
> рамках разграничений пользователей (совместное разграничение доступа процессов и пользователей - >доступ к объекту разрешается, если он разрешен и пользователю, и процессу. Данная схема разграничений >может использоваться в том случае, когда пользователю следует сузить права доступа к ресурсам - ему >разрешается доступ только заданными процессами).

>В нашем случае, как видели, должен использоваться третий режим, при котором доступ к файловому >объекту, содержащему ключ, разрешается пользователю (если ему разрешено право доступа - после >идентификации для доступа к соответствующему объекту) и только соответствующим процессом системы >защиты данных, поэтому пользователь не может ни похитить ключ (прочитать содержимое файла), ни его >модифицировать (подобных возможностей процесс системы защиты ему не предоставляет).

По сути изобретение решает задачи, которые описаны для DRM, только там понятие "процесса" значительно расширено. Я вспоминаю пример, когда заявка на патент пневматических замков для контейнеров провалилась из-за того, что был зарегистрирован патент на пневматические замки аналогичной конструкции для гробов. Может не совсем удачное сравнение, но отражает тот факт, что или эксперт не обладал соотвествующей квалификацией, или патентный поиск не был проведен с достаточной полнотой.
<site updates> Поиск 








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


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