View Paper - Targeted Encryption Device
Contents
1. a 4 or Product Requirements 6 Hi Ree MEI aces ie tete veil hn nicis iet vatis iet i vatis eA 6 gt eR Ce i iai ach embed Eh k a i pa E i 6 3 3 Performance Timing Requirements i delet i a i a pde sedebat raul 6 34 Implementation Resteletlotiscnaaeseneadent o ie po erbe eR RES re EA i a 6 2 TRED o shit notru te Reb A Cre a menit tati EE A 7 5 Detaled Destinasi eiie eR i a ettet cis t 10 MES II e EET 10 2427 AMMA ONG Sca a i aa i i a i 10 Sd Operator 10 vM opi PE METTE 10 5 3 1 Cryptographic Modules icit dto iae acido a b EU i En p Fia r 10 5 3 1 1 Cryptographic Design SDECIHC OBL ais i QA i i i ex y 10 53 12 SGryptoeraphie auci terea i eed n b e i a a i ber EA 10 5 9913 Internal Structite ass Pt a hebt ia 12 DOT caes i RO IN OR SV NU NEU M d 12 531 93 teat Ecsta a a a QR al a i a a CORO ed 14 5 3 5 CPU Memory Module ati o ERI iai i ORE M a 14 594 1 CPU Memory Design SDEGICAGOEBa sea i i i i i Re 14 29 222 Memory Desi hi icit upinis a a hd is a 14 52 45 Internal a ii i i e i a a Ei i a i tes 16 S S d acu a I 18 5 9 25 np ii ieina ii e i K i2. w o Normalized Ted Inline 7 x 3 3 o 100 1000 10000 100000 File Size KB Figure 7 1 Comparison of Bandwidth with and without TED 7 1 2 Latency Test The latency was measured using the ping command Sample sizes were between 200 and 300 pings with the average ping time shown in figure 7 2 Even the largest packet size only delays the latency by 1ms well below the timing requirement of PR 02 of a 10ms delay traversing through the ted 30 Latency of Variable Packet Size Ted Inline Normalized vo E gt 4 l 128 1024 Packet Size Bytes Figure 7 2 Latency of Variable Packet Size 7 1 3 Duplexity Test As part of IEEE 802 3 standard auto negotiation of the end stations are successfully connecting with a full duplex connection at 100 Mbps satisfying IR 01 Duplexity 7 1 4 NAT Test Requirement IR 02 NAT Transversal outlined that the TED must survive static NAT transversal The NAT function of the TED was built into the target design This means that NAT configuration on the TED is a function of how the targets are applied to each packet When NAT is enabled the trigger for the decrypt is now a result of the source and destination IP addresses If a packet is received on a TED and the source IP address was the public IP address of the sending TED and the destination is for the private IP address The major
3. AE EAT GUI cU i L NEHME NE 30 Ud Administration Panel Testi oi edel oie nia n b lei EE 30 8 BUmifigt asus odit du RTE Re room o a dU ca Edel HL OR a C VO Nu 32 9 te odd i a OE eite bugs 33 10 DISCUS SUT E 34 10 1 PR 04 e ERO d Eos que det due i a i a DC a a 34 10 2 Major Challenge and Lessons Leattied ia iet stitit Ee nnde eie ti em e edente 34 11 patire Wall a acad 35 11 1 Giyptographic Cipher d PALOS caet gode hit tener enter 35 Hl Packet Processiie habui a dai a td a Ai 35 ANEXE S es S RAUS a ean efr p O TIDAL a i S NS 36 Annex A Additional Diagrams and m atit ma a i a i pun T du oblitus 36 List of Figures and Tables Figure 1 1 TED lini lenient ta Onn cech eei E Pu taie i at ed e T 1 Pappe 4 1 Architectur e tul ratae i UR TR 7 Figure 4 2 Altera Hardware Software Tool Suite Yi ii i i i i 8 Pisure 4 5 FED Development oan mta ca ada distat Ra ura atau tater 9 Figure 5 1 Demonstration of Weak Cryptographic Hash 11 Figure 5 2 Encryption Structure Tora Block Chain Ciphet uni oo ena teni das 11 Fig
4. STD LOGIC VECTOR DOWNTO DRAM DQ 15 0 DRAM DOMO DRAM Other Control Signals DRAM CKE DRAM CLK DRAM WE N DRAM CAS N DRAM RAS N DRAM CS N DRAM BA 1 0 DRAM ADDR 12 0 I DRAM DQ 31 16 D 15 0 LDQM DRAM_DQM3 UDQM Figure 5 23 SDRAM Interface 28 6 Equipment The equipment that was used for testing and development is categorized in Table 6 1 Table 6 1 Final Project Equipment List Function 2 Terasic DE2 115 Development Board TED 2 Raspberry Pi Model B Red Setver User 5 amp Black Sensor 2 Cisco 2960G Catalyst Switch Network Distribution 1 Cisco 2600 Router Network Routing 29 7 Results 7 1 Testing 711 Bandwidth Test To measure the bandwidth of the TED and demonstrate PR 01 100Mbps throughput we used the SCP protocol in verbose mode This method would have consistent overheads for both configurations and provide a detailed report once the file was transferred The smaller file sizes showed no significant difference in throughput however as the file size increased the throughput settled at approximately 20 Mbps We believe this is due to an interrupt running on the FGPA The FPGA must be connected via USB at all times to the Quartus software This is a restriction enforced with the particular license we are using Since we are showing no lag times in latency and smaller packet transfers we believe this assumption is well founded Sustained Network Throughput
5. char int natEncrypt TARGET char int packet pointer void ipiip efh eth Outgoing Memory tanstan h lt lt Initiates gt gt gt gt headNumber TARGET GetNextPacket void void SendPacketBlack void void SendPacketRed void void A AddLayer3Option chac ChangeLayec3Size char char NatPortChange char Incoming Memory lt lt Initiates gt gt SetKey Value c void AddTarget char 4 void SetOperation Mode int void Figure 5 9 Packet Processor Structure Figure 5 10 is the data structure of the packet processor In order to dissect a packet a series of buffers are taken relative to where the packet pointer is located in the code ANSI C is not an object orientated language however utilizing the struct type it is possible to create some reusability within the code Structs allow us to apply a rigid template to place over each packet which make the code very stream lined and much more manageable than bit masking or void pointers The other data type is the TARGET type which is a linked list This allows the packet processor to perform lookups on the targets that will flag the TED when a packet requires encryption or decryption packet pointer void ip ip h eth eth h tran tran h headNumber TARGET lt lt TARGET gt gt
6. L 1 1 S S Outgoing Memory Incoming Memory 16kB 16kB Figure 4 1 Architecture Model The architecture of the TED will be realized within software Integrated Development Environments IDE will be used to translate software code into hardware builds The programs that we will employ are summarized below Quartus II software will be used to write all custom hardware interface modules using very high speed integrated circuit hardware description language VHDL These modules will be defined using the Avalon interface specification which is an open source interface specification used by the standard central processing unit CPU and peripherals included with the Altera suite QSYS is used to incorporate standard modules such as on chip FPGA random access memory RAM read only memory ROM a NIOS II standard processor as well as any custom modules that we define for the TED OSYS also creates a memory map for all I O and peripherals assignment of interrupt priorities as well as defining a system interconnect bus that takes care of the creation of chip select signals for various peripherals allowing for ease of our design of the TED as that is not included in our scope Finally after our hardware design is compiled and downloaded to our target board the NIOS II software build tools SBT will be used to program hardware drivers for our peripherals DMA control algorithms and deep packet inspection and packet process
7. TARGET TAG target Number int stcHost char 4 dstHost char 4 srcPort char 2 dstPort char 2 nest Target Number struct GetNextPacket void void SendPacketBlack void void SendPacketRed void void lt lt eth_h gt gt ethemetHeader 4 eth src char 6 eth dst char G lt lt ip h gt gt internetHeader verlHL char 1 totalLength char 2 ipBuff char G ipChkSm char 2 ip src char 4 ip dst char 4 lt lt tran_h gt gt transportHeader src port char 2 dst port char 2 tepBuff char 8 tcp length 1 Figure 5 10 Packet Processor Data Structure 5 3 2 4 Operation Figure 5 11 shows the dynamic view of the lifetime of a packet as it transverses the packet processor 18 a See Se eee Wait for Packet Packet Dissection Get Headers Get Packet Next Packet 23 Lookup Targets Dissect Packet NC Get Interface crypt Output Input M Copy IP ID Y Interface received S Get Data Block Black Red Encrypt Data Contents Decrypt Data Contents Output on Red TX Q Output on Black Tx Figure 5 11 Packet Processor Flow Diagram 5 3 2 5 Error Handling The module relies on the end points for error detection and correction If the TED
8. 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Sequence Number Acknowledgement Number Flags Window Size Checksum Urgent Pointer Figure 5 5 TCP Header 01 2 3 4 5 6 7 8 910411 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 3031 Figure 5 6 UDP Header Figures 5 7 and 5 8 show a graphical view of the packet prior to entering the packet processor and the boundaries that are created once it leaves the packet processor respectively 0000 0010 0020 0030 0040 0050 0060 0070 0080 0090 0100 0110 0120 0130 Figure 5 7 Packet Processor Initial View 9 A B D E F 0010 zi 91 574 009 Fa IE 0030 0040 0050 0060 0070 0080 0090 0100 0110 0120 0130 Figure 5 8 Packet Parser Final View 5 3 2 3 Internal Structure Figure 5 9 shows the function relationships of the software All the code inside NIOS II block is part of the packet processor written entirely with ANSI C The relationships that move across the boundaries are VHDL functions 16 17 NIOS 2 Processor Crypt DMA Crypt DecryptCheck T portDecrypt TARGET c ipDeerypt TARGET char int natDecrypt TAR char int EnayptCheck 1 I 1 lt lt CryptComglete gt gt portErerypt Ts char int ipEmypt TARGET
9. area network light emitting diode liguid crystal display media access controller media independent interface memory mapped network address translation physical layer interface chip random access memory read only memory start of packet software build tools Altera Inc proprietary Eclipse distribution synchronous dynamic random access memory targeted encryption device very high speed integrated circuit hardware description language virtual private network vii 1 Introduction 1 1 Document purpose This document will describe the design of our project the Targeted Encryption Device TED It will describe what engineering problems were faced how we approached these problems and how we solved these problems This paper will also define the requirements of this device and present the testing to support that the requirements were met 1 2 Background A Targeted Encryption Device is a hardware implementation that will secure network data communication between itself and another TED which are used as a pair between two secure endpoints Figure 1 1 shows how the TED will operate inside a simple network The TED will not be addressable on the network and will be transparent in the network communication process User 1 s premises Regular User 1 Administrative User 2 Regular User 3 Administrative User 4 Figure 1 1 TED Implementation Virtual private networks VPN are currently the most common
10. causes and error it will rely on the station to request the entire packet as indicated by the TCP sequence numbers 5 3 2 6 Miscellaneous The packet processor also handles administration functions for the TED The TED will be looking for a very specific UDP packet destined for IP address 10 10 10 10 with a payload that defines the key value and three four tuples of trigger information Source and destination IP address as well as source and destination port numbers The data format for the administration packet will have the following structure 1 56 bit Key Value 2 Target 1 Target 2 Target 3 20 Figure 5 12 shows the allocation of the key and four tuple data structure 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 1615 1413 121110 9 8 7 6 5 4 3 2 1 0 56 bit key 0000 0010 0020 0030 0040 0050 0060 8 bit Align Buffer IP Destination Target 42 IP Source Port Source 2 Target 2 Port Destination 2 n Target 3 1 Figure 5 12 Admin Packet Data Structure Received configurations will not be appended Each configuration packet received will replace the old configuration in its entirety 5 3 5 DMA Module 5 3 3 1 DMA Design Specification The DMA modules inside the TED must be able to interface with the Avalon bus communication protocol In addition they must be able to transfer data independently of the processor with a minimum of intervention using either memory map
11. field programmable gate array FPGA will be used to buffer packets coming in and out of a secure end point During this buffer the FGPA will process all packets to determine if a packet is flagged for encryption decryption If flagged the FGPA will encrypt decrypt the packet and retransmit the packet IMP 02 FPGA Software This project will require the use of a hardware description language HDL capable of configuring an FPGA IMP 03 Custom Cryptographic Module The cryptographic module will be a custom design based on the request of the customer 4 TED Architecture The FPGA platform being used is the Terasic DE2 115 board that utilizes a Cyclone IV FPGA chip from the manufacturer Altera The architecture model of the DE 115 is shown in figure 4 1 The NIOS processor will be running our designed packet processing software that will perform deep packet inspection of every single packet that moves through the TED The Encryption and Decryption DMA modules consist of a designed DMA and a designed cryptographic block cipher The design of the DMA is meant to provide the cryptographic cipher with a way to interface with the packet processor in a way that will be much faster than with the CPU tcm PIO Input SWs T 1 T T r S MI I j Triple Speed Ethernet Triple Speed Ethernet M LCD PIO Output LEDs Data Memory idt Instruction Memory asnaviva osnaviva CUSTOM
12. gt DMA Figure 5 14 Typical DMA Transfer of Control Incoming Figure 5 14 shows the life of a packet as it is received on the red receive interface The design uses the streaming to MM DMA in order to move the data to one of sixteen 2048 byte blocks of memory that are allotted by a linked list structure While it is stored in the linked list structure the packet processor software function will inspect the packet and determine if it is and administration packet from the administration graphical user interface GUI coming from a 22 paired location protected by another TED and must be decrypted or a packet that is simply actively ignored Once the packet processor makes the determination of a decryptable packet it will trigger the decryption MM MM DMA and then the red transmit MM to streaming DMA If the packet is to be actively ignored it is sent to the red transmit interface by its MM to streaming DMA If the packet is an administration packet the packet processor will use deep packet inspection to read the configuration data set its registers appropriately and then return the block of memory to the pool available for packet reception on the red receive interface Outgoing Memory Y Encryption DMA Black Tx lt DMA List Structure Red Rx H DMA Figure 5 15 Typical DMA Transfer of Control Outgoing Figure 5 15
13. memory block 21 6 Decryption This required the use of a MM to MM DMA in order to read encrypt and write sequential data located in the incoming memory block 20kB 300kB DATABUS A iS iS Triple Speed Ethernet Triple Speed Ethernet LCD PIO Output LEDs Data Memory Instruction Memory PIO Input SWs 8snaviva osnaviva WIN 8 8 1 Outgoing Memory incoming Memory 16kB 16kB Figure 5 13 DMA members 5 3 3 3 Internal Structure Figure 5 13 shows the life of a packet as it is received on the black receive interface Specifically our design uses the streaming to MM DMA in order to move the data to one of sixteen 2048 byte blocks of memory that are allotted by a linked list structure While it is stored in the linked list structure the packet processor software function will inspect the packet and determine if it is coming from a paired location protected by another TED and must be decrypted or a packet that is simply actively ignored Once the packet processor makes the determination of a decryptable packet it will trigger the decryption MM MM DMA and then the red transmit MM to streaming DMA If the packet is to be actively ignored it is simply sent to the red transmit interface by its MM to streaming DMA Incoming Memory Y Decryption DMA Red Tx 2 DMA List Structure Black Rx
14. n E i a Pe eda 19 a S ka a 19 DMA MEN as ai i eodeni E i tb a tec 20 S OUT DMA ES SAS DEC EASA belit Sin diate a 20 bouis OMA a a o tans 20 5 9 9 3 Internal SIPC LI Ee cts ids xe cua 21 Dub VEOBGEALIOB ndo tu e 22 5385 Handling ties deed tis rie a eu Cete e RE Hes 25 5 3 4 Parallel Module ee eedem tere 23 5 3 4 1 Parallel T O Desion SpecitiCatIOfta uma mh a i i HA d T NU ud 23 Dos cParallel T O DESI ia iii i otia do cbr i lr Reds bn eb nora uude 24 5343 merda SEL amies hei iii a iii 24 54 2 Intertace D schptonsu ski ks iai i i i k i e d i e i i el E d eR 24 5 4 1 Pel ey Tbe RA apta soe ee a a ebd cunt 25 5427 25 LED iii ai i i i i i i 25 MER Cr rig 26 5452 SDRAM dam abi feli 27 aaa nee ne ee LU wr SM d NE E 28 hi oru P 20 Td USES EIN ecd nt m Rte a A terat inte 29 7 14 Bandwidth oin ae eta ie 29 7 42 29 ply 30
15. shows the linked list structure that controls the organization and allotment of the sixteen 2048 byte packet buffers in both the incoming and outgoing memory blocks Nodes on the below linked lists that maintain packet information and pointers to the specific bufferare moved from list to list when buffers are allocated for frame reception received a frame inspected encrypted decrypted prepared for transmission transmitted and then made available again Available Receive 16 Blocks of 2048 bytes Inspect Control Transmit Only Possible on the Red Interface Figure 5 16 Packet Buffer Linked Lists 5 3 3 4 Operation Several approaches were assessed in order to control the operation of the DMAs and flow of packets in two directions at once Initially attempts were made to use a zero size main loop and rely on interrupts to trigger specific code blocks in the event of frame reception encryption and frame transmission etc Early design efforts failed in that due to the sheer number of interrupts generated the processor was overwhelmed with the amount of context switching that must take place on each interrupt and was unable to operate in a meaningful way The ultimate design uses a super loop in the 23 main function that polls each linked list in turn performs specific operations on tha
16. solution to secure communications between two endpoints Often these endpoints require the same protocol configuration and encryption to speak to each other VPNs that run on an operating system have an inherit risk that some information intended to be secured was not There are a number of flaws as a result of this implementation The major flaws that we intend to address are the following memory leaks from software running on the secure endpoint detection of the VPN signature by packet signature categorization and or an accidental plaintext transmission The TED will overcome these limitations and vulnerabilities associated with VPN software by abstracting the encryption and configuration from secure endpoints to our proposed hardware solution 1 21 Proposed Use Cases The four proposed use cases will be described in reference to Figure 1 1 1 2 11 Secure Endpoint 2 to Secure Endpoint 4 The main use case describes two separate secure endpoints secure endpoint 2 and secure endpoint 4 whose network traffic will be encrypted by two TEDs All network traffic originating from secure endpoint 2 will be received by TED A through the red interface TED A will then inspect the details of each frame of data and then choose to encrypt the layer 3 payload and retransmit the frame The destination is secure endpoint 4 the layer 3 payload is then encrypted and a new layer 4 header is generated and inserted into the frame along with the encrypted
17. 3 Internal Structure Referring to Figure 5 3 and Figure 5 4 for encryption and decryption our cryptographic design is placed within the cipher block Figures A 1 and A 2 in Annex A below show the encryption and decryption models for how the algorithm is applied within the cipher block 5 3 1 4 Operation The requirements of the cipher mentioned earlier in the paper outlined the importance of hashing and data repetition The application of the cipher was on a pet packet basis This means that the first 32 bits of each packet will be block 0 and each packet would have a different salt value To demonstrate the importance of this some sample sets of data are shown to highlight the importance of these requirements For the following tables the following sets of data were used e Plaintext Contents aaaa aaaa aaaa aaaa aaaa 5 32 bit blocks of ASCII a Ascii Hex Code for a 0x61 e Salt 1 x47112015 e Salt 2 x20154711 Table 5 1 shows the result of the cipher with no salt and no rotation The final hash of this packet is 988F3FF9 This hash was produced in this mode every single time it processed a packet with the same data Also the values after each block is processed cancel each other out As the cipher text from a preceding block is passed to the next block it reverses the operation performed on it As a result we are left with a hash that is only one operation away from decryption Table 5 1 Cipher Output with no Salt or R
18. Royal Military College of Canada Department of Electrical and Computer Engineering Detailed Design Document EEE455 457 DID 07 for Targeted Encryption Device NCdt Blake Mackey OCdt Jason Leverton Project EEE GEF 455 457 15 13 Supervisor Dr Sylvain Leblanc Project Manager Maj Randy Hartman 1 April 2015 Table of Contents Table AE Contents p qp rp i ATL D3blese asai i a v List of A DDEOVIAUGHS a tet bud teu vii 1 Ll BDocument Purposes eeu pesa tus d 1 12 BackptOUtdu ete aee ea epe ro ter Gin dab Me EA OE Gb a onan beh 1 KZA Proposed Use Go date a Da a PR eT Und p ghe ian 1 L2 LT Secure Endpoint 2 to Secure Endpoint Asia kia siai ika ii tio ca 2 1 2 1 2 Secure Endpoint 2 to Non Secure Endpoint 3n ues os aa derer a 2 12123 Non Secure Endpoint 1 to Secure Etdpotnt4d Liss is a taedet de du i ste 2 1 2 1 4 Non Secure Endpoint 1 to Non Secure Endpoint 3 ids iii as a i a oiii 2 SUI S alias L ion a tetas i 2 142 SIA DE siais tidie tuin tie e i i 2 TAT lt ac mde i a edu 3 2 Applicable DOcuIMents Idi e kiai ii ei
19. This would be made up of 3 parts 1 8 bit key bits 55 downto 48 2 16 bit key bits 47 downto 32 3 32 bit key bits 31 downto 0 The purpose of this key arrangement was to ensure that during key generation an 8 bit pattern was left unmasked which follows that each of the keys must not equal zero during generation The requirement that each packet must produce a different cryptographic hash is a very common issue with block ciphers Figure 5 1 demonstrates visually the side effect of having the same hash function for each packet The left image is the source the middle image is with no salt and the final image is the desired end state 11 ANE Figure 5 1 Demonstration of Weak Cryptographic Hash The solution to this requirement is to introduce a unique value that would pair with the encryption key to produce a variation in the hash This variation value is known as a salt The salt that we used for each packet was derived from the identification value found within the layer IP header This is a 16 bit value so it was expanded with itself in order to provide a 32 bit salt An identification value of OXE74b will result in a 32 bit salt of OXE74bE74b The 32 bit salt would only be used to provide the first initialization vector IV Each subsequent block will be salted by the cryptographic hash of the preceding block as shown in figure 5 2 Figure 5 3 shows the decryption model notice that the major difference between the two
20. X 6 4 LED RX ENETO RX DV ENETO DUPLEX INDE SYN 4 KW LEO DUPLEX ENETO RX ER A RX ER LED LINK1000 ENETO RX CRS ENETO LINK 100 eos LED LINK100 ENETO RX COL ENETO LINK 10 COL LEO LINK10 E meno ENETO INT N JP1 INT n 3 ENETO RST N Mii MODE K hos n CONFIG4 2 MODE 25 XTAL 98 1111 Figure 5 18 Ethernet Interfaces 26 The external LCD interface will be controlled by FPGA signals of the type STD LOGIC and are wired directly to certain pins on the FPGA as described in figure 4 8 0 1 0 021 9vivo 021 2 5 5 Figure 5 19 LCD Interface 5 4 4 Parallel I O The parallel interface has two function controlled by the memory mapped interface to the CPU It reads information from switches and displays discrete information on LEDs All signals are of the type STD LOGIC whether they are to or from the FPGA as shown in figures 4 9 and 4 10 AB28 As AC28 AA22 AD27 AC27 T T Swi7 SW16 SW15 SW14 1 0 Figure 5 20 DE 115 Switches Interface LEDR14 LEDR15 LEDR16 LEDR17 Figure 5 22 DE 115 Switches Interface 5 4 5 SDRAM The SDRAM interface in figure 4 10 provides access to 128MB of external RAM in the form of two external 64MB chips that are wired to a 32bit high low half word configuration All signals communicating to the SDRAM are of the type STD LOGIC or
21. acket is ready for inspection from MAC controller The value is passed to the packet processor as a void pointer that represents the start of the packet Initially the packet shows up as a block of data and the end state is to return whether or not to encrypt the packet and which interface to send the packet on 5 3 2 2 CPU Memory Design 15 The function of the packet processor will be a relative bit offset from the initial byte of the packet Each packet will have constants that can be relied upon Figures 5 4 shows the Ethernet and IPv4 pairing that is expected The packet processor will be looking for this packet and if it does not see it it will forward the traffic without further processing The dark fields denote a portion of the header that we use to perform the relative bit offset mechanic that allows us to deconstruct the packet 01234567 8 91011 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Word Offset Source Mac Address Destination Mac Address Layer 2 Protocol dg nid Identification Fragment Offset L4 Protocol Header Checksum Destination IP Options Optional Figure 5 4 Ethernet and IPv4 Headers Figure 5 5 and 5 6 show the only choice point we enter into with our program Once an Ethernet and IPv4 packet are confirmed the next layer expected is a TCP or UDP packet If neither is found the packet is forwarded without further processing 01 2 3 4 5 6 7 8 9101112 13 14 15 16
22. air of TEDs capable of operating in line between a secure endpoint and a gateway to provide a secure method of network communication The intent is to abstract the encryption and configuration from secure endpoints In order to provide transparent operation our solution must be able to process the data coming from a secure endpoint determine if it is destined for its pair and whether to encrypt or actively ignore and then retransmit the frame through the black interface to the gateway and the inverse is true of decryption 1 4 Scope 14 1 TED Capabilities The TED encrypts network traffic with a custom cryptographic module A custom cryptographic module presents a lower attack vector than an open source cipher due to its less commonly used nature and the non readily available tools and scripts for decryption The downside of a custom designed cryptographic module is the lack of any formal peer review or validation process system design is modular so alternate block ciphers can be used in place of the custom cryptographic module The TED operates transparently on any Ethernet switched local area network LAN In line operation between a secure endpoint and gateway ensures all network traffic generated by or destined for the secure endpoint will be intercepted by the applicable red or black interface of the TED This eliminates the need for addressable interfaces The TED operates across network address translation NAT con
23. d as detailed in figure 5 10 25 Terasic DE2 115 Development Board 2x Ethernet RJ 45 2x Marvell 88E1111 PHY Altera Cyclone IV FPGA 2x20 LCD Display 128MB SDRAM aa 18 Switches 4 PBs 26 LEDS Ib nnn Figure 5 17 Terasic DE2 115 Development Board Interfaces 5 4 1 All FPGA Internal Interfaces All internal FPGA interfaces will be of the signal type STD LOGIC or STD LOGIC VECTOR DOWNTO specified by the IEEE VHDL libraries included in the Quartus II software and they will conform to the Avalon open source interface specification that is primarily used by Altera This interface specification allows the Qsys software to map and create the proper module interconnection logic and relieve the overhead from the programming team 5 4 2 Ethernet The external Ethernet interfaces in figure 4 7 are identical and are copper Ethernet RJ 45 connections communicating over twisted pair CAT 5 wiring The internal interface between the FPGA and Marvell 88e1111 PHY are of the type STD_LOGIC or STD_LOGIC_VECTOR 3 DOWNTO 0 as well as an on board oscillator used by the PHY 5 4 3 LCD ENETO U8 J4 ENETO TX 0 0 P ENETO GTX CLK re GTX CLK ENETO TX CLK TX CLK ENETO TX TX EN ENETO TX ER 2 5 LI TX ER ENETO RX DATA 3 0 ENETO LED TX FUCOATAD 0 LED TX NNI WV ENETO RX CLK ENETO LED R
24. difference between NAT operation and normal operation is to know that static NAT is being used and to know the public IP addresses of each network 7 1 5 Administration Panel Test Requirement IR 03 Administration Interface outlined a secure user that was able to change the key and target settings of the TED Section 5 3 3 6 outlined the structure of how the TED would process this data It would require the key followed by the 4 tuple of the source and destination IP port pairings This configuration was completed as a java swing GUI The information was sent to the TED as a UDP datagram with the payload being a character buffer of all the configuration changes being sent to the device Figure 7 2 shows the GUI configuration and figure 7 5 shows the resultant JPanel Demo Program TED Configuration Panel Key Value 0x123456ABCDEF 123456ABCDEF Target Source IP 1 a0a0a0a0 Target Destination IP 1 12121212 Target Source Port 1 0050 Target Destination Port 1 1255 Target Source IP 2 0 0 01 Target Destination IP 2 00000000 Target Source Port 2 0017 Target Destination Port 2 0000 Target Source IP 3 08080808 Target Destination IP 3 00000000 Target Source Port 3 0100 Target Destination Port 3 0400 Figure 3 3 TED Administration GUI Figure 7 4 TED UDP Administration Packet 31 32 8 Summary The purpose of this
25. evice We were trading a usage characteristic ie Traffic over port 23 can be characterized as telnet traffic for an absolute signature For this reason we only encrypt the entire transport layer payload and leave the transport layer as is 10 2 Major Challenge and Lessons Learned Hardware implementation was the major challenge of this project There were specific ways that the board allowed us to interface with the data We required precise control over the bits that were entering the FPGA We used a relative bit offset mechanism to perform deep packet inspection and knowing the exact address of each bit was crucial This piece alone accounted for the majority of all the work hours on this project The lesson learned from this challenge was to give more respect to the proprietary software that is packaged with FPGA boards We invested many hours to determine the raw specs of the FGPA that would meet our design requirements instead we should have researched the tools and software that fit our project 35 11 Future Work 11 1 Cryptographic Cipher Iterations Additional iterations of our designed cipher are needed There is a currently weakness in our implementation that can exploit the fact that the blocks are processed in the same way each time If data is known to occur in the first 4 bytes of the packet the key and salt pairing can be easily extracted against a brute force attack 1 2 Packet Processing Depth The packet proces
26. figured networks The knowledge of the public IP addresses for each host is required 2 Applicable Documents 1 DE2 115 User Manual 1 Jan 2010 Altera Inc Web 5 Nov 2014 lt ftp ftp altera com up pub Altera Material 12 1 Boards DE2 115 DE2 115 User Manual pdf gt This user manual was used in order to configure and use the FPGA development board for the TED the Terasic DE2 115 2 IEEE Working Group IEEE 802 3 ETHERNET IEEE 802 3 ETHERNET IEEE 23 Aug 2014 Web 7 Sept 2014 lt http www icee802 0rg 3 gt The 802 3 standard was used to deconstruct Ethernet frames into the different layers as well to implement full duplex and half duplex flow control into the TED red and black interfaces 3 IETF RFC 793 Transmission Control Protocol RFC 793 Transmission Control Protocol 1 Sept 1981 Web 7 Sept 2014 http tools ietf org html rfc7937 RFC 793 was used specifically to determine the layer four header structure as it relates to TCP in order to perform deep packet inspection of TCP IP packets 4 IETF RFC 791 Internet Protocol RFC 791 Internet Protocol IETF 1 Sept 1981 Web 7 Sept 2014 http tools iet org html rfc7917 RFC 791 was used in order to determine the layer three header structure as it relates to IP in order to perform deep packet inspection of IP packets 5 Nios II Software Developer s Handbook 13 June 2013 Web 9 Nov 2014 lt www altera com
27. ing The language used in the SBT is C and the environment is a custom Eclipse distribution Figure 4 2 provides a summary of each program and the modules that will use them Altera Hardware Software Co Development Tool Suite Hardware interfacing Ethernet PHYs SWs LEDs SDRAM Quartus II TED Architecture Definition Busses interrupts memory addressing Memory mapped I O and peripherals QSYS System software development Packet inspection DMA control NIOS II SBT Eclipse eclipse 2 OTHERS n casts orn Figure 4 2 Altera Hardware Software Tool Suite Figure 4 3 shows out development flow as we progressed through the project There were no major deviations on the execution of our development Analyze TED Requirements Statement of Requirements 1 NIOS Processor Define and Generate Develop crypto algorithm Standard Peripherals System in QSYS in Java Develop software packet c Custom hardware drivers Custom Hardware recognition control Integrate QSYS into A for ethernet PHY and ethernet PHY crypto Quartus II for NIOS II with Eclipse SBT avuto modulein C Cs module buffers DMA in VHDL in C C Assign FPGA pins Download software Hardware VHDL Ensure timing constraints gt executable
28. literature hb nios2 n2sw_nii5v2 pdf gt The NIOS II software developers handbook was used when writing C code for the NIOS II processor in order to conform to best practices when programming this particular processor 6 Nios II Hardware Development Tutorial 11 May 2011 Altera Inc Web 9 Nov 2014 lt www altera com literature tt tt_nios2_hardware_tutorial pdf gt The NIOS II hardware developers tutorial was used when developing the custom cryptography module for the QSYS system builder in order to be able to integrate the module with the Avalon bus and in order to write hardware drivers to integrate the module with the NIOS II processor architecture 7 Postel J RFC 768 User Datagram Protocol RFC 768 User Datagram Protocol 28 Aug 1980 Web 7 Sept 2014 lt http tools ietf org html rfc768 gt RFC 768 was used in order to determine the layer four header structure as it relates to UDP in order to perform deep packet inspection of UDP IP packets 8 4th Year Project Page Segfaults net Project Management Office EEE455 457 1 Sept 2013 Web 7 Sept 2014 lt http projects segfaults net joomla index php en statement of work gt The RMC 4th year project page was used as a reference for timelines and document templates in order to conform with the 4th year final project standards and deadlines 9 Quartus II Handbook 18 Aug 2014 Altera Inc Web 5 Nov 2014 http www alte
29. methods is that the initialization vector is applied after the cipher block Plaintext Plaintext Plaintext TT Initialization Vector IV block cipher block cipher block cipher ls mentam xey pla Ciphertext Ciphertext Ciphertext Cipher Block Chaining CBC mode encryption Figure 5 2 Encryption Structure for a Block Chain Cipher Ciphertext Ciphertext Ciphertext block cipher block cipher block cipher ver il Initialization Vector IV LLITIITITITIT Plaintext Plaintext Plaintext Cipher Block Chaining CBC mode decryption Figure 5 3 Decryption Structure for a Block Chain Cipher The final requirement is to ensure that each block within a packet is hashed differently Consider the case where there are more than 5 blocks of data and each block contains an identical set of data If the data is identical the salt for any 12 block will be identical to the salt of the block that came before it This greatly reduces the security of the cipher The solution to this requirement was a key rotation algorithm to ensure that each block is encrypted with a different subset of the original key This allows the data to remain the same but produce a different salt for the next block So for each block that is processed the 8 16 and 32 bit keys is mutated to produce a different hash for each block of data 5 3 1
30. opment Board Interfaces 25 Fip re 5516 Ethernet Interfaces ge a o Rp a RUN etude dn qut d eap a eme 25 Figure 5 19 LCD Interface oa editor iai i He Ma e i i diede re 26 Fapuse o 20 DE 115 Switches Ier Ae ooo ai Y pee o i a eeu a i 26 Figure 5 2D DE 115 LEDs cei tee tote ice ri i Ca E EUR CER EE HARE 27 Fig r 5 22 DP 15 SWitehes derit qii ipto i i bti thon 27 Figure 5 255 SRAM IBECP ACE i dei a e oe i ii i i i i i i a 27 JR Project Equipment bast as at i i i i i a a S 28 Figure 7 1 Comparison of Bandwidth with and without TED 29 Figure 7 25 Latency ot Varable Packetotbes auos si i a eR aa OUS od S Gel RC bela 30 Lii JJ TED AdminisitaloB GUL ouest dtd debts tte tod tton 31 Fig re 7 4 TED UDP Administration ai th a ttai beds 31 Figure A 1 Block Cipher Decryption cu codes te GE Pg 36 Figure A 2 Block Cipher Encryption Modele n d eite b ki 37 CPU DMA EOP FPGA GUI HDL IV LAN LED LCD MAC MII NAT PHY ROM SOP SBT SDRAM TED VHDL VPN List of Abbreviations central processing unit direct memoty access end of packet field programmable gate array graphical user interface hardware description language initialization vector local
31. otation Value after the 1 operation 0x988F3FF9 Value after the 2 4 operation 0x0 Value after the 3 operation 0x988F3FF9 13 Value after the 4 operation 0x0 Value after the 5 operation 0x988F3FF9 Table 5 2 shows the results of the cipher with different salts but the same data and no rotation The same issue of rotation where the operations cancel each other out exist but this time we have the same data with different hashes The salt value ensures that data is processed differently each time This helps eliminate table lookup attacks on this cipher Table 5 2 Cipher Output with Salt Salt 0x47112015 Value after the 5 operation OxDF9E1FEC Salt 0x20154711 Value after the 5 operation OxB89A78E8 Table 5 3 shows the final iteration of our cipher development The addition of a rotation algorithm on the key values is added This rotation ensures that each block will be processed differently Table 5 3 Cipher Output with Rotation and Salt 0x47112015 ue after the 1 operation 0xDF9E1FEC ue after the 2 operation 0xA689B540 ue after the 3 operation 0xA07D94C2 ue after the 4 operation 0x37DD6ABF ue after the 5 operation 0x55A8AFBC 14 The structure of the algorithm with 32 16 and 8 bit keys requires that we do not produce a repeating pattern with the key throughout the encryption of the packet The initial condition of the keys must not be reached for a
32. packet is received or transmitted on any interface 2 Enable Cryptographic module 3 Cryptographic filtering modes 4 Reset the TED 5 3 4 2 Parallel I O Design The design elements of this module were connecting the appropriate signals to the IO elements that will display the data We also didn t want to slow down the primary operations of the TED so the operations were placed on a completely separate bus To further separate the primary operations of the TED we are using an asynchronous reset button to drive any setting changes The reset button also acts as a way to test a multitude of settings rapidly from the TEDs initial state The code development behind each switch and LED varies considerably and can be referenced in the source code 5 3 4 3 Internal Structure Each I O element is a memory mapped interface to the CPU as shown in figures 5 11 5 12 and 5 13 On initialization the TED will cycle through each switch and appropriately trigger each of the settings To make initialization occur more rapidly a reset switch was used to force the board to re initialize The reasons for this were two fold The first is to have a quick way to power cycle the board without removing the power and the second was to remove the requirement to loop through and constantly check for any I O changes 5 4 Interface Descriptions Following in this section is a brief description of all physical interfaces we used on the DE2 115 development boar
33. payload This new frame is retransmitted through the black interface of TED A to gateway 1 and routed to secure endpoint 4 When the frame is received by TED B through the black interface it is inspected to determine if the source IP address matches secure endpoint 2 and that the destination matches secure endpoint 4 If both of these conditions are met the layer 3 payload is decrypted and the original frame as transmitted by secure endpoint 2 is retransmitted on the red interface to secure endpoint 4 1 2 1 2 Secure Endpoint 2 to Non Secure Endpoint 3 Network Traffic generated by secure endpoint 2 is received by TED A through the red interface The frame is actively ignored because it is not destined for a secure endpoint and therefore is transmitted on the black interface of TED A to gateway 1 frame is routed to non secure endpoint 3 as any normal frame 1 2 1 3 Endpoint 1 to Secure Endpoint 4 Network traffic generated by endpoint 1 is received by gateway1 and routed to secure endpoint 4 The packet is received by the black interface of TED B The frame is inspected to see if the source address is originating from a secure endpoint is actively ignored by TED B and retransmitted through the red interface to secure endpoint 4 1 2 1 4 Endpoint 1 to Non Secure Endpoint 3 This is a standard network communication 1 3 Aim The aim of our project is to design and prove the concept of a p
34. ped semaphores or interrupts to signal they are finished with transfers The cryptographic module will also use a form of DMA in order to complete the encryption and decryption operations 5 3 3 2 DMA Design When looking at Figure 5 13 the interfaces in the architecture that required the use of DMA and their types are 1 Triple speed Ethernet MAC Red Receive Red Rx interface This required the use of streaming to memory mapped MM DMA in order to write incoming streaming data as it is received from the red receive interface to sequential locations in the outgoing memory block 2 Triple speed Ethernet MAC Black Transmit Black Tx interface This required the use of a MM to streaming DMA in order to write data from sequential locations in the outgoing memory block to a stream to the black transmit interface 3 Triple speed Ethernet MAC Black Receive Black Rx interface This required the use of a streaming to MM DMA in order to write incoming streaming data as it is received from the black receive interface to sequential locations in the incoming memory block 4 Triple speed Ethernet MAC Red Transmit Red Tx interface This required the use of a MM to streaming DMA in order to write data from sequential locations in the incoming memory block to a stream to the red transmit interface 5 Encryption This required the use of a MM to MM DMA in order to read encrypt and write sequential data located in the outgoing
35. phic module In addition when the network was properly configured to operate in a NAT environment the TED was able to survive two instances of NAT transversal Through a comparison of network operations with and without the TED placed inline network communications we have shown that there are negligible performance losses when using the TED The final results of our testing showed a 0 5 decrease in bandwidth and less than 0 1 decrease in latency approximately 1 100 millisecond The demonstration of duplexity was demonstrated by conducting synchronous communication between User 1 and User 3 and observing that no blocking waits were being initiated within the Quartus console We have established the security against some of the more vulnerable aspects to block ciphers such as rainbow tables however since the data is wrapped in 32 bit blocks leaving the cipher open to brute force techniques While the cipher successfully obscures the data without a proper peer review it is impossible to verify that it is a secured algorithm Its implementation must be viewed as an academic pursuit 34 10 Discussion 10 1 PR 04 Requirement Removal One major change we made from our preliminary design specification was the removal of performance requirement 04 The TED will insert a custom layer 4 header to mask any usage signatures from the device This requirement was removed because we felt it conflicted too much with the idea of a transparent network d
36. project was to develop a hardware based symmetric encryptor that would abstract the security of network data away from the operating system towards a dedicated device Security software that runs on an operating system inherits the security vulnerabilities of all other programs running on that operating system To remove that attack vector will greatly increase the overall security of the system We placed the device inline of network communications and in doing so we can intercept data and modify the contents without obstructing the flow of network communications This means we do not have to transverse the protocol stack in order to process the data This allows our device to encrypt data without leaving a signature or changing the header data in the packet This also makes our device a layer two device but it is fully aware of the entire contents of the packet This paper introduces 3 common use cases These are the three use cases that we used to validate our design however there is no restriction to how this device may be used It can operate WAN to WAN and even function as a data diode These use cases are beyond the scope of this paper but demonstrate that many possibilities for deployment exist bound only to the interpretation of the user 33 9 Conclusion The final state of the project demonstrates that the DE 115 FGPA development board is capable of conducting secure network communications over Ethernet with a custom cryptogra
37. ra com literature hb gts guartusii handbook pdf gt The Quartus II handbook was used as a general reference when implementing all parts of the TED in order to provide a reference when using different programs in the suite QSYS Quartus II NIOS SBT 3 1 3 2 3 3 3 4 Product Requirements Functional Requirements FR 01 Network Visibility The device must be in line of data transmission in order to achieve visibility and control over all packets transmitted and received by the secure endpoint FR 02 TED Pairing TEDs will work in units of two Both TEDs will have a shared secret key and operate point to point Interface Requirements 01 Network Access TED will be connected directly to the secure endpoint and the gateway with RJ45 IR 02 NAT Configuration Static NAT setup on the gateway will be required if NAT mode is enabled IR 03 Admin User Configuration Develop a graphical user interface capable of sending configuration commands to the TED from a secure endpoint Performance Timing Requirements PR 01 Device Network Speed The TED must be able to operate in real time with the secure endpoint and the gateway at 100Mbps PR 02 TED Processing The delay of processing the encryption decision will not exceed 10mS PR 03 Duplexity The TED must be able to send and receive concurrently on its red and black ports Implementation Restrictions IMP 01 Hardware Restriction A
38. s for NIOS II to Software C C Java are met DE2 115 PE Compile hardware design for DE2 115 Cyclone IV Run and debug software FPGA on DE2 115 Download design to DE2 115 Refine software and hardware Figure 4 3 TED Development Flow 10 5 Detailed Design 5 1 Overview The modules within the TED were designed and implemented using ANSI C and VHDL With the exception of the DMA all modules are portable to other chipsets that support standard VHDL and compile ANSI C 5 2 Limitations 5 21 NAT Operation The TED was tested and designed to operate on a static NAT configuration 5 3 Modules 5 3 1 Cryptographic Module 5 3 1 1 Cryptographic Design Specification There are three specific requirements that our algorithm must meet which are inherited requirements from the system level requirements The algorithm must not have a significant impact on system level latency or bandwidth The algorithm must be able to produce a different cryptographic hash for identical packets The algorithm must be able to produce a different cryptographic hash for identical blocks 5 3 1 2 Cryptographic Design The first step for the algorithm was deriving the constants of the algorithm A block size of 32 bits was chosen simply due to alignment with our 32 bit processor This meant that two 32 bit values could be XOR together in a single clock cycle A key size of 56 bits was chosen
39. sor is programmed to only consider Ethernet IPv4 TCP and UDP Additional functionality can be built into the board to include IPv6 ICMP ARP VLAN and any other desired protocol Annexes Annex A Additional Diagrams and Figures 32 bit Cipher Text 32 bit Cipher Text 32 bit Initialization Vector Key and Counter Right Rotation Shift ED a lt 2 co b7 b6 b5 b3 b2 b1 K 56 bit e Figure A 1 Block Cipher Decryption Model 36 32 bit Initialization Vector 32 bit data block 32 bit Cipher Text Key and Counter Right Rotation Shift dl b7 b6 b5 b4 b3 b2 b1 bO K 56 bit 9 Figure A 2 Block Cipher Encryption Model 37
40. sts are duplicated for each of the outgoing memory and incoming memory in order that packets are moved in different directions through the TED simultaneously achieving duplexivity through the TED 5 3 3 5 Error Handling Error handling of all DMAs is permitted to trickle down to the transmission of packets through the opposing interface The IEEE 802 3 standard provides for robust handling of errors during transmission through the use of checksums in different layers of a packet This robust handling of errors does not interfere with operation of the TED and allows it to degrade gracefully and remain operational 1f errors happen during packet inspection or encryption In short if a packet fails checksum verification during any link of transmission it is simply dropped and it is left to the individual protocol on the secure endpoints to proceed 5 3 4 Parallel I O Module 5 3 4 1 Parallel I O Design Specification The parallel 1 O was required to assist in development The various mechanisms available on the DE 115 board allowed us to troubleshoot outside of the software This reduced the amount of configuration needed within the code and also provided instantaneous feedback in terms of the interface states Specific functions and register settings were bound to switches LEDs and displays 24 1 PHY Chip Settings a Control link speed 10 100 1000 Auto b Control duplexity c Crossover enabled or disabled d Alert when a
41. t linked list buffer and then moves the node to another linked list in order that it is acted on approptiately by that list In turn each of the linked lists operations and node transitions is as follows 1 The available linked list is inspected All nodes which point to a specific 2048 byte block are moved to the receive linked list 2 receive linked list is inspected All nodes that have received packets are moved to the inspect linked list 3 The inspect link list is inspected All nodes are run through the packet processor which determines if the packet is an administration packet if it is supposed to be encrypted decrypted based on deep packet inspection i it is communication between two paired TEDS or whether it is to be actively ignored It is then moved to the control linked list the crypt linked list or the transmit linked list respectively 4 The control linked list is inspected All nodes that contain configuration information cryptographic keys are loaded onto the TED The nodes is then moved to the available linked list 5 The crypt linked list is inspected The layer four payload data of all nodes encrypted decrypted depend which interface the packet was received from The node is then moved to the transmit linked list for transmission 6 The transmit linked list is inspected All nodes that have been transmitted are moved to the available linked list It is important to note that these li
42. ure 5 3 Decryption Structure for a Block Chain Cipher eie qon epe d 11 Table 5 1 Cipher Output with no Salt or ai eie rr e k a es 12 with a tnm odere aa 13 Table 5 3 Cipher Output with Rotation and Salia i a b bles deba pretii uds 13 a GER ferie 14 Figure 5 4 Ethernet and IPv4 Header sede qu dede dad a Oia 15 Figure 5 5 DOC P Ir bab be Ee edite e aba a i BER Vett Rb rbd eo tide 15 Pipe 5 6 UDP Header sis tp tertie qo teni e tiec a Mr bat o te Cv RAT 15 Figure 5 7 Packet Processor View suia aud nd aae dirae dard aded d aud pred cir 16 Pip re 5 8 Packet Patser Pinal i it a bita a a a iR 16 Figure 5 9 Packet Processor o sh Quen ded e Aa thane 17 Pigu 5 10 Packer Processor Data i a i i i A Rufe 18 Fioure 51 1 Packer Processor Plow qa a a a a i ER RA 19 Figure 5 12 Admin Packet Data i i r i i 20 ES 21 Figure 5 14 Typical DMA Transfer of Control Incoming uie iieri eitis 21 Figure 5 15 Typical DMA Transfer ot Control Outgoing ax cus ret d cea e de e 22 Fig re slo Packer DU Lei Linked utis i b p oboe bte htt optat 22 Figure 5 17 Terasic DE2 115 Devel
43. valid packet size of 1500 bytes The rotating mechanism that we have chosen allows us to rotate the 16 bit key sixteen times the 8 bit key eight times and each rotation of the 16 bit and 8 bit keys allows the use of 31 rotations of the 32 bit key Formula 1 shows that the equation for the amount of blocks that can be processed with unique values of our rotating key set The final value of this is 3255 blocks as shown in formula 5 1 As a comparison a 1500 byte packet contains 375 blocks including the header data Formula 5 1 Block Repetition Block Repetition 31 15 7 3255 Blocks 5 3 1 5 Error Handling The error handling for this module will rely on the higher layer network mechanisms for error detection such as TCP and IP protocols on the end user workstations In the event of an error the packet will simply be discarded and retransmitted 5 3 2 CPU Memory Module 5 3 2 1 CPU Memory Design Specification This CPU and Memory modules will be responsible for the packet decomposition and target selection The packet decomposition must perform the following operations 1 Determine the size of the incoming frame 2 Determine the size of the present headers up to the transport layer 3 Determine the start point of the data The target selection must be able to compare the incoming packet data with list of encryption and decryption targets it has stored in memory The packet processor receives a notification that the p
Download Pdf Manuals
Related Search