In addition to security requirements, a common way to improve system regarding security is to maintain a list of threats.
They can be assimilate to use cases and bring solution to mitigate/decrease the risks associated.
A list of definitions for acronyms is provided at the end of the page (categories).
Threats in the scope of GENIVI
| Ref. | Threat | Risk Level | Impact | Security Requirement | Threat Response | Category |
|---|
| Expert Group Responsible | Comment |
|---|---|
| T1a |
| An attacker attempts to replace components of the boot system, kernel, |
| drivers or other system software with their own malicious software. | High | If an attacker is able to |
| replace any of the components in the boot process or critical system |
| components, it may be assumed all user private data, including DRM content is |
| at risk. | This threat must be mitigated by implementing a trusted boot mechanism where |
| the root of trust must be in hardware. | The threat will be mitigated through trusted boot and file |
| system monitoring. | BM, |
| HW, SWM, SEC |
| SysInfra | • Unclear how to verify the authenticity of |
| the user land components at load time (SysInfra EG?). |
| • SWM is responsible for allowing |
| only authenticated components to be installed via supported software update |
| mechanisms. (Auto EG) |
| T1b |
| Replacement of a component of the boot system, kernel, |
| driver or other system software with prior versions of approved software that may contain errors or vulnerabilities. (aka |
| rollback attack) | High | If |
| an attacker is able to replace any of the components in the boot process or |
| critical system components with vulnerable software, it may be assumed that |
| all user private data, including DRM content is at risk. | This threat must be mitigated by implementing a trusted boot mechanism where |
| the root of trust must be in hardware that can detect rolling back to prior |
| versions of the system software. |
Only an authorized update agent is allowed to modify the files. | After |
| successful install of newer version, the older version of FW and kernel are |
| invalidated and no longer available. Also, FW is stored on NAND protected |
| partition which is not accessible to OS. Kernel modifications will require |
| root privileges. | BM, SWM |
| SysInfra | |
| T1c |
| An attacker attempts to modify the firmware to defeat a trusted boot. | High | If an attacker is able to |
| replace any of the components in the boot process or critical system |
| components with vulnerable software, it may be assumed that all user private |
| data, including DRM content is at risk. | Any part of the trusted boot |
| process must be verified when |
| update, modified or replaced. | Firmware is |
| integrity checked during the boot process. | BM, HW |
| SysInfra | • This is about the boot process and is not |
| related to SWM. |
| T1d |
| Physical duplication and replacement of flash to bypass |
| the security platform. | Medium | If |
| the components of the DRM subsystem can be duplicated and replaced without |
| detection then the attacker would be able to access the content indefinitely |
| if the content is metering on a per play use. | Since |
| this is a physically invasive attack, this will only affect one system. However, since this attack has shown to be |
| effective in similar form factor devices. | DRM |
| rights objects are reflash attack protected through the usage of monotonic |
| counters. |
Rest of the components are not refllash attack protected. | M&G, LBS |
| M&G | • DRM should be defined by M&G |
| • LBS needs a mechanism to manage |
| access to the map data |
| T1e |
| Attacker places system in debug/diagnostic/recovery mode that bypasses boot |
| authentication | High | If the system |
| can be placed in debug mode then the system is more subject to attack. | Debug and |
| development diagnostic modes must be disabled post production. | All debug features will be |
| disabled in final products. |
The recovery feature will be suitably protected. | HW |
| SysInfra | |
| T1f |
| Attacker replaces SW with approved version for different (but compatible) |
| device model or for a different geo/OEM/ISP/etc. | High | If an attacker is able to |
| replace any of the SW components with vulnerable software, it may put user |
| private data, including DRM content is at risk. | This threat must be mitigated by implementing a |
| trusted boot mechanism where the root of trust must be in hardware that can |
| detect the SW version is supportable on this HW platform. |
This attack may also target OEM usage and business models. | Each device |
| firmware can be signed by unique key thereby stopping cross-device (from same |
| OEM) usage. The keys will be different among different OEMs and hence |
| cross-OEM FW usage will not be possible. | BM, SWM |
| SysInfra | |
| T2a |
| Denial of service attack on the protected content by an attacker deleting the |
| rights object(s), or deletion of the encrypted premium content. | Medium | Prevent use of the DRM content. | Only |
| authorized entities may access the right objects or DRM storage files. | The system allows only |
| authorized entities access to critical components like ROs. | LXC, MAC |
| SysInfra | |
| T2b |
| Rights Object (RO) / license tampering when in storage on |
| file system: Time stamp modification in the license file / RO set by DRM |
| license issuer for purchased content | High | A successful |
| attack will allow unlimited viewing/access to the protected content. | The rights |
| object must be integrity |
| protected and may only be adjusted (e.g. metering counters decremented) |
| within a hardware boundary. | The ROs are |
| protected from reflash attack. They are also protected by Linux file system |
| permissions to make sure only DRM agent accesses them. | LXC, MAC |
| SysInfra | • Might include navigation map access e.g. |
| • Should not be restricted to |
| content DRM. Software license management could also be in scope. |
| T2c |
| RO/license tampering: Tampering rights object e.g. to modify the permissions |
| and constraints when in transit from the license server. | High | A successful attack will allow |
| unlimited or non-authorized entities to view/access to the protected content. | The rights object must be integrity protected in |
| transit and in storage. | Rights objects as well as DRM |
| communications are protected by the DRM license acquisition protocol (e.g. WM |
| DRM, OMA DRM) implemented by the OEM. | 3RD, NET |
| Net | |
| T2d |
| Key Theft: Stealing Content Encryption Key (CEK) after it is extracted; this |
| is a critical key for decrypting the encrypted content | High | Theft of the key would allow |
| access to the protected content. | The key must only be unencrypted form when they are being used in the |
| cryptographic engine and must be protected hardware and software attacks. | DRM keying material are only |
| plaintext and used within a HW security engine. | CRP, HW |
| Security | • Threat should be generalized as 'stealing |
| the global encryption keys'. |
| T2e |
| Theft of CEK when it is passed from DRM agent to |
| decryption engine in the media framework pipeline for decryption. | High | Theft of the key |
| would allow access to the protected content. | The key must only be unencrypted form when |
| they are being used in the cryptographic engine and must be protected |
| hardware and software attacks. | DRM keying |
| material are only plaintext and used within a HW security engine. | CRP, M&G |
| M&G | • Threat should be generalized as 'stealing |
| the global encryption keys'. |
| T2f |
| Replay attacks on content by reloading rights objects. | High | Replay attacks on the RO, by |
| replacing the RO data, will potentially allow an attacker access some content |
| for unlimited usages. | Only authorized and trusted |
| agents must be allowed to |
| manage/access the rights object database. | The RO database is accessible to |
| only authorized entities. | LXC, MAC |
| SysInfra | • Threat could be more general to any kind of |
| digital content on the platform (e.g. navigation maps). |
| T2g |
| Content theft/piracy: Content is stolen / copied from the non-volatile |
| (flash) storage. | High | If unencrypted content is |
| stored, then the DRM subsystem is considered invalid. | Protected content is encrypted when in non-volatile |
| storage. | DRM content is encrypted while |
| stored in non-volatile storage, and only decrypted in secure HW engine. | CRP |
| Security | • Check back with user management team if |
| this threat is relevant in the automotive context (e.g. managing phone books |
| from different users). |
| T2h |
| Content theft/piracy: Re-producing and pirating |
| clear/decrypted content by reading it from its memory location (Memory |
| snooping) | High | If the content |
| is transmitted internally in an unprotected form and an attacker may be able |
| to access/copy the DRM content then the DRM. | The only memory |
| containing clear content is protected from reading by apps using protected |
| memory. | DRM content is |
| protected from user since the content is only in a plaintext or decrypted |
| format in the HW security engine and |
| the hardware protected memory. | LXC, M&G |
| M&G | • Mostly related media playback use |
| cases. |
| T2i |
| Content theft/piracy: Stealing encoded content on user accessible buses using |
| logic analyzer or other hardware method. | Medium | An attacker with expert |
| knowledge and advanced tools would be able to copy the protected content. | The system must take precautions to hide sensitive busses that might be used |
| to transmit unprotected content from probing. | The buses will be hidden in the |
| platform motherboard packaging. | HW |
| Net | • Need a new threat to address data exchange |
| over INC. |
| T2j |
| Bypass security by external battery removal: rights count or time metering |
| aspects for DRM content may not be correctly updated or checked if power |
| source is removed before the content is consumed. | Medium | An attacker might be able to get |
| access to content outside the licensing rights. | The system must ensure the user cannot gain invalid access to premium content |
| by removal of the battery, and therefore prevent the attacker from bypassing |
| metering aspects of the DRM system. | Time based metering attacks will |
| be mitigated by inherent architecture of the DRM protocols. | 3RD, HW, NET |
| SysInfra | • GPS is frequently used to monitor the time |
| of the day. |
| T2k |
| Modification of the CPU memory management to expose the |
| protected memory region or redirect content to non-protected areas. | High | An attacker that |
| is able to affect the memory management including removing security of |
| restricted memory areas they would gain access to plaintext premium content. | The setting and |
| management of layout and access of the protected memory region is controlled by only trusted and |
| authorized agents. | During the boot |
| the BIOS/firmware will set the protected memory regions which will enable the |
| system to protect the premium content. | BFW, LK, LXC |
| M&G | • Added the Linux Kernel that is also |
| involved into the memory configuration. |
| T2l |
| A rogue or malicious application, with access the premium |
| content and attempts to exploit DRM methods to steal premium content. Since most premium content architectures |
| provide a ‘preview’ feature, malicious viewers would be able to ‘preview’ the |
| entire movie. | High | A |
| rogue or malicious application could take advantage of DRM methods (e.g. |
| preview capability) to expose protected content. | Any |
| application which is able to utilize the DRM subsystem must be a trusted component. | During the boot |
| process the operating system will validate the system components including |
| the DRM viewers. |
The preview capability will be limited only to few frames and accessible to |
| authorized components. | BM, M&G |
| M&G | • Added M&G EG as playback of |
| DRM-protected media is in their scope. |
| T2m |
| Attacker copies content from external audio/video connection. | High | A successful attack would |
| compromise the premium content. | Premium content should not be available of external |
| interfaces | When not using HDMI, the content |
| quality will be downgraded. | HW |
| Net | |
| T2n |
| Attacker denies playing content by consuming playback |
| resource (e.g. video overlay, audio channels, etc.). | Medium | A success attack |
| would prevent a valid end-user from utilizing system resources. | Platform should |
| provide reasonable resource management to mitigate denial of service attacks | For IVI plans to |
| provide some resource |
| management to mitigate against denial of service attacks in the form of |
| cgroups | LXC, RM, AM, LM |
| SysInfra | • Added Audio Manager and Layer Management as |
| they are involved into resource allocation. |
| T2o |
| Attacker corrupts content as it is downloaded. | High | This would prevent the end user |
| from being able to view/access content. | The communication channel must be protected from corruption |
| during download. | Integrity protection of the |
| content in an integral part of the planned DRM architectures, so it is |
| expected that this will detect any over-the-air corruption. | NET, M&G | ||
| T2p |
| Attacker plays/transfers/etc. content until license is |
| exceeded. | High | A |
| successful attack would prevent the user from accessing premium content and |
| would be considered a denial of service | Any |
| application which is able to utilize the DRM subsystem must be a trusted component. | During the |
| Trusted boot process the operating system will validate |
| the system components including the DRM viewers. |
Only authorized component will be able to access the rights object |
| database. This will be implemented using Linux file system permissions and |
| Mandatory Access Controls (MAC). |
| BM, LXC, MAC | ||
| T3a |
| Attacker tampers with messages/content sent by Device Manageability (DM) |
| server | High | This could affect system |
| functionality and expose user private data. | Messages exchanged between the |
| manageability client and server must be integrity and replay protected and, where user private data |
| is involved, must be |
| confidentiality protected. | Integrity protection of the |
| content in an integral part of the planned device manageability architecture, |
| so it is expected that this will detect any over-the-air corruption of |
| messages or data. | NET | • Need to better adapt the threat to the |
| automotive environment (e.g. Device Manageability is not a common term in |
| IVI). |
| • AI(all): Brainstorm how these |
| threats (related to DM) map to automotive diagnostics, etc. |
| • All threats in T3* are postponed |
| until a match with automotive features/technologies is defined. |
| T3b |
| A man-in-the-middle attacker hijacks DM server session; enables attacker to |
| control device completely potentially overwriting software/firmware | High | An attacker that hijacks a DM |
| session could attempt to overwrite client firmware and software. | The software and firmware that |
| is being updated from the DM server must be integrity protect to ensure the code is from an |
| authenticated and authorized party. | Confidentiality and |
| authentication protection is part of the planned device manageability session |
| architectures, so it is expected that this will detect any attempts to load |
| malicious software/firmware. | NET | • Need to better adapt the threat to the |
| automotive environment (e.g. Device Manageability is not a common term in |
| IVI). |
| T3c |
| Unauthorized DM client plug-in installed by the attacker |
| affecting SP interaction with the device | High | If an attacker |
| is able to augment any the DM client with a vulnerable/malicious plug-in, it |
| may be assumed all user private data, including DRM content is at risk. | This threat must be mitigated by using the |
| same protection mechanisms to protect plug-ins that are used to protect the |
| rest of the DM software. | The trusted boot |
| and file system monitoring mechanism will make sure there is no compromise to |
| the DM client and plug ins. Certain plug-ins will be optionally linked |
| statically to avoid any possible usage of unauthorized plug-in. | BM, LXC, MAC | ||
| T3d |
| By taking over DM client, attacker launches DOS (or DDOS) attacks on SP |
| network. | High | If an attacker is able to |
| replace any DM client with vulnerable / malicious software, it would be able |
| to launch an attack on the server. | This DM server should be resistant to denial of |
| service attacks by authorized and unauthorized entities. | DM server will not accept any |
| connections from unauthorized clients. | LXC, MAC, OOS | • The threat can be mitigated with LXC and |
| MAC, but the suggested threat response is OOS |
| T3e |
| Untrusted application accesses DM client through IPC channels opened by the |
| client application/daemon. | High | If an attacker is able to affect |
| operation of the DM client from malicious software, it may be assumed DM |
| access may be blocked. | The system must allow only authorized applications to access the DM client |
| through open IPC channels. | DM client will not allow |
| unauthorized access over its IPC channels. | IPC, LXC, MAC | ||
| T3f |
| Attacker kills the DM client; affecting SP access to the |
| device | High | An attacker |
| would create a denial of service of the ability of the DM server to support |
| the client. | The system should have some watchdog |
| mechanism to determine when a critical system component is modified, deleted |
| or halted. | System watchdog |
| will make sure all critical services remain running. | NSM | ||
| T3g |
| Attacker attempts to spoof the device to a DM server. | High | An attacker could gain user data |
| and services that are intended for the actual user. | The DM server and the client should perform a bi-directional |
| authentication. | The planned device manageability |
| architecture provides the ability to perform strong, bi-lateral |
| authentication. It will be recommended |
| to the service providers to enable this feature. | NET?, OOS? | ||
| T3h |
| Attacker places system into “unmanaged” state to re-provision or control |
| management. | High | If an attacker was able to place |
| the device into an unmanaged or un-provisioned state, this would either |
| present a denial of service to the end user, or would allow the attacker |
| re-provision the platform. | The device must prevent an unauthorized entity from placing that device into |
| an un-provisioned state. | The provisioned information is |
| either stored in the HW Security Engine or in Linux protected files in the |
| file system. | BFW, HW, PST |
| SysInfra | |
| T3i |
| Attacker replaces HW SIM/token to access unavailable |
| features/capabilities. | High | If SIM is used |
| for security of the rest of the platform, this can seriously compromise the |
| system | SIM should not |
| be used as a general purpose security mechanism. If done, then strong |
| protection mechanism should be put in place to make sure only authorized SIM |
| modules are used. | SIM will NOT be |
| used for general purpose security mechanism. Its usage will be limited to |
| only 3G network accesses. 3G network will provide access control to allow |
| only authorized SIMs | HW, OOS |
| SysInfra | |
| T4a |
| Using ptrace on a trusted/operating system component an |
| attacker can replace the text segment of a running process and then set the |
| registers such that it is executed. Thus, the attacker can directly inject |
| malicious code into an otherwise correctly working program. | High | If an attacker |
| is able to utilize ptrace on a trusted/operating system component the |
| security of the operating system may be bypassed. | For final |
| product ptrace must be |
| disabled or under access control. | Ptrace will be |
| disabled in the final product or under access control | LK, MAC |
| SysInfra | • Need an additional threat similar to this |
| related to DLT message injection. |
| T4b |
| Affect protected memory at boot to expose the area to malicious software | High | An attacker that |
| is able to affect the memory management settings at boot, including removing |
| security of restricted memory areas, they would gain access to plaintext |
| premium content. | The setting and |
| management of layout and access of the protected memory region must be controlled by only trusted |
| and authorized agents. The trusted boot process ensures that malicious or |
| unauthorized SW cannot be booted. | During the boot |
| process the BIOS/firmware |
| will set the protected memory regions which will enable the system to protect |
| the premium content. | BFW, LK |
| SysInfra | |
| T4c |
| Denial of service by deletion of some or all of the components of the |
| operating system | High | If an attacker is able to delete |
| any of the components in the boot process, or critical system components, it |
| may be assumed all operation of the client is at risk. | The system must be able to |
| detect if all components/services required for correct operation are |
| available. | The file system monitor will |
| detect the compromise. The user can recover from the compromise using the OS |
| recovery mechanism. | FSM, SWM | ||
| T4d |
| Elevation of privilege of applications by exploiting |
| vulnerabilities in system components. | High | If |
| an attacker is able to exploit vulnerabilities in any of the critical system |
| components, could lead to the exposure of user private data, including DRM. | This threat must be mitigated by minimizing |
| the capabilities of processes to the actual and minimal set of capabilities |
| required for the task, implementing access control for privileged operations |
| and running untrusted applications in sandboxes. |
The
The system must also be capable of being securely updated or patched by an |
| authenticated and authorized entity. | Number |
| of high privileged processes are minimized through MAC and process isolation. |
| Sandboxing and effective usage of access control will help minimize the |
| damage caused by compromised applications. Device will also have secure |
| software update mechanism. | LXC, MAC, SWM | ||
| T4e |
| By manipulating ld.so.conf/ld.so.conf.d the attacker can insert their |
| nefarious library into the search path before the original library. After |
| this modification, applications that are launched and wish to link to a |
| shared library (libc for example), will be directed to the nefarious libc |
| instead. | High | If an attacker is able to |
| manipulate ld.so.conf / ld.so.conf.d it may be assumed all user private data, |
| including DRM content is at risk. | This threat must be mitigated by protecting system directories from update by |
| un-authorized entities. | File system monitor will watch |
| the critical files and directories on the platform. Sandboxing will also |
| minimize the damage caused by compromised applications.. | LXC, MAC, FSM |
| SysInfra | |
| T4f |
| Leveraging a kernel or other critical component |
| vulnerability (e.g. buffer overflow) to elevate privilege. | High | If |
| an attacker is able to replace any of the system critical components by |
| exploiting vulnerable software, it may be assumed all user private data, |
| including DRM content is at risk. | Dynamic analysis would help |
| detect and mitigate any active vulnerability exploit. |
Intrusion detection system to detect updates to the critical system |
| components | Attack |
| vectors are limited through effective usage of application sandboxing. The |
| trusted boot and file system monitoring will make sure compromises are |
| detected on the file system. | BFW, LXC, MAC, FSM |
| SysInfra | |
| T4g |
| Malicious application attempts to exploit an app vulnerability to gain |
| elevated privilege. | High | The malicious |
| SW could access data, potentially user private, or perform actions that it is |
| not authorized for. | This threat must be mitigated by minimizing processing running as root, |
| implementing access control for privileged operations and running untrusted |
| applications in sandboxes. |
The system must |
| also be capable of being securely updated or patched by an authenticated and |
| authorized entity. | Number of high |
| privileged processes are minimized through Capabilities usage. Sandboxing and |
| effective usage of access control will help minimize the damage caused by |
| compromised applications. Device will also have secure software update |
| mechanism. | LXC, MAC, SWM |
| SysInfra | |
| T4h |
| An attacker exhausts system resources (memory, disk, etc.) to trigger OS |
| vulnerability or error. | Medium | If an attacker |
| is able to overload critical system components, it may be assumed all |
| operation of the client is at risk. | The system must be able to detect a DoS |
| operation to prevent incorrect operation. | No plans to |
| control resource usage by a process. | LXC, RM |
| Net | • GENIVI Resource Management might provided |
| for a different threat response. |
| T4i |
| An attacker attaches a malicious device (e.g. 1394) to compromise the kernel |
| via DMA. | High | An attacker which is able to |
| utilize a DMA device to compromise the kernel could bypass system security. | The system must control what devices have DMA access, and those abstracted |
| and controlled. | The kernel may not load |
| untrusted (unsigned / unauthenticated) drivers. The trusted boot will make |
| sure that all drivers are trust worthy. The security update mechanism will |
| provide a way to fix bugs found in drivers and kernel. | BFW, SWM |
| SysInfra | • Assume that the cases where software can be |
| injected an executed before the kernel is loaded is covered by BFW. |
| • The response 'the kernel will not |
| be able to load new drivers' is not acceptable in GENIVI context. Some sort |
| of driver signature verification must be put in place instead. |
| T4j |
| An attacker triggers an OS vulnerability/error via HW |
| modifications (e.g. jumpers). | Medium | If |
| OS vulnerability may be induced by a HW setting, an attacker may be able to |
| reduce or affect the security of the platform. | We |
| must ensure that user (or attacker) accessible HW interfaces may not be |
| modified to reduce security of the platform. | HW |
| modifications are out of scope for this document. Through trusted boot and |
| security update mechanisms the device will guarantee to run the trusted |
| kernel and software components. | HW, OOS |
| SysInfra | |
| T5a |
| The user or malicious software attempts to set/reset the RTC used by DRM |
| agent. | High | If an attacker is able to affect |
| the operation of the RTC, the attacker could be able to access the content |
| indefinitely if the content is metered per-play. | Only authorized and trusted |
| agents must be allowed to |
| manage the real time clock. | RTC will not be accessible to |
| any SW component for SET operation. DRM agent will use the RTC to implement |
| its time management functions. | LXC, NET, MAC |
| Net | • Connman, NTP involved |
| • ome head units use GPS or other |
| modules in the vehicle as a source of real time. |
| • As a threat response, only allow |
| the RTC to be changed by trusted components. In this way, event when the |
| system time is synchronized to e.g. spoofed source, the RTC remains |
| unaffected. |
| T5b |
| Denial of service against the flash memory by a malicious |
| application which attempts to exceed the erase/write lifecycle of the flash. | Medium | This could |
| dramatically reduce the lifetime of the device or require a hardware update |
| to the system. |
Attacks on a flash area that may hold system components may introduce other |
| vulnerabilities. | It |
| is recommended that the system should be able to detect and/or prevent abusive or unsafe accesses |
| (erase/write operations) to the flash device. | Wear-leveling |
| shall be used to prevent burnout. | PST, LXC |
| SysInfra | • There might be cases where the flash memory |
| is written to bypassing the persistence component (e.g. if the flash memory |
| is accessible via a writable file system). |
| T5c |
| Denial of service against the CPU by a malicious application which attempts |
| to consume CPU cycles. | Medium | This could dramatically reduce |
| availability of the system. | It is recommended that the |
| system must be able to |
| prevent/throttle abusive operations by applications. | Resource management to mitigate |
| DOS attacks is out of scope | LXC, RM |
| SysInfra | |
| T5d |
| The RTC is set by an authorized agent, although the |
| authorized agent is using an untrusted time source. | High | If |
| an attacker is able to affect the source of the RTC, the attacker could be |
| able to access the content indefinitely if the content is metering on a per |
| play use. | Only authorized |
| and trusted agents must be |
| allowed to manage/access the real time clock. |
The architecture must |
| also identify best practices on what are valid time sources for the RTC. | RTC |
| will not be accessible to any SW component for SET operation. The SCU |
| firmware manages the RTC time setting if needed. | NET |
| SysInfra | • Connman runs NTP and should be resposible |
| for authenticating the time source. |
| • The same should apply to the |
| components using the time from GPS or other ECUs to set RTC. |
| T5e |
| Unauthorized re-Flash of device through external debug port (e.g. JTAG): If |
| the JTAG ports are kept open and unprotected in field, attackers can use it |
| to alter device properties, update software on flash, modify the behavior etc | High | If an attacker is able to access |
| unprotected JTAG interfaces, they may be able to use it to alter device |
| properties, update software on flash, modify system behavior, extract keying |
| material and compromise the entire system security. | JTAG ports must be disabled or protected. | The IVI platform has secure JTAG |
| interface which requires asymmetric key based authentication. | HW | ||
| T5f |
| An attacker depletes the battery by overuse of |
| power-hungry resources (e.g. video brightness, wireless power levels, etc,). | Medium | If |
| an attacker is able to misuse, power intensive system components, the |
| attacker may be able to affect user interaction | The |
| system must be able to |
| control access to power intensive system to authenticated / authorized users. | Resource |
| management to mitigate DOS attacks is out of scope. All system resources that |
| need to be protected, will implement some form of access control. |
| Un-authorized applications will not be allowed to manage these resources | LXC, RM, MAC |
| SysInfra | • Thread Model document says "Resource |
| management to mitigate DOS attacks is out of scope", which is not |
| correct. |
| T5g |
| An attacker manipulates HW to DoS or annoy user (e.g. change screen |
| brightness, play audio noise, etc.). | Medium | A successful |
| attacker would be able to prevent valid operation of device based on |
| modification of system settings. | The system must be able to control access to |
| system configuration settings | Resource |
| management to mitigate DOS attacks is out of scope. All system resources that |
| need to be protected, will implement some form of access control. |
| Un-authorized applications will not be allowed to manage these resources | LXC, RM, MAC | • Thread Model document says "Resource |
| management to mitigate DOS attacks is out of scope", which is not |
| correct. |
| T6a |
| Malicious application attempts to programmatically disrupt system services, |
| (e.g WiMAX stack, 3G services, DRM stack, device manageability services) | High | If an attacker is able to |
| disrupt any of the system services, the system security may be significantly |
| compromised. | Access to trusted and critical |
| system services must protected |
| and only available to trusted applications and services. | Number of high privileged |
| processes are minimized through Capabilities usage. Sandboxing and effective |
| usage of access control will help minimize the damage caused by compromised |
| applications. Device will also have secure software update mechanism. | LXC, MAC, SWM |
| Net | |
| T6b |
| With the use of the LD_PRELOAD environment variable, the |
| attacker can link a nefarious library into an otherwise unmodified binary and |
| subvert it when it is executed. | High | An |
| attacker could use the init() function to execute nefarious code immediately |
| as well as overriding predefined symbols to insert nefarious actions during |
| the execution of the subverted program. E.g. redefine the read() function to copy the data returned to another location. | This |
| threat must be mitigated by |
| ensuring only certain environment variables are allowed in the application |
| sandboxes. | File |
| system monitor will watch the critical files and directories on the platform. |
| Sandboxing will also minimize the damage caused by compromised applications. | BFW, LXC, MAC, FSM |
| SysInfra | |
| T6c |
| Malware (trojans, viruses, phishing applications, etc.) is allowed to |
| execute. | High | Once malware |
| runs, it may not be possible to completely prevent it from stealing user |
| data, utilizing user services or acting as a bot targeting other systems or |
| devices. | This threat must be mitigated by making sure the platform can support |
| anti-virus/anti-malware applications. |
It is also strongly recommended that platforms should have anti-virus/anti-malware |
| applications installed and configured before shipment to the end user. | Through Application sandboxing the damage |
| caused by the malware will be limited to only the compromised applications. |
| OEM may also choose to install a mobile optimized anti-virus software to |
| further control the damage. | LXC, MAC, RM |
| SysInfra | |
| T6d |
| Malware spoofs dialog boxes or other components of the UI. | Medium | Malware which is able to display |
| arbitrary dialog boxes could trick the user into installing further |
| applications, requesting and stealing additional user data, etc. | This threat must be mitigated by making sure the platform can support |
| anti-virus/anti-malware applications which would be able to prevent and/or |
| detect this malware. | No plans to implement trusted path like mechanism to |
| provide trusted i/o. Many of the social engineering like attacks are |
| currently out of scope. | LXC, MAC, OOS |
| Security | • LXC and MAC can mitigate the threat, but |
| the suggested threat response is OOS |
| • Popup manager API must be |
| accessible only to the authorized applications. |
| T7a |
| Denial of service attack on the network stack | High | If an attacker |
| is able disrupt any of the system services, the system security may be |
| significantly compromised. | The network |
| stack must be resilient to |
| DoS attacks by having basic firewalling capabilities | The system will |
| mitigate this threat as outlined in the Network Firewall and access control |
| section | NET |
| SysInfra | • Ryan to clarify how to incorporate the |
| Network Firewall configuration. |
| T8a |
| Denial of service attack on the platform keying material |
| by the deletion or overwrite of the key storage file. | High | If an attacker |
| could delete or modify the cryptographic keying material this could |
| compromise or prevent the use and manageability of the device | Only authorized entities may access the cryptographic keying |
| storage files. The key storage file must be protected from applications running on the main CPU. | All keys are |
| protected within the HW security engine environment. The DRM and other keys |
| are never exposed to the applications running on CPU. | CRP, LXC, MAC, PST |
| Security | • Since a broad range of hardware designs |
| must be supported, extend the threat response to say that if the keys are not |
| managed by the HW security engine, there will be additional risks to address. |
| T8b |
| Replacement of, or direct access to, flash to extract or |
| modify cryptographic keys. | High | If attacker is |
| able to extract plaintext keying material from flash it may be assumed all |
| user private data, including DRM content, is at risk. | All |
| cryptographic keys must be |
| stored securely to preserve integrity and confidentiality. | OTP provides |
| secure storage for all keys configured during provisioning. The DRM RO keys |
| are stored in HW security engine key ring which is encrypted by device root |
| key (RKEK) and stored in NAND. | HW, PST |
| SysInfra | • Since a broad range of hardware designs |
| must be supported, extend the threat response to say that if the keys are not |
| managed by the HW security engine, there will be additional risks to address. |
| T8c |
| Simple or differential timing/power/RF analysis attacks on the crypto engine |
| to recover the keying material. | Medium | If an attacker is able to mount |
| a simple/differential timing/power/RF analysis attack, they might be able to |
| extract keying material for the cryptographic subsystem. | The device should be resistant to simple and differential timing/power/RF |
| attacks. | Security HW engine does not |
| mitigate this threat. | HW | • The threat response needs to be reworded to |
| say that the hardware can only partially mitigate this threat. |
| T8d |
| Use of weak crypto by some applications. | Medium | Weak cryptography could expose |
| application data to cryptanalysis. | Ensure that guidelines are |
| giving to OEMs/ISV for distribution to application developers. | The HW security engine supports |
| industry standard strength cryptographic algorithms and mechanisms. | CRP | • Need also to provide guidelines about |
| recommended algorithms and key lengths. |
| T8e |
| Attacker deletes or replaces another applications |
| cryptographic keys or data. | High | A malicious |
| application, which is able to access or manage cryptographic keys or data |
| that it does not own, could prevent correct operation of the device. | There must be a mechanism to restrict |
| access to only authenticated and authorized applications. | See T8a |
| response. The DOS like attack where malicious application deleting the keys |
| stored in key ring is possible. | CRP, LXC, MAC, PST | • Since a broad range of hardware designs |
| must be supported, extend the threat response to say that if the keys are not |
| managed by the HW security engine, there will be additional risks to address. |
| T8f |
| Attacker exhausts RNG entropy (DoS). | Medium | A malicious application exhausts |
| the entropy from the RNG and there prevents valid other application |
| components receiving strong random numbers. | There must be a mechanism to ensure the RNG only provides strong random |
| numbers. | HW security engine may not be |
| mitigating this threat fully. | HW, CRP | ||
| T9a |
| Platform secrets, RNG seeds, configuration information or |
| keying material are altered or disclosed at production or provisioning time. | High | This insider |
| attack is launched by the production employee, or launched from the |
| compromised provisioning equipment, the attacker would be able control or |
| copy critical security information being placed onto the platform | To prevent these |
| insider threats approved secure provisioning techniques must be followed. | OEMs are |
| strongly advised to maintain secure manufacturing sites where key and other |
| provisioning will take place. | OOS |
| CEConn | • The threat response should also apply to |
| the service sites (garages, etc.) |
| T9b |
| Malicious firmware or trusted software is embedded at time |
| of production or point-of-sale, servicing where device management or |
| provisioning occurs. | High | This |
| insider attack is launched by the production employee or launched from the |
| compromised provisioning equipment. The attacker would be able to compromise |
| the complete system. | To prevent these insider threats |
| approved secure provisioning techniques must be followed. |
This threat must be |
| mitigated by implementing a trusted boot mechanism where the root of trust |
| must be in hardware that can detect the malicious replacement of firmware. | OEMs |
| are strongly advised to maintain secure manufacturing sites where key and |
| other provisioning will take place. | OOS, HW, BFW |
| CEConn | • The threat response should also apply to |
| the service sites (garages, etc.) |
| T9c |
| Additional (unpaid/unauthorized) non-malicious SW is installed (that adds |
| features, etc.). | High | This insider attack is launched |
| by the production employee or launched from the compromised provisioning |
| equipment. The attacker would be able to compromise the complete system. | To prevent these insider threats |
| approved secure provisioning techniques must be followed. | OEMs are strongly advised to |
| maintain secure manufacturing sites where key and other provisioning will |
| take place. | OOS |
| SysInfra | • The threat response should also apply to |
| the service sites (garages, etc.) |
| T9d |
| Device HW could be cloned. | Medium | Loss of business for Tier-1 and |
| OEMs, as well as an impact on consumer confidence. | Standard OEM Policies regarding |
| HW cloning must be adhered |
| to. | Device unique key will help |
| mitigate the risk. | HW, BFW |
| DLT | |
| T10a |
| An attacker attempts to read/discover context or location |
| data stored on the device, generated by the device, or in transport to a |
| third party from the device. | High | A successful |
| attack would present a significant end-user privacy breach from the device. | The |
| confidentiality of context or location aware data must be protected by access control and/or cryptography. If should be configurable which services |
| and applications have access to the location information to preserve end-user |
| privacy and security. | Sandboxed |
| applications are aware of resources that are directly exposed. The access |
| control techniques will also make sure that only certain apps can access |
| critical system resources. | LXC, MAC, CRP, PST, NET, CEC |
| DLT | • The exact context of this threat is |
| unclear. Does it only apply at run time or also to standalone and |
| disassembled head units? (The threats T12a-T12b suggest that this is the |
| former.) |
| • CEC is affected in the case of |
| e.g. off-board navigation via a nomadic device. |
| T10b |
| An attacker modifies context or location data stored on the device, generated |
| by the device, or in transport to a third party from the device. | High | A successful attack could |
| present a disruption in service on the platform. This disruption could cause security issues |
| to the end- user. For example if an |
| attacker were able to modify location data, emergency services (e.g. 911) |
| would not be able to correctly find the end-user. | The integrity of context or |
| location aware data must be |
| protected by access control and/or cryptography. | Sandboxed applications are aware |
| of resources that are directly exposed. The access control techniques will |
| also make sure that only certain apps can access critical system resources. | LXC, MAC, CRP, PST, NET, CEC | ||
| T10c |
| Malicious application attempts to gain access to user |
| private data (e.g. email addresses, calendar information) | High | On an open |
| platform a malicious application may attempt to access and exploit user data. | This threat should be mitigated by providing |
| effective sandboxing for applications, providing mechanisms to applications |
| to protect privacy sensitive data. | Application |
| sandboxing will allow apps to hide information and other data. Email client |
| running a sandbox will not be visible to other apps. Also, it is encouraged |
| that applications use strong access control on any external interfaces. | LXC, MAC, CRP, PST, NET, CEC | ||
| T10d |
| Screen scraping by malicious application. | High | An |
| application, which is able to scrape or capture information from the screen, |
| may be able to gain access to user authentication data. | This |
| threat must be mitigated by |
| making sure the platform can support anti-virus/anti-malware applications |
| which would be able to prevent and/or detect this malware. | Mobile |
| anti-virus software will mitigate this threat in a reactive fashion. | LXC, MAC, M&G, SEC | • The access to the frame buffers managed by |
| the Graphics Backend Server must be restricted (M&G). |
| • Antivirus software is not directly |
| addressed in GENIVI. The features currently included with FSM might be |
| covered by a more generic anti-virus software (SEC). |
| T11a |
| An attacker is able to send unsolicited messages over Bluetooth to |
| Bluetooth-enabled device. |
| (Bluejacking) | Medium | Bluejacking is usually harmless, |
| but because bluejacked people generally don't know what has happened, they |
| may think that their device is malfunctioning. Usually, a bluejacker will |
| only send a text message, but with modern devices it's possible to send images |
| or sounds as well. |
With the increase in the availability of Bluetooth enabled devices, these |
| devices have become vulnerable to virus attacks and even complete take over |
| of devices through a trojan horse. | The device should also have the ability to |
| configure its’ visibility to other clients, that is the device into |
| undiscoverable mode. | OEMs are encouraged to deploy devices with |
| Bluetooth disabled by default | CEC | ||
| T11b |
| A potential attacker can attack the Bluetooth interface to make phone calls, |
| send messages read and write contacts and calendar events, eavesdrop on phone |
| conversations, and connect to the Internet. (Bluebugging) | High | A potential |
| attacker can attack the Bluetooth interface to make phone calls, send |
| messages, read and write contacts and calendar events, eavesdrop on phone |
| conversations, and connect to the Internet. | The device should also have the ability to configure its’ visibility to other |
| clients, that is the device into undiscoverable mode. |
The device must implement strong access control for sensitive functions |
| like SMS, read/write privacy data etc. | Sandboxed applications are aware |
| of resources that are directly exposed. The access control techniques will |
| also make sure that only certain apps can access critical system |
| resources. |
The Bluetooth devices are not connected without user prompt. | CEC, LXC, MAC | ||
| T12a |
| Loss of Personal data when the attacker has physical control of the device. | High | If private, |
| sensitive user data is unprotected in non-volatile storage, an attacker with |
| physical access may be capable of retrieving this data | The device must be capable of encrypting sensitive user data in non-volatile |
| storage. Note: the platform cryptographic services must be available for use |
| by applications. |
The device must be capable of allowing the service provider to remotely |
| disable/lock it. | The device |
| supports a range of cryptographic services that will be available to |
| application developers to utilize to protect their data. | PST, CRP | ||
| T12b |
| Insertion of malicious HW and return | Medium | An attacker |
| launching a successful HW attack could present a DoS attack or bypass device |
| security. | Best design |
| practices to prevent unauthorized hardware addition or modification/removal |
| of valid HW. | We need to |
| ensure and help educate OEMs/ISVs that user (or attacker) accessible HW |
| interfaces may not be modified to reduce security of the platform. | OOS | ||
| T13a |
| An attacker is able to modify and/or delete security critical application |
| or operating system audit logs. | High | If an attacker |
| is able to modify and/or delete security critical audit logs, security |
| information that a device administrator uses to correctly manage the device |
| may be compromised, and hence the correct operation or security of the |
| devices is at risk. | The device must integrity protect operating system audit logs and provide the |
| cryptographic capabilities for integrity to applications to protect their |
| logs and data. |
The device must also protect access to the management of these logs. | Linux based |
| protection only. Apps should make sure the logs stored in syslogd have no |
| secret information. | DLT, LXC, MAC, PST | • The threat response does not seem to match |
| the threat description (avoiding to put private data into logs does not help |
| to prevent the logs from being deleted or modified). |
| • Assuming that this threat is about |
| accessing the log file directly (bypassing the auditing application.) |
| T13b |
| A malicious entity (internal or external to the device) attacks the |
| auditing/logging system or components. | High | Attacker which is able to |
| successfully attack the logging/auditing components of the system |
| could: |
| • Prevent system components or |
| applications for logging |
| • Maliciously add or erase log |
| entries |
| • Maliciously delete log |
| entries |
| • Change timestamp data |
| • Read sensitive log data. | The system must provide robust authentication |
| and authorization over the auditing and logging subsystem. | Linux based |
| protection only. Apps should make sure the logs stored in syslogd have no |
| secret information. | DLT, LXC, MAC | • Assuming that this threat is about |
| accessing the log file contents via the auditing application. |
Threats out of GENIVI scope
| Threat | Risk Level | Impact | Security Requirement | Threat Response | Category | EG | Comment | |
|---|---|---|---|---|---|---|---|---|
| T2i | Content theft/piracy: Stealing encoded content on user accessible buses using logic analyzer or other hardware method. | Medium | An attacker with expert knowledge and advanced tools would be able to copy the protected content. | The system must take precautions to hide sensitive busses that might be used to transmit unprotected content from probing. | The buses will be hidden in the platform motherboard packaging. | HW | OOS | Need a new threat to address data exchange over INC. |
| T2m | Attacker copies content from external audio/video connection. | High | A successful attack would compromise the premium content. | Premium content should not be available of external interfaces | When not using HDMI, the content quality will be downgraded. | HW | OOS | |
| T4j | An attacker triggers an OS vulnerability/error via HW modifications (e.g. jumpers). | Medium | If OS vulnerability may be induced by a HW setting, an attacker may be able to reduce or affect the security of the platform. | We must ensure that user (or attacker) accessible HW interfaces may not be modified to reduce security of the platform. | HW modifications are out of scope for this document. Through trusted boot and security update mechanisms the device will guarantee to run the trusted kernel and software components. | HW, OOS | OOS | |
| T5e | Unauthorized re-Flash of device through external debug port (e.g. JTAG): If the JTAG ports are kept open and unprotected in field, attackers can use it to alter device properties, update software on flash, modify the behavior etc | High | If an attacker is able to access unprotected JTAG interfaces, they may be able to use it to alter device properties, update software on flash, modify system behavior, extract keying material and compromise the entire system security. | JTAG ports must be disabled or protected. | The IVI platform has secure JTAG interface which requires asymmetric key based authentication. | HW | OOS | |
| T8c | Simple or differential timing/power/RF analysis attacks on the crypto engine to recover the keying material. | Medium | If an attacker is able to mount a simple/differential timing/power/RF analysis attack, they might be able to extract keying material for the cryptographic subsystem. | The device should be resistant to simple and differential timing/power/RF attacks. | Security HW engine does not mitigate this threat. | HW | OOS | The threat response needs to be reworded to say that the hardware can only partially mitigate this threat. |
| T9a | Platform secrets, RNG seeds, configuration information or keying material are altered or disclosed at production or provisioning time. | High | This insider attack is launched by the production employee, or launched from the compromised provisioning equipment, the attacker would be able control or copy critical security information being placed onto the platform | To prevent these insider threats approved secure provisioning techniques must be followed. | OEMs are strongly advised to maintain secure manufacturing sites where key and other provisioning will take place. | OOS | OOS | The threat response should also apply to the service sites (garages, etc.) |
| T9b | Malicious firmware or trusted software is embedded at time of production or point-of-sale, servicing where device management or provisioning occurs. | High | This insider attack is launched by the production employee or launched from the compromised provisioning equipment. The attacker would be able to compromise the complete system. | To prevent these insider threats approved secure provisioning techniques must be followed. This threat must be mitigated by implementing a trusted boot mechanism where the root of trust must be in hardware that can detect the malicious replacement of firmware. | OEMs are strongly advised to maintain secure manufacturing sites where key and other provisioning will take place. | OOS, HW, BFW | OOS | The threat response should also apply to the service sites (garages, etc.) |
| T9c | Additional (unpaid/unauthorized) non-malicious SW is installed (that adds features, etc.). | High | This insider attack is launched by the production employee or launched from the compromised provisioning equipment. The attacker would be able to compromise the complete system. | To prevent these insider threats approved secure provisioning techniques must be followed. | OEMs are strongly advised to maintain secure manufacturing sites where key and other provisioning will take place. | OOS | OOS | The threat response should also apply to the service sites (garages, etc.) |
| T12b | Insertion of malicious HW and return | Medium | An attacker launching a successful HW attack could present a DoS attack or bypass device security. | Best design practices to prevent unauthorized hardware addition or modification/removal of valid HW. | We need to ensure and help educate OEMs/ISVs that user (or attacker) accessible HW interfaces may not be modified to reduce security of the platform. | OOS | OOS |
Acronyms for classification
3RD : third parties
AM : audio management
BFW : BIOS/Firmware
BM : Boot management
CEC : Connectivity
CRP : Crypto
DLT : Diag, Log & Trace
FSM : File system monitoring
HW : Hardware (like secure boot)
IPC : inter-process communication
LBS : Location-based services
LK : Linux kernel
LXC : linux container
M&G : media and graphics
MAC : Mandatory Access Control
NET : network
NSM : Node state management
OOS : out of scope (for GENIVI)
PST : persistence
RM : resource management
SEC : Security
SWM : Software management