Logo
Sam Eldin
CV - Resume Tools 4 Sharing Architects 2 Show Big Data Presentation Android Training Java-Unix Code Templates Interviews QA & Code

Compression-Encryption Cyber Security Chip
Introduction:
The biggest two cyber issues which the world is facing today is security and privacy. Both cyber security and privacy issues are growing and it seems there is no stopping or even slowing them down.

Anyone who claims that he/she has the answers to both security and privacy issues would face skepticism and criticism. Therefore, we would present our solutions and leave them for the world to be the judge.

Chip Executive Summary:
The internet is highways of data traveling from one computer network to another computer network. Data is packaged in small amounts of data known as Packets. There are rules and regulations governing the processes of moving these packets. A router receives and sends data on computer networks. To make an analogy of how data travels on the internet, let us look at Chicago-Davenport Possible Routes Image presenting the road map between Chicago, IL and Davenport, IA. The number of possible routes a driver may choose based on weather, time of the day, traffic, construction, ..etc, can be a handful. For example, 294-88 highways route may start with Chicago, Downers Grove, Dixon, Rock Falls, Prophetstown and end at Davenport. The same thing would apply to the internet routes where cities are replaced by computer networks.


Chicago Davenport Routing Map
Chicago-Davenport Possible Routes

Packets traveling through such routes would have to pass though each of the networks. There is nothing that can stop any of the routing networks from having a copy of each packet, damage the packets or stop the packets from going to next network. What we just described are some of the possible cyber security issues. As for privacy, both hackers and companies can use such data in these packets to their advantage. For example, mobile data can be accessed by other Apps running on the same mobile device.

What are we proposing?
First, a packet is composed of a data section and network traveling information sections. The connecting networks only use the network traveling information sections to get the packet to the next routed network. The data section should not change nor be altered.

         We are proposing the building of a computer chip which compresses-encrypts the packet data section.

What is special about our Compression-Encryption Chip?
Compression and encryption are not new and have been used in packet security. Based on the type of data, both compression and encryption would slow down the system quite considerably. The main goal is to handle packets as fast as routers.

Add Fields Packet Diagram
Our Add Fields to the Packet Diagram

The difference between our Compression-Encryption Chip and what is already being used by security experts is:

Telecommunication Speed:
Our chip compresses data by more than 70% (lossless - no loss of data) which would translate to sending three or more packets instead of one packet.
It saves time, space, adds more security and boosts the internet traffic by a multiple of 70%.
The fact is our compression would reduce the size of data (example Medical Records) by more than 70% with no loss of data.
As for Telecommunication Speed means you would be sending four images instead of one.
Actual speed is:

         70% (saving with every networks connection) * number of connection

As for the moble:

         70% (saving with every networks connection) * number of connection * 5G

Cybersecurity:
Our chip runs with its own CPU and memory, therefore it could not be hacked plus its secrets are hidden within the chip
Our chip runs as fast as the Computer CPU since all the chip programs run within the chip
Our chip performance would be as fast as any top-of-the-line router if not faster, where a router can move as many as 60 million packets of data every second.
Our packet data would be composed of starting fields (Chip ID, Encryption Key, Index, and Timestamp) and the actual data. The starting field would be compressed, but not encrypted. The actual data would be compressed and encrypted.
We added security fields (Chip ID, Encryption Key, Index, and Timestamp) to be the start of the compressed packet data, which would be would decompressed first by the receiving (Inbound) chip and then checked for accuracy. Any errors or tampering with these fields would result in rejecting the packet and moving the packet to an analysis server which analyzes and handles any hacking packet.
Our Inbound chip would start with the security fields and then decompress these fields but not decompress nor decrypt the actual data. The remaining packet data (actual data) would still be compressed and encrypted. Our chip would check the decompressed fields and check for validation. If fields have the correct values, then these fields would be used to look up a decryption key stored on the chip. If the decryption key is not found, this would means that sending or starting (Outbound) chip does not have permission nor access to our Inbound chip. Then our chip would not decompress nor decrypt any further and would move the packet to the analysis server.
Our Inbound chip would not decompress-decrypt the actual data unless the correct values in the security field are the right combination to find the encryption key stored in the Inbound chip. This would protect the actual data in case hackers are using our Inbound chip.
Our chip would be architected and designed to be selective of what should be decrypted in case someone is using our chips without permission. Therefore, the actual data would not be decompressed nor decrypted unless our Inbound chip has the correct values in these security fields.
In the case our Inbound chip is bombarded with stolen outbound chips packets, rerouted of our packets, resending packets or copies of our old packets so our Inbound chip would be overwhelmed with our packets. Our Inbound chip would be able to quickly reject all these packets and keep the actual data safe (compressed-encrypted). There is no need to decompress-decrypt the actual data, plus time and effort are redirected to handle the next packet and boost the chip performance.


Our Strategy:
Our strategy is to use compression, encryption, security fields and built-in values on the chip to make it more difficult to hack our system even if someone would be using our chips.

At the starting network:

Add an ID number, compression-decryption keys and another index to the data section, which we call fields
Compress-encrypt the data with the added fields
Add the compressed-encrypted to the packet and pass the packet to the network router to do their job on network traveling information
The packets would be traveling from starting network and go through the routed networks until they reach the destination-end network

At the Destination-end network:

Decompress-decrypt the received packet data and check for the added fields
If the fields (ID, Key, and index) are not correct, then discard the packet and keep a copy for tracking and analysis
Try to warn the starting network that the packets have issues
If the fields (ID, Key, and index) are correct, then pass the data (without the fields) to the end network to process the data. Also keep a copy for tracking


Privacy Issues:
ID, Encryption Key and Index can be used to control the decryption and only the chips with correct values would be able to decrypt the data. For example, any mobile App trying to spy on mobile user would not be able to use the encrypted data. The combination of the three fields (ID, Key, Index) would give our compression and encryption an infinite number of possible encryption.

Machine Learning Software:
As for tracking and analysis of packets, we would be creating Machine Learning software to learn as it processes packets plus have the needed steps to present actions to handle any cyber attack.

Our Lossless Compression-Encryption Algorithms:
First, we need to state that our audience needs to accept that without any proof that our lossless compression-encryption algorithms are as fast as any CPU with zero loss of data. We are not presenting any hint or proof so we do not give our algorithms away. The world is full of gurus and any hint may give our secrets away. Our algorithms must run on a sperare chip. The chip must have its own CPU and memory (Cache and core).

We are proposing two types of chips:

         • OSI Model and TCP/IP Model Chip
         • Personal Chip


OSI refers to Open Systems Interconnection whereas TCP/IP refers to Transmission Control Protocol.

The first chip would replace the data section in the OSI Model and TCP/IP Model.
The second chip is what we call "Personal Chip". It would be used with PCs (laptop, desktop) and mobile phones.

The main advantage of using our chip is speedy compression-encryption-decompression-decryption which would also boost the internet speed by multiple of 70% with no performance issues.

Our Machine Learning Virtual Server:
To add intelligence to our chips without adding dynamic software analysis, processing, tracking, updates, ..etc, we are proposing virtual servers with Machine Learning capabilities. These virtual servers would communicate with the chips to add dynamic performance. Creating-deleting any number of these Virtual Servers is done with astonishing speed and flexibility. These virtual servers lifecycle would be very short for hackers or attacks to even know they exist. Our Chips would verify these virtual servers using dynamic IDs similar to dynamic cookies. We would be using Bit mapping to make it more difficult to hack.

Use Case #1 - Methods of Distributed Denial of Service (DDoS) Attacks
The AWS DDoS Attack in 2020:

Amazon Web Services, the giant in cloud computing, was hit by a gigantic DDoS attack in February 2020. This was the most extreme recent DDoS attack. The attack targeted an unidentified AWS customer using a technique called Connectionless Lightweight Directory Access Protocol (CLDAP) Reflection. This technique relies on vulnerable third-party CLDAP servers and amplifies the amount of data sent to the victims IP address by 56 to 70 times. The attack lasted for three days and peaked at an astounding 2.3 terabytes per second.

         We estimate 2.3 terabytes per second is equal to 1 billion packet per second.

According to our understanding, the attack was detected at 5:00 AM PT and customers started calling 5 hours later. AWS confirmed the attack at 6:30 PM PT, then AWS started addressing the DDoS.
It is clear that it took AWS 14 hours to respond to the DDoS. The exact DDoS attack could have started even earlier than 5 :00 AM PT.

Use Case #2 - Russian Cyber Attack on the USA Federal Agencies
The hackers attached their malware to a software update from SolarWinds, a company based in Austin, Texas. Many federal agencies and thousands of companies worldwide use SolarWinds' Orion software to monitor their computer networks. SolarWinds says that nearly 18,000 of its customers in the government and the private sector received the tainted software update from March to June of 2020.

Questions and Concerns:
         • No one knows how long hackers had access to which department and data.
         • No one knows what data is being stolen
         • Is the hackers' code still remain hiding in these infected government departments
         • Would the hackers start another attack and when?

Our Approach:
The following is our prevention and remedy processes for addressing cyber attacks:

Prevention Remedy
1. Constant Monitoring 1. Detect
2. Tracking - Logging 2. Identify
3. Scanning 3. Escalate
4. Analysis -Audit Trail 4. Fix
5. Reporting 5. Validate


Our OSI Model and TCP/IP Model Chip
What is our OSI Model and TCP/IP Model Chip?
Our OSI Model and TCP/IP Model Chip is a device which compresses-encrypts packets to secure and boost the sending and receiving of packets.

What are we building?
We are building a system which combines hardware (chips and servers) and software (Intelligent Machine Learning) to make it harder for hacker attacks.

How can our chip protect against hackers' attacks?
To make our solution clear to both technical and non-technical audience, we would be covering some basic knowledge plus using examples of our protection against hackers' attacks. We kept most of the technical notes in the second part of our page, so the further our readers read, the more technical our page would be.

Basic Knowledge:
Routers and packets need to briefly be explained to make our solution clear to both technical and non-technical audience.

What is a router in networking?
A router receives and sends data on computer networks. Routers perform the traffic directing functions on the Internet. A router uses the information in its routing table or routing policy and it directs the packet to the next network on its journey.

Packets:
What is a Web packet?
A packet is a small amount of data sent over a network, such as a LAN or the Internet. Each packet includes a source (the starting Router) and destination (the end router) as well as the content (data) being transferred.

What will the router do with the packet?
After a router determines whether the destination (the end router) is on the local network or a remote network. The router examines the routing table for figuring out the destination network number. When a match is found, the packet is sent to the interface associated with the network number.

In short, packets are moved from the starting router to end router in a number of possible ways based on internet traffic and protocols. This means that every packet may end up routed through a number routers. Each router would be able to have a copy of all the packets passing through or process these packets. Routers can also create bogus packets and send them to both the start and end routers if they wish to do so. Such action would jam all the communication for the starting and end routers. This is known as denial of service (DoS) and Man-in-the-middle (MitM) attacks. The hackers' objective is to overwhelm the resources of target system (victims) and cause them to stop functioning, denying access to their users.

Packet Structure - OSI and TCP/IP
OSI refers to Open Systems Interconnection whereas TCP/IP refers to Transmission Control Protocol. The main section we would be compressing-encrypting is the data section as shown in image #1.


Packet Structure - OSI and TCP/IP
Image #1

Image #1 presents two approaches of building packets.

OSI Model:
OSI Model, uses 7 layers which make up the packet. Application (7), Presentation (6) and Session (5) is the data section in OSI packet. Our Chip would add some more security data (fields) to layers 5-7. Our chip would compress-encrypt this data section. The security data (fields) would be explained later in the following sections.

TCP/IP Model:
TCP/IP Model uses four sections (Application, Transport, Internet and Network Access). The data section would be composed of Application plus we would be adding some more security data (fields) to the Application part. Our chip would compress-encrypt this data section. The security data (fields) would be explained later in the following sections.

Our Cyber Defense:
How can our chip protect against hackers' attacks?
Our proposed defense system is composed of the following:

         1. Outbound Chip - compress-encrypt data section
         2. Inbound Chip - decompress-decrypt data section
         3. Intelligent Virtual Machine Learning Server - Prevention and Remedy Agents



Our Chip Protect Diagram
Image #2


Our OSI Model and TCP/IP Model Chip Diagram - Image #2 is presenting our Cyber Defense. Packets would start at Starting Network and may pass through a number of possible routes which may include Hacked Networks. Once a packet is received by the End Network, which could be the start of hackers attacks. Assuming that the Start Client data is not been compromised, our protection starts with the Outbound Compressing-encrypting chip. The chip would compress-encrypt the data (with our security fields). Inbound chip would decompress-decrypt the data section (which contains our security fields). Based on Inbound chip evaluation of data section, Inbound chip would be able to determine if the packet has been compromised. Our Inbound chip would pass good data to the End client system as well as a copy is sent to Intelligent Virtual Machine Learning Server - Prevention and Remedy Agents for storage and tracking. In the case that our Inbound chip recognizes that the packet has been compromised, it would reject the packet and send it to the Intelligent Virtual Machine Learning Server - Prevention and Remedy Agents for analysis and tracking.

Our Intelligent Virtual Machine Learning is our dynamic tool for both prevention and remedy against cyber attacks. A typical packet's size is about 1,500 bytes, but the number of packets could be in billions per second. Virtual Machine Learning Server would store the packet using speedy buffer and local Network-Attached Storage (NAS) for tracking packets. Our Machine Leaning server tools are intelligent and fast software tools for handling hackers attacks and perform both prevention and remedy processes.

What would our chip compress-encrypt?
We would be compressing-encrypting Data Section as shown in Image #1 plus a number of new fields as follows:

         1. Packet ID number - we would provide
         2. Size of the compressed data section
         3. Packet Sequence Number - we would provide
         4. Timestamp
         5. Hacked Index - we would provide
         6. Application
         7. Presentation
         8. Session including Cookies
         9. Misc - anything else may add to the security and the processing speed


ID, Key and Misc Fields:
Our Outbound (compression-encryption) and Inbound (decompression-decryption) chips would perform their tasks based on the ID, Key and Misc fields. The possible combination of these three IDs, Keys and Misc values would give our chip the ability to create endless number of possible compression-encryption.

We would be covering some of the added fields later in the following sections.

The main advantage of using our chip is speedy compression-encryption which would also boost the internet speed by multiple of 70% with no performance issue.

In the Testing Our Chips Performance section, we would be presenting how Our OSI Model and TCP/IP Model Chip handles cyber attacks.

Our Personal Chip
The second chip is what we call "Personal Chip". It would be used with PCs (laptop, desktop) and mobile phone.

Our Chip has two modes the user can choose:

         • Public - what already exist at the current stage of technology
         • Private - Protected and Secured


Public
What already exist at the current stage of technology:
Data would take its normal route and our chip would not be involved.

Private - Protected and Secured:
A chip user would have the option to select the "Private" mode. Private option would activate our chip to start compression-encryption. Our Chip would be located as an internal or external (with its own device). We would have to work with PC and phone manufacturing (PC, tablets, Apple-iPhone, T-Mobile, Sprint, AT&T, ..etc) on how to add our chip to their devices and their interface. The main job of the chip is replace the first packet buffer. Our chip data section would replace the packet data section. This means that every application and phone App would be sending its data to our chip instead of first packet buffer. Our chip would compress-encrypt that data and then send the compressed-encrypted data to the existing packet building tool, which it would add the header, IP addresses, .. etc. For example, a mobile App collecting data and ready to send out its data, it would direct the data to our chip and no other App would be able to even touch such data. TikTok or any spying App would not able to get any data except after the data is compressed-encrypted by our chip. Our compressed-encrypted data will have no value unless is undone by another of our chips. Then, the mobile packets would take its normal transmission route (wireless) to the towers. The same thing would be done to PC users, the packet with our compressed-encrypted data would be send to routers or towers (wireless connections).



Personal Chip Mobile Diagram
Image #3

Image #3 represents a rough draft of how data created by any App where the App would have to send its data to our Outbound chip. Our Outbound chip would compress-encrypt the data and then pass the compressed-encrypted data to the mobile packet tool to start the packet journey to the mobile towers. The "Private" mode would be protecting mobile data from hackers as well as Apps running in the mobile to spy on users. Privacy is protected since compressed-encrypted data would have no value to any App or receiver unless the compression-encryption is undone.

Our Chip would have its own build-in analysis programs (similar to microwave oven) to execute and analyze the needed actions. Our chip internal communication setting would be:

         1. One to One - only two users - example point to point
         2. One to Many - example a bank and its customers
         3. Many to Many - group communicating with other groups or inter department communication
         4. Network to Network - members of networks communication


Every chip would have a hard list embedded ID, Key and Misc fields for CPU to access and performs the needed tasks. The chip CPU decompress-decrypt the incoming data section and the Data Section would have the same fields listed in Our OSI Model and TCp/PI Chip.

Can one personal chip be used with multiple sittings?
We would be creating more Personal and Business Chip ID, Keys and Misc fields. The ID, Key and Misc fields values would give us the ability to create any number of communication settings. For example, one personal chip may communicate with a number of banks, working groups, ..etc.

Packet ID Number:
Each packet would be assigned an ID based on a number of security parameters. The Packet ID would be made from a number of security values for chip to analyze.

Once our chip decompresses-decrypts the data section of the packet, our chip would recognize the packet ID number. In the case of an ID is a fraud and it would pass the packet to our Machine Leaning Virtual server(s) for further security analysis. In case of no issue with fields, then packet with decompressed-decrypted data would pass to its normal route.

Size of the Compressed Data Section:
To eliminate any package damage or corruption to the compressed-encrypted data section, the size can be an indication that some of the routers are deliberately changing data section and our chip may recommend the use of different routing and hopefully would dynamically eliminate routers with cyber security issues.

Packet Sequence Number:
Packet Sequence Number would help with receiving data in the correct order and will correspond to sender to resent. All data and items listed are compressed-encrypted so there would be no interruption or intrusion.

Timestamp:
Timestamp is an added security parameter as will as keep thing update.

Hacked Index:
Intelligent Virtual Machine Learning Server would track each of the application and destination IP and gives a grade from

         0 - 9

of the possibility of internal hack exists in the internal system.
Firewalls can also use this Hacked Index for an IP against their protocols.

Routing Analysis:
A router uses the information in its routing table or routing policy and it directs the packet to the next network on its journey. If such information can be captured and made available for Our Machine Learning (ML) System. Then our Machine Learning (ML) System (Virtual Servers) would be used to dynamically figure out which routers are source of cyber security issues and recommend not routing through certain routers, zone, country, ..etc. Our ML would help in knowing the routers which would damage packets as the packets passed through them. It would add an extra intelligent analysis to Firewalls.

Speed of Actions:
How many HTTP requests can a server handle?
According to our internet search, with high-performance software, a single modern server processes over one million HTTP requests per second. Load-balancing can be used to improve http requests per second. The speed of server CPU can also add the http server handle requests.

Our chip would be running independently from http server as an external device or be a part of the firewall box. Our chip would be able compress-encrypt as well as decompress-decrypt the data section of packets. Our chip would have its own CPU, memory, and cache memory. We recommend that another server with our Machine Learning system would communicate with our chip to receive rejected packets for analysis.

ID number Lookup Chip Registers:
We are moving the lookup and search for IDs and fields on the chip bit level for speed. The key in our chip and all its processes is speed. We added a number of fields to data section to help with the processes of eliminating corrupt or hacked packets.

All the field values stored as integer (bits) which would be used to look them up in the chip array of IDs. For exampl, the Chip ID would be "&" "AND" (see Image #4) with each array registered IDs and once an ID is found, then package is accepted. There would be also a number of lookup fields to insure the packet was not corrupted or we have cyber issues.

Chip Register Lookup ID
Image #4

The Chip registers processes would be performed at hardware level for speedy performance.

Our Chip Protection List:
Our Chips goal is prevention and remedy. Our chips and Intelligent Virtual Machine Learning Server(s) would make our cyber security performance speedy, dynamic, flexible, intelligent, robust and traceable.

First, the following fields would be populated by compressing-encrypting chip, then these fields with system data would be compressed-encrypted.

The chip would add the compressed-encrypted data to the packet and sent to the router.

         1. Packet ID number - we would provide
         2. Size of the compressed data section
         3. Packet Sequence Number - we would provide
         4. Timestamp
         5. Hacked Index - we would provide
         6. Session including Cookies
         7. Misc - anything else may add to the security and the processing speed


We have a number of processes on how to populate these fields, and we are open to use other security experts and their real world experience. The main goal is create a dynamic intelligent processes in our security approaches.

Any alternation to the packet data would be figured out by our chip and eliminated with high speed processing.

Stolen Chips or Unauthorized User:
To prevent using stolen chips (internal or external chip) can resolved as follows:

         • User must enter log name and password before the chip starts
         • User must register a list of devices (phone, laptop, desktop, ..etc)
         • Face recognition and other means of ID procedures

Testing Our Chips Performance:
Based on the two use cases (AWS and Russian Hackers) and our chip architect-design, we would be able to present how our chip would have handled these two use cases.

We have used a number of cyber attacks definitions from the internet to present our cyber security answers.
We would like to give credit to these websites for great work and we hope that we are not violating any of their copyright.


Methods of Distributed Denial OF Service (DDoS) Attacks
The goal of a denial of service (DoS) attack is to overwhelm the target system resources and cause it to stop functioning. This would prevent access to the system users.

Distributed denial of service (DDoS) is a variant of DoS in where coordinated attackers compromised of a large number of computers or other devices against the target system. DDoS attacks could also be a decoy to other cyber threats. These attacks would start a denial of service to capture the attention of security staff and generate confusion, while hackers carry out more attacks aimed at stealing data or causing other damage.

Botnets:
Systems under hacker control that have been infected with malware. Attackers use these bots to carry out DDoS attacks. Large Botnets can include millions of devices and can launch attacks at devastating scale.

Use Case # 1- The AWS DDoS Attack in 2020
We estimate 2.3 terabytes per second is equal to 1 billion packet per second.

Our Chip Protection Against Botnets:
There is two facts we need to mention:

         • A single modern server processes over one million HTTP requests per second
         • A router can move as many as 60 million packets of data every second.

Therefore, AWS DDoS Attach would be handled as follows:

         1 billion packets / 60 million packets = 17 routers

The web traffic would be composed of the following request types:

         1. A client request using our chip not hacked
         2. A client request using our chip - hacked (Botnets attack)
         3. A client request not using our chip - not hacked
         4. A client request not using our chip - hacked (Botnets attack)
         5. A visitor request
         6. Botnets attack
         7. Misc- others requests

The total number of request of all the above would be = as we estimate 2.3 terabytes per second is equal to 1 billion packet per second.

Our Chip cyber defense is composed of the following:

         1. Outbound Chip (compressing-encrypting)
         2. Inbound Chip (decompressing-decrypting)
         3. Virtual Machine Learning Server - Monitoring and Reporting - Prevention and Remedy


Our chip would be connected to the routers and get packets from the routes. Therefore it is critical to have the same speed of the router if not faster. Our chip would have its own CPU, clock, core memory, Cache and IO. The chip programs would be embedded in the chip. The speed of decompression-decryption would be determine by our chip manufacture (chip partners and chip builder). Our chip can also has its own box running independently or a part of a firewall or bare-metal server.

Our Virtual Machine Learning Server would be performing the time consuming processes and handling. Our Virtual Machine Learning Server would be communicating with chip using bits.

There is three level of defense:
Chip Level:
Our chip would decompress-decrypt the packet data:
If the security fields are not matching the chip's stored and calculated values, then the chip has the option of discarding the packet plus transfer the packet to Virtual Machine Learning server for further analysis.
If the security fields are matching the chip's stored and calculated values, then the chip would forward the packet to next level of packet handling processes plus send a copy of the packet to Virtual Machine Learning server for tracking and further analysis

Virtual Machine Learning Server Level:
Based the load, Virtual Machine Learning Server would analyze the packets, make decision and start Prevention processes. Virtual Machine Learning Server would store the packets using speedy buffer and local Network-Attached Storage (NAS) for tracking packets. Our Machine Leaning server tools are intelligent and fast software tools for handling hackers attacks and perform both prevention and remedy processes.

Machine Learning Tools:
As we mentioned above every packet would be stored on NAS for further analysis. Our Machine Learning software would learning, analyzing these packets looking for patterns, trends, code, ..etc to add to our Machine learning library of tools.

Local Network-Attached Storage (NAS) for Tracking Packets:
NAS is a cheap secondary storage which is fast and expandable. A NAS device has the Capacity: 2TBbyte, 3TBbyte or 4TBbyte. The fact that the average packet size is about 1,500 byte, there is plenty of room for storage in crunch time. Analysis and processing on the stored packets can be done at any time based on system priority.

Let us do the math:
The Totals:

         • All the above (as we estimate 2.3 terabytes per second) would = 1 billion packet per second.
         • Max number packets one firewall would handle = 64,584 packets per second
         • Max number packets one router would handle = 60 million packets per second
         • Max number packets one web server would handle = 1 million users per second
         • Max number packets one bare metal server would handle = ?? per second


Best Case Scenario:
Our best case scenario would be our chip is as fast as the router:

         1 billion packets / 60 million packets = 16.667 (= 17) Inbound chip

Worst Case Scenario:
Out worst case scenario would be using the firewalls:

         1 billion packets / 64,584 packets per second = 15,484.67 (= 15,500) firewall

The following is our automated handling - Prevention and Remedy:

    • Assuming that we have capability of creating any number of virtual servers to handle the load
    • The Inbound chip would eliminate all request except chip clients packets (non-hacked and hacked).
    • The rejected packets are redirected to the Virtual Machine Learning Servers for analysis and handling
    • A copy of chip clients packets (non-hacked and hacked) are redirected to other Virtual Machine Learning Servers for analysis, tracking and handling.
    • The Hacked Index Field would be used to warn the sending client that there is a possible hacking on the client site and how sever it is.
    • Our routing analysis would be used to figure out which of the routing routers are possible suspect of being hacked.
    • The Virtual Machine Learning Servers performs: Identify, and Escalate

Use Case #2 - Russian Cyber Attach on the USA Federal Agencies:
Assuming that the hackers are hidden within the federal agencies, we have the following remedies:

Nothing Leave the Nestwork Without Being Compressed-Encrypted
Our Outbound Chip would compress-encrypt data section of every packet. This means all the attempt to steal data would end up with no value unless the hacker and their receiving agents undo the compression-encryption.

Scan for Hackers' Code
Our Machine Leaning tools would perform the scanning for these hackers code.

Tracking and Analysis
Assuming that we have copies of packets received and stored in NAS, then our Machine Leaning software tools would be looking for any information to track the hackers, IP addresses, malicious invasion.

Smurf Attack:
Sends Internet Control Message Protocol (ICMP) echo requests to the victim's IP address. The ICMP requests are generated from 'spoofed' IP addresses. Attackers automate this process and perform it at scale to overwhelm a target system.

Our Chip Protection Against Smurf:
Our protection against Botnets would apply here also.
Our Inbound chip decompresses-decrypts the packet data and it would be looking for ID fields. If these ID fields are not correct, the packet is skipped and sent to our Virtual Machine Learning Servers for prevention and remedy.

TCP SYN Flood Attack:
Attacks flood the target system with connection requests. When the target system attempts to complete the connection, the attacker's device does not respond, forcing the target system to time out. This quickly fills the connection queue, preventing legitimate users from connecting.

Our Chip protection against TCP SYN flood:
Our protection against Botnets would apply here also.
Our Inbound chip decompresses-decrypts the packet data and it would be looking for ID fields. If these ID fields are not correct, the packet is skipped and sent to our Virtual Machine Learning Servers for prevention and remedy.

Teardrop Attack:
Causes the length and fragmentation offset fields in IP packets to overlap. The targeted system tries to reconstruct packets but fails, which can cause it to crash.

Our Chip Protection Against Teardrop:
Our protection against Botnets would apply here also.
Our Inbound chip decompresses-decrypts the packet data and any discrepancies, would result in the rejection-skipping the packet and sent to our Virtual Machine Learning Servers for prevention and remedy.

Ping of Death Attack:
Pings a target system using malformed or oversized IP packets, causing the target system to crash or freeze.

Our Chip Protection Against Ping of Death:
Our protection against Botnets would apply here also.
Our Inbound chip would eliminate any packet with discrepancies. Skipped packets are sent to our Virtual Machine Learning Servers for prevention and remedy. All packets are store on local NAS for further analysis.

Man-In-The-Middle Attack (MiTM)
When users or devices access a remote system over the internet, they assume they are communicating directly with the server of the target system. In a MitM attack, attackers break this assumption, placing themselves in between the user and the target server. Once the attacker has intercepted communications, they may be able to compromise a user's credentials, steal sensitive data and return different responses to the user.

Our Chip Protection Against MitM:
Our packet data is compressed-encrypted and it has no value unless the hackers decompress-decrypt the packet data. Therefore, hackers would not be able to get any valuable data.
Our Inbound chip would eliminate any packet with discrepancies. Skipped packets are sent to our Virtual Machine Learning Servers for prevention and remedy. All packets are store on local NAS for further analysis.

Session Hijacking:
An attacker hijacks a session between a network server and a client. The attacking computer substitutes its IP address for the IP address of the client. The server believes it is corresponding with the client and continues the session.

Our Chip Protection Against Session Hijacking:
First the session and Cookies are compressed with rest of the data and fields. Regardless of any attempt to substituting the IP address, the Inbound chip would be able to flag that and handle it. Any packet with our compressed-decrypted data has no value to hackers unless they decompress-decrypt the packet data. Hacker would not be able to access information transmitted between client and server. We recommend that clients PC, laptop or any electronic devices to have their own chip also.

Replay Attack:
A cybercriminal eavesdrops on network communication and replays messages at a later time, pretending to be the user. Replay attacks have been largely mitigated by adding timestamps to network communications.

Our Chip Protection Against Replay:
ID and timestamp fields are compressed-encrypted. They also used to verify any issue with packet data. Any packet with our compressed-decrypted data has no value to hackers unless they decompress-decrypt the packet data. Hacker would not be able to access information transmitted between client and server. We recommend that clients PC, laptop or any electronic devices to have their own chip also.

IP Spoofing - use some else (trusted) IP address instead of yours (attacker):
An attacker convinces a system that it is corresponding with a trusted, known entity. The system thus provides the attacker with access. The attacker forges its packet with the IP source address of a trusted host, rather than its own IP address.

Our Chip Protection Against Spoofing:
ID and timestamp fields are compressed-encrypted. They also used to verify any issue with packet data. Any packet with our compressed-decrypted data has no value to hackers unless they decompress-decrypt the packet data. Hacker would not be able to access information transmitted between client and server. We recommend that clients PC, laptop or any electronic devices to have their own chip also.

Eavesdropping Attack:
Attackers leverage insecure network communication to access information transmitted between client and server. These attacks are difficult to detect because network transmissions appear to act normally.

Our Chip Protection Against Eavesdropping:
Any packet with our compressed-decrypted data has no value to hackers unless they decompress-decrypt the packet data. Hacker would not be able to access information transmitted between client and server. We recommend that clients PC, laptop or any electronic devices to have their own chip also.

Drive Attackers:
Can hack websites and insert malicious scripts into PHP or HTTP code on a page. When users visit the page, malware is directly installed on their computer; or the attacker's script redirects users to a malicious site, which performs the download. Drive-by downloads rely on vulnerabilities in browsers or operating systems.

Our Chip Protection Against Drive Attackers:
One of our Virtual Machine Learning servers job is to scan for malicious code.
The packet data is compressed and hackers would not be able to access information transmitted between client and server. We recommend that clients PC, laptop or any electronic devices to have their own chip also.