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

Question

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

1.

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

2.

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

3.

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

4.

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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