Система и способ управления доступом в электронных блоках управления транспортными средствами

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

 

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

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

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

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

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

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

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

Однако данный стандарт предъявляет лишь высокоуровневые требования к подсистеме безопасности и вопросы реализации этой подсистемы в него не включаются. В стандарте рассматриваются различные подходы к реализации, например, возможен вариант с использованием нескольких точек принятия решения (англ. policy decision point, PDP), а сами эти точки принятия решений могут быть реализованы в виде дополнительных приложений, работающих под управлением платформы ААР. Использование этого подхода не позволяет (или существенно затрудняет) создание подсистемы безопасности с заданными свойствами, такими как полнота описания политик безопасности, их взаимная непротиворечивость, задание комплексных и сложных политик безопасности, а также не позволяет выразить свойства безопасности, уже описанные в стандарте для его базовых компонентов и сервисов.

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

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

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

Технический результат настоящего изобретения заключается в реализации заявленного назначения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг. 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, которым необходимо разрешение на взаимодействие, обращаются к IAM 110' и получают разрешения от IAM 110'. На Фиг. 1.1 отображен пример, приложение «А» для взаимодействия с приложением «Б» и для взаимодействия с базовым компонентом запрашивает разрешения на взаимодействие у IAM 110'.

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

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

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

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

- неконтролируемое увеличение доверенной кодовой базы системы, построенной на базе стандарта ААР.

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

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

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

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

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

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

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

А именно, предлагается программная платформа ААР на базе защищенной операционной системы (англ. secure operating system). Примером защищенной операционной системы является KasperkyOS 200. Ключевые свойства KasperskyOS 200 позволяют реализовать подсистему безопасности для ААР, соответствующую архитектуре MILS (англ. Multiple Independent Levels of Security).

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

Стоит отметить, что механизмы межпроцессного взаимодействия, реализованные в KasperskyOS 200, описаны в патенте US 9201712 (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. В процессе проведения IPC ядро 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 имеет идентификатор ID B. В качестве идентификатора может выступать, например, 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. Приложения управления транспортным средством 120 также исполняются в защищенной операционной системе 200 и взаимодействуют с базовыми компонентами 110 по упомянутым интерфейсам взаимодействия. В общем случае упомянутые интерфейсы взаимодействия являются интерфейсами межпроцессного взаимодействия.

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

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

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

На начальном этапе 310 перехватывают с помощью ядра операционной системы 210 в электронном блоке управления транспортным средством 100 запрос на взаимодействие приложения управления транспортным средством 120 с базовым компонентом 110. В общем случае взаимодействие является межпроцессным взаимодействием. В предпочтительном варианте реализации операционная система является защищенной операционной системой, например, KasperkyOS. Базовым компонентом 110 является программный элемент платформы, определенный в спецификации ААР. При этом базовый компонент 110 предоставляет интерфейс взаимодействия с приложениями 120. В одном из вариантов реализации базовый компонент 110 предоставляет интерфейс взаимодействия с другими базовыми компонентами 110.

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

На этапе 330 с помощью средства безопасности операционной системы 220 вычисляют (выносят) вердикт о предоставлении доступа для взаимодействия приложения 120 с базовым компонентом 110 по интерфейсу взаимодействия. В общем случае средство безопасности операционной системы 220 вычисляет вердикт, используя формализованную модель безопасности. Вычисленный вердикт разрешает взаимодействие между базовым компонентом 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. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

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

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

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

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

- средство безопасности, предназначенное для:

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

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

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

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

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

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

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

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

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

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

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