Friend-Foe Identification System

1. Friend-Foe Identification System Justin Ayvazian Eric Putney Ben Johnson Michael Ruth Advisor: Professor Sandip Kundu

2. Outline • Project Overview • Motivation • Problem Statement • System Design • System Diagrams and Operation • User and Data Flow Diagrams • Hardware Block Diagrams • Communication Scheme • Message Security • Password entry and transformation • RC5 • Project Progress • Graphical Interface and Vehicle Tracking • Prototype Implementation • Future Consideration

3. Motivation • 7,000 heavily armored Mine Resistant Ambush Protected (MRAP) vehicles transported into Iraq from 07’ to 08’ • Accounts for drop in deaths since 2007 • Vehicle hijackings and digital attacks more frequent as a result • Prominent in Afghanistan and Pakistan • 18 attacks on Pakistani soil, up to 13 vehicles hijacked per attack (From August to November of 07’) • Extrapolated,that’s over 2100 vehicles hijacked since August 07’ • Deaths per day due to Vehicle Bombings in Iraq

4. Problem Statement • Identify ground vehicles • Hijackings and bombings • Transmissions • Eavesdropping • Security • Digital Terrorism • Data Encryption and Decryption

5. System Overview

6. Requirements Specification • Vehicle mounted system • Power efficient, compact, and stand-alone • Identification and threat assessment of approaching vehicles • 2 mile range on base for adequate reaction time • Security • Secure transmissions • Prevent digital terrorism and impersonation of friendly vehicles • Password interface • Prevent unknown hijackings of military vehicles

7. Final Design Concept • Prototype system with limited range • Design hardware and communication modules, leave physical method of transmission up to end user • WiFi as wireless transmission method for prototype • Well defined standards, inexpensive implementation • Nios II FPGA Core • Run C control code on top of hardware modules • Ex: RC5 and WiFi Transmission

8. Scaling for Prototype • Time to react: 110 seconds for 2 mile range at 105 km/h • Range: 2 miles -> 100 m • Speed: 105 km/h -> 6.56 km/h • GUI Applet: Vehicle’s speed is 1.83 m/s

9. Outline • Project Overview • Motivation • Problem Statement • System Design • System Diagrams and Operation • User and Data Flow Diagrams • Hardware Block Diagrams • Communication Scheme • Message Security • Password entry and transformation • RC5 • Project Progress • Graphical Interface and Vehicle Tracking • Prototype Implementation • Future Consideration

10. User-Level Diagram

11. Data Flow Diagram

12. Interrogator Unit

13. Transponder Unit

14. Identification Process

15. Packet Structures 4 message types: Base Module: Request Identification Acknowledge ID/Update Randomization Value Vehicle Module: Transmit Identification Acknowledge Randomization Value Update

16. Outline • Project Overview • Motivation • Problem Statement • System Design • System Diagrams and Operation • User and Data Flow Diagrams • Hardware Block Diagrams • Communication Scheme • Message Security • Password entry and transformation • RC5 • Project Progress • Graphical Interface and Vehicle Tracking • Prototype Implementation • Future Consideration

17. Password Transformation • Why do passwords need to be transformed? • Avoid physical keys, use shared password • Future messages with same vehicle will be unique • Implementation • Shared 16 bit password for all vehicles • Multiply by randomly generated 16-bit number • 232 possible values • “Three strikes rule” - ~ 5x10-3 % chance of correctly guessing password even if all other parts of the system have been compromised

18. Randomization Value Updating • Updated through rolling encryption scheme • Similar to system used for remote entry devices for cars • Last message from base to vehicle sends new randomization value • Generated by base, stored by both vehicle and base • Base stores current value and previous value of randomization values • Final message is vehicle to base • Base must store both in case final transmission not received by base but is sent by vehicle

19. Message Encryption • Encryption Requirements • Real-time ciphering • Robust algorithm to prevent cryptanalysis • RC5 • Parameter-Based Symmetric Block Cipher • Adaptable for speed and encryption strength • Lightweight encryption algorithm  FAST • Performs word-oriented operations  FAST

20. RC5 Encryption Module Initial C-based implementation—Completed Timing trials from 32-bit XP OS, running on a 1.83 GHz processor. Future Verilog implementation Timing Expectations Algorithm requirements: Strong Security Data Dependant rotations Fast Encryption, Decryption, and Key Expansion

21. RC5—Security Strength Several strategies for breaking block cipher: Exhaustive search Statistical tests Linear Cryptanalysis Differential Cryptanalysis Best public attack a variant of differential cryptanalysis Still requires unreasonable amounts of plaintext/ciphertext pairs

22. RC5—Security Strength (cont.) Data Dependent Rotations Helps protect against differential cryptanalysis Coupled with the use of the password transformation, identical messages will have different ciphertexts Prevents Timing analysis Strength against other known cryptanalysis methods Linear Exhaustive 2Bits_in_key attempts Statistical Data-dependent rotations/password randomization

23. RC5—Operation Speed Real-time requirement for transmissions Speed Results for RC5 – 32/12/16 What if we increase the number of rounds? Achieves ≈220μs Key Expansion with 2000 rounds Hypothesis: Verilog implementation will be more efficient than C

24. Outline • Project Overview • Motivation • Problem Statement • System Design • System Diagrams and Operation • User and Data Flow Diagrams • Hardware Block Diagrams • Communication Scheme • Message Security • Password entry and transformation • RC5 • Project Progress • Graphical Interface and Vehicle Tracking • Prototype Implementation • Future Consideration

25. Interrogator User Interface • Output on the base module will be a GUI using a Google Maps overlay • Present • Used the longitude and latitude for UMass in demo • 100 meters at UMass longitude is .001270 • 100 meters at UMass latitude is .0010 • Range of base station is 100 meters • Future • Will be putting the GUI in an applet – need to acquire license from Google • Simulated path based on normal UMass walkways will be used for demos– need GPS module before data can be taken

26. Interrogator User Interface

27. Prototype Progress • Transponder Unit (Vehicle): • RC5 • Message encryption and decryption • Key table generation • Control Module • Data parsing & concatenation • Interrogator Unit (Base Station): • RC5 • Message encryption and decryption • Key table generation • Control Module • Data parsing & concatenation • GUI implementation

28. Future Deliverables Working Model • C and Verilog code • GUI • Implemented RC5 encryption scheme • Full Communication Between: • GPS and Vehicle via USB • Vehicle and Base Station via 802.11 protocols • Base Station and GUI via USB Equipment • GPS via USB port • WiFi Transceivers via USB ports • Altera DE2 Boards

29. Future Considerations • Ad Hoc networking • Allow vehicles to identify one another away from base • Enhanced driver identification system • Increased protection against hijackings • Example: fingerprint scan • More specific to military personnel • Anti-jamming • Switch between 802.11 b and 802.11 g to prevent narrow band jamming

30. Questions?

31. Sources [1] B. Kaliski, Y. Yin. On the Security of the RC5 Encryption Algorithm. v1.0, September 1998. Available at ftp://ftp.rsasecurity.com/pub/rsalabs/rc5/rc5-report.pdf. [2] R. Rivest. The RC5 Encryption Algorithm. March 20, 1997. Available at http://people.csail.mit.edu/rivest/Rivest- TheRC5EncryptionAlgorithm. [3] R. Rivest. The RC5 Algorithm. Dr. Dobbs Journal number 226, pages 146-148. January 1995. Available at http://people.csail.mit.edu/rivest/Rivest-rc5rev.pdf