Projects
Securing the Connected Car: An In-Depth TARA Journey
Figure 1: The Connected Vehicle System Under Scrutiny
The modern vehicle is no longer just a mode of transport; it's a complex, interconnected digital ecosystem on wheels. This evolution, while bringing unprecedented convenience and features, also introduces a new frontier of cybersecurity challenges. Our team at UniWest conducted a meticulous Threat Analysis and Risk Assessment (TARA) on a critical use case involving remote vehicle interaction. This endeavor aimed to expose potential vulnerabilities and fortify the vehicle against cyber threats.
Understanding the Digital Fortress: The System Design
The system under assessment, illustrated in Figure 1 above, showcases a common yet critical functionality: headlight control, both locally via a switch and remotely through a mobile application. The core components include:
- Body ECU (Electronic Control Unit): This acts as a central hub for various body control functions. It processes signals from the driver's switch and communicates over the CAN bus. Notably, it also features a JTAG interface, a potential point of interest for attackers.
- CAN Bus: The backbone of in-vehicle communication, this network relays commands and data between different ECUs and actuators, including the one controlling the headlights.
- Actuator & Headlight: The physical components that execute the command to turn the headlights on, off, or make them blink.
- Telematics Gateway: The crucial link between the vehicle's internal network and the outside world. It employs Wi-Fi, Bluetooth, and 5G connectivity, making it a primary target for remote attacks.
- Cloud Platform: An external server infrastructure that facilitates communication between the mobile application and the vehicle via the Telematics Gateway.
- Mobile Application: Allows users to perform actions like locating their parked vehicle by making the headlights blink, demonstrating a direct remote interaction pathway.
This architecture, while enabling advanced features, presents multiple entry points and communication channels that could be exploited if not properly secured.
Figure 2: Visualizing the Data's Journey - Our DFD
Laying the Groundwork: Key Assumptions
Before diving into the threat landscape, we established several operational assumptions to define the scope and focus of our TARA:
- The firmware and software embedded within the vehicle's components were assumed to be functioning correctly and providing accurate data.
- "Over-the-air" (OTA) update mechanisms were presumed to utilize secure channels with cryptographically signed packages, thereby mitigating risks of unauthorized remote code execution through this vector.
- For this specific assessment, core driving systems such as brakes, acceleration, and steering were considered isolated from the software systems under review and thus not directly affected by software-based threats.
- The vehicle's power supply systems (batteries, alternators) were assumed to be resilient against electronic disruptions.
These assumptions allowed us to concentrate on the vulnerabilities within the defined connected headlight system.
Mapping the Threat Landscape: Threat Identification and Risk Assessment
Our analysis, guided by a meticulously constructed Data Flow Diagram (DFD) (Figure 2) and the STRIDE threat modeling methodology, brought several potential threats to light. We evaluated each based on the attacker's required access, opportunity, available target information, necessary equipment, and skills, alongside the potential operational, safety, privacy, and financial impacts.
Spotlight on Key Threats:
Threat #01: CAN Bus Tampering
Imagine an attacker, armed with standard off-the-shelf wireless sniffing tools, positioned near
the vehicle. As the unsuspecting owner uses their mobile app to, say, blink the headlights, the
attacker intercepts these CAN bus messages relayed wirelessly via the telematics gateway. This
"sporadic" opportunity requires proficient technical knowledge of both wireless protocols and
CAN bus communication. While only limited data is exposed, the potential impact is severe:
"Medium" operational disruption and, alarmingly, "Life-threatening injuries" if critical
functions like headlight control are compromised during driving.
Threat #03: Actuator Spoofing
In this scenario, an attacker with expert understanding doesn't need direct physical access. By
intercepting signals related to the mobile app, they could inject unauthorized commands through
the telematics gateway. This would give them direct control over the headlight actuator,
allowing them to turn the lights on/off or make them blink erratically. While the target
information is limited, the opportunity is "Frequent" once wireless channel access is gained,
and standard CAN message injection tools suffice. The ramifications? "Medium" operational impact
and potentially "Life-threatening injuries" due to hazardous driving conditions created by
sudden headlight changes.
Threat #04: Mobile Client Spoofing
The danger here lies in social engineering and mobile security expertise. An attacker could
develop a rogue mobile application that perfectly mimics the OEM's official app. Distributed
widely, this malicious app could trick users into granting it access, thereby stealing sensitive
personal data from the phone, including real-time location information. Although this attack
might not directly impact vehicle operation or safety, the "High" privacy impact is a
significant concern, potentially leading to substantial financial and reputational damage for
the OEM.
Other identified threats included Denial of Service (DoS) attacks on the Body ECU and the Cloud infrastructure , as well as Information Disclosure vulnerabilities in the Cloud.
Figure 3: Snapshot of Initial Risk Levels (Illustrative)
Building Stronger Walls: Mitigation and Security Requirements
Identifying threats is only half the battle; devising robust countermeasures is paramount. Our recommendations focused on a defense-in-depth strategy:
- CAN Bus Integrity: To counter tampering (Threat ID #01), we proposed the encryption and authentication of CAN bus communications. This involves layered cryptographic protection and mutual authentication mechanisms.
- Secure App-to-Vehicle Communication: For threats like Actuator Spoofing (Threat ID #03), end-to-end security is key. This means robust encryption and mutual authentication for all control commands exchanged between the mobile app and the telematics gateway.
- User and Application Trust: To combat Mobile Client Spoofing (Threat ID #04), enforcing strong, multi-factor user authentication is essential. Furthermore, creating a trusted app ecosystem, possibly with app vetting and continuous monitoring for abnormal behavior, is crucial.
- Cloud Resilience: Protecting against Information Disclosure (Threat ID #05) and DoS attacks on the cloud requires securing APIs with strong encryption, implementing token-based authentication, conducting regular security audits, and continuously monitoring for any breaches or anomalous traffic patterns.
The Road to Resilience: Evaluating Residual Risk
The implementation of these security controls leads to a significant reduction in the overall risk profile. For example, with encrypted and authenticated CAN bus messages, the likelihood of successful tampering plummets, drastically lowering the operational and safety-critical impacts of Threat ID #01. Similarly, end-to-end security for mobile app commands makes unauthorized actuator control (Threat ID #03) far more difficult, minimizing associated risks. Stronger authentication and a secure app ecosystem substantially mitigate the privacy risks from malicious mobile apps (Threat ID #04), and enhanced cloud security measures reduce the chances and impact of data breaches (Threat ID #05).
Figure 4: Snapshot of Residual Risk Levels After Mitigation (Illustrative)
Lessons Learned and The Path Forward
This TARA project provided profound insights into the multifaceted nature of automotive cybersecurity. It underscored the necessity of a holistic approach, considering every component and communication link as a potential attack vector. The exercise reinforced the value of systematic methodologies like STRIDE and DFDs in comprehensively mapping out threats and understanding system interactions. Prioritizing risks based on their diverse impacts is critical for focusing mitigation efforts effectively.
Ultimately, securing connected vehicles is an ongoing journey, not a destination. As technology evolves, so too will the threats. Continuous monitoring, regular reassessment of risks, and adaptive security measures are essential to stay ahead in this dynamic landscape, ensuring that the future of mobility is not only smart but also secure.
This project overview is based on "Lab 2: TARA, Automotive Cyber Security" by Group 15, HORTVG, for University West & Combitech. Images are representational based on figures from the report.
Engineering a Distributed Media Platform
Figure 1: The platform interface, showcasing various media.
This project was undertaken as part of the "Distributed Systems, Databases, and Blockchains" course at University West. The primary goal was to practically apply theoretical concepts of distributed systems, including architecture, communication, naming, and fault tolerance, while also fostering collaborative development skills. We developed "ArtGather," a web platform designed with a three-tier architecture to provide a structured solution for managing data access and user interaction related to art, movies, and music.
The Architectural Backbone: A Three-Tier Approach
ArtGather is built upon a classic three-tier architecture. This model divides the application making it modular and easy to work with. The layers are as such:
- Presentation Layer: This is the user-facing interface, developed using HTML, CSS, and JavaScript (with Jinja for templating). Displaying information and capturing user input through various forms and interactive elements.
- Application Layer (Business Logic): The core of the system, this middle tier runs on a Flask (Python) backend. It processes user requests from the presentation layer, enforces business rules, interacts with the data layer, and orchestrates the overall system behavior.
- Data Layer: Responsible for data persistence and management, this layer utilizes a MariaDB (a fork of MySQL) relational database. It handles storage, retrieval, and ensures data consistency and integrity. The database itself was hosted on a Raspberry Pi 4.
Figure 2: Conceptual overview of the three-tier architecture employed in ArtGather.
Communication between the web frontend and the Flask server occurs via HTTP methods, facilitated by a Web Server Gateway Interface (WSGI). The Flask application, in turn, communicates with the MariaDB database using the Flask-MySQL extension to execute SQL queries.
Frontend: Crafting the User Experience
The frontend was built with standard web technologies to create an intuitive and visually appealing user experience. HTML was used for structuring content and forms, CSS for styling and layout, and JavaScript for dynamic behaviors such as hover effects on cards and buttons, and popup menus. Jinja templating allowed for dynamic content rendering within the HTML pages served by Flask. The visual design, including color palettes, aimed to align with initial sketches from the system design phase.
Figure 3: Additional UI design asset from project materials.
Backend: The Powerhouse with Flask
The server-side logic, encapsulated in `server.py`, was developed using Python and Flask. Key aspects of the backend include:
- Virtual Environment: To manage dependencies like Flask, Flask-MySQL, and Flask-Bcrypt effectively, a Python virtual environment was utilized.
- Routing and Request Handling: Flask's `@app.route()` decorator was used to define URL endpoints and specify how GET and POST requests are handled. User input from HTML forms and Jinja templates was processed accordingly.
- Session Management: Flask sessions were used to maintain user state and manage interactions across multiple requests.
- Security: User passwords were securely managed by hashing them using the Flask-Bcrypt extension before storage in the database.
Evolving the Database: A Pinterest-Inspiried Approach
A significant engineering challenge and a highlight of this project was the evolution of the database design. The initial concept for data organization (Figure 4) was relatively straightforward. However, to create a more engaging and flexible user experience for discovering and curating media, a more sophisticated approach was needed.
Figure 4: The initial high-level ERD design for the ArtGather database.
Figure 5: The final ER Diagram of the ArtGather database, showing tables like Users, Items, and Lists.
This led to the from-scratch design and implementation of a "Pinterest-style" system. This involved a significant expansion of the database schema (Figure 5) to support features like user-created "boards" (or lists), allowing users to collect and categorize items (art, movies, music) in a highly personalized manner. This required new tables and relationships to effectively link users, items, and these curated boards, demonstrating agile development and the ability to adapt and expand the system based on evolving requirements for a richer user experience. This dynamic system allowed users to not just consume content, but actively organize and share their discoveries, much like popular visual discovery engines.
Core Functionalities of ArtGather
The platform aimed to provide several key features, many of which were implemented:
- User registration and login with hashed password support.
- Profile customization, including profile pictures and descriptions.
- Uploading content (art, metadata for movies/music). Uploaded image files were stored in the server's filesystem (`/static/img`), with their paths saved in the database.
- Creating and managing "boards" or lists of items.
- Categorization of items (Art, Movies, Music).
- A system for users to "buy" art (simulated, as payment support was not fully implemented).
- A booking system for temporarily reserving items.
Figure 6: Another UI design asset from project materials.
The Booking System: Handling Concurrent Reservations
A key feature was the item reservation system, designed to handle concurrent user requests. This was implemented as a Python class within the Flask server.
- It used a dictionary (`self.booking_list`) to store active reservations, mapping item IDs to user IDs.
- Threading timers (`self.timers`) were associated with each reservation, typically for a 10-minute window.
- The system operated on a first-come, first-served basis. If a user attempted to book an item, their request was timestamped by the server.
- If the reservation timer expired or the user navigated away from the reservation page without completing the "purchase," the reservation was automatically cancelled, making the item available again.
Figure 7: Illustration of time-based coordination for booking requests, showing how server-side timestamping helps manage concurrency.
This server-side time-based coordination was favored over client-side timestamps to mitigate issues like network latency and client-side manipulation. However, if the server itself were to restart, active reservations would be lost as they were stored in runtime memory.
Figure 8: System component interaction diagram element from project materials.
Reflections and Learnings
This project provided valuable experience in designing and implementing a distributed system. Key takeaways include:
- Scope Management: Not all initially planned functionalities were fully implemented or bug-free due to time constraints. For instance, advanced list management and full media playback capabilities were simplified.
- Practical Problem Solving: Devising a solution for image uploads (filesystem storage with DB path) was a practical challenge overcome.
- Scalability and Reliability: While the three-tier architecture supports scalability in principle, hosting both the application and data layers on a single Raspberry Pi presented a significant bottleneck and a single point of failure. The educational focus prioritized manageable simplicity over robust, production-grade replication and fault tolerance.
- Security Considerations: Password hashing was a good security practice implemented. However, the communication between layers (e.g., WSGI) was not encrypted with protocols like HTTPS, which would be crucial for a production system.
- Collaborative Development: The use of Git and GitHub was essential for team collaboration.
- Development Approach: Working with vanilla JavaScript and allowing CSS styling directly within HTML files for specific pages offered flexibility for team members working on different parts of the application simultaneously.
Conclusion
The ArtGather project successfully demonstrated the application of distributed system principles in a practical context. It resulted in a functional platform for users to share and discover media, built with a focus on maintainability and developer-friendly practices, even if some planned features were simplified. While the system had limitations in terms of scalability and fault tolerance due to its educational scope and hardware constraints, it provided a solid foundation and significant learning experiences in full-stack development and distributed system design.
This project overview is based on the "Distribuerade system, databaser och blockkedjor Laborationsrapport" by Ali-Rida Ammar and a partner student, University West, DSD400, 2024. Images are adapted or taken from the report.