Система и способ обеспечения межпроцессного взаимодействия в электронных блоках управления транспортными средствами Российский патент 2021 года по МПК B60K37/00 G06F15/16 G06F21/53 

Область техники

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

Уровень техники

В настоящее время вместе с развитием технологий бурно развивается автомобильная промышленность. В автомобили внедряются новые системы, позволяющие сделать управление автомобилем более комфортным. Обычно эти системы основаны на компьютерных технологиях. Различными системами автомобиля управляют блоки управления, которые в свою очередь выполняют различные алгоритмы. Так, например, для соблюдения норм экологических стандартов ЕВРО (ЕВРО-4, ЕВРО-5) автопроизводителям приходится оптимизировать не только двигатели, но и системы управления этими двигателями для обеспечения более экологичного выхлопа при неухудшении мощностных характеристик. Для более адаптивного хода оптимизируются системы управления коробками передач, которые адаптируются под стиль вождения, дорожные условия, погодные условия, переключая передачи более плавно или резче, подключая задние или передние колеса и изменяя момент передачи усилия между осями колес. Повсеместно внедряются более сложные системы, так называемые системы помощи водителю (англ. advanced driver-assistance systems, ADAS), например, система автоматизированной парковки (по датчикам, регистрирующим расстояние от автомобиля до препятствия), система-ассистент при движении (например, распознавание по камере положения автомобиля в полосе и в общем на дороге) система автоматизированного экстренного торможения (например, при обнаружении препятствия с помощью инфракрасных датчиков). Кроме того, набирают популярность электромобили, которые управляются при движении компьютерными системами, размещенными на борту автомобиля (описано в публикации <<https://www.google.com/selfdrivingcar/>>). С развитием информационных технологий также все более актуально встает вопрос о беспилотных транспортных средствах (как легковых, так и грузовых).

Существуют классические стандарты платформ, на которых функционируют блоки управления. Блоки управления критическими узлами транспортного средства (например, рулевой или тормозной системой) реализованы по стандартам, к которым предъявляются повышенные требования к безопасности. Кроме того, такие блоки управления критическими узлами транспортного средства обычно работают на одноядерном процессоре с ограниченными ресурсами (например, зачастую реализованы с использованием специализированных микроконтроллеров с невысокой производительностью центрального процессора и малым объемом памяти). С другой стороны, мультимедийные системы не имеют повышенных требований к безопасности, так как их функционал (воспроизведение медиафайлов или отображение геопозиции на карте) не воздействует напрямую на безопасность людей, находящихся в транспортном средстве. Упомянутые системы помощи водителю, которые развиваются в настоящее время, представляют собой «прослойку» между мультимедиа и безопасными блоками. К системам помощи водителю, предъявляются повышенные требования безопасности. В некоторых блоках управления используются системы реального времени, что в свою очередь ограничивает и алгоритмы, которые могут быть выполнены блоками.

В настоящее время консорциумом Autosar разрабатывается новый стандарт, описывающий программную платформу для современных высокопроизводительных электронных блоков управления (ЭБУ) применяемых в автомобилях - Autosar Adaptive Platform (далее - ΑΑΡ). Среди ключевых особенностей этого стандарта выделяются требования к обеспечению информационной безопасности построенных на его базе систем.

Так, способ модульной реализации стандарта ΑΑΡ и способ обмена данными между интерфейсами, предоставляемыми модулями (приложениями), описываются в публикации DE 102018202446.

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

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

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

Сущность изобретения

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

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

Согласно другому частному варианту реализации предлагается система, в которой операционная система является безопасной операционной системой

Согласно еще одному частному варианту реализации предлагается система, в которой безопасной операционной системой является KasperskyOS.

Согласно еще одному частному варианту реализации предлагается система, в которой блок управления является блоком управления транспортным средством.

Согласно еще одному частному варианту реализации предлагается система, в которой взаимодействие является межпроцессным взаимодействием.

Согласно еще одному частному варианту реализации предлагается система, в которой приложение управления является базовым компонентом платформы, определенном в спецификации Autosar Adaptive Platform.

Согласно еще одному частному варианту реализации предлагается система, в которой средство безопасности операционной системы является единственной точкой вычисления вердиктов о предоставлении доступа.

Согласно еще одному частному варианту реализации предлагается система, в которой вердикт вычисляется в соответствии с политиками безопасности, которые определены на этапе компиляции.

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

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

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

Согласно еще одному частному варианту реализации предлагается способ, в котором операционная система является безопасной операционной системой.

Согласно еще одному частному варианту реализации предлагается способ, в котором безопасной операционной системой является KasperskyOS.

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

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

Согласно еще одному частному варианту реализации предлагается способ, в котором приложение управления является базовым компонентом платформы, определенном в спецификации Autosar Adaptive Platform.

Согласно еще одному частному варианту реализации предлагается способ, в котором средство безопасности операционной системы является единственной точкой вычисления вердиктов о предоставлении доступа.

Согласно еще одному частному варианту реализации предлагается способ, в котором вердикт вычисляется в соответствии с политиками безопасности, которые определены на этапе компиляции.

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

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

Краткое описание чертежей

Дополнительные цели, признаки и преимущества настоящего изобретения будут очевидными из прочтения последующего описания осуществления изобретения со ссылкой на прилагаемые чертежи, на которых: Фиг. 1 изображает структуру системы стандарта Autosar Adaptive Platform.

Фиг. 1.1 изображает вариант схемы предоставления доступа согласно спецификации стандарта Autosar Adaptive Platform.

Фиг.1.2 изображает вариант схемы предоставления доступа согласно спецификации стандарта Autosar Adaptive Platform с использованием медиаторов.

Фиг. 2 отображает систему обеспечения межпроцессного взаимодействия в электронном блоке управления.

Фиг. 2.1 отображает архитектуру FLASK.

Фиг. 2.2 отображает межпроцессное взаимодействие в безопасной операционной системе KasperskyOS.

Фиг. 3 изображает схему способа обеспечения межпроцессного взаимодействия в электронном блоке управления.

Фиг. 4 представляет пример компьютерной системы общего назначения, которая позволяет реализовать настоящее изобретение.

Описание вариантов осуществления изобретения

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

Фиг. 1 изображает структуру системы стандарта Autosar Adaptive Platform.

В общем случае система в стандарте ΑΑΡ функционирует в блоке управления (англ. electrical control unit, ECU) транспортным средством 100. Функциональность системы в стандарте ΑΑΡ определяется набором из базовых компонентов 110. Базовый компонент - это программный элемент платформы (реализованный, например, в виде приложения, системного приложения или сервиса), определенный в спецификации ΑΑΡ, необходимый для ее полноценной работы, в том числе для работы приложений, работающих под ее управлением. Приложение 120 реализует некоторый необходимый для управления транспортным средством функционал в рамках стандарта ΑΑΡ. Приложение 120 включает исполняемый код приложения в бинарном виде и спецификацию (манифест), описывающую основные свойства приложения, заданную на языке ARXML (на базе языка XML). Спецификация включает по меньшей мере:

- ресурсы, требуемые приложению 120 (например, объем памяти, привязку к определенным ядрам процессора ECU);

- состояния системы, в которых данное приложение 120 должно работать (например, при выключенном двигателе не работают приложения 120 систем помощи водителю);

- интерфейсы, которые предоставляет приложение 120 другим приложениям 120.

Спецификация (манифест) приложения 120 позволяет получать доступ к сервисам других приложений 120, абстрагируюсь от конкретной реализации межпроцессного взаимодействия (англ. Inter-Process Communication, IPC) между приложениями 120.

Приложение 120 может обращаться (взаимодействовать) к любому из базовых компонентов 110 стандарта ΑΑΡ и, используя предоставляемые интерфейсами базовых компонентов 110 сервисы, реализовывать свою функциональность. Кроме того, приложение 120 может обращаться к другим приложениям 120 через предоставляемые ими интерфейсы. В общем случае не имеет значения, на каком электронном блоке управления 100 находится приложение 120, стандарт ΑΑΡ предлагает механизмы, которые позволяют прозрачно для приложений 120 связываться с другими приложениями 120, размещенными на других блоках управления 100.

Примеры базовых компонентов 110 приведены ниже.

Компонент исполнения приложений (англ. execution management). В зависимости от состояния системы упомянутый базовый компонент 110 запускает или останавливает определенные приложения 120, основываясь на текущем состоянии системы. Например, если автомобиль на парковке с выключенным двигателем - это одно состояние, и система предоставляет доступ одному набору приложений, если автомобиль в движении - это другое состояние, и система предоставляет доступ другому набору приложений (включающих, возможно, приложения и из первого набора).

Компонент контроля взаимодействий (англ. communication manager). С помощью компонента контроля взаимодействий производится регистрация сервисов, предоставляемых приложениями 120, выполняется обнаружение этих сервисов, и обеспечивается информационное взаимодействие с этими сервисами.

Компонент контроля работоспособности платформы (англ. platform health manager). Данный компонент позволяет определить контрольные точки в системе и контролировать корректность хода работы компонентов 110 и приложений 120.

Компонент синхронизации времени (англ. time synchronization manager), обеспечивает единое время на всех системах транспортного средства, так как приложения 120 исполняются на разных блоках управления 100 внутри транспортного средства.

Компонент управления доступом (англ. Identity and Access Manager, далее по тексту - IAM) 110', который выявляет и хранит все допустимые взаимодействия приложений 120. Например, есть приложение «А» и приложение «Б», которое предоставляет некоторый сервис приложению «А», при этом интерфейс сервиса приложения «Б» содержит набор методов, описанных в манифесте приложения «Б». В IAM 110' имеется возможность задать, к каким методам сервиса приложения «Б» у приложения «А» есть доступ. Такая же схема используется для того, чтобы определить, какие приложения 120 могут получать доступ к базовым компонентам платформы. IAM 110' анализирует манифест приложений 120 и выдает разрешения на осуществление того или иного взаимодействия.

Совокупность упомянутых базовых компонентов 110 дает возможность создавать приложения для платформ, работающих по стандарту ΑΑΡ.

В спецификации ΑΑΡ предполагается, что в системе могут быть заданы компоненты, отвечающие за принятие решений безопасности (англ. Policy Decision Points, PDP) и компоненты, отвечающие за исполнение этих решений (англ. Policy Enforcement Points, PEP). При этом детали, определяющие функциональность этих компонентов, не приводятся, более того, указывается, что эти детали могут быть определены в каждой реализации ΑΑΡ индивидуально, включая, например, возможность реализации PDP и PEP в виде дополнительных приложений 120 - медиаторов (пример реализации приведен на Фиг. 1.2).

Варианты схем предоставления доступа согласно спецификации стандарта Autosar Adaptive Platform изображен на Фиг. 1.1. и Фиг. 1.2, для большей наглядности запросы разрешений на взаимодействия отмечены пунктирными линиями, сами взаимодействия - сплошными линиями.

Как было упомянуто выше, в стандарте ΑΑΡ приложение 120 или компонент 110, которым необходимо разрешение на взаимодействие, обращаются к ΙΑΜ 110' и получают разрешения от ΙΑΜ 110'. На Фиг. 1.1 отображен пример, приложение «А» для взаимодействия с приложением «Б» и для взаимодействия с базовым компонентом запрашивает разрешения на взаимодействие у IAM 110'.

В другом примере реализации стандарта ΑΑΡ точка принятия решений может находиться внутри ΙΑΜ 110' или быть реализована в некотором приложении 120' (Фиг. 1.2), которое работает совместно с IAM 110', а если требуются комплексные политики безопасности - то даже в нескольких приложениях 120'. Стоит отметить, что в данном случае реализации межпроцессное взаимодействие также реализуется через приложение 120'.

Приведенные подходы имеют значительное количество недостатков, включая:

- отсутствие совместимости между различными реализациями ΑΑΡ;

- сложности с заданием требуемых политик безопасности и контроля их свойств, таких как полнота покрытия, непротиворечивость, время вычисления решения о разрешении на взаимодействие и других;

- неконтролируемое увеличение доверенной кодовой базы системы, построенной на базе стандарта ΑΑΡ (доверенная кодовая база более подробно рассмотрена при описании Фиг. 2).

Для устранения упомянутых недостатков предлагается реализация компонента IAM 110', которая подробно описана при рассмотрении Фиг. 2.

Фиг. 2 отображает систему обеспечения межпроцессного взаимодействия в электронном блоке управления транспортным средством.

В стандарте ΑΑΡ выделяются требования к обеспечению информационной безопасности построенных на базе указанного стандарта систем и платформ. Однако данный стандарт предъявляет лишь высокоуровневые требования к подсистеме безопасности и вопросы реализации этой подсистемы в стандарт не включаются. Настоящее изобретение описывает вариант реализации.

В тексте стандарта ΑΑΡ рассматриваются различные подходы к реализации, например, возможен вариант с использованием нескольких точек PDP и PEP, а сами эти точки PDP и PEP могут быть реализованы, как упомянуто выше, в виде дополнительных приложений 120, работающих под управлением платформы, основанной на стандарте ΑΑΡ. Использование этого подхода не позволяет (или во всяком случае существенно затрудняет) создание подсистемы безопасности с заданными свойствами, такими как полнота описания политик безопасности, их взаимная непротиворечивость, обеспечение доверия к коду PDP и PEP, задание комплексных политик безопасности, а также не позволяет реализовать свойства безопасности, уже описанные в стандарте ΑΑΡ для его базовых компонентов 110.

Доверенная кодовая база системы, построенной на базе стандарта ΑΑΡ, включает набор компонентов, обеспечивающих безопасность системы, таким образом, что компрометация или неправильная работа таких компонентов (хотя бы одного из них) приводит к нарушению свойств безопасности системы в целом. Доверенная кодовая база системы (англ. Trusted Code Base) - это совокупность всего кода информационной системы (в настоящем примере реализации - системе стандарта ΑΑΡ), нарушение работы (ошибки, уязвимости) в котором может повлиять на цели безопасности. Целями безопасности в свою очередь являются требования, относящиеся к безопасности информационной системы, выполняемые при любых возможных условиях работы информационной системы.

Примерами требований, требования, относящихся к безопасности информационной системы, являются:

- конфиденциальность,

- целостность,

- доступность,

- другие.

Таким образом, код как PDP, так и PEP включается в доверенную кодовую базу системы, построенной на базе стандарта ΑΑΡ. Однако в случае, когда требуется задать свойства безопасности сложной системы, построенной на базе стандарта ΑΑΡ, сложно гарантировать корректную работу PDP и PEP, если не принимаются дополнительные меры.

В качестве примера таких мер можно рассмотреть формальную верификацию (например, верификацию формальными математическими способами) реализации PDP и PEP либо генерацию кода PDP и PEP на основании правил, позволяющих гарантировать их правильную работу.

Изначально, как было упомянуто выше, в стандарте ΑΑΡ предусматривается упомянутый компонент управления доступом IAM 110', который является точкой контроля процессов взаимодействия, происходящих в системе по стандартам ΑΑΡ. В рамках настоящего изобретения предлагается, сохранив программный интерфейс компонента IAM 110', изменить его функциональность следующим образом.

А именно, предлагается программная платформа ΑΑΡ на базе безопасной операционной системы (англ. secure operating system). Примером безопасной операционной системы является KasperskyOS 200.

Безопасная ОС в общем случае гарантирует функциональную и информационную безопасность. Гарантии функциональной безопасности включают меры защиты от проблем, возникающих вследствие комбинаций случайных факторов, воздействующих на ОС и имеющих случайный характер. Например, с точки зрения функциональной безопасности (англ. safety) с некоторой вероятностью может сложиться ситуация, при которой произойдет сбой в ОС. Целью обеспечения функциональной безопасности является доведение вероятного сбоя до требуемого уровня (например, не более 10^-7 в сутки). Гарантии информационной безопасности (англ. security), включают меры защиты от проблем, вызванных целенаправленными воздействиями на ОС (например, атаками). Например, с точки зрения информационной безопасности, если известна уязвимость ОС, то вероятность успешной атаки равна 1. Цель обеспечения информационной безопасности (отсутствие уязвимостей) - основная цель безопасной ОС.

Ключевые свойства KasperskyOS 200 позволяют реализовать подсистему безопасности для ΑΑΡ, соответствующую архитектуре MILS (англ. Multiple Independent Levels of Security), основанной на разделении системы на изолированные доверенные и недоверенные компоненты и контроле взаимодействий между ними, и архитектуре FLASK (англ. Flux Advanced Security Kernel), основанной на разделении системы безопасности на две части PDP и PEP. Пример архитектуры FLASK приведен на Фиг. 2.1. В случае, если клиент 201 запрашивает доступ к объекту, менеджер объектов 202 запрашивает вердикт у сервера безопасности 203, и, основываясь на решении (вердикте) сервера безопасности, предоставляет доступ клиента к объекту.

Особенностью безопасной операционной системы KasperskyOS 200 является возможность контроля межпроцессных взаимодействий в системе, причем с одновременным использованием набора формализованных моделей безопасности, что позволяет задавать для взаимодействий максимально детальные политики безопасности. Данная функциональность обеспечивается отдельной подсистемой KasperskyOS 200, которая называется Kaspersky Security System (далее - KSS) 220.

Стоит отметить, что механизмы межпроцессного взаимодействия, реализованные в KasperskyOS 200, описаны в патенте US9201712 (System and method for selecting a synchronous or asynchronous interprocess communication mechanism), а подсистема KSS 220 - в патенте US9774568 (Computer security architecture and related computing method).

Единственным возможным механизмом взаимодействия между программными компонентами, работающими под управлением KasperskyOS, является IPC, предоставляемый ядром (микроядром) 210 операционной системы 200. Упомянутый механизм взаимодействия предоставлен на Фиг 2.2. В процессе проведения IPC между приложениями 120 ядро 210 запрашивает у KSS 220 вердикт-разрешение на проведение IPC (вердикт о предоставлении доступа для взаимодействия). KSS 220 имеет доступ к данным, передаваемым в процессе IPC и проводит анализ этих данных в соответствии с заданными политиками безопасности (которые в общем случае определены на этапе компиляции и не могут быть изменены), после чего вычисляется вердикт о предоставлении доступа для взаимодействия, используя формализованные модели безопасности. Вычисленный вердикт используется ядром 210 проведения межпроцессного взаимодействия.

Формализованными моделями безопасности являются:

- мандатный контроль доступа (модель Белла-Лападулы);

- мандатный контроль целостности (модель Биба);

- модель ролевого управления доступом;

- модели безпасности на базе конечных автоматов;

- модели безопасности на базе различных диалектов темпоральных логик;

- другие.

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

В качестве примера, можно рассмотреть процедуру предоставления доступа к сервису приложения «Б» 120 из приложения «А» 120. Изначально после загрузки системы все взаимодействия между приложениями «А» и «Б» запрещены. Это означает, что при попытке совершить такое взаимодействие ядро 210 запросит у KSS 220 разрешение на осуществление такого взаимодействия и получит ответ, что такое взаимодействие невозможно, после чего попытка осуществить это взаимодействие будет заблокирована.

Однако, если в манифесте приложения «А» 120 содержится указание о возможности взаимодействия с сервисом приложения «Б» 120, IAM 110', получив этот манифест, проводит его анализ с целью определения целостности и аутентичности этого манифеста и получает из него сведения, описывающие допустимые взаимодействия. Затем компонент IAM 110', обладающий исключительным правом модификации параметров конфигурации безопасности решения, через интерфейс безопасности KSS 220 задает параметр конфигурации безопасности, указывающий на возможность проведения взаимодействия. После этого при попытке осуществления доступа к сервису приложения «Б» 120 из приложения «А» 120 KSS 220 вынесет положительный вердикт, и взаимодействие может быть проведено.

Рассмотрим пример простой политики безопасности, позволяющей реализовать поведение, описанное выше.

Пускай приложение «А» 120 имеет идентификатор ID A, который может быть определен независимо от приложения средствами ядра 210 ОС.

Аналогично приложение «Б» 120 имеет идентификатор IDB. В качестве идентификатора может выступать, например, ID процесса, ассоциированного с данным приложением. Кроме этого приложение «Б» 120 имеет набор сервисов (например, интерфейсных методов), каждый из которых имеет свой идентификатор, причем значения этих идентификаторов задаются в манифесте приложения «Б» 120. Пускай в манифесте приложения «А» 120 содержится указание о возможности получения доступа к сервису приложения «Б» 120, имеющего идентификатор ID SERVICE_B_1.

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

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

IAM 110' имеет доступ к интерфейсу безопасности KSS 220 и может через этот интерфейс добавлять новые триплеты в список.

При анализе манифеста приложений IAM 110' обнаруживает разрешенные взаимодействия, получает соответствующие им идентификаторы и с использованием интерфейса безопасности добавляет их в список политики безопасности KSS 220. При этом другие взаимодействия по-прежнему запрещены.

Таким образом обеспечиваются нижеперечисленные свойства.

1. Контроль обеспечивается в точке, через которую осуществляются все взаимодействия в системе - в ядре 210 ОС, что исключает возможность осуществления взаимодействия, не прошедшего проверку.

2. В системе присутствует единственная точка принятия решения (PDP), работающая с использованием формальных моделей безопасности, что позволяет гарантировать полноту и непротиворечивость политик безопасности, выполнять вычисление вердиктов на предоставление доступа для взаимодействия за предсказуемое время, использовать формальные механизмы для оценки качества этой модели безопасности (например, время принятия решений). В упомянутой архитектуре MILS рекомендуется наличие одной (единственной) PDP в системе, функционирующей на самом низком уровне операционной системы (в ядре 210, как упомянуто выше), что и реализовано в предлагаемом подходе.

3. Безопасная операционная система гарантирует, что все взаимодействия находятся под контролем KSS 220. Правила взаимодействия описаны на языке высокого уровня. Код, вычисляющий вердикты, является генерируемым, что позволяет обеспечить высокий уровень доверия к компонентам (приложениям 120), для которых вычисляются вердикты в KSS 220. Например, правилом описано, что компонент «А» не может иметь доступ к компоненту «Б». Но правилом может быть также описано, что компонент «А» имеет доступ к компоненту «В», а компонент «В» имеет доступ к компоненту «Б». При применении модели целостности KSS 220 выявит некорректность правила, и на этапе анализа конфигурации безопасности будет выдана ошибка.

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

Основным отличием предлагаемого подхода от других аналогичных подходов является то, что IAM 110' не является ни компонентом, реализующим политики безопасности, ни компонентом, обеспечивающим применение вердиктов. В случае с предложенной архитектурой IAM 110' - это лишь средство конфигурирования глобальной политики безопасности, что позволяет существенно упростить IAM 110', и это в свою очередь, позволяет провести его детальный анализ с целью выявления потенциальных уязвимостей и ошибок. Сами же политики безопасности, механизм вычисления вердиктов и их применения реализуются независимо в ядре 210 ОС с использованием KSS 220.

Таким образом, блок управления транспортным средством 100 функционирует под управлением безопасной операционной системы 200, которая предназначена для исполнения приложений управления транспортным средством 120 и базовых компонентов 110. Безопасная операционная система 200 содержит ядро 210 и средство безопасности 220. Базовые компоненты 110 исполняются в безопасной операционной системе 200 и предоставляют интерфейсы взаимодействия с приложениями 120 и другими базовыми компонентами 110. При этом базовый компонент 110 является изолированным приложением 120 (в соответствии с архитектурой MILS). Приложения управления транспортным средством 120 также исполняются в безопасной операционной системе 200 и взаимодействуют с базовыми компонентами 110 и другими приложениями 120 по упомянутым интерфейсам взаимодействия и предоставляют интерфейсы взаимодействия с другими приложениями 120. В общем случае упомянутые интерфейсы взаимодействия являются интерфейсами межпроцессного взаимодействия.

Ядро безопасной операционной системы 210 обеспечивает межпроцессное взаимодействие между базовыми компонентами 110 и приложениями управления транспортным средством 120 посредством упомянутых интерфейсов. Для этого ядро 210 перехватывает запросы на взаимодействие приложения 120 с базовым компонентом 110 по предоставляемому интерфейсу взаимодействия. Далее обеспечение взаимодействия происходит на основании вердикта средства безопасности безопасной операционной системы 220.

Средство безопасности безопасной операционной системы 220 является единственной точкой принятия решений предоставления доступа. В общем случае, используя формализованную модель безопасности, средство безопасности безопасной операционной системы 220 вычисляет вердикт о предоставлении доступа к базовым компонентам 110 по упомянутым интерфейсам взаимодействия. Вердикт о предоставлении доступа выносится средством безопасности безопасной операционной системы 220 в случае, если взаимодействие между базовыми компонентами 110 и приложениями управления транспортным средством 120 соответствует упомянутой формализованной модели безопасности.

Ядро 210 на основании вердикта средства безопасности безопасной операционной системы 220 обеспечивает межпроцессное взаимодействие между базовым компонентом 110 и приложением 120 посредством интерфейса взаимодействия. В случае, если вынесен вердикт на предоставление доступа, ядро 210 в одном из вариантов реализации передает перехваченный запрос на взаимодействие приложения 120 с базовым компонентом 110 по предоставляемому интерфейсу взаимодействия базовому компоненту 110.

Фиг. 3 отображает схему способа обеспечения межпроцессного взаимодействия в электронном блоке управления.

На начальном этапе 310 перехватывают с помощью ядра операционной системы 210 в электронном блоке управления транспортным средством 100 запрос на взаимодействие приложения управления транспортным средством 120 с базовым компонентом 110. В общем случае взаимодействие является межпроцессным взаимодействием. В предпочтительном варианте реализации операционная система является безопасной операционной системой, например, KasperskyOS (рассмотрена при описании Фиг. 2). Базовым компонентом 110 является программный элемент платформы, определенный в спецификации ΑΑΡ (рассмотрена при описании Фиг. 1). При этом базовый компонент 110 является изолированным приложением 120 (в соответствии с архитектурой MILS) и предоставляет интерфейс взаимодействия с приложениями 120. В общем случае базовый компонент 110 и приложение 120 предоставляют интерфейсы взаимодействия с другими базовыми компонентами 110 и другими приложениями 120.

На этапе 320 запрашивают с помощью ядра операционной системы 210 у средства безопасности операционной системы 220 вердикт о предоставлении доступа для взаимодействия приложения 120 с базовым компонентом 110 по интерфейсу взаимодействия. При этом средство безопасности операционной системы 220 является единственной точкой принятия решений (в соответствии с архитектурой FLASK), а именно, единственной точкой вычисления вердиктов о предоставлении доступа.

На этапе 330 с помощью средства безопасности операционной системы 220 вычисляют (выносят) вердикт о предоставлении доступа для взаимодействия приложения 120 с базовым компонентом 110 по интерфейсу взаимодействия. В общем случае, средство безопасности операционной системы 220 вычисляет вердикт в соответствии с политиками безопасности, которые определены на этапе компиляции и не могут быть изменены. В предпочтительном варианте реализации средство безопасности операционной системы 220 вычисляет вердикт, используя формализованную модель безопасности (рассмотрены при описании Фиг. 2). Вычисленный вердикт разрешает взаимодействие между базовым компонентом 110 и приложением управления транспортным средством 120 в случае, если взаимодействие между базовым компонентом 110 и приложением 120 соответствует формализованной модели безопасности.

На этапе 340 с помощью ядра безопасной операционной системы 210 на основании вердикта средства безопасности операционной системы 220 обеспечивают межпроцессное взаимодействие между базовым компонентом 110 и приложением управления транспортным средством 120.

Фиг. 4 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26, содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.

Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.

Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканнер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.

Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг. 4. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

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

Группа изобретений относится к системе и способу обеспечения взаимодействия приложений в электронном блоке управления (ЭБУ). ЭБУ работает под управлением операционной системы. Система содержит: по меньшей мере два приложения управления, средство безопасности операционной системы и ядро операционной системы. Приложения управления, исполняющиеся в операционной системе, предоставляют интерфейс взаимодействия с другими приложениями управления и взаимодействуют с другими приложениями по упомянутому интерфейсу взаимодействия. Средство безопасности операционной системы вычисляет вердикт о предоставлении доступа для взаимодействия приложения управления с другим приложением управления по упомянутому интерфейсу взаимодействия. Ядро операционной системы перехватывает запрос на взаимодействие приложения управления с другим приложением управления по интерфейсу взаимодействия и на основании вердикта средства безопасности операционной системы обеспечивает взаимодействие между приложениями управления посредством упомянутого интерфейса взаимодействия. Достигается обеспечение безопасности функционирования приложений в электронном блоке управления транспортного средства. 2 н. и 18 з.п. ф-лы, 8 ил.

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

- по меньшей мере два приложения управления, исполняющихся в операционной системе, которые:

• предоставляют интерфейс взаимодействия с другими приложениями управления,

• взаимодействуют с другими приложениями по упомянутому интерфейсу взаимодействия;

- средство безопасности операционной системы, которое вычисляет вердикт о предоставлении доступа для взаимодействия приложения управления с другим приложением управления по упомянутому интерфейсу взаимодействия;

- ядро операционной системы, которое:

• перехватывает запрос на взаимодействие приложения управления с другим приложением управления по интерфейсу взаимодействия;

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

2. Система по п. 1, в которой операционная система является безопасной операционной системой.

3. Система по п. 2, в которой безопасной операционной системой является KasperskyOS.

4. Система по п. 1, в которой блок управления является блоком управления транспортным средством.

5. Система по п. 1, в которой взаимодействие является межпроцессным взаимодействием.

6. Система по п. 1, в которой приложение управления является базовым компонентом платформы, определенным в спецификации Autosar Adaptive Platform.

7. Система по п. 1, в которой средство безопасности операционной системы является единственной точкой вычисления вердиктов о предоставлении доступа.

8. Система по п. 1, в которой вердикт вычисляется в соответствии с политиками безопасности, которые определены на этапе компиляции.

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

10. Система по п. 9, в которой вердикт разрешает взаимодействие между базовым компонентом и приложением управления в случае, если взаимодействие между базовым компонентом и приложением управления соответствует формализованной модели безопасности.

11. Способ обеспечения взаимодействия приложений в электронном блоке управления, работающем под управлением операционной системы, состоящий из этапов, на которых:

- перехватывают с помощью ядра операционной системы по меньшей мере один запрос на взаимодействие приложения управления, исполняющегося в операционной системе, с другим приложением управления, исполняющимся в операционной системе, по интерфейсу взаимодействия, предоставляемому приложением управления для взаимодействия с другими приложениями управления;

- запрашивают с помощью ядра операционной системы у средства безопасности операционной системы вердикт о предоставлении доступа для взаимодействия приложения управления с другим приложением управления по упомянутому интерфейсу взаимодействия;

- с помощью средства безопасности операционной системы вычисляют вердикт о предоставлении доступа для взаимодействия приложения управления с другим приложением управления по упомянутому интерфейсу взаимодействия;

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

12. Способ по п. 11, в котором операционная система является безопасной операционной системой.

13. Способ по п. 12, в котором безопасной операционной системой является KasperskyOS.

14. Способ по п. 11, в котором блок управления является блоком управления транспортным средством.

15. Способ по п. 11, в котором взаимодействие является межпроцессным взаимодействием.

16. Способ по п. 11, в котором приложение управления является базовым компонентом платформы, определенным в спецификации Autosar Adaptive Platform.

17. Способ по п. 11, в котором средство безопасности операционной системы является единственной точкой вычисления вердиктов о предоставлении доступа.

18. Способ по п. 11, в котором вердикт вычисляется в соответствии с политиками безопасности, которые определены на этапе компиляции.

19. Способ по п. 11, в котором средство безопасности операционной системы вычисляет вердикт, используя формализованную модель безопасности.

20. Способ по п. 19, в котором вердикт разрешает взаимодействие между базовым компонентом и приложением управления в случае, если взаимодействие между базовым компонентом и приложением управления соответствует формализованной модели безопасности.