Защита мобильных соединений - Сохранение секретов и ключей

Question

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

Вот что, я думаю, я правильно понял: Внедряя SSL-сертификат (и, необязательно, привязывание SSL на клиенте), вы в значительной степени предотвращаете обнюхивание информации о пользователях в открытых сетях и имитацию других пользователей («Человек-в-середине» и т. Д.). Любой дополнительный уровень безопасности предназначен для защиты сервера и предотвращения доступа к информации о вашей структуре транзакций и деталях. Другие уровни безопасности включают аутентификацию сообщения (например, HMAC) для аутентификации сообщения перед его обработкой и шифрования для «скрытия» содержимого сообщения.

Я хотел бы реализовать процесс Encrypt-then-HMAC для дальнейшего обеспечения транзакций, и это мой вопрос относительно этого процесса: Как вы храните ключ/секрет на клиенте? Я понимаю, что это будет зависеть от специфики приложения и степени безопасности, которую он хочет достичь. По этой причине я включаю в себя некоторые особенности: не существует высокочувствительной информации о пользователе, который хранится или передается (SSN, банковское дело и т. Д.), Но приложение обрабатывает платежи, и, следовательно, могут возникнуть большие затраты, если кто-то начнет возиться с сервером и платежной системы. Поэтому я стараюсь реализовать безопасную передачу между клиентом и сервером, не делая ничего необычного или непропорционального в усилиях.

Я много читал о предмете и из того, что мог собрать, независимо от того, каким образом вы получаете ключ или секрет, в какой-то момент он будет представлен в виде открытого текста для логики шифрования/хэширования, и поэтому кто-то будет быть в состоянии отлаживать приложение, точку прерывания, что шаг и компрометировать ключ/секрет. Как вы обходите это (и можете ли вы)? Что будет считаться «подходящим» (hardcoding?, Происходящим из структуры таблицы или других элементов?)?

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

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

Answer 1

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

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

Если клиент является устройством iOS, вы можете сохранить ключ в keychain, это криптографически защищенная часть оборудования, эквивалентная TPM (Trusted Platform Module).Он защищен PIN-кодом PIN-кода устройства, обратите внимание на то, что PIN-код может быть установлен более, чем четыре цифры по умолчанию. Атаки на устройстве, даже на взломанных телефонах с использованием тюрьмы, должны использовать брелок, и попытки имеют минимальное время для каждой попытки (по дизайну), что обеспечивает минимальное среднее время атаки, основанное на сложности ПИН. Выключение устройства - единственная доступная атака - это грубая сила, которая недопустима.

Недостатком является то, что при шифровании и расшифровке ключ будет чистым. Если ключ когда-либо находится в объекте Foundation (например: NSString/NSData), существует потенциал, который он выживет после его использования, лучше оставаться с массивами символов «c» и очистить их после использования.

ОК, практическое решение: Нанять специалиста по криптографическому домену, если вы действительно хотите безопасности. При минимальном найме, чтобы советовать и проверять дизайн и реализацию, я это делаю. Ищите кого-то с сертификатом CISSP и опытом в области шифрования. CISSP требует как минимум пять лет работы на 100% в поле под прямым наблюдением, шестичасовое испытание и обычно около 160 часов тестового времени обучения и 40 часов непрерывного образования в год.