Храните ключ шифрования в связке ключей во время процесса установки приложения

Question

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

1

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

2

Кажется, лучше хранить ключ в связке ключей и получать его отсюда по запросу. Но чтобы избежать # 1, необходимо установить ключ к связке ключей в процессе установки. Является ли это возможным? Как это сделать?

3.

Я не знаю, что делают сертификаты. Помогают ли они в решении проблемы?

4

Передача ключа с сервера также плохая идея, потому что его очень легко перехватить.

Answer 1

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

На какой машине 100-1000x расшифровывает узкое место? Ваш сервер настолько занят, что не может выполнить асимметричное дешифрование? Вы должны делать это так редко на телефоне, что это не имеет значения. Я не говорю, что асим является ответом здесь; только то, что его производительность не должна быть проблемой для защиты одной строки, расшифрованной один раз.

Ваша служба требует SMS, чтобы все пользователи указали свой номер телефона? Вы пытаетесь автоматизировать захват номера телефона или вы позволяете пользователю вводить его самостоятельно? Автоматический захват телефонного номера через частные API (или не частные, но недокументированные данные конфигурации) и отправка его на сервер может привести к нарушению условий обслуживания. Это конкретный случай использования, от которого Apple хочет защитить пользователя. В вашем пользовательском интерфейсе вам обязательно нужно четко понимать, что вы делаете, и получить явное разрешение пользователя.

Лично я бы аутентифицировался следующим образом:

• Сервер отправляет запросный байт
• Клиент отправляет UUID, дату и хэш (UUID + вызов + userPassword + obfuscationKey + date).
• Сервер вычисляет то же самое, проверяет, что дата находится в допустимом диапазоне (30–60 с), и проверяет правильность.
• В этот момент я обычно заставляю сервер генерировать длинный, редкий, случайный идентификатор сеанса, который клиент может использовать для оставшейся части этого «сеанса» (в любом месте от следующих нескольких минут до следующего года) вместо повторной аутентификации в каждом сообщении.

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

Обратите внимание на "userPassword" там. Пользователь должен аутентифицироваться, используя то, что знает только пользователь. Ни UUID, ни номер телефона не являются такими вещами.

Система выше, плюс HTTPS, должна быть простой в реализации (я делал это много раз на многих языках), иметь хорошую производительность и быть защищенной до соответствующего уровня для широкого диапазона «подходящих».

Answer 2

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