Предисловие

Сертификаты, ключи, доступы, безопасность - всё очень запутанно. Многие из нас просто знают, как решать большинство ошибок, связанных с этим, либо могут это быстро нагуглить. Сегодня хотелось бы постараться углубиться в данную тему в рамках 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, но тем не менее, надеюсь было интересно и познавательно прочитать. Тема достаточно сложная, чтобы описать её совсем простой лексикой, поэтому возможно после первого прочтения, вам захочется перечитать еще раз или вернуться сюда позже, в конце рабочей недели. Это нормально. Развивайтесь, копайте глубже.

Спасибо за ваше уделенное время. Поставьте лайк этой статье, это мне сильно поможет, хорошего вечера :)

Комментарии (8)


  1. Protos
    07.11.2022 20:34
    +1

    Было бы круто, если бы начиная с Профили предоставления (Provisioning profiles) были бы какие-то картинки, схемы или скриншоты с порталов Apple, для большего понимания.


    1. EmachinesDIMA
      07.11.2022 23:44

      Поддерживаю.

      Не хватает конкретики и иллюстраций для лучшего восприятия.

      Сертификаты, ключи, провиженинги и их виды. Разъяснений не хватает.

      От себя добавлю (свою статью на эту тему не оформил, но могу сделать это очень быстро) - интересующимся следует посмотреть в сторону fastlane match и как это работает.

      Fastlane- это ruby-фрэймворк который позволяет удобно собирать приложения благодаря написанным actions (функциям) и match является одной из них - позволяет хранить секреты в зашифрованном виде в приватном репозитории/хранилище .


    1. maxnechaev Автор
      08.11.2022 07:26
      +1

      Абсолютно правы. Моя недоработка. Буду добавлять больше наглядного материала. Спасибо


  1. saboteur_kiev
    08.11.2022 01:28
    +2

    Непонятно почему статья называется Сертификаты Apple, если рассказано про обычные сертификаты, которые используются в любой системе.

    Не нашел НИ ОДНОГО нюанса, относящегося именно к Apple


    1. maxnechaev Автор
      08.11.2022 07:27

      Спасибо за комментарий. Только учусь выстраивать композицию статей, видимо перегнул со вступлением и не углубил в Apple, благодарю за ваше время!


  1. pulsework
    08.11.2022 13:17

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

    и еще - вы описали систему из двух ключей - но вроде если их будет 4 то обмен между сервером и клиентом станет полностью безопасен и без дополнительных центров и сертификатов изначально находящихся на ПК?


  1. gdt
    09.11.2022 21:09

    Подскажите, пожалуйста, если абстрактные Алиса и Боб обменяются публичными ключами - "вор" все еще сможет что-то прочесть (без доступа к приватным ключам)? Т е Алиса шифрует свои сообщения публичным ключом Боба, а Боб - публичным ключом Алисы.

    И да, ничего специфичного для iOS.


  1. lex899
    09.11.2022 21:40

    Мне кажется абсолютно некорректно описана криптография как таковая.

    Один ключ служит для того, чтобы зашифровать сообщение, второй же, чтобы расшифровать его

    Строго говоря шифровать и подписывать можно как закрытым так и открытым ключом. Правда шифровать закрытым бесполезно.

    вор всё еще может перехватить ваш открытый ключ.

    Смысл открытого ключа именно в том что он ОТКРЫТЫЙ. От того что его перехватят ничего не произойдет.

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

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

    Центры сертификации предоставляет вам файл, содержащий публичный ключ, который зашифрован приватным ключом центра сертификации. Результатом всей это операции и являются сертификаты.

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