Алгоритм для дешифрования данных с помощью штрихов

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

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

Символ, который они нарисовали, скорее всего будет одним ударом (например, когда вы поднимаете палец), но может быть очень сложным, так что ему трудно повторить его, даже если они видят, что вы его рисуете в. Как будто каждая подпись человека уникальна и трудно дублировать. На самом деле, это может просто слишком усложнить его, если он должен был предотвратить дублирование, поэтому на данный момент это можно игнорировать, и мы можем предположить, что этот символ не будет замечен кем-то другим, и, следовательно, не имеет значения, можно ли его повторить ими или нет.

Я предполагаю, что реальный вопрос заключается в том, как бы вы последовательно преобразовали один и тот же (разумный) ход в один и тот же ключ (например, значение хэша). Очевидно, что в алгоритме должен быть некоторый порог прощения, поскольку от пользователя нельзя ожидать повторения штриха ровно на 100%.

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

Хорошим примером инсульта, который пользователь может использовать в качестве своего символа дешифрования, является "&". символ. Представьте, что пользователь рисует этот символ на своем iPhone каждый раз, когда им нужно расшифровать файл. Размер символа может быть не одинаковым при каждом его рисовании. Кроме того, вращение символа может быть различным в зависимости от того, как пользователь держит свое устройство. В идеале, в обоих случаях, поскольку символ был нарисован, по отношению к пользовательским штрихам, то же самое, он должен иметь возможность генерировать одно и то же значение хэша и, таким образом, расшифровывать файл.

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

Еще одна вещь, о которой я думал, - это разбить символ, который нарисован на крошечные сегменты, а затем запустить распознавание символов. Итак, представьте, что у вас есть 4 символа в базе данных: вертикальная линия, горизонтальная линия и диагональ в обоих направлениях. Теперь, когда пользователь рисует, каждый сегмент распознается как один из них, а затем все они объединены для формирования некоторого значения хэш-функции. Поэтому представьте, что пользователь выбрал в качестве своего символа дешифрования букву нижнего регистра "r". Поэтому они начнут с вертикальной линии вниз, а затем вертикальной линии, а затем диагональной линии вверх и вправо. Одна из проблем с этим методом заключается в том, как вы узнаете, когда разделить ход на отдельные сегменты? Вероятно, вы также захотите учесть, сколько времени занимает каждый отдельный сегмент (например, с шагом в 40 пикселей). Таким образом, если кто-то нарисовал деформированный "r", где горб выходит около дна, он не распознается как один и тот же символ и, следовательно, не будет расшифровывать файл.

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

Любые другие идеи о том, как это можно реализовать? Вы когда-нибудь слышали о чем-то подобном? Существуют ли какие-либо фундаментальные недостатки, которые могут помешать работе такой системы?

Спасибо

Ответы

Ответ 1

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

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

Ответ 2

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

Вы можете быть уверены, что когда одна строка закончится, а другая начнется, так как есть 8 направлений, и вы можете обнаружить изменение направления (или для более простого подхода, просто определить перо и перо вниз и использовать их в качестве разделителей строк). Первая строка дает масштабный коэффициент, поэтому длину каждой другой линии можно представить как фактор (например, в обычной форме L, первая вертикальная линия даст "базовую длину" b, а другая строка будет иметь длина примерно 0,5 * b). После того, как пользователь будет закончен, вы можете использовать наименьший коэффициент s для "округления" длин, так что у вас будет массив целых длин, например [1 * s, 2 * s, 4 * s, 5 * s]. Это предотвратит слишком высокую точность системы, а использование базовой длины сделает систему устойчивой к масштабированию.

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

Кроме того, вы можете сохранить значение смещения 2D (конечно, "округленное" ) для каждой строки после второй строки, так что линии также должны находиться в одной и той же позиции, если вы этого не сделаете, L и T, скорее всего, получат одну и ту же строку (1 линия вверх-вниз, 1 строка влево-вправо, длина 0,5). Поэтому хранение позиций немного укрепляет все, но необязательно.

EDIT:

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

Обратите внимание, что этот алгоритм дает только 3 бита на ход, если все строки имеют одинаковую длину и максимум, возможно, до 6-8 бит за такт, а еще немного, если вы также сохраняете позиции. Это означает, что вам понадобится довольно сложный символ из 20-40 ударов, чтобы получить 128 бит безопасности.

Легкий способ добавить больше вариантов/безопасности - позволить пользователю использовать разные цвета из данной палитры.

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

Ответ 3

Распознавание рукописного ввода часто учитывает продолжительность инсульта во внимание больше, чем фактическая длина и т.д.

Хотя это касается чувствительности к давлению, я думаю, вы сможете увидеть некоторые похожие концептуальные биты в том, что вы здесь думаете.... jdadesign.net/safelock/

Это не совсем та же тема, но это самая близкая вещь, которая приходит на ум в данный момент.

Ответ 4

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

Подумайте об этом так. Если вы разложили жест на сегменты вверх, вниз, влево и вправо, каждый сегмент будет представлять собой 2 бита информации. Для ключа AES символу потребуется 64 таких сегмента. Это довольно сложный жест, чтобы помнить. И если он упрощается путем повторения многих сегментов подряд ( "справа, справа, справа,..." ), он делает паршивый (предсказуемый, неслучайный) ключ.

Ответ 5

Я подумал об этом. Я не специалист по comp-sci, но что-то вроде этой работы.

Скажем, что с любым символом или "шаблоном" кто-то рисует. Единственное, что вам нужно проанализировать, - это все точки в шаблоне, создаваемые в touchBegan, touchMoved и touchEnded.

Итак... пусть возьмут все созданные точки, будь то 100 или 1 000 000, это не имеет большого значения.

Разделите их на группы, как и многие группы. Чем более весомым я предполагаю, но и для этого примера, поставьте их в 4 группы. С 100 точками группа 1 будет содержать точки 1 > 25, группа 2 содержит 26 > 50 и т.д.

Для каждой группы используйте все точки для вычисления средней позиции.

Это может работать лучше, если пространства холста разделены на сетку, а "средние позиции" получаются на их ближайшую координату.

Затем проверьте относительное расстояние между всеми группами. Таким образом, между 1,2 1,3 1,4 2,3 2,4 3,4.

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

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

Я подозреваю, что чем больше очков и групп у вас есть, тем точнее это будет.

На самом деле, я собираюсь попробовать.

Ответ 6

Жесты.

http://depts.washington.edu/aimgroup/proj/dollar/

Вы можете определить собственные алгоритмы для определенных жестов. EG - круг,

1. Начните исходную точку 2. Найдите самый левый, самый правый и самый дальний для точек и получите приблизительный радиус. 3. проверить все точки на радиус с погрешностью (25%?) 4. Если радиус проверяется, у вас есть круг.

Вертикальная прямая линия: 1. Проверьте начальную и конечную точки X и Y. 2. Сравните промежуточные точки против x и y начала и конца. 3. Если они примерно совпадают с координатами X, но восходящими или нисходящими Y-координатами, у вас есть вертикальная линия.

И так далее, усложняется для более сложных жестов.

Можно даже комбинировать жесты. Итак, скажем, у вас есть алгоритм для 6 жестов. Вы можете комбинировать их для формирования разных символов. Порядок, в котором создаются жесты, может быть важным, добавив дополнительный уровень безопасности.

Ответ 7

что, если бы вы взяли все координаты x, y штриха и выполнили какую-то линейную двухпозиционную операцию на них? Затем вы можете вычислить "приблизительный" хеш, и если число, вычисленное, когда штрих находится внутри... скажем, 10% вашего приближения, тогда вы предоставляете доступ..

Ответ 8

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

Например, что-то вроде метода разблокировки фигуры 9 клеток для Android может получить около 16 бит энтропии. Допустим, вы используете 5 секунд времени процессора для вычисления ключа шифрования. Затем со средним ПК требуется 5 * 2 ** 16/20 секунд или около 4,5 часов для взлома. Любая потеря энтропии во вводе или неэффективность в настройке ключа и шифровании будет быстро снижаться до минут, не говоря уже о том, используются ли кластеры компьютеров.

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