Apple HomeKit

В данной статье речь пойдет про Apple HomeKit Accessory Protocol (HAP): внутренности и разработку контроллера.

Apple HomeKit создан для взаимодействия контроллера (по умолчанию iOS-устройства, приложение Home) и множества устройств(аксессуаров). Протокол открыт для некоммерческого использования, загрузить его можно с сайта Apple. На основе этой версии протокола создано несколько open-source проектов, и когда говорят про HomeKit на каком-нибуль Raspberry Pi обычно подразумевают установку homebridge и плагинов для создания совместимых аксессуаров.

Обратная же задача — создание контроллера — не такая распространенная и из проектов мне удалось найти лишь pypi.org/project/homekit/.

Поставим задачу создать контроллер, например, для управления аксессуарами с Android-телефона и попробуем ее решить. Для простоты будем работать только с IP-сетями, без Bluetooth.

Как это должно работать?

1. Обнаружение устройства

Для того, чтобы начать работать с аксессуарами, их необходимо первым делом обнаружить. Устройства рекламируют себя в соответствии с протоколами Multicast DNS и DNS service discovery.

Говоря проще, можно в локальной сети обнаружить устройство, отправив multicast запрос _hap._tcp.local по адресу 224.0.0.251, и, получив ответ, распарсить DNS записи A, SRV, TXT. После этого можно подключаться к сервису, используя полученную информацию.

2. Установка защищенного соединения

Возможно два сценария: устройства уже связаны, либо связь (pairing) надо только установить. В первом случае нужно перемещаться к шагу /pair-verify, в случае же установления нового соединения, первым делом надо выполнить шаг /pair-setup.

Apple HomeKit использует протокол Stanfordʼs Secure Remote Password (SRP) с использованием пароля (пин-кода).

3. Работа с аксессуарами, характеристиками и их значениями.

/pair-setup

Коммуникация происходит по установленному TCP соединению. Все запросы в данном шаге — это обычные HTTP POST запросы с типом данных application/pairing+tlv8 и соответственно с телом в TLV-кодировке.

Далее кратко что происходит на данном этапе:

• M1: контроллер отправляет запрос на установление связи (SRP Start Request)

• M2: аксессуар инициирует новую сессию SRP, генерирует необходимые рандомы и ключевую пару. В ответ контроллеру отправляется сгенерированный публичный ключ и соль. (SRP Start Response)

• M3: контроллер отправляет запрос на проверку данных (SRP Verify Request). На данном шаге контроллер генерирует свою сессионную ключевую пару , спрашивает пользователя ввести пин-код, считает общий ключ SRP сессии и пруф (SRP proof). Аксессуару отправляется сгенерированный публичный ключ и пруф.

• M4: аксессуар проверяет пруф контроллера отправляет свой пруф в ответ (SRP Verify Response).

• M5: контроллер -> аксессуару (‘Exchange Requestʼ). Первым делом контроллер проверяет пруф аксессуара. После этого генерируется долгосрочная ключевая пара (LTPK и LTSK) на кривой ed25519. Контроллер формирует новый ключ (HKDF) из сессионного ключа, конкатенирует его с идентификатором контроллера(iOSDevicePairingID) и его публичным ключом (iOSDeviceLTPK), подписывает секретным LTSK. Идентификатор, публичный ключ и подпись записываются в TLV-сообщение, шифруются алгоритмом ChaCha20-Poly1305 с использованием общего сессионного ключа. Зашифрованное сообщение опять записывается в виде TLV-сообщения и отправляется аксессуару.

• M6: аксессуар -> контроллер (‘Exchange Responseʼ). Здесь же аксессуар извлекает информацию (iOSDeviceLTPK, iOSDevicePairingID), проверяет подпись. Далее, аналогично, подписывает и отправляет свой идентификатор, долгосрочный публичный ключ, подпись.

После успешного выполнения всех шагов M1-M6, контроллер и iOS устройство сохраняют идентификаторы и публичные ключи (LTPK) друг друга на долгий срок.

/pair-verify

Процедура используется каждый раз для установления защищенного соединения. Здесь же шагов уже меньше (M1-M4).

Каждый участник: и Контроллер, и Аксессуар генерируют Curve25519 ключевые пары, отправляют друг другу публичные ключи и вырабатывают симметричный общий ключ, из которого формируется сессионный ключ. Долгосрочные ключи (LTPK и LTSK) используются лишь для проверки подписей.

Защищенное соединение

После успешного завершения процедуры pair-verify соединение TCP остается открытым и все данные внутри него зашифрованы сессионным ключом. Получается, что Keep-Alive HTTP-соединение «обновляется» (аналогично вебсокетовскому Upgrade) и теперь для получения корректного HTTP данные необходимо прежде расшифровать.

Данные — точно так же HTTP запросы и ответы, но уже стандартный json.

Начало решения: выбор

Выбор остановился на Go и brutella/hap пакете. Модуль не содержит в себе реализации контроллера и планов на добавление нет, поэтому необходимо все будет сделать самому. Но это просто, учитывая то, что все криптографические процедуры реализованы для серверной части.

В пользу решения на Go говорило и то, что на нем можно писать графическую часть в том числе и для Android (fyne.io, gioui.org).

Модуль форкнут, удалено лишнего, добавлены файлы для части контроллера.

Реализация:

По реализации подробно расписывать не буду, только несколько моментов.

1. При обнаружении устройств контроллер по очереди для разных ip-адресов устройства пробует подключиться по TCP. После первой удачной попытки данные сохраняюся для последующего установления постоянного соединения.

2. Поскольку все запросы — это http, то можно использовать родную для Go реализацию http.Client. Возник вопрос как заставить его работать с обычным TCP-соединением? Для этого необходимо поддержать интерфейс RoundTripper:

func (c *conn) RoundTrip(req *http.Request) (*http.Response, error) {   err := req.Write(c)   if err != nil {     return nil, err   }   if c.inBackground {     res := <-c.response     return res, nil   }   rd := bufio.NewReader(c)   res, err := http.ReadResponse(rd, nil)   if err != nil {     return nil, err   }    return res, nil } 

После этого можем назначать http.Client и использовать его:

d.httpc = &http.Client{ Transport: c, }      // использовать: res, err := d.httpc.Get("/accessories")     ...

3. И самое интересное. Если посмотреть на код выше, то можно заметить условие на флаг inBackground. Ведь можно же было обойтись одним http.ReadResponse. И на этапе pair-setup и pair-verify это работает. Проблема возникает уже после установления безопасной сессии. Дело в том, что аксессуары могут отправлять уведомления об изменениях значений. И такие уведомления выглядят так:

EVENT/1.0 200 OK Content-Type: application/hap+json Content-Length: <length> {   ”characteristics” : [{     ”aid” : 1,     ”iid” : 4,     ”value” : 23.0   }] }

Что мы имеем? Во-первых, все данные надо читать в цикле, чтобы не пропустить уведомления. Во вторых, http.ReadResponse не может с ним справиться, поскольку EVENT — не стандартный для http заголовок.

С первым справится просто — запускаем горутину, считывающую данные:

func (c *conn) backgroundRead() { rd := bufio.NewReader(c)  for { b, err := rd.Peek(len(eventHeader)) // len of EVENT string if err != nil { fmt.Println(err) if errors.Is(err, io.EOF) { return } continue } if string(b) == eventHeader {       // обработка события       // трансформируем событие (заменяем EVENT на HTTP)       // читаем с res := http.ReadResponse()       // читаем all := io.ReadAll(res.Body)       // присваиваем res.Body = io.NopCloser(bytes.NewReader(all))       // вызываем колбэк     } else {       // обработка ответа       // читаем с res := http.ReadResponse()       // читаем all := io.ReadAll(res.Body)       // присваиваем res.Body = io.NopCloser(bytes.NewReader(all))     }   } }

Каждую итерацию проверяем заголовок на совпадение с EVENT и в таком случае — «трансформируем» — заменяем EVENT на HTTP для успешной обработки методом http.ReadResponse. Для замены пишем структуру с реализацией интерфейса io.Reader.

Следующая возникшая проблема: в некоторых случаях (длинный ответ) при итерации цикла возникала ошибка на неверный заголовок HTTP. Проблема в том, что ReadResponse возвращает ответ с полем Body, в котором данные не читаны, а значит не читаны они и в нашем соединении. Решение — прочитать полностью res.Body и только после этого можно переходить на следующую итерацию.

Графическое приложение

Для наброска графического приложение использовался модуль gioui.org. На функционал приложение на данный момент небогато — обнаружение устройств, аутентификация и установление соединения, управление аксессуарами реле и лампами (Вкл-Выкл).

Работа приложения проверялась в паре с homebridge.

PS: к сожалению, при запуске на Android, приложение не смогло обнаружить ни одно устройство.

avc: denied { bind } for scontext=u:r:untrusted_app:s0:c31,c257,c512,c768 tcontext=u:r:untrusted_app:s0:c31,c257,c512,c768 tclass=netlink_route_socket permissive=0 b/155595000 app=localhost.hkapp

Ссылки

1. github.com/hkontrol/hkontroller собственно, реализация контроллера

2. github.com/hkontrol/hkapp графический интерфейс

Заинтересованных в open-source разработке приглашаю принять участие.