Использование ручек с алгоритмом нечеткой толерантности в качестве ключа шифрования

Как я могу зашифровать/дешифровать с нечеткой точностью?

Я хочу использовать Stroke на InkCanvas в качестве ключа для моего шифрования, но при повторной расшифровке пользователю не нужно рисовать тот же самый символ, только похожий. Можно ли это сделать в .NET С#?

--- Обновление (9 sep) ---

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

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

Ответ 1

OK. Позвольте разбить вашу проблему на две части.

1) Нечеткий 2) Шифрование

Реальность заключается в том, что оба эти понятия относительно стары, и их реализация существует уже много лет. Каждый из них имеет дело с проблемой очень хорошо, но это не значит, что объединение этих двух является хорошей идеей. Я считаю, что вы должны иметь свое решение в качестве двухэтапного подхода.

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

Нечеткая часть решения также не такая уж сложная. Как и любой другой метод нечеткого распознавания, вам нужно выполнить извлечение функции и создать вектор, который будет передан в алгоритм шифрования. Вам нужно создать нечеткость в ваших функциях. Например, количество ударов, квадрант начальной точки для каждого хода, коэффициент кривизны для каждого удара и тому подобное. Этого будет достаточно для создания 32-битного вектора для перехода к алгоритму шифрования.

UPDATE

Я попытаюсь сделать это более наглядным:

2 бита для числа штрихов: 1, 2, 3, +3, который переводится в 00, 01, 10 и 11

2 бит для квадранта начала первого такта: TopLeft, TopRight, BottomLeft, BottomRightt кодирует до 00, 01, 10 и 11

2 бит для квадранта конца первого такта: ditto

2 бит для квадранта начала второго такта: то же самое. Если нет второго штриха, то 00.

2 бит для квадранта конца второго такта: так же. Если нет второго штриха, то 00.

2 бит для квадранта начала третьего такта: так же. Если нет третьего штриха, то 00.

2 бит для квадранта конца второго такта: так же. Если нет третьего штриха, то 00.

2 бита для кривизны первого такта: straight- > 00... Nice round- > 11. Это не будет очень легко, и вы можете уменьшить степень кривизны до 2 и использовать только один бит, но это "сосать и посмотреть".

Итак, это 16 бит. Вы можете оставить остальное как ноль и попробовать и посмотреть, как это работает.

Надеюсь, что это поможет.

Ответ 2

Существует ряд схем шифрования, которые позволяют нечеткие секреты. Часто эти схемы разрабатываются для защиты секретов с биометрической информацией (например, отпечатки пальцев, сканирование сетчатки), но основные схемы более общеприменимы. Одним из примеров такой схемы является схема нечеткого хранилища, предложенная Juels и Sudan.

Ответ 3

Используйте форму OCR (оптическое распознавание символов), чтобы преобразовать штрих в обычный текст, а затем использовать этот текст как ключ. Пока пользователь рисует все, что получает OCR-ed в тот же самый текст, они смогут снова расшифровать.

Ответ 4

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

Ответ 5

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

Итак, Alice хочет зашифровать некоторое сообщение M. Она - единственный человек, который должен расшифровать сообщение, поэтому Боб не находится на картинке. Алиса генерирует нечеткий ключ шифрования Ke и шифрует M, чтобы стать Me: Encrypt(M,Ke) = Me. Сообщение, которое отправлено, (Ke,Me). На принимающей стороне Алиса производит нечеткий ключ дешифрования Kd. Некоторые алгоритмы проверяют, что Ke ~ Kd и Me дешифрованы: Decrypt(Me,Ke) = M. Обратите внимание, что это симметричное шифрование; Kd используется только для проверки того, что он "достаточно равен" Ke.

Конечно, проблема заключается в том, что Ke отправляется в виде открытого текста вместе с сообщением, поэтому Ева может просто взять ключ и дешифровать Me. Тем не менее, Ke требуется на принимающей стороне, чтобы сравнить его с Kd. Итак, как мы можем отправить Ke вместе с сообщением без возможности прослушивания Eve? Мы могли бы создать хэш Ke и отправить его по строке: (Hash(Ke),Me). Однако на принимающей стороне не было бы возможности проверить "достаточное равенство" между Ke и Kd на основе Hash(Ke).

Мы могли бы использовать некоторый алгоритм, который генерирует значение на основе Ke, такое, что если Ke ~ Kd -> V(Ke) ~ V(Kd) (если Ke и Kd схожи, то сгенерированные значения аналогичны). Мы отправляем сообщение (V(Ke),Me) получателю. Однако Еве было бы относительно легко определить Ke на основе V(Ke). Она начинает со случайного ключа кандидата: KeC и используя наш алгоритм, определяет a V(KeC). Если он не выглядит вообще как V(Ke) в сообщении, она делает некоторые радикальные изменения в кандидате KeC и снова пытается. Когда она приближается к сообщению V(Ke), она делает меньше изменений на KeC и т.д.

Таким образом, невозможно создать безопасную схему шифрования, если мы позволяем отправлять Ke вместе с сообщением. Это означает, что Ke следует присваивать Trent, доверенной третьей стороне. В этом случае Trent может быть базой данных приложения. Итак, теперь схема выглядит следующим образом:

Алиса генерирует Ke, сообщение M и уникальный id Id. Ke хранится в нашей базе данных Trent вместе с Id. M зашифровывается с использованием обычной схемы шифрования, которая использует Ke как ключ: Me = Encrypt(M,Ke). Сообщение, отправленное получателю, (Me,Id).

На принимающей стороне Алиса получает сообщение (Me,Id). Алиса генерирует Kd. Основываясь на Id, получим соответствующий Ke от Trent и сравним его с Kd. Если есть совпадение, мы дешифруем Me: M = Decrypt(Me,Ke).

Единственная проблема теперь в том, что у вас есть злоумышленник Мэллори с доступом к Тренту. Он может задавать Trent для значений Ke на основе случайных идентификаторов. Чтобы этого не произошло, вы не должны включать Id в сообщение, чтобы сообщение просто становилось (Me). Теперь вам нужно разработать стратегию, чтобы получить кандидата Ke от Trent только с помощью Kd. Это, конечно, возможно, потому что вы можете сравнить Kd со всеми Ke в базе данных, вернуть наиболее "похожие" Ke и попробовать это как ключ дешифрования. Эта стратегия предполагает, что каждый человек Stroke (или Ke) достаточно различен.

Стратегия, описанная выше, заимствована из биометрического шифрования, где вы храните биометрические данные в базе данных и используете их для идентификации или аутентификации лиц. Попробуйте найти Google для биометрическое шифрование, чтобы получить дополнительную информацию.

Ответ 6

Как я уже отмечал в комментарии, я не знаю, что нечеткое шифрование - это зрелая тема, так что подумайте об этом. Поскольку вы выполняете шифрование/расшифровку локально, как насчет аппаратной реализации? Т.е. вы покупаете планшетный компьютер для выполнения биометрии и поддерживаете обычный ключ шифрования внутри него. Это будет выглядеть так:

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

Обратите внимание, что шаг 5 является слабым местом цепочки безопасности, поскольку атаки на просмотр документов (например, Acrobat Reader) становятся больше превалирует. Лучше использовать какую-либо схему песочницы, такую как экземпляр VMWare.

Ответ 7

Один простой способ сделать это - вместо этого закодировать много информации о ключе, а затем выяснить, насколько точно он соответствует. Пример информации, предполагая, что вы можете преобразовать пользовательский ввод в некоторую аппроксимацию строк/дуг/точек:

Число прямых линий Количество закрытых регионов
Количество используемого чертежа.

Стандартное отклонение точек на оси x.
Стандартное отклонение точек на оси y.
Стандартное отклонение размеров фигур.

Отсортированный список областей вложенных областей.

Etc.

Таким образом, вместо представления изображения вы представляете свойства изображения. Нечеткость будет заключаться в том, что вы даете каждому из этих свойств оценку точности, добавляете или умножаете или иным образом объединяете общий уровень точности и принимаете пароль, если он пропускает некоторый порог.