Как безопасно хранить данные на мобильном устройстве?

Question

Я должен разработать/реализовать криптографическое решение для приложения для потокового видео, предназначенного как для IOS, так и для Android. Моим основным криптографическим требованием является сохранение видеопотоков, зашифрованных на мобильном устройстве, и запрещение пользователям запускать его на любом другом устройстве/программе. Таким образом, мне нужен хороший метод для дешифрования потока во время каждой игры, не мешая пользователю вводить пароль каждый раз.

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

Что я узнал:

1. Cryptography бы мой потокового медленно. Мне нужно использовать это разумно.
2. Разработчики/разработчики не должны пытаться «изобретать» новые криптографические алгоритмы самостоятельно. Всегда рекомендуется использовать существующие проверенные решения.
3. Сила/слабость решения не в разработке/выборе алгоритма, а в политике управления ключами и управления ключами
4. Невозможно сохранить ключ дешифрования на мобильном устройстве, и все советуют против Это. Таким образом, это исключает возможность использования любых схем на основе PKI. Единственное возможное решение - попросить пользователя каждый раз вводить пароль для дешифрования потока.
5. У меня возникла идея использовать ID-based encryption scheme и реализовать PKG на самом мобильном устройстве. Но вскоре я понял, что это также требует хранения «тайны» на устройстве, которая оказывается той же проблемой, что и выше.

После прочтения множества статей/проблем/решений я оказался в плане того, что я мог сделать.

1. Я бы воспользовался решением на C++, чтобы максимально запутать код.
2. Я бы использовал симметричную схему AES 256 для шифрования/дешифрования.
3. Я бы использовал несколько параметров от устройства до нескольких уровней хэширования (и добавление параметров на каждом уровне в качестве соли, чтобы сделать его как можно более сложным), чтобы получить хэш, который будет действовать как ключ. Это (надеюсь) безопасно идентифицирует мою установку пользователя. Это вдохновляет от here.
4. Я бы зашифровал данные на самом устройстве после его загрузки на устройство. От сервера к клиенту я бы сделал какое-то скремблирование, чей ключ был бы закодирован как алгоритм (например, методы кривой заполнения пробела). Я знаю, что это может быть самое слабое звено, но я нашел бы лучшее решение для этого позже.

Мои вопросы:

1. Даже после прочтения всех этих, одна вещь мне не ясно. Существует несколько алгоритмов. Как злоумышленник знает, какой алгоритм используется в продукте? Только если злоумышленник это знает, он может разработать методы взлома, верно?Просто, чтобы взять пример слабой реализации алгоритма DES, только если злоумышленник знает, что я использую DES, она может найти способы взломать его. Как она это знает? Могу ли я обмануть атакующего, создав интерфейс/объявить строки в программе, чтобы заставить злоумышленника полагать, что я реализую AES, но на самом деле я реализую простой DES? Применяют ли криптографические дизайнеры к таким методам?

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

Прошу прощения, что мои вопросы немного абстрактны. Это потому, что я все еще на этапе проектирования и все же реализую что-то конкретное.

Answer 1

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

Это называется «DRM». Существует два типа DRM: DRM, который был взломан, и DRM, которого никто не мешал пытаться взломать.

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

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

Я бы использовал симметричную схему AES 256 для шифрования/дешифрования.

Это нарушение № 1, № 4 и № 5 того, что вы узнали.

Как злоумышленник знает, какой алгоритм используется в продукте?

Просмотрев ваш код.

Могу ли я обмануть атакующего, создав интерфейс/объявить строки в программе, чтобы злоумышленник верил, что я реализую AES, но на самом деле я реализую простой DES?

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