Как скрыть секретные ключи в коде?
Здесь есть много хороших идей, но они разбросаны, поэтому я попытаюсь создать ответ, который будет лучше, хотя проблема была решена.
Во-первых, словарь не имеет гарантированного заказа, поэтому вы используете его только для быстрого поиска ключа и поиска соответствующего значения, или вы перечислите все пары ключ-значение, не заботясь о том, что такое заказ.
Если вы хотите заказать , вы используете OrderedDictionary, но компромисс в том, что поиск медленнее, поэтому, если вам не нужен порядок, не просите об этом.
Словари (и HashMap на Java) используют хеширование. Это O (1) раз, независимо от размера вашей таблицы. В упорядоченных словарях обычно используется какое-то сбалансированное дерево, которое является O (log2 (n)), так как ваши данные растут, доступ становится медленнее. Чтобы сравнить, для 1 миллиона элементов, это порядка 2 ^ 20, так что вам нужно будет сделать порядка 20 поисков для дерева, но 1 для хэш-карты. Это намного быстрее.
Хеширование детерминировано. Недетерминизм означает, что когда вы хэш (5) в первый раз, а вы хеш (5) в следующий раз, вы получите другое место. Это было бы совершенно бесполезно.
То, что люди хотели сказать, заключается в том, что если вы добавляете вещи в словарь, порядок сложный и может быть изменен в любое время, когда вы добавляете (или потенциально удаляете) элемент. Например, представьте, что хеш-таблица содержит в себе 500 тыс. Элементов, и у вас есть значения 400 тыс. Когда вы добавляете еще один, вы достигаете критического порога, потому что для его эффективности требуется около 20% свободного пространства, поэтому он выделяет большую таблицу (скажем, 1 миллион записей) и повторно хеширует все значения. Теперь они все в разных местах, чем раньше.
Если вы будете строить тот же словарь дважды (внимательно прочитайте мое заявление, ТО ЖЕ), вы получите тот же порядок. Но, как правильно говорит Джон, не рассчитывайте на это. Слишком много вещей может сделать это не то же самое, даже изначально выделенного размера.
Это поднимает отличную точку. На самом деле очень дорого изменить размер хэш-карты. Это означает, что вам нужно выделить большую таблицу и повторно вставить каждую пару «ключ-значение». Таким образом, стоит выделить 10x памяти, в которой она нуждается, а не иметь хотя бы одного роста. Знайте свой размер hashmap и предопределите достаточно, если это вообще возможно, это огромный выигрыш в производительности. И если у вас плохая реализация, которая не изменяет размер, это может быть катастрофой, если вы выберете слишком маленький размер.
Теперь, о чем Джон спорил со мной в моем комментарии в своем ответе, было то, что если вы добавляете объекты в словарь в два разных цикла, вы получите два разных порядка. Правда, но это не ошибка словаря.
Когда вы говорите:
new Foo();
вы создаете новый объект в новом месте в памяти.
Если вы используете значение Foo как ключ в словаре, без какой-либо другой информации, единственное, что они могут сделать, это использовать адрес объекта в качестве ключа.
Это означает, что
var f1 = new Foo(1);
var f2 = new Foo(1);
f1 и f2 не являются одним и тем же объектом, даже если они имеют одинаковые значения.
Итак, если вы должны были помещать их в словари:
var test = new Dictionary();
test.Add(f1, "zero");
don 't ожидать, что он будет таким же, как:
var test = new Dictionary();
test.Add(f2, "zero");
, даже если оба f1 и f2 имеют одинаковые значения. Это не имеет никакого отношения к детерминированному поведению Словаря.
Хеширование - это удивительная тема в информатике, мой любимый преподавать в структурах данных.
Проверьте Cormen и Leiserson за книга высокого класса по красно-черным деревьям против хеширования Этот парень по имени Боб имеет отличный сайт о хэшировании и оптимальных хэшах: http://burtleburtle.net/bob
8 ответов
The reasons those secret keys were so easily discovered is because they were hidden in software.
Avoid hiding secrets in software at all cost - obfuscation will only get you so far. Ask yourself this: How well can I hide a key in software from someone with full access to the disassembly, user mode and kernel mode debuggers, and no day job? It's only a matter of time before it gets cracked.
Вы просто прячете ключ где-нибудь и расшифровываете его, когда вам это нужно. Использование ключа «надежно» является сложной частью. Взломщики могут установить точку останова на место, где вы используете расшифрованный ключ, и сбросить его. Они могут сканировать ваш код на наличие паттернов, которые показывают, что вы используете известный криптоалгоритм (большинство алгоритмов имеют предварительно вычисленные таблицы). и т. д. и т. д.
Вот почему вам нужно сделать весь исполняемый файл сложным для анализа. Для этого вы используете исполняемые упаковщики, запускаете код на виртуальной машине, проверяете целостность и т. Д. Все это замедляет отладку и изменение кода.
Как отмечают большинство людей, вы не можете никого остановить, просто замедлите их , Я бы пошел на форум взломщиков и спросил там о том, как скрыть ключевые проблемы. Скорее всего, они полезны, если вы спросите хорошо.
ps. Шифрование с открытым ключом не будет скрывать ключ лучше, но это может затруднить (или теоретически невозможно) создание генератора ключей, если вы используете схему лицензирования.
Суть в том, что вы не можете. Смотрите любой другой комментарий здесь по причинам, почему. Даже программное обеспечение для шифрования, такое как PGP / GPG, хранит ключи в файле и затем настоятельно рекомендует хранить эти файлы на флэш-накопителе в сейфе или в другом безопасном месте. Ключи, хранящиеся как часть исполняемого кода, будут обнаружены.
На самом деле, если вы пытаетесь зашифровать на клиентском компьютере что-либо, что будет расшифровано клиентом как часть обычных операций, это тоже дурацкое поручение. Клиентские машины по своей природе небезопасны, и вы не можете контролировать, что они собираются делать с вашими данными.
Если вы вместо этого пытаетесь выполнить аутентификацию, посмотрите на интернет-аутентификацию с входами на сервер. или какой-то сгенерированный KeyCode, который используется для проверки программного обеспечения.
Секретные ключи как часть государственно-частной пары ключей должны храниться в файлах данных, которые можно защитить. Симметричные ключи должны генерироваться на лету как Session Keys, а затем отбрасываться. Всегда предполагайте, что любой, у кого есть секретный или сеансовый ключ на своем компьютере, сможет его обнаружить и использовать против ваших намерений.
Прочтите « Прикладная криптография » Брюса Шнайера для получения дополнительной информации.
Вы не можете спрятать ключ навсегда. Но вы можете сделать это трудно найти. Некоторые подходы заключаются в том, чтобы зашифровать ключ в памяти, сохранить несколько копий (возможно, зашифрованных по-разному), которые сверяются друг с другом, оставить пустые копии для доступа, сохранить ключ в каком-то странном формате и т. Д. Ни один из них не будет работать, если кто-то действительно хочет ваш ключ, но вы можете, по крайней мере, отговорить случайного / неопытного злоумышленника.
Когда мы начали разработку нашего программного обеспечения, мы создали файл с датой лицензии. Затем мы поняли, что не слишком много людей даже заинтересованы в покупке нашего программного обеспечения. Затем мы решили отдать его бесплатно. Гораздо больше людей начали беспокоиться, по крайней мере, пробуя наш шедевр. Наконец, мы открыли наше программное обеспечение с открытым исходным кодом. Гораздо больше пользователей начали использовать его. Теперь мы просто надеемся, что небольшое количество этих пользователей может превратиться в платных клиентов (т.е. купить поддержку продукта или запросить настройку).
Суть в том, что если кто-то захочет взломать ваше программное обеспечение, он / она сделает это. это все равно. Стоит ли тратить свое время на защиту этого скрытого секретного ключа?
Вам не всегда нужен ключ для проверки лицензии.
Но игнорируя этот факт, ваш ключ также может быть результатом другой функции. Вы на самом деле не храните определенное значение ключа, вместо этого у вас есть функция, которая генерирует ключ на лету (всегда тот же результат). Хотя это и не невозможно, найти его гораздо сложнее, поскольку вы больше не ищете значение, но вы должны выяснить, что это уравнение.
Скрытие секретных ключей в коде не будет по-настоящему безопасным. Как вы, возможно, заметили, DVD-диски и большинство регистраций серийных номеров программного обеспечения взламываются ежедневно. Если вы действительно хотите что-то защитить, вам нужно использовать шифрование с открытым ключом.
Я думаю, что это одна из главных причин, по которой DVD и BluRay были взломаны так быстро. Я думаю, что единственный способ, которым они действительно могут помешать обычному человеку иметь возможность цифрового копирования домашних фильмов, - это если они создали носитель, который не был лицензирован для использования на компьютерах, и мог использоваться только на сертифицированных проигрывателях. Вырезал бы часть рынка, которая хотела смотреть фильмы на своих компьютерах и ноутбуках, но, вероятно, перестал бы иметь идеальные цифровые рипы чуть дольше и лишил бы среднего человека возможности сделать это.