wiki:Ada

Overview

Ada as a project will focus on printing as much of the vehicle as possible. Based initially on a professionally manufactured frame, Ada will be composed mostly of 3D printed parts, including parts produced using our microwave-based aluminum casting method. The goals is to reduce costs, encourage security, and render hardware and software specs available for use by anyone so motivated.

Security

The Ada's computing system will generally emphasize the reduction of both internal (involving physical access) and external attack surfaces.

Emphasizing the security of these products by examining a wide set of potential (even highly unlikely) threat models is not to suggest that such concerns should worry average drivers, but rather to improve the quality of the high-tech devices which we use in our everyday lives and promote the principles of shared knowledge and freedom to innovate/collaborate.

Translation: This is about Free and open source security and efficient innovation- NOT Tin-Foil Hats.

  • ECUs currently employ unique identification, authentication, and encryption schemes for protection. Most communication within a vehicle uses a model-unique data/command/format system that operates on OSI levels 1 and 2. We will produce our own free and open source data protection schemes, and employ layers of security at the transport and session layers. We will also attempt to implement lower-level communication protocols of minimal computational complexity in order to facilitate a reduced exploitation potential and bolster our ability to authenticate legitimate inputs. We will engage in formal verification/mathematically prove our software.
  • In addition to attempting to minimize hardware vulnerabilities in our initial design, we intend to provide security by avoiding mistakes found in previous research regarding common entry points for hardware as well as via stringent auditing and patching.
  • The need for log files is primarily rejected by our ethos and therefore not a part of our plans as of the time of this writing. If diagnostic is required, it will be implemented as a separate device that is read-only and properly secured, preferably using a symmetric scheme for this particular activity.
  • While current cars separate a number of specific networks responsible for different aspects of the vehicle's functionality, the role of particular ECU's in a car operation frequently makes such nodes viable "bridges" between otherwise separate networks. Provided it is determined necessary to have certain ECU's interface with more than one separate internal network, defenses in the form of limitation of transferability between networks based on need and type of information will be implemented. The directionality of the communication data will also be restricted based on such considerations.

Fly By Wire

Hardware Description

Powertrain

  • Ada will have an electric engine, driven by super-capacitors.

User Interface

  • We will devise a system of locking/unlocking the car incorporating key verification with forward secrecy, and utilizing a challenge exchange technique accompanied by a key response to the challenge exchange issued by the vehicle but based upon a non-proprietary algorithm. Data and logs of such authentication exchanges will be stored by the monitoring system in an encrypted volume.

Computation Hardware

  • The 'fly by wire' internal electronics system will be connected to the monitoring system only via a read-only connection, for logging and intrusion detection purposes.
  • In combination with strong transport and session layer security, a strong packet analysis/"IDS" hardware-based system, customized fire-walling within and around internal network structures, and finally read-only link directionality, the internal networks interfacing with external network structures/communication protocols will be designed in furtherance of our goals (see Telematics Unit,specifically)

Entertainment Systems

  • A reconfiguration of what has traditionally entailed the "Telematics" Unit will be necessary in order to reduce attack surfaces. We will have to manage more scrupulously the security of the communication protocols implemented, and limit the extent of its usability as an entry point in to other units within the vehicle.

  • A local copy of OpenStreetMaps? will be available for navigation. It will include routing algorithms that will not need to connect to existing cellular networks and will have to accomplish most navigation work on its own.
  • SIP services tied to the driver's ID should automatically connect using an encrypted WiFi? connection via VPN where available, but deferring to GSM over a VPN when wireless is unavailable.
  • The Telematics unit and endpoints for all communications !to/from the vehicle will be protected by firewalls and equipped to detect suspicious packet flows and malicious content.
  • A location obfuscation effort and communication protocol protects including strong encryption/anonymization efforts will be made.

  • There will be a user control interface for adjusting levels of security, setting protocol and external communication security preferences, and adjusting informed usability configuration.

Monitoring System

  • There will be cameras for recording traffic/law enforcement events. Data should be stored on an encrypted volume. Decryption keys will be kept on a separate piece of hardware, not in the car, available to the owner. Camera usage/functionality should be configurable according to the user's specifications.

Fly-By-Wire System

  • To minimize the available attack surface, the fly-by-wire network will utilize a wired network between the various computer components responsible for carrying out the collective functional needs of the car.

Internal Computer Network Security and Protocol Design

  • With respect to those ECU's comprising the fly-by-wire network and responsible for the vital operational concerns of the vehicle, communication will transpire in (layered) bare serial, with connectivity between ECU's existing for functional need, thereby minimizing excessive networking between unnecessary nodes and reducing the horizontal attack surface associated with a network consisting of indiscriminate wired and protocol-facilitated inter-connectivity between numerous, disparate nodes.

Proposed Hardware Communication Security for the Fly-By-Wire System

  • Generation of "Out of the Box" Public/Private? key pairs occurs automatically upon the first power-on of the vehicle, for each ECU.
    • Key generation will be confirmed to the owner/operator at each step of this initial exchange, and will preclude any possibility of prior access to key pairs after manufacture/prior to full possession.

Upon first initiation of a communication between two compute nodes, Compute Node A will deliver a hash along with a copy of its "OOB" (out of the box) Public Key. Upon Receiving this data, Compute Node B will check the Hash, then encipher Computer B's own OOB Public Key using Computer A's OOB Public Key, delivering it with a hash. After receiving Computer B's OOB Public Key/signature and checking integrity, Computer A will automatically generate a new, "session unique" Key pair. Next Computer A will deliver the newly generated session unique public key to Computer B by Using Computer B's OOB Public Key, along with a hash. Upon checking integrity and deciphering the New delivery, Computer A's new Session Unique Key will be used by Node B to encipher the public key belonging to a corresponding randomly generated session unique key pair of Computer B's own, The sessions keys between any given set of compute nodes will be considered valid until the next power-down of the vehicle.

We will also wrap the initial exchanges in an efficient symmetric key while it is transported between nodes along a secure protcol, e.g. similar to TLS). (Opaque Key Exchange effort)

Should malfunction/exploitation/parsing breakdown occur and cause the compute node to cease functioning, the fly-by-wire hardware set would require replacement in order to maintain consistency of connectivity rules between connected devices and key coordination.

*After Session Keys have been established, serial data delivered in the layered fashion described above will be transferred across a hard-wired network with limitations on connectivity based on need/functionality.

  • Known Plain Text Attack Protection: in order to protect against discerning keys via collecting an abundance of enciphered packets and divining the plain text via pattern recognition and signal predictability, we will send data across wires within packets containing noise to be enciphered along with the appropriate signal.

Note: We have considered a mutation of the infamous "boston brakes" scenario of compromising vehicle brake security via hardware switching/replacement. We understand the strong encryption system doesn't protect against such a break-in scenario, however we have at least raised the bar for such a theoretical attacker/attackers in that he/she/they would need to discern the private keys for the targeted ECU by forcing the EEPROM to reveal the out of the box key, an extremely taxing and resource-intensive operation.

When the machine is turned at the factory human infiltration remains a potential point of concern since the an employee could affect the OOB keys' generation by physically intercepting the random number generation on each ECU or else man in the middle-ing the wire, and then generating and substituting their own private/public key pairs to then be able to send data at leisure. This would need to occur the first time the system was assembled and turned on.

Luckily, we rely mostly on secure automation processes and have neuroses guiding our hiring practices that might best be characterized as "trust issues." And, regardless, we could always anonymize the destination/customer to whom an assembled vehicle will belong, or shuffle hardware kits (for the standard, most secure, and RECOMMENDED kit option at least) distribution during assembly. Home assembly (if so skilled) is always an option as well.

We are basically committed to preventing key access by our company, its employees, or any one else seeking such access without need.

If customers prefer to manage and flash their own cryptographic systems this option would be available via our customizable ordering system and alternative, more "tinker-friendly" hardware sets. Nonetheless the designs and structure and code underlying all options will be available freely.

Block/stream ciphers (particularly Helix/Phelix?) may come into consideration as algorithms in other aspects of this design process, however, for the fly-by-wire nodes, because we seek to limit unnecessary connectivity/communication potential between parts where it can be destructive and provides no benefit, a shared key amongst all ECU's on the fly-by-wire could prove to be a serious disadvantage in terms of the large numbers of ECU's which will ultimately cause the complexity of the exchange to mushroom, but also in order to facilitate restrictive communication permissions. Details on algorithm choices are tentative for the moment, as we want to bolster our ultimate decision in cipher choice by conducting scrupulous testing and comparison scenarios against our protocol and network design proposals in scenarios closely simulating our specific design and hardware implements. These tests will include testing for speed, CPU power consumption considerations, and many other operational considerations. We are particularly interested in efficient asymmetric algorithms Such as Elliptical Curve Cryptography due to its efficiency, however in the context of car infrastructure networks, this leaves the system particularly vulnerable to side- channel attacks including specific/differential power consumption attacks, and power-fault attacks involving deceptive inputs. However, we hope to at least make this more difficult using the aforementioned "random noise" method described in our general over of plain-text decipherment, a particular problem for cars sending relatively simple signals back and forth. In addition we will performing a variety of simply tasks to prevent, as much as possible, precarious and revealing forms of data/signal leakage of varying kinds, Finally, there have been rumors of NSA subversion with respect to the Dual EC DRBG specifically. Similar considerations are addressed in this paper:

FURTHER CONSIDERATIONS

  • White noise generators attached to the glass/windows
  • Specialized Firewall and IDS devices for Telematics Unit and other components accessible to external networks
  • Note: These outlines/preliminary specifications are broadly descriptive but change sometimes hourly. Patches/Security? Problems/Design? based vulnerabilities/bug reports/hardware fails/networking issues should be submitted to the specific design/code documents released as this project unfolds.

USER/CUSTOMER SPECIALIZATION/SPECIFICATION

  • Alterations to the proposed firmware, software, hardware, network design, (more) secure communication and reduced tracking features, or any aesthetic/personalization requests outlined by our signature design can potentially be accommodated. (or at your own leisure).
  • Should you be interested in appropriating/altering/tinkering/ or otherwise engaging in a *hands on* alteration effort, a request for parts will induce you to select between a set of options to select preferred hardware/firmware/software flexibility of the following kinds:
    1. secured according to our detailed model designed according to specifications we have detailed
    2. ordering our detailed outline but with "backdoor" hardware surfaces which enable flexible firmware reprogramming and other such undertakings. Such hardware devices will introduce and probably reduce the security of the design substantially, but allow for flexible reprogramming (if that's your thing).
    3. a "completely" unhardened set of components, implementing our design but without essential protection against vulnerabilities in attack surfaces, allowing pretty much any kind of shenanigans, exploration, and opportunities for entry.

Since our goal is to provide and outline the most secure way to construct cars in accordance with modern technological demands, we will accommodate such requests (and accommodate numerous others if physically/financially/ viable) in the spirit of encouraging freedom of software/hardware/open design.

HOWEVER: you are legally responsible for any vehicle safety issues arising from any of the above potential activities, and responsible for your use and any repercussions therefore with respect to improper vehicle safety as outlined by local law.

HELPFUL HACKING FOR OUR FOSS ETHOS

  • While we encourage use of the secure, default outlines we seek to provide, there exists the potential to discover vulnerabilities/unknown attack surfaces through !tinkering/alterations and we strongly encourage discovered hacks, but PRIMARILY those accomplished via our default designs, to be submitted as detailed bug reports or formal and detailed security flaw reports.

  • Attacks and Infiltrations accomplished via (B) or (C) type hardware (see above) are probably less useful to us, though may still be interesting, depending upon the nature/specifics of the attack. Unless your report illustrates an attack surface relevant to our specific model, it is probably less useful for improving the ultimate security and design of Ada/Fosscar? initiatives.
  • We are particularly interested in robust hardware vulnerability analysis and report, network-related vulnerabilities, bug reports and software patches, and ESPECIALLY: Telematics Unit Communication and Location Security compromises.

LINKS

---> https://github.com/fjvva/ecu-tool (ECU TOOL)

Last modified 2 years ago Last modified on 12/24/14 09:36:18