В данной статье речь пойдет про Apple HomeKit Accessory Protocol (HAP): внутренности и разработку контроллера.
Apple HomeKit создан для взаимодействия контроллера (по умолчанию iOS-устройства, приложение Home) и множества устройств(аксессуаров). Протокол открыт для некоммерческого использования, загрузить его можно с сайта Apple. На основе этой версии протокола создано несколько open-source проектов, и когда говорят про HomeKit на каком-нибуль Raspberry Pi обычно подразумевают установку homebridge и плагинов для создания совместимых аксессуаров.
Обратная же задача - создание контроллера - не такая распространенная и из проектов мне удалось найти лишь pypi.org/project/homekit/.
Поставим задачу создать контроллер, например, для управления аксессуарами с Android-телефона и попробуем ее решить. Для простоты будем работать только с IP-сетями, без Bluetooth.
Как это должно работать?
Обнаружение устройства
Для того, чтобы начать работать с аксессуарами, их необходимо первым делом обнаружить. Устройства рекламируют себя в соответствии с протоколами Multicast DNS и DNS service discovery.
Говоря проще, можно в локальной сети обнаружить устройство, отправив multicast запрос _hap._tcp.local по адресу 224.0.0.251, и, получив ответ, распарсить DNS записи A, SRV, TXT. После этого можно подключаться к сервису, используя полученную информацию.
Установка защищенного соединения
Возможно два сценария: устройства уже связаны, либо связь (pairing) надо только установить. В первом случае нужно перемещаться к шагу /pair-verify, в случае же установления нового соединения, первым делом надо выполнить шаг /pair-setup.
Apple HomeKit использует протокол Stanfordʼs Secure Remote Password (SRP) с использованием пароля (пин-кода).
Работа с аксессуарами, характеристиками и их значениями.
/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).
Модуль форкнут, удалено лишнего, добавлены файлы для части контроллера.
Реализация:
По реализации подробно расписывать не буду, только несколько моментов.
При обнаружении устройств контроллер по очереди для разных ip-адресов устройства пробует подключиться по TCP. После первой удачной попытки данные сохраняюся для последующего установления постоянного соединения.
Поскольку все запросы - это 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")
...И самое интересное. Если посмотреть на код выше, то можно заметить условие на флаг 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Ссылки
github.com/hkontrol/hkontroller собственно, реализация контроллера
github.com/hkontrol/hkapp графический интерфейс
Заинтересованных в open-source разработке приглашаю принять участие.
