Предисловие
Сертификаты, ключи, доступы, безопасность - всё очень запутанно. Многие из нас просто знают, как решать большинство ошибок, связанных с этим, либо могут это быстро нагуглить. Сегодня хотелось бы постараться углубиться в данную тему в рамках Apple и понять, почему все так работает. Меня зовут Макс Нечаев, я Senior iOS-developer в крупном фуд-тех стартапе в Катаре - Snoonu. Очень надеюсь, что статья поможет вам немного лучше понять данную область разработки.
Сегодня поговорим о сертификатах и профилях подготовки в Swift.
Введение. Про систему криптографии
Думаю, что вы прекрасно понимаете: если один человек передает сообщение другому - то это не является безопасным способом обмена информацией. Особенно, если в их цепочку вмешается третий, который сможет спокойно читать сообщения ничего не подозревающих собеседников.
Здесь на сцену выходит первый механизм шифрования информации - симметрическая криптография. Упростив, можно сказать, что это некий способ зашифровать сообщение первого собеседника с помощью специального ключа, передать зашифрованное сообщение, далее расшифровать его уже у второго собеседника с помощью того же самого ключа.
В данном кейсе злоумышленник не сможет ничего понять, так как информация зашифрована, непонятна, не логична. Отлично, мы справились. Способ идеальный. Так ли это? Но… а что если у злоумышленника появится этот ключ?
Да и вообще, как мы передадим этот ключ от первого собеседника ко второму? Ведь если мы пошлем его тем же способом, что и сообщения, то наш вор получит ключ, а значит и расшифрует все сообщения. Зашифровать ключ? Хорошо, а тот ключ, который сможет расшифровать первый ключ? Что же тогда делать с ним? Отправлять также?
Думаю вы видите бесконечный цикл, в котором в любом случае выигрывает вор.
Есть один вариант, его когда-то использовал WhatsApp, вы могли начать секретный чат с собеседником. По специальному QR-коду собеседник ставил к себе ключ шифрования. Благодаря этому действию, ваш ключ не передавался онлайн. Но есть нюансы. Во-первых, это не удобно. Ведь для расшифровки того, что вам написал собеседник нужно было находиться рядом, как минимум на момент создания чата. Во-вторых, QR-код, будем честны, не самый безопасный способ передавать ключи шифрования.
Ассиметричное шифрование
Здесь на помощь приходит более современный и интересный способ. Он связан с увеличением количества ключей и с другим способом шифрования информации. Прежде всего, здесь мы будем использовать два ключа.
Один ключ служит для того, чтобы зашифровать сообщение, второй же, чтобы расшифровать его.
Скорее всего вы что-то уже об этом слышали (особенно если интересовались шифрованием в блокчейне). У вас есть закрытый и открытый ключи. Здесь немного подробнее.
Даже если злоумышленник перехватит один из ключей, это не так опасно, если мы будем уверены, что второй надежно защищен, лучше всего чтобы второй ключ хранился офлайн.
Если говорить менее абстрактно. Допустим, что сервер сгенерирует пару ключей: открытый и приватный. Сервер отправляет вам открытый ключ. С помощью него вы шифруете своё сообщение (напомню, его невозможно теперь прочитать без приватного ключа). Сервер получает ваше сообщение и расшифровывает его без проблем. После чего, сервер отправляет вам зашифрованное сообщение, которое вы, в свою очередь, расшифровываете с помощью открытого ключа. Работает?
К сожалению, здесь всё не так просто. Наш вор всё еще может перехватить ваш открытый ключ. Таким образом, он не сможет прочитать те сообщения, которые вы отправляете на сервер, верно, но он расшифрует и прочитает те сообщения, которые придут к вам.
Суть в том, чтобы клиент и сервер действительно смогли подтвердить то, что общаются друг с другом. В данном случае будут использованы технологии как симметричного, так и асимметричного шифрования.
Начинается игра в кошки мышки. Ведь нужно зашифровать ключ, как я уже писал выше, и сам механизм шифрования тоже зашифровать. Опять мы попадаем в бесконечный цикл. Здесь можно было бы углубиться в конкретные протоколы шифрования и как они работают, но статья не об этом. Я думаю, что вы уже поняли, какая проблема стоит перед нам? Какое же решение?
По классике фильмов в жанре “триллер”, “неожиданный поворот”-решение проблемы уже было упомянуто в этой статье.
Для того, чтобы избежать этого бесконечного цикла, этой игры в “кошки-мышки”, нам нужно выйти за пределы интернета, уйти в офлайн. Наконец-то мы подошли к самому интересному!
Центры сертификации
Здесь на сцену выходит третья сторона. Центры сертификации. Они-то как раз и помогают чуть больше обезопасить соединение. Центры сертификации предоставляет вам файл, содержащий публичный ключ, который зашифрован приватным ключом центра сертификации. Результатом всей это операции и являются сертификаты. Цель здесь, предоставить пользователю безопасный доступ к открытому ключу.
Если у пользователя есть доступ к открытому ключу конкретного центра сертификации, он может прочитать сертификат, что и будет доказательством, что это не подделка.
Звучать может немного запутанно, да и вообще непонятно, как это может работать безопасно и почему вор не может перехватить и это.
Самое интересное здесь то, что таковые центры сертификации не скачиваются, они уже зашиты в программное обеспечение. Будь то браузер или система iOS. Ключи не отправляются. Они уже есть у вас!
В iOS вы столкнетесь с сертификатами, когда захотите дистрибутировать своё приложение. Вы создадите пару ключей и захотите попросить Apple выступить в качестве центра сертификации для вашего приложения. Выдать сертификат по вашему bundle ID.
Главная цель здесь, обезопасить загрузку приложения, а также возможность пользователям его устанавливать.
Если вы внимательны, думаю заметили, что нельзя создать даже архив приложения, не подписав его. Apple хотят быть уверены, что именно вы (или ваши коллеги, обладающие сертификатами) создали этот бинарный код приложения, а не третьи лица. По этой же причине все bundle ID должны быть уникальными.
Профили предоставления (Provisioning profiles)
В отличие от сертификатов, концепция профилей специфична для разработки iOS, и их назначение напрямую связано с усилиями Apple, направленными на то, чтобы iOS воспринималась как безопасная операционная система. Вот в чем проблема: как Apple может предоставить разработчикам более глубокий доступ к операционной системе и оборудованию без ущерба для безопасности обычного пользователя?
Ответ: Позвольте им делать все, что они хотят, но ограничьте их возможность делиться своими творениями в зависимости от того, что делает продукт. В то время как Android позволяет вам загружать двоичные файлы из Интернета и устанавливать их на свой телефон без ограничений, iOS запрещает вам делать это, если разработчик явно не подтвердит во время компиляции, что вашему конкретному телефону разрешено устанавливать этот конкретный двоичный файл.
Вы уже знаете, что это за подтверждения – это то, что представляет собой профиль подготовки, и они включены в ваши приложения вместе с вашими сертификатами, чтобы Apple / iOS могли быть полностью уверены в двоичных файлах, которые они получают.
Разработчики обязаны предоставлять профили при настройке физических устройств, и они содержат такую информацию, как:
- Идентификатор пакета приложения
- Сертификаты, привязанные к этому идентификатору
- Возможности приложения (например, доступ к камере)
Процесс "подписания", упомянутый ранее, затем объединит эту информацию в двоичный файл, который позже в процессе проверяется устройством, пытающимся установить приложение, чтобы подтвердить, что двоичный файл является законным и что его действительно разрешено устанавливать.
Для всех сборок, ориентированных на физические устройства, требуются профили подготовки, но только для отладочных сборок требуется явный список устройств. Для корпоративных сборок и сборок App Store профили не обязательно должны включать данные об устройстве, поскольку такие сборки предназначены для установки теоретически бесконечным количеством пользователей.
Выводы
Данная информация не самая необходимая, если вы занимаетесь разработкой приложение под iOS, но тем не менее, надеюсь было интересно и познавательно прочитать. Тема достаточно сложная, чтобы описать её совсем простой лексикой, поэтому возможно после первого прочтения, вам захочется перечитать еще раз или вернуться сюда позже, в конце рабочей недели. Это нормально. Развивайтесь, копайте глубже.
Спасибо за ваше уделенное время. Поставьте лайк этой статье, это мне сильно поможет, хорошего вечера :)
