RU2750626C2 - Система и способ управления доступом в электронных блоках управления транспортными средствами - Google Patents
Система и способ управления доступом в электронных блоках управления транспортными средствами Download PDFInfo
- Publication number
- RU2750626C2 RU2750626C2 RU2019138370A RU2019138370A RU2750626C2 RU 2750626 C2 RU2750626 C2 RU 2750626C2 RU 2019138370 A RU2019138370 A RU 2019138370A RU 2019138370 A RU2019138370 A RU 2019138370A RU 2750626 C2 RU2750626 C2 RU 2750626C2
- Authority
- RU
- Russia
- Prior art keywords
- interaction
- application
- security
- operating system
- base component
- Prior art date
Links
- 238000000034 method Methods 0.000 title abstract description 31
- 230000003993 interaction Effects 0.000 claims abstract description 81
- 238000004891 communication Methods 0.000 claims description 17
- 230000003044 adaptive effect Effects 0.000 claims description 10
- 238000004458 analytical method Methods 0.000 claims description 2
- 238000005516 engineering process Methods 0.000 abstract description 6
- 239000000126 substance Substances 0.000 abstract 1
- 239000000306 component Substances 0.000 description 67
- 238000013459 approach Methods 0.000 description 10
- 239000008358 core component Substances 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 6
- 230000003287 optical effect Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 5
- 238000012546 transfer Methods 0.000 description 3
- 208000035155 Mitochondrial DNA-associated Leigh syndrome Diseases 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 208000003531 maternally-inherited Leigh syndrome Diseases 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 238000007630 basic procedure Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000000593 degrading effect Effects 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 238000012067 mathematical method Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6281—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database at program execution time, where the protection is within the operating system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
- B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
- B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
- B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/12—Protecting executable software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
- H04W4/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2149—Restricted operating environment
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Mechanical Engineering (AREA)
- Automation & Control Theory (AREA)
- Databases & Information Systems (AREA)
- Multimedia (AREA)
- Technology Law (AREA)
- Stored Programmes (AREA)
- Storage Device Security (AREA)
- Control By Computers (AREA)
- Combined Controls Of Internal Combustion Engines (AREA)
Abstract
Изобретение относится к области вычислительной техники для обеспечения безопасности электронных блоков управления транспортными средствами. Технический результат заключается в обеспечении межпроцессного взаимодействия в электронном блоке управления транспортным средством. Технический результат достигается за счет системы обеспечения взаимодействия в электронном блоке управления, работающем под управлением операционной системы, при этом система содержит: базовый компонент и предоставляющий интерфейс взаимодействия с приложениями; приложение управления, взаимодействующее с базовым компонентом по упомянутому интерфейсу взаимодействия; средство безопасности операционной системы; ядро защищенной операционной системы, которое перехватывает запрос на взаимодействие приложения управления с базовым компонентом по интерфейсу взаимодействия; на основании решения средства безопасности операционной системы обеспечивает взаимодействие между базовым компонентом и приложением управления посредством упомянутого интерфейса взаимодействия. 5 з.п. ф-лы, 4 ил.
Description
Область техники
Изобретение относится к решениям для обеспечения безопасности электронных блоков управления транспортными средствами.
Уровень техники
В настоящее время вместе с развитием технологий бурно развивается автомобильная промышленность. В автомобили внедряются новые системы, позволяющие сделать управление автомобилем более комфортным. Обычно эти системы основаны на компьютерных технологиях. Различными системами автомобиля управляют блоки управления, которые в свою очередь выполняют различные алгоритмы. Так, например, для соблюдения норм экологических стандартов ЕВРО (ЕВРО-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. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.
В заключение следует отметить, что приведенные в описании сведения являются примерами, которые не ограничивают объем настоящего изобретения, определенного формулой. Специалисту в данной области становится понятным, что могут существовать и другие варианты осуществления настоящего изобретения, согласующиеся с сущностью и объемом настоящего изобретения.
Claims (15)
1. Система обеспечения межпроцессного взаимодействия в электронном блоке управления транспортным средством, который работает под управлением защищенной операционной системы, при этом система содержит элементы, исполняющиеся в указанной защищенной операционной системе:
- по меньшей мере один базовый компонент, содержащий интерфейс межпроцессного взаимодействия с приложениями управления и другими базовыми компонентами;
- по меньшей мере одно приложение управления, взаимодействующее с базовым компонентом по упомянутому интерфейсу взаимодействия, при этом каждое приложение содержит манифест, включающий сведения о доступных взаимодействиях;
- средство безопасности, предназначенное для:
- анализа манифеста приложения, запрос о котором получен от ядра защищенной операционной системы, с целью определения целостности и аутентичности указанного манифеста и получения сведения, описывающего допустимые взаимодействия приложения, заданные политиками безопасности;
- вынесения вердикта о предоставлении доступа для взаимодействия приложения с базовым компонентом по упомянутому интерфейсу взаимодействия на основании манифеста приложения;
- ядро защищенной операционной системы, которое предназначено для:
- перехвата запроса на взаимодействие приложения управления с базовым компонентом по интерфейсу взаимодействия;
- запроса у средства безопасности вердикта для обеспечения взаимодействия между базовым компонентом и приложением управления;
- на основании вынесенного вердикта средством безопасности обеспечения взаимодействия между базовым компонентом и приложением управления посредством упомянутого интерфейса взаимодействия.
2. Система по п. 1, в которой защищенной операционной системой является KasperkyOS.
3. Система по п. 1, в которой базовым компонентом является программный элемент платформы, определенный в спецификации Autosar Adaptive Platform.
4. Система по п. 1, в которой средство безопасности является единственной точкой вычисления вердиктов о предоставлении доступа.
5. Система по п. 1, в которой средство безопасности вычисляет вердикт, используя формализованную модель безопасности.
6. Система по п. 5, в которой вердикт разрешает взаимодействие между базовым компонентом и приложением управления в случае, если взаимодействие между базовым компонентом и приложением управления соответствует формализованной модели безопасности.
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| RU2019138370A RU2750626C2 (ru) | 2019-11-27 | 2019-11-27 | Система и способ управления доступом в электронных блоках управления транспортными средствами |
| US16/874,948 US11347892B2 (en) | 2019-11-27 | 2020-05-15 | System and method for access control in electronic control units of vehicles |
| EP20178816.3A EP3828748B1 (en) | 2019-11-27 | 2020-06-08 | System and method for access control in electronic control units of vehicles |
| CN202010597099.3A CN112860448B (zh) | 2019-11-27 | 2020-06-28 | 用于车辆的电子控制单元中的访问控制的系统和方法 |
| US17/727,872 US11640481B2 (en) | 2019-11-27 | 2022-04-25 | System and method for providing a security policy |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| RU2019138370A RU2750626C2 (ru) | 2019-11-27 | 2019-11-27 | Система и способ управления доступом в электронных блоках управления транспортными средствами |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| RU2019138370A RU2019138370A (ru) | 2021-05-27 |
| RU2019138370A3 RU2019138370A3 (ru) | 2021-05-27 |
| RU2750626C2 true RU2750626C2 (ru) | 2021-06-30 |
Family
ID=75974025
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| RU2019138370A RU2750626C2 (ru) | 2019-11-27 | 2019-11-27 | Система и способ управления доступом в электронных блоках управления транспортными средствами |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US11347892B2 (ru) |
| CN (1) | CN112860448B (ru) |
| RU (1) | RU2750626C2 (ru) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7405785B2 (ja) * | 2021-03-01 | 2023-12-26 | トヨタ自動車株式会社 | マネージャ、制御方法、プログラム及びマネージャを備える車両 |
| CN115102772B (zh) * | 2022-06-28 | 2023-07-04 | 广东为辰信息科技有限公司 | 基于汽车soa的安全访问控制方法 |
| CN115421469B (zh) * | 2022-08-30 | 2024-09-10 | 重庆长安汽车股份有限公司 | 一种智能座舱车控系统的安全访问方法、设备及介质 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2004124072A (ru) * | 2003-08-07 | 2006-01-27 | Майкрософт Корпорейшн (Us) | Отображение достоверности из высоконадежной среды на незащищенную среду |
| US20120159436A1 (en) * | 2010-12-21 | 2012-06-21 | Gary Morgan | Method of bypassing an autosar software component of an autosar software system |
| DE102017200286A1 (de) * | 2016-01-22 | 2017-07-27 | Denso Corporation | Fahrzeugsteuersystem |
| US20180006999A1 (en) * | 2015-06-30 | 2018-01-04 | AO Kaspersky Lab | Computer security architecture and related computing method |
| CN109246137A (zh) * | 2018-10-23 | 2019-01-18 | 北京航空航天大学 | 基于区块链的海上作战数据的安全防护方法及装置 |
| US20190050577A1 (en) * | 2017-08-10 | 2019-02-14 | AO Kaspersky Lab | System and method of ensuring secure changing of system configurations |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2399175A1 (en) * | 2000-02-16 | 2001-08-23 | Synhrgy Hr Technologies, Inc. | Improved database access system |
| DE102006054705A1 (de) * | 2006-11-21 | 2008-05-29 | Robert Bosch Gmbh | Verfahren zum Betreiben einer Recheneinheit |
| DE102007062114A1 (de) * | 2007-12-21 | 2009-07-23 | Opensynergy Gmbh | Kraftfahrzeug-Steuervorrichtung |
| US9317690B2 (en) | 2011-03-28 | 2016-04-19 | Mcafee, Inc. | System and method for firmware based anti-malware security |
| DE102012024818A1 (de) * | 2012-03-06 | 2013-09-12 | Conti Temic Microelectronic Gmbh | Verfahren zur Verbesserung der funktionalen Sicherheit und Steigerung der Verfügbarkeit eines elektronischen Regelungssystems sowie ein elektronisches Regelungssystem |
| CN103631695B (zh) * | 2013-12-19 | 2017-02-08 | 北京经纬恒润科技有限公司 | 时间监测方法及装置 |
| US10169061B2 (en) * | 2015-05-06 | 2019-01-01 | Ford Global Technologies, Llc | Scalable and flexible operating system platform |
| EP3099019B1 (en) | 2015-05-27 | 2019-01-02 | OpenSynergy GmbH | Method, computer program product, and control unit for an automotive vehicle |
| DE102016008957B4 (de) * | 2016-07-13 | 2018-01-25 | Audi Ag | Direkter Zugriff auf Bussignale in einem Kraftfahrzeug |
| EP3566400B1 (en) | 2017-01-05 | 2022-08-17 | Guardknox Cyber Technologies Ltd. | Specially programmed computing systems with associated devices configured to implement centralized services ecu based on services oriented architecture and methods of use thereof |
| RU2638000C1 (ru) * | 2017-02-08 | 2017-12-08 | Акционерное общество "Лаборатория Касперского" | Способ контроля системы исполнения программируемого логического контроллера |
| US10915102B2 (en) * | 2017-07-20 | 2021-02-09 | Panasonic Intellectual Property Management Co., Ltd. | Vehicle |
| WO2019123447A1 (en) * | 2017-12-24 | 2019-06-27 | Arilou Information Security Technologies Ltd. | System and method for tunnel-based malware detection |
| DE102018202446A1 (de) | 2018-02-19 | 2019-08-22 | Continental Automotive Gmbh | Verfahren zum Modularisieren einer Softwarearchitektur |
| CN109035117B (zh) * | 2018-09-01 | 2023-06-09 | 李善伯 | 一种自动化地面道路交通系统实现方法 |
| AT521713B1 (de) * | 2018-10-11 | 2023-07-15 | Avl List Gmbh | Verfahren zur Detektion sicherheitsrelevanter Datenflüsse |
| EP3828748B1 (en) * | 2019-11-27 | 2024-06-26 | AO Kaspersky Lab | System and method for access control in electronic control units of vehicles |
-
2019
- 2019-11-27 RU RU2019138370A patent/RU2750626C2/ru active
-
2020
- 2020-05-15 US US16/874,948 patent/US11347892B2/en active Active
- 2020-06-28 CN CN202010597099.3A patent/CN112860448B/zh active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2004124072A (ru) * | 2003-08-07 | 2006-01-27 | Майкрософт Корпорейшн (Us) | Отображение достоверности из высоконадежной среды на незащищенную среду |
| US20120159436A1 (en) * | 2010-12-21 | 2012-06-21 | Gary Morgan | Method of bypassing an autosar software component of an autosar software system |
| US20180006999A1 (en) * | 2015-06-30 | 2018-01-04 | AO Kaspersky Lab | Computer security architecture and related computing method |
| DE102017200286A1 (de) * | 2016-01-22 | 2017-07-27 | Denso Corporation | Fahrzeugsteuersystem |
| US20190050577A1 (en) * | 2017-08-10 | 2019-02-14 | AO Kaspersky Lab | System and method of ensuring secure changing of system configurations |
| CN109246137A (zh) * | 2018-10-23 | 2019-01-18 | 北京航空航天大学 | 基于区块链的海上作战数据的安全防护方法及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112860448B (zh) | 2024-05-24 |
| US11347892B2 (en) | 2022-05-31 |
| RU2019138370A (ru) | 2021-05-27 |
| CN112860448A (zh) | 2021-05-28 |
| US20210157941A1 (en) | 2021-05-27 |
| RU2019138370A3 (ru) | 2021-05-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2750626C2 (ru) | Система и способ управления доступом в электронных блоках управления транспортными средствами | |
| EP3467650B1 (en) | Controlling user creation of data resources on a data processing platform | |
| US11381575B2 (en) | Controlling access to resources of edge devices | |
| CN106326738A (zh) | 计算机安全体系架构及相关的计算方法 | |
| CN110442041B (zh) | 一种基于异构云计算框架的仿真平台构建方法及仿真系统 | |
| US9734311B1 (en) | Secure authentication of firmware configuration updates | |
| US11640481B2 (en) | System and method for providing a security policy | |
| US20120166619A1 (en) | Licensing and metering of virtualized applications | |
| RU2666645C1 (ru) | Система и способ обеспечения безопасного изменения конфигурации систем | |
| CN105827645B (zh) | 一种用于访问控制的方法、设备与系统 | |
| CN111177703B (zh) | 操作系统数据完整性的确定方法及装置 | |
| RU2749157C1 (ru) | Система и способ обеспечения межпроцессного взаимодействия в электронных блоках управления транспортными средствами | |
| CN113821353B (zh) | 在车辆的电子控制单元中实现进程间通信的系统和方法 | |
| CN112182788A (zh) | 基于虚拟仿真试验平台的资源配置方法 | |
| CN111310193A (zh) | 数据处理方法、装置、存储介质和处理器 | |
| CN115174185A (zh) | 一种访问控制方法及装置 | |
| Kalinin et al. | Formalization of objectives of grid systems resources protection against unauthorized access | |
| Saydjari | Lock: An historical perspective | |
| Prasath et al. | Autonomous Application in Requirements Analysis of Information System Development for Producing a Design Model | |
| Zegzhda et al. | Formal security model for virtual machine hypervisors in cloud computing systems | |
| Chang et al. | Implementing a hardware‐assisted memory management mechanism for arm platforms using the b method | |
| CN113312661B (zh) | 用户授权系统、方法、装置及电子设备 | |
| WO2020262456A1 (ja) | 実行コード提供方法およびソフトウェア開発システム | |
| US11469884B1 (en) | Decentralized techniques for managing device administration rights | |
| DE102021130909A1 (de) | Bereitstellen von sicheren/verschlüsselten virtuellen maschinen in einer cloud-infrastruktur |