TLS-подобное шифрование по Bluetooth на iOS?

Так что это может быть особый случай, но я надеюсь, что кто-то может помочь мне здесь.

Мне нужно поговорить с периферийным устройством через Bluetooth. Устройство, для которого мы также контролируем прошивку. Теперь проблема в том, что нам нужно убедиться, что никто не сможет подслушать, так как информация, которая будет отправлена, будет конфиденциальной. Это означает, что нам нужно зашифрованное сообщение.

Из того, что я вижу, является то, что Bluetooth LE 4.2 поддерживает шифрование, НО мы должны быть в состоянии поддерживать более старые iPhone, чем 6s. Это означает: нет BLE 4.2 и нет встроенного шифрования.

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

Последние несколько дней я потратил на поиски решений и способов их решения. Тем не менее, это, кажется, очень специфический случай, с которым не сталкивались многие люди. Все библиотеки, которые я смог найти, используют сокеты. И все, что я мог найти о сокетах для iOS, это IP-сеть, а не Bluetooth.

У кого-нибудь есть опыт работы с этим видом связи Bluetooth? Или какие-то другие предложения? Может быть, какое-то очевидное решение, которое я пропускаю?

Спасибо :)

 JanBrinker01 авг. 2016 г., 15:30
@ Эмиль: Мы хотели бы сделать это как можно ближе к HTTPS (то есть TLS). И мы стремимся к сертификатам, да.
 Emil01 авг. 2016 г., 14:06
Как бы вы хотели аутентифицировать оба конца и защитить от MITM-атак? У вас есть сертификаты или вы хотите использовать сравнение паролей? Может быть, только одна сторона должна быть аутентифицирована (как обычно на HTTPS)?
 Emil30 июл. 2016 г., 00:41
Сколько оперативной памяти / места в коде у вас на периферии и как быстро ваш процессор?
 Emil30 июл. 2016 г., 23:09
Каковы твои цели? Это только для защиты вашей прошивки? Если это так, надежно храните ключ шифрования внутри периферийного устройства, а также открытый ключ RSA, используемый для проверки подписи. Тогда просто отправьте прошивку в зашифрованном виде и подписали.
 JanBrinker01 авг. 2016 г., 10:11
@ user3732210, что на самом деле реальная угроза для нашего приложения. Многие люди могут слушать во время процесса сопряжения.
 JanBrinker01 авг. 2016 г., 10:04
@ Paulw11, насколько я вижу (пожалуйста, исправьте меня, если я ошибаюсь), вам нужно ввести код на смартфоне, который отображается на периферийном устройстве Bluetooth, чтобы вы могли подключиться. Но: наша периферия не имеет дисплея. Нет возможности склеивания
 Emil01 авг. 2016 г., 13:59
Вы всегда можете запустить собственную схему шифрования / аутентификации поверх BLE, особенно если сопряжение BLE 4.x не достаточно хорошее.
 Paulw1129 июл. 2016 г., 23:49
Атрибуты зашифрованного GATT поддерживаются на iphone4s и выше и iPad mini и выше (т.е. на любом устройстве с BLE). BLE 4.2 имеет лучшее шифрование и поддержку шифрования всего соединения, но главное, что он дает вам - это защита от MITM-атак во время сопряжения. Это большой риск для вас?
 Paulw1101 авг. 2016 г., 10:25
Если вы не можете надежно соединиться, то даже BLE 4.2 вам не поможет.pomcor.com/2015/06/03/has-bluetooth-become-secure
 Paulw1101 авг. 2016 г., 15:45
Вы можете жестко закодировать закрытый ключ на вашем устройстве Bluetooth. Затем ваше приложение может использовать соответствующий открытый ключ для шифрования ключа сеанса и отправки его на устройство. Затем ваше приложение и устройство могут обмениваться сообщениями, зашифрованными с помощью этого сеансового ключа, с использованием AES или аналогичного.
 JanBrinker01 авг. 2016 г., 16:39
@ Paulw11 нет, мы не можем. Может быть много периферийных устройств, и мы не можем использовать один и тот же ключ для каждого периферийного устройства. Также по практическим причинам у нас не может быть периферийных устройств, имеющих уникальные пары ключей, поскольку мы не можем отправить приложение, содержащее все открытые ключи, на все периферийные устройства. Подключение к Интернету может быть дано не всегда, поэтому мы также не можем опросить сервер. Так что, действительно, самым простым решением для этого было бы использовать TLS. :)
 JanBrinker01 авг. 2016 г., 10:09
@ Эмиль, у нас столько же оборудования, сколько у нынешних смартфонов. Что бы ни использовал конечный потребитель, будь то iPhone 5, 5s, 6, 6s или какой-то iPad ... Цель не в том, чтобы защитить прошивку. Цель состоит в том, чтобы защитить секреты, которыми обмениваются периферийные устройства. Важная часть: мы не можем использовать симметричное шифрование по разным причинам. Так что нет предопределенных ключей для периферийных устройств.
 Preeti30 июл. 2016 г., 02:53
До версии 4.2 BLE поддерживает шифрование AES-CCM, но с ограниченной защитой от перехвата. Т.е., если подслушиватель присутствовал во время процесса сопряжения между iPhone и периферийным устройством, он мог бы получить общие ключи и прослушивать во время будущей зашифрованной связи. Если перехватчик не присутствовал во время процесса сопряжения, он не смог бы расшифровать зашифрованные данные.
 Paulw1101 авг. 2016 г., 22:55
То, что я описал, по сути является ядром TLS. С TLS (по крайней мере) один конец имеет фиксированную пару открытый / закрытый ключ. Это необходимо для безопасного обмена ключом сеанса. Поскольку вы не доверяете соединению быть защищенным от перехвата, вы не можете совместно использовать ключ сеанса по ссылке, не шифруя его. Для его шифрования требуется предварительный общий асимметричный ключ. Не имеет значения, используют ли все устройства одну и ту же пару открытого / закрытого ключей, если злоумышленнику будет достаточно сложно извлечь закрытый ключ из встроенного программного обеспечения. Если это слишком большой риск, тогда используйте кабель, а не BT
 JanBrinker01 авг. 2016 г., 15:31
@ Paulw11: нам не нужно создавать связь. Нам нужно обмениваться секретной информацией с периферийным устройством, чтобы другие не слушали (шифрование с открытым ключом с помощью обмена ключами, как это делает TLS), а затем мы стремимся использовать сертификаты на одном конце для аутентификации. Обоснование таково: если TLS безопасен, то мы также можем безопасно обмениваться ключами с «TLS через Bluetooth». Вопрос: как это сделать на iOS?

Ответы на вопрос(1)

Вся основа в TLS основывается на доверии, то есть сертификатах, центрах сертификации и цепочках сертификации, а также проверке подлинности всех отправленных и полученных данных. Можно сказать, что вся безопасность зависит от аутентификации. Само шифрование довольно простое. Один вопрос, на который вы должны ответить:

Должна ли быть возможность подключения к периферийным устройствам, которые имитируют ваш протокол, то есть к периферийным устройствам, НЕ произведенным вами? Если нет, в вашем помещении у вас должен быть какой-то (уникальный) секрет в каждом периферийном устройстве, например, закрытый ключ. Соответствующий открытый ключ может быть подписан вашим собственным центром сертификации. Открытый ключ CA может быть включен в ваше приложение для смартфона (поэтому вам нужен только один ключ в вашем приложении, а не один для всех периферийных устройств). Таким образом, вы можете проверить, что периферийное устройство, к которому вы подключаетесь, изготовлено вашей компанией. Этот открытый ключ также должен быть идентификатор периферийного устройства. Если у вас нет пары секретного / открытого ключа внутри периферийного устройства, и вы не можете выполнить сравнение паролей и не имеете общего симметричного ключа, насколько я знаю, невозможно избежать атак «человек посередине».

Поскольку каждый смартфон также должен изначально рассматриваться как не прошедший проверку подлинности, если вам необходимо возобновить сеанс позже, необходимо сохранить уникальный идентификатор, назначенный каждому смартфону, на периферийном устройстве.

Имея это в виду, у вас есть три основных варианта:

Попробуйте модифицировать какое-либо существующее программное обеспечение сервера TLS, например mbedtls, для отправки всех пакетов через BLE, а не через сокеты. У меня есть ощущение, что это может быть нетривиально, потому что кажется, что оно основано на концепции блокирования сокетов.Просто прочитайте спецификацию TLS наhttps://tools.ietf.org/html/rfc5246 и внедрить минимальный сервер TLS с только необходимыми функциями. На самом деле это не так сложно, как может показаться в первую очередь, если вы выполняете только минимальную реализацию и используете существующие строительные блоки, такие как код синтаксического анализа сертификатов RSA, AES, SHA-2, ECDHE, X.509 (вы можете найти их здесь:https://tls.mbed.org/source-code).Извлеките важные части в TLS и создайте упрощенный протокол без всех параметров согласования (поскольку они могут быть жестко заданы). Например, вам не нужно отправлять и иметь возможность анализировать все виды сообщений (например, ClientHello), обрабатывать фрагментацию и т. Д. Просто отправляйте случайные значения, сертификаты, подписанные данные, зашифрованные данные напрямую.
 TrinityTonic25 мая 2018 г., 12:51
Устаревший, но может быть интересным для новичков. (1) может быть сделано и с неблокирующим вводом / выводом. mbedtls (и другие реализации SSL) поддерживают это. НЕ выбирайте (2) или (3), если вы не являетесь экспертом по безопасности, и даже в этом случае это не рекомендуется. Никогда не катай свои собственные.

Ваш ответ на вопрос