Modular AI Vehicle Security & Support (MAVSS): Holistic Cybersecurity Approach
Charles Parker, II; MBA / MSA / JD / LLM / PhD
Vehicles are and have been for decades an integral facet of the nation’s culture. Consumer’s spend hours with their vehicles, these are in movies, songs, and other cultural aspects. These are in cartoons and advertisements from the 1960’s and 1970’s, indicating there will be flying cars in the future. In the Saturday Evening Post from the 1950’s, the driverless vehicle was advertised (Weber, 2014).
After years of thought, creativity, design, and engineering, the vehicle’s functionality advanced. The prior rendition of the vehicle was a mechanical beast, requiring several mechanical engineers and one electrical engineer. The innovations and advances inversed this ratio. The increase in electrical engineers is required as the vehicle moved from primarily being mechanically focused to a greater level of interaction with the user and implementation of electronics.
In particular, the users demanded through their financial voting to purchase vehicles that were advanced and integrated with their personal electronics and devices, and offered interactions with the world outside of the vehicle. These include music services, maps, phone calls, texting, and the various other functions, making the vehicle achieve greater sales.
At present, the industry and vehicle environment is at the cusp of autonomous drive (AD) vehicles actively on the road. The driver won’t need to engage with the vehicle or other drivers on the road. The vehicle’s sensors and OS will manage the systems and driving, as the vehicle moves toward the user’s destination, interacting with other vehicles (V2V) and the infrastructure (V2I). To engineer this functionality to not only operate but also with safety and security integrated through the software development lifecycle (SDLC) requires teams of electrical engineers, software engineers, cybersecurity engineers, and other technical specialties, along with a few mechanical engineers.
The advancing technology has been experienced by the general public in the past with vehicle’s key and entry system. The vehicle’s key system started with the physical, metal key. This tool was upgraded to a button to push (Gill, & Sachin, 2016). Now, with near field communication (NFC), the user simply walks up to the vehicle and this opens with a press of a button on the door handle. The next step may be a biometric fingerprint scanner. This is already used as a security feature in other industries for over a decade. This technology has already proven itself to be viable and proficient.
The minimalist statement on the connected and autonomous vehicle (CAV), in that the vehicle will just drive itself, while simplistic, still requires a certain level of definitions. The vehicle manufacturers, as the technology improved, strengthened the sophistication and complexity of the modules and sensors in operation within the confines of the vehicle (Lima, Rocha, Volp, et al., 2016). The CAV requires constant communication with other vehicles (V2V), the infrastructure when time- and technology-appropriate (V2I), and other germane equipment relevant to the vehicles operations within and with other vehicles (V2X). The intra-vehicle communication involves the sensors located throughout the vehicle, internal and external. The sensors within the vehicle act as a gateway for the real-world (Shin, Son, Park, et al., 2016) as these provide the input which is processed. These sensors are located throughout the vehicle at the various strategic locations.
Attack Points
These sensors are vital to the CAV. These have to completely communicate at all times with other sensors and logging functions. Any lag or disruption would represent a problematic situation. This situation, the CAV would not have the required data and information to safely operate and drive on the roadway alone or with other vehicles present. This situation may provide for significant physical damage to the vehicle (Bezemskij, Loukas, Anthony, & Gam, 2016). The CAV would e operating virtually blind without these operating well and in a timely manner. This attack point is present with each sensor across the vehicle. The attacker would choose the sensor requiring the least effort to compromise, providing the greatest ROE (return on effort) expended. The attack may then pivot from one compromise to other systems. With each successful attack, there would be increasingly detrimental effects to the vehicle, its operations, and potentially the passengers. This may also provide for vehicle theft (Omanakuttan, Sreedhan, Manoj, et al., 2017).
Detection and Mitigation
With this level of pertinence on these systems, the sensors and related activities should be fully secured from unauthorized access and manipulation. The historic attacks have been centered on three aspects of sensor operations-software, network, and spoofing (Shoukry, Nuzzo, Pugelli, Sangiovanni-Vincentelli, Seshia, & Tabuada, 2015). With software, there may be malicious applications operating within the sensor, may forward incorrect frames/messages, or not send these. With the network as the attack point, the backbone communication may be targeted, or the packets may be adjusted for the attacker’s malicious intent. Spoofing involves the attack providing false data to the sensor from an external source. The typical example of this involves GPS spoofing. The attacker could send a signal indicating the vehicle is in Panama, when actually they are in Oxford, OH. With spoofing attacks, the sensors are vulnerable to this form of manipulation (Shin, Son, Park, et al., 2016). These would be manifested as contactless attacks (Yan, Xu, & Liu, 2016). The detecting the unauthorized access and malicious manipulation is the primary initial step. The detection step, in theory and design, has been problematic (Shoukry, Nuzzo, et al., 2015).
Prior Research
The prior detection methods have focused on different aspects of the system. Shoukry, Nuzzo, Puggelli, et al. (2015) researched detection in a linear dynamical system. The researcher's theory termed this secure state estimation. This detection involved each sensor as this would be attacked, while mitigation is more concerned with the state of the module or system being attacked and the subsequent malicious messages/frames.
Spoofing input data is troublesome to the vehicle for several reasons (Son, Shin, Kim, et al., 2015). The researchers investigated attacking drones utilizing the Micro-Electro-Mechanical Systems (MEMS) gyroscope. The research indicated the spoofing did negatively affect the drone applications. This was evidenced by 18 of the 20 drones losing control and crashing. The research answered the hypothesis of whether this was possible. The countermeasures were noted as physical isolation, differential comparator resonance timing. One limiting aspect to the research was the detection and defenses were based on the researcher's limited parameters.
Davidson, Wu, Jellinek, et al. (2016) also researched unmanned aerial vehicles (UAV) spoofing attacks. The research indicated the noted attacks were effective. The primary defensive measure for the researcher’s theory was the RANSAC algorithm.
Yan, Xu, and Liu (2016) researched contactless attacks against autonomous vehicles. The researchers noted the difference between a traditional form network and networks in autonomous vehicles. The autonomous vehicles depend heavily on the sensors to assist these in analyzing the environment for driving decisions. For the study, the researcher’s target was a Tesla Model S. The researchers in the use case were successful with spoofing and jamming attacks.
Holistic Approach
The attempt to create the cybersecurity protocol and application has been in the design mode for well over a decade. Nearly all of these efforts have been fruitless. There are a number of companies in the market conducting proof of concept (PoC) testing to understand how to mold their system into a vehicle’s network, communication network, and protocols. This has exhibited itself much like attempting to place a square peg into a much smaller round hole. There has not been a cybersecurity system designed with the focus on the embedded system as part of the environment. The prior attempts have designed a system and attempted to force this into the embedded system.
The present companies have viewed this function as static or the simple input/output issue to be managed by one transaction. As for the former, the companies view the vehicle as a quasi-castle or stronghold. The application is viewed as the castle walls, seemingly impregnable. The castle walls during the medieval era. During this period, there were several attacks against the static castle walls, which were exceptionally effective. Samples of these include, however, are not limited to, fire, battering rams, ladders, catapults, and others (History on the Net, n.d.).
Other companies view this as a more simplistic transaction. In the case with a malicious or erroneous message/frame, in theory, the system would detect the issue, and simply remove this from the communication channel. The transaction is exceptionally simple. When the input is deemed as not appropriate, this is removed from the communication or data flow.
Figure 1.
The problematic portion with these have been and continues to be the overly narrow simplistic application of the potential uses of the creativity and technology. This is not a quick transaction. The CAV and its safety implications require much more thought, effort, and application of resources. The cybersecurity application needs to be presented with much more than this. With the level of applicable, viable technology available, this should be implemented.
These present applications detect the attack or message/frame sent in error and remove this from the equation. The method may have worked in the earlier days of vehicle attacks or with an attacker lacking imagination, motivation, or an updated knowledge of exploiting vulnerabilities.
This approach either ceases at this point or logs the event. In the case of spoofing, there has been engineered into the system minimal effort to ensure the sensor inputs are valid. The single step application of cybersecurity will not operate significantly well in the future environment with CAV in vast numbers on the roadways through the nation.
With the level of technology available for this application, additional processes and learning by the modules and nodes are warranted. The machine learning (ML) / artificial intelligence (AI) application to vehicle cybersecurity is well applicable, yet has not been explored or initiated in the past. AI provides for decision-making, deeper understanding of the data and implications, and issue detection and reporting.
MAVSS (Modular AI Vehicle Security & Support)
MAVSS is a new application of present technology. This allows for future ML/AI technology incorporation as this advances, is tested, and fully vetted for appropriate placement. This provides for a deeper understanding and appreciation of the transaction in the vehicle communication channels. The new application of technology will require additional process overhead. This is engineered not to be a significant detriment to the vehicle’s or passenger’s safety and operations. As this or a like system is incorporated into the CAV, this processing time, would become the baseline.
This new system is modular in form. The vehicle manufacturer may apply all or part of the MAVSS vehicle cybersecurity system. Based on the use case and target vehicle, there may not be the need for the entire system due to the OEM’s needs or parameters. The system likewise is agnostic. This may be applied to any vehicle platform. There is no limitation as to the platform this may be incorporated into.
This module focuses on quick decision-making. This is required for the vehicle’s basic operations. Any new system cannot create a significant time lag. This is also required if the vehicle were to be under attack, especially in the case with contactless modes of attack.
This new cybersecurity system is based on a biology model. With any organism, there is the potential for infection. This may be from a break in the skin or exoskeleton or an ingesting an item. The organism does not take the stance of the skin, exoskeleton, or body being impregnable or perfectly secure from an attack. The exterior is not and would never be perfect. The body takes into account there will be breaches in their system. The physiology manages this. The body is always looking for attempts to break the exterior to enter the organism. This is analogous to an attack. There is a weak point in the skin. The organization may digest food that creates an issue. The breach in the skin or system is analogous to a compromise. The weak point is the attack surface. The malware introduced into the system via a portal or gateway.
Once the break in the exterior is detected by the organism’s system, this is remedied by a number of different resources being delegated to attack the malware. This is not simply detected and noted, but communicated to other resources to complete the removal of the issue or remediation. This is also used for future protection in the form of antibodies and other assets, as the body learns. MAVSS is no different in its design and application for this holistic defense.
AI and ML is applied also to the embedded systems and sensors in CAV. MAVSS is not architected to be a simple “If this then that” simple algorithm. This learning is for a baseline of level of communication between the modules and ECUs and is the starting point (Bezemskjj, Loukas, Anthony, & Gan, 2016). This is a common application with machine learning (ML) and AI. The systems learn the baseline, and expected activity for a vehicle, fleet, or platform through activity. This is completed at the manufacturer, and through user driving through applying ML with linear regression. This is done to remove any potential out of context messages. These should not be present as they may be unexpected, in error, or simply malicious in nature.
These messages or frames would be manufacturer provided. The OEM engineered the product. The engineers know the protocol and general timing of events and messages. As an example, when the user is making a left turn, there are a number of steps prior to the vehicle turning. These would need to be present in order for the vehicle to make the left hand turn. Each respective OEM would provide their CAN database (Evenchick, 2013). This has the OEM messages and signals. These are also known as the OEMs DBC or CAN DBC files (CSS Electronics, n.d.). These generally are specific per each OEM. These provide the expected messages and signals, and timing. This is not perfect, however, is an exceptional resource. This provides a significant amount of data that would be required. There would be empty spaces in the data and timing, which would be filled in by the actual data from the vehicle operations.
For each OEM, the user or an agent for the OEM would need to operate a vehicle for three to four days. This time is required to capture a sufficient level of data and messages to provide a level of comfort. This time would provide for the messages that would be encountered by the vehicle in nearly all of the use cases. The number of vehicles required would be dependent on the OEM. If the entirety of the fleet use the same set of CAN messages, the required number of vehicles would be limited to under five. If this were not to be the case, there would need to be this same number of vehicles per each vehicle fleet using different CAN messages.
This would be an on-going process with the user, as they would operate the vehicle. This would function to assist MAVSS with learning over time from the user’s day to day operations. This would apply also regression analysis. As each day passes, the increase in data and analysis provides a greater level of understanding of the standard communications and appropriate timing of these.
As noted, the system is designed to be holistic in structure and defensive in posture. MAVSS is designed to holistic as this is not analyzing the vehicle as an impregnable castle, or static in nature. Historically, the static model has not worked exceptionally well. There were significant difficulties with the present offerings. This is analogous to the enterprise attack cycle, with the Admin creating a solution. This tends to work well for a limited amount of time. The attackers find another vulnerability and exploit this. The Admin creates a new solution for the vulnerability, and the cycle continues.
For the vehicle use case, the dynamic system is required. With the level of sophistication of a select group in attackers, the target with a static defense is welcomed. The attackers have a static target to research and attack. The dynamic learning from its environment and intuitive nature as to these inputs would provide a much more difficult target. The MAVSS form is based on nature. There is a Central Brain with extensions monitoring and making decisions. This is analogous to an octopus. There is a central brain managing the overall animal. The extension brains manage the local issues. If an issue is presented the extension brain is not able to manage, this is reported to the central brain.
General Structure
MAVSS is engineered with Central Processor (CP) and External Nodes (XT Nodes). The Central Processor functions as the primary/central brain. This manages decisions above the local process (XT Nodes). Typically, this would manage the red flags and significant detected issues.
The XT Nodes are external to the central processor. This manages daily operations, questions, and issues. This is connected to the Central Processor. The XT Node function is to complete the initial processing and decision-making. If there were to be a significant issue, which is not able to be managed locally, this would be directed by the central processor prior to alerting the OEM.
Operations
The Central Processor receives the data from the XT Nodes when appropriate. The XT Nodes forwards the general log at regularly scheduled intervals, and when there is an issue with the messages/frames. This functions to analyze any correlations between nodes and the subject activity. The correlation analysis reviews for anomalies, equipment errors, and any message/frame directing an action outside of a margin from the regression analysis and model. Any of these found to be an issue are triaged. With these, the system decides the best course of action with the issue management. This management would take into consideration safety first. This would be managed at the central processor level first. If this were not to be able to be resolved at the vehicle level, the issue and logs would be sent to the OEM over the air (OTA).
The logging is a pertinent function for the MAVSS. The XT node logs detected attacks, anomalies, and unusual activities. This general log is forwarded to the central processor daily or every two days. The central processor uploads to the cloud daily. The cloud application analyzes the data per OEM, and product line. This is completed on various levels to review for issues. This data is analyzed alone, from day to day, week to week, against others in the state, region, and country. This would function to not only analyze the data from the vehicle, but also others to analyze for any potential trends, i.e. attacks against fleets, or groups of vehicles.
The error log itself is received by the central processor. The issue and data had been already triaged and compiled by the XT node. The red-flagged issues are handled differently than the standard issue.
XT Node Interaction with Sensors
The XT node, as a natural course of action, completes routine plausibility tests based on the sensor data and reality. This test is to ensure the data from point to point is viable and physically attainable. This analysis is a complete process, and not a boilerplate action. For each sensor, the generic, general test would be the same overall process. This testing however would be specialized for each sensor’s data and functionality. The testing itself would compare the prior and current data points for plausibility. This would function to check the current points and prior point for reality measures. This would also take into account a trend analysis, including drift, and regression analysis.
An example would involve GPS and a direct plausibility test. The vehicle is not able to be physically located in two separate geographic locations simultaneously or travel thousands of miles in seconds. This would violate the laws of physics. The vehicle may be located in Flint, MI at 3:04p, but not Tampa, FL at 3:07p on the same day.
As a second example, the user is driving to East Lansing, MI. There is the average traffic flow on I-69. The GPS is operating appropriately. The vehicle begins to receive two GPS satellite signals much stronger than the others. Within a minute these signals are the strongest. The GPS signals indicate four minutes later the vehicle is in Colorado. The XT node detects this clear issue and registers this as an anomaly for further review and analysis The anomalous GPS signals continue. The XT node continues to monitor these. The XT node cannot reconcile the present GPS coordinates with the most recent coordinates occurring prior to the GPS signals creating the issue. The vehicle has failed the plausibility and drift tests, along with the regression analysis comparison tests. With the autonomous vehicle, this is a critical issue, which needs to be managed immediately.
This is managed on the front-end with the vehicle ML/AI UX interface not contacting the user, as the GPS is clearly not correct. This may cause an issue with the user if this were to be communicated in an incorrect manner. The module would then operate per the OEM directive. These options include the vehicle depending on the other sensors, e.g. LiDAR and radar, immediately and continuing to travel on the safe route. The V2V would also act to compensate for the loss of the GPS signal.
In the case when the attack/issue is no longer present, the systems receiving the subject data would return online and processing the data and implementing the noted data.
As for the vehicle’s administrative or back-end processes, MAVSS would report the issue to the central processor and forward the relevant portion of the log (e.g. time stamps, geographic data for the seven prior recordings and erroneous recordings, etc.). This would be forwarded to the OEM for review and may direct other vehicle actions.
If at any point, the operations would not be safe for the vehicle and users, the ML/AI UX interface would contact them to instruct them to take control of the vehicle operations. At a certain point when the vehicle would be out of range of the faux GPS signals, the GPS data and input could be placed back into the data used to guide the vehicle.
The ML/AI module addition adds a needed layer of analysis, and decision-making to increase the UX, safety, and value for the user. This addition benefits the individual vehicle, driver, passengers, and other vehicles. The MAVSS adds this along with the traditional security.
O/S Hardening
With any O/S, and especially within the vehicle, there is the distinct need to control the access to the system, processes, and other parties (Sigg, 2011). This applies the principle of least privilege. If the O/S is vulnerable or susceptible to attack and compromise, the other sensors, modules, ECUs, and vehicles may not trust the specific equipment or any of the messages or data generated by it. There may be an unauthorized person or another application controlling the messages, and subsequently the vehicle and its operations. Any trust with the compromised system would be a fallacy at best.
The intent with MAVSS is to prevent the issue, deter the attack, create a vehicle cybersecurity environment in which the compromise would be excessively complex and difficult in comparison to others, and in general create a secure center of operations. The attributes have been designed to accomplish this via incorporating ML/AI into this to secure the O/S and overall system. The defense is required. This in effect would act as a communication gateway, secured from unauthorized entry and communication.
Although this is a complicated issue, the methods to accomplish this furtherance for security are known, have been implemented, and robust. This uses generally accepted methods. There is no need to recreate the wheel in this instance. With the checks and counter-checks, the redundancy is not a requirement, however, is implemented at certain critical points. This also functions to reduce any potential waste of resources. The system is designed to incorporate the functions as needed. The functions and modules are implemented, while the portions not needed are not incorporated. This reduces the redundancy, processing overhead (hardware and software requirements, and heat generation), and financial costs.
The methods are partially borrowed from the enterprise cybersecurity defensive systems. This would include a firewall to protect the system from any malicious inbound and outbound traffic. This tool may be used presently as part of the defense in depth. In the longer-term, this may be supplemented by other tools, which would work better in our environment. This would act as a wall between the internet and internal structure (IBM, n.d.). This is necessary to protect the system (Bach & Alshammari, 2013). The intent is to prevent any unauthorized access to the system. This would use a stateful firewall, as this inspects the packets and tracks the TCP connection (Bach & Alshammari, 2013). This would be configured with security in mind. Specifically, this would receive messages from a limited number of known and approved IP addresses. This list would not be published externally to the OEM, Tier 1, or Tier 2 manufacturer. Within the application, the IPs are limited and whitelisted. Only the trusted sources involved and are allowed to interact with the vehicle. Any updates to this are secured and encrypted. These are updated at the dealership or OTA (e.g. FOTA or SOTA, dependent on the use case). Only the digitally signed packages are accepted.
Within this vehicle cybersecurity application, the IP address could be spoofed. While this is a viable attack method, the defense-in-depth counter-measures would be the effective remediation.
Anti-malware and anti-virus software also be incorporated into the system. This would be implemented to protect the system from unauthorized software. This would be a lightweight system. This would not be operating at all times, but only when needed. The scan process would be operating during non-optimal times. This would also be triggered when an application or other non-digitally signed file or application would be attempted to be downloaded, regardless of who initiated the download. As this is an integral part of the system’s cybersecurity health, the would be regularly scheduled. Due to this, the system would not be slowed down, and be used as an additional layer only.
This is pertinent, as malicious applications may be unintentionally downloaded by the user onto the vehicle, or intentionally by another application, without the user’s consent.
The attack vectors are updated frequently by attackers and researchers. A new attack vector involves the mobile cell phone. The Apple phones have their respective application (Apple CarPlay), as does Android (Android Auto). In the case where there would be malware on the cell phones, if this were to be coded carefully, may affect the vehicle’s operations.
The methods to attack the system are numerous and change with regularity. To create a system based on attack signatures would only be a slight workable solution based on this. With the new attacks, it is not possible to protect against the entirety of potential attacks based on the scope and vehicle confines. Also, to create a system to magically know the future attacks is not possible due to the nuances of prior attacks, along with the attacks on hardware and software to exploit the vulnerabilities yet to be detected by the manufacturers and cybersecurity researchers.
To meet their ends, the attackers have a general set of steps followed, to varying degrees. The first two steps are pertinent to this use case. The attackers may perform reconnaissance and scanning (Rossi, 2016; Smith, 2017; Grey Campus, n.d.) to increase their knowledge of the attack surface for the module or ECU. To counter these steps, the MAVSS would monitor the IP addresses attempting to connect to the module or ECU. If this would not be on the whitelist, the IP address would be blocked and logged, along with the date, day, and time. These would be analyzed for correlations within the vehicle, and also the other vehicles, in case the attacker was working towards a large scale attack. This data would be forwarded to the central processor, and later forwarded to the cloud for meta-analysis.
There are two potential issues with this. The vehicle could place a honeypot in the MAVSS to lure the attackers towards and away from their potential actual targets within the vehicle. This solution would not be practical due to the processing overhead and cost.
In the scenario where the attacker was able to bypass the entirety of the security controls, and their lateral movement within the vehicle not be noticed, one action they may work towards is exfiltrating the software, firmware, keys, etc. The system would also be reviewing outgoing traffic to ensure this was routed to approved IP addresses only. The data volume would also be checked for plausibility prior to being sent. For example, if the expected daily log traffic was expected to be 750G, and on a Thursday a 3T file was attempted to be sent, the system would pause the traffic to review the significant differential. This data would be forwarded to the central processor, and later forwarded to the cloud for analysis.
The files also are a target for the attackers. The attackers may want to temporarily park data in a file in the vehicle for exfiltration at a later date, as they accumulate the targeted data or information. The MAVSS knows what files are to be on the system and their estimated size. The system would compare files within the whitelist to verify the estimated size, and only the files are present that are supposed to be. This would not be a constant function, however, would be completed periodically. As these issues are detected, the data would be forwarded to the central processor by the XT node.
The system would also have a distinct knowledge of the ECUs and their respective configuration. The system would periodically check the whitelisted configuration for each ECU (e.g. authorized open ports) against the actual ECU configuration. This would likewise not be a constantly operating function but reviewed periodically (i.e. the 15th of the month or the next day the vehicle is on). As these issues are detected, the data would be forwarded to the central processor by the XT node.
At times, the firmware and software may need to be updated. The FOTA or SOTA updates require authentication to verify these are from the trusted sources. There are several vendors who have created and vetted a solution for this, including Red Bend (Ahmed, 2016). The MAVSS would integrate an authentication process into the system.
Event Trigger
At the XT Nodes, at times there are safety triggers for the vehicle. These would be automatically addressed. From a biological aspect, the regular process is relatively clear. Input from the fingerprint is sent to the spinal column, forwarded to the brain for processing, and the message redirected back to the finger via the same route for an action or inaction. There are certain inputs that are defined as being critical to the organism’s well-being. In these emergency situations, an immediate reaction is required. If this is not done, the external issue may destroy tissue or kill the organism.
With these safety critical cases, (e.g. touching an excessively hot item), the organism retracts the finger immediately prior to the message being sent to the brain for processing and a decision being returned. Within the vehicle, the issue may physically manifest itself as the vehicle being in an accident and the airbags being deployed. As the accident occurs, the vehicle occupants would not want the message delayed with the message being processed at the XT Node, triaged and recognized and not being able to be processed, forwarded to the central processor, processed and decisioned, and forwarded back to the XT Node for processing. In this case, the message would not be delayed. The message would continue without being processed so the airbags would be deployed and other safety features implemented. This would be fully logged as part of the natural process.
Closing
With this system, there may appear to be an over-abundance of caution in certain processes with the layers of cybersecurity. This defense in depth will be required as the industry continues to move towards the AD vehicles. This tool or a like functioning tool will be a direct or indirect requirement for the autonomous drive vehicles.
References
Davidson, D., Wu, H., Jellinek, R., Singh, V., & Ristenpart, T. (2016, August). Controlling UAVs with sensor input spoofing attacks. Retrieved from https://www.usenix.org/system/files/conference/woot16/woot16-paper-davidson.pdf
Kumar, KN, & KR, S. (2018). U.S. Patent Application No. 2018/0278628A1. Washington, DC: U.S. Patent and Trademark Office.
Lima, A., Rocha, F., Volp, M., & Esteves-Verissimo, P. (2016, October). Toward safe and secure autonomous and cooperative vehicle ecosystems. In Proceedings of the 2nd ACM Workshop on Cyber-Physical Systems Security and Privacy, pp. 59-70. doi:https://dx.doi.org/10.1145/2994487.2994489. Retrieved from http://orbilu.unilu/bitstream/10993/28773/1/cps03-limaA.pdf
Omanakuttan, A., Sreedhar, D., Manoj, A., Achankunju, A., &Cherian, C.M. (2017). GPS and GSM based engine locking system using smart password. International Journal of Computer Sciences and Engineering, 5(4), 57-61. Retrieved from http://www.ijcseonline.org/pub-paper/10-IJCSE-02023.pdf
Park, B., & DeMarco, C.L. (2016). Optimal controls via waveform relaxation for power systems cyber-security applications. 2016 IEEE Power and Energy, Society General Meeting (PESGM). doi:10.1109/PESGM.2016.7741585
Rubin, S.H., Grefe, W.K., Bouabana-Tebibel, T. Chen, S., Shyu, M., & Simonsen, K.S. (2017). Cyber-secure UAV communications using neuristically inferred stochastic grammars and hard real-time adaptive waveform synthesis and evolution. IN 2017 IEEE International Conference on Information Reuse and Integration (IRI). Retrieved from https://users.cs.fiu.edu/~chens/PDF/IRI17_stuart.pdf
Shoukry, Y., Nuzzo, P., Puggelli, A., Sangiovanni-Vincentelli, A.L., Seshia, S.A., & Tabuada, P. (2017). Secure state estimation for cyber-physical systems under sensor attacks: A satisfiability modulo theory approach. IEEE Transactions on Automatic Control, 62(10), 4917-4932. Retrieved from https://arxiv.org/pdf/1412.4324.pdf
Son, Y., Shin, H., Kim, D., Park, Y.S., Noh, J., Choi, K., Choi, J., & Kim, Y. (2015, August 12-14). Rocking drones with intentional sound noise on gyroscopic sensors. Symposium conducted at the Proceedings of the 24th USENIX Security Symposium in Washington, D.C. Retrieved from https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-son.pdf
