I have read research paper from University of California (Department of Information and Computer Science) written by Magda El Zarki, Sharad Mehrotra, Gene Tsudik and Nalini Venkatasubramanian which titled "
Security Issues in a Future Vehicular Network".
They have made an assumption that the security and privacy issues in vehicular network security are fairly common to most mobile and wireless network settings usch as authentication, data integrity, resistance to various denial-of-service attacks
and so forth.
In that paper, they highlighted a few important items for vehicular network security.
·
No confidentiality: the issue of data secrecy or confidentiality is not of concern in this network environment; none of the application scenarios we consider require any data to be kept secret. This is
quite unusual in mobile networks. For example, in
many modern cell phone networks (GSM, CDPD etc.) a secure channel is maintained between the cell phone and the nearest base station and/or local subscriber registry
·
No key distribution: most mobile network security architectures include provisions for key distribution. This is not only the case when an encrypted channel is set up; many settings require a key to be shared for authentication and data integrity reasons. In our case, key distribution is unnecessary for two reasons:
1) there will be no bulk data transmitted (on a continuous basis) either among cars
or between cars and roadside infrastructure, and,
2) vehicles traveling at high speeds (as most do on highways) will likely spend little time within a cell of a given base station. Also, vehicles communicating in
an ad hoc network broadcast their data, thus, pair-wise (or group-wise) key distribution is not needed.
·
No hand-over: typically, one of the notable security features of mobile networks is the secure hand-over protocol [3, 4], e.g., as a node moves from one cell to another, its state (including any on-going connection data) is handed over from one base station to the next. However, explicit hand-over is not needed if communication is largely one-way, i.e., vehicles reporting current speed and other parameters to the base stations.
·
No battery power concerns: this is actually the most important distinguishing factor of the network environment outlined in this proposal. In practically all mobile networks, power (CPU) consumption is a paramount concern. This includes not only power utilized for reception and transmission but also the power necessary to perform (usually expensive) cryptographic operations on weak and batterychallenged computing devices such as small PDAs, packet radios or cell phones. In our case, power consumption is not relevant since a running vehicle provides an ample source of battery power.
·
No CPU speed issues: a related concern in many mobile networks is the low CPU speed of the mobile node. Hence, there is usually a goal to minimize the use of cryptography because of the relatively long delays it imposes (e.g., an average Palm Pilot or Handspring PDA takes seconds to generate a digital signature). This often results in security protocols that are “contorted” to minimize the use of cryptography; sometimes, with disastrous consequences, e.g., the original GSM security architecture. Since “nodes” in our context are vehicles, more powerful (faster) CPUs can be assumed.
·
Extreme Time Sensitivity: as mentioned earlier, all data is very much time-sensitive. In applications such as VIVA, the needs for timeliness are only part of the problem. Time synchronization is also extremely important (although we can perhaps count on the GPS devices to provide accurate and uniform clock readings). Moreover, the system must be intolerant of replays (hostile and otherwise).
Taking the above differences into account leads us to a fairly simple security architecture with the following notable features:
·
Digital Signatures: we require all broadcasts in VIVA as well as all “reports” in HITCH to be digitally signed by the originating vehicle. Since each vehicle (and the roadside infrastructure) will receive many more messages that it will send, the cost of signature verification is of more importance than that of signature generation. Therefore, at least at the beginning, we are likely to use RSA-based digital signatures (as opposed to, say, DSA). Of course, an appropriate message and signature format will be defined.
·
Time-stamping and sequencing: all communication in both applications will include both sequence numbers as well as timestamps. Clock synchronization is a non-issue, for the time being, as all vehicles and fixed infrastructure components are (per our assumption) equipped with GPS receivers and GPS is also a time service.
·
Certification Infrastructure (PKI): public key digital signatures are not particularly useful without a certification infrastructure. Designing a nimble, scalable and secure PKI has been a major challenge in the last decade. (See, for example, IETF PKI efforts.) We must take into account the unique aspects of our network environment in designing an appropriate PKI. Moreover, there are some recent and promising results in cryptography that obviate the need to public key certificates. For example, the Boneh/Franklin identity-based encryption system is an elegant method of obtaining public key cryptography without any certificates: in it, an entity’s public key is derived from a unique identity string, e.g., an email address or X.500 distinguished name. (This could be a vehicle identification number, in their case.)
Linux is a hacker’s dream computer operating system. It supports tons of tools and utilities for cracking passwords, scanning network vulnerabilities, and detecting possible intrusions. I have here a collection of 10 of the best hacking and security software tools for Linux. Please always keep in mind that these tools are not meant to harm, but to protect.1. John the Ripper
