Безопасность приложений Интернета вещей

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

Пользователи лишены контроля над своими цифровыми жизнями

Сценарии из эпизода 1 демонстрируют, что пользователи часто не владеют достаточными средствами управления своей цифровой жизнью. Несмотря на то что сервисы и устройства Интернета вещей соединены сетью, их разнородность требует гибкой поддержки взаимодействия на стороне приложений, определяемого самим пользователем. Чтобы не изобретать новые протоколы и стандарты, в концепции Паутины вещей (Web of Things) [1] используются популярные стандарты для построения прикладного слоя приложений Интернета вещей. В мире автомобилей стандарты HTML5 и JavaScript обеспечивают взаимодействие через Web для встроенных информационно-развлекательных систем и систем доступа к данным автомобиля [2].

Интернет обеспечивает сетевой уровень связности, WWW — прикладной, а приложения Интернета вещей — главную нить для управления пользователями своими цифровыми жизнями. Для общности будем считать, что приложение Интернета вещей — это программное обеспечение, работающее от имени пользователя для реализации функций в соответствующем окружении.

Платформы Интернета вещей обеспечивают управление…

Приложения Интернета вещей помогают пользователям управлять их цифровыми жизнями, соединяя подключенные к Интернету разнообразные составляющие: киберфизические системы и устройства (системы умного дома, автомобиль, фитнес-браслеты), онлайн-сервисы (такие как Google и Dropbox), социальные сети (Facebook, Twitter и т. п.). Разберем два основных направления использования платформ приложений Интернета вещей: пользовательская автоматизация и встроенные автомобильные системы, которые помогут продемонстрировать как общность ряда проблем и их решений для всех приложений Интернета вещей, так и особенности (такие как угрозы подмены URL для приложений, использующих веб-технологии, в сравнении с рисками дорожной безопасности для автоприложений).

Сегодня популярны платформы пользовательской автоматизации — IFTTT (If This Then That), Zapier и Microsoft Flow. Например IFTTT поддерживает более 550 подключаемых к Интернету компонентов и сервисов, обслуживая 11 млн пользователей и 54 млн экземпляров приложений с миллиардом запусков ежемесячно [3]. В ядре всех платформ заложены так называемые реактивные принципы, использующие такие понятия, как триггеры, действия и программные фильтры для подстройки под индивидуальные запросы пользователя. Триггеры и действия устроены так, что разработчики конечных приложений могут передавать им различные параметры. Фильтры обрабатываются после срабатывания триггера и перед вызовом действия. Фильтры обеспечивают приложениям высокий уровень персонализации — это куски кода, обычно на JavaScript, имеющие API для взаимодействия с используемыми сервисами. Пользователи могут создавать приложения и публиковать их для других пользователей, таким образом, платформы развиваются. На рис. 1 представлена схема приложения пользовательской автоматизации, на ней показано, как триггеры работают в качестве источников информации, а действия — приемников.

Рис. 1. Приложения пользовательской автоматизации, соединяющие триггеры и действия

Современные автомобили оснащены медиасистемами, возможности которых с каждым годом расширяются: начав с базовых функций радио и навигации, они развились до многофункциональных центров, сравнимых по возможностям с планшетами и смартфонами. Недавно ряд автопроизводителей, включая Volvo, Renault, Nissan и Mitsubishi, объявили о возможности установки сторонних приложений в свои фирменные медиацентры. Это стало возможным благодаря использованию специальной версии операционной системы Android Automotive [4] — открытой платформы с возможностью публикации приложений для нее независимыми разработчиками. Как и приложения пользовательской автоматизации, автоприложения могут обладать широким спектром возможностей. В то же время эти приложения имеют доступ к весьма чувствительной информации, такой как текущее местоположение автомобиля, и могут повлиять на поведение автомобиля на дороге.

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

… и вооружили злоумышленников

К сожалению, мощь приложений Интернета вещей доступна и злоумышленникам. Хотя магазины приложений (например, Google Play) — двигатели инноваций и рынка, но они же предоставляют возможности для атак со стороны злонамеренных разработчиков. Недавняя утечка персональных данных более 50 млн пользователей Facebook через приложение от Cambridge Analytica — тревожное свидетельство реальности угроз со стороны приложений от независимых разработчиков. Приложения Интернета вещей на таких платформах, как IFTTT, имеют доступ к чувствительной пользовательской информации: к местоположению, параметрам физической нагрузки, содержимому личных файлов и к частной переписке в социальных сетях. И вся эта персональная информация может быть скомпрометирована небезопасными или написанными с ошибками приложениями.

На рис. 2 показан пользовательский интерфейс стороннего приложения пользовательской автоматизации, использующего триггер «Новая фотография» (по событию в iOS Photos), выполняющего при его включении действие «Загрузить файл на заданный URL» (через Google Drive) и фильтрующего код прозрачным для пользователя образом.

Рис. 2. Интерфейс приложения на платформе IFTTT

Как уже отмечалось, некоторые автопроизводители открывают доступ сторонним приложениям к медиасистемам своих автомобилей, а поскольку эти приложения обладают доступом к чувствительным ресурсам, таким как местоположение машины, они также могут оказаться в сфере интересов злонамеренных разработчиков. В прессе широко обсуждалась серия атак на медиацентры автомобилей Jeep, подключенных к Сети, — злоумышленники с удаленного ноутбука отправляли команды функциям приборной панели, системам рулевого управления, торможения, переключения передач, получив полный контроль над машиной. В 2015 году компания Chrysler отозвала 1,4 млн автомобилей с такой уязвимостью. Все это демонстрирует необходимость защиты приложений Интернета вещей.

Доступность критичной информации через Web посредством платформ Интернета вещей расширяет поверхность атаки, позволяя разного рода злоумышленникам воспользоваться потенциальными уязвимостями в различных компонентах экосистемы приложений Интернета вещей: окружении, физических устройствах, сервисах, сетях связи, облачных платформах, пользовательских интерфейсах. В таблице (первый столбец) приводятся категории злоумышленников в контексте приложений Интернета вещей, использующих веб-технологии.

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

Обход текущих механизмов безопасности

Платформы Интернета вещей имеют разнообразные средства контроля доступа и авторизации для управления доступом к чувствительным API. Например, IFTTT требует авторизации пользователя и каждого вызываемого по событиям сервиса, такого как iOS Photos или Google Drive. Для этого используется протокол авторизации OAuth 2.0b, который в момент установки приложения перенаправляет пользователя на страницу аутентификации на сайте провайдера соответствующего сервиса. Полученный от сервиса маркер доступа в дальнейшем используется при вызовах от любых приложений, вызывающих этот сервис. Для приложения на рис. 2 пользователь предоставляет приложению доступ к iOS Photos на его устройстве и учетной записи Google Drive. Такие разрешения достаточно грубы — они представляют доступ к большему объему пользовательской информации, чем это необходимо для выполнения соответствующих функций. Далее фильтрующий код выполняется в изолированном окружении (песочнице) с небольшим тайм-аутом. Песочница спроектирована таким образом, что предоставляет доступ только к API допущенных к взаимодействию сервисов; в противном случае песочница отказывает в выводе либо блокирует взаимодействие.

К сожалению, разработчики вредоносных приложений могут обойти механизмы контроля доступа песочницы, создав фильтрующий код. Платформы часто используют механизм URL-ссылок как «универсальный клей» для соединения различных сервисов. Например, iOS Photos и Google Drive предоставляют для загрузки контента API на базе URL. Для приложения резервирования фотографий (рис. 2) IFTTT загружает новую картинку на свой сервер, создает публично доступный случайный URL и передает его в Google Drive. URL используются приложениями и в других случаях, таких как подстановка логотипов в сообщения электронной почты.

В литературе описаны два класса URL-атак для скрытного выманивания приватной информации через приложения: атаки с URL для загрузки и с использованием URL-разметки [1]. В обоих случаях злоумышленник может закодировать частную информацию в параметрическую часть URL-строки со ссылкой на управляемый им сервер — например: https://злоумышленник.su/секрет.

В атаке с URL для загрузки злоумышленник использует возможность отправки данных по ссылке. В сценарии из рис. 2 IFTTT сохраняет новую фотографию на собственном сервере и отправляет ее на Google Drive с использованием промежуточного URL. Таким образом, злоумышленник может сформировать промежуточный URL со ссылкой на свой сервер посредством подстановки строк в JavaScript-коде фильтра. А чтобы остаться незамеченным, сайт злоумышленник.su так же, как и платформа, перенаправляет полученное изображение на Google Drive, резервируя фотографию, как и ожидает пользователь. Для такой атаки не требуется дополнительного взаимодействия с пользователем, поскольку функция выполняется на стороне Google Drive.

В атаках с использованием URL-разметки злоумышленник создает текст на HTML с невидимым изображением URL-ссылки с вложенными приватными данными, например местоположением пользователя. Этот текст может быть встроен в публикацию в социальной сети или размещен в теле сообщения электронной почты. Утечка происходит в момент запроса от браузера, обрабатывающего страницу, либо при открытии сообщения электронной почты.

Другие распространенные платформы пользовательской автоматизации — Zapier и Microsoft Flow — столь же уязвимы для выманивающих данные URL-атак [1], особенно опасных из-за их скрытной природы. Исследователи изучили около 300 тыс. приложений на платформе IFTTT от более 400 сервисов и обнаружили, что более 30% приложений могут потенциально содержать злонамеренный код.

Автоприложения также могут содержать такого рода уязвимости [2]. Архитектура безопасности Android Automotive во многом наследует модель разрешений стандартного варианта Android. Эта модель требует от приложений запрашивать разрешения на использование системных ресурсов, а для доступа к таким чувствительным ресурсам, как камера или приемник GPS, требуется, чтобы пользователь явно предоставил соответствующие права непосредственно перед тем, как приложение начнет работать с ними. В других случаях, например для доступа к Интернету или использования NFC, требуется предоставить разрешение в момент установки приложения. При этом зачастую пользователь не представляет последствий предоставления таких разрешений.

При помощи приложения SoundBlast из категории психоатак было показано, как можно шокировать водителя, увеличив в момент движения на высокой скорости громкость радиоприемника до максимума. Вредоносное приложение также может влиять на доступность сервисов — например, ForkBomb и IntentStorm нарушают штатную работу медиацентра, вплоть до его перезагрузки. Сходным образом вредоносные автоприложения могут извлекать чувствительную информацию — например, текущее местоположение и переговоры в салоне автомобиля.

Среди других угроз от автоприложений — получение данных от бортовых датчиков: скорость, температура и число оборотов двигателя. Несмотря на то что доступ к текущей скорости требует специального разрешения, запрос информации о числе оборотов двигателя не требует в Android Automotive особых разрешений. Таким образом, злоумышленник может просто вычислить скорость автомобиля, зная число оборотов в единицу времени и текущую передачу [2].

В работе [3] показано, что даже приложения Интернета вещей от добросовестных разработчиков могут порождать риски защищенности и безопасности, о которых пользователь не догадывался в момент установки приложения. Например приложение «Если появилась новая фотография, отправить ее на Flickr как общедоступное изображение» может обеспечить утечку в Сеть фото чека для домовладельца или фотографии любовницы. Более того, дополнительные риски несут и взаимодействующие приложения пользовательской автоматизации, установленные одним и тем же пользователям. Например, пользователь может установить два приложения: «Если я ушел из офиса, включить обогреватель дома» и «Если комнатная температура в доме превысила определенный порог, то открыть окна». Несмотря на то что такие приложения установлены для различных случаев, их взаимодействие может создать ситуацию открытия окон в доме без присмотра, создав тем самым лазейку для грабителей. Похожим образом в противоречивое взаимодействие могут вступить приложение, предупреждающее о задымлении («Если в помещении появился дым, включить сирену и открыть вентили системы пожаротушения»), и детектор утечек («При обнаружении утечки перекрыть воду») [4].

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

Предоставление разрешений, которые никогда больше не будут в будущем использоваться приложением, также увеличивает риск злонамеренных действий. Недавно различные платформы Интернета вещей начали поддерживать межплатформенное взаимодействие приложений для расширения функционала. Например, пока IFTTT не позволяет установить множественные триггеры в одном приложении, в платформе apilio.io была реализована возможность «смешения» нескольких IFTTT-приложений для реализации сложной логики. Кроме того, некоторые платформы позволяют взаимодействовать с приложениями другой платформы — таковы, например, IFTTT и Stringify. С точки зрения безопасности подобные совершенствования увеличивают поверхность атаки и открывают новые возможности для появления уязвимостей. Наконец, приложения все чаще полагаются на элементы искусственного интеллекта, а значит, растет потребность в анализе и противостоянии угрозам со стороны технологий машинного обучения.

Как защитить приложения Интернета вещей и платформы?

Возвращаем управление пользователю

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

Оперативные контрмеры

Полномочия в современных системах контроля доступа в приложениях Интернета вещей варьируются от уровня «все или ничего» до некоторого достаточно грубого, негранулярного уровня. Описанные атаки подчеркивают необходимость в гранулярном контроле доступа — это может быть достигнуто на уровне архитектуры безопасности, требующей от поставщиков сервисов предоставления более детального, гранулярного API для платформ Интернета вещей, использующего, возможно, сведения об уровне чувствительности данных. С другой стороны, платформы Интернета вещей могли бы усовершенствовать механизмы защиты за счет включения более тонкой системы контроля доступа — например, предоставляя безопасные выходные данные через API таким образом, чтобы существовала единственная возможность вложить ссылку или изображение в разметку для приемника через API-конструкторы, формируемые платформой.

Пользователи должны иметь право на «последнее слово» в определении политик безопасности, касающихся их персональных данных. В то же время механизмы безопасности имеют практический смысл лишь в том случае, если не обременяют пользователей дополнительными настройками, нотификациями, всплывающими уведомлениями и пр. К счастью, в большинстве случаев гранулярные полномочия могут быть автоматически выведены из контекста. Таким образом, общая схема может быть выстроена с минимальным отвлечением пользователя. Поставщики сервисов в любом случае должны регистрироваться на платформах Интернета вещей в качестве партнерского сервиса, следовательно, полномочия могут быть унаследованы от сервиса, используемого в данном приложении, либо подтверждены пользователем путем, сходным с динамической проверкой, применяемой в Android-приложениях. Иначе говоря, приложение на рис. 2 не потребует обязательных дополнительных взаимодействий с пользователем: событие («Новая фотография») может быть автоматически классифицировано как чувствительное. С другой стороны, такие триггеры как «Космонавт вышел в космос» могут автоматически классифицироваться как публичные.

Перспективные контрмеры

Платформы Интернета вещей — централизованные элементы, имеющие привилегированный доступ к чувствительным данным и устройствам миллиардов пользователей, что делает и платформы, и сервисы привлекательной целью для злоумышленников. Если они оказываются скомпрометированными, злоумышленники могут получать чувствительные пользовательские данные и произвольным образом манипулировать пользовательскими данными и устройствами. Децентрализация позволяет понизить требуемый уровень доверия к платформам Интернета вещей посредством взаимоконтроля взаимодействия между поставщиками сервисов с применением гранулярных маркеров авторизации (например, индивидуальных маркеров для приложений) либо с использованием понятия доверенных клиентских приложений (например, считая таковыми мобильные приложения).

Предложена также децентрализованная архитектура, обеспечивающая целостность действий приложений с незначительным влиянием на производительность. Однако защищенность персональных пользовательских данных на стороне платформ по-прежнему остается открытой проблемой. Одним из решений могло бы быть построение децентрализованной одноранговой («точка — точка») системы между всеми провайдерами сервисов, используемых приложениями пользовательской автоматизации в качестве триггеров или действий. Устранение облачной платформы повышает защищенность, но за это придется заплатить усложнением сервисов и взаимоотношений между их поставщиками. Другим решением может стать применение достижений в сфере гомоморфного шифрования: платформы Интернета вещей могли бы работать только с зашифрованными данными. Например, можно вычислять близость к заданному местоположению, не предоставляя текущие координаты, а просто сравнивая зашифрованные данные с использованием техник гомоморфного шифрования.

Многообещающим подходом для защиты в сторонних приложениях является отслеживание потоков информации от чувствительных источников к нечувствительным приемникам. Предложен фреймворк, в котором контроль за информационными потоками используется совместно с техникой песочниц. Для платформ пользовательской автоматизации на JavaScript предложено [1] применять современные средства отслеживания информационных потоков. Кроме того, техники анализа исходного кода способны выявлять взаимодействия между различными приложениями Интернета вещей, обнаруживая небезопасные вызовы между ними.

Прочие контрмеры

Защита приложений пользовательской автоматизации требует также и решений за пределами чисто технических мер. Приложение может на словах предлагать желаемую функцию — «Автоматически зарезервировать новые изображения в iOS Photos на Google Drive», но при этом реализовывать и нечто другое — «Разблокировать дверь». В результате, будучи обманутым, пользователь может установить приложение, не соответствующее его ожиданиям. Таким же образом и приложения от добросовестных поставщиков могут привести к непредвиденным последствиям, которые пользователь не мог себе представить в момент установки приложения. Следовательно, очень важно обращать внимание пользователя на риски безопасности и защищенности, возникающие при установке приложений. Современные техники, использующие обработку естественного языка для проверки соответствия текстовых описаний приложений фактическому API, — многообещающий подход, однако контекстно зависимая природа приложений пользовательской автоматизации все равно требует от конечного пользователя самостоятельно оценивать риски.

Автоприложения

Рис. 3. Традиционный магазин приложений и безопасный магазин приложений

На рис. 3 показана разница между архитектурами традиционного магазина приложений и его безопасного варианта. Традиционный позволяет приложениям действовать от имени пользователя, в результате чего возникают риски утечек из-за негибкости подсистем полномочий, управления API и управления информационными потоками. Безопасная версия приложения, предназначенного для установки в автомобиль, могла бы работать только с безопасными версиями сервисов определения местоположения — например, способными искать ближайшие точки интереса для пользователя без передачи сведений о местоположении его машины неавторизованным получателям.

В итоге можно было бы достичь мира и покоя в цифровой жизни Анны.

Перспективы

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

Несмотря на то что недавние разработки создали значительный инновационный и деловой потенциал, они же и открыли простор для крупномасштабных атак со стороны недобросовестных создателей приложений. Утечка персональных данных через приложение Cambridge Analytica продемонстрировала, что эти угрозы вполне реальны. Пользователи самостоятельно устанавливали Facebook-приложение от Cambridge Analytica, но подобным же образом пользователь может захотеть установить приложение Интернета вещей, например, сигнализирующее о выбросах углекислого газа и одновременно неявно собирающее информацию о местоположении пользователя. Такие утечки могут обеспечить атаки и на сам сервис. Например, API от Uber для платформы IFTTT предоставляет не только сведения о местоположении начала и окончания поездок, но и имя водителя, телефонный номер, фото и номер водительского удостоверения. Это позволяет незаметно «отпрофилировать» компанию Uber, построив детальную базу данных ее водителей и автомобилей. Подобные сценарии требуют принципиально нового подхода к обеспечению безопасности приложений Интернета вещей — сегодня имеется ряд направлений совершенствования безопасности приложений.

Гранулярный контроль доступа. Регулирование уровня безопасности для чувствительных ресурсов требуется для создания полностью взаимоуправляемых механизмов в противовес пробросу запросов, используемому, например, в атаках по вытягиванию ресурсов. Гранулярный контроль доступа соединяет системы полномочий как уровня пользователя и приложений, так и уровня управления API.

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

Управление API. Для функций, выполняемых приложениями, необходимо управление API, способствующее регулированию необходимой степени безопасности. Управление работает до уровня моделей полномочий, принудительно ограничивая доступные параметры API — например, допустимый уровень громкости колонок медиацентра в автомобиле или возможность делиться местоположением только при определенных условиях.

Механизмы отслеживания информации. Для учета фактов использования приложением чувствительной информации необходимо сохранять следы его работы. Благодаря этому возможно, например, выявить утечки на основе подстановок в URL. Такие механизмы могут применяться как в среде выполнения, так и в момент развертывания приложения.

Архитектуры безопасности для магазинов приложений. Необходимо внедрить технологии анализа кода для автоматического выявления подозрительных приложений еще до того, как они станут доступными для установки из магазина.

***

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

Литература

1. I. Bastys, M. Balliu, A. Sabelfeld. If this then what? Controlling flows in IoT apps. In Proc. 2018 ACM SIGSAC Conf. Computer and Communications Security (CCS), 2018. — P. 1102–1119. doi: 10.1145/3243734.3243841.

2. B. Eriksson, J. Groth, A. Sabelfeld. On the road with third ­party apps: Security analysis of an in­vehicle app platform. In Proc. 5th Int. Conf. Vehicle Technology and Intelligent Transport Systems (VEHITS), 2019. — P. 64–75.

3. M. Surbatovich, J. Aljuraidan, L. Bauer, A. Das, L. Jia. Some recipes can do more than spoil your appetite: Analyzing the security and privacy risks of IFTTT recipes. In Proc. 26th Int. Conf. World Wide Web, 2017. — P. 1501–1510. doi: 10.1145/3038912.3052709.

4. Z. B. Celik, P. D. McDaniel, G. Tan. Soteria: Automated IoT safety and security analysis. In Proc. USENIX ATC, 2018. — P. 147–158.

Мусард Баллью (musard@kth.se) — доцент Школы электротехники и информатики Королевского технологического института, Юлия Бастис (bastys@chalmers.se) — аспирант факультета информатики и инженерии, Андрей Сабельфельд (andrei@chalmers.se) — профессор факультета информатики и инженерии, Технический университет Чалмерса (Швеция).

Musard Balliu, Iulia Bastys, Andrei Sabelfeld, Securing IoT Apps. IEEE Security & Privacy, September/October 2019. IEEE Computer Society. All rights reserved. Reprinted with permission.