Защита Интернета вещей от сетевого уровня до уровня приложения
Воутер ван дер Бик
Безопасность в Интернете вещей (IoT) стала критически важным требованием, поскольку недавний закон предписывает «разумные функции безопасности». Совершенно очевидно, что затраты на внедрение безопасности в IoT необходимы, и намного перевешивают затраты, связанные с невыполнением этого требования. .
Безопасность строится послойно; первый уровень, который необходимо защитить, - это аппаратный уровень, второй - сетевой уровень. В этой статье упомянутый сетевой уровень - это сетевой уровень потоков:недорогая, энергосберегающая, ячеистая сеть IoT.
Однако сеть представляет собой сочетание беспроводных и проводных IP-технологий, поэтому также существует потребность в безопасности на уровне приложений. Это происходит из уровня приложения OCF; безопасный домен, в котором все устройства и клиенты могут безопасно общаться друг с другом, - сказал Воутер ван дер Бик, старший архитектор Интернета вещей, Cisco Systems и председатель технической рабочей группы Open Connectivity Foundation и Бруно Джонсон, генеральный директор Cascoda , член Open Connectivity Foundation.
Аппаратная безопасность
Ограниченный микроконтроллер требует функций для защиты от вредоносного кода и аппаратного отслеживания, которые могут поставить под угрозу безопасность. Безопасное оборудование защищает последовательность загрузки микроконтроллера, проверяя его подпись, и защищает доступ к памяти и периферийным устройствам, чтобы изолировать важные части кода. Это разрешает доступ только через четко определенный и надежный интерфейс прикладного программирования (API). Эти функции минимизируют поверхность атаки подключенных устройств, обеспечивая безопасную основу для сети и приложений.
Сетевая безопасность
Сетевой уровень должен гарантировать, что данные, передаваемые по воздуху, не могут быть изменены, и что устройства, которые присоединяются к сети, являются легитимными. Для защиты данных по воздуху Thread использует общесетевой ключ, который использует криптографию с симметричным ключом, известную как AES-CCM. AES-CCM добавляет код тега к каждому сообщению и шифрует его с помощью этого общесетевого ключа. Если у получателя есть ключ, он может расшифровать, проверить источник и убедиться, что сообщение не было повреждено при передаче. Наконец, ключ периодически меняется на основе существующего ключа и определенного счетчика последовательности в случае его взлома.
Однако, когда новому устройству необходимо присоединиться к сети, оно не знает общесетевой ключ и, следовательно, должно его получить. Этот процесс известен как ввод в эксплуатацию. Конечно, ключ нельзя передать без шифрования, так как злоумышленник может его перехватить. Чтобы решить эту проблему, при вводе в эксплуатацию потока используется процесс, известный как обмен ключами с аутентификацией паролем (PAKE), который является частью стандарта безопасности транспортного уровня дейтаграмм (DTLS).
PAKE использует секрет с низкой степенью защиты в сочетании с асимметричной криптографией для генерации секрета высокой надежности между двумя сторонами. Высоконадежный секрет используется для шифрования передачи ключа от уполномоченного по потокам (например, смартфона, подключенного к сети потоков) к присоединяющемуся устройству.
Безопасность приложений
Чтобы обеспечить сквозную безопасность на уровне приложений, OCF предлагает решения для передачи права собственности от производителя к покупателю или от одного покупателя к другому. Первым шагом в интеграции является установление права собственности на устройство. Для этого OCF выдает сертификаты и ведет базу данных для каждого сертифицированного устройства. На этом этапе устройству предоставляются эти учетные данные для установления безопасных соединений с взаимной аутентификацией с другими устройствами в защищенном домене IoT благодаря инфраструктуре открытых ключей (PKI) OCF.
Затем инструкции по обеспечению передаются через безопасное соединение, зашифрованное с помощью DTLS. Процесс начинается с передачи права собственности на устройство, а затем инициализации устройства после набора переходов между состояниями. Следует отметить, что OCF учитывает, что в течение своего жизненного цикла устройство может сменить владельца. Следовательно, OCF требует, чтобы устройства реализовали аппаратный сброс, чтобы вернуться в состояние инициализации.
В дополнение к процессу подключения устройства OCF могут быть снабжены различными уровнями безопасности. OCF предлагает многоуровневый подход:управление доступом на основе ролей и описание использования производителем. Первый касается безопасности устройства, а второй добавляет дополнительный уровень защиты от сети.
Реализация с использованием ограниченного оборудования
Реализация OCF-over-Thread на оборудовании с ограничениями является проблемой из-за очень ограниченного пространства кода, памяти и вычислительной мощности недорогих микроконтроллеров. В результате необходимо воспользоваться преимуществами повторного использования кода. Наибольшая экономия кода достигается за счет совместного использования базовой криптографической библиотеки и mbedTLS, общих для обоих стеков. Это возможно, потому что OCF и Thread построены на DTLS.
Выполнение основных криптографических примитивов для DTLS требует доступа к выделенному оборудованию для ускорения, которое намного эффективнее по времени и энергоэффективности, чем чистое программное обеспечение. Такое аппаратное ускорение сокращает время ввода потока в эксплуатацию на несколько порядков - значительное увеличение скорости выполнения наиболее ресурсоемкой задачи, за которую отвечает микроконтроллер. Следовательно, управление доступом к функциям аппаратной криптографии для обоих стеков через библиотеку mbedTLS критически важно.
И OCF, и Thread Group запускают проекты с открытым исходным кодом для своих соответствующих спецификаций. Эти конкретные реализации устраняют двусмысленность для разработчиков и улучшают взаимодействие.
Технологии, которые могут работать вместе от приложения до сетевого уровня, образуют лучшую в своем классе безопасную платформу Интернета вещей, которую можно развернуть уже сегодня.
Авторы - Воутер ван дер Бик, старший архитектор Интернета вещей, председатель рабочей группы по системам и техническим вопросам Cisco, Open Connectivity Foundation, и Бруно Джонсон, генеральный директор Cascoda, член Open Connectivity Foundation.
Интернет вещей
- Распаковка IoT, серия:проблема безопасности и что вы можете с этим сделать
- Защита промышленного Интернета вещей:недостающий элемент головоломки
- Путь к промышленной безопасности Интернета вещей
- Защита промышленного Интернета вещей:руководство по выбору архитектуры
- Устранение уязвимостей безопасности промышленного Интернета вещей
- Защита Интернета вещей с помощью обмана
- Из рук в руки - зачем Интернету вещей нужен SD-WAN
- COVID-19:что кибербезопасность IoT в здравоохранении извлекла из первой волны
- Шесть шагов для защиты встроенных систем в IoT
- Безопасность раскрывает истинный потенциал Интернета вещей