Многоадресное шифрование для загрузки файла

Question

У меня есть программа, которая имеет платные дополнения, которые часто обновляются. Пользователи должны будут купить подписку, чтобы иметь возможность использовать определенные дополнения (т.е. платить ежемесячно бесплатно).

Основная причина, по которой я выбрал модель надстроек на основе подписки, проста: обновления действительно выгодны, так как надстройки должны часто обновляться. Короче говоря, эти дополнения в основном бесполезны без обновлений, потому что программное обеспечение, с которым он работает, также часто обновляется, и все будет плохо.

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

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

Это самое эффективное решение, которое я придумал:

• Пользователь получает случайный ключ AES256.
• Мы зашифровываем платный аддон случайным ключом AES256.
• Затем мы шифруем ключ аддона ключом пользователя.
• Промойте и повторите вышеописанное со всеми пользователями и надстройками и создайте один монолитный ключевой файл.
• Загрузите зашифрованный файл дополнения и монолитный ключевой файл в службу обмена файлами.

Вышеупомянутое решение имеет следующие характеристики:

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

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

Пример:

• У нас 10000 пользователей и 100 аддонов.
• 10000 пользователей * 100 дополнений = 1 000 000 ключей
• 1 000 000 ключей * 300 байт на ключ ** = 300 МБ

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

Даже в лучшем случае (невозможном) это будет ключевой файл размером 96 МБ.

Есть ли другие решения этой (не) известной проблемы? Как они называются и где они используются?

Answer 1

Вы пытаетесь внедрить DRM, хотя данные в этом случае являются надстройкой. Это, как известно, не имеет решения, если вы не контролируете устройство пользователя (в значительной степени).

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

Обратите внимание, что по умолчанию шифрование AES только добавляет конфиденциальности. Конфиденциальность легко нарушается. Я бы хотя бы добавил целостность и аутентичность, используя тег аутентификации (например, используя HMAC). Таким образом, вы можете создать относительно безопасную схему, которая работает, если (или, для DRM, до тех пор) код вашего приложения не будет взломан или ключи пользователя не будут переданы.