СИСТЕМА И РЕАЛИЗУЕМЫЙ КОМПЬЮТЕРОМ СПОСОБ МЕЖМАШИННОЙ АУТЕНТИФИКАЦИИ УСТРОЙСТВА Российский патент 2022 года по МПК H04L29/00 

ОБЛАСТЬ ТЕХНИКИ

[001] Настоящее изобретение относится к области обеспечения безопасности связи. В частности, оно относится к межмашинной (machine-to-machine, М2М) аутентификации с использованием механизма усовершенствованной многофакторной аутентификации (МФА).

УРОВЕНЬ ТЕХНИКИ

[002] Аутентификация представляет собой процесс определения того, является ли кто-то или что-то, собственно, тем или чем он или оно представляется. Как правило, аутентификация была сосредоточена на взаимодействиях между человеком и машиной таким образом, что машина автоматически проверяет достоверность идентифицированного пользователя. С недавних пор аутентификация также предназначена для межмашинных сред (например, онлайн-служб резервного копирования, датчиков телемедицины и интеллектуальных сетей). Для этого применяют несколько технологий.

[003] Технологии аутентификации на основе сертификата обеспечивают шифрование с использованием открытого и закрытого ключа шифрования, который является уникальным. Эти маркеры также могут быть использованы в качестве цифровой сигнатуры транзакций. Как правило, сертификационная организация (СА) несет ответственность за выдачу и проверку цифровых сертификатов в составе инфраструктуры открытого ключа.

[004] Также существуют технологии, основанные на контекстной аутентификации, которые используют контекстную информацию, например положение GPS, для определения того, является ли идентичность системы подлинной или нет. Однако контекстная аутентификация сама по себе недостаточна и обычно используется в дополнение к более надежным аутентификационным технологиям.

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

[006] Кроме того, существуют аутентификационные инструменты, которые не подходят для межмашинной среды, поскольку они ориентированы на человека (например, ответ на вызов, биометрическая аутентификация или связь по вспомогательному каналу).

[007] Цифровые сертификаты во многих случаях оказываются недостаточными для аутентификации. Например, они бесполезны для беспилотных воздушных систем (unmanned aerial system, UAS), поскольку платформа может нести много рабочих полезных нагрузок, а цифровые сертификаты не гарантируют безопасного использования дополнительных полезных нагрузок.

[008] Технологии многофакторной аутентификации (МФА) основаны на одноразовых паролях, которые используют секрет или порождающий полином, общий для группы лиц и хранящийся на бортовом устройстве аутентификации и на оконечном устройстве аутентификации. Этот метод обеспечивает аутентификацию посредством выработки разового кода доступа, основанного на секрете маркера.

[009] Таким образом, многие из имеющихся в настоящее время технологий проверки подлинности не полностью применимы к М2М-средам. Как правило, необходимо разобраться с тремя вопросами: "что вы знаете, что вы имеете, и кто вы". Поскольку современные технологии основаны на участии человека и предполагают, что объект, подвергаемый аутентификации, является человеком, или что человек участвует в процедурах аутентификации, им свойственны различные ограничения. В частности, неспособность дать правильный ответ на вопрос "кто вы" или, в этом случае, "что представляет собой устройство".

РАСКРЫТИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

[0010] Анализ предшествующего уровня техники показывает, что существует потребность в системе и способе многофакторной (МФА) межмашинной (М2М) аутентификации.

[0011] Переход к М2М-сценарию требует глубоких изменений в существующих методах аутентификации. В соответствии с идеями этого раскрытия предлагается новая модель, стратегически расширяющая биометрическую концепцию, то есть измерение и анализ уникальных физических или поведенческих характеристик, для целей проверки идентичности, с тем чтобы обеспечить взаимодействие между машинами. Это новая концепция может быть названа "машинометрической".

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

[0013] Помимо этой цели объект настоящего изобретения относится к способам управления дополнениями сторонних производителей (сторонними подсистемами) в устройстве и относится к снижению вероятности аутентификации устройства с помощью скомпрометированного компонента.

[0014] Еще один объект обеспечивает создание механизма для лучшего выявления любых нарушений безопасности в надежных системах или выявления скомпрометированных компонентов.

[0015] Еще один объект раскрытия настоящего изобретения относится к методам, которые обеспечивают целостность операций без отрицательного влияния на автономность. Под автономностью в раскрытии настоящего изобретения понимается способность действовать независимо от человеческого управления.

[0016] Раскрытые методы значительно повышают безопасность и устраняют необходимость вмешательства человека, что подходит для большинства систем, не ориентированных на человека. В частности, в беспилотной воздушной системе могут быть выгодно использованы идеи, раскрытые в этом документе, для обеспечения целостности миссий. Кроме того, раскрытие настоящего изобретения также позволяет усовершенствовать беспилотные морские системы, объекты, собирающие и обменивающиеся данными в рамках Интернета вещей, промышленные роботы с элементами автономии, автономные программные агенты, такие как определенные инструменты для фондовой биржи и другие системы, требующие высокого уровня автономии.

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

[0019] На ФИГ. 1 схематично показан пример системы согласно примеру.

[0020] На ФИГ. 2А схематично показано устройство с несколькими критическими компонентами.

[0021] На ФИГ. 2В схематично показано устройство по ФИГ. 2А с неавторизованным компонентом.

[0022] На ФИГ. 3А схематично показана сеть зависимостей, выбранных компонентов беспилотной воздушной системы.

[0023] На ФИГ. 3В показана схема соседних зависимостей двух компонентов по ФИГ. 3А.

[0024] На ФИГ. 4 показана возможная классификация сигнатур различных типов.

[0025] На ФИГ. 5 схематично показана область положительной аутентификации в трехмерном пространстве сигнатур.

[0026] На ФИГ. 6 схематично показан процесс автономной аутентификации устройства.

[0027] На ФИГ. 7 схематично показан подпроцесс многофакторной аутентификации компонента устройства по ФИГ. 6.

[0028] На ФИГ. 8 схематично показана архитектура передачи данных для осуществления аутентификации компонентов.

[0029] На ФИГ. 9 схематично показана примерная архитектура для осуществления аутентификации выбранных компонентов беспилотного летательного аппарата.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

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

[0031] В частности, предложенные способы аутентификации применимы ко всем категориям пилотируемых и беспилотных транспортных средств, промышленным роботам с элементами автономии, автономным программным агентам, таким как отдельные инструменты для фондовой биржи, и Интернету вещей в целом. Однако предложенное решение будет объяснено прежде всего для применения с беспилотными воздушными системами (unmanned aerial system, UAS), поскольку они служат примерами для объяснения различных операций в сложных сценариях с частыми необходимыми обновлениями.

[0032] На ФИГ. 1 приведена структурная схема системы 100, выполненной с возможностью проведения многофакторной М2М-аутентификации в отношении критического компонента 102 устройства 110 и, таким образом, всего устройства. Хорошо известные конструкции и устройства на ФИГ. 1 показаны в блочной форме, чтобы избежать излишнего затруднения отображения раскрытия настоящего изобретения. В базе конфигурационных данных 140 хранится выборка критических компонентов. База данных 140 показана отдельно, однако она может быть частью системы 100. В альтернативном варианте реализации база данных 140 может быть частью самого устройства 110. Схожим образом, система 100 может иметь определенные блоки, установленные в устройстве 110.

[0033] Может быть желательно, чтобы перед выполнением функции или задачи устройством 110, выполнялись определенные условия. Эти условия в основном относятся к аутентификации критических компонентов, таких как компонент 102 устройства 110, участвующих в выполнении такой функции. Аутентификация, обеспечиваемая системой 100, служит для этой цели.

[0034] Устройство 110 проходит аутентификацию, когда достоверно аутентифицировано определенное число критических компонентов 102. Таким образом, аутентификация может быть установлена на двух разных уровнях. На верхнем уровне для аутентификации каждого критического компонента 102, рассматривают один или более вспомогательных компонентов 104, имеющих связь с критическим компонентом 102. Сеть зависимостей может таким образом быть определена согласно отношениям между различными компонентами 102, 104. На нижнем уровне каждый компонент может потребовать k-факторной аутентификации. То есть k различных сигнатур указанного компонента должны быть проверены на достоверность.

[0035] На ФИГ. 1 показано, что устройство 110 получает команду на выполнение функции, затрагивающей первый компонент 102. Для обеспечения реализации этой функции необходима М2М-аутентификация. Сначала блок 120 извлечения системы 100 посылает запрос на аутентификацию в устройство 110 в отношении первого компонента 102. Кроме того, блок 120 извлечения также извлекает список зависимостей, хранящийся в базе конфигурационных данных 140. Список зависимостей содержит аутентификационную информацию первого компонента 102 и одного или более дополнительных компонентов 104, связанных с первым компонентом 102. Аутентификационная информация в списке зависимостей включает в себя сохраненные значения физических сигнатур и цифровых сигнатур компонентов 104, 102.

[0036] Приемный блок 160 в системе 100 принимает текущие сигнатуры для первого компонента 102 и для каждого зависимого компонента 104, присутствующего в списке зависимостей. Физические сигнатуры могут быть приняты посредством датчиков. В частности, если устройство 110 включает в себя систему комплексного контроля технического состояния транспортного средства (Integrated Vehicle Health Management, IVHM), отвечающее за мониторинг и определение момента наступления отказа, система 100 может предпочтительно использовать инструменты и средства системы комплексного контроля технического состояния транспортного средства для приема текущих сигнатур. В частности, датчики системы комплексного контроля технического состояния транспортного средства, такие как датчик температуры, датчик вибрации, электрические датчики, могут измерять текущие физические характеристики. Текущие сигнатуры могут нуждаться в преобразовании в соответствующий формат, с тем чтобы текущую сигнатуру можно было потом сравнить блоком 180 проверки системы 100 с соответствующей сохраненной сигнатурой для каждого компонента. Если в результате сравнения выявлено, что сигнатуры являются достоверными, блок 180 проверки производит аутентификацию первого компонента 102. Сравнение может быть успешным, даже если сигнатуры не являются идентичными, но находятся в пределах ожидаемого диапазона, как будет описано далее. Когда достоверно аутентифицированы все критические компоненты 102, само устройство 110 также считается аутентифицированным.

[0037] Описанная выше ситуация показывает случай аутентификации, который был инициирован событием задействования определенной функции устройства 110. Тем не менее, также предполагается, что аутентификация может быть произведена на основе временного интервала, с тем чтобы постоянно удостоверяться в целостности устройства 110.

[0038] На ФИГ. 2А схематично показано устройство 200, состоящее из четырех компонентов, обозначенных S1, S2, S3 и S4. Далее рассматривается неавторизованный компонент S5, добавленный в устройство 200, как показано на ФИГ. 2В. Вследствие этого один или более компонентов S1-S4 могут быть скомпрометированы, как и само устройство 200. Указанное может привести к сбою, перехвату управления или другим неожиданным или вредоносным действиям.

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

[0040] Например, если устройство 200 представляет собой беспилотный летательный аппарат (БПЛА), и управление критическим компонентом перехвачено, беспилотный летательный аппарат может быть принужден совершить посадку на неавторизованной базе, вместо своей базы.

[0041] Для того, чтобы иметь дело с этими проблемами, связанными с безопасностью, предлагается несколько альтернативных мер. Во-первых, необходимо выделить критические компоненты, как было упомянуто в связи с ФИГ. 1. Такими критическими компонентами могут быть компоненты, компрометация которых может вызывать общий отказ. Следовательно, желательны их непрерывные мониторинг и аутентификация. Это означает соответствующий обмен информацией между взаимозависимыми компонентами в алгоритме аутентификации, например, платформой и бортовыми камерами.

[0042] Говоря в целом, начальные процессы обеспечения безопасности включают в себя следующие выполняемые последовательно подзадачи: идентификация, аутентификация и авторизация. В случае рассматриваемой беспилотной воздушной системы авторизация является частью системы управления полетом (Mission Management System, MMS) и полностью зависит от правильности предшествующих идентификации и аутентификации. Таким образом, технология, предложенная в настоящем документе, прежде всего сосредоточена на усовершенствовании двух предшествующих подзадач: идентификации и аутентификации. Эти подзадачи в настоящее время очень часто включают вмешательство человека. Вместо этого раскрытие настоящего изобретения предлагает межмашинный (machine-to-machine, М2М) подход, который исключает какую-либо необходимость участия человека. С этой целью ниже более подробно описаны последовательные идентификация/аутентификация беспилотной воздушной системы.

[0043] Целостность беспилотной воздушной системы, решающей конкретную задачу, зависит от успешной идентификации и аутентификации беспилотного летательного аппарата, данные которой выдаются в блок выдачи команд и управления (Command and Control, С2). Блок С2 должен иметь исключительный доступ к беспилотным летательным аппаратам, в том числе критическим компонентам, таким как бортовая рабочая полезная нагрузка и подсистемы (камеры, датчики, приводы, антенны, линии передачи данных и т.д.) и управление этими беспилотными летательными аппаратами. Полная целостность критических компонентов беспилотного летательного аппарата является условием безопасного, полноправного и успешного выполнения задачи. Полноправность определена в раскрытии настоящего изобретения как полное и независимое управление устройством.

[0044] На ФИГ. 3А показана примерная сеть зависимостей для аутентификации. Первый узел указывает на второй узел, а стрелки обозначают зависимость от компонента. Один компонент считается достоверным, когда все узлы в пути зависимости прошли проверку на достоверность. Соответственно, подтверждение достоверности в этой сети должно проводиться в определенном порядке для полного осуществления аутентификации. В этом отношении на ФИГ. 3В показана схема компонентов, изображающих первые соседние зависимости двух приведенных в качестве примера узлов в сети.

[0045] Более подробно, ФИГ. 3А относится к беспилотной воздушной системе с питанием от батарей, которая включает в себя бортовой компьютер 310, отправляющий сигналы в контроллер 312, который регулирует подачу питания в силовую установку.

Команды и наземной станции (не показано) отправляют на бортовой компьютер 310 из приемника 302. Бортовой компьютер 310 получает питание от основной батареи 308, размещенной в предохранительной емкости 306 (для уменьшения влияния возможного перегрева батареи и ухода параметров при изменении температуры). Бортовой компьютер 310 также управляет охлаждающим вентилятором 304, используемым для регулирования температуры ответчика 314 системы опознавания "свой-чужой" и основной батареи 308.

[0046] В этом конкретном случае для аутентификации контроллера 312 и ответчика 314 системы опознавания "свой-чужой", минимальные требования (извлекаемые из списка зависимостей с использованием базы конфигурационных данных) предназначены для аутентификации бортового компьютера 310 и охлаждающего вентилятора 304, соответственно. Бортовой компьютер 310 легко адаптируется к идентификации на основе цифровых сигнатур. Охлаждающий вентилятор 304 может быть аутентифицирован с использованием его физических характеристик, например скорости вращения вентилятора и результирующей сигнатуры вибраций. Поэтому необходим подходящий датчик для измерения его текущей физической сигнатуры. Поскольку беспилотный летательный аппарат обычно включает в себя множество бортовых датчиков, они могут быть использованы для получения необходимых физических сигнатур.

[0047] Следующая последовательность иерархических отношений для аутентификации представлена на ФИГ. 3А и 3В:

- аутентификация бортового компьютера 310 зависит от аутентификации приемника 302 и основной батареи 308;

- контроллер 312 аутентификации зависит от аутентификации бортового компьютера 310;

[0048] Нет необходимости говорить, что сеть зависимостей для аутентификации может быть расширена по мере необходимости. Например, цепочки аутентификации может быть расширена до других компонентов в пути зависимости. Например, отношение аутентификации для контроллера 312 может включать в себя не только бортовой компьютер 310, но и приемник 302. Схожим образом, могут быть включены дополнительные пути для связывания ответчика 314 системы опознавания "свой-чужой" с бортовым компьютером 310 и приемником 302. Помимо рассматриваемого сценария для беспилотной воздушной системы эта модель зависимостей также может быть применена для других различных примеров.

[0049] На ФИГ. 4 схематично показано несколько цифровых и физических сигнатур, которые могут оказаться эффективными при аутентификации либо самого устройства, либо только одного определенного компонента. В любом случае каждый компонент устройства, проходящего аутентификацию, должен иметь одну или более сигнатур, которые могут быть либо физическими 408, либо цифровыми 404, либо и физическими, и цифровыми. Цифровые сигнатуры 404 могут представлять собой идентификатор процесса, смарт-картой 404 или радиочастотную метку 406. Физические сигнатуры 408 относятся к характеристикам, которые однозначно идентифицируют указанный компонент, например, вычислительная 410, аэродинамическая 412, электрическая 414, механическая 416, такая как: сигнатура механических вибраций, объем, форма, альбедо, схема потребления энергии, электрическая сигнатура, магнитная сигнатура, радиочастотная сигнатура или любая их комбинация. Эти сигнатуры могут нуждаться в преобразовании в единый формат и сохранении в бортовой базе конфигурационных данных.

[0050] Обработка с аутентификацией на основе цифровых сигнатур является простой, и специализированный алгоритм может допускать определенные отклонения от сохраненных значений сигнатуры или не учитывать их, чтобы учитывать возможные погрешности измерения физических данных или сбои передач. Например, отсутствие одного цифрового подтверждения достоверности может считаться приемлемыми. Ослабление строгости условий зависит от обстоятельств. Ниже приведены некоторые случаи.

[0051] При проверке достоверности физической сигнатуры всегда существуют некоторые отклонения. Предложенное решение может нуждаться в приеме определенного диапазона ожидаемых точных значений для учета неизбежных изменений физической среды, например изменения температуры, изменений граничных условий (на земле или в полете) и т.д. Если существует k возможных независимых параметров достоверности для аутентификации компонента устройства, эти параметры достоверности определяют "машинометрическое" пространство сигнатур. Эта концепция показана на ФИГ. 5.

[0052] На ФИГ. 5 графически показано трехмерное пространство 500, образованное следующими физическими сигнатурами для данного беспилотного летательного аппарата: первой собственной частотой f (Гц) выбранной подсистемы, временной задержкой t1 при нарастании тока после подачи входной команды на ступенчатое изменение тяги и временной задержкой t2 положения фюзеляжа по тангажу после подачи входной команды на руль высоты.

[0053] Для повышения надежности, как описано выше, для ожидаемых значений сигнатур задают достоверные доверительные интервалы. Если значения находятся в пределах конкретных диапазонов, сигнатура может быть признана достоверной. Например, как показано параллелепипедом 502 по ФИГ. 5: 2,0 Гц<f(Гц)<4,5 Гц, 0,1 с<t1<0,6 с и 0,5 с<t2<0,7 с. Таким образом, беспилотный летательный аппарат успешно аутентифицирован, если полученные параметры находятся в пределах этих диапазонов.

[0054] На ФИГ. 6 показана упрощенная блок-схема нескольких операций, выполняемых для аутентификации устройства согласно примеру. Блок-схема включает этап 602 извлечения из базы конфигурационных данных 604 для получения набора n критических компонентов устройства, которые должны быть аутентифицированы. Затем на этапе 606 построения строят список зависимостей для указанных n критических компонентов. После подготовки списка зависимостей и раз запускают цикл и выполняют этап 610 выбора для извлечения элемента из списка зависимостей. Этот элемент обрабатывают и верифицируют в соответствии с многофакторным процессом согласно процессу 612 многофакторной аутентификации. Многофакторную аутентификацию выполняют циклично по всем измерениям "машинометрического" пространства сигнатур (факторов). Процесс многофакторной аутентификации 612 для каждого отдельного компонента показан на ФИГ. 7. Каждый раз, когда результат этапа 614 проверки для данного элемента является положительным, компонент считается аутентифицированным. Как только этап 608 проверки показывает, что список зависимостей пуст, аутентификация устройства считается пройденной. Следует отметить, что аутентификация считается не пройденной, когда первый критический компонент считается "не аутентифицированным".

[0055] На ФИГ. 7 показана еще одна упрощенная блок-схема аутентификации 612 на нижнем уровне. Им является внутренний цикл в пределах процесса, показанного на ФИГ. 6. Компонент считается прошедшим k-факторную аутентификацию, когда каждая из k сигнатур, связанных с данным критическим компонентом, прошла проверку на достоверность. Компонент, имеющий k сигнатур, должен пройти этап 702 проверки на достоверность k раз. Каждый раз, когда сигнатура оказывается достоверной, производят обработку следующей до тех пор, пока проверка 704 не покажет отсутствие сигнатур, связанных с этим компонентом (или в альтернативном варианте реализации получен результат "не аутентифицирован"). Таким образом, аутентификация 706 компонента является положительной при условии прохождения всех k сигнатур проверки на достоверность. Этот процесс аутентификации на уровне компонентов должен быть выполнен для одного компонента либо периодически, либо асинхронно (например, всякий раз при добавлении нового компонента).

[0056] Если устройство является беспилотным летательным аппаратом 300, добавление нового компонента требует обновления базы конфигурационных данных 604. Указанное может быть выполнено посредством обработки автоматически или по запросу непосредственно блоком выдачи команд и управления (Command and Control, С2). Потеря аутентификации одного или более критических компонентов приводит к общей потере аутентификации. Это событие может автоматически инициировать заданные условные действия по обеспечению безопасности. Эти действия могут включать обмен информацией с блоком С2, запуск процесса повторной аутентификации, возвращение на свою базу, прекращение выполнения полетных задач, разрушение беспилотного летательного аппарата 300 и т.д. То, как следует поступать с устройством после неудачной аутентификации, находится вне пределов объема раскрытия настоящего изобретения.

[0057] На ФИГ. 8 показана архитектура передачи данных для реализации настоящего изобретения в беспилотном летательном аппарате 300. Одной из ключевых частей этой архитектуры является модуль 810 аутентификации. Этот модуль 810 аутентификации выполняет мониторинг физических изменений и соотносит их с любым изменением идентичности, поскольку она связана с базой полетных данных 806. Модуль 810 аутентификации исполняет задачи идентификации и аутентификации каждого критического компонента. Эта архитектура соответствует структурной схеме по ФИГ. 1. Модуль 810 аутентификации является возможной программной (SW) реализацией для беспилотного летательного аппарата блока 120 извлечения и блока 180 проверки. База полетных данных 806 также хранит аутентификационную информацию компонентов беспилотного летательного аппарата, как базу конфигурационных данных 140.

[0058] Каждый компонент беспилотного летательного аппарата, считающийся критическим, проходит индивидуальную аутентификацию, при этом менее критичным компонентам может потребоваться только простая аутентификации на основе сертификата, а те, которые считаются существенными, могут требовать многофакторной аутентификации, как раскрыто выше. Модуль 810 аутентификации отвечает за оценку состояния аутентификации. В зависимости от ситуации он может либо подтвердить, либо отклонить положительную аутентификацию или отправить соответствующую рекомендацию в блок С2.

[0059] Большинство беспилотных летательных аппаратов оборудованы цифровой шиной 818 для обеспечения возможности обмена данными между различными компонентами (например, авиационным электронным оборудованием и датчиками). Защищенный обмен данными через цифровую шину 818 требует применения всех трех этапов процесса обеспечения безопасности обработки (идентификации, аутентификации, авторизации), обеспечиваемой модулем 810 аутентификации. Данные, отправленные через эту цифровую шину 818, могут подвергаться непрерывному мониторингу модулем 810 аутентификации для выявления и аутентификации любого нового компонента, соединяемого с шиной 818. Требования безопасности означают, что идентичность проверяется каждый раз, когда беспилотный летательный аппарат отправляет/получает данные через шину 818 (аналогично меткам в стандарте ARINC 429 и виртуальным линиям связи в спецификации ARINC 664 часть 7).

[0060] В некоторых случаях для связи между двумя оконечными пунктами требуются некоторые другие модули для посредничества или завершения связи. Модули можно рассматривать как один компонент или группу компонентов, то есть подсистему, элементы которой аутентифицируются вместе. Одним из преимуществ настоящей архитектуры является возможность аутентификации данных из уже позитивно идентифицированных источников. Как показано на ФИГ. 8, модуль А 802 записывает данные в шину 818, а модуль В 804 считывает эти данные вместе с полетными данными из базы полетных данных 806, которые успешно прошли процесс идентификации и аутентификации. Агенты 812, 816, 814 аутентификации предпочтительно представляют собой программные приложения, вырабатываемые автоматически и распределяемые модулем 810 аутентификации для управления основными задачами аутентификации и посредничества между цифровой шиной 818 и рассматриваемым модулем. Агенты 812, 816, 814 аутентификации выполняют служебную роль. Роль агентов 812, 814, 816 аутентификации описана ниже. Агенты аутентификации проверяют целостность модуля, пропускают аутентификационную информацию в модуль аутентификации и управляют вводом/выводом соответствующего модуля.

[0061] Архитектура по ФИГ. 8 позволяет вставить динамическую авторизацию между слоем данных (шиной 818) и уровнем приложения (модулем А 802, модулем В 804 и источниками данных, такими как база полетных данных 806 и данных миссии). Если один из модулей не идентифицирован или не аутентифицирован (или даже не авторизован), соответствующий агент 812, 816, 814 уведомляет модуль 810 аутентификации, который может отключить не идентифицированный модуль от шины 818 или снизить уровень доверия, следуя уже определенной модели доверия в зависимости от уровня важности функциональных возможностей такого модуля. Определенная пользователем доверительная модель необходима для взаимодействия защищенных агентов.

[0062] Уровень доверия, состояние идентификации или аутентификации для каждого компонента беспилотного летательного аппарата 300 может быть запрошен из таблицы-посредника, построенной на основании базы полетных данных 806. Эта таблица-посредник содержит обновленное состояние аутентификации всех компонентов. Ее данные являются общедоступными и доступны для всех агентов 812, 816, 814 аутентификации. Если модуль 810 аутентификации решает отклонить аутентификацию для модуля, состояние этого модуля в таблице-посреднике обновляется, и соответствующий агент действует соответствующим образом. Каждый агент 812, 816, 814 аутентификации производит считывание таблицы-посредника перед действием отклонения/приема рассматриваемых данных в шину 818. Следует отметить, что многие конкретные варианты реализации могут различаться в зависимости от требований к архитектуре или ресурсам. Например, агент аутентификации может только проверять целостность модуля и информировать модуль аутентификации о результатах или провести проверку и предпринять какие-либо действия, решение по которым будет принято в модуле аутентификации.

[0063] На ФИГ. 9 показан еще один пример системы 100 для беспилотной воздушной системы, которая включает в себя беспилотный летательный аппарат 924 и наземную станцию 922 управления. Цифровые и физические сигнатуры, используемые для аутентификации конкретных компонентов, показаны пунктирными линиями с использованием наклонного шрифта. Алгоритм аутентификации системы 100 показан жирными пунктирными линиями. В этом конкретном примере система 100 является частью главного бортового компьютера беспилотного летательного аппарата 924. Многофакторная аутентификация показана буквой С в кружке.

[0064] Аутентификацию двигателя 904 выполняют с использованием физических сигнатур, в частности электрических сигнатур (сопротивления (R) и тока (I)), а также температуры (Т) для данного режима полета. Аутентификацию бортового компьютера 920 выполняют с использованием физической и цифровой сигнатуры, (компьютерная цифровая идентификация и электрическое напряжение компьютера). Для двигателя 904 и других компонентов также могут быть использованы любые соответствующие характеристики программного обеспечения для многофакторной аутентификации.

[0065] Беспилотный летательный аппарат 924 принимает входные команды на выполнение задания от наземной станции 922 управления. Бортовой компьютер 920 обрабатывает входные команды на выполнение задания, выполняет задачи в зависимости от этих входных команд (например, управления камерой или конкретные навигационные задачи) и исполняет задачи независимо от входных команд от наземной станции управления, таких как обнаружение и уход от препятствий.

[0066] Предположим, что для определенной миссии аутентификация беспилотного летательного аппарата 924 потребует аутентификации двигателя 904 в качестве одного из критических компонентов. Соответствующий процесс аутентификации может представлять собой типичный процесс на основе раскрытого "машинометрического" подхода. Аутентификация двигателя 904 требует не только аутентификации его физических сигнатур посредством проверки, находятся ли они в ожидаемых диапазонах для электрического сопротивления R, диапазона тока I и диапазона температуры Т, но также зависит от положительной аутентификации соседних компонентов: блока 916 управления двигателем и воздушного винта 902. Агент аутентификации программного обеспечения сравнивает цифровую сигнатуру блока 916 управления двигателем с аутентификационной информацией, сохраненной в таблице-посреднике. Это может быть, например, информация, относящаяся к синхронизации последовательности подачи энергии на обмотку статора. Затем информацию об успешной/не успешной аутентификации относительно блока 916 управления двигателем передают в модуль 918 аутентификации. Следует отметить, что процедура аутентификации блока 916 управления двигателем может быть дополнительно расширена с помощью, например, проверки его тепловой сигнатуры. Схожим образом, информацию об акустической сигнатуре воздушного винта, соответствующую входной мощности, согласованной с сигнатурой контроллера 916, передают в модуль 918 аутентификации. Только если все этапы аутентификации пройдены, модуль 918 аутентификации считает двигатель 904 аутентифицированным. Если нет, модуль 918 аутентификации действует соответственно. Например, он может выдавать команду агенту аутентификации на изменение работы блока 916 управления двигателем, так что происходит уменьшение подачи питания на двигатель, и беспилотный летательный аппарат 924 принуждают к посадке. Схожим образом, путь зависимости камеры 906 включает в себя систему сервоприводов, в том числе сервопривод 910 панорамирования и сервопривод 910 качания, и бортовой компьютер 920. Как компьютер, так и камера нуждаются в аутентификации с использованием технологии многофакторной аутентификации.

Кроме того, раскрытие изобретения содержит примеры согласно следующим пунктам:

Пункт 1. Способ межмашинной аутентификации, включающий этапы:

i) идентификации по меньшей мере одного критического компонента (102) устройства (110) по запросу на аутентификацию устройства (110);

ii) извлечения аутентификационной информации для критического компонента (102), содержащей множество ожидаемых физических и цифровых сигнатур для критического компонента (102) и по меньшей мере одного дополнительного компонента (104), связанного с критическим компонентом (102);

iii) приема текущих сигнатур для критического компонента (102) и указанного по меньшей мере одного дополнительного компонента (104) и

iv) для каждого компонента (102, 104), проверки достоверности каждой текущей сигнатуры с помощью соответствующей ожидаемой сигнатуры и аутентификации устройства (110), если сигнатуры для каждого компонента (102, 104) являются достоверными.

Пункт 2. Способ аутентификации по пункту 1, согласно которому аутентификационная информация для критического компонента (102) содержит список зависимостей с последовательностью дополнительных компонентов (104), связанных с критическим компонентом (102) и подлежащих последовательной проверке.

Пункт 3. Способ аутентификации по пункту 1 или 2, согласно которому идентификация критического компонента (102) зависит от функции, которую устройство (110) должно выполнить.

Пункт 4. Способ аутентификации по любому из пунктов 1-3, согласно которому возникновение события в устройстве (110) инициирует запрос на аутентификацию.

Пункт 5. Способ аутентификации по любому из пунктов 1-4, согласно которому запрос на аутентификацию устройства (110) инициируют периодически.

Пункт 6. Способ аутентификации по любому из пунктов 1-5, согласно которому физические сигнатуры компонентов (102, 104) принимают исходя из измерений датчиков устройства (110).

Пункт 7. Способ аутентификации по любому из пунктов 1-6, согласно которому одну или более сигнатур компонентов (102, 104) принимают посредством связи с системой комплексного контроля технического состояния транспортного средства, выполняющей мониторинг указанного устройства (110).

Пункт 8. Способ аутентификации по любому из пунктов 1-7, согласно которому физические сигнатуры компонентов (102, 104) преобразуют в цифровой формат, подлежащий сохранению и проверке.

Пункт 9. Способ аутентификации по любому из пунктов 1-8, согласно которому текущая сигнатура является достоверной, когда она находится в заданном диапазоне соответствующей ожидаемой сигнатуры.

Пункт 10. Система межмашинной аутентификации устройства (110), содержащая:

i) блок (120) извлечения, выполненный с возможностью идентификации по меньшей мере одного критического компонента (102) устройства (110) по запросу на аутентификацию устройства (110), а также выполненный с возможностью извлечения аутентификационной информации для критического компонента (102), содержащей множество ожидаемых физических и цифровых сигнатур для критического компонента (102) и по меньшей мере одного дополнительного компонента (104), связанного с ними;

ii) приемный блок (160), выполненный с возможностью приема текущих сигнатур для критического компонента (102) и указанного по меньшей мере одного дополнительного компонента (104); и

iii) для каждого компонента (102, 104), блок (180) проверки, выполненный с возможностью проверки достоверности каждой текущей сигнатуры с помощью соответствующей ожидаемой сигнатурой, а также выполненный с возможностью аутентификации устройства (110), если сигнатуры для каждого компонента (102, 104) являются достоверными.

Пункт 11. Система по пункту 10, также содержащая базу конфигурационных данных (140) для хранения ожидаемых сигнатур компонентов (102, 104) устройства (110).

Пункт 12. Система по пункту 10 или 11, также содержащая датчики для измерения физических сигнатур компонентов (102, 104) устройства (110).

Пункт 13. Система по любому из пунктов 10 или 11, в которой приемный блок (160) выполнен с возможностью приема физических сигнатур компонентов (102, 104) от датчиков устройства (110).

Пункт 14. Система по любому из пунктов 10 или 11, в которой приемный блок (160) выполнен с возможностью связи с системой комплексного контроля технического состояния транспортного средства, выполняющей мониторинг указанного устройства (110), для приема физических или цифровых сигнатур.

Пункт 15. Компьютерный программный продукт для межмашинной аутентификации устройства, содержащий инструкции компьютерного кода, которые при исполнении процессором побуждают процессор выполнить способ по любому из пунктов 1-9.

Эти и другие раскрытые признаки, функции и преимущества могут быть получены независимо в различных примерах или могут быть скомбинированы в других примерах.

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

1. Способ межмашинной аутентификации, включающий этапы:

i) идентификации по меньшей мере одного критического компонента (102) устройства (110) по запросу на аутентификацию устройства (110);

ii) извлечения аутентификационной информации для критического компонента (102), содержащей множество ожидаемых физических и цифровых сигнатур для критического компонента (102) и по меньшей мере одного дополнительного компонента (104), связанного с критическим компонентом (102);

iii) приема текущих сигнатур для критического компонента (102) и указанного по меньшей мере одного дополнительного компонента (104) и

iv) для каждого компонента (102, 104), проверки достоверности каждой текущей сигнатуры с помощью соответствующей ожидаемой сигнатуры и аутентификации устройства (110), если сигнатуры для каждого компонента (102, 104) являются достоверными.

2. Способ аутентификации по п. 1, в которой аутентификационная информация для критического компонента (102) содержит список зависимостей с последовательностью дополнительных компонентов (104), связанных с критическим компонентом (102) и подлежащих последовательной проверке.

3. Способ аутентификации по п. 1 или 2, согласно которому идентификация критического компонента (102) зависит от функции, которую устройство (110) должно выполнить.

4. Способ аутентификации по п. 1 или 2, согласно которому возникновение события в устройстве (110) инициирует запрос на аутентификацию.

5. Способ аутентификации по п. 1 или 2, согласно которому запрос на аутентификацию устройства (110) инициируют периодически.

6. Способ аутентификации по п. 1 или 2, согласно которому физические сигнатуры компонентов (102, 104) принимают исходя из измерений датчиков устройства (110).

7. Способ аутентификации по п. 1 или 2, согласно которому одну или более сигнатур компонентов (102, 104) принимают посредством связи с системой комплексного контроля технического состояния транспортного средства, выполняющей мониторинг указанного устройства (110).

8. Способ аутентификации по п. 1 или 2, согласно которому физические сигнатуры компонентов (102, 104) преобразуют в цифровой формат, подлежащий сохранению и проверке.

9. Способ аутентификации по п. 1 или 2, согласно которому текущая сигнатура является достоверной, когда она находится в заданном диапазоне соответствующей ожидаемой сигнатуры.

10. Система межмашинной аутентификации устройства (110), содержащая:

i) блок (120) извлечения, выполненный с возможностью идентификации по меньшей мере одного критического компонента (102) устройства (110) по запросу на аутентификацию устройства (110), а также выполненный с возможностью извлечения аутентификационной информации для критического компонента (102), содержащей множество ожидаемых физических и цифровых сигнатур для критического компонента (102) и по меньшей мере одного дополнительного компонента (104), связанного с ними;

ii) приемный блок (160), выполненный с возможностью приема текущих сигнатур для критического компонента (102) и указанного по меньшей мере одного дополнительного компонента (104); и

iii) для каждого компонента (102, 104), блок (180) проверки, выполненный с возможностью проверки достоверности каждой текущей сигнатуры с помощью соответствующей ожидаемой сигнатуры, а также выполненный с возможностью аутентификации устройства (110), если сигнатуры для каждого компонента (102, 104) являются достоверными.

11. Система по п. 10, также содержащая базу конфигурационных данных (140) для хранения ожидаемых сигнатур компонентов (102, 104) устройства (110).

12. Система по п. 10 или 11, также содержащая датчики для измерения физических сигнатур компонентов (102, 104) устройства (110).

13. Система по п. 10 или 11, в которой приемный блок (160) выполнен с возможностью приема физических сигнатур компонентов (102, 104) от датчиков устройства (110).

14. Система по п. 10 или 11, в которой приемный блок (160) выполнен с возможностью связи с системой комплексного контроля технического состояния транспортного средства, выполняющей мониторинг указанного устройства (110), для приема физических или цифровых сигнатур.