RU2754871C2 - Methods and device for last mile hyper-protected communication - Google Patents

Abstract

FIELD: data packets routing.SUBSTANCE: invention relates to the field of routing data packets in a communication message to various gateway nodes in the "cloud". To achieve the effect, packets are sent over different physical media, such as an Ethernet cable or Wi-Fi channel, and packets are masked by providing them with different source addresses. It also describes how to mute some participants in a conference call and how to store data files in a highly secure manner.EFFECT: provision of concealment of communication content between a client device, for example a mobile phone or laptop, and a network or a cloud of media nodes.25 cl, 181 dwg, 2 tbl

Description

References to related claims

This application takes precedence over US Provisional Application No. 62 / 480,696, filed April 3, 2017, and is a partial continuation of Application No. 14 / 803,869, entitled "Dynamic Secure Communications Network and Protocol," filed July 20, 2015, which in turn takes precedence Provisional U.S. Patent Application 62 / 107,650, filed January 26, 2015.

Each of the above applications is incorporated herein in its entirety by reference.

The technical field to which the invention relates

This invention relates to methods and apparatus for providing hypersecure Last Mile communication between a device and a network or cloud gateway.

Review of known technical solutions

The improvement of communication systems contributed to the progress of civilization from the earliest stages of development. From the use of couriers and messengers, on foot messengers or messengers on horseback; delivery of mail by train, car and plane; the appearance of telegram and telegraph, telephone, radio, television, computers, cell phones; The Internet, email and the world wide web; and more recently social networking, voice over the Internet, M2M connectivity, the Internet of Things (IoT) and the Internet of Everything (IoE), communication has always paved the way for the latest technology. With the introduction of each new generation of telecommunication technological equipment, the number of people between whom communication was established and the speed of information transfer between them also increased.

The effect of this trend is that humankind is more interconnected than ever before, with people trusting and relying on communication technology as a means of safely and securely delivering their confidential, personal, family and financial information only to those with whom they are. intend to contact. Knowledge and information can now be disseminated to millions of people in a matter of seconds. Friends and family members can communicate with each other from different parts of the world while doing other things along the way, and it's as easy as pressing a button. It is often said: "the world is small".

While this progress is extremely beneficial for everyone, our heavy reliance on technology has negative consequences as well. Unsurprisingly, when the communication system fails, such as during an earthquake or bad weather conditions, people become disoriented or even panic about being "turned off", even if this is a temporary inconvenience. The quality of service, or QoS (Quality of Service) of a communication system, is a critical indicator of communication efficiency. Peace of mind, financial well-being, self-awareness and even people's very lives depend on the reliability and security of their communications.

Another key aspect of a communications network is its ability to provide privacy, security, and security to its client. As communication technology has evolved, so has the sophistication of criminals and "hackers" intent on harming, disrupting systems, stealing money, and accidentally or maliciously harming others. Credit card fraud, password theft, identity theft, and the unauthorized posting of confidential information, personal photos, files, emails, text messages, and private tweets (stolen to compromise or blackmail the victim) are just a few examples of modern cybercrime.

To highlight the epidemic share of the security problem in modern open communication networks, the following are known examples of confidentiality breaches and cybercrime cases at the time of filing this patent application (examples are given in chronological order):

"Target: Information stolen from at least 70 million people" - CNBC, January 10, 2014.

"Hackers Send Malicious Emails Using Smart Refrigerators and TVs" - BGR (www.bgr.com), January 20, 2014

"Hacking Nest Thermostat Spurs Google Privacy Concerns" - Slash Gear (www.slashgear.com), June 24, 2014.

"Account hacks are calling into question the security of Line. Line, a toll-free calling and messaging app, was shaken by a recent spate of data breaches. The app found hundreds of accounts had been compromised." - Nikkei Asian Review, July 2, 2014 ...

"The NSA is verifying the data of ordinary Americans," - AP, July 6, 2014.

"Leaked Wi-Fi Passwords Through Smart LED Bulbs" - BBC News, July 8, 2014.

"Six people are accused of ticket fraud on StubHub." StubHub was targeted by hackers who used stolen passwords and credit card numbers to buy and sell thousands of tickets to pop concerts and New York Yankees games, New York authorities said. ", - Bloomberg, July 24, 2014.

"Research shows that the 'Internet of Things' is very easy to hack," - International Business Times (www.ibtimes.com), August 4, 2014.

"Russian Hackers Stole Over Billion Internet Passwords" - New York Times, August 5, 2014.

New Whistleblower Reveals US Secrets, Concludes Government - CNN, August 6, 2014

"Hackers Access Google Nest Thermostat Root in 15 Seconds" - Enquirer (www.theinquirer.net), August 11, 2014.

"Dairy Queen has been hacked by the same malware that hit Target" - Christian Science Monitor, August 29, 2014.

“Unauthorized access to nude photos of celebrities is a consequence of vulnerabilities in iCloud accounts,” - CBS News, September 1, 2014.

"Home Depot could be the new target of unauthorized credit card access ... Hacking Home Depot could have far more serious consequences than Target (40 million cards stolen in three weeks)" - Fortune, September 2, 2014.

"Fake Cell Phone Towers Intercept Calls Across the United States" - Business Insider, September 3, 2014.

"Hacking Attack: From Banks to Retail, First Calls of Cyberwar?" - Yahoo Finance, September 3, 2014

"Home Depot Confirms Payment Hacked in US and Canadian Stores" - Fox News, September 9, 2014.

"Yahoo is in a legal war with the US government over surveillance systems" - CBS / AP, September 11, 2014

"For hackers, your medical card is worth more than your credit card" - Reuters, September 24, 2014.

"Alarm: HTTPS has been hacked. Using a browser to attack SSL / TLS (BEAST) will be considered one of the worst hacks [spelling and punctuation of the original] , because it compromises connections in browsers that hundreds of millions rely on daily for security. people ", - InfoWorld, September 26, 2014.

"A Sony cyberattack that started out as a minor nuisance quickly escalated into a major scandal." - New York Times, December 30, 2014

Realizing how rapidly the rate of cybercrime, security breaches, identity theft and invasion of privacy is growing, the question arises: "Why are all these cyberattacks possible and what can be done to stop them?" While society strives to improve privacy and security, consumers also need more connectivity, cheaper, better communications, and improved convenience in financial transactions.

To understand what are the limitations of the quality characteristics and vulnerability of modern communication networks, storage media and network devices, you first need to understand how modern electronic, optical and radio communications work, and how data is transmitted and stored, including files, electronic mail, text, audio information and video images.

Circuit Switched Telephone Network Operation

Electronic communications include a large number of hardware components or network devices connected by wires, radio links, microwave links, or fiber optic links. Information is transferred from one device to another by sending electrical or electromagnetic energy through this network using various methods of embedding or encoding information "content" into the data stream. In theory, the laws of physics set the maximum data rate for such networks of equal speed of light, but in most cases, practical limitations in data coding, routing and traffic management, signal-to-noise ratio, and overcoming electrical, magnetic and optical noise and unwanted signals distort the flow of information. or create obstacles to its passage, limiting the capabilities of the communication network to some part of its ideal performance.

Historically, electronic data transmission was pioneered using dedicated "wired" electrical connections forming a "network" of communication between two or more electrical network devices. In telegraph operation, a mechanical key manually closes and opens the DC electrical network, magnetizing the solenoid, which in turn moves the metal lever, causing clicks in the listening device or "relay" at the same time intervals as the sender presses the key. In doing so, the sender used an agreed language, such as Morse code, to encode the information and turn it into an impulse stream. Likewise, the listener also had to understand Morse code - a sequence of long and short pulses called dots and dashes in order to decipher a message.

Later, Alexander Graham Bell developed the first telephone using the concept of "wave-like current," now called alternating current, to carry sound through an electrical connection. The telephone network consisted of two magnetic transducers connected by an electrical network, in which each magnetic transducer consisted of a movable diaphragm and a coil, or "voice coil," surrounded by a fixed shell of permanent magnets. While talking near this transducer, the change in air pressure caused by the sound causes the voice coil to reciprocate in the surrounding magnetic field, creating an alternating current in the coil. On the listener's side, the time-varying current flowing through the voice coil creates an identical oscillation and time-varying magnetic field opposite to the surrounding magnetic field, causing the voice coil to reciprocate in the same manner as a transducer recording sound. The resulting movement provides audio playback in the same way as the audio recorder. In modern and simple terms, when the transducer converts sound into electric current, it works like a microphone, and when the transducer converts electric current into sound, it works like a loudspeaker. In addition, since the transmitted electrical signal is analogous to an audio signal that is transmitted as a normal pressure wave in air, that is, sound, such electrical signals are now referred to as analog signals or analog waveforms.

Since the transformer, as described above, is used for both speaking and listening, during the conversation, both parties need to know when to speak and when to listen. As in a string made of interconnected cans, in such a system the caller cannot speak and listen at the same time. Although this one-way operation, called "half-duplex", may seem archaic, in fact it is still widely used in radio communication today in portable radios, and in modern telephony it is called "push-to-talk" (push to talk) or PTT.

Subsequently, full-duplex (ie, two-way or transceiver) telephones with separate microphones and loudspeakers, where parties could speak and listen at the same time, became widespread. But even today, full duplex telephony requires proper attention to prevent feedback, a condition in which received sound enters the microphone and returns to the caller, creating confusing echoes and sometimes unpleasant whistles - problems that are especially common in telephone communication over a long distance.

The early telegraph and telephone systems had another disadvantage - the lack of confidentiality. In these early implementations of communication networks, everyone connected to this network hears everything that is transmitted over the given network, even if he does not want to. In rural telephone networks, these shared networks were called "shared lines". The telephone system then quickly evolved into multichannel networks, in which the local telephone exchange connected leased lines directly to the phones of individual customers. At the local communication point, the system operator manually connected subscribers to each other through a switchboard using jumpers, and also had the opportunity to connect to another communication point, and for the first time provide telephone services "over a long distance". Large complexes containing a large number of relays forming telephone "switching" networks gradually replaced the human operator, and later they were replaced by electronic switches on vacuum tubes.

After Bell Laboratories developed the transistor in the late 1950s, automatic and local telephone exchanges replaced the fragile and hot vacuum tubes with cold, solid-state devices using transistors and then integrated circuits. As the network grew, the number of digits of the phone number increased from a seven-digit prefix and personal number, by adding area codes and finally country codes to handle international calls. Copper cables carrying voice calls quickly covered the entire world and crossed oceans. Regardless of the size of the network, the principle of operation remained unchanged - calls were a direct electrical connection or "network" between subscribers with voice transmission of analog signals and with call routing determined by an automatic telephone exchange. This telephone system eventually came to be called the "circuit-switched telephone network" or, colloquially, the Plain Old Telephone System (POTS). Circuit-switched telephony peaked in the 1980s and was subsequently replaced by "packet-switched telephony", discussed in the next section.

Almost parallel to the telephone network, the development of regular radio communication took place, which began with radio broadcasting in the 1920s. This broadcast was unidirectional, carried out by radio broadcasting stations on certain frequencies licensed by the government, reception was carried out by any number of radio receivers tuned to that broadcasting frequency or radio station. The broadcast signal was an analogue signal, either amplitude modulated (AM) or later frequency modulated (FM) in a dedicated portion of the licensed radio spectrum. In the United States, the Federal Communications Commission (FCC) has been established to manage the provision and regulation of such licensed bands. The concept of broadcasting has been extended to on-air television programs using radio broadcasts initially composed of black and white content and later in color. Subsequently, it also became possible to deliver television signals to people's homes, either using a radio relay satellite dish or via coaxial cables. Since any listener tuned to a particular broadcast frequency can receive the broadcast signal, the term "multicast" is now used for such unidirectional multi-user communication.

Simultaneously with the advent of radio broadcasting began the creation of the first two-way communications systems for commercial and military ocean-going ships, and by the beginning of World War II, radio stations had evolved into duplex hand-held transceivers, combining transmitters and receivers in a single device. Like telephone systems, the first radio systems operated in "simplex" mode, allowing only one broadcasting station to transmit on one radio channel while the rest listened. By combining transmitters and receivers operating at different frequencies, simultaneous transmission and reception at each end of the radio link became possible, allowing full duplex communication between the two parties.

However, to prevent overlapping transmission from multiple parties, a protocol called half-duplex or push-to-talk (push-to-talk) is commonly used to control the link, which allows only first-come, first-out transmission on a specific channel. Standard industrial types of radios using analog modulation include amateur (licensed or publicly available) radios, marine VHF radios, UNICOM (Universal Integrated Communication) radios for air traffic control, and FRS radios for face-to-face communications. In these two-way radio networks, radio stations send their data over specific frequency "channels" to a central radio tower, and the tower amplifies and retransmits the signal, transmitting it throughout the radio network. The number of available frequencies transmitting information in the broadcast domain determines the total system bandwidth and the number of users that can simultaneously independently exchange data in this radio network.

To expand the overall radio network capacity to accommodate more subscribers, the concept of a cellular network, in which a large area is broken up into smaller pieces, or "cells" of radio communications, was demonstrated in the 1970s and gained widespread acceptance over the course of a decade. The cellular concept was to limit the broadcast range of the radio tower to a smaller space, i. E. shorter communication range, and, therefore, to be able to use the same frequency bands for the simultaneous operation of different subscribers located in different cells. For this, software has been created to control call switching when moving from one cell to a neighboring cell without "signal loss" and sudden call disconnection. Just like the traditional telephone network (POTS), full duplex radio communications, and radio and television broadcasting, cellular networks were originally analog in nature. To control the routing of calls, a telephone number system has been adopted to determine the proper wireless electrical connection. This choice was also beneficial in that it made it easy to connect the new wireless cellular network to the traditional "wired" telephone system, allowing interconnection and interoperability between the two systems.

Beginning in the 1980s, telephone and radio communications, along with radio and television broadcasting, began an inexorable transition from analog to digital communication methods and formats, which was driven by the need to reduce power consumption and increase battery life, improve quality by increasing signal ratio -noise, as well as start paying attention to the need to transmit data and text by voice. Radio formats such as EDACS and TETRA have emerged, capable of simultaneously providing one-to-one, one-to-many, and many-to-many communication modes. Cellular communications also quickly moved to digital formats such as GPRS, as did television broadcasting.

By 2010, most countries had stopped or were in the process of ending all analogue television broadcasting. Unlike broadcast TV, cable TV providers did not have to go digital and maintained a hybrid mix of analog and digital signals until 2013. Their final transition to digital methods was motivated not by government standards, but by commercial reasons - the need to expand the number of available network channels in order to be able to deliver high-definition (HD) and ultra-high-definition (UHD) content, offer more Pay TV (PPV) services, also known as "one-way data transmission"), as well as provide high-bandwidth digital communication services for its customers.

While it is customary to correlate the transition of global communications networks from analogue to digital with the advent of the Internet and, more specifically, with the adoption and widespread adoption of the Internet Protocol (IP), the digitalization preceded the commercial acceptance of IP in telephony, providing if without accelerating, universal communication transition to IP and "packet-switched networks" (discussed in the next section).

The "Subscriber Network" (PSTN) has led to the evolution of circuit-switched telephony, including the interconnection of radio, cellular, PBX, and POTS connections and subnets, each of which includes heterogeneous technologies. This network includes subscriber network gateways connected by high-capacity trunk lines, as well as, for example, a gateway, a cellular network, a mini-PBX and a two-way radio network connected via wired connections. Each subnet operates independently, controlling devices of the corresponding type.

The subscriber communications network also connects to circuit-switched cellular networks using the analog and digital protocols AMPS, CDMA and GSM. Through the cell tower, circuit switched cellular networks are connected using standardized cellular radio frequencies to mobile devices such as cell phones. In the case of GPRS networks, add-ons to GSM technology, circuit-switched cellular networks can also connect to tablets, while providing low-speed data and voice transmissions. Full duplex radio networks such as TETRA and EDACS connect subscriber networks to handheld radios and larger embedded and desktop radios via high power radio towers and radio connections. Typically used by police, ambulance, paramedics, firefighters, and even port officials, these full-duplex radio networks are also considered service and communications networks, and are intended for government, municipal and emergency responders rather than ordinary consumers. (Note: As used herein, the terms "desktop", "tablet" and "laptop" are used as abbreviated references to their respective types of computers.)

Unlike POTS, cellular networks, and PBXs, which use traditional phone numbers to route calls, full-duplex radio networks use dedicated radio channels (rather than phone numbers) to establish radio links between the tower and the mobile devices it serves. Thus, intercom systems retain a distinct and unique distinction from cell phone networks for ordinary consumers.

It follows from this that the subscriber communication network flexibly combines subnets of different types. It is this diversity that determines the intrinsic weakness of today's circuit-switched networks — the ability to interoperate subnets. Because different subnets do not communicate according to any common control protocol or language, and because each technology handles data and voice communications differently, these different systems are essentially incompatible, except for their limited ability to place a telephone call through the main subscriber trunk. communication networks or long-distance trunk lines. For example, during the 9/11 terrorist attack at the World Trade Center in New York, many rescuers from different parts of the United States crowded in Manhattan trying to help fight the disaster, only to find out the radio communication system, their radios were incompatible with the equipment of volunteers from other countries and cities, making it impossible to administer centralized command and control relief efforts. Due to the lack of standardization of the communication protocols of their radios, these radios simply could not communicate with each other.

In addition, with direct electrical and radio connection of circuit-switched telephone networks, especially using analog or unprotected digital protocols, it is not difficult for a hacker to use a radio scanner to find active communication channels and analyze, select, eavesdrop or intercept conversations occurring at this time. Since the subscriber network forms a "always on" channel or communication network between the communicating parties, a hacker has enough time to identify the connection and "exploit" it either legally by government interceptions ordered by a federal court, or criminally by cybercriminals or government agencies carrying out illegal, prohibited or unauthorized surveillance. The definitions of legal and illegal espionage and surveillance and the network operator's obligation to cooperate in these activities vary widely from country to country and are the subject of heated debate among global companies such as Google, Yahoo and Apple operating across many international borders. Communications networks and the Internet are global and borderless, but the laws governing such electronic information are local and subject to the jurisdictional government body that currently controls domestic and international communications and commerce.

Regardless of its legality or ethics, electronic tracking and surveillance are commonplace today, ranging from monitoring by ubiquitous CCTV cameras located at every street corner and over all highways and subway lines to sophisticated hacking and decryption of codes performed by various departments and agencies. national security of states. Despite the fact that all networks have vulnerabilities, archaic and insufficient means of protecting subscriber communication networks make them especially easy to hack. Thus, the subscriber communication network, even connected to a secure modern network, is a weak link in the overall system and creates a vulnerability that allows one to overcome protection and commit cybercrimes. However, it will still take many years, if not decades, to exit the WAN and completely replace it with an IP-based packet-switched network. Such packet-switched networks (discussed below), although more modern than the subscriber communications network, are still not immune to overcoming defenses; hacking; denial of service attacks or disclosure of confidential information.

Operation of a packet-switched communication network

If the operation of a modern circuit-switched telephone network can be figuratively represented as two cans connected by a string, then the work of a post office can serve as a similar figurative representation of the operation of packet-switched communication networks. In this approach, text, data, voice and video are converted into files and digital data streams, and then this data is combined into quantized "packets" of data that are transmitted over the network. The transmission mechanism is based on email addresses that uniquely identify where the data packet is sent and where it comes from. The format and communication protocol also provide for the inclusion of information about the nature of the data contained in the package, including the content intended for the program or application in which it will be used; and equipment providing physical links and electrical or radio connections for packet transmission.

Born in the 1960s, the concept of packet-switched networks was created in the paranoid Cold War era following the launch of a Soviet satellite. At the time, the US Department of Defense (DoD) expressed concern that nuclear missile strikes from space-based facilities could destroy the entire US communications infrastructure, suppressing its ability to respond to a preemptive Soviet strike, and that vulnerability to such an attack could indeed provoke her. Therefore, the DoD funded the creation of a redundant communications system or lattice "network" in which the network's ability to transfer information between military targets could not be compromised by destroying any particular data link or even a large number of data links on the network. This system, called ARPANET, became the parent of the Internet and the notorious Eve of modern digital communications.

Despite the creation of a packet-switched network, the explosive growth of the Internet did not take place until the 1990s, when the combined impact of the first easy-to-use Mosaic web browser, the emergence of hypertext-based web pages, the rapid adoption of the World Wide Web, and widespread use of e-mail has not occurred the global adoption of the Internet platform. One of the founding principles - no centralized control or the need for a central computer - encouraged widespread use of the Internet, in part because no country or government could stop it (or even fully grasp the global implications of this), and also because its user base consisted of consumers working on their newly acquired personal computers.

Another far-reaching consequence of the growth of the Internet has been the standardization of the Internet Protocol (IP) used to route data packets across the network. By the mid-1990s, Internet users realized that the same packet-switched network that carries data could also be used to carry voice, and VoIP emerged shortly thereafter. Although the concept theoretically allowed anyone with Internet access to make voice communications over the Internet for free, the propagation delays in the network, i.e. delay, reduced speech quality and often made it illegible. Although latency has been reduced due to the introduction of high speed Ethernet lines, high speed Wi-Fi and 4G data, and the quality of the connection has improved in the Last Mile, the Internet itself was created to ensure accurate delivery of data packets, not for in order to guarantee the delivery of these packets at a given time, i.e. The Internet was not designed to operate on a real-time network.

Thus, the dream of using the Internet instead of the expensive services of a long-distance provider remained practically unfulfilled, despite the presence of such OTT providers (abbreviated as Over the Top) such as Skype, Line, KakaoTalk, Viper and others. OTT telephony suffers from quality of communication (QoS) due to uncontrolled network latency, poor audio quality, call drop, echo, reverberation, backpropagation, stuttering audio, and often even inability to place a call. The poor quality of OTT communication is inherently a drawback not of VoIP technology, but of the network itself, in which OTT providers do not have the ability to control the data path or delays with which communication is carried out. Basically, OTT providers cannot provide QoS because OTT communication works like a hitchhiker on the Internet. Ironically, VoIP-based communications are best used today by ISPs with low-latency, dedicated hardware networks — the telco companies that are least motivated to do so.

In addition to its intrinsic network redundancy, one of the greatest strengths of packet-switched communication is its ability to transfer information from any source to any destination, if the data is ordered in packets conforming to the Internet protocol and provided that the communication devices are connected to the network. and are connected to the Internet. The Internet Protocol manages the network's ability to deliver payload to its destination without caring or worrying about what information is being sent or which application will use it, while eliminating the need for custom APIs and expensive proprietary hardware. In many cases, even the applications associated with the payload are tuned to predefined formats, for example, to read an email, to open a web page in a browser, to view an image or video, view a firmware file, or read a PDF document, etc.

Because the universal file format it uses avoids reliance on proprietary or proprietary software, the Internet can be viewed as an "open source" communications platform capable of communicating with the widest range of networked devices, from computers to cell phones, from cars to household appliances. ... The most recent apt expression for this universal connectivity is the Internet of Everything (IoE).

A large number of computers, including high-speed cloud servers and cloud storage, are connected by high-bandwidth communications links, usually fiber optic, along with countless other servers that form the Internet's cloud.

Cloud figurativeness is appropriate here because there is no clearly defined boundary defining which servers are considered part of the cloud and which are not. On a daily or even minute basis, some servers may access the Internet, while others may be shut down for maintenance, which has no impact on the functionality and performance of the Internet. This is the advantage of a truly redundant distributed system — there is no single point of control and therefore no single point of failure.

The cloud can be connected to a user or network device using any wired, Wi-Fi, or wireless connection.

Packet-switched wireless telephony uses 3G cellular protocols, including HSUPA and HSDPA, as well as 4G / LTE. LTE or "long term evolution" refers to networking standards to provide interoperability with various cellular protocols, including the ability to seamlessly switch phone calls from one cell to another, even if those cells operate with different protocols. Note. For the purposes of this document, Last Mile refers to a data link between any type of client device, such as a tablet, desktop or mobile phone, and a cloud server. Depending on the direction of data transfer, the term "first mile" is also sometimes used to indicate the data transfer channel between the subscriber device initiating the transfer of data to the cloud server. In such cases, the last mile channel is also the first mile channel.

At a shorter communication range, the Wi-Fi hotspot connects smartphones, tablets, laptops, desktops, or networked home appliances and can be used in local wireless devices in homes, cafes, restaurants and offices. Wi-Fi extends to communications operating in accordance with the IEEE standards for the 802.11a, 802.11b, 802.11g, 802.11n single-carrier specifications, and more recently for the 802.11ac dual-band format. Wi-Fi protections based on a simple static login key are mainly used to prevent unauthorized access to a connection, but are not intended to protect data indefinitely from eavesdropping or hacking.

A distributed block of wired lines (router) can be connected with a fiber-optic cable, coaxial cable or Ethernet channel to a laptop, desktop computer, telephone, TV receiver or twisted-pair copper wires to telephone lines that go to the point-of-sale terminal serving fixed or wired lines communication centers of trade, including hotels, factories, offices, service centers, banks and homes. Wired connections can include fiber or coax distribution to your home, office, factory, or commercial organization, connected locally with a modem to convert high speed data (HSD) lines to Wi-Fi, Ethernet, or twisted-pair copper lines. In remote areas where there is no fiber or coaxial cable, digital subscriber line (DSL) connections are still used, but with significant reductions in data rates and connection reliability. Overall, taking into account access via wireless, Wi-Fi, and wired communications, it is predicted that by 2020 the number of objects connected to the Internet on a global scale will reach 20 billion.

Unlike circuit-switched networks, which establish and maintain a direct connection between devices, packet-switched communication uses an address to "route" a packet over the Internet to its destination. Thus, in packet-switched communication networks, there is no separate dedicated network supporting the connection between communication devices, and data passing through the Internet does not follow the same specific path. Each packet must find its way through a maze of interconnected computers to reach its destination.

For example, in routing an IP packet from a laptop to a desktop computer when using a packet-switched network connection, during operation, the first data packet sent from a laptop to a Wi-Fi router via a wireless connection is sent to a number of DNS servers, DNS (Domain Name Server ) - domain name server. The task of a number of DNS servers is to translate the text name or phone number of the destination device, in this case a desktop computer, into an IP address. Once determined, the IP address is passed from a number of DNS servers back to the sender's address, i.e. notebook. This address, which is used to identify the device, is used to route data packets over the network.

After that, the laptop collects the IP data packets and sequentially starts sending them to the addressee, first, for example, via the Wi-Fi radio module to the nearby Wi-Fi router, and then through the network of routers and servers acting as intermediate routers to the addressee. Routers and a number of computer servers acting as routers together form networks that operate either as nodes on the Internet or as points of presence (POP), i.e. limited connectivity gateways capable of accessing the Internet. While some routers or servers that act as points of presence connect to the Internet with only a small number of neighboring devices, other servers are connected to a large number of devices and are sometimes referred to as "superpoints". For clarity, it should be noted that the network language term POP should not be confused with the plain old post office (POP) application name or the regular post office used in email applications.

Each router or server acting as a router contains a routing table in its memory files that identifies the IP addresses that it can address, and possibly also the addresses that the routers above it can address. These routing tables are automatically downloaded and installed on every router the first time you connect to the Internet, and are usually not loaded when a packet is routed through the network. When an IP packet enters a router, point of presence, or superpoint of presence, the router reads enough of the IP address, usually the most significant digits of the address, to know where to route the packet further on its way to the destination. For example, a packet sent to Tokyo from New York can go first through Chicago, then through servers in San Francisco, Los Angeles, or Seattle, and then to Tokyo.

Since the number of routers a packet passes through and the available data rate for each of the connections between the routers vary in infrastructure, network traffic and load, there is no way to determine which path is the fastest or best.

Unlike circuit-switched telephony, which establishes and maintains a direct connection between clients, there is no universal intelligence for data packet switching browsing the Internet to decide which path is the best, optimal, or fastest to route a packet, and there is no guarantee. that two sequentially sent packets will go along the same route. Thus, the packet "determines" its path through the Internet based on the priorities of the companies operating the routers and servers that the packet passes through. Each router essentially contains specific routing tables and routing algorithms that determine its preferred routes based on the state of the network. For example, router preferences can set a high priority for sending packets to other routers owned by the same company, balancing traffic among connections to neighboring routers, finding the shortest latency for the next router, making direct deals with strategic business partners, or creating a rush line for VIPs. -clients by passing as many intermediate routers as possible. When a packet arrives at a router, there is no way to know if the routing options have been chosen by a specific POI with the best interest in the sender or the network server operator.

So, in a sense, the route a packet takes is a matter of time and luck. In the previous example of routing from New York to Tokyo, the route itself and the resulting quality of service can vary significantly depending on even small deviations in the path, i.e. in nonlinear equations of the so-called "butterfly effect". Consider the case where a packet from New York goes through "Router A" in Chicago and due to temporarily high traffic in California, it will be sent to Mexico City rather than California. The Mexico City router then sends the IP packet to Singapore, from where it finally goes to Tokyo. The next packet is sent through "Router B" to Chicago, which, with low traffic at this point in time, routes the packet to San Francisco and then straight to Tokyo in just two steps. In this case, the second packet may arrive in Tokyo earlier than the first, directed along the longer route. This example clearly illustrates the problematic issue of using the Internet for real-time communications, for example, for transmitting online video or real-time VoIP technology, namely that the Internet is not designed to provide guaranteed transmission times or to control transmission delays. The latency can vary from 50 ms to 1 s or more only depending on whether a packet passes through two servers or fifteen.

Lack of control over Internet routing is a problem for real-time applications and, in particular, is the reason for poor quality of service for OTT providers who try to organize the provision of VoIP (Voice over Internet Protocol) telephony, using the Internet as a free infrastructure for their services. Since OTT providers have no control over routing, they cannot control network latency. Another problem with packet-switched communications is that it is easy to take over data without being discovered. If a pirate intercepts a packet and determines the IP address of its source or destination, he can intercept data from compromised routers in various ways and either eavesdrop on it, or redirect traffic through his own pirate network to spy on conversations and even decrypt encrypted files.

The source and destination IP addresses of the sender and receiver and other important information used to route the packet (and also used by pirates to crack the packet) are listed as digital data - IP packets, IP datagrams, or TCP / IP packets. An IP packet contains digital information that defines the physical connection between devices, how the data is organized for device communication, the network routing of the packet, the means to ensure the accuracy of the payload (payload) and the payload data type, and then the payload data itself to be used. various application programs.

An IP packet is sent and received sequentially as a string of sequential digital bits organized in a specific way called the Internet Protocol and set by various standards bodies, including the Internet Engineering Task Force (IETF) and others. The standard guarantees that any IP packet conforming to the established protocol can be transmitted and understood by any network device conforming to the same IP standard. Connecting and interoperating network devices and applications connected to the Internet is a feature of the Internet and is a guiding principle of the Open Source Initiative (OSI) that prevents any company, government, or individual from taking control of the Internet or limiting its availability or functionality. possibilities.

The OSI Model is an abstract construct of seven layers of functionality that precisely defines the format of an IP packet and each segment of that packet. Each part or "segment" of an IP packet corresponds to data applied to a function of a particular layer of the OSI model. These seven layers of the OSI model fulfill the following roles:

Layer 1 - the physical layer - contains hardware-specific information defining the physical nature of communications as electrical, radio, and optical signals, and how these signals are converted into bits for use in a communications system. The task of the PHY layer (abbreviation for Physical layer) is to convert specific transmission media such as Wi-Fi radio, Ethernet, serial ports, optical fiber, 3G or 4G cellular radio, DSL on copper twisted pair into a bit stream , USB, Bluetooth, cable or satellite TV, digital audio broadcasting, video or multimedia content. In an IP packet, the preamble represents Layer 1 data and is used to synchronize the entire data packet or "frame" with the transmitting and receiving equipment.

Layer 2 is a link layer containing bits arranged in frames, which defines the rules and means by which bit streams transmitted from physical layer 1 are converted into interpretable data. For example, bitstreams based on Wi-Fi radio data can conform to any given IEEE standard, including 802.11a, b, g, n, and ac; 3G radio signals can be modulated using HSDPA or HSUPA high speed packet access methods; modulated light signal in fiber optic line or electrical signals in coaxial cable can be decoded into data according to DOCSIS 3 standard, etc. In an IP packet, Layer 2 data encompasses the remainder of the packet, preceded by a "bearer header" and a bearer terminator, which collectively determine when the covered payload starts and ends, and provides loss control. One of the key elements of Layer 2 data is the MAC or media access address, which is used to route data traffic to specific Ethernet addresses, radio links, or specific hardware transceiver lines.

Layer 3 - the network layer or Internet layer - contains packets called "datagrams" containing Internet Protocol (IP) information used to route an IP packet, including whether the packet contains IPv4 or IPv6 data and the corresponding source IP addresses and the recipient, as well as information about the nature of the payload contained in the packet, for example, whether this type of transmission control protocol uses TCP (Transmission Control Protocol), User Datagram Protocol (UDP), etc. Layer 3 also includes a function to prevent the formation of "immortal" packets - IP packets that are never delivered, but never die. A special type of Layer 3 packet, ICMP (Internet Control Message Protocol), is used to diagnose network health, including the well-known "ping" function. In an IP packet, layer 3 contains the "IP header" and includes the payload contained in the transport and upper layers.

Layer 4 - transport layer - contains data segments that determine the nature of the connection between communication devices, where the UDP protocol defines the minimum description of the connectionless payload, namely how large the payload is, whether there are lost bits and which application service (port) will be use the delivered data. UDP is considered connectionless because it does not acknowledge delivery of the payload, instead relying on the application to check for errors or data loss. Typically UDP is used for time sensitive communications such as broadcast, multicast and online transmission, where packet retransmission is not used. In contrast, TCP provides a virtual connection, confirming that the packet and payload have been delivered reliably before sending the next packet, and resends the undelivered packets. TCP also checks the integrity of the delivered packets against a checksum and includes a means to reassemble the untimely delivered packets in their original order. Both TCP and UDP define the send and receive ports, a description of an upper layer service or application, such as a web server or mail server, associated with the information contained in the Layer 4 payload. In an IP packet, Layer 4 contains the TCP / UDP header. and contains information about the data / payload, including content intended for use by the upper layers 5, 6, and 7 of the OSI model.

Layers 5, 6 and 7 - upper or application layers - describe content delivered over the Internet as data / payload. Layer 7, the Application Layer, is the highest layer in the OSI model and builds on the six basic layers of the OSI model to support both open source and proprietary application software. Commonly used Layer 7 applications include email using SMTP, POP, or IMAP; Web browsing using HTTP (Chrome, Safari, Explorer, Firefox); file transfer using FTP and terminal emulation using Telnet. Proprietary applications include a suite of Microsoft Office products (Word, Excel, PowerPoint), Adobe Illustrator, and Photoshop; applications for working with Oracle and SAP databases; financial software Quicken, Microsoft Money and QuickBooks; plus audio and video players (eg iTunes, QuickTime, Real Media Player, Window Media Player, Flash), and document readers like Adobe Acrobat Reader and Apple Preview. Level 7 applications also typically use built-in objects, syntactically defined by Level 6 - Representative Level - which includes text, graphics and images, sound and video, document presentations such as XML or PDF, and security features such as encryption. Level 5 - session level - establishes the ability to connect multiple applications, for example, import one object into a file of another program and control the initiation and termination of a session.

As described above, the seven-layer OSI model defines the functions of each layer, and the corresponding IP packet includes the data related to each layer, one inside the other like a nesting doll ... An outer packet or physical layer 1 defines the entire IP frame and contains information related to all higher levels. Within this physical data, a layer 2 data frame describes a data link and contains a layer 3 network datagram. This datagram, in turn, describes the Internet layer as a payload, and a layer 4 data segment describes the transport layer. The transport layer transfers top-level data as payload, including content from levels 5, 6, and 7. This seven-level nesting is sometimes also mnemonically associated with the English phrase " a ll p eople s eem t o n eed d ata p rocessing" ( it seems that all people need data processing), in which the first letters of the words correspond to the first letters of the names of seven levels, starting from the topmost: a pplication (applied), p resentation (representative), s ession (session), t ransport (transport ), n etwork (network), d ata-link (channel) and p hysical (physical).

While the lower layers — physical and link — are hardware-related, the middle layers of the OSI model, which are included in an IP packet to describe network and transport information, are completely independent of the hardware platform used to communicate and deliver the IP packet. Moreover, the upper layers, which are included as the transport layer payload, are specific only to the applications for which they are intended and operate completely independently of the packet routing and delivery over the Internet. This separation allows each layer to be independently controlled, supporting a huge number of possible combinations of technologies and users without requiring organizational approval of the package format or validation of the package payload viability. Incomplete or incorrect IP packets are simply dropped. Thus, packet-switched networks are capable of routing, transporting, and transferring a variety of application-related information in heterogeneous communication environments in a consistent manner between any network device or entity connected to the Internet.

In conclusion, it should be noted that circuit-switched networks require one direct connection between two or more communicating parties (similar to the traditional telephone network of the last century), while packet-switched networks distribute documents, sound, video and text over several packets. , transmit these packets over multiple network paths (similar to a post office using the best option to ensure accurate and timely delivery), and then reassembling the original content with confirmation that nothing is lost along the way. Comparison of circuit switched subscriber network and VoIP technology with packet switching is presented in the following table:

Network Subscriber Communications Network (PSTN) Internet Technology Circuit Switched Packet switched Connection Dedicated electrical communication line Each packet is routed over the Internet Data transfer Real time (network) Best option (package) Signal Analog or digital Digital, IP, VoIP technology Content Voice Voice, text, data, video Baud rate Low High Error control Absent or minimal Deep Impact of damage to the communication line Invalid or interrupted call Changing the call route Effect of power failure The power supply is provided by the network Backup battery required

It should be noted here that although the Subscriber Network (PSTN) operates in real time, using electrical line connections, using "best practices" for packet and payload delivery, as opposed to a post office using any car and postmen to eventually deliver the mail, even if it's already late. Networking and communication operations are described in more detail in the reference section of a related patent application titled "Dynamic Secure Communication Network and Protocol".

Considering the quality of the network, several factors are assessed, namely:

скорость передачи данных, т.е. пропускную способность;

data transfer rate, i.e. bandwidth;

качество обслуживания;

quality of service;

защищенность сети и данных;

network and data security;

конфиденциальность пользователей.

user privacy.

Based on the above considerations, data rates are estimated in millions of bits per second (Mbps). In addition, QoS takes into account several other factors, including latency, audio quality, network stability, disruptions or frequent service interruptions, out of sync or connectivity, low signal strength, slow application performance, and functional network redundancy in an emergency.

Cybersecurity aims to prevent network attacks and prevent unauthorized access to traffic and data content, including cybercrime, snooping, IP packet interception, port polling and denial of service attacks, profiling, fraud, cyber infection, surveillance, etc.

Quality of service

Quality of Service describes the performance of a network in terms of capacity, bandwidth, latency, data rate, scalability, data integrity, audio quality, bit error rate, and other performance parameters.

For security-related programs, files and checks, the accuracy of the data is the determining factor. The importance of the factors depends on the nature of the payload carried over the packet-switched network. In contrast, for voice and video, including real-time applications, factors affecting the delivery time of the package are key. Quality metrics such as video, voice, data, and text vary by app. A good network condition, characterized by an acceptable IP packet waveform at a high data rate, is a condition characterized by minimal latency, clean strong signal, no signal distortion, stable performance, and no packet loss. Intermittent networks, characterized by packet waveforms with reduced bit rates with random interruptions, affect video functions most significantly, causing painfully slow loading of regular video and unacceptable quality of online video. Overloaded networks operating at a reduced effective data rate with regular short interruptions, for which an example of an IP packet waveform is shown in the figure, not only seriously degrades video quality due to jerky choppy movements, blurry images and incorrect color and brightness, but also also begin to degrade the quality of sound or voice communication due to distortion, echo and even the loss of entire sentences from a conversation or soundtrack. However, in congested networks, data can still be delivered using TCP through repeated relay requests.

Unstable networks exhibit low throughput with multiple stops and unpredictable data transfer times. Unstable networks also contain corrupted IP packets, shaded in dark in the 610D waveform figure, which must be resent for TCP transmission, and are simply discarded as corrupted or invalid data for UDP transmission. When the quality of the network drops to a certain level, even emails become intermittent and IMAP (Internet Message Access Protocol) synchronization is disrupted. Thanks to the lightweight data format, most SMS and text messages will be delivered, albeit with some delay, even with severe network congestion, but attachments will not be downloaded. In unstable networks, any application can be disrupted, and even the normal operation of a computer or mobile phone can be suspended while waiting for a file to be delivered. In such cases, the video freezes, the sound changes so much that it becomes unintelligible, VoIP connections are dropped many times, sometimes even more than a dozen times within a few minutes of the call, and in some cases it is not possible to connect at all. Likewise, the transmission of emails stops or freezes, and the circular icons on the computer screen rotate endlessly. Task progress bars stop altogether. Even text messages are dropped and become "undeliverable".

Although there are many factors that can cause network instability, including power failures in key management servers and superpoints of presence, call congestion, transfer of huge data files or UHD movies, and active DoS attacks (Denial of Service) to selected servers or networks, the key factors used to monitor network QoS are packet drop rate and packet delay. Packet drops occur when an IP packet cannot be delivered and is defined as "immortal" after the timeout is exceeded, or when a router or server detects a checksum error in the IP packet header. If UDP is used to transmit a packet, the packet is lost, and Application Layer 7 must be smart enough to know that something has been lost. If TCP is used when transmitting a packet on transport layer 4, a request will be generated to retransmit the packet, which will increase the load on an already potentially congested network.

Another factor that determines QoS - propagation delay - can be quantified in several ways: either as the delay in the transmission of an IP packet from node to node or, in a unidirectional transmission, from sender to recipient, or, alternatively, as the round trip time from the sender to the recipient and back to the sender. The effect of propagation delay on packet delivery when using UDP and TCP data transmission protocols is different. As the intermode propagation delay in the network increases, the required round-trip time increases, for example, during a conversation using VoIP technology. In the case of UDP transmission, round trip time increases linearly with propagation delay. Because long propagation delays are associated with a higher bit error rate, the number of dropped UDP packets increases, but because UDP requests retransmission of dropped packets, the linear dependence of round trip time on latency persists with increasing latency. TCP transmission shows significantly longer round trip times for each packet sent than UDP due to the handshake required to confirm delivery of the packet. If the bit error rate remains low and most packets do not require retransmission, then the TCP propagation delay increases linearly with the intermode propagation delay. If, however, the communication network becomes unstable as the propagation delay increases, then the round trip time associated with TCP transmission increases exponentially due to the protocol's need to retransmit dropped packets. Thus, TCP is contraindicated for time-sensitive applications such as VoIP and online video.

Since all packet communication is statistical and there are no two packets with the same propagation time, the best way to estimate network delay for a unidirectional transmission is to measure the round trip time of a large number of IP packets of the same size and then halve it to estimate the unidirectional delay. Latency up to 100ms is considered excellent, up to 200ms is very good, and up to 300ms is still acceptable. The 500ms propagation delays that OTT applications often encounter on the Internet create an uncomfortable experience for users and interfere with normal conversation. In particular, during voice communication, such long propagation delays create a "bad" sound and can lead to reverberation, creating a "ringing" or metallic sound, interrupting normal conversation when the other party is waiting for a response to their last comment, and as a result, speech becomes distorted or illegible.

To be clear, unidirectional latency differs from a ping test performed with an ICMP Layer 3 utility (such as the free network tester at http://www.speedtest.net), in part because ICMP - the packets are usually smaller than real IP packets, because the ping test does not use the TCP "resend request" feature, and also because there is no guarantee that when transmitted over the public Internet network, the ping test route will be match the actual route of the package. In fact, it turns out that if the ping test signal arrives with a long delay, then this means that something is wrong with the network or with some kind of connection between the device and the network, for example, in a Wi-Fi router or in the area of the latter miles, but a good ping test alone cannot guarantee a low propagation delay for a real packet.

In order to increase the security of the network, encryption and verification methods are often used to prevent hacking, interception or espionage. But sophisticated encryption and encryption protocols with multiple keys constantly confirm the identity of the interlocutors, create additional delays and thereby increase the effective network latency, reducing the quality of service by increasing security.

Information security and confidentiality of information

The basic concepts in the field of communications include information security and information confidentiality. The two concepts, although related, are somewhat different from each other. "Information security, including network security, computer security and secure communications, encompasses the methods used to control, intercept and prevent unauthorized access, misuse, modification or denial of service to a computer or communication network, resources available to the network or data contained in the network Such data may include personal information, biometrics, financial records, health records, private messages and recordings, and private photos and videos. Networked devices include cell phones, tablets, laptops, desktops, file servers, email servers, web servers, databases, personal data storage, cloud storage, internet-connected home appliances, connected cars, and public devices used by individuals such as cash registers or POS terminals, gas stations, ATM machines, etc.

It is clear that cybercriminals and computer hackers trying to gain unauthorized access to protected information are committing a crime. If the illegally obtained data contains personal information, the attack also violates the victim's privacy. However, on the other hand, breaches of confidentiality can occur without breaking the law and, in fact, cannot be prevented. In today's networked world, unauthorized use of a person's personal information can be carried out without violating information security requirements. In some cases, companies collecting data for one purpose may sell their database to other customers interested in using that data for another purpose. Even when Microsoft bought Hotmail, it was well known that the mailing list was sold to advertisers interested in sending information to potential customers. Whether such actions are considered a breach of information confidentiality remains controversial.

"Information confidentiality", which includes online privacy, computer privacy, and private communication, means a person's personal right or authority to control and use his or her personal and confidential information, including collecting, storing, sharing or exchanging information with others. Confidential information may include personally identifiable information, including height, weight, age, fingerprints, blood type, driver's license number, passport number, social security card number, or any personal information useful to identify a person without knowing their name. In the future, even a person's DNA map may become the subject of legal registration. In addition to personally identifiable information, there is non-personally identifiable information that may include the brands of clothing we buy; websites we visit frequently; do we smoke; do we drink alcohol; do we own a pistol; what car we drive; what diseases have you had during your life; whether there are hereditary diseases or ailments in our family, and even what kind of people like us.

This sensitive information, combined with public reports regarding personal income, taxes, property documents, criminal records, traffic violations, and any information posted on social media sites, form a powerful data set for stakeholders. The technology of deliberately collecting large data sets capturing demographic, personal, financial, biomedical and behavioral information, and analyzing this data by patterns, trends and statistical correlation, is today known as "big data." The healthcare system, including insurance companies, medical professionals, pharmaceutical companies, and even lawyers for doctors suspected of malpractice, are taking a very keen interest in personal information stored in the form of big data. Automotive and consumer goods companies also want access to such databases to guide their marketing strategy and advertising budget. Even politicians in recent elections have started looking for big data to better understand voter views and political controversies that should be avoided.

The confidentiality issue is not that big data captures personal information today (this is already a standard procedure), but whether this set of data stores your name or sufficient personally identifiable information to identify you without even knowing your name. For example, the US government initially stated that personal information collected by healthcare.gov used to sign the Affordable Care Act would be destroyed after private medical accounts were created. It then openly admitted recently that the third-party corporation that helped the US government to collect the data had previously signed a government contract giving it the right to store and use the collected data, which means that sensitive personal information released to the US government is not really confidential. ...

Finally, it should be noted that surveillance is practiced by both governments and crime syndicates using similar technological methods. Of course, criminals clearly do not have the legal right to collect such data, but cases of unauthorized surveillance by the state are darker practices that differ significantly from country to country. For example, the US National Security Agency has repeatedly pressured Apple, Google, Microsoft and other companies to secure access to their clouds and databases. Even the conversations and statements of government officials were monitored and intercepted. When asked whether Skype, a division of Microsoft, monitors the content of its subscribers' broadcasts, the CIO of Skype unexpectedly replied: "No comment."

Cybercrime and cyber surveillance methods - Focusing on the topic of cybersecurity, it should be noted that there are many means for gaining unauthorized access to device data, such as malicious and hacking technologies used to commit cybercrime and unauthorized entry into supposedly secure networks.

For example, a person with a tablet connected to the Internet might want to call a business office phone, send a message to the TV, call a friend out of town on the phone, download files from a web storage, or send email through a mail server. While these applications are all common uses of the Internet and global communications systems, there are many opportunities for surveillance, cybercrime, fraud and identity theft across the network.

For example, for a tablet connected to a network via a cellular radio antenna and an LTE station, or via a short-range radio antenna and a public Wi-Fi base station, an attacker could control the radio link. Likewise, LTE calls can be monitored or analyzed by an intercepting radio or sniffer. The same eavesdropper can be configured to monitor Wi-Fi data transmission and on the receiving end over the cable between the cable modem transmission system (CMTS) and the cable modem.

In some cases, an LTE call can also be intercepted by a fake pirate tower by redirecting the communication channel between the tablet and the cell tower. Transmitting data over a packet-switched network to a router, server, and cloud storage is also vulnerable to man-in-the-middle attacks. Wired line connections can pick up calls on a POTS line from a Subscriber Line Network (PSTN) gateway to a telephone, and on a corporate PBX line from a PBX server to an office phone.

Through a series of security holes, spyware can be installed on a tablet, router, PSTN bridge, cloud storage, cable modem connection device (CMTS), or desktop computer. The Trojan can be installed on a tablet or desktop computer to phish passwords. The worm can also be used to attack a desktop computer, especially if the computer is running a Microsoft operating system with active X enabled. Finally, to launch denial of service attacks, the virus can attack any number of network devices, including servers, desktops and tablets. ...

Malware can operate in different parts of the communications network, where cyberattacks can include viruses, man-in-the-middle attacks, surveillance, and denial of service attacks. The last mile of the communications network provides even broader opportunities for malware and cyberattacks and is divided into three sections: local telephone company / network, last link, and device. Local telcos / networks include fiber optic cables, routers, cable modem connection devices (CMTS), coaxial / fiber optic cables, cable modems, Wi-Fi antennas, and LTE radio towers. This part of the network can include radio interception, spyware, virus and man-in-the-middle attacks.

In the last link - local connection to the device - the network connection includes a wired connection, a Wi-Fi connection, and an LTE / radio connection and is exposed to spyware, radio interception, eavesdropping, and a fake tower. The device itself, including tablets, laptops, desktops, smartphones, smart TVs, POS terminals, etc., is subject to many attacks, including spyware, Trojans, viruses, and worms.

Such surveillance and spy devices are readily available in commercial and online markets. This includes devices used to monitor traffic on local Ethernet networks and devices that provide the same functionality for monitoring Wi-Fi data and monitoring cellular communications. Despite the fact that the analysis of packets of cloud connections with fiber-optic cable was not identified as a threat, during the research it became obvious that non-invasive data interception for the optical communication line, i.e. one where the fiber optic cable does not need to be cut or at least temporarily disrupt its normal operation already exists.

In addition to using hacking and surveillance methods, there are a large number of commercial, readily available spyware programs for monitoring cell phone calls and data transmission over the Internet. Today, the best spy programs capable of successfully spying on employees, children and spyware offer a surprisingly wide range of functions, including tracking calls, photos and videos, SMS / MMS text messages, third-party instant messages, emails, GPS position tracking, Internet usage, address books, calendar events, listening, application control, and even remote control functions, collectively contain an alarmingly convincing number of ways to violate information confidentiality. Cyberattacks have become so frequent that they are monitored daily.

To launch a cyberattack, several stages or combinations of methods are usually involved, including:

анализ IP-пакетов;

analysis of IP packets;

опрос портов;

port polling;

профилирование;

profiling;

атаки с имперсонификацией;

impersonation attacks;

перехват пакетов;

interception of packets;

кибер инфицирование;

cyber infection;

наблюдение;

observation;

пиратское администрирование.

pirate administration.

IP packet analysis - Using radio monitoring devices, a cybercriminal can obtain a significant amount of information about a user, his transactions and his accounts. The content of an IP packet can be retrieved or analyzed at any point in the path between two users. For example, when a user sends a file, such as a photo or text in an IP packet from his laptop to his friend's mobile phone, a cybercriminal can detect the IP packet in one of several locations, intercepting the last link of the sender, intercepting the sender's local network, controlling the cloud. by intercepting the recipient's local telephone company or intercepting the last link of the recipient. The following data are available for observation in the intercepted IP packet: MAC addresses of layer 2 used in the information exchange of devices, addresses of layer 3 of the sender of the receiving side, i.e. the recipient of the packet, including the transmission protocol used, such as UDP, TCP, etc. The IP packet also contains the sending and receiving layer 4 port numbers, potentially allowing you to identify the type of service requested, as well as the data file itself. If the file is not encrypted, the data contained in the file can also be easily read by a cybercriminal.

If the payload is not encrypted, text information such as account numbers, usernames and passwords can be read and, if valuable, stolen and altered for criminal purposes. If the payload contains video or cryptographic information, some additional work needs to be done to determine which Application Layer 6 format is used to convey the content, but once it is identified, the content can be viewed, published, or even used to blackmail one or both parties. information exchange. Such a cyber attack is called a man-in-the-middle attack because the cybercriminal does not personally know any of the parties to the information exchange.

As stated earlier, the routing of IP packets in the cloud is unpredictable, so control of the cloud is more difficult because the cybercriminal must capture important information of the IP packet when it first encounters it, since subsequent packets may not follow the same route and analyze the packet. ... Capturing Last Mile data increases the likelihood of seeing a sequence of related packets from the same conversation, since local routers usually follow a prescribed routing table, at least until the packets reach a point of presence (POP) outside of the service area. the client's own operator. For example, a Comcast customer is likely to pass IP packets into a routing chain using full Comcast-owned network until the packet is geographically moved outside of Comcast's reach and service area.

If the sequence of packets transmitted between the same two IP addresses is observed for a long enough time, the entire conversation can be recreated piece by piece. For example, if SMS text messages are sent over the same network in the Last Mile, a cybercriminal can identify through IP addresses and port numbers that multiple IP packets carrying the text represent a conversation between the same two. devices, i.e. between a cell phone and a laptop. Therefore, even if the account number and password were in the body of different messages or were sent incompletely and spread across many packets, the coincidence of packet IDs still allows a cybercriminal to recreate the conversation and steal account information. Once the account details are stolen, attackers can either transfer money to an offshore bank or even usurp the account's authority by changing the account password and security settings, i.e. using identity theft on a temporary basis.

Even if the payload is encrypted, the rest of the IP packet, including IP addresses and port numbers, is not encrypted. After repeatedly analyzing a large number of IP packets, a cybercriminal with sufficient computing power can brute force systematically test each combination until he breaks the encryption password. Once the key is cracked, this packet and all subsequent packets can be decrypted and used by a cybercriminal. The likelihood of a login password being cracked by "guessing the password" is greatly increased when packet analysis is combined with the user and account "profiling" described below. It should be noted that man-in-the-middle attacks on communication devices are usually not used because the cybercriminal does not have direct access to them.

Port polling - Another way to hack a device is to poll a large number of Layer 4 ports by its IP address and check for a response to directed requests. When a cybercriminal determines, through packet analysis or other means, that the mobile phone has the target device's IP address, the cybercriminal launches a sequence of polling ports on the cell phone, looking for an unsecured or open port, service and maintenance port, or security evasion. While the hacker polling program systematically checks each port number, attacks usually focus on notorious ports such as port # 7 for ping, port # 21 for FTP, port # 23 for telnet terminal emulation, port # 25 for simple email, and etc. Each time a response is sent, the pirate learns more about the target device's operating system.

In the process of polling ports, the cybercriminal does not want to reveal his real identity, so he will use a hidden pseudo-address to receive messages, but not traced back to his personal device. Alternatively, cybercriminals can use a stolen computer and account, making it look like someone is trying to hack the target device, but if tracked down, it will lead to an investigation in an innocent person rather than an attacker.

Profiling - User and account profiling is the process by which a cybercriminal conducts research using publicly available information to learn more about the target, its accounts and its personal history in order to crack its passwords, identify accounts, and identify assets. Once a hacker obtains the target's IP address from traffic analysis or other means, he can use the "traceroute" utility to find the DNS server of the device account. Then, using the "Who is" function on the Internet, you can find out the name of the account holder. Then, during the profiling process, the cybercriminal searches the Internet to collect all available information about the account holder. The sources of information are such public records as property documents, data on car registrations, marriages and divorces, liens on property to secure the payment of tax, parking tickets, traffic violations, criminal records, etc. In many cases, the websites of universities and professional societies also contain a person's home address, email addresses, telephone numbers, and date of birth. By examining social networking sites such as Facebook, LinkedIn, Twitter and others, a cybercriminal can collect significant detailed information, including family and friends, pet names, addresses of former residence, information about classmates, major events in someone's life. , as well as photos and videos, including those containing sensitive details, family secrets and data on personal enemies.

The next step for a cybercriminal is to use this profile data to "guess" the user's passwords based on his profile to hack the target device and other accounts of that person. After a cybercriminal picks up the password for one device, the chances are high that it can go to other accounts, because people tend to use the same passwords to make them easier to remember. At this point, it may be possible to steal a person's identity, transfer money, make him the target of police investigations, and essentially ruin someone's life by stealing his entire fortune. For example, as described in the introduction to this document, after collecting a long list of passwords from stolen accounts, cybercriminals used those passwords to illegally purchase multi-million dollar premium tickets to concerts and sporting events using the same passwords and logins.

Impostors - When a cybercriminal impersonates someone else, does not use or uses illegally obtained secure credentials to gain access to messages and files under the false pretense of being an authorized agent or device, the cybercriminal acts as an "impostor." An imposter cyberattack can occur when a cybercriminal has sufficient information or access to a user account to usurp the victim's account, send messages on behalf of the victim, and deliberately distort their meaning on behalf of the owner of the compromised account. Recently, for example, a close friend of one of the inventors was hacked into the personal account of the "Line" messenger. After gaining control of the account, the cybercriminal sent messages to her friends with false information that "she was in a car accident and urgently needs money to borrow", specifying payment details to send the money. Unaware that the account had been hacked, her friends thought the request was real and rushed to save her financial situation. To avoid suspicion, the request sent to each friend included amounts of less than $ 1,000. Fortunately, before sending money, one of her friends called her to double-check her billing information and the fraud was discovered. If not for this call, no one would ever know that the requests were from an impostor, and the Line account owner would never know that the money was sent or even requested.

Another form of misleading occurs when a device has been granted security privileges and is able to communicate with a server or other network device, and somehow the cybercriminal device manages to impersonate an authorized server, resulting in the victim's device willingly transferring files and information to a pirate server without realizing that this server is an impostor. This technique was reportedly used to trick celebrities into backing up personal image files using iCloud, while keeping silent that the backup cloud was an impostor.

Another form of impostor occurs when someone, with physical access to a person's personal phone or open browser, performs fraudulent activities such as sending an email, answering a phone call, or sending a text message from another person's account or device. The recipient believes that they are connected to a known device or account and that the person managing that device or account is its owner. The impostor may be a prankster, such as a friend posting sensitive comments on Facebook, or his actions may be more personal when a spouse answers personal calls or intercepts confidential text messages of a personal nature. This unauthorized access can result in jealousy, divorce, and prosecution. Leaving a device temporarily out of control in an office or cafe, for example, going to the toilet, puts you at additional risk, giving the impostor the ability to quickly access personal or corporate information, send unauthorized emails, transfer files, or download any malware to the device, such as described in the next section entitled "Infection".

A cyberattack by an imposter also goes a long way in stealing a device. In such cases, even though the device is logged out, the thief has enough time to pick up a login. The "find my computer" function, which is supposed to find a stolen device on the network and erase the computer files when a cybercriminal first logs into the system on that device, no longer works because high-tech criminals today know how to activate only the device itself without cellular or Wi-Fi connection. This risk is especially great for cell phones, where a simple four-digit identification number or PIN provides security for entry. Finding a PIN is just a matter of time since there are only 9999 possible combinations.

A key issue for securing any device is preventing access for impostors. Preventing intruders from intruders requires reliable means of authenticating a user's identity at regular intervals and confirming that only they have the right to access the information and privileges they need. Device protection is often the weakest link in this chain. After overcoming device protection, the need for strong network security is controversial.

Capturing packets - Packet interception is a cyberattack in which the normal flow of packets over a network is redirected through a malicious device.

For example, if a router is attacked by a cyber attack, IP packets passing through the router can be rewritten into a revised IP packet, redirecting it to a different address and port of the pirate device. The pirate device then obtains any information it needs from the payload of the IP packet and possibly modifies the contents of the payload of the IP packet. A rogue payload can be used to commit a range of crimes, to gather information, or to download malware onto a cell phone, as described in the Infections section below.

The cracked packet is then redefined to look like the original IP packet with the sender's IP address, except that the packet is sent over a wired connection instead of a wired connection. Alternatively, the intercepted IP packet can be returned to the compromised router and then sent to the cloud via a wired connection. To maximize the criminal benefit of packet interception, a cybercriminal needs to hide their identity when capturing packets, and for this reason, they mask the true routing of an IP packet, and even ICMP Layer 3 "traceroute" will have difficulty identifying the true data path. If, however, this interception significantly increases the packet routing latency, this unusual latency may be a cause for investigation by the network operator.

Cyber infection - One of the most insidious categories of cyberattacks is "cyber infection" - the installation of malware on target devices or a network with which you can collect information, perform fraudulent actions, redirect traffic, infect other devices, disrupt or shut down a system, or cause a denial of service ... Cyber infection can spread through emails, files, websites, system extensions, application programs, or over networks. One of the main classes of malware - "spyware" - collects all kinds of information about transactions and sends them to a cybercriminal. In the case of "phishing," a web page or application shell that displays as a familiar login page, asks for an account login or personal information, and then passes that information on to the cybercriminal. Other malware infections can control equipment, for example, control a router to perform the aforementioned packet capture. In these cases, the cybercriminal tries to obtain information or gain benefits in order to achieve his goals.

Another class of cyberinfections, containing viruses, worms and Trojans, is designed to overwrite critical files or to re-perform meaningless functions in order to prevent the device from performing its usual tasks. Mostly to prohibit service, degrade performance, or destroy a device entirely. These malicious infections are inherently destructive and are used for revenge purposes, to disrupt the normal operation of a competitor's business, or just for the fun of a hacker wishing to see if this is possible.

Observation - Wiretapping and surveillance go beyond cybercrime. In such cases, a private investigator or acquaintance is hired or forced to install a device or program in the personal devices of the subject of interest to control his conversations, data exchange and location. the risk of being caught is increased because the detective must gain temporary access to the target device without being known to the subject. For example, there are SIM cards on sale that can copy the access rights to the phone's network, but at the same time information is transmitted to a cybercriminal controlling calls and data traffic of the target.

Other forms of surveillance include the use of clandestine video cameras to monitor every action and phone call of a person, much like a casino. With video monitoring, a device's password or PIN can be learned by simply observing the user's keystrokes during the login process. With a sufficiently large number of cameras at the surveillance site, eventually, sooner or later, the login process will be recorded. To gain access to a network of cameras without arousing suspicion, a cybercriminal can hack into an existing video surveillance system on buildings, in shops or on the streets, as well as monitor the behavior of unsuspecting victims through access to someone else's network. Combining video surveillance with packet analysis provides an even more complete set of data for later launching cyberattacks.

Pirate administration (unauthorized entry) - Another means by which cybercriminals can obtain information is by hacking and gaining access to the system administrator rights of a device, server or network. Thus, instead of gaining unauthorized access to the account of one user by hacking the system administrator's login, the cybercriminal gains much wider access and privileges without the knowledge of those who use the system. Since the system administrator acts as a police officer for the system, no one can stop his criminal activities - in fact, in a system or network with a corrupt administration, no one can control the police.

Conclusion - The ubiquity and interoperability that the Internet, packet-switched networks, and the near universal acceptance of the seven-layer OSI (Open Source Initiative) model have gained over the past twenty years have allowed global connectivity to expand on an unprecedented scale, connecting a wide range of devices from smartphones to tablets, computers, smartphones. TVs, cars and even household appliances and light bulbs. The global acceptance of the Internet Protocol (IP) as the basis for connectivity to Ethernet, cellular, Wi-Fi, and cable TV has not only unified communications, but also made it much easier for hackers and cybercriminals to infiltrate as many devices and systems as possible. Considering the many software and hardware methods currently available to attack modern communication networks, it is obvious that one method of protection is not enough for complete security. Instead, a systematic approach to securing each device, last link, local telephone company / network, and cloud network is needed to ensure they are protected from sophisticated cyber attacks. The methods used should ensure internal information security and confidentiality of information without compromising the quality of service, network latency, video or audio quality. While encryption should remain an important element in the development of the next generation of secure transmission and storage of data, network security should not rely solely on encryption techniques.

Summary of the invention

In accordance with this invention, data (which broadly includes text, audio, video, graphics, and all other types of digital information or files) is transmitted over a dynamic secure communications network and protocol (SDNP) or "cloud". The SDNP Cloud includes many "nodes", sometimes referred to as "media nodes", that are individually hosted on servers or other types of computers or digital equipment (collectively referred to herein as "servers") located anywhere in the world. It is possible to place two or more nodes on one server. Typically, data is transmitted between media nodes by light over fiber optic cables, radio waves in high frequency or super high frequency range, electrical signals over copper wires or coaxial cable, or over satellite communication channels, but in a broad sense, the invention includes any means, with by means of which digital data can be transferred from one point to another. The SDNP network includes the SDNP cloud, as well as Last Mile channels between the SDNP cloud and client devices such as cell phones, tablets, laptops and desktops, mobile consumer electronic devices, and IoT devices and appliances, automobiles and other transportation funds. Last Mile communication systems also include cell phone towers, in-house cable or fiber, and public Wi-Fi routers. Within a Last Mile, a connection between a client device and the nearest cell tower or other repeater may also be referred to as a Last Link.

When transmitted between media nodes in the SDNP cloud, data is represented as "packets", discrete strings of digital bits that can be of a fixed or variable length, and the data is masked using the following methods: scrambling, encryption, or splitting - or the corresponding reverse processes: descrambling, decryption and mixing. (Note: In this document, unless the context indicates otherwise, the word "or" is used in its conjunctive (and / or) sense.)

Scrambling means changing the order of data in a packet. For example, for data segments A, B, and C that are in ABC order in the source packet, the order will change to CAB. The operation inverse to scrambling is called "descrambling" and implies changing the order of the data in the packet to the one in which it originally appeared - ABC in the above example. The combined operation of descrambling and then scrambling a data packet is called "re-scrambling". When re-scrambling a packet that was previously scrambled, the packet may be scrambled in the same or different manner with respect to the previous scrambling operation.

The second operation, "encryption", is the encoding of the data in a packet and its representation in a form called cipher text, which can only be understood by the sender and other authorized parties, as well as by someone who must perform the reverse operation - "decryption" to do this. ... The combined operation of decrypting a ciphertext data packet and then encrypting it, typically, but not necessarily using a method other than the previous encryption method, is referred to herein as "re-encryption".

The third operation, "split", as the name suggests, means splitting a packet into two or more smaller packets. The reverse operation - "mixing" - is defined as combining two or more packages back into one package. Splitting a packet that was previously split and then mixed can be done in the same way, or it can be different from the previous split operation. The order of operations is reversible, whereby the division can be reversed by mixing, and conversely, the mixing of several input elements into one output can be canceled by division to restore the constituent components. (Note: Since scrambling and descrambling, encryption and decryption, and splitting and mixing are reverse processes, only knowledge of the algorithm or method that was used for the forward operation is required to perform the reverse operation. Therefore, when it comes to a specific algorithm for scrambling, encryption or separation, it should be clear that knowledge of this algorithm allows you to perform the reverse process).

In accordance with the present invention, a data packet that passes through the SDNP cloud is scrambled or encrypted, or one or both of these operations are performed on it in combination with splitting. In addition, "useless" (ie meaningless) data can be added to the packet to make the packet more difficult to decode or to make the packet length conform to the specified requirements. In addition, the package can be statistically analyzed, i.e. divided into separate pieces. In the professional language of computer scientists, parsing is to divide the computer language operator, computer command, or data file into parts that may be useful to the computer. Parsing can also be used to obscure the purpose of a command or data packet, or to package data into packets of a given length.

Despite the fact that the format of the data packets corresponds to the Internet protocol, in the SDNP cloud, the addresses of the media nodes are not standard Internet addresses, i.e. they cannot be identified by any Internet domain name server. Therefore, although media nodes can technically receive data packets over the Internet, these media nodes will not recognize addresses or respond to queries. Moreover, even if Internet users needed to contact the media site, they would not be able to access or view the data inside the media site, because the media site can recognize them as impostors who do not have the necessary media credentials. SDNP node. In particular, if a media node is not registered as a valid SDNP node running on a server that meets the requirements of an SDNP name server or equivalent, data packets sent from that node to other SDNP media nodes will be ignored and discarded. Likewise, only clients registered with the SDNP name server can access the SDNP media node. Like unregistered servers, data packets received from sources other than registered SDNP clients will be ignored and discarded immediately.

In a relatively simple embodiment called "single-route", the data packet travels a single path through a number of media nodes in the SDNP cloud while being scrambled at the media node where it enters the cloud and descrambled at the media node where it exits the cloud (these two nodes are called "gateway nodes" or "media gateway nodes"). In a slightly more complex embodiment, the packet is re-scrambled at each media node using a different scrambling method from that used at the previous media node. In other embodiments, the packet is also encrypted at the gateway node where it enters the cloud and decrypted at the gateway node where it leaves the cloud, and in addition, the packet can be re-encrypted at each media node it passes through. in the cloud. Since a given node uses the same algorithm each time it scrapes or encrypts a packet, this embodiment is referred to as "static" scrambling and encryption.

In the case when two or more packet conversion operations are performed, for example, it is scrambled and encrypted, the reverse operations are recommended to be performed in the opposite order, i.e. in reverse order. For example, if a packet is scrambled and then encrypted before leaving a media node, then when it arrives at the next media node, it is first decrypted and then descrambled. The package is recreated in its original form only if it is in a media node. While the packet is being transmitted between media nodes, it is in scrambled, split or mixed or encrypted form.

In another embodiment, called "multi-route" data transmission, the packet is split at the gateway node, after which several generated packets traverse the cloud along a series of "parallel" routes, with none of the paths sharing media nodes with the others, except for the gateway nodes. These multiple packets are then mixed to recreate the original packet, typically at the egress gateway node. Thus, even if a hacker managed to understand the meaning of one packet, he would only have a portion of the entire message. A packet can also be scrambled and encrypted at the gateway node before or after it is split, and several resulting packets can be re-scrambled or re-encrypted at each media node they pass through.

In a further embodiment of the invention, packets are not only sent along one path or a number of parallel paths in the SDNP cloud, but can be sent along different paths, many of which intersect with each other. Since the depiction of possible paths resembles a lattice in this embodiment of the invention, this process is called "lattice transmission". As with the embodiments described above, packets can be scrambled, encrypted, and split or mixed as they pass through separate media nodes in the SDNP cloud.

The paths of packets through the SDNP network are determined by a signaling function that can be performed either by segments of the media nodes themselves, or preferably in "two-channel" or "three-channel" versions, by separate signaling nodes operating on dedicated signaling servers. The signaling function determines the route of each packet as it leaves the transmitting client device (e.g., a cell phone) based on the state (e.g. propagation delay) of the network, the priority and urgency of the call, and informs each of the media nodes along the route that it is should receive the packet, and indicates the node to which it should be sent. Each packet is identified by a label, and the signaling function tells each media node which label to apply for each of the packets it sends. In one embodiment of the invention, the data label is included in the SDNP header or sub-header, the data field attached to each sub-data packet is used to identify the sub-packet. Each sub-packet can contain segments of data from one or more sources, stored in special data "slots" in the packet. Several sub-packets can be present in one larger data packet when transferring data between any two media nodes.

The routing function is consistent with the splitting and mixing functions, since after splitting a packet, it is necessary to determine the corresponding routes of each of the sub-packets into which it is divided, and the node in which these sub-packets are to be restored (mixed) should be instructed to perform mixing them. The packet can be split and then mixed once, as in the multi-route option, or it can be split and mixed several times as it travels through the SDNP network to the egress gateway node. The definition of the node at which the packet will be split, into how many sub-packets it will be split into, the corresponding routes of the sub-packets and the nodes in which these sub-packets will be mixed to recreate the original packet are all under the control of the signaling function. whether it is performed by separate signaling servers or not. The partitioning algorithm can determine which data segments are to be included in each of the sub-packets during transmission, as well as the order and position of the data segments in those sub-packets. The mixing algorithm defines the reverse process at the node where the sub-packages are mixed to recreate the original package. Of course, if there is a corresponding command from the signaling function, at this node the packet can be split again according to another split algorithm, corresponding to the time or state at the time the split process occurred.

When a media node receives a command from a signaling function to send multiple packets to a specific target media node on the "next hop" over the network, even if the packets are split packets (sub-packets) or refer to different messages, that media node can combine packets into one larger packet, especially when several sub-packets have to be sent to the same media node for the next hop (similar to a post office that puts a bunch of letters with the same recipient address in a box and sends that box by the address).

In "dynamic" embodiments, the individual media nodes in the SDNP cloud do not use the same scrambling, encryption, or splitting techniques and algorithms for packets passing through them one by one. For example, a given media node can scramble, encrypt, or split a packet using one particular scrambling, encryption, or splitting algorithm, and then scramble, encrypt, or split the next packet using a different scrambling, encryption, or splitting algorithm. Working in "dynamic" mode greatly increases the difficulties faced by potential hackers, because they have a short period of time (for example, 100ms) to understand the semantic content of the package, and even if it is successful, the usefulness of this knowledge will be short-lived.

In dynamic embodiments of the invention, each media node is associated with a so-called "DeMilitarized Zone (DMZ) server", which can be thought of as a part of the node that is isolated from the data transmission part and which has a database containing lists or tables ("selectors") of possible scrambling, encryption and splitting algorithms that this media node can apply to outgoing packets. The selector is part of a piece of information called "shared secrets" because this information is unknown even to media nodes and because all DMZ servers have the same selectors at a given time.

When a media node receives a packet that has been scrambled, in dynamic embodiments it also receives an "initial state" that is used to indicate to the receiving node which algorithm should be used when descrambling the packet. The initial state is a hidden numeric value that is meaningless in itself, but is based on a constantly changing state, such as the point in time at which the packet was scrambled by the previous media node. When the previous host scrambled the packet, the associated DMZ server generated an initial state based on the state. Of course, this state was also used by the respective DMZ server in selecting the algorithm to be used when scrambling the packet that was sent to the sending media node as an indication of how to scramble the packet. Thus, the sending node received both instructions on how to scramble the packet and an initial state to be sent to the next media node. The seed generator running on the DMZ server generates the seed according to an algorithm based on the state during the execution of the process. Despite the fact that the seed generator and its algorithms are part of the shared secrets of the media node, the generated seed is not secret, because without access to the algorithms, the numerical value of the seed is meaningless.

Thus, the next media node along the packet's path receives the scrambled packet and an initial state that is obtained for the state associated with the packet (eg, the point in time at which the scrambling was performed). The initial state can be included in the packet itself, or it can be sent to the receiving node before the packet is sent, either along the same route as the packet, or along some other route, such as through a signaling server.

Regardless of how it gets the initial state, the receiving host sends this initial state to its DMZ server. Since this DMZ server has a scrambling algorithm selector or table that is part of the shared secrets and is therefore the same as the selector in the sending host's DMZ server, it can use the seed to identify the algorithm that was used to scramble the packet and can tell the receiving node how to descramble the packet. Thus, the receiving node recreates the packet in a descrambled form, thereby restoring the original data. Typically, the packet is scrambled again according to a different scrambling algorithm before being transmitted to the next node. In this case, the receiving host connects to its DMZ server to get the scrambling algorithm and initial state, and the process repeats.

Thus, when a packet traverses the SDNP network, it is scrambled by each node according to different scrambling algorithms, and a new initial state is created at each node, which allows the next node to descramble the packet.

In an alternative embodiment of the present invention, the actual state (eg, time) can be transferred between nodes (ie, the sending node does not need to send the initial state to the receiving node). The DMZ servers associated with both the sending and receiving media nodes contain hidden number generators (again, part of the shared secrets) that contain the same algorithms at any given time. The DMZ server associated with the sending node uses the state to generate a hidden number, and the hidden number to determine the scrambling algorithm from a selector or table of possible scrambling algorithms. The sending node transmits the state to the receiving node. Unlike the initial states, hidden numbers are never transmitted over the network, but are transmitted exclusively over a confidential communication line between the media node and its DMZ server. When the receiving media node accepts the state for an incoming data packet, the hidden number generator in its associated DMZ server uses the state to generate an identical hidden number, which is subsequently used with a selector or table to identify the algorithm according to which the packet will be descrambled. This state can be included in the packet, or it can be transmitted from the sending node to the receiving node before the packet is transmitted, or via some other route.

The techniques used for dynamic encryption and separation are similar to those used for dynamic scrambling, using "keys" and "seed" for dynamic encryption. Shared secrets stored on DMZ servers include encryption and partitioning algorithm selectors or tables, and key generators. In the case of symmetric key encryption, the sending node transmits the key to the receiving media node, which can be used by the receiving node's DMZ server to identify the algorithm used to encrypt the packet and thereby decrypt the file. In the case of asymmetric key encryption, the media node requests information, i.e. the receiving node first sends the encryption key to the node containing the data packet being transmitted. The sending media node then encrypts the data according to this encryption key. Only the receiving media node that generates the encryption key has the corresponding decryption key and the ability to decrypt the ciphertext generated using that encryption key. It is important to note that with asymmetric encryption, access to the encryption key used for encryption does not provide any information on how to decrypt the data packet.

In the case of splitting, the media node in which the packet was split sends an initial state to the media node in which the resulting sub-packets will be mixed, and the DMZ server associated with the mixing node uses this initial state to identify the split algorithm and therefore algorithm to be used when mixing sub-packages.

As indicated above, in two- or three-channel embodiments of the invention, the signaling function is performed by a signaling node operating on a separate set of servers called signaling servers. In such embodiments, the initial states and keys may be transmitted via signaling servers rather than from the sending media node directly to the receiving media node. Thus, the sending media node can send the seed or key to the signaling server, and the signaling server can forward the seed or key to the receiving media node. As stated above, signaling servers are responsible for developing the packet's routes, so the signaling server knows the next media node to which each packet is directed.

To complicate matters for would-be hackers, the list or table of possible scrambling, splitting, or encrypting methods in a selector can be periodically (eg, hourly or daily) "shuffled" so that the methods corresponding to particular initial states or keys are changed. Thus, the encryption algorithm applied by a given media node to a packet created at time t ₁ on day 1 may be different from the encryption algorithm it applies to a packet created at the same time t ₁ on day 2.

Each of the DMZ servers is usually physically associated with one or more media nodes in the same "server group". As noted above, a media host can ask for directions on what to do with a received packet by providing the associated DMZ server with an initial state or key (for example, based on the time or state when the packet was created), but that media host cannot get access to shared secrets or any other data or code on the DMZ server. The DMZ server responds to such requests by determining, by seed or key, which method the media host should use to descramble, decrypt, or mix the packet. For example, if a packet is scrambled and the media node wants to know how to descramble it, the DMZ server can check the list (or selector) of scrambling algorithms to find a specific algorithm that matches a given initial state. The DMZ server then instructs the media node to descramble the packet according to this algorithm. In short, the media node forwards the requests contained in the initial states or keys to the DMZ server, and the DMZ server responds to these requests by issuing commands.

Despite the fact that media nodes are accessible over the Internet (although they do not have IP addresses that are recognized by DNS), DMZ servers are completely isolated from the Internet, and are connected only on the local network by wires or fiber optic cable with media connected to this network. -servers.

In "single channel" embodiments of the invention, initial states and keys are transferred between the sending media node and the receiving media node as part of the data packet, or may be sent in a separate packet prior to the data packet being transmitted along the same route as the data packet. For example, when encrypting a packet, media node # 1 may include an encryption key in the packet based on the point in time at which encryption was performed. When this packet arrives at media node # 2, media node # 2 transmits the key to the appropriate DMZ server, and the DMZ server can use this key to select a decryption method in its selector and perform decryption. Media Node # 2 can then ask its DMZ server how to re-encrypt the packet before transmitting it to Media Node # 3. The DMZ server again addresses the selector, informs the media node # 2 which method it should use when encrypting the packet, and transmits to the media node # 2 a key that reflects the state corresponding to the encryption method. Media node # 2 performs encryption and transmits the encrypted packet and key (separately or as part of a packet) to media node # 3. This key can then be similarly used by media node # 3 to decrypt the packet, and so on. As a result, there is no one static decryption method that a hacker could use when decrypting packets.

The use of the time or dynamic state "state" in the above example to determine the scrambling, encryption or splitting method to be included in the initial state or key is illustrative only. Any variable parameter, such as the number of nodes the packet has passed through, can also be used as a "state" in an initial state or key to select a particular scrambling, encryption, or splitting method to be used.

In "two-channel" versions, initial states and keys can be transferred between media nodes via a second "command and control" channel consisting of signaling servers, rather than being transferred directly between media nodes. Signaling nodes can also provide routing information to media nodes and tell media nodes along the packet's route how the packet should be split or mixed with other packets, requiring each media node to apply an identification "label" for each packet transmitted. so that the next media node (s) will be able to recognize the packet (s). Signaling servers, if possible, provide this media node with information only about the previous and next media nodes of the packet passing through the network. No single media node knows the entire packet route through the SDNP cloud. In some embodiments of the invention, the routing function may be distributed between two or more signaling servers, with one signaling server determining the route to a particular media node, the second signaling server determining the route from this media node to another media node, and so on to the output gateway node. In this case, no signaling server also has complete information about the route of the data packet.

In "three-channel" implementations, a third group of servers, called "name servers", are used to identify items in the SDNP cloud and to store information regarding the identification of devices connected to the SDNP cloud and their corresponding IP or SDNP addresses. In addition, name servers constantly monitor media nodes in the SDNP cloud, maintaining, for example, a current list of active media nodes and a propagation delay table for each combination of media nodes in the cloud. In the first stage of placing a call, a client device, such as a tablet, can send an IP packet to a name server requesting the address and other information of the recipient or called party. In addition, a separate dedicated name server is used to operate on first contact whenever the device is first connected, i.e. registered in the cloud.

As an added security benefit, a single SDNP cloud can provide separate security "zones" with different selectors, initial states and key generators, and other shared secrets. Adjacent zones are connected by bridged media nodes that contain the shared secrets of both zones and have the ability to convert data formatted in accordance with the rules for one zone into data formatted in accordance with the rules for the other zone, and vice versa.

Likewise, for communication between different SDNP clouds served by, for example, different service providers, a full duplex communication channel is formed between the front-end bridging servers in each cloud. Each front-end bridging server has access to the corresponding shared secrets and other security elements for each cloud.

An important advantage of the present invention is that there is no single point of control in the SDNP network and that no node and no server in this network has a complete understanding of how data transfer occurs or how it can change dynamically.

For example, signaling nodes operating on signaling servers know the route (or, in some cases, only part of the route) that data is transmitted, but they do not have access to the content of the transmitted data and do not know who the true caller or client is. ... In addition, signaling nodes do not have access to shared secrets on the media node's DMZ servers, so they do not know how data packets are encrypted, scrambled, split or mixed during transmission.

SDNP nameservers know the true phone numbers or IP addresses of the callers, but do not have access to the data being transmitted or the routing of various packets and sub-packets. Like signaling nodes, name servers do not have access to shared secrets on the media node's DMZ servers, so they do not know how data packets are encrypted, scrambled, split, or mixed during transmission.

The SDNP media nodes that are actually transmitting media content have no idea who the sender of the information is, and they do not know the route that various fragmented sub-packets take through the SDNP cloud. In reality, each media node only knows which data packets to expect (identified by their labels or headers) and where to send them next, i.e. "next hop", but the media nodes do not know how the data is encrypted, scrambled, mixed, or split, nor do they know how to choose an algorithm or decrypt a file using a state, an initial state numeric value, or a key. The knowledge required to correctly process data segments of incoming packets is known only to the DMZ server, which uses its shared secrets, algorithms that are not available on the network or the media node itself.

Another original aspect of the present invention is its ability to reduce network latency and minimize propagation delay to ensure QoS, as well as eliminate echoes or dropped calls by controlling the size of data packets, i. E. sending small packets of data at the same time through the cloud rather than relying on a single high-speed connection. Dynamic Network Routing SDNP uses its knowledge of propagation delays between nodes in the network to dynamically select the best route for transmitting data at that point in time. In another embodiment of the invention, for high-priority clients, the network can facilitate transmission routing by sending duplicate messages in fragmented form through the SDNP cloud, choosing only the fastest data to restore the original audio or data content.

Among the many advantages of the SDNP system in accordance with the present invention, in parallel and "lattice" options, packets can be fragmented as they travel to the SDNP cloud, preventing potential hackers from understanding the message even if they are able to decrypt a separate sub-packet or a group of sub-packets, and in "dynamic" variants the scrambling, encryption and splitting methods applied to the packets are constantly changing, which does not give the potential hacker any significant benefit from successfully decrypting the packet at a given time. Numerous additional advantages of the embodiments of the present invention will become apparent to those skilled in the art upon reading the description below.

Similar security techniques are commonly used on the Last Mile between the SDNP cloud and a client device such as a mobile phone or tablet. The client device is usually located in a separate security zone from the cloud, and it can first become an authorized SDNP client, which means installing a software package specific to the security zone of the device on the client device, usually by downloading from the SDNP administration server. The client device connects to the SDNP cloud through a media gateway node (sometimes simply called a "gateway") in the cloud. The media gateway has access to shared secrets related to both the cloud and the client device's security zone, but the client device does not have access to shared secrets related to the SDNP cloud.

As an additional layer of security, client devices can exchange materials and keys directly with each other via signaling servers. Thus, the transmitting client device can send material and / or key directly to the receiving client device. In such embodiments, the packet received by the receiving client device will be in the same encrypted or encrypted form as the packet leaving the sending client device. Therefore, the receiving client device can use the key or material it receives from the sending client device to unpack or decrypt the packet. The exchange of materials and keys directly between client devices is in addition to the native dynamic scrambling and encryption of the SDNP network and thus represents an additional layer of security called nested security.

In addition, the client device or gateway node with which it interacts can mix packets representing the same kind of data, for example, voice packets, text message files, documents, pieces of software, or a variety of information, for example, one voice packet and one text file, one text packet, and one video or photo image before the packets reach the SDNP destination, or the egress gateway can split the client packet into multiple packets. This is in addition to the scrambling, encryption, or splitting that happens on the SDNP network. In such cases, the sender client device may send the receiving client device a key telling it how to split the packet in such a way as to recreate the original packets that were mixed at the client sender media device or gateway node. Sequential mixing and separation can be a linear sequence of operations, or it can use a nested architecture in which customers implement their own security measures and the SDNP cloud.

To further confuse potential hackers, a client device can transmit sequential packets (or subpackets) in one connection to different gateway nodes and / or can transmit them over different physical communication channels (cellular, Wi-Fi, Ethernet cable, etc.) - a process sometimes referred to herein as "Multi-PHY" transmission. To add confusion, it can also include different source addresses in sequential packets, thereby preventing hackers from identifying packets as originating from the same client device.

The invention also includes unique advances in the handling of conference phone calls. Conventional conference packages send conference packages to all participants in the call. In accordance with this invention, some of the designated members may be "disabled", i. E. are excluded from the conversation, preventing the client device or other node from transmitting packets to the participant or participants that should be disconnected. Alternatively, the data packets are broadcast to all participants in the group call, but using different encryption methods. In the case of regular conference calls, data packets are sent to all users using encryption, where all participants have a copy of the decryption key. In private or mute mode, data packets sent to users use a different encryption, in which the decryption key is only sent to select users.

The inherent security mechanisms of SDNP network and protocol communication also make it ideal for securely storing files and data. Since normal communication over the SDNP network usually involves the anonymous transfer of fragmented data in encrypted form, encrypted data from one client device to another, the storage of files and data can be realized by interrupting the transfer and storing them in one or more buffers indefinitely while the client device will not want to remove them. This distributed file storage is sometimes referred to in the document as Disaggregated Data Warehouse.

Brief Description of Drawings

In the following drawings, components that have a common resemblance have been assigned similar reference numerals. However, it should be noted that not every component assigned a specific number designation is necessarily identical to another component with the same number designation. For example, an encryption operation having a particular numeric designation is not necessarily identical to another encryption operation with the same numeric designation. Moreover, groups of components, such as servers on a network, that share a common identification number are not necessarily identical to each other.

FIG. 1 is a schematic diagram of the process for standard network transmission of packets.

FIG. 2A is a schematic diagram of a packet scrambling process.

FIG. 2B is a schematic diagram of the packet descrambling process.

FIG. 2C is a schematic diagram of various packet scrambling algorithms.

FIG. 2D is a schematic diagram of static parametric packet scrambling.

FIG. 2E is a schematic diagram of hidden number dynamic scrambling.

FIG. 3 is a schematic diagram of the packet re-scrambling process.

FIG. 4A schematically shows a packet encryption process.

FIG. 4B is a schematic diagram of the packet decryption process.

FIG. 5 schematically shows the encrypted scrambling process and its inverse function.

FIG. 6 is a schematic diagram of a DUSE repackaging process including re-scrambling and re-encryption.

FIG. 7A is a schematic diagram of a process for dividing fixed-length packets.

FIG. 7B is a schematic diagram of the mixing process for fixed-length packets.

FIG. 8 is a schematic diagram showing different methods of mixing bags.

FIG. 9A is a table summarizing SDNP security functions and anti-security functions.

FIG. 9B is a flow diagram illustrating SDNP security operations performed on inbound and outbound Last Mile single-path data packets.

FIG. 9C is a flow diagram illustrating SDNP security operations performed on inbound and outbound data packets for Last Mile multipath communication.

FIG. 9D is a block diagram illustrating audio, video, text and file content creation, data packet preparation, data packet recognition, and content playback on an SDNP client device.

FIG. 9E is a depiction of an SDNP data packet using the 7-layer OSI model to illustrate hierarchical data encapsulation.

FIG. 9F is a graph and table depicting the SDNP payload.

FIG. 9G is a flow diagram illustrating the processing of incoming Last Mile data packets at an SDNP gateway using three-link communications.

FIG. 9H is a flow diagram illustrating the processing of inbound Last Mile data packets at an SDNP gateway using single link communications.

FIG. 9I is a flow diagram illustrating the processing of outbound Last Mile data packets in an SDNP gateway using three-link communications.

FIG. 10 is a schematic diagram of an SDNP cloud.

FIG. 11 schematically shows examples of insecure Last Mile communication without authentication.

FIG. 12 shows an insecure Last Mile connection over the legacy telephone system (POTS) without identity verification.

FIG. 13 schematically shows examples of insecure Last Mile authenticated communication.

FIG. 14 shows an insecure Last Mile connection over the analogue public switched telephone network (PSTN) with operator identity verification.

FIG. 15 shows insecure Last Mile communication over a digital wired network with login or token-based authentication.

FIG. 16 shows an insecure Last Mile connection over an analog wired network with PIN or credit card identity verification.

FIG. 17 shows examples of a Last Mile hypersecure link that supports authentication.

FIG. 18 shows a hypersecure Last Mile over a Wi-Fi wireless network that can be verified for identification.

FIG. 19 shows a hypersecure Last Mile communication over a cellular wireless network that can be verified for identification.

FIG. 20 shows a hypersecure Last Mile wired Ethernet link that can be verified for identification.

FIG. 21 shows an identifiable hypersecure Last Mile link over a wired wired network that can be verified.

FIG. 22 shows an identifiable hypersecure Last Mile communication over combo wired and home wireless Wi-Fi networks.

FIG. 23 is a schematic diagram of an example of a Last Mile connection including a verifiable identifier of a hypersecure site connected to a secure LAN last connection with an identifier.

FIG. 24 illustrates a Last Mile communication consisting of a verifiable hypersecure wireline segment identifier connected over a wireline to tampering protected devices and to unidentified unsecured devices.

FIG. 25 illustrates a Last Mile communication consisting of a verifiable hypersecure wireline segment identifier connected via Wi-Fi LAN to WPA-protected computing and communication devices at work and at home.

FIG. 26 illustrates a Last Mile communication consisting of a verifiable segment identifier of a hyper-secure wired link connected via Wi-Fi LAN to secure WPA IoT devices that provide authentication.

FIG. 27 illustrates Last Mile communication, consisting of an identifiable stretch of hyper-secure wired link connected via Ethernet or Wi-Fi LAN to WPA-protected business-to-business devices.

FIG. 28 is a schematic illustration of an example of Last Mile communication consisting of identifiable hypersecure communication steps connected by secure wired or secure wireless LAN links.

FIG. 29A schematically illustrates wired and wireless hypersecure bridges, including Ethernet and Wi-Fi, used in Last Mile networks.

FIG. 29B schematically illustrates wired and wireless hyper-secure bridges using Last Mile satellite and automotive networks.

FIG. 29C schematically illustrates wired and wireless hyper-secure bridges using cable and cellular networks used in Last Mile networks.

FIG. 30 illustrates Last Mile communications, consisting of identifiable, wireless hypersecure communications via satellite to a variety of devices, including telephones, airplanes, trains, ships, and home satellite receivers (set-top boxes).

FIG. 31A shows an example of the latter hypersecure communication channel between aircraft-to-satellite airborne communication devices.

FIG. 31B is an example of satellite communications and an aircraft antenna module.

FIG. 32 shows an example of the last hypersecure communication channel between devices in a communication network on board a cruise ship with multiple satellite communication channels.

FIG. 33 shows an example of a hypersecure Last Mile communication between devices on an on-board railway communication network with radio communication and a satellite.

FIG. 34 shows the hypersecure Last Mile communication with the vehicle telematics module, including the connection to the last cellular channel.

FIG. 35 shows an example of the last link between telematics modules in an automotive network with cellular communication and devices connected to the Wi-Fi network in the cockpit.

FIG. 36 shows an example of inter-transport hyper-secure communication with cellular communication.

FIG. 37 depicts hyper-secure technology for backbone communications over microwave, satellite, and fiber networks.

FIG. 38 shows a comparison of security, identity verification, and caller anonymity features for hyper-secured networks, secured and unsecured communication networks.

FIG. 39 shows a diagram of a single-line hyper-secured last mile connection with static IP addresses.

FIG. 40A is a schematic diagram of the IP stack of a Last Mile single-line hypersecured connection using static IP addresses.

FIG. 40B is a simplified representation of Last Mile single-path hypersecure communications using static IP addresses.

FIG. 41 shows a diagram of a single-route hypersecure communication with dynamic client IP-addresses in the "Last Mile" mode.

FIG. 42A depicts the IP stack of a Last Mile single-haul hypersecure communication using dynamic client IP addresses.

FIG. 42B is an alternate image of a Last Mile hypersecured single-haul IP stack using dynamic client IP addresses.

FIG. 43 shows a diagram of multi-route hypersecure communication with static IP addresses "Last Mile".

FIG. 44A is an image of a Last Mile multichannel hypersecure IP stack with static IP addresses using the last PHY connection.

FIG. 44B is an image of a Last Mile multichannel hypersecure IP stack with static IP addresses using a few recent PHY connections.

FIG. 45 shows the scheme of multi-route hyper-secure communication with dynamic client IP-addresses, built on the principle of "The Last Mile".

FIG. 46A depicts a Last Mile multichannel hypersecure IP stack with dynamic client IP addresses using one last PHY connection.

FIG. 46B is a depiction of a Last Mile multichannel hypersecure IP stack with dynamic client IP addresses using a few recent PHY connections.

FIG. 47 is a diagram of an alternative version of Last Mile multi-route hypersecure communication with dynamic client IP-addresses.

FIG. Figure 48 shows the IP stack of an alternate version of Last Mile multi-route hypersecure communication with dynamic client IP addresses.

FIG. 49 shows the IPv4 and IPv6 datagrams for Ethernet communication with SDNP payload.

FIG. 50A shows the IPv4 and IPv6 Ethernet "Last Line" packets used in client-SDNP Cloud communications.

FIG. 50B shows the gateway IPv4 and IPv6 Ethernet connection packets used in the cloud communication between the client and SDNP.

FIG. 50C presents packets of Ethernet-connection IPv4 and IPv6 gateway used in SDNP-cloud for communication with the client.

FIG. 50D represents the IPv4 and IPv6 Ethernet "Last Line" packets used in the SDNP cloud to communicate with the client.

FIG. 51A shows serial Ethernet data packets (abbreviated) used in single-route Last Mile communications with static client addressing.

FIG. 51B shows serial Ethernet data packets (abbreviated) used in single-route Last Mile communications with dynamic client addressing.

FIG. 51C shows serial Ethernet data packets (abbreviated) used in Last Mile multi-route communication with static client addressing.

FIG. 51D shows serial Ethernet data packets (abbreviated) used in Last Mile multi-route communication with dynamic client addressing.

FIG. 52A is a table summarizing Last Mile SDNP routing over Ethernet.

FIG. 52B provides topological descriptions of Last Mile single-line communications over Ethernet.

FIG. 52C provides topological descriptions of Last Mile multi-route Ethernet communications.

FIG. 52D provides additional topological descriptions for Last Mile multi-route Ethernet communications.

FIG. 53 graphically represent IPv4 and IPv6 for Wi-Fi communication with SDNP payload.

FIG. 54A is a graphical representation of Last Line IPv4 and IPv6 packets over Wi-Fi used in communications between the client and the SDNP cloud.

FIG. 54B is a graphical representation of the IPv4 and IPv6 Gateway Link Wi-Fi packages used in Wi-Fi communications when communicating between the client and the SDNP cloud.

FIG. 54C graphically represents the IPv4 and IPv6 Gateway Link Wi-Fi packets used in the communication between the client and the SDNP cloud.

FIG. 54D is a graphical representation of Last Line IPv4 and IPv6 datagrams over Wi-Fi used to communicate between the client and the SDNP cloud.

FIG. 55 is a graphical representation of IPv4 and IPv6 packet datagrams for 4G cellular with SDNP payload.

FIG. 56A is a graphical representation of the Last Line 4G IPv4 and IPv6 cellular data packets used in the communication between the client and the SDNP cloud.

FIG. 56B is a graphical representation of Last Line IPv4 and IPv6 Cellular Packets over 4G used to communicate between the SDNP cloud and the client.

FIG. 57A is a graphical representation of a Single-Middle "Back-to-Back" PHY.

FIG. 57B is a graphical representation of the back-to-back PHY mixed media channel interworking.

FIG. 57C is a graphical representation of alternate implementations of Back-to-Back PHY communications.

FIG. 58 is a graphical representation of the client's serial connections to the SDNP Last Line cloud using IPv6 datagrams carried over the Multi-PHY Ethernet protocol.

FIG. 59 graphically depicts serial client connections to SDNP Last Line cloud using IPv6 datagrams delivered over Wi-Fi Multi-PHY protocol.

FIG. 60 is a graphical representation of the client's serial communication with the Last Line SDNP cloud using IPv6 datagrams carried over Multi-PHY 4G cellular networks.

FIG. 61 graphically depicts serial client connections to SDNP Last Line cloud using IPv6 datagrams using Multi-PHY delivery over Ethernet and Wi-Fi.

FIG. 62 is a graphical representation of the client's serial communication with the Last Line SDNP cloud using IPv6 datagrams using multi-PHY delivery and Wi-Fi and 4G cellular networks.

FIG. 63 is a diagram of the OSI layer stack of a DOCSIS cable modem network, illustrating the functionality from the first to the seventh layers.

FIG. 64 is a graphical representation of the basic DOCSIS3 communications packages for cable systems with SDNP payloads.

FIG. 65A is a graphical representation of spectrum allocation and carrier modulation techniques for various DOCSIS3 protocols.

FIG. 65B is a graphical representation of the DOCSIS3.1 communication sequence between CTMS and CM.

FIG. 65C graphically depicts DOCSIS3.1 uplink communications.

FIG. 65D graphically depicts DOCSIS3.1 downlink communications.

FIG. 66 is a diagram of a three-way SDNP network for Last Mile communications.

FIG. 67 is a schematic diagram of a Call Request operation in a three-way Last Mile SDNP link.

FIG. 68 is a diagram of an address request operation in a three-channel Last Mile SDNP link.

FIG. 69 is a schematic diagram of an "address delivery" operation on a SDNP three-way Last Mile link.

FIG. 70 is a diagram illustrating the synthesis of SDNP commands and control packets.

FIG. 71 is a flowchart of the "Routing Instructions" operation in a SDNP single-channel, three-channel "Last Mile" link.

FIG. 72 is a schematic diagram of an SDNP Call operation in a single three-channel SDNP Last Mile data transfer from an SDNP client to an SDNP cloud.

FIG. 73A shows the SDNP cloud and Last Mile route connection to an SDNP client as a three-way connection for an SDNP call.

FIG. 73B is a schematic diagram of an SDNP cloud and three-channel Last Mile connection, implemented as a "call" over a non-SDNP client.

FIG. 74 is a diagram of how a "routing instruction" operation is performed in a Last Mile multichannel three-channel SDNP link.

FIG. 75A is a schematic diagram of an SDNP call operation in a three-channel SDNP Last Mile link from an SDNP client to the SDNP cloud.

FIG. 75B is a schematic diagram of an SDNP call operation in a Last Mile SDNP multi-channel three-channel link from the SDNP cloud to the SDNP client.

FIG. 76 is a diagram of how the Routing Instructions group call function works for a single three-channel Last Mile SDNP link.

FIG. 77A is a schematic diagram of a "SDNP group call" using SDNP multi-route cloud transport and Last Mile SDNP communication from a U1 client to clients in other zones.

FIG. 77B depicts a "SDNP Bulk Call" diagram using SDNP Multi-Route Cloud Transport and Last Mile SDNP communication from a U7 client to clients in other regions.

FIG. 77C is a diagram of an SDNP Multicast Call using SDNP Multi-Route Cloud Transport and Last Mile SDNP communication from a U9 client to other clients in the same area and in other areas.

FIG. 78 shows a "SDNP Bulk Call" diagram using SDNP multi-route cloud transport and Last Mile communication for both SDNP clients and unsecured PSTN devices.

FIG. 79A is a tabular representation of the regular and private call operations in the SDNP group.

FIG. 79B shows the scheduled and superfrequency calls in the SDNP call group in tabular form.

FIG. 80A shows regular and private group calls to SDNP PTT in tabular form.

FIG. 80B is a tabular representation of SDNP PTT regular and super-private group calls.

FIG. 81 shows the data transfer scheme for the operation of writing fragmented data to hyperprotected file storage.

FIG. 82A is a data flow diagram for writing fragmented data to hypersecure file storage.

FIG. 82B is a diagram of the data flow for reading in hyperprotected file storage.

FIG. 83 shows the data transfer scheme for reading fragmented data in hyperprotected file storage.

FIG. 84A shows various examples of cloud-connected SDNP file shares.

FIG. 84B is a schematic diagram of a hyper-secure distributed file storage network consisting of on-premises and cloud storage servers.

FIG. 85A shows a file mapping for a backup (RRF = 0) hyperprotected file storage.

FIG. 85B shows RRF file mapping = 1 read of redundant hypersecure file storage.

FIG. 85C shows an RRF = 2 read file mapping of a redundant hyperprotected file store.

FIG. 86 is a network diagram of a distributed hyperprotected file storage system using three-channel network communication.

FIG. 87A shows the operation of a file write request on a hypersecured distributed file storage system.

FIG. 87B shows the operation of querying the name of a file server on a distributed hypersecured file storage system.

FIG. 87C shows a signaling server scheduling operation in a distributed hyper-secured file storage system.

FIG. 87D shows a Last Mile client signaling server-side routing instruction and SDNP cloud for writing to a distributed hyper-secured file storage system.

FIG. 87E shows the routing instructions on the Last Mile Signaling Server and SDNP Cloud for writing to a distributed hyper-secured file storage system.

FIG. 88 shows file transfer to a distributed hyper-secured file storage system.

FIG. 89A shows a link response confirming that the file storage is working and is being written to the hypersecured distributed file storage system.

FIG. 89B illustrates a file storage communication link in a hypersecured distributed file storage system.

FIG. 89C shows a file storage server for recording an acknowledgment data packet containing an FS link.

FIG. 89D shows the synthesis of a link to read a file storage in a client SDNP messenger.

FIG. 90A shows a non-redundant RRF = 0 hyperprotected file store file map with non-redundant FS links LRF = 0.

FIG. 90B shows a hyperprotected file storage map RRF = 0 with channel redundancy LRF = 1.

FIG. 90C shows a hyperprotected file storage map RRF = 1 with channel reservation LRF = 1.

FIG. 91 shows a graph of storage resilience versus the number of file storage servers and client FS connections.

FIG. 92 is a diagram of the SDNP encryption and SDNP decryption functions.

FIG. 93A is a schematic diagram of SDNP distributed file storage with client file protection and hypersecure file transfer.

FIG. 93B is a schematic diagram of an SDNP distributed file storage with embedded security and hypersecure file transfer.

FIG. 94 shows a simplified diagram of hyper-secure encoding in a distributed file storage SDNP.

FIG. 95 shows a simplified diagram of hyper-secure decoding in SDNP distributed file storage for reading.

FIG. 96A is a diagram describing AAA operations when reading hyperprotected files.

FIG. 96B is a diagram describing file access and SDNP transport in the process of reading hyperprotected files.

FIG. 97A shows how to work with requests to read files in a distributed hyperprotected file storage system.

FIG. 97B shows a query for the name of a file storage server in a hypersecured distributed file storage system.

FIG. 97C shows scheduling the delivery of a file storage server name and signaling server in a hypersecured distributed file storage system.

FIG. 97D shows the instruction for reading in a distributed hypersecure file storage system on the side of the Last Mile signaling server and in the SDNP cloud.

FIG. 97E shows the Last Mile client signaling server-side routing instructions and SDNP cloud for reading in a distributed hyper-secured file storage system.

FIG. 98 shows file decoding on the storage side while reading in a distributed hyperprotected storage file system.

FIG. 99 shows the transfer of file data in a distributed hyperprotected file storage system during reading.

FIG. 100 shows data transfer in a distributed hypersecure file storage system when a link is refreshed.

FIG. 101 shows data transfer in a distributed hyper-secured file storage system used for file redistribution.

FIG. 102 shows time stamps in SDNP text messages.

FIG. 103 is a diagram of a registered SDNP communication.

FIG. 104A shows end-to-end encryption in Internet OTT OTT communications.

FIG. 104B shows end-to-end encryption in hypersecure communications.

FIG. 105A is a diagram of an SDNP Call operation with an SDNP Security Agent invisibly monitoring an outgoing call.

FIG. 105B is a diagram of an SDNP Call operation with an SDNP Security Agent invisibly monitoring an incoming call.

FIG. 106 shows data transfer between a file storage server in a distributed hypersecure storage system with an SDNP security agent performing invisible monitoring of FS channel routing.

FIG. 107 is a schematic diagram of an SDNP Call operation with an SDNP security agent performing invisible monitoring of an outgoing call using Last Mile multichannel communication.

FIG. 108 is a flow chart for assigning and authorizing an SDNP security agent.

FIG. 109 shows the communication between a mobile phone and a tower exposed to the SS7 vulnerability.

FIG. 110 shows SDNP communication using phone number masking to repel SS7 attacks.

FIG. 111 shows hosting SDNP SoftSwitch cloud networks on separate servers.

FIG. 112 shows hosting SDNP SoftSwitch cloud networks on shared servers.

FIG. 113 shows hosting SDNP SoftSwitch cloud networks on overlapping networks.

FIG. 114 connection of cloud networks SDNP SoftSwitch to the global cloud telecommunication network SDNP.

FIG. 115 shows an example of a nested SDNP subnet.

Description of the invention

After almost a century and a half of using telephone networks with switched channels, modern communication systems and networks for a period of only about a decade have switched to using the method of packet data switching using the Internet protocol, with data transmission over networks of Ethernet, Wi-Fi standards , 4G / LTE and DOCSIS3 over conventional and fiber optic cables. There are many advantages of the technology for the joint transmission of voice, text data, computer data, as well as static and video images; these include the use of redundant data paths to ensure reliable delivery of IP packets (which is the reason the Internet was originally created), and an unprecedented level of interoperability and networking capabilities around the world. However, as is the case with any innovation, the complexity of the tasks that have to be solved in connection with the introduction of new technologies is comparable to the number of benefits they provide.

Disadvantages of existing communication service providers

As described in the introductory part of this story, modern communication systems are characterized by many disadvantages. The most powerful communications systems today, made up of bespoke digital equipment owned by the world's largest long-distance service providers such as AT&T, Verizon, NTT, Vodaphone, etc., tend to deliver superior voice quality. but at a high cost, which includes high tariffs for monthly subscription fees, tariffs for connecting services, tariffs for the use of long-distance communication, complex plans for accounting for various data rates, charges for roaming services when using long-distance communication, as well as various tariffs for using services over maintenance of equipment. Since the form of ownership of these networks is private, information about the actual security of data transmission is not in the public domain; and the facts of data security breaches, hacker attacks and unauthorized interference in the operation of systems are not publicly disclosed. Given the number of eavesdropping and privacy violations reported by the media on a daily basis, there are serious doubts about the security of the communication process provided by private service providers - the security of data transmission, if not in private, may be at risk. cloud of these providers, at least during their transmission using last mile connections.

"Internet service providers" are another link in the global communications network. As described in the introduction to this invention, the process of transmitting voice messages over the Internet using VoIP technology is characterized by many QoS problems, including the following:

The Internet, being a packet-switched data network, is not designed to transmit IP packets at regular intervals, or to support real-time applications with low latency and high quality of service.

The routing behavior of an IP packet is unpredictable, resulting in ever-changing delays, sudden bursts of large data transmission errors, and unexpected dips in voice data transmission.

The IP packet transmission route is chosen at the discretion of the Internet provider, which determines the specific network through which the packet data will be transmitted, and can adjust the routing process, taking into account the balancing of the load of its own network or better service for its VIP clients due to the deterioration of the connection quality the bulk of their customers - the total traffic in their network.

Service providers of "low quality" ("OTT providers"), such as, for example, Line, KakaoTalk, Viber, etc., use free, randomly "opening" data transmission channels on the Internet while traveling him "hitchhiking" and, thus, not being able to control the factors that ensure the quality of data transmission in the network.

Use of heavyweight audio codecs that are unable to provide intelligibility of transmitted voice data even at moderate data rates.

The use of voice data transmission technology based on the TCP data transmission protocol leads to high time delays and degradation of the audio stream quality, which is associated with the presence of delays caused by the use of the "handshake" protocols and the processes of retransmission of IP packets. When only UDP is used in the data transfer process without additional means, there is no guarantee of maintaining the integrity of the payload.

In addition to poor quality of service issues, the security level of today's devices and networks is completely unacceptable and inadequate for the needs of future global communications. As described in the introduction of the US Patent Application "Dynamic Secure Communication Network and Protocol", the level of security of networks in the face of the large number of cyberattacks carried out using communication devices, including those on which spyware, Trojans, viruses, and phishing programs are installed is inadequate; among the dangers waiting for the user at the "last link" level - spyware, packet interception, wiretapping and interception of conversations using false pirate base stations; at the local network level or part of the network served by local telephone companies (last mile connections) - spyware, packet sniffing, virus programs and pirate "middleman attacks". The cloud itself can be accessed by unauthorized access, with security breaches at any gateway - factors such as the use of virus software, cybercriminal attacks ("middleman attacks"), DoS attacks, and unauthorized government surveillance come into play. In summary, we can say that the security of today's communication process is under threat given the numerous vulnerabilities that are easily exploited by cybercriminals and provide the possibility of committing cybercrime or violating user privacy in the cyber environment; Among these types of vulnerabilities are the following:

Availability of public information about the recipient of the IP packet, including the recipient's IP address, the recipient's port number, and the recipient's MAC address.

Availability of public information about the source of the IP packet, including the source IP address, source port number, and source MAC address.

Availability of public information about the type of transport layer used in Layer 4, as well as (based on information about the port number) about the type of requested service and application data contained within the payload of the IP packet

When using unencrypted files - access to all application data and file data contained within the payload of the IP packet - including personal and confidential information, login information, application passwords, financial data, and video and photo data

The presence of a communication dialogue, which makes it possible for a cybercriminal to make repeated attempts to crack encrypted files

Multiple options for installing malware (including spyware, phishing, and Trojans) on communications devices and routers using virus paths via FTP, e-mail, and web pages.

To reiterate the key point, it can be argued that the fundamental inherent disadvantage of packet-switched networks using the Internet Protocol is that any hostile party or cybercriminal intercepting IP packets can see which devices were involved in the creation of the data entering in the IP packet, where this IP packet came from, where it is forwarded now, how the data transfer process takes place (i.e., whether UDP is used or TCP is used), as well as the request for the provision of which service was sent ( i.e. what type of application data is contained within the payload). In this regard, a cybercriminal is able to determine the "context" of a conversation, which makes it easier for him to crack the encryption code used, compromise the security of the password used, and gain unauthorized access to files, data, and payload content.

Encryption - To protect against various kinds of described cyber attacks, modern network administrators, information technology specialists and software applications themselves can use, basically, only one means of protection - encryption. Encryption is a means of converting plain, easily recognizable text (readable text, executable text for viewing video files, image files, or listening to audio files) into alternative file types known as "cipher text" that are presented as streams of meaningless text characters.

The encryption process, converting an unprotected file into an encrypted file, involves the use of logical or mathematical algorithms called "code" that allows data to be converted to equivalent text elements without showing any obvious model of the conversion process that occurs during encryption. After that, the encrypted file is sent over the communication network or using some kind of computer medium to the recipient device. After receiving the file, the receiving device decodes the encrypted message using a process known as "decryption" to display the original contents of the file. The discipline of encryption and decryption, known collectively as cryptography, combines elements of mathematics (including number theory, set theory, and algorithm design theory), computer science, and electrical engineering.

With simple encryption technologies, using "one key" or "symmetric key", one keyword or one passphrase known in advance to both parties exchanging information can be used to unlock the encryption and decryption of a file. For example, during World War II, submarines and naval vessels exchanged messages over open radio channels using message encryption technology. At the very beginning, only one key was used in the encryption process. By analyzing the patterns of the code, Alliance cryptologists were sometimes able to compute the keyword or pattern used in the encryption process, and thus secretly read the encrypted messages. As encryption methods become more sophisticated, the process of manually cracking the code also gets more complicated.

The encryption code evolved into ciphers based on the use of mechanical machines, which was an early form of computer computation. At that time, the only way to break the code was to steal the encryption machine and use the same tools to decrypt messages that were used to encrypt them. The most difficult task was to steal the cipher machine and not be caught doing this task. If it became known to the enemy that the secret of the encryption machine was violated, he simply changed the code (cipher) used and updated the already functioning encryption devices with this change in mind. This principle is still practiced today - the most effective cyberattack is the one that was not detected.

With the advent of computer technology and the advent of the Cold War, encryption has become more complex, but the speed of computers used to crack encryption codes has also increased. At each stage of the development of the process of secure communication, technologies and practical skills of information encryption and the ability to crack an encryption code have developed almost parallel to each other, at the same speed. An important next step in the development of encryption technologies was taken in the 70s when the innovative dual-key encryption technology was introduced; this principle is still used today. One of the most well-known double-key encryption methods is the use of the RSA public key cryptosystem, a method named after the first letters of the names of its developers: Rivest, Shamir, and Adleman. Despite the fact that in the development of this method, the merits of only the indicated developers are officially recognized, many of their contemporaries, independently of them, also came to use a similar method. The RSA method uses two cryptographic keys, which are based on two large primes that are not publicly disclosed. One of the algorithms is used to convert these two primes into an encryption key, referred to in this document as E-key; another mathematical algorithm is used to convert the same two secret primes into a secret decryption key, also referred to in this document as D-key. An RSA user who has chosen secret primes (referred to in this document as the "key owner") distributes or "publishes" this E-key, generated using the appropriate algorithm and having a size that typically ranges from 1024 bit up to 4096 bits, for everyone who wants to encrypt their file. Due to the fact that this key is sent to many users unencrypted, the E-key is known as the "public key".

Parties wishing to communicate with the owner of the key then use the specified public E-key in combination with an available publicly available algorithm, usually offered in the form of commercial software, to encrypt any file that is intended to be sent. specific owner of the key. Upon receipt of an encrypted file, the key owner uses the secret D-key to decrypt the specified file; in the course of this action, the file is converted to plain, unencrypted text. The uniqueness of the double key method, in general, and, in particular, of the RSA algorithm, is the fact that the public E-key used to encrypt the file cannot be used for decryption. For decryption, only the secret D-key, which the owner of the key has, can be used.

The concept of using a double key, split key, or "multiple" key in encrypting and decrypting files is not limited to RSA or any other algorithmic method, but, from a methodological point of view, describes the communication method as a specific sequence of steps. For example, when exchanging two keys over a network with switched data packets. A device, such as a laptop, which "wants" to receive a secure file from a cell phone, first generates two keys - an E-key for encryption and a D-key for decryption, using a specific algorithm. The laptop then sends the E-key to the cell phone using the public network through which the ip packet is sent. The IP packet forwarding process obviously illustrates the use of a clear-cut form, contains the MAC address, source IP addresses (NB) and laptop port addresses, as well as the destination IP address (CP), cell phone port, and TCP data protocol, and also an encrypted copy of the E-key as its payload.

Using a pre-negotiated encryption algorithm or software package, the cell phone then processes the unencrypted text file using the encryption algorithm and the E-key, resulting in an encrypted file, namely the cipher text, which is sent as the payload of the IP packet to the process of secure data transfer from a cell phone to a laptop. When an IP packet is received, an algorithm is used to decrypt the file using the private decryption key (for example, the D-key). Since the D-key is matched with the E-key, then, in essence, the algorithm uses information about both keys to decrypt the ciphertext; the process provides for the creation of unencrypted plain text. While the payload of the IP packet is protected in the form of an encrypted file (i.e., cipher text), the rest of the IP packet is still forwarded in unencrypted form (which opens up the possibility of interception), open to read by any cybercriminal. including information about the source IP address (CP) and port number, as well as the destination IP address (NB) and associated port number. So, even if the payload itself cannot be opened, other parts of the communication process can still be tracked.

Virtual private networks - Another method of ensuring security, also based on the use of an encryption procedure, is to use the so-called virtual private network (VPN). When using a VPN in a network where encrypted IP packets are transmitted, a “tunnel” or “secure channel” is formed. With VPN, not only the payload is encrypted, but also the contents of the entire IP packet, which is then "embedded" into another unencrypted IP packet, acting as a "data carrier" through which the encapsulated packet is transferred from one VPN gateway to another. Initially, VPNs were used to combine disparate LANs into one over long distance - for example, when private network companies in New York, Los Angeles, and Tokyo wanted to combine their various LANs into one using the same functionality. as if it were one global private network.

The basic principle of virtual private networks can be thought of as encrypted communication between two devices, for example, where a server, being part of one local network that supports a certain number of devices wirelessly using radio connections and wired mode, is connected using a "virtual private network" ( VPN), consisting of encrypted content passing through a VPN tunnel, with a second server that has wired connections to stationary computers, a laptop, and a Wi-Fi base station. In addition to this relatively low bandwidth, the first server can also connect to the supercomputer via a high-speed connection. As a result, the communication consists of a sequence of data packets containing an internal VPN packet embedded in an external IP packet. During operation, an external IP packet from server A (indicating the source IP address and port number) is sent to server B with the destination IP address of the recipient and port number. The specified external IP packet describes the process of the servers forming an encrypted "tunnel" of data transmission. The VPN payload of the external packet contains the last mile IP packet, which allows direct information exchange between the stationary computer with the DT source IP address and the corresponding port specially designed for this purpose, as well as the laptop with the NB source IP address and an appropriate port specially created for this purpose; the specified package carries a file transfer request. Although any communication session can be initiated, in one example, the file transfer request is made through the VPN tunnel.

In order to carry out the specified data transfer in a secure mode using a VPN, a VPN tunnel is created and a session opening is initiated even before the actual data transfer takes place. When used in a corporate environment, the VPN tunnel may not be routed over the Internet, but is forwarded using a dedicated ISP or related service provider with its own fiber optic cable and hardware network. The service provider often enters into annual or long-term contacts with the company, under the terms of which a certain bandwidth of VPN servers is guaranteed for a certain fee. Ideally, server-to-server communication is allocated a high-speed link for direct connections without intermediate connections (or "last mile" connections) that could negatively impact VPN speed, quality of service, or data security.

In practice, the use of traditional VPNs requires a two-step process - the first stage creates or "logs in" to a virtual private network, and the second stage transfers data within a secure channel, or "tunnel". Tunneling concept, where external IP packets carried by 7-tier stacks (used to make the VPN connection) consisting of layers 1-4, where layer 5 is used to create a virtual VP session, and layer 6, presentation layer, is used for encryption required to form a VPN gateway channel between servers. While a VPN connection uses the Internet protocol to send IP packets, the PHY Layer 1 and VPN data link layer is often maintained by a separate operator to minimize routing unpredictability. For example, application layer 7 data flowing from device to device between communicating stationary computers is transferred as tunnel data, including all seven OSI layers required to establish a connection, as if there were no VPN. Thus, VPN can be thought of as a Layer 7 communication protocol used to transport internal VPN packets.

During operation, an external IP packet from the data transfer stack is transferred from one communication stack to another, in order to reveal the encapsulated data - the true contents of the packet. Thus, an end-to-end connection occurs without knowledge of the details used to create a VPN tunnel, except that the VPN tunnel must be formed in advance before any connection attempt is made and must be closed after the call ends. Failure to open a VPN tunnel will primarily result in unencrypted transmission of an IP packet susceptible to eavesdropping, capture, infection, etc. Failure to close the VPN after the call ends can provide a cybercriminal with the opportunity to hide his illegal activity in someone else's VPN tunnel and, if intercepted, could lead to possible criminal charges against an innocent person.

While the use of VPNs is a common way to connect multiple private LANs to each other using private connections with dedicated bandwidth and bandwidth, using VPNs as part of public networks and the Internet is problematic when communicating between two stakeholders. ... One of the problems with using virtual private networks is that the VPN connection must be established in advance, even before it can be used, and not based on the exchange of data packets. For example, in a VoIP call over a packet switched data network, before the cell phone can reach the intended recipient of the call on the second cell phone, it must first establish a VPN session. To do this, the VPN connection application must first be downloaded to the caller's mobile phone. The caller then has to send IP packets to the VPN site, usually the service provider. These packets are forwarded over any available Last Mile routing, such as a radio link from a mobile phone to the nearest Wi-Fi base station, followed by a wired link to a local router, and then a wired link to a VPN site. Once a session is established between the caller's mobile phone and the VPN site, the caller's cell phone must then instruct the VPN site to create a VPN tunnel from the caller's cell phone to the VPN site. This part of the VPN tunnel is simplified as a Layer 5 session with a tunnel encrypted with Layer 6.

After the VPN connection is established, the caller's mobile phone can make a call through any VoIP telephony application to any other phone. If the called phone is not connected to the same VPN, the application must establish a last mile "call" connection between the VPN host and the cell phone in order to follow these instructions. If the VoIP application cannot do this or does not have the appropriate rights to carry out such actions, the call will not take place - it will be terminated immediately. Otherwise, the internal IP packet will establish an Application Layer 5 session between the calling cell phone and the destination cell phone, and will also confirm that the test IP packets are properly decrypted and legible.

In order to make a call, the call must be initiated by Layer 7 of the application running on the subscriber's phone, and not by the usual telephone dialing functions, since The SIM card of the telephony service provider in the phone is not compatible with the VPN tunnel functions. Once a call is made, the cell phone will transmit a sequence of IP packets, which are small chunks (or "snippets") of voice information selected according to the communications application installed on the phone. These packets are sent from the app on the caller's mobile phone through the network, such as over a Wi-Fi link to the nearest Wi-Fi base station, then over a wired connection to a router, and finally over a wired connection to a VPN site. The data is then securely transferred to the VPN host through the VPN tunnel to the VPN endpoint, the target VPN gateway. In this example, the VPN tunnel does not extend to the recipient's cell phone, but instead stops ringing the device. Behind the VPN destination gateway, data is no longer encrypted as the VPN operator is no longer involved. For data packets exiting the VPN tunnel, the VPN host injects data over the last mile of the destination device, such as a wired connection to the nearest router, then a wired connection to the local cellular system and tower, transmitting the call like a normal cellular call using 2G , 3G or 4G. The process of calling from a mobile phone application to a phone that is not running the same application is called a "call out" function.

The above example highlights another problem with connecting to a VPN over a public network - the last mile connection from the VPN site to the called party is not part of the VPN and therefore does not guarantee security, performance, or QoS. In particular, the caller's last mile containing connections is open to eavesdropping and is susceptible to cyberattacks. As soon as the call is completed and the caller's mobile phone hangs, the VPN connection should be interrupted, while the coordinates of the fifth layer of VPN Layer 5 will close the VPN session and the subscriber's cell phone will disconnect from the VPN node.

The adaptation of a virtual private network - a technology originally created for transferring data between computers - faces a number of major challenges.

The last mile of communication between the VPN gateway and the destination mobile phone is unsecured and threatened by eavesdropping and surveillance.

The last mile of communication between the caller's mobile phone and the VPN gateway is only secure if the caller is using a data-driven application. If the caller connects to the VPN gateway over a phone line, i.e. connects to the function, then communication from the caller's mobile phone to the nearest VPN gateway is not secure and subject to the risk of eavesdropping and surveillance.

Call security can only be ensured if both callers are using data rather than last-mile telephony and know that both parties must be connected to the same VPN before initiating a call.

The last paragraph emphasizes the paradox of secure VPN communication - the called subscriber must know that they are calling before they are called to join the network. In order to inform a person that he needs to call, you must first contact him and instruct him to enter the VPN before he can start the call. Basically, they have to receive an unsecured phone call in order to connect to a secure phone call. An unsecured phone call is easy to hack, sniff, and listen to. In addition, the unsecured call metadata shows who is calling whom and at what time. Call metadata is extremely useful for tracking a person's activity or for profiling them as a target of criminals.

Even if all of these instructions have been followed, there is still no guarantee that an attempt to make a phone call or send documents over a VPN will not be unsuccessful for several reasons, including the following:

The latency of data transfer in a VPN may be too high, making it impossible for applications in real time, voice over IP, or video streaming;

Last mile VPN data latency between the caller and the VPN gateway, or between the VPN gateway and the recipient of the phone call, may be too late to allow real-time applications, VoIP, or streaming video data;

The closest VPN gateway to the caller or to the destination subscriber (that is, the last mile connection) may be located too far away - perhaps even more than the distance to the destination subscriber, which would be the case if the VPN the network was not used, which will lead to a significant delay in data transmission within the connection, unstable network operation, uncontrolled routing using unknown networks, varying QoS technology and numerous opportunities for intermediary attacks using unprotected connection segments;

The last mile VPN connection between the VPN gateway and the recipient of the call may not support outside dialing and packet transfer functionality, or may not support connections with local telephone companies;

Local service providers or government censors may block calls from unknown VPN gateways, or the process of establishing connections to such gateways, for reasons of national security or regulatory compliance;

When using corporate virtual private networks, the ability to make calls using the functionality of VoIP technology can be provided only to company employees or clearly defined authorized categories of users; the processes of conducting financial transactions or watching online videos may be blocked; servers for transmission of private mail messages to the public network, such as, for example, Yahoo, Google, etc., may be blocked; and access to numerous websites, such as YouTube, online chat programs, or, for example, the Twitter service, may also be blocked in accordance with company policy;

In the event of unstable networks, the VPN can remain open after the call ends, which will result in maintaining an open session in continuous mode with access to the caller's device until the VPN provider manually resets the connection. This can lead to the loss of a part of the bandwidth when making subsequent calls, or to the need to pay large amounts of tariffs for an open connection.

Comparison of networks - comparing communication options offered by over-the-top or OTT providers with communication systems using public networks to connect to a dedicated VPN quickly reveals that beyond the VPN itself, most communication systems have nearly identical components and connections. In particular, the last mile of a caller having a cell phone, a Wi-Fi radio, a Wi-Fi base station, wired connections, and a router is the same last mile in both implementations. Likewise, on the "last mile" of the other side, the cell phone, cell phone connection, cell base station and tower, wired connections, and router are identical for the Internet and VPN versions. The main difference is that in a public network, the VPN tunnel with secure communication between VPN peers is replaced by servers / routers providing an insecure communication connection. Another difference is the OTT connection, the call is available instantly as described in the instructions, where in order to use the VPN, additional instructions are needed to set up the VPN and end the VPN session before the next call.

In both examples, last mile connections offer unpredictable quality of service, packet sniffing capability, and the risk of cyberattacks. Since the servers / routers are likely run by different providers on different local networks, it is possible to interpret the servers as existing different clouds, i.e. clouds. For example, publicly open networks owned and operated by Google, Yahoo, Amazon, and Microsoft can be considered different clouds, such as the "Amazon cloud," although they are all connected by the Internet.

A competing network topology, peer-to-peer or PPN, involves a network of many peers with packet routing managed by the PPN rather than a router or provider. While peer-to-peer networks have existed in hardware for decades, it was Napster who popularized the concept as a way to avoid the control, cost, and regulation of ISPs. Napster's founders were forced to file for bankruptcy after being sued by the US government for music copyright infringement; at the same time, the OTT operator Skype was just beginning to develop. Later, the Skype network moved away from the traditional OTT network model to the peer-to-peer one proposed by Napster.

In PPN switching, each device that connects to enter the PPN becomes another node in the PPN. For example, if in a network topology a cell phone with PPN software is registered in a peer-to-peer network, it, like all other connected devices in the region, becomes part of the network. Calls posed by any devices go from one device to another to get to their destination, another PPN connected device. For example, if, in a network topology, a cell phone uses its PPN connection to call another PPN-connected device, such as a cell phone, the call follows a roundabout route through any device (s) physically located in the PPN between the two devices. As shown in the figure, a call originating from a cell phone connects Wi-Fi through a Wi-Fi base station to a desktop computer, then to a laptop, to a desktop computer, then to a desktop computer, and finally to a cell phone through a cell phone base station. and a tower. Thus, all routing is controlled by the PPN, and the Internet is not involved in routing control. Since both sides are involved, the PPN software used to connect to the network also acts as an application for VoIP-based voice communications.

In the event that a cell phone tries to call a cell phone with a non-PPN based device on the opposite end of the earth, routing must necessarily include data transmission over the Internet using access points, especially when transmitting packets across oceans or mountain ranges. The first part of routing in a network with a topology proceeds similarly to the previous example, starting with a cell phone and routing through a Wi-Fi base station, desktop computer, laptop. At this point, if the laptop is connected to the network, the call will be routed through it, otherwise the call must be routed through the cell phone base station and tower to the cell phone, and then back to the cell phone base station and tower before sending.

If the call crosses the Pacific Ocean, then computers and cell phones cannot carry traffic across the ocean, so the call is then necessarily routed to the Internet to a third-party server / router in the cloud and then through a connection to a third-party server / router in the cloud. The call then leaves the Internet and enters the PPN in the network topology first through the desktop computer, which in turn connects to Wi-Fi, to the laptop and to the base station. Since Wi-Fi does not launch the PPN app, the actual packet entering the Wi-Fi has to go to the tablet or cell phone and back to Wi-Fi before being sent to the cell phone base station and tower over the wired connection. Finally, the cell phone call connects to a cell phone that is not a PPN enabled device. Thus, the connection is a "challenge" for the PPN as it leaves the PPN topology. Using this PPN approach, the VPN will first register the calling device with the PPN as instructed by performing PPN authorization. The call can then be made through the PPN app. The advantage of such a peer-to-peer network is that there is no need for additional equipment to carry a call over long distances, and every device connected to the PPN regularly updates the PPN provider regarding its status, load and latency, the PPN provider can control packet routing to minimize latency. ...

The disadvantages of this approach are that packets traverse a network containing many unknown nodes that pose a potential security threat and have unpredictable effects on call latency and quality of service. Thus, with the exception of Skype, peer-to-peer networks operating at layer 3 and higher are not typically used in packet-switched networks.

Comparison table of ad hoc VPN providers, OTT ISPs and PPN peers is shown below.

Network VPN virtual private network OTT Internet Peer-to-Peer PPN Nodes Public / Host Servers Public routers / servers PPN Users Node bandwidth Famous infrastructure Famous infrastructure Mixed, unknown Cloud bandwidth Guaranteed Unpredictable Unpredictable Last Mile bandwidth Depends on the provider Depends on the provider Depends on PPN Delay Uncontrollable Uncontrollable The best option Network stability Uncontrollable Unmanaged, redundant The best option Call setup Complex entrance Not required Authorization User ID Username Phone number Username VoIP technology quality of service Variable to good Variable Variable Cloud Security Encrypted payload only Unencrypted Unencrypted Last Mile Defense Unencrypted Unencrypted Unencrypted Listenable Package Header (Cloud) Entire Package (Last Mile) Whole package Whole package

As shown in the figure, while VPN and the Internet have a fixed infrastructure, the peer-to-peer nodes differ depending on who is logged in and which devices are connected to the PPN. Cloud bandwidth, defined in the context of this table as high-speed long-distance network connections, such as networks that cross oceans and mountain ranges, is contractually guaranteed only in the case of a VPN, and is otherwise unpredictable. Last mile bandwidth is a local ISP that depends on both ISPs and VPNs, but for PPN is completely dependent on who is logged in.

The propagation delay of sequential IP packets is unmanageable for OTT and VPN because the ISP does not control last-mile routing, but instead depends on local telephony or network operators, while PPNs have limited capabilities, using optimal options for direct traffic between nodes that are currently online in a certain geography. Likewise, for resilience, PPNs have the ability to redirect traffic to maintain the network, but are completely dependent on who logs on to the system. The Internet, on the other hand, is internally redundant and almost certainly guarantees delivery, but not necessarily on time. Network resiliency for a dedicated VPN depends on the number of nodes allowed to connect to the VPN host. If these nodes are down, the VPN will be unusable.

In terms of call setup, the Internet is always available, PPNs require additional instructions to log into the PPN before making a call, and VPNs can involve a complex login procedure. Moreover, most users see the use of OTT phone numbers, rather than the separate login IDs used by VPNs and PPNs, as an important benefit for ease of use. All three of these networks suffer from erratic VoIP quality, generally lagging behind commercial carriers. From a security point of view, all three options cannot act as last mile connections, as they are prone to interception of packets with public addresses and payloads. VPNs provide encryption of the cloud connection, but still provide the IP addresses of the VPN hosts. Thus, no network option is considered secure. Thus, encryption is used by various applications to prevent hacking and cyberattacks, either as a Layer 6 protocol or as an embedded part of the Layer 7 application itself.

Excessive trust in encryption “Whether used to encrypt IP packets or create a VPN, today's network security depends almost exclusively on encryption and represents one weakness in today's packet-switched communications networks. For example, a lot of research has been done on how to attack RSA encryption. Although limiting the primes to large sizes greatly reduces the risk of "brute-force" decryption D-key code cracking, polynomial coefficient methods have successfully demonstrated cracking keys based on smaller primes. There are concerns that the evolution of "quantum computing" will eventually lead to practical ways to "crack" RSA keys and other encryption keys in a cyberattack. To combat the ever-present risk of "breaking" the code, new algorithms and methods for encrypting the "larger key" have emerged, such as the "improved encryption standard" or the AES cipher, approved by the US NIST in 2001. The design principle, based on the Rijndael cipher known as a permutation-permutation network, combines both character substitution and permutation using different key and block sizes. In its current implementation, the algorithm contains fixed block sizes of 128 bits with keys including various lengths of 128 bits, 192 bits and 256 bits, with the appropriate number of repetitions used in converting the input file, varying in round numbers of 10, 12, and 14 degrees, respectively. In practical terms, the AES cipher can be efficiently and quickly executed in both software and hardware for any key size. In cryptographic language, AES based encryption using a 256b key is referred to as "AES256 encryption". AES512 encryption using 512b key is also available.

While each new generation raises the bar of cryptography to improve encryption and break it faster, profit-driven cybercriminals often focus on their goals instead of using computation to crack the encrypted file. As described earlier, using packet sniffing and port polling, a cybercriminal can obtain valuable information about a conversation, a corporate server, or even a VPN gateway. Instead of attacking the network, cyber analysis allows you to attack the personal computers, laptops and mobile phones of the CEO or CFO of the company. Malware and spyware is automatically installed as soon as company employees click on the link attached to the emails, which completely bypasses the firewall protection, since this way the malware gains access "from the inside".

The likelihood of a cipher being broken is also increased if data travels across the network unchanged, that is, statically. For example, in the network of FIG. 1, the underlying data in packets 790, 792, 794, and 799 remains unchanged as the packets travel across the network. Each data packet shown contains a sequence of data or sound sequential in time or pages, unaltered from the original order when it was created. If the content of the data packet is text, reading a plain text file in the sequence 1A-1B-1C-1D-1E-1F will result in "legible" text for communique number "1". If the content of the data packet is audio, transform, i.e. "playing" an unencrypted text file in the sequence 1A-1B-1C-1D-1E-1F through an appropriate audio codec essentially based on the DAC software will result in sound for sound file number "1".

In any event, throughout this disclosure, each data interval, represented by blocks of a fixed size, contains a predetermined number of bits, for example, two bytes (2B). The exact number of bits per slot is flexible only if each communication node in the network knows how big each data slot is. Each data interval contains audio, video, or text data, indicated in the drawings as a number followed by a letter. For example, as shown in the figure, the first interval of data burst 790 contains content 1A, where the number "1" indicates a specific link # 1, and the letter "A" represents the first piece of data in message # 1. Similarly, the second slot of data packet 790 contains the content 1B, where the number "1" indicates that it is part of the same message # 1, and the letter "B" represents the second piece of data in message # 1, sequentially following 1A.

If, for example, the same data packet is assumed to include the content "2A", the data represents the first packet "A" in another message, in particular for communication # 2, not associated with message # 1. Data packets containing homogeneous messages, for example, where all the data for communication # 1 is easier to parse and read than those that mix different messages. The data, ordered sequentially in the correct order, allows a cybercriminal to interpret the nature of the data, be it audio, text, graphics, photographs, videos, executable code, etc.

Moreover, in the example shown, since the source and destination IP addresses of the packet remain constant, that is, when the packets remain unchanged during transport over the network in the same form as the data entering or leaving the gateway servers 21A and 21F, since the base data does not change, a hacker has a better chance of intercepting data packets and a better chance of analyzing and opening files or listening to a conversation. Simple transport and one-dimensional security, that is, relying only on encryption for protection, increases the risk of a cyber attack because the likelihood of success is higher with such an overly simple use of the Internet as a packet-switched network.

Protection of real-time networks and network devices

In order to improve the quality of service for telephony, video and data communications while addressing the many security vulnerabilities that pose challenges to today's packet-switched networks, a new and innovative systems approach to IP packet routing management is needed that drives the global network that includes disparate technologies and at the same time contributes to end-to-end security. The objectives of such an innovative packet-switched network include the following criteria:

1. Ensure the security and quality of service of the global network or long-distance service provider, including dynamically managing the routing of voice, video and data traffic in real time in the network;

2. Ensure the safety and quality of service of the "local network or telephone company" on the last mile of the communication network;

3. Ensure the safety and quality of service of the "last link" of the communication network, including ensuring secure communication over unprotected lines;

4. Ensure the security of communication devices and authenticate users to prevent unauthorized or fraudulent access or use;

5. Promote a secure way of storing data on the device, online, online, or in the cloud to avoid unauthorized access;

6. Ensuring the security and confidentiality of all non-public personal information, including all financial, personal, medical and biometric data and records;

7. Ensuring the security and confidentiality of all financial transactions related to online banking and shopping, credit cards and electronic payments

8. Ensuring security, confidentiality and anonymity in transactions and information exchange in machine-to-machine (M2M), inter-vehicle (V2V) and machine-to-vehicle (V2X) interactions.

For the foregoing purposes, the inventive approach contained in this section relates to the second topic described in clause 2, i.e. "security and QoS of a local network or a telecommunications company in the last mile of a communications network" This topic can be viewed as a secure last mile connection without compromising real-time communications.

Glossary

Unless the context otherwise requires, the terms used in describing a dynamically secure communication network and protocol have the following meanings:

Anonymous data packets: Data packets that do not contain information about the original sender or final recipient.

Client or client device: A device, usually a mobile phone, tablet, laptop, personal computer or IoT device, connected to the SDNP cloud over the Last Mile.

Concealment: An encoding process by which the contents of an SDNP packet or portions thereof are made unrecognizable by any sequential combination of security operations such as encryption, splitting, unwanted data insertion, and encryption. Recovering hidden data requires performing anti-functional processes or reverse decoding, such as decrypting, removing unnecessary data, mixing and decompressing.

Decryption: A mathematical operation used to convert data packets from ciphertext to plaintext.

Disaggregated data storage: The process of fragmenting data files and hiding their contents before storing different fragmented files on different storage nodes.

DMZ (Demilitarized Zone) server: A computer server not directly accessible from the Secure Dynamic Network And Protocol (SDNP) or the Internet, used to store selectors, seed generators, key generators and other shared secrets. The DMZ can also be called an "air server", i. E. computer without a wired network connection or access.

Dynamic Encryption / Decryption: Encryption and decryption based on keys that dynamically change as a data packet passes through the SDNP network.

Dynamic mixing: A mixing process where mixing algorithms (inverse to partitioning algorithms) dynamically change based on an initial state based on state, such as time, state, and zone, when a mixed data packet is generated.

Dynamic scrambling / descrambling: Scrambling and descrambling based on algorithms that dynamically change depending on the state, for example, when a data packet is created or the area in which it is created.

Dynamic Partitioning: A partitioning process where partitioning algorithms are dynamically changed based on an initial state based on state, such as time, state, and zone, when a data packet is divided into multiple sub-packets.

Encryption: A mathematical operation used to convert data packets from plaintext to ciphertext.

Fragmented data transfer: Routing split and mixed data over the SDNP network.

Useless Data Removal (or "garbage disposal"): Removing useless data from data packets to restore the original data or restore the original length of the data packet.

Insertion of useless data (or "garbage insertion"): Deliberately inserting meaningless information into a data packet, either to make it difficult to understand the actual content of the data, or to control the length of the data packet.

Key: A hidden numeric value that is generated by entering a state, such as time, into a key generator that generates a key using a secret algorithm. The key is used to select an algorithm for encrypting or decrypting the data in the packet from the selector. The key can be used to securely transmit status information over public or unsecured lines.

Key Exchange Server: A computer server, often owned by a third party and independent of the SDNP network operator, used to distribute shared keys to clients and optionally to servers using symmetric encryption keys, especially when dealing with client-managed keys i.e. e. based on end-to-end encryption by the client to prevent the possibility of espionage by the network operator.

Last Link: The network connection between the client device and the first device on the network with which it communicates, typically a radio tower, Wi-Fi router, cable modem, set-top box, or Ethernet connection. In the case of Ethernet communications, the last link includes a physical "bonded" (ie, wired) connection to the cable modem or fiber optic modem. To connect to a Wi-Fi network (for example, in a cafe) "Last Line" includes a Wi-Fi router connected to DSL, cable or fiber optic network. In a cellular network, "Last Link" includes radio communications between a cell tower and a mobile phone, which may include, for example, a 3G or 4G / LTE connection.

Last Mile: The network connection between the SDNP gateway and the client, including the last link. Last mile typically includes communications over networks owned and operated by local telecommunications and cable companies such as Comcast cable, Verizon cellular, Korean Telecom, British Telecom, and so on.

Mixing: Combining data packets from different sources that contain different types of data to create a single data packet (or a series of sub-packets) with unrecognizable content. In some cases, previously separated data packets are mixed to restore the original data content. Mixing operations can also include junk data insertion and deletion, and parsing.

Multiple PHY or Multi-PHY: Communication involving the alternating transmission of concatenated serial data packets over multiple physical media such as fiber and 4G, different Wi-Fi channels and frequencies, 4G and Wi-Fi, Ethernet Wi-Fi, etc.

Parsing: A numeric operation in which a data packet is split into shorter sub-packets for storage or transmission.

Router: The device that routes the routing of a datagram to the destination address specified in its IP header. For packet routing outside the SDNP network, the IP address used can be a valid Internet IP address (recognized by the DNS server) or a NAT address assigned by a network address translator operated by a local service provider (for example, Comcast assigns its own internal IP addresses to communicate inside the Comcast cable / fiber network).

Scrambling: An operation in which the order or sequence of data segments in a data packet is altered with respect to its natural order and takes on an unrecognizable form.

Splitting: An operation in which a data packet (or multiple sequential data packets) is split into multiple sub-packets, which are sent to multiple destinations. The split operation can also include the insertion and deletion of useless data.

SoftSwitch: Software containing executable code that acts as a switch and router.

SDNP: Acronym (Secure Dynamic Network And Protocol), meaning a hyper-secure communications network implemented in accordance with the present invention.

SDNP Address: An address used to route SDNP packets through the SDNP cloud or last mile, containing the special IP address of the next destination, i.e. sufficient information to complete only one transition.

SDNP Administration Server: A computer server used to distribute executable code and shared secrets to SDNP servers in the global space or in specific zones.

SDNP Bridge Node: An SDNP node that connects one SDNP zone cloud to another with different zones and security credentials.

SDNP client or client device: A network device, usually a cell phone, tablet, laptop, desktop, or IoT device running an SDNP application to connect to the SDNP cloud, typically connecting on the last mile of that network.

SDNP Cloud: A network of interconnected SDNP servers that run soft switch executable code to perform SDNP site operations.

SDNP Gateway Node: A media node connecting the SDNP cloud to the last mile of SDNP and the client. SDNP gateways require access to at least two areas - the SDNP cloud and the last mile.

SDNP Media Node: A soft switch executable code that processes incoming data packets with specific identification tags in accordance with the instructions of the signaling server or other computer performing the signaling function, including encryption / decryption, scrambling / descrambling, mixing / splitting, tagging and generating SDNP headers and subtitles. The SDNP media node is responsible for identifying incoming data packets with specific labels and for forwarding the newly generated data packets to the next destination.

SDNP Media Server: A computer server that hosts a soft switch that acts as an SDNP media node for two-link and three-link communications, and also performs the tasks of an SDNP signaling node and SDNP name server node for single-link communications.

SDNP Name Server: A computer server that hosts a soft switch that acts as an SDNP name server node for three-link communications.

SDNP Name Server Node: Soft switch executable code that manages a dynamic listing of each SDNP device connected to the SDNP cloud.

SDNP Network: The entire hyper-secure communications network extending from customer to customer, including the "Last Link" and "Last Mile" sites, as well as the SDNP cloud.

SDNP Node: An SDNP communication node containing a soft switch running on a computer server or hardware device connected to the SDNP network, acting as an SDNP node - media node, signaling node, or name server node.

SDNP Server: A computer server that is either an SDNP media server, an SDNP signaling server, or an SDNP name server and implements the appropriate softswitch functionality to act as an SDNP node.

SDNP signaling node: The soft switch executable code that initiates a call or communication between parties, defines all or part of several routes for transmitting fragmented data based on caller criteria and a dynamic propagation delay table between nodes, and generates commands for the SDNP media node how to manage incoming and outgoing data packets.

SDNP signaling server: A computer server that hosts a soft switch that acts as an SDNP signaling node in SDNP dual and triple link systems, and also acts as an SDNP name server node in dual link systems.

SDNP tag: Source address, SDNP postal code, or any other code used to identify an incoming data packet or subpacket.

Security Operation: The process of modifying a data package to perform hiding (or restoring the contents of a hidden package) using state-dependent credentials related to the zone and state in which the package was created.

Security Parameters: Numerical values, such as seed and keys, which are generated by seed generators or secret key generators in combination with an ever-changing input state, such as network time, and which can therefore be safely transmitted over public or unsecured links.

Initial State: A hidden numerical value that is generated by entering a state, such as time, into an initial state generator that generates an initial state using a secret algorithm. The initial state is used to select an algorithm for scrambling, decrypting, or splitting the data in the packet from the selector. The initial state can be used to securely transmit state information over public or unsecured links.

Selector: A list or table of possible scrambling, encryption, or splitting algorithms that are part of the shared secrets and that are used in conjunction with an initial state or key to select a specific scrambling, descrambling, encrypting, decrypting, splitting or mixing algorithm for a packet or packets.

Shared secrets: Confidential information about the operation of SDNP nodes, including tables or selectors of scrambling / descrambling, encryption / decryption and mixing / splitting algorithms, as well as algorithms used by seed generators, key generators, zone information and algorithm shuffling processes, stored locally on DMZ servers that are not accessible over the SDNP network or the Internet.

Single PHY: The association of bundled data packets carried over a single physical medium, such as purely optical fiber, Ethernet, Wi-Fi, or cellular networks.

State: Input data, such as location, zone, or network time, that is used to dynamically generate security parameters, such as initial states or keys, or to select algorithms for specific SDNP operations, such as mixing, splitting, scrambling, and encryption.

Time: UTC used to synchronize communications on the SDNP network.

Descrambling: A process used to restore data segments in a scrambled data packet to their original order or sequence. The descrambling function is the opposite of the scrambling function.

Zone: A network of defined interconnected servers that share common security credentials and shared secrets. Last mile connections are separate zones from those in the SDNP cloud.

Development of a Dynamically Secure Communication Network and Protocol (SDNP)

To prevent cyberattacks and hacking of a packet-switched communication system with minimal packet delay in real time, ensure strong connectivity and maximum continuity of voice and online video, the dynamic secure communication network and protocol (SDNP) discussed in this document was developed based on on a number of guiding principles, namely:

Передача данных в режиме реального времени должна всегда происходить по пути наименьшей задержки.

Real-time data transmission should always follow the lowest latency path.

При несанкционированном исследовании или синтаксическом анализе пакета данных должно быть недоступно содержимое, касающееся того, откуда поступил пакет, куда он направляется и что в нем находится.

Unauthorized exploration or parsing of a data packet should not be able to access content regarding where the packet came from, where it is going, and what it contains.

Полезная нагрузка пакета данных должна быть динамически перешифрована, т.е. дешифрована, а затем снова зашифрована с использованием другого алгоритма шифрования, исключая риск взлома в любое разумное время.

The payload of the data packet must be dynamically re-encrypted, i.e. decrypted and then encrypted again using a different encryption algorithm, eliminating the risk of being compromised at any reasonable time.

Даже после расшифровки вся полезная нагрузка пакета данных по-прежнему содержит невразумительную информацию, представляющую собой динамически скремблированное сочетание нескольких разговоров и несвязанных данных, смешанных с бессмысленными наполнителями пакета.

Even after decryption, the entire payload of the data packet still contains unintelligible information, which is a dynamically scrambled combination of multiple conversations and unrelated data mixed with meaningless packet fillers.

Implementation of the above guidelines includes many unique ways, functions, properties and implementations, including in whole or in part in various embodiments of the invention:

SDNP использует одно или несколько выделенных облаков, содержащих телефонную систему, функции программного переключателя, реализованные с использованием проприетарного программного обеспечения управления и контроля, недоступного через Интернет.

SDNP uses one or more dedicated clouds containing the telephone system, soft switch functions implemented using proprietary command and control software not available over the Internet.

Передача данных внутри облака полностью происходит с использованием выделенной системы маршрутизации пакетов SDNP в проприетарных облаках на основе адресов SDNP и динамических портов (т.е. проприетарных адресов NAT), а не IP-адресов распознаваемых DNS. Адреса SDNP не могут использоваться или маршрутизироваться через Интернет или за пределами облака SDNP.

All intra-cloud communication is done using dedicated SDNP packet routing in proprietary clouds based on SDNP addresses and dynamic ports (i.e. proprietary NAT addresses) rather than DNS resolved IP addresses. SDNP addresses cannot be used or routed over the Internet or outside of the SDNP cloud.

Сеть SDNP постоянно идентифицирует и осуществляет динамическую маршрутизацию всей передачи данных в режиме реального времени по имеющимся путям с самой малой задержкой.

The SDNP network continuously identifies and dynamically routes all data transmission in real time over the available paths with the lowest latency.

Никакая защищенная или выполняемая в режиме реального времени передача данных не маршрутизируется вне облака SDNP или через Интернет, кроме передачи данных между облаками и на участке последней мили, и, кроме того, обычно использует маршрутизацию для одного перехода с невидимыми адресами.

No secure or real-time data transfer is routed outside of the SDNP cloud or over the Internet, other than cloud-to-cloud and last mile data transfers, and also typically uses single hop routing with invisible addresses.

Данные маршрутизации, содержащиеся в пакете данных, идентифицируют маршрут для одного перехода между двумя соседними устройствами, определяя только адреса SDNP или IP-адреса предыдущего и следующего сервера

The routing data contained in the data packet identifies the route for one hop between two neighboring devices, specifying only the SDNP addresses or the IP addresses of the previous and next server

Номер телефона или IP-адреса вызывающего абонента и получателя вызова, т.е. соответствующие адреса отправителя и получателя клиента не присутствуют ни в заголовках IP-пакетов, ни в зашифрованной полезной нагрузке.

The phone number or IP address of the caller and the recipient of the call, i.e. the client's corresponding source and destination addresses are not present in the headers of the IP packets or in the encrypted payload.

Разделяемые секреты, связанные с управлением и контролем, существуют в системном программном обеспечении, установленном на защищенных серверах DMZ, недоступных через Интернет.

Shared management and control secrets exist in system software installed on secure DMZ servers that are not accessible from the Internet.

Передача пакетов SDNP может осуществляться по трем независимым каналам, которыми являются "сервер имен", используемый для идентификации элементов в облаке SDNP; "медиа-серверы", используемые для маршрутизации содержимого и данных, и "сигнальные серверы", используемые для управления и контроля пакетов и вызовов.

SDNP packets can be transmitted over three independent channels, which are a "name server" used to identify items in the SDNP cloud; "media servers", used to route content and data, and "signaling servers", used to manage and control packets and calls.

Информация о маршруте вместе с ключами и числовыми начальными состояниями (при необходимости) может предоставляться всем участвующим в обмене медиа-серверам по отдельному сигнальному каналу до вызова или установления связи и без содержимого. сигнальный сервер передает медиа-серверам только данные о предыдущем и следующем адресатах пакета, проходящего через сеть.

Route information, along with keys and numeric initial states (if necessary), can be provided to all participating media servers over a separate signaling channel prior to calling or establishing a connection and without content. the signaling server transmits to the media servers only the data on the previous and next recipients of the packet passing through the network.

Медиа-пакеты содержат фрагментированные данные, представляющие только часть вызова, документа, текста или файла, динамически смешанные и повторно смешанные с другими пакетами, содержащими фрагментированные данные из других источников и разного типа.

Media packets contain fragmented data representing only a portion of a call, document, text, or file, dynamically mixed and remixed with other packets containing fragmented data from other sources and of different types.

Для защиты передачи данных на участках первой и последней мили используются специальные способы защиты, в том числе разделение сообщений, связанных с сигнальным сервером, и медиа-пакетов и связанных с ними пакетов содержимого.

To protect the transmission of data on the first and last mile sections, special protection measures are used, including the separation of messages associated with the signaling server and media and associated content packets.

Передача пакетов зависит от типа содержимого: голосовые сообщения и видео реального времени или онлайн-видео передаются на основе улучшенного протокола UDP, в то время как пакеты сигнализации, пакеты команд и управления, файлы данных, файлы приложений, системные файлы и другие файлы, которые чувствительны к потере пакетов или задержке, используют протокол TCP.

Packet transmission depends on the type of content: voice messages and live video or online video are transmitted based on the enhanced UDP protocol, while signaling packets, command and control packets, data files, application files, system files and other files that are sensitive loss of packets or delay, use the TCP protocol.

Для подтверждения того, что устройство является реальным клиентом, а не клоном, и для проверки подлинности того, что участвующее в передаче лицо - это настоящий владелец устройства, а не самозванец, используются специальные способы защиты и проверки подлинности.

Special security and authentication methods are used to confirm that the device is a real client and not a clone, and to authenticate that the person participating in the transfer is the real owner of the device and not an impostor.

To provide secure, low latency, high quality of service VoIP and real-time applications, the Dynamic Secure Communications Network and Protocol (SDNP) discussed in this document uses an inventive “dynamic multi-connectivity” network including:

динамическую адаптивную многолучевую и многосвязную маршрутизацию с минимальной задержкой;

dynamic adaptive multipath and multi-connection routing with minimum delay;

динамическое скремблирование пакетов;

dynamic packet scrambling;

динамическую фрагментацию с использованием разделения, смешивания, синтаксического анализа пакетов, а также наполнители пакетов бесполезными битами;

dynamic fragmentation using splitting, mixing, parsing of packets, and stuffing packets with useless bits;

динамическое внутриузловое шифрование полезной нагрузки в сети или облаке;

dynamic intra-site encryption of the payload in the network or cloud;

динамический сетевой протокол с маскировкой адресов и необходимой информацией маршрутизации;

dynamic network protocol with address masking and necessary routing information;

многоканальную связь, отделяющую среду передачи и содержимое от сигнализации, команд и управления и сетевых адресов;

multichannel communication separating the transmission medium and content from signaling, command and control and network addresses;

динамический адаптивный транспортный протокол реального времени с функциями для конкретных типов данных и контекстной маршрутизацией;

dynamic adaptive real-time transport protocol with functions for specific data types and context routing;

поддержку зашифрованной клиентом полезной нагрузки с управлением ключами пользователя;

support for client-encrypted payload with user key management;

облегченный аудиокодек для повышения качества обслуживания в перегруженных сетях.

lightweight audio codec for better quality of service on congested networks.

As already indicated, communication in an SDNP network is based on multi-route and multi-mesh transmission for the dynamic routing of data packets. Unlike single-channel packet-switched communication used for OTT data transmission to the Internet and VoIP technology, in the SDNP system in accordance with the present invention, the contents of data packets are not transmitted sequentially as integral packets containing information from a common source or from a caller, but are transmitted to fragmented form with dynamic mixing and remixing of content originating from multiple sources and callers, in which the specified data combines incomplete snippets of data, content, voice, video and data files of different types with useless data fillers. The advantage of the considered implementation of fragmentation and data transmission is that even unencrypted and unscrambled data packets are almost impossible to interpret, since they are a combination of unrelated data and data types.

By combining fragmented packet mixing and splitting with scrambling and dynamic packet encryption, these hybrid packets of dynamically encrypted, scrambled fragmented data are meaningless packets of inarticulate information, completely incomprehensible to any party or observer, without shared secrets, keys, numeric initial states as well as the state and time variables used to create, batch, and dynamically re-batch this data.

In addition, the fragmented content of each package and the secrets used to create it remain in effect for only a fraction of a second before the package is redesigned with new fragments and new protections, such as changed initial states, keys, algorithms, and secrets. The limited amount of time a cyber pirate has access to hack and crack a state-dependent SDNP data packet further enhances the security of SDNP, with one tenth of a second left to perform processing that requires tens of thousands of years of computation. twelve orders of magnitude longer than the time available for cracking.

A combination of the aforementioned methods employs multidimensional security that far surpasses the security achievable with static encryption. For this reason, the dynamic secure communication network and protocol in question is referred to herein as a hyper-secured network.

Scrambling data packets - In accordance with the present disclosure, secure packet network communication relies on several elements to prevent tampering and provide security, one of which is the scrambling of SDNP packets. Scrambling SDNP packets involves rearranging data segments out of sequence, making the information inaccessible and useless. Referring to FIG.2Aan unscrambled data packet — data packet 923 — after the scrambling operation 924 is performed, turns into a scrambled data packet 925. The scrambling operation can use any algorithm, numerical method, or sequence control method. The algorithm may be a static equation or include dynamic variables or numeric seed states based on "states" such as scrambling time 920 and a numeric seed 929 generated by an seed generator 921 that can generate an initial state 929 using an algorithm that also depends on conditions such as 920 scrambling time. For example, if each date is converted to a unique monotonically increasing number, then each seed 929 is unique. Time 920 and start state 929 can be used to select a particular algorithm, and can also be used to select or compute a particular scrambling operation 924 selected from a list of available scrambling methods, i. E. of the scrambling algorithms 922. It is convenient to illustrate this operation and the packet scrambling sequence in data flow diagrams using a schematic or symbolic representation, denoted here by symbol 926.

The descrambling operation shown in FIG. 2B illustrates the inverse function of the scrambling operation 924, namely the descrambling operation 927, where the state or time 920 and the corresponding initial state 929 used to create the scrambled data packet 925 are again used to cancel the scrambling operation to obtain the descrambled data, namely , descrambled data packet 923. If a particular state or time 920 was used in the initial scrambling of the packets, the same scrambling method shall be used again in descrambling operation 927 by selecting it from the list of scrambling algorithms 922. Although the list of scrambling algorithms 922 refers to to the term "scrambling", the same algorithm table is used to identify and select the inverse function needed to perform the "descrambling", i. e. the list of scrambling algorithms 922 contains information necessary for both scrambling data packets and descrambling data packets. Since the two functions include the same instructions executed in reverse order, the list 922 can also be renamed to the scrambling / descrambling algorithm list 922. However, for clarity, this table is indicated only by the name of the function without indicating its inverse function.

If the scrambling algorithm chosen to implement the descrambling operation 927 does not match the original algorithm used when scrambling the packets, or if the initial state 929 or the state or time 920 does not match the scrambling time, then the descrambling operation will not be able to recover the original descrambled data packet 923, and package data will be lost. It is convenient to use data flow diagrams to illustrate this packet descrambling process using a schematic or symbolic representation, denoted here by symbol 928.

In accordance with the contemplated invention, various algorithms can be used to perform the scrambling operation, provided that the process is reversible, which means that repeating actions in the opposite order with respect to the original process returns each data segment to its original and correct position in a given data packet. From a mathematical point of view, acceptable scrambling algorithms are those that are reversible, i.e. when the function F (A) has an inverse function F ^-1 (A) or, alternatively, the transformation has a corresponding inverse function for which

F ^-1 [F (A)] = A

This means that when you apply function F to a data file, sequence, character string, file, or vector A, and then apply the inverse function F ^{-1, you} will get the original input A, which has not changed in either size or order of elements.

Examples of such reversible functions are illustrated by the static scrambling algorithms shown in FIG. 2C , including specular reflection and phase shift algorithms. In mirroring algorithms, data segments are replaced by other data segments that are mirror images of them about an axis of symmetry defined by the module ("mod") of the mirroring process. In modulo 2 mirroring, as shown in the figure, every two data segments of the original packet of input data 930 are swapped, i. E. swap places 1A and 1B, similarly to 1C and 1D, 1E and 1F, etc., thus forming a scrambled output data packet 935 with symmetry axes between the first and second data segments, between the third and fourth data segments, and so on. or, in the language of mathematics, in positions 1.5; 3.5; 5.5; ...; (1.5 + 2n).

In mod 3 mirroring, the first and third data segments in each triplet of data segments are reversed, and the middle packet of each triple remains in its original position. Accordingly, data segments 1A and 1C are swapped, and 1B remains in the center of the triple; data segments 1D and 1F are swapped, and 1E remains in the center of the triplet, etc., thus forming a scrambled output data packet 936. In mod3 mirroring, the symmetry axes are at positions 2, 5, 8, ..., ( 2 + 3n).

In mod 4 mirroring, the first and fourth, as well as the second and third data segments from each four data segments are swapped, etc., thus forming a scrambled output data packet 937 from the input data packet 931. Accordingly, data segment 1A is swapped with 1D; data segment 1B swaps with 1C; etc. In mod 4 mirroring, the axis of symmetry is between the second and third data segments of each quad, i.e. between the 2nd and 3rd data segments, 6th and 7th data segments, etc., or, in the language of mathematics, in positions 2.5; 6.5; ...; (2.5 + 4n). In modulo m mirroring, the mth data segment of the input data packet 932 is replaced by the first, i. E. 0th data segment; 0-th data segment is replaced with m-th element; and similarly, the n-th element is replaced with an (m-n) -th data segment to form a scrambled output data packet 938.

Another scrambling method, also shown in FIG. 2C is a frame shift where each data segment is shifted left or right by one, two, or more frames. For example, with a phase shift of one frame, each data segment is shifted by one frame, with the first data segment shifting to a second position; the second data segment is shifted to the position of the third frame, etc., thereby producing a scrambled output data packet 940. The last frame of the input data packet 930, frame 1F in the example shown, is shifted to the position of the first frame previously occupied by data segment 1A.

With a phase shift of 2 frames, the first data segment 1A of the input data packet 930 is shifted two frames to the position previously occupied by the data segment 1C, the fourth frame 1D is shifted to the last position of the scrambled output data packet 941, the penultimate data segment 1E is shifted to the first position, and the last 1F is shifted to the second position. Likewise, with a phase shift of 4 frames, the data segments of the input data packet 930 are shifted four positions, with the first frame 1A replacing the frame that was previously 1E, 1B replacing 1F, 1C replacing 1A, etc., while a scrambled output data packet 942 is formed. In the case of maximum phase shift, the first frame replaces the last; the second frame initially occupied by segment 1B becomes the first frame of the output packet 943, with the second element shifted to the first position, the third to the second, and so on. The phase shift of one frame beyond the maximum phase shift leads to the fact that the output data does not differ from the input data. In the examples given, the data is phase shifted to the right. The algorithm also works with a phase shift to the left, but with different results.

The above algorithms and similar methods are referred to herein as static scrambling algorithms because the scrambling operation occurs at the same time and transforms a set of input data into unique output data. In addition, the previously described algorithms do not use the data packet value to determine the order in which the scrambling is performed. Referring to FIG. 2D , in accordance with the subject invention, parametric scrambling means that the scrambling method is selected from a table of possible scrambling algorithms, for example, sort #A, sort #B, etc. based on the value obtained from the data contained in the data packet itself. For example, suppose each data segment can be converted to a numeric value based on a computation of the data contained in that data segment. One possible approach to determining the numerical value of a data segment is to use the decimal or hexadecimal equivalent of the bit data in the data segment. If a data segment contains multiple members, the numeric equivalent can be found by summing the numbers in the data segment. The data segment is then combined into a single number or "parameter" by which the scrambling method is then selected.

In the example shown, at block 950, the unscrambled data packet 930 is parametrically converted to a data table 951 containing a numeric value for each data segment. According to the figure, data segment 1A (0th frame) has a numeric value of 23, data segment 1B (1st frame) has a numeric value of 125, and so on. Then, at block 952, one data packet value is retrieved for the entire data packet 930. In the example shown, the sum 953 is the result of linear mixing of all data segment values from table 951 and is equal to 1002. At 954, this is a parametric value, i. E. the sum 953 is compared against a condition table, for example, a set of predefined if-then-then operators available in software to compare the sum 953 with a number of non-overlapping numeric ranges in table 955 to determine which sorting procedure to use. In this example, the parametric value 1002 is in the range 1000 to 1499, which means that you should use the sort routine sort #C. After selecting the sorting procedure, the parametric value is no longer required. Thereafter, at block 956, the unscrambled input data 930 is scrambled in the selected manner to produce a scrambled output packet 959. In the illustrated example, the Sort #C shown in table 957 contains a set of relative movements for each data segment. The first data segment of the scrambled data packet 959 (0th frame) is determined by moving the 1D data segment three positions to the left, i. E. shifting it three times. The first frame contains data segment 1B, it does not change its original position, i.e. moves to 0 places. The second frame contains the segment of data 1E, shifted two positions to the left from the original position. Likewise, the third frame contains the 1F data segment two positions to the left from the original position. The fourth frame of the scrambled output data packet 959 contains the data segment 1C shifted to the right, i. E. at +2 positions, relative to its original position. The fifth frame contains the data segment 1A, shifted five positions to the right, i. E. by +5 positions, relative to its original position.

Thus, according to table 957 for sort #C, each data segment is moved to a uniquely determined new position, thereby forming a parametrically determined scrambled data packet 959. To descramble this scrambled data packet, the process is performed in reverse order using the same method. sorting sort #C. To ensure that the same algorithm is selected to perform the descrambling operation, the parameter value 953 of the data packet cannot be changed as a result of the scrambling operation. For example, linear mixing of the parametric value of each data segment yields the same numeric value regardless of the order of the numbers.

Dynamic scrambling uses the state of the system, such as time, to be able to identify the conditions under which the data packet was scrambled, allowing the same method to be selected to perform the descrambling operation. In the system shown in FIG. 2E , the state is used to create a masked numeric seed that is sent to the sender or receiver of the packet, which then uses this seed to select a scrambling algorithm from the table. Alternatively, the state itself can be transmitted to the sender or receiver, and this state can be used by a hidden number generator located at the sender or receiver, where a hidden number is selected for the scrambling / descrambling algorithm. FIG. 2E , where a state such as time 920 is used to generate a hidden number 961 with a hidden number generator 960 and a hidden number 961a from a list of scrambling algorithms 962 is used to select a scrambling method. The hidden number generator 960 can also input the hidden number HN 961b directly into the operation scrambling 963, where HN can act as a variable during the scrambling operation. As shown in FIG. 2F, state 920 may be passed directly to hidden number generator 960, or state 920 may be passed to hidden number generator via material generator 921.

Choosing a scrambling algorithm based on a hidden number rather than just a numeric seed has the advantage that it eliminates any possibility of criminal re-creation of the scrambling table by analyzing the data stream, i.e. statistically matching repetitive scrambled data sets with corresponding numeric seed states. The initial state can be visible in the data stream and therefore vulnerable to espionage, while the hidden number generator and the hidden number HN it creates are based on shared secrets. Thus, the hidden number HN is not present in the data stream, is invulnerable to espionage and parsing, which means that it is not transmitted over the network, but generated locally from the numeric initial state. Thus, this mathematical operation - a hidden number generator - provides increased security in terms of preventing hacker attacks, because the assignment of a numeric initial state is masked.

Once an algorithm is selected, the numeric seed can also be used as an input variable in the scrambling process algorithm 963. The dual assignment of the numeric seed further confuses the analysis because the seed does not directly select the algorithm, but works with it to determine the final sequence of scrambled data segments. Likewise, in order to descramble a dynamically scrambled data packet, the initial state 929 (or alternatively state or time 920) must be transmitted from the communication site, device, or software initially performing the scrambling to any node or device that wishes to descramble it.

In accordance with the contemplated invention, seed generation algorithm 921, hidden number generator 960, and scrambling algorithm list 962 are "shared secrets" - information stored on a DMZ server (as described below) and unknown to either the sender or the recipient of the data packet. The shared secret is set in advance and is not associated with the transmitted data packets, except, possibly, the time of setting the code, where various authentication procedures are used to prevent the leak of the secret. As described below, shared secrets can be restricted to "zones," so knowing one set of stolen secrets still prevents a hacker from gaining access to the entire communications network or intercepting messages in real time.

In addition to shared secrets in dynamic scrambling, where the scrambling algorithm changes during the transmission of a data packet, an initial state based on "state" is required for scrambling or descrambling data. This state on which the initial state is based can be any physical parameter such as time, site number, network ID, or even GPS coordinates, provided that there is no uncertainty about the state used in generating the initial state, and provided that means of informing the next node about what state was used when scrambling the previous data packet. The algorithm used by the seed generator to create an initial state is part of a shared secret, and therefore knowing the initial state makes it impossible to determine the state on which this initial state is based. The initial state can be transferred from one communication site to another by placing it in the data packet itself, sending it through another channel or path, or using any combination of these methods. For example, a state used to generate seed can include a random number generated by a counter and then incremented by a fixed number each time a data packet passes through a communications site, each number representing a specific encryption algorithm.

In one embodiment of dynamic scrambling, when the scrambling operation is first performed, a random number is generated to select the scrambling method to be used. This random number is placed in the data packet in its header or in that part of the data packet that is reserved for commands and control, and is not scrambled. When a data packet arrives at the next node, the entered number is read by the communication node and used by the software to select the proper algorithm for descrambling the incoming data packet. Then this number, i.e. "counter value" is incremented by one or some other specified integer, the packet is scrambled according to the algorithm associated with this new number, and this new number is written to the output data packet, replacing the previous number. The next site repeats this process.

In an alternative embodiment of the present method, based on a counter for selecting a scrambling algorithm, a random number is generated to select an initial scrambling algorithm, and this number is sent to each communication node used to transmit a particular data packet as a "shared secret". The counter value, for example, starting from 0, is placed in the data packet in its header or in that part of the data packet that is reserved for commands and control, and is not scrambled. This data packet is then forwarded to the next communication node. When the packet arrives at the next communication node, the server reads the counter value, adds this value to the initial random number, identifies the scrambling algorithm used in the previous data packet scrambling operation, and descrambles the packet accordingly. Then the counter value is incremented by one or any other specified integer, and this counter value is again stored in the header of the data packet or that part of the data packet that is reserved for commands and control, and is not scrambled, instead of the previous counter value. A random number serving as a shared secret is not transmitted in the communication data packet. After the data packet arrives at the next communication node, the server adds a random number, which is a shared secret, added to the changed counter value extracted from the data packet. This new number uniquely identifies the scrambling algorithm used by the previous site to scramble the incoming packet. In the case of this method, a cybercriminal can only intercept the uninformative counter value from the unencrypted part of the data packet, looking at which there is no idea what this data means.

In another alternative method, a hidden number can be used to convey the state of the packet and what algorithm was used to scramble it. The hidden number combines a time-varying state or seed with a shared secret, which is typically a numerical algorithm, and they are used together to create a confidential number, i.e. "hidden number", which is never transmitted between communication nodes and, therefore, is not the subject of parsing or research in a man-in-the-middle attack or by a cyber pirate. The hidden number is then used to select the scrambling algorithm to be applied. Since the state or initial state is meaningless without knowledge of the algorithm used to compute the hidden number, and since the algorithm, which is a shared secret, can be stored behind a firewall that is not accessible over the network or the Internet, no monitoring of network traffic will be able to detect the pattern. To further complicate matters, the location of the initial states can also be a shared secret. In one embodiment of the invention, the number transmitted in the non-scrambled part of the data packet and available for observation and data parsing, for example, 27482567822552213, is a long number, in which only a part of it is the initial state. If, for example, the initial state is determined by the numbers from the third to the eighth, then the real initial state is not the whole number 27 482567 822552213, but only its part in bold, i.e. the initial state is 48256. This seed, together with the shared secret algorithm, is then used to generate a hidden number, and this hidden number is used to select a scrambling algorithm that dynamically changes across the network.

The application of encryption of data packets in the SDNP network is described in Appendix No. 14/803 869 dated July 20, 2015, entitled "Secure Network and Dynamic Link Protocol". The application of encryption of data packets in the Last Mile connection will be described in more detail in this section.

Data passing over the network, although scrambled, can be considered a "text file" because the actual data is present in the data packets; packets are not converted to ciphertext. In contrast, in ciphertext, a character string containing the original data, whether it is scrambled or not, is converted to a meaningless series of meaningless characters using the encryption key, and cannot be converted back to its original text file form without the decryption key. The role of encryption in this SDNP communication system is discussed below in the Encryption section.

In order to change the sequence of data packets during transmission over the network, it is required to "re-scramble" the packets as shown in FIG. 53. The packet re-scrambling process converts the scrambled data packet to its original unscrambled state and then scrambles it again according to the new scrambling algorithm. Thus, the term "re-scrambling" as used herein means descrambling a data packet and then re-scrambling it, typically using a different scrambling algorithm or method. This approach eliminates the risk of data corruption arising from scrambling a previously scrambled packet and loss of control over the sequence tracking, which is necessary to restore the original data. According to the figure, a scrambled data packet 1008, originally scrambled with a packet scrambling operation 926, is "re-scrambled", first by descrambling it with a descrambling operation 928, using the reverse operation of the scrambling algorithm that scrambling the data and then scrambling the packet re-scrambling operation 926, but with a different scrambling algorithm than the one used in the previous scrambling operation 926. The resulting re-scrambled data packet 1009 differs from the previous scrambled data packet 1008. The re-scrambling operation 1017 is sequential performing descrambling and subsequent scrambling, and in this document is called "US re-scrambling", where "US" is an abbreviation from the English. Unscrambling-Scrambling, which means "descrambling-scrambling". In order to recover the original data packet 930, the operation of descrambling the final packet 928 needs to apply the inverse function of the same algorithm that was used for the previous re-scrambling of the data packet.

In accordance with the contemplated invention, static and dynamic scrambling of data renders the interpretation of unscrambled data meaningless, turning sound into unrecognizable noise, turning text into a disjointed set of characters, turning video into "video snow" and the scrambling code into unrecoverable. Scrambling itself provides a high degree of security. However, in the SDNP method discussed in this document, scrambling is only one of the elements designed to provide and guarantee secure communication that prevents hackers from interfering with cyberattacks, cyber piracy and man-in-the-middle attacks.

Packet encryption - In accordance with the present disclosure, secure packet-switched communication relies on several elements to prevent tampering and ensure security, one of which is SDNP encryption. As stated above, the word "encryption" is of Greek origin, meaning "hide, hide, obscure", and is a means of converting normal information or data, commonly referred to as a "text file", into "cipher text", which has an incomprehensible format, which makes data unreadable without secret knowledge. In modern communications, this secret knowledge is usually associated with the sharing of one or more "keys" used to encrypt and decrypt data. Typically, these keys contain pseudo-random numbers generated according to a specific algorithm. Numerous articles and texts have been written today discussing the merits and demerits of various encryption methods, for example: "Cryptonomicon" by Neil Stevenson, © 1999; The Book of Ciphers: The Science of Secrecy from Ancient Egypt to Quantum Cryptography by Simon Singh, © 1999; Practical Cryptography by Niels Ferguson, © 2013 and Cryptanalysis: An Investigation of Ciphers and Their Decryption, first published in 1939.

Despite the fact that the concept of encryption or ciphers appeared in ancient times and is well known to specialists in this field, the application of cryptography in the considered dynamically secure communication network and protocol is unique, it facilitates both end-to-end encryption and dynamic encryption for a single hop in relation to the architecture of the network itself, regardless of any client's own data encryption. The basic principle behind the architectural design of an SDNP data transmission system is that, given sufficient time, any statically encrypted file or message can ultimately be hacked and information stolen, no matter how complex the cipher is. Despite the fact that this assumption may not correspond to reality, there is no need to prove or disprove it, because the opposite approach, i.e. waiting for a specific encryption method to fail can lead to unacceptable and irreversible consequences.

Instead, the SDNP data transmission system is based on the premise that all encrypted files have a limited "shelf life", this metaphorical saying means that encrypted data is secure (secure) only for a limited period of time and that sensitive data must be dynamically re-encrypted again via at regular intervals, ideally much less than the most optimistic estimates of the time required to break a cipher using modern computers. For example, if, according to cryptologists, a large server farm of crypto engines can break this cipher in one year, then in the SDNP data transmission system the data packet will be re-encrypted every second or even every 100 ms - an interval whose value is many orders of magnitude shorter than the interval. during which the best technology is able to crack it. Therefore, encryption in SDNP is necessarily dynamic, i.e. time-dependent, and can also be space-dependent, i.e. depending on the location of the communication node in the packet-switched network or geographic location. Thus, as used herein, the term "re-encryption" refers to decrypting a data packet and then re-encrypting it, typically using a different encryption algorithm or method.

Consequently, SDNP encryption involves the repeated and frequent conversion of data from an unencrypted text file to cipher text, which makes the information unintelligible and useless. Even if the encryption of the data of a particular packet was miraculously cracked, then when using SDNP dynamic encryption methods, the next data packet will have a completely different encryption key or cipher, which will require starting a new process of breaking its encryption from the very beginning. Limiting the total content of each uniquely encrypted packet of data mitigates the potential damage from unauthorized access, since an open data packet itself contains a data file that is too small and is of little value or benefit to a cyber pirate. Moreover, by combining dynamic encryption with the aforementioned SDNP scrambling methods, communication security can be significantly improved. Even in unencrypted form, the intercepted data file contains only a small piece of data, voice or video, which scrambling turns into a meaningless and unintelligible sequence of data segments.

For security reasons, SDNP encryption is dynamic and stateful. Referring to FIG. 4A , the unencrypted data packet is a text file 930 processed by an encryption operation 1020 to form an encrypted data packet containing ciphertext 1024 or 1025. In the case of ciphertext 1024, the entire data packet of the text file 930 is encrypted in its entirety, with data segments 1A to 1F are treated as a single data file. In the case of ciphertext 1025, each data segment of text file 930 1A to 1F is encrypted separately and specifically and is not combined with other data segments. The first data segment 1A is encrypted and placed in the corresponding first data segment of the ciphertext, shown for clarity as a character string beginning with $ 7 and being a long string of characters or numbers that are not shown. Likewise, the second data segment 1B of the text file is encrypted and placed in the second data segment of the ciphertext, which is a long character string shown for clarity starting with * ^. The characters 7 $ and * ^ are shown to demonstrate the initial elements of meaningless strings of characters, numbers, and alphanumeric characters, and do not impose any restrictions or contain any specific information about the source of the text file or the length of encrypted character strings.

Encryption operation 1020 can use any available algorithm, cryptographic method, or encryption method. Although the algorithm may be a static equation, in one embodiment of the invention, the encryption operation uses dynamic variables or "states", such as encryption time 920, as well as an encryption generator 1021 to generate an "E-key" 1022, which also may depend on the state, for example, the encryption time 920. For example, the encryption date and time may be used as a numeric value to generate an encryption key that cannot be recreated even if an encryption algorithm was discovered. Time 920 or other "states" may also be used to select a particular algorithm from a list of encryption algorithms 1023, which is a list of available encryption algorithms. It is convenient to use flow diagrams to illustrate this operation and the sequence of encrypting a packet using a schematic or symbolic representation, denoted herein by the symbol shown for encryption operation 1026. Throughout the disclosure, a lock may also be a symbol representing secure and encrypted data. A lock with a dial above it indicates a secure delivery mechanism, for example, encrypted files that, if not accepted within a certain time interval or until a certain point in time, self-destruct and are lost forever.

The decryption operation shown in FIG. 4B , illustrates the inverse function of encryption operation 1020, namely, decryption operation 1031, where state or time 920 and other states used to create ciphertext 1024, together with a decryption key ("D-key") 1030 generated by D-key generator 1029 are reused to de-encrypt, that is, decrypt the file, to obtain unencrypted data containing the original data packet 990 of the text file. If a particular state or time 920 was used in the initial encryption of packets, the same encryption operation must be used again in the decryption operation 1031 by selecting it from the list of encryption algorithms 1023. Although the list of encryption algorithms 1023 refers to the term "encryption", the same table of algorithms is used to identify and select the inverse function needed to perform "decryption", i. e. the list of encryption algorithms 1023 contains the information necessary for both encrypting and decrypting data packets. Since the two functions include the same instructions in reverse order, table 1023 can also be renamed to encrypt / decrypt algorithms table 1023. However, for clarity, this table is labeled only with the function name without indicating its inverse function.

If the encryption algorithm chosen to implement the decryption operation 1031 does not match the inverse algorithm with respect to the original algorithm used in the packet encryption operation, or if the state or time 920 does not match the encryption time, or if the D-key 1030 is not related by a known numerical relationship with the E-key 1022 used during encryption, then the decryption operation 1031 will not be able to recover the original unencrypted data 990 and the packet data will be lost. In data flow diagrams, this packet decryption process is conveniently illustrated using a schematic or symbolic representation, denoted here by the decryption operation symbol 1032.

As mentioned, the use of encryption and decryption keys in cryptography and general encryption algorithms such as symmetric public key encryption, RSA encryption (an abbreviation for Rivest, Shamir, and Adleman) and AES256 (Advanced Encryption Standard - an improved encryption standard) and others are issues well known to those skilled in the art. However, the application of such known cryptographic techniques in the contemplated SDNP communications system is not as susceptible to tampering or decryption due to hidden information, shared secrets, and time-dependent dynamic variables and states unique to the contemplated SDNP communications system.

Therefore, even in the unlikely case that a cybercriminal has enough computing power to ultimately break into a secure encryption system, he lacks some information included in the SDNP network as non-public or shared secrets needed to perform a decryption operation, and he must also crack encryption system in a split second, until the cipher changes. In addition, each packet of data passing through the considered SDNP network uses its own encryption method with unique keys and dynamic states. The need to simultaneously retrieve missing information, dynamic states, and limited content in any given packet makes stealing any sensitive data from any given packet of data both defiantly difficult and unrewarding for a cybercriminal.

The application of dynamic encryption and decryption of data packets in an SDNP network is described in Appendix 14 / 803,869 "Secure Dynamic Communications Network and Protocol" referenced above. The application of packet cryptography in Last Mile communication will be described in more detail in this section.

In order to intercept an entire document, online video, or voice conversation to recover coherent serial data, a cyberattack must sequentially hack and decrypt not one, but thousands of sequential SDNP packets. The daunting challenge of continually cracking a sequence of SDNP packets is further exacerbated by the combination of dynamic encryption with the previously described methods for scrambling data packets. Referring to FIG. 5 , creating an encrypted scrambled data packet 1024 includes a sequential combination of a scrambling operation 926 and an encryption operation 1026 for converting the unscrambled data packet 990 of a text file first into a scrambled data packet 1008 of a text file and then into ciphertext 1024 of a scrambled data packet. To recover an encrypted scrambled packet, the inverse functions must be applied in reverse order — first a decryption operation 1032 to recover the scrambled text file data packet 1035, and then a de-scrambling operation 928 to recover an unscrambled text file data packet 990.

As shown in the figure, scrambling and encryption are complementary technologies to provide secure communications. Unencrypted, scrambled data passing over the network can be considered a "text file" because the actual data is present in the data packets, i.e. packages are not converted to ciphertext. Encrypted data packets or ciphertext are scrambled or unscrambled character strings converted to a meaningless series of meaningless characters using an encryption key, and cannot be restored to their original text file form without a corresponding decryption key. Depending on the algorithm used, the encryption and decryption keys can be the same key or different keys linked by a known mathematical relationship. Thus, scrambling and encryption are complementary technologies for providing secure communications in accordance with the subject invention for an SDNP data transmission system.

These two methods, scrambling and encryption, can be considered independently even when used in combination with each other, except that the sequence used to recover the original data packet from the encrypted scrambled data packet must be the opposite of the sequence used for its creation. For example, if data packet 990 was first scrambled using scrambling operation 926 and then encrypted using encryption operation 1026, then in order to recover the original data packet, the encrypted scrambled data packet 1024 must first be decrypted using decryption operation 1032 and then de-scrambled. using the de-scrambling operation 928. Mathematically, if the scrambling operation F converts a string of bits or characters into an equivalent scrambled version, and the de-scrambling operation F ^-1 cancels this scrambling, thereby

F ^-1 [F (A)] = A,

and, similarly, if the encryption operation G converts the string of the text file to an equivalent ciphertext, and the decryption operation G ^-1 cancels this encryption, whereby

G ^-1 [G (A)] = A,

then in the combined version, when sequentially performing scrambling and encryption operations, followed by decryption and de-scrambling, the original argument A is obtained - an unscrambled data packet of a text file. Respectively,

F ^-1 {G ^-1 [G (F (A))]} = A

because the actions are performed in reverse order, in particular, the decryption [G ^-1 ] of the encrypted scrambled packet [G (F (A))] recovers the scrambled data packet of the text file F (A). The subsequent de-scrambling operation F ^{-1 of the} scrambled packet of the text file F (A) recovers the original data packet A.

When using linear methods, this sequence is reversible. For example, if a data packet is first encrypted and then scrambled, then the scrambled ciphertext must first be de-scrambled and then decrypted to recover the original data packet. Respectively,

G ^-1 {F ^-1 [F (G (A))]} = A

Changing the sequence is not allowed. Decrypting a data packet that was previously encrypted and then scrambled without first de-scrambling will not restore the original data packet, i.e.

F ^-1 {G ^-1 [F (G (A))]} ≠ A

Likewise, de-scrambling a packet that has been scrambled and then encrypted will also fail to recover the original data packet, because

G ^-1 {F ^-1 [G (F (A))]} ≠ A

As a result, if a packet of a text file is scrambled before encryption, it must be decrypted before being de-scrambled; if a packet of a text file is encrypted before being scrambled, it must be de-scrambled before being decrypted.

While it is understood that scrambling and encryption can be performed in any order, in one embodiment of SDNP methods in accordance with the present invention, encryption and decryption during transmission over the network occurs more often than scrambling, and therefore encryption must occur after scrambling, and decryption - before de-scrambling, according to FIG. 5 , and not vice versa. For convenience, the combination of a packet scrambling operation 926 followed by an encryption operation 1026 is defined as an operation to encrypt a scrambled packet 1041, and its inverse operation, a combination of a decryption operation 1032 followed by a de-scrambling operation of a packet 928, is a decryption operation of a decrypted packet 1042. These are hybrid operations. can be used in static and dynamic SDNP data transmission system in accordance with the present invention.

One of the security enhancements in any implementation using static scrambling encryption is that for each data packet sent, different scrambling and / or encryption methods are applied, including changing the state, initial states and / or keys at time t ₁ , when each the data packet enters the communication network.

However, more reliable is an alternative solution with a dynamic change in the encryption and / or scrambling method of the data packet as the packet passes through the network in time. To facilitate the necessary data processing to implement a purely dynamic version of the SDNP communication system, it is necessary to combine the previously defined processes to "re-scramble" (i.e., de-scramble and then scramble) and "re-encrypt" (i.e., decrypt, and then encrypt) each packet as it passes through each communication node in the packet-switched communication network. This document sometimes uses the term "repackaging" or "repackaging" for a combination of "re-scrambling" and "re-encryption", regardless of whether the packet is decrypted initially before de-scrambling or de-scrambled before decryption. In any case, the operations of de-scrambling and decryption in this node should be performed in the reverse order of the execution of scrambling and encryption operations when the packet leaves the previous node, i.e., if the packet was scrambled and then encrypted in the previous node, then in the current node, it must first be decrypted and then de-scrambled. Typically, the packet is then scrambled and then encrypted when it leaves the current node.

The repackaging operation at the site is shown in FIG. 6 , where the data packet of the incoming ciphertext 1040 is first decrypted by a decryption operation 1032 and then de-scrambled by a de-scrambling operation 928 to recover the packet of the unscrambled text file 990 being the contents of the original packet. If any information in a packet needs to be checked, split, split, or redirected, a plain text file is the best format for doing this. Then, the data packet of the text file 990 is scrambled again using the scrambling operation 926, after which a new encryption is performed using the encryption operation 1026 to create a new scrambled data packet of ciphertext 1043. Since the repackaging operation of the incoming scrambled data packet of ciphertext 1040 is performed by sequentially performing decryption, de- scrambling, scrambling and encryption, to denote the technique described in this document in accordance with the present invention, the abbreviation DUSE is used (English Decryption - decryption, Unscrambling - de-scrambling, Scrambling - scrambling, Encryption - encryption). In a dynamically secure communication network and protocol, it is desirable that the state or time, the decryption key, and any initial states used to perform the decryption operation 1032 and the unscrambling operation 928 are different from the state or time, the initial states or encryption keys used to perform the operation. scrambling 926; and encryption 1026.

The application of repackaging data packets in the SDNP network is described in the application 14/803 869 "Secure Network and Dynamic Link Protocol", which is referred to above. The application of Last Mile data packet repackaging will be described in more detail in this section.

Mixing and dividing packages - Another key element of the dynamically secure communications network and protocol discussed in this document is its ability to split data packets into multiple sub-packets, route those sub-packets along multiple routes, and mix and match sub-packets to recover complete data packets. The packet splitting process is shown in FIG.7Awhere the data packet 1054 is split using a split operation 1051 in combination with an algorithmic split operation 1052 and an addition random information operation 1053 that has the ability to insert or delete segments of non-data random information. Similar to the excess DNA present in the human genome, random data segments are inserted using the random addition operation 1053 to expand or control the length of the data packet or, if necessary, remove them. The operation of adding random information 1053 is especially important when there is not enough data to fill the packet. The presence of random data segments embedded in a data packet also makes it difficult for cyber pirates to separate real data from noise. As used herein, a "random" packet or data segment is a packet or data segment that consists entirely of uninformative data (bits). These random bits can be injected into a stream of data packets, surrounding real data with a sea of uninformative bits.

The purpose of the split operation 1052 is to split the data packet 1054 into smaller data packets, such as sub-data packets 1055 and 1056, to process each of the constituent components. Dividing the data packet 1054 into smaller pieces provides unique advantages such as multipath support, i. E. transmission of data packets along several and different paths, and facilitating unique encryption of the constituent parts of sub-packets using different encryption methods.

The split operation can use any algorithm, numerical method, or split method. The algorithm may be a static equation or include dynamic variables or numeric seed states or "states" such as the time 920 when the incoming data packet 1054 is first generated by a series of sub-packets and the numeric seed state 929 generated by the seed generator 921, which may also depend from a state such as the time 920 at the time the data packet was created. For example, if each date is converted to a unique monotonically increasing number, then each seed 929 is unique. Time 920 and initial state 929 can be used to identify a particular algorithm selected from a list of available methods, i. E. from Algorithm 1050. Splitting (not mixing) a packet is the opposite of mixing, using the same algorithm in strict reverse order to that used previously to create a particular packet. Ultimately, whatever was done is undone, but not necessarily in one step. For example, a scrambled encrypted data packet can be decrypted but remains scrambled. The unseparated packet of incoming data 1054 processed by splitting operation 1051 is converted into multiple data packets, for example, split into packets 1055 and 1056 of constant length by splitting operation 1052 to perform the operation algorithmically. In the data flow diagrams, a packet splitting operation 1051, including splitting 1052 and an addition of random information 1053, is conveniently illustrated using a schematic or symbolic representation denoted herein by the splitting operation 1057 symbol.

However, as used herein, the term "splitting" may include splitting, which consists in dividing a packet into two or more packets or sub-packets, and in addition, it can include inserting random packets or sub-packets into the resulting " splitting "packages or sub-packages, or removing random packages or sub-packages from resulting packages or sub-packages."

The inverse function is the batch mixing operation 1060 shown in FIG. 7B , combines multiple packets 1055 and 1056 into one and forms a mixed packet 1054. Like packet splitting, the packet mixing operation can use any algorithm, numerical method, or mixing method. The algorithm can be a static equation or include dynamic variables or numeric initial states or "states" such as time 920 used to specify conditions under which incoming data packets 1055 and 1056 are mixed. The mix operation used to create a data packet can use numeric seed 929 generated by seed generator 921, which may also be state dependent, eg time 920. Time 920 and seed 929 may be used to identify a particular mixing algorithm selected from a list of available mixing methods, i. e. from mixing algorithms 1050. In data flow diagrams, this packet mixing process is conveniently illustrated using a schematic or symbolic representation, denoted herein by mixing operation symbol 1061.

In accordance with the present invention, packet mixing and splitting may use any of a large number of possible algorithms. FIG. 8 shows three of the many possible mixing methods, namely concatenation, interleaving, and algorithmic methods. During the concatenation process, a sequence of segments of data packet 1056 is added to the end of data packet 1055, resulting in a mixed packet 1054. During the interleaving process, segments of data packets 1055 and 1056 are alternately shuffled, such as 1A, 2A, 1B, 2B, etc. this results in a mixed packet of data 1065. Another method used to mix packets is an algorithm. In the example shown, the interleaved reflective symmetry algorithm reverses the order of the data segments by 1A, 2A, 1B, 2B, 1C, 2C in the first half of mixed packet 1066 and the opposite order in the second half, i.e. 2D, 1D, 2E, 1E, 2F, 1F.

The application of mixing and splitting data packets in an SDNP network is described in the aforementioned US Patent Application No. 14/803,869 entitled "Dynamic Secure Communication Network and Protocol". FIG. 9A summarizes the functional elements of SDNP, including functions and their reverse action, i.e. anti-functions, as well as dynamic components of the corresponding functions, i.e. the state or execution time of each function in the data packet. SDNP function including packet scrambling 926 and its anti-descrambling packet 928; fragmentation operations including scrambling 1057 and its mixing anti-function 1061; hide operations, including junk data insertion 1053A and delete 1053B, and encryption 1026 and decryption 1032 operations. All of these functions are performed uniquely according to time or state variables 920.

The use of mixing and splitting data packets, as well as scrambling, descrambling, encryption, decryption and concealment in transmission of data in Last Mile together constitute the SDNP Last Mile security operation. This SDNP Last Mile security operation is "directional"; the operation performed on and on all outgoing data packets is different from the operation performed on incoming data packets.

The SDNP Last Mile security operation is also symmetric and reversible to Last Mile, which means that when using local security credentials such as keys, seed values, shared secrets specific to a particular Last Mile operation, executed with an outgoing data packet on the client's device are canceled in the SDNP gateway, usually performing an anti-function, i.e. a mathematical reverse or any other operation originally performed by the client, but in reverse order. In this way, the SDNP gateway allows you to restore the original content in preparation for routing through the SDNP cloud. Likewise, for inbound data packets to the client device using the last mile zone security credentials, the SDNP Last Mile security operation performed on the client device overrides every security operation performed by the SDNP gateway, performing the anti-function in reverse order. Thus, the client device can recover the original data on all incoming data packets.

The last mile SDNP security operation is dynamic and localized; zone-specific using state-dependent conditions such as location, time, etc. to determine which parameters were used at the time of preparing the data packet and for which region, geography or locale for a particular "last mile". Due to localization, data packet provisioning across different regions and over different last mile connections never has the same encoding and security credentials. In addition, these last mile security credentials are always different from the credentials used in the SDNP cloud. Moreover, being dynamic, the state used to create data packets is constantly changing, which further complicates the actual process of securing each data packet and displays more than two identical data packets.

The unique combined use of directional symmetric reversible dynamic localized security operations specific to each Last Mile interaction, the algorithmic application of dynamic encryption, dynamic fragmentation, dynamic spoofing, and dynamic encryption used in this invention provides hypersecure communications that are unattainable with using conventional static encryption methods. The ubiquitous use of dynamic methods that operate within tens of milliseconds not only makes decryption nearly impossible, but also does not give a hacker time to decrypt or interpret a data packet before the next arrives. In practice, SDNP Last Mile security operations can be performed using software, firmware, hardware, ASICs, or any combination of the above.

While many combinations of sequences are possible, one example of SDNP Last Mile security operation is shown in FIG. 9B specifically for sequential SDNP payloads used in Last Mile single-path communications, i. E. when a client device communicates with one SDNP gateway. The process includes two work sequences, one for outgoing data packets and one for incoming data packets. In the case of outgoing data packets shown in the upper half of the figure, the “outgoing data” is first encrypted with a packet encryption operation 926, then tricked by inserting unnecessary data 1053A. In some cases, the entire package may consist solely of unnecessary data, further confusing hackers' attempts to collect data.

These packets are then split into multiple parts by splitting 1057 using parsing 1052 and sent separately to encryption 1026. Each part is then encrypted using shared or separate encryption keys, and the resulting ciphertext is arranged into a sequential SDNP payload, displayed as data package 1199A. The packet is then formatted into IP data packets i.e. "Preparing an IP packet", in preparation for transmission to the "Last Line" and "Last Mile". All operations performed are dynamic, occurring at a specific time or with a specific state of the 920A during the safety process.

In the case of the incoming data packets shown in the lower half of the figure, the incoming data from the Last Line containing the serial payload of SDNP 1199B, i. E. from the "IP packet recognition" are first decrypted in parts, or in full, using the decryption operation 1032 and the mixing operation 1061 to restore the real data stream. Then, garbage data is extracted from the packets, i.e. junk data is removed from the packets by a junk data delete operation 1053B followed by a packet fetch operation 928 to recover the "received data". All operations performed on incoming data packets must use state 920B used by the SDNP gateway when creating the data packet, i.e. contain information at a specific time or with a specific state 920B when the package was created. This status information can be transmitted by the signaling server over another communication channel or transmitted in the packet of incoming data in the form of clear text or static cipher text, i.e. text, the decryption key of which is already known by the SDNP Last Mile security operation. However, the state 920B cannot be encrypted with a key that requires the state information contained in the state 920B, otherwise the code will not be able to open and use its own security credentials.

Another example of a Last Mile SDNP security operation is shown in FIG. 9C specifically for parallel SDNP payloads used in Last Mile multipath communication, i. E. when a client device communicates with multiple SDNP gateways. As with the single-route communication described above, the process includes two work sequences, one for outgoing data packets and one for incoming data packets. In the case of outgoing data packets shown in the upper half of the figure, the “outgoing data” is first encrypted with a packet encryption operation 926, then tricked by inserting unnecessary data 1053C. In some cases, the entire package may consist solely of unnecessary data, further confusing hackers' attempts to collect data.

These packets are then split into multiple subpackets by splitting operation 1057 using parsing operation 1052 and sent separately to encryption operation 1026. Each piece is then encrypted using shared or separate encryption keys, and the resulting ciphertext is packed into multiple SDNP payloads, which are displayed as data packs 1199C, 1199D and 1199E. The packets are then formatted into separated individual IP data packets, i.e. "Preparing IP packets", in preparation for transmission to the "Last Line" and "Last Mile". All operations performed are dynamic, occurring at a specific time or with a specific state 920C during the execution of the security process.

In the case of the incoming data packets shown in the lower half of the figure, the incoming data from Last Mile containing parallel SDNP payloads 1199F, 1199G, and 1199H, i. E. from "IP Packet Recognition" are first decrypted piece by piece, then decryption operation 1032 is used, then dither operation 1061 to restore the actual data stream. Then, garbage data is extracted from the packets, i.e. junk data is removed from the data packets by a junk data delete operation 1053D followed by a packet extraction operation 928 to recover the "received data". All operations performed on incoming data packets must use the 920D state used by the SDNP gateway when creating the data packet, i.e. containing information for a specific time or with a specific state of the 920D when the package was created. This status information can be transmitted by the signaling server over another communication channel or transmitted in the packet of incoming data in the form of clear text or static cipher text, i.e. text, the decryption key of which is already known by the SDNP Last Mile security operation.

An SDNP Last Mile security operation does not need to use the same algorithms or techniques for both inbound and outbound data packets. As shown in FIG. 9D , outgoing data packets use the SDNP 1190A Last Mile security operation and the incoming data packets use the SDNP 1190B Last Mile security operation. Referring to the top half of the figure, outbound data packets can contain data representing any combination of real-time data sources from transducers or sensors, or can contain files created prior to data transfer.

For example, audio 1198A converted to electrical signals using microphone 1180 and video signals from camera 1181 are converted to an equivalent digital format using audio-video codec 1182A. The generated formats usually include png, pic, mpeg, mov, etc. standards, interpreted and compatible with standard devices according to OSI Layer 6. Using standard audio-video formats avoids the need to transfer proprietary code to open a file between source and destination. addresses.

The generated digital data of the audio / video codec 1182A is then mixed with the text data from the virtual keyboard 1183 (keyboard implemented on a touch screen) and with data files 1179A using the content mixing program 1184. This mixing program, in turn, sends data for operation on secures Last Mile SDNP 1190A and provides SDNP header information for the 1191A IP packet preparation operation to identify and tag data packets in real time from static files.

SDNP 1190A Last Mile security operation then passes the secured data packets to IP provisioning 1191A, which then embeds the SDNP payload into the IP data packets according to the routing instructions received by the SDNP signaling server 1603. The data packets can be distributed in multiple IP packets for multi-route Last Mile communication, or can be combined into a serial data line and embedded, and placed in one or more serial data packets for a single Last Mile communication line. These packets are then sent to the PHY 1192A client to add Layer 1 and Layer 2 data to complete the IP data packet.

In the reverse operation, shown in the lower half of the figure, the incoming data from the Last Line received by the PHY client 1192B is passed to the IP packet recognition operation 1191B, which identifies the incoming data as a valid message or an unknown and potentially malicious data packet. Valid messages are identified using SDNP -tags, -seeds, -keys and other identifiers previously transmitted to the client device and the IP packet recognition operation 1191B through the signaling server 1603.

Anthropomorphically, the 1191B IP packet recognition operation expects, and even assumes, valid incoming data packets. Unexpected data packets that are not properly identified are dropped and are never opened or processed again. Thus, a hacker cannot disguise himself and send valid data to any SDNP node without first registering his identity in the SDNP cloud.

The IP packet recognition operation 1191B transfers the valid data packets to the Last Mile security operation SDNP 1190B, which in turn performs all the necessary operations to restore the original content of the data packet - data consisting of a sequential combination of video, audio, texts and data files. Content demultiplexer 1193, which allows data to be recovered from a mixing operation used to create data packets, for example, it recovers a sequential data file created by a mixing operation 1184 in another party's telephone, which is then used to separate different types of files. Data produced by demultiplexer 1193 includes text displayed in messenger window 1196, data files 1179A, and data sent in real time to audio-video codec 1182B. The audio-video codec 1182B converts digital presentation layer data into live video images 1195, or through speaker 1194 to sound 1198B.

To transfer Last Mile data, the data must be entered or packaged into the layered organization system shown in FIG. 9E , similar to the aforementioned Matryoshka model. Accordingly, SDNP payload 438 is transport payload 437, which together with transport header 436 constitutes IP 435 payload. The combination of IP 435 payload with IP header 434 is an IP datagram equivalent to MAC payload 432. Payload wrapping MAC 432 into MAC header 431 and MAC footer 433 results in a MAC "frame", a frame that is equivalent to physical layer 490, also known as PHY Layer 1 content, consisting of physical media such as electrical signals, light, radio waves, or microwaves. ...

In SDNP routing, the Layer 2 MAC header 431 describes the MAC connection of the Last Line, i.e. the connection between the client device and the first device in the Last Mile connection. Using the source and destination addresses of the client device and SDNP gateway, header 434 at Layer 3 defines the endpoints of the Last Mile routing. However, since Last Mile is not part of the SDNP cloud, the exact route that data packets take in Last Mile cannot be clearly defined or controlled. In SDNP Last Mile, Layer 4 transport header 436 defines the UDP that is used for the real-time SDNP payload, and also defines a specially assigned SDNP port address in each packet - an address that changes dynamically to prevent cyberattack strategies when polled ports.

SDNP Payload 438, Last Mile IP Packet Payload, contains SDNP Preamble 1198 containing zone information, keys, seeds, and SDNP 1199A data field, a sequential string of multiple segments of independently ciphertext. The decrypted form of the ciphertext consists of text files 1197A, 1997B, and 1197C, each of which contains its own unique SDNP header, as well as corresponding data on data files 91, 92, and 93, respectively. Separate subheadings contain information related to tags, archives, addresses, urgency and QoS data, as appropriate.

The functions of the preamble and SDNP headers differ depending on the monitoring and control methods used. In Last Mile three-way communication, the signaling server instructs the client device and SDNP gateway (s) how to communicate with each other to place a call, send a file, or open a session. In this way, instructions are sent to both devices using a TCP control packet before any multimedia data packets are transmitted. Thus, for Last Mile communication between a client and an SDNP gateway, the minimum data required are the tags or addresses used to identify the incoming packet. In some cases, for example, if it is not possible to reach the signaling server, then the SDNP data packet may alternatively contain additional data in the packet headers and preamble.

The data packet and accompanying table 1177 shown in FIG. 9F illustrate one example of a format used to convey SDNP information within an SDNP payload 438. A data packet includes an SDNP 1198 preamble and one to eight 1178X data field headers with corresponding Data Field X data fields. Each data field such as "data field 1", "data field 2", etc. is preceded by a corresponding header Hdr 1, Hdr 2, and so on. and contains communiqués including voice messages, text, videos, images, movies, files, etc. The number of data fields can vary from one to eight according to the 4b length of the # field, i.e. from binary 0001 to binary 1111. The length of SDNP 1198 preamble and SDNP 438 payload depends on Field # specification. If only one field is selected, i.e. if Field # = 0001 is binary, SDNP 1198 preamble will contain only L Fld 1 (L Fld 2 to L Fld 8 will be eliminated) and SDNP 438 payload will only include Hdr 1 and data 1 field. .e. if Field # = 1111 is binary, then SDNP 1198 preamble will contain eight field length specifications from L Field 1 to L Field 8 and SDNP 438 payload will include eight data and header fields sequentially as Hdr 1, Data 1 field, Hdr 2, field Data 2, .... Hdr 8, Data 8 field. As shown in the SDNP 1198 preamble, there are specifications for the field lengths L Fld 1, L Fld 2 and L Fld 8. The small gap between L Fld 2 and L Fld 8 is intended to to show that the sequence continues and does not represent a break in the data.

The length of each data field defined in L Fld X can range from zero or 0B (zero data field) to a maximum hexadecimal length of FFFF or 65.535B. For practical Ethernet compatibility reasons, the maximum data packet length for any field is preferably limited to 1500B or Hex 05DC, and the total length of all data fields should not exceed the packet size of 9000B or Hex 2328. The specified length of each data field can vary independently. The length of the zero field, for example, where L Fld 8 = 0000 hexadecimal, leads to the deletion of the corresponding data field 8, but not to the deletion of the corresponding Hdr 8 header. Headers are deleted only according to the Field # specification.

According to this SDNP protocol, the distribution of content across different data fields is extremely flexible. Data directed to a single destination can be contained within a single data field, or, for the purpose of deception, it can be split into multiple data fields and combined with unnecessary data. The data fields can be resized independently of each other. Data fields can also contain only unnecessary data, or entire data packets can be generated containing only unnecessary data. However, for efficient packet routing, data destined for different destinations must be split into separate data fields, each with its own unique headers.

The SDNP packet format is applicable for end-to-end data transfer across the entire SDNP network, including multiple cloud areas such as SDNP cloud or Last Mile link. Although the content of SDNP data packets changes as they travel across the network, the format of SDNP packets remains unchanged. Because this format includes minimal data transfer overhead, the SDNP data packet format is equally suited for heavy workloads or for critical real-time communications. The packet format is suitable for bidirectional data flow, i.e. for data flow from the Last Mile to the SDNP gateway and through the SDNP cloud, or vice versa, to deliver data packets outgoing from the cloud, leaving the SDNP gateway for transport across the Last Mile to the intended client device.

In operation, the routing direction of SDNP data is determined by the Layer 3 Network Source and destination addresses described in IP header 434 in FIG. 9E. Each packet is loaded with its own source and destination addresses, while the media node prepares the packet for transmission to the next media node along its route. In three-link communications, the SDNP or packet destination IP address is delivered from the signaling server to the media nodes as a control and management (C&C) packet before provisioning outgoing packets. In general, the signaling server is capable of sending control and management instructions to every node in the communication path, including both transmitting (caller) and receiving (recipient) devices. If only single-channel communication is available, for example, in connection with long propagation delays, the signaling server cannot warn the media node of the incoming packet in advance or what to do with it. In this case, the routing addresses are carried in the inbound data packet in the SDNP 438 payload. In such cases, the media server follows the default instructions on how to handle the inbound packet using the data fields contained in the inbound SDNP packet, including routing and status information. as well as security credentials.

Payload 438 consists of two parts: a readable part containing the preamble 1198 and an unreadable part 1199a containing data in "hidden form". The content of this package can use any number of obfuscation techniques to disguise its contents, such as encryption, scrambling, and possibly the use of junk data. The hiding method used must be reversed to retrieve the useful content 1197a, 1997b, and 1197c. These packets contain the destination addresses of future outgoing packets. Addresses only exist in unhidden or decrypted form for a short period of time before the next packets can be prepared and encrypted.

As described, SDNP Preamble 1198 contains information specific to the entire packet. In addition to the specifications of the data fields, FIG. 9F illustrates SDNP preamble 1198 and includes the SDNP zone in which the SDNP packet was generated, eg, U1 zone, two numeric seeds, and two keys. These keys and seeds can be used as special security credentials for zones during scrambling / descrambling, adding / removing garbage, mixing / splitting and encryption / decryption processes. Seeds and keys can be used as a unique means of delivering credentials required to open and read data fields, or in combination with control and management packets sent to the client device and SDNP gateway from the signaling server, a network of control and management computers not participating in transfer of message content in data packets.

Seeds and keys can be safely delivered in the public domain, i.e. in unencrypted form, since the data does not contain the information necessary for its use - it is only part of the security credentials. Other parts of the security credentials that are missing may have been sent earlier in another data packet, or may contain shared algorithm secrets, lookup tables, and codes not delivered over the network and not part of the message. Encryption keys can be symmetric when both the sender and recipient have the key, or public keys where the public, including the sender, has access to the encryption key, but only the recipient, i.e. the party generating the encryption key has the decryption key. Moreover, all security credentials are limited to a specific security zone, such as U1, and are dynamic, limited to a specific time or state, which expire if they are not used for a specific time. If the key and seed data fields are not used as security credentials, for example because the signaling server itself instructs SDNP devices about security operations, then these fields can be populated with numeric values that represent encryption keys, mistakenly directing an attacker to parse a false security key. , forcing to waste time.

In Last Mile communications, intermediate routers between the client device and the SDNP gateway do not process, decode, or open transmitted data packets because they are not part of the SDNP network and cannot query or interpret data within an SDNP packet. Instead, all security operations are performed exclusively at two endpoints - the SDNP client and the SDNP gateway, since only these devices act as SDNP communication nodes. Because each endpoint dynamically executes SDNP protocols, Last Mile communication is hypersecure throughout the Last Mile. If the other caller is also using SDNP software, then the second party's Last Mile is also protected by the aforementioned SDNP methods, and end-to-end hypersecure communication is guaranteed - from one subscriber to another.

However, if the end device is not an SDNP client, then the router closest to the caller, i.e. a Last Line router may be equipped with SDNP, and the Last Line can be sufficiently protected from the special functions performed by an SDNP equipped router, although it is not equipped with SDNP. This alternative method of protecting the Last Line is described in more detail in subsequent sections of this document and will not be discussed in this section. The described method, although applicable to ensure the security of Last Line communications, is not sufficient to protect other parts of the Last Mile.

As in FIG. 9F, each SDNP data field is accompanied by an SDNP 1178X data field header containing information uniquely applicable to the corresponding data field but not useful to other data fields. In particular, in the disclosed embodiment, each header contains a data type field describing what data is contained in the corresponding data field, a destination address field used to identify a specific data field and its purpose, a zone field used to transfer information about a zone from one zone to other, as well as information on urgency and delivery. As shown in the figure, each SDNP 438 payload contains one SDNP 1198 preamble and one or more SDNP 1178x data field headers and corresponding x data fields, where x describes the number of individual payloads, which can range from 5 to 50 depending on size and the urgency of these payloads.

Although the signaling server can provide most of the described information to the SDNP client and SDNP gateway, one of the fundamental components required by a Last Mile data packet is the "address field" or tag required to identify the data packet. A field called the destination address of the SDNP payload (abbreviated in the figure as "Dest Addr") may contain any unique identifier sufficient to distinguish the identifier of one data field from another. Its purpose is similar to the function of barcodes used to mark and track baggage at the airport or boxes sent by courier. Address types can include, for example, digital tags, SDNP zip archives, IPv4 or IPv6 addresses, NAT addresses, or even a POTS phone number if the identifier is unique to prevent conflicts when identifying the data packet. The size of the destination address field depends on the type of address type selected.

To keep packets anonymous during routing, it is preferable to use confidential codes such as SDNP zip code as the SDNP destination address rather than using real phone numbers or IP addresses. In operation, whenever a data packet from an SDNP client arrives at the SDNP gateway, the SDNP payload is decrypted and then each data field header is checked to determine the destination addresses. Before checking the header of a data packet, the data packet must be decrypted or processed to reverse the concealment methods used to create the packet. In the case of a two-way or three-way connection, as shown in FIG. 9G , the signaling server 1603 has previously informed the SDNP gateway of the planned arrival of the data packet and its corresponding identification mark and security credentials. Thus, when the SDNP gateway receives data packet 438A including Last Mile data transmission from the SDNP client, the gateway performs the SDNP 1190D Last Mile security operation to convert the ciphertext SDNP payload to plain text data packet 438B. The security operation describes the processing of an outgoing data packet to hide its contents and the process of modifying an incoming data packet to expose its contents. In particular, a security operation performed on an incoming data packet is used to restore its contents by undoing hiding operations performed on it prior to transport, including using decryption to unencrypt, descramble to unscramble, undo junk data insertion to delete " junk "data and mixing to undo the split operation. These processes are performed according to the state and zone of the data packet at the time of its creation. For outgoing data packets, the security operation consists in hiding the contents of the data packet prior to transport by performing encryption, scrambling, junk data staging, and dividing the packet according to the state and zone of the data packet at the time of its creation. The unencrypted seed and key data fields in data packet 438A can be ignored or optionally used in conjunction with signaling server information to decrypt the ciphertext. As a result of the operation, data field 1 and its associated header of data field 117D marked Hdr 1, containing the destination address of the data field, data type, urgency, and delivery information, are opened. In such cases, the destination address is not the routing address, but only the SDNP routing code, i.e. a tag used to identify a packet that is part of a particular conversation.

After a specific data field contains an identified destination address, such as an SDNP routing code corresponding to the signaling server 1603 instructions, the data field is extracted, optionally mixed with other related content by the 1184Z mixer, and repackaged into a new IP or SDNP datagram using a prepare operation. SDNP 1191Z packages for delivery to the next destination. The new data packet sent to the cloud includes the SDNP 434Z header containing the destination of the new packet and the data content, SDNP 435Z payload. The recipient provided by the signaling server 1603 to the media gateway node as an IP address or SDNP address may consist of another SDNP server acting as an SDNP cloud node, or may include transmitting Last Mile data to another SDNP client. In these three-link cases, the destination address is not really an address, but a means of identifying a packet where the next destination is already known to the SDNP gateway. In case the packet destination is for SDNP cloud routing, the data packet is then processed by SDNP cloud security operation 1190Z according to the Z1 accounts for the cloud, not the U1 accounts used in Last Mile.

In single-channel communication, as shown in FIG. 9H , the signaling server cannot inform the SDNP gateway in advance of the impending arrival of the data packet and its data fields, either because (i) there is no signaling server on the local network, (ii) the signaling servers are temporarily down, or (iii) the signaling server is too busy and is unable to route packets in advance in time. In such cases, the 438A data packet from the SDNP client must contain the necessary security credentials for Zone U1, Seed 1, Seed 2, Key 1 and Key 2 to decrypt the data packet using Last Mile SDNP 1190D security operation transforming encrypted 438A data packet into plain text data packet 438B. The standard SDNP data packet format reserves these data fields even if the content of the field is not required by a particular media node. For example, if the specific masking process used to create the data packet does not use the Key 2 field, the data in this field is meaningless and is not used by the destination host. However, a data packet reserves the same number of bytes for a used or unused field, so that all SDNP data packets have a uniform format. After decrypting the ciphertext in data packet 438A, the SDNP gateway extracts the contents of data packet field 1 and its associated header field Hdr 1 1178D from plain text data packet 438B. From this data packet, the 1191D IP packet recognition process combines the A data fields and the destination address from the Hdr 1 field header 1178D for two reasons - first, in three-way communication to confirm the expected incoming packet, and, secondly, to create a new one. SDNP addresses. This new SDNP address is combined with the D Type, Urgency and Delivery fields and processed by the SDNP 1191Z packet preparation operation to create the SDNP 434Z header in the outbound packet. The content of data field 1 is also extracted from the inbound plain text data packet 438B, and its contents are optionally mixed 1184Z with other outbound content to create an outbound SDNP 435Z payload. The packet is then processed by the SDNP 1190Z cloud security system in preparation for shipment. Thus, the address field serves several functions, both for identifying an incoming data packet and for providing a forwarding address when needed.

If the media node receives a data packet without prior instructions from the signaling server, then the media node will revert to the default instructions on how to handle the incoming data packet and how to prepare outgoing data packets. If the media node does not contain instructions for processing undeclared incoming packets, then the data packet will be discarded. If the media node is included with instructions on how to handle unrecognized packets, then the media node will first confirm, under the security credentials, that the packet is a valid SDNP packet and process it accordingly. However, if the sender cannot be identified, for example if the encryption code, initial values, or source address are invalid, then the packet will be discarded as malicious.

Returning to FIG. 9F , a packet field labeled "Field Zone" describes the zone in which the specific field was created, i. E. whether past encryption or scrambling has been done, for example with zone settings U1 or U2. In the case of nested security protocols or other methods of hiding nested data, additional information is required to decrypt, decrypt, or cancel hiding the data packet, for example, key, initial values, time or state, in which case the packet field marked "Other Field" can be used to convey information about a specific field. Typically these fields are not used, except for nested security protocols, such as when an encrypted data field is then encrypted or encrypted a second time. Care must be taken when using nested security techniques to recover data in the exact reverse order of data packet preparation, or the content will be lost forever.

A packet field labeled "Data Type", if used, facilitates context-specific routing, distinguishes between data, video, text and computer files that do not require real-time communication with data packets containing sensitive information such as voice and video. real time, i.e. distinguishes between real-time routing and non-real-time data. Data types include voice, text, live video, data, software, etc.

Packet fields marked Urgent and Delivery are used together to determine the optimal routing of data in a specific data field. Urgency includes Slow, Normal, Priority, and Urgent categories. Delivery includes various QoS markers for normal, redundant, special and VIP categories. In one embodiment of this invention, the binary size of the various data fields, as shown in table 1177, is selected to minimize the required bandwidth. For example, the data fields as shown can range from 0 to 200V, with eight 200V data fields per data field means that an SDNP packet can contain 1600V of data.

And FIG. 9G , and FIG. 9H illustrates the case where the client device sends data packets in the U1 zone through the Last Mile to the gateway node. The gateway node then processes the incoming data packets to override the last Mile protection and hiding methods it uses using the security credentials of the U1 zone. The gateway node can then blend the contents of the packet with the contents of other packets during the 1184Z blending process to create a new packet (or packets) linked for transmission over the SDNP cloud using Zone Z1 security credentials.

A similar process is used when the SDNP gateway receives a data packet from the cloud (including another gateway) and sends the data packet to the client device, for example, from the SDNP cloud to the client's (called) phone. As shown in FIG. 9I , in dual or triple link communications, signaling server 2603 previously informed the SDNP gateway of the planned arrival of a data packet and its associated identification markings and security credentials coming from the cloud. Thus, when the SDNP gateway receives data packet 2438A from the SDNP cloud, the gateway performs a security operation on the 2190D SDNP cloud to convert the SDNP payload from cipher text to plain text data packet 2438B. The unencrypted seed and key data in data packet 2438A can be ignored or optionally used in conjunction with signaling server information to decrypt the ciphertext. The use of data fields depends on the algorithms used to hide the packet payload. For example, if no encryption is used, then fields containing encryption keys are ignored.

As a result of the operation, a number of data fields are retrieved. A subsequent operation splits these data fields in a content splitting operation 2184Z to extract the specific content consisting of a data field 1 and an associated header of a data field 2117D with the designation Hdr 1 using a recognition operation 2191D. The Hdr 1 header contains the destination address of the data field, data type, urgency, and delivery information. The retrieved data field is then rewound to a new IP or SDNP datagram by preparing SDNP packet 1191Z for delivery to the next destination. The new data packet going to the cloud includes the SDNP 2434Z header containing the destination of the new packet (the IP address corresponding to the person's phone number) and the data content, the SDNP 2435Z payload. The outgoing packet is then processed by SDNP Last Mile Security Operation 2190Z according to the Last Mile U1 security credentials, not the Z1 security credentials used in the cloud.

If the signaling server is not available, i.e. in single-channel communication, the media node must process the incoming data packet using the instructions previously delivered as the default instructions. In such cases, the incoming data packet is checked against the criteria necessary to confirm that the sender is a valid SDNP client (such as an SDNP routing code or an authentication code previously delivered as a predefined shared secret). If the package is determined to be valid, the package is processed according to the default instructions. If not, then the packet is dropped.

The above methods are exemplary behavior and are not intended to limit the processing and routing of data packets to a specific data packet format.

Communication security and confidentiality

An important consideration for Last Mile is the ability of the network to maintain both secure and private communication. While privacy and security are often associated, they are not the same thing. Security, as a term used in the field of communications, is viewed as "the discipline to prevent unauthorized access to communication data in a recognizable form." Security, however, does not apply when an individual or institution has the right to access or control the message. Confidentiality is defined as "the state or state of freedom from surveillance or infringement by others and freedom from public scrutiny." From a legal point of view, confidentiality is defined as a person's right to control access to their personal information.

When communicating, the human right to privacy regarding voice calls, videos, text messages, email, private messages, etc. vary greatly from country to country. The role of complying with relevant government regulations to ensure legally enforceable access to communications is discussed in a later section. In addition, an ideal network and communication system should be able to prevent communication hacking, i.e. it must be absolutely safe, and all communications must be protected only for those who have the right to know, i.e. must be confidential.

When assessing the privacy and security capabilities of your network, you must carefully consider the Last Mile settings of your network and the devices connected to it. Depending on the security credentials used to establish access rights to information, the Last Mile and the devices attached to it often determine the security and privacy of a network. The Last Mile is the weakest link. There are four possible combinations of communication networks to consider:

Safe and private networks. From an individual perspective, this case represents ideal network performance that provides both information security and privacy for the user. At its extreme, a truly secure private network means that any person, government, agency, or corporation can neither intercept critical communications, nor obtain personal data about behavior, actions, contacts and partners, personal preferences and activities of a person, etc. etc. While privacy advocates regard the idealized secured private network as the gold standard for confidential communications, governments, security organizations, and corporations view absolute communication autonomy as a challenge that allows people to engage in crime and terrorism with absolute secrecy and impunity.

Unsecured networks with no privacy. A network that is not secure and does not have privacy provisions (like OTT ISPs today) poses a serious risk to any person, group, club, company or government using the communication channel. Since a cybercriminal can easily gain access to calls and data, any criminal group can use this information for any purpose of their choice. For attackers and spammers, unsafe communication channels can act as a wake-up call, flood networks with spam, initiate denial-of-service attacks, and create destructive harm. For ideologues, political activists, and religious denominations, insecure communication can be used to leak sensitive information to accelerate political change, discredit government officials, stimulate unrest, or even overthrow governments (see the historical feature film The Fifth Estate (DreamWorks © 2013) for an example chronicles leaked from WikiLeaks of hundreds of thousands of important government documents, causing a storm of international outrage). For financially motivated cybercriminals, such as those associated with organized crime and the mafia, attacks focus on monetary crimes such as theft, fraudulent transfer of funds, fraud, identity theft, money laundering, extortion, blackmail, and other crimes. For those involved in fear and intimidation such as drug cartels, gangs and terrorists, unsafe communications can be monitored to track the location, movement and activities of their competitors, enemies and victims in order to plan and execute violent crimes such as attacks, kidnappings, murders , explosions or acts of terrorism. Finally, in the case of personal cyberattacks, unsecured communications can be used to illegally hack databases containing personal information of individuals, including social security numbers, passports, banking information, credit card information, medical cards, and other sensitive personal information.

Secure networks that lack privacy. Examples of secure networks that lack confidentiality typically include corporate accounts where the IT (Information Technology) manager or security department has the authority and authority to monitor all corporate communications to ensure that no inappropriate or illegal communication occurs on the company's network. Despite the fact that the network is protected from hackers and cybercriminals, communication messages in such a network are not private and can be monitored by authorized agents to detect violations, including unauthorized personal use of the company's communication infrastructure, corporate espionage, violation of confidentiality agreements, unauthorized disclosure of intellectual priorities ( IP leak), sexual harassment, violations of the rules of fair disclosure (FD), insider trading, bribery, violation of the FCPA (Foreign Corrupt Practices). In corporate communications, when joining a company, an individual is informed that their corporate relationships are not private and may be monitored, including phone calls, email, text messages, private messages and SMS, and other communiqués. In legal proceedings, whether civil or criminal, these communiqués can also be summoned to court and presented as evidence, even if personal information is mixed with corporate information. In fact, if a company employee uses company communications, devices and networks for personal use, then (except in cases of attorney-client privilege) all information is legal and should not be considered private. For this and other reasons, the mixed use of personal messengers such as Line and KakaoTalk for business and personal purposes is particularly problematic, as an employee cannot invoke privacy rights to prevent viewing of their text chats, images and files.

Quasi-private, unsecured networks. A quasi-private insecure network is a network in which data can be compromised, for example, by eavesdropping on conversations, but private transactions can be carried out confidentially despite lack of security if certain conditions are met. Thus, confidentiality is established by verifying the identity of the caller (or callers) in various ways using shared secrets that are not detectable even by a hacker who intercepts the call. A common example of insecure private communication is voice banking. The caller confirms his identity by answering a series of ever-changing questions to which the impostor is unlikely to know the answers, such as "we see you having dinner last night and paying with your credit card." Could you tell me which city you dined in? "Or," You get regular bills from the winery. What is this winery? "Another example of a question:" Can you tell me the name of your favorite elementary school teacher? "For these identity verification methods to work, the bank must either have access to sensitive information (such as credit card statements) , or the bank and its clients must establish a set of shared secrets when opening an account, usually in person, rather than electronically. After identifying the caller, the client can instruct the institution to take certain actions that will not benefit the cybercriminal. For example, "please, transfer $ 10,000 from my savings to my checking account. "However, if the funds are transferred to another bank, an even stricter check is necessary to ensure the client's confidentiality. In any case, the privacy is subject to the condition that the message cannot disclose shared secrets either electronically or verbally, otherwise the entire confidentiality will be lost and accounts may be at risk. As such an authenticated message on an unsecured line, a quasi-private message is called, meaning conditional confidentiality. Another example, or quasi-private communication over an insecure network, can be done using a security token - a device issued by a bank and owned only by the customer. The pseudo-random number generated by the device is reported to the bank operator, who confirms that the number matches the authorized bank numbers. Since the number is 8 or more digits, there is little chance of guessing the correct code the first time. If a message is received about an incorrect token number, the call is interrupted, the account is blocked, and the anti-fraud department is notified of the need for an investigation. In any case, the importance of maintaining confidentiality on an unsecured network depends on the ability to communicate without disclosing any sensitive data such as account numbers, PINs, credit card details, etc. communication is almost private.

Identity Verification and AAA Protocol (Authentication, Authorization, Administration) - The concept of security and confidentiality is based on accurate and reliable verification of identity, i.e. on the fact that the caller is who he claims to be. Authentication, also known as "authentication", is essential to ensure the correct use of data and communications, and to prevent illegal or unauthorized access. Strong identity verification is essential for national security, law enforcement, IP ownership, businesses, and individual rights. An example of the importance of identity verification includes the following:

For a country's national security, caller ID verification is important to track the identity of criminals, spies, terrorists, drug dealers and anyone who divulges national secrets or threatens national security. It is equally important to be able to identify those who have the right to access, read or send confidential, secret or top secret communiqués, data and files.

For law enforcement agencies, caller ID verification is important to identify individuals or organizations involved in criminal activities such as robbery, arson, drug trafficking, smuggling, prostitution and human trafficking, extortion, blackmail and other crimes. It is equally important to be able to identify individuals who are authorized law enforcement officials, including the police, firefighters, paramedics, rangers, air marshals, transport and airport security administrations, port authorities, customs, and the coast guard.

For IP owners such as film studios, personal identification is important to identify individuals, organizations and organizations involved in piracy and unauthorized distribution of copyrighted material such as music, films, books, videos, etc. It is also important to confirm the legal and valid distribution of IP materials and copyrighted materials.

For businesses, verifying the identity of their employees is important to track down the deliberate or accidental disclosure of material inside information, identify those who engage in commercial espionage, identify individuals involved in the illegal disclosure of intellectual property, and those who commit other crimes, such as fraud or the use of corporate communications in personal purposes. It is equally important to verify the identity of those who have access to the company's confidential information, and specifically allow access to which types of data they have. For example, the engineering department of a company should not have access to the HR records of the marketing department to compare how much marketing employees are paid.

For individuals, identity verification is important to ensure the "confidentiality" of the caller by confirming that the person or persons you are communicating with are not impostors.

Thus, the role of identity verification is to confirm a person's identity, i.e. in certifying who he claims to be, as well as in identifying, blocking and, ultimately, arresting persons who mislead about his identity. Authentication is the first letter "A" in the Triple-A security model, or AAA, for Authentication, Authorization, and Administration. Numerous methods can be used to verify a person's identity and authenticate their account in the system, such as PIN, passwords, fingerprints, tokens, and methods of answering requests.

Once authenticated, the user's real identity is then used to determine the rights and privileges of access to communiqués, data, files, system operation, etc. These privileges and access rights are collectively referred to as the "authorization" of the user provided by the system, i. E. an authorized user can only access the communications, data, files and system functions for which he is authorized. Therefore, authorization is synonymous with "privilege" or "access".

The third letter "A" in AAA means "administration". Administration is the maintenance of accounting records of authorized network and file access, for example, for billing purposes, and to track and report unauthorized network, file, and system access attempts. Administration also plays an important role in keeping track of changes to security credentials, PINs, passwords, etc., required for an authentication operation.

The ability of a network to perform AAA protocol operations is of paramount importance to ensure the confidentiality and prevent corruption of the network by unauthorized users or network operators. Any network that fails to insure the identity of its users can be damaged for illegal purposes. Damage to the network by unauthorized users inevitably creates problems when communicating using OTT, since there is no means to verify the identity of the caller. Unauthorized access and network communication by unidentified users, i.e. anonymity pose a significant risk in modern communications.

Anonymity - The principle of anonymity in communication is the practice of deliberately hiding the identity of the caller in order to communicate without being tracked. An almost symbolic example of anonymous communication is the payphone. In case of a payphone call, payment is made in cash, the payphone number is publicly available, and anyone can use the phone, i.e. the identity of the caller is unknown, and there is no means of determining whether the caller is who he claims to be. Since the phone number is not listed, no one owns the number and (except for sophisticated voice recognition software) cannot identify the identity of the caller. In the case of a registered device such as a mobile phone, the identity of the owner of the device can be traced back to the phone number, but the identity of the caller may remain unknown. For example, a phone can be stolen, or a pay-as-you-go SIM can be used to hide the true identity of the caller. In addition, a laptop, tablet or mobile phone can be connected via Wi-Fi in a public cafe, providing anonymity similar to that of any payphone or telephone booth.

Some OTT operators have chosen to use VoIP telephony as a payphone without verifying the identity of their subscribers. For example, a recent online report from CNN Money (http://money.cnn.com/2015/11/17/technology/isis-telegram/) states: “An app called Telegram is“ hot news among jihadists. ”Research confirm that the use of Telegram played an important role in the secret planning of the ISIS terrorist attack on Paris. In the article "The founder of Telegram knew that ISIS was using an app to plan an attack on Paris" (http://www.independent.co.uk/life-style /gadgets-and-tech/news/telegram-knew-isis-communicate-paris-pavel-durov-a6742126.html), Telegram founder Pavel Durov said: “The right to privacy is more important than fear of such terrible events as terrorism ".

Another example of the use of privacy and anonymity for reported crimes is BitTorrent, an application and data network that is often used to illegally download or share copyrighted material. CNN Money Tech's news article (http://money.cnn.com/2011/06/10/technology/bittorrent_lawsuits/) titled "50,000 BitTorrent Users Sued in Illegal Downloads" liability under new anti-piracy laws for illegal downloading of The Hurt Locker movie and other copyrighted material. Network operator BitTorrent has taken the payphone position that it is not responsible for what people do using their network for their private activities. Free speech advocates support this position, while law enforcement, government, national security, and IPR officials despise this attitude as reckless and irresponsible. Regardless of the policy on this issue, until communication systems can verify the identity of the caller, the discussion of ending anonymous calls is purely academic.

Caller authentication is especially important for corporations and businesses to control access to confidential company data, including intellectual property, engineering design, product valuation, manufacturing know-how, confidential financial reports and forecasts, business status, sales forecasts, inventory and WIP, audit quality, commercial and IP contracts, customer lists, employee accounts and other trade secrets. When accessing corporate communications, the access privileges given to any employee, contractor, or manager are dependent on proof of their identity. In conference calls, including investor calls, identity verification is important to confirm who is on the call and to ensure that no one is listening without the investor's knowledge.

Paradoxically, while caller ID verification can be used to prevent plans for criminals and corporate espionage, the same ID verification is useful for maintaining the privacy of the caller. If both parties to a call or text chat prove their identity using a specific authentication procedure, the impostors do not have access to the call or its data, protecting the call from criminal attacks.

Finally, a distinction must be made between anonymous callers and anonymous calls. An anonymous caller is a person who hides his true identity from the network on which he communicates. Anonymous call, however, does not require the anonymity of the caller on the network, only that his real identity during communication is hushed up in the data packets of the call. A registered SDNP account holder can make a call or send data using anonymous data transfer, even if the network knows his identity and phone number. Thus, law-abiding citizens can communicate anonymously, without having to hide their identity from the SDNP network operator. If the caller makes regular private calls, entertainment or business activities, his SDNP call remains confidential and secure, even if the network knows that his name is stored in the SDNP name server database.

Examples of the need for legal, anonymous communication include global games where it is important to protect the identity of the gamer, especially children. Another advantage of anonymity is associated with communication between vehicles (vehicle-to-vehicle, V2V) to prevent criminal actions by drivers, by identifying the personal data of drivers that impede driving. In contrast, if the caller commits criminal or other fraudulent communication, law enforcement officers may (in accordance with the law) gain access to their calls and data transfers. Thus, the network operator can satisfy the requirements of court orders and subpoenas without revealing the identity or disclosing the calls of law-abiding citizens.

Thus, using the previously discussed communication methods in the SDNP network, only identifiable SDNP subscribers can make anonymous calls. Unidentified callers do not have access to the SDNP network or the ability to make anonymous calls.

National security and privacy - The nature of secure and private communications is further complicated when the roles and laws of government are taken into account. Each country defends its sovereign right to control the implementation of communications within its borders. However, with the advent of the Internet and dynamic routing of packet-switched data networks, there are many technical and legal challenges associated with network surveillance and monitoring. One of the problems is monitoring the end-to-end traffic of the server-to-server network - data packets passing through the country without stopping. Since Internet traffic is dynamically routed, the operator has no idea what data packets are being carried by his network of servers. Any country can, of course, try to intercept and decrypt these large amounts of data, but because of encryption, access without knowing the encryption keys is challenging, especially for real-time monitoring. And since callers may not reside in a country, a particular country does not have jurisdiction to subpoena or request the encryption keys used to make a call. This end-to-end data network is analogous to radio wave traffic passing through the earth's atmosphere. Despite the fact that radio waves can travel overhead, it is almost impossible to stop them. Likewise, other than completely isolating a country's infrastructure from the Internet, there is no real way to stop network traffic over data transmission.

A more pragmatic solution for managing communications is to focus monitoring on the "Last Mile" links, ie. interception and monitoring of calls and data about them in those places where the source and / or destination of the call are located in the country. This approach has a number of advantages over capturing large volumes of traffic through data, including (i) less data, which is more manageable for analysis, (ii) the last mile operator or network operator is subject to the laws of the country in which it is located (iii ) the operator of the last mile or network operator may be summoned to court to hand over any available encryption keys, (iv) the caller's device must electronically “register” to connect to the last mile network and still transmit the caller's information, and (v) The GPS network address can be determined by triangulating the signal.

In contrast to the legal and technical issues involved in enforcing network traffic regulations, the laws governing last mile traffic and call termination are wholly owned by the country where the last mile network operator lives. Depending on national privacy laws, a country's government may insist on the required level of access to Last Mile communications, including the following combinations:

No right to control any data or calls without a subpoena for good reason. By court order, the right to secretly monitor any call or data exchange.

The right to monitor the metadata of any call without judgment.

The right to control all calls and data transfers without a court order.

The right to intercept, monitor and, if necessary, block any messages.

For example, various governments, such as the United States, have taken the position that they reserve the right to monitor the "metadata" of calls without a court order. Metadata includes information about the data packet about who is calling whom, how long the call lasted, where the subscribers were at the time of the call, etc., without actually having access to the call data itself. Basically, the metadata includes the header of the IP packet, but not its payload. In contrast, call and data monitoring involves access not only to header data, but also to the payload. In such cases, where the payload can be encrypted, the government may insist that the network operator provide it with the master encryption keys, if any. One of the issues raised by privacy advocates concerns the abuse of power by the government. Specifically, if the network relies on one set of master encryption keys, then giving up those keys in response to a court order allowing surveillance of a specific person effectively allows the government to control everyone's calls, even if the court order was for only one person or group of people. ... This problem is sometimes referred to as an embarrassment: "Who is the police for the police?"

Another consideration concerns the privacy rights of international calls. In such cases, callers should be aware that the relevant public access laws depend on the location of both callers, i.e. from where the last two miles of the nets are. A call from the United States to China will be governed by US law for a caller in the United States and Chinese law for another caller in China. In such situations, one government may have more telephone access than another. Thus, a caller in a country with broader privacy rights may consider their privacy violated by the government of another country, but since they called that country, they have no legal basis to complain.

In the case of communication using the previously considered secure dynamic network and protocol, interception of end-to-end data in a hyper-secure cloud communication of fragmented encrypted data packets transmitted anonymously over the SDNP network is practically impossible. Thus, the privacy and security of hypersecure calls are determined by the device itself and the Last Mile link. By adapting the previously discussed SDNP techniques for the Last Mile link, the hyper-secure interoperability and high confidentiality function disclosed in this document can be realized.

It also discusses mechanisms for adjusting the security and privacy settings of the SDNP network in accordance with local laws governing Last Mile data transfers in each country. These methods include safeguards to allow an authorized security agency to monitor communications in accordance with law and court decisions, without exposing the call data to danger for hackers and cybercriminals. Thus, the hypersecure Last Mile link discussed here does not use a cyberattack-vulnerable backdoor.

Methods and Device for Last Mile Hypersecure Communication

To ensure end-to-end hypersecurity, the application of the techniques previously described for routing encrypted anonymous fragmented data packets in the SDNP cloud must also be adapted for Last Mile communications. The security of Last Mile communications is particularly problematic, since data can be transmitted on networks not supported by the SDNP operator, packet routing can include regular IP packet routing, and the internal security of the Last Mile network can be unknowingly compromised by a cybercriminal, possibly with involvement in the operator. network "Last Mile".

In accordance with this invention, Last Mile data transmission necessarily implies the transfer of IP datagrams outside the cloud network using a packet format other than the data packet format within the SDNP cloud. As shown in FIG. 10 , SDNP cloud, consisting of 1201 servers (schematically represented by SDNP nodes with support for softswitches M _0,0 - M _{0, f} ) transports VoIP, video, text and data using SDNP datagrams presented in sample data packets 1222B, 1222C and 1222F. The SDNP datagram contains SDNP Layer 3 source and destination addresses, not Internet IP addresses. SDNP addresses differ from IP addresses in that they are only recognized by SDNP name servers or other servers acting as SDNP name servers, not Internet DNS name servers.

As described above in patent 14/803 869, SDNP packets change dynamically as they travel through the network, with updated routing addresses and constantly changing payloads executed according to shared secrets and dynamic states (such as time). For example, data packet 1222B sent by node M _0,0 includes an SDNP Layer 3 datagram with unique SDNP addresses and a uniquely encrypted payload. The output data packet 1222C from node M _0,1 consists of an SDNP C layer 3 datagram with various SDNP addresses and an encrypted payload. A few tens of milliseconds later, the same payload reaches node M _{0, f} , which processes the data and forwards data packet 1223G, including the IP datagram G, over the Last Mile.

Since the changes are performed according to the specified states, the original packet data can be restored by performing a series of anti-function operations performed in the reverse order from the order in which they were performed. For example, an SDNP functional sequence consisting of scrambling, garbage insertion (hiding) and encryption steps can be reversed by decrypting the reverse sequence, deleting and unlocking if the same state is invoked to execute the corresponding anti-function and used to execute the given functions. The packet state data can be transmitted as time, seed, or key, either embedded in the packet payload or sent in advance. The transport and processing of data within the SDNP cloud is done using special shared secrets and SDNP security credentials. Media sites that share a common set of shared secrets and security credentials can be called a "security zone." The zone used to access credentials running in the SDNP cloud cannot be accessed by any user outside of the SDNP cloud. Thus, all last mile connections must be a different security zone from the SDNP SDNP cloud zone.

In the example shown, server 1201A and server 1201F, where the corresponding nodes M0,0 and M0, f are located, act as SDNP gateways, i.e. interact with devices outside the SDNP cloud, as well as with other intra-cloud SDNP nodes. Communication between these gateways and communication devices outside the cloud represents the "last mile" of communication. Accordingly, gateway nodes must understand the security credentials of zones in both the SDNP cloud and the last mile network they connect to, acting as a translator during packet routing. Semantically, the term "last mile" is an abstraction meaning communication outside the SDNP cloud and not specifically referring to a mile distance. Instead, the term "last mile" encompasses any communication between the client device and the SDNP cloud at any distance, regardless of whether the client device is acting as an SDNP client, i.e. whether SDNP application or firmware is running or not.

The term "last mile" also applies to both the originating client device and the called client device. Literally speaking, caller data represents the "first mile" of the call, not the last - the distinction between first and last miles is arbitrary. In particular, in any duplex conversion or in any IP "session" communication, the device receiving the call will necessarily answer the call or session request by sending a response to the caller. Thus, in any two-way communication, the first mile always acts as the last mile in the response data path. In fact, the caller's first mile is also the last mile to answer. Thus, the specific term "last mile" is used throughout this application to refer to both the first and last mile, regardless of which device initiated the communication or call.

Communication outside of the SDNP cloud with any device other than the SDNP client is necessarily done using IP datagrams, not SDNP datagrams. For example, as in FIG. 10, data packet 1223A includes "IP Datagram A" constructed using an SDNP payload with an IP address rather than an SDNP address. Likewise, IP datagram G includes data packet 1223G containing an SDNP payload routed using an IP address. Source and destination IP addresses are any IPv4 or IPv6 addresses recognized by the routing network. IP addresses can include Internet addresses recognized by Internet DNS servers, or they can include NAT addresses used for routing over local area networks specified by the local network service provider.

Because the hardware and firmware used in Last Mile communications can vary significantly and may include telephone lines, fiber optic lines, cable TV networks, 3G and 4G radios, microwave towers and satellites, Last Mile communications analysis should be considered for various physical layer 1 networks and their respective layer 2 data link formats used. For example, formats may include analog (POTS), Ethernet, Wi-Fi, 3G, 4G / LTE, and DOCSIS3. The respective security and privacy features of each Last Mile implementation are discussed on a case-by-case basis in the next section on SDNP " call out " communications.

SDNP Call Out over Unsecured Lines - Any call that leaves a specific network for transport over a separate (and usually different) network, usually called "call out", the term means that data or voice leaves one network to transport over another. For example, communication between clients using Skype applications is usually called a Skype call, and a call from a Skype client to a regular number or cell phone number is called a Skype call out or Skype Out call. As a rule, calls to regular phones require a certain additional fee, both in the form of a subscription and in the form of a usage fee.

In the context of this section, the exchange of data from the SDNP Cloud over an insecure Last Mile connection with any device other than an SDNP client is hereinafter referred to as "SDNP Call Out". FIG. 11 schematically shows two examples of SDNP egress routing to an unprotected Last Mile. In the example above, communication is done using analog signals with an analog device such as a telephone or a 6A payphone. In such cases, the SDNP gateway must be equipped with a D / A converter. Otherwise, modems or converters may be added to the gateway. The information is transmitted over an analog signal 1221 rather than a data packet. Analog telephone signals, while effective for transmitting voice, are not well equipped for high-speed data transmission.

In the example below, SDNP Call Out occurs over the digital network to any digital device (eg cell phone 32) that is not activated as an SDNP client or does not have SDNP firmware. In such cases, data packet 1223 transmits the call or data using the conventional Internet protocol, i. E. an IP packet format that conforms to the 7-layer OSI model. An IP datagram includes IP or NAT addresses in the source and destination address fields, and IP or VoIP data as payload. The digital path can include various forms of digital data, such as Ethernet, Wi-Fi, or 4G / LTE, which differ depending on the type of Last Mile connection.

In the above diagrams, Last Mile communication data is transferred outside the SDNP network via an unsecured communication channel or network, and since the call is not secure, it is subject to hacking, espionage, eavesdropping and other cyber attacks. As described in the reference section of this application, insecure Last Mile links and connections, whether twisted-pair copper, coaxial, fiber, Ethernet, Wi-Fi, cellular or satellite communications, are inherently unprotected if en route end-to-end data transfer has not added special protection methods such as encryption. Therefore, the security of even the most secure data cloud or VPN is compromised by its weakest link - in this example, the Last Mile channel. Even encryption does not guarantee security, especially on one well-defined electrical, microwave, or radio wave connection. Apart from insecurity, the examples do not include any authentication mechanisms. Without the ability to authenticate, the Last Mile channel has no guarantee of confidentiality. Therefore, the schemes are insecure Last Mile networks that lack the confidentiality of caller information.

FIG. 12 illustrates an SDNP 1201A gateway making an SDNP call-out to an unsecured Last Mile without confidentiality, connecting to the PSTN or PSTN gateway 1A over a wired or optical circuit 24 of the NSP, and the PSTN gateway 1A then it is directed to the old telephone exchange 3 via an analogue communication channel. POTS switch 3 makes normal twisted-pair copper 7 telephone calls to home telephone 6, cordless telephone system 5, or payphone 6A. The entire last mile is neither private nor secure. Although SDNP addressing and SDNP payload are used in the transmission of data packet 1222A containing the SDNP-A datagram, the benefits of hypersecurity are lost after the last mile of data is entered. For example, data packet 1223B containing IP datagram B, carried over NSP wired or fiber optic line 24, uses a normal IP address recognized by Internet DNS servers and contains a normal IP address that can be detected by any cybercriminal. Analog lines 4 and 7 are equally vulnerable because they carry simple analog audio signals as analog call data 1221. Although the SDNP gateway can support unsecured insecure calls, it is not advisable to connect secure SDNP calls to insecure Last Mile networks without privacy.

A small improvement in the aforementioned insecure Last Mile implementation can be achieved with authentication. FIG. 13 schematically illustrates examples of routing SDNP calls to an unsecured last mile, but with two different types of authentication. The upper example shows SDNP output from an SDNP 1220A gateway over an analog or POTS line to an office landline telephone 9. As shown in the figure, the operator 1225 performs manual authentication to verify the identity and identity of the account holder. Despite being authenticated, analogue beep 1221 is insecure and remains confidential only if secrets or account information are not disclosed in the conversation, i.e. if secrets are not disclosed, then the information is confidential, and if information is disclosed, then the message ceases to be confidential. Thus, the term semi-privacy is used herein to refer to authenticated messages over unsecured lines, i.e. conditionally private messages.

The bottom diagram shows an SDNP call from an SDNP 1220A gateway to an unsecured digital Last Mile. Data carried by IP datagram 1223 to an electronic device such as desktop PC 36, although unsecured, can be verified using an electronic identity verification method, such as token 1226, to which an attacker has no access. Since communications are insecure and can be eavesdropped, care should be taken in digital conversations not to divulge account numbers or sensitive data.

Specific examples of semi-private unsecured calls are provided in the next few examples. FIG. 14 depicts an insecure Last Mile Identity connection between the SDNP network and an office desk phone 9, such as a private banker's phone. The account owner's call, if made internationally, for example, will be routed globally using a hyper-secure link on the SDNP network and finally connected to Last Mile as an SDNP call via SDNP gateway 1201A. The long distance portion of the call is performed using dynamically changing SDNP datagrams, such as data packet 1222A containing an SDNP datagram A with an SDNP payload. Data packet 1222A is converted by SDNP gateway 1201A from SDNP datagram A to IP datagram B, shown by data packet 1223B. Unlike SDNP datagram A, IP datagram B contains a tracked IP payload. Data packet 1223B is transmitted by a cellular service provider (NSP) over wired or fiber optic 24 to the public switched telephone network or PSTN gateway 1A. This gateway, in turn, connects to Company 8A's switchboard over POTS line 4 with analog call 1221. Company switch 8A connects to desk phone 9 over analog PBX or phone line 7A to desk phone 9 as well as to 1225 Personal Authentication Operator. During the call, the account owner contacts the private banker on desk phone 9, but before proceeding with any transactions, the 1225 Personal Authentication Operator joins the call to verify the caller's identity and then leaves the call to maintain the caller's privacy. However, since the call is insecure, both the private banker and the account holder must be careful not to divulge sensitive information such as account numbers, passwords or PINs. As such, the call is semi-private, i.e. conditionally private.

FIG. 15 shows the unsecured communication between the SDNP network and the desktop computer 36, identifying the identity. In a digital session, desktop computer 36 communicates with an SDNP 1201A gateway using IP datagram B carried over from multiple digital media. On the first Ethernet segment, 106A transmits data packet 1223D, consisting of IP datagram B, from the desktop computer 36 to the local Ethernet router 27B. The local Ethernet router, in turn, connects to the network router 27 through an Internet Service Provider (ISP), wired or fiber optic link 24A using data packet 1223C containing IP datagram B. Wired or fiber optic link 24 of the NSP network operator transmits data packet 1223B containing IP datagram B in the last round of routing 27 and SDNP between gateway 1201A. Because IP datagrams are used, Last Mile is insecure. Digital authentication methods such as login window 1227 and security token 1228 can be used for authentication to ensure that communication remains semi-private. These authentication methods should be limited to single use to prevent unauthorized persons from using them. For example, once a token generates a number and is used to gain access, the combination is no longer usable, so if a hacker intercepts the token, it becomes useless as it has expired and is no longer valid.

Other examples of insecure Last Mile Identity communication are described in FIG. 16 , where the SDNP 1201A gateway communicates as an SDNP call out with a point of sale (POS) terminal 38 and a gas pump POS terminal 38A. The Last Mile connection, as shown in the figure, is a fusion of digital and analog connections, including an NSP wired or fiber link 24 containing data packet 1223B, plugging IP datagram B into router 27, then wired or fiber link 24A with IP datagram B in data packet 1223C to PSTN bridge 3A, and POTS or analog lines 30B with digital PCM (Pulse Code Modulated) data 1221 connected to the analog network. Authentication in financial transactions is based on bank card data 1229, which may include electronic validation based on a smart card IC and a dynamic PIN 1228. Authentication includes confirmation at a financial institution 1230 connected to the SDNP network or through an SDNP 1201A gateway, or through another Last Mile link.

Hypersecure Last Mile Link - By adapting secure dynamic network communication methods and protocol, hypersecure communication can be achieved on the Last Mile. For hypersecurity, the connected device must execute SDNP code as an "SDNP client". The SDNP client contains operating instructions, shared secrets, and SDNP connectivity information hosted on a connected communication device. An SDNP client can include software that runs on an operating system, firmware that runs on a microcontroller or programmable chip, or custom hardware or an integrated circuit.FIG. 17 is an example of hypersecure communication on the Last Mile using an SDNP connection. As shown in the figure, the SDNP gateway 1201A connects to a device under the control of an SDNP client, in this example SDNP application 1335 running on a desktop computer 36. The SDNP client is hardware and operating system specific. Mobile devices require separate applications for different mobile device platforms with Android, iOS and Windows Mobile operating systems. Likewise, laptops, desktops and servers, including Windows 10, macOS, Unix, Linux, etc., require various OS specific applications. Hardware hosting of SDNP clients in devices without higher-level operating systems such as POS terminals, hotspots, IoT, etc., must be tailored to the programmable device executing the code. Programmable integrated circuits often require programming in a chip-specific development environment specific to chip manufacturers such as Qualcomm, Broadcom, Intel, AMD, NVidia, Microchip, etc.

Since the SDNP 1201A gateway and the SDNP 1335 application interact with the SDNP 1222 payload, the caller identity and call payload are not amenable to packet sniffing, especially the SDNP 1222 payload containing a pseudo source address and SDNP destination not recognized by DNS servers, but the payload includes encrypted SDNP data that can be combined, fragmented and mixed with data. SDNP payload 1222 is embedded in IP datagram 1223, which routes Last Mile routing using the IP addresses or NAT addresses of the cellular, cable, or ISP network used for the last mile connection, rather than the SDNP address.

Another aspect of SDNP-based hypersecure Last Mile communication is that any SDNP client is natively capable of authentication and authentication. The confidentiality functions are thus not based on the ability of the network to provide confidentiality to support AAA, whether client software or firmware is designed to facilitate the verification process or not. Since any hypersecure Last Mile relationship can be verified, it should be understood that the following examples of a hypersecure Last Mile relationship apply to both private and insecure communications. Thus, unlike insecure Last Mile networks with semi-private features, secure hypersecure Last Mile communication is defined by the SDNP client, not the network, and is capable of supporting any degree of single-factor or multi-factor authentication the client desires.

Specific examples of hypersecured calls are shown in the following examples. FIG. 18 shows the hypersecure Last Mile communication between the SDNP network and various cellular mobile devices with the latest Wi-Fi connection. As shown in the figure, data packet 1222A containing SDNP datagram A and SDNP payload is converted by SDNP gateway 1201A for Last Mile communication into data packet 1223B with IP datagram B also containing SDNP payload. Because the hypersecure Last Mile link uses different shared secrets, numeric parameters, encryption keys, and other zone-specific security credentials other than those used in the SDNP cloud, the SDNP workload in IP datagram B is different from the SDNP payload in SDNP Datagram A. In other words, SDNP Gateway 1201A converts SDNP datagrams to IP datagrams by switching workload from one security zone to another, and by inserting SDNP routing as the source and SDNP addresses not recognized by DNS servers.

This area-specific SDNP payload is then packed into an IP datagram packet with an IP header containing IP addresses specific to Last Mile of the Network, or NAT, or Internet addresses, to facilitate routing of packets between the SDNP 1201A gateway and communications devices, i.e. a tablet 33 and a cell phone 32 serving as SDNP clients. Since the intermediate Last Mile routing devices are not SDNP clients, the structure of the SDNP payload within IP datagram B remains unchanged as it travels through the Last Mile. In other words, data packets 1223B, 1223C, and 1223D are identical datagrams consisting of SDNP Datagram B with identical SDNP payloads — payloads that do not change as the packets travel from device to device in the Last Mile. Simply put, only an SDNP host or SDNP client can reverse engineer the SDNP payload embedded in a Layer 3 datagram, be it an IP datagram or an SDNP datagram.

As shown in the figure, data packet 1223B, consisting of IP datagram B, is transmitted over wired or fiber optic link 24 to router 27, and then data packet 1223C also includes IP datagram B, transmitted over wired or fiber optic link 24A on Wi- Fi router 26 operated by an internet service provider. Wi-Fi router 26 then communicates the last line using data packet 1223D containing an IP datagram B over Wi-Fi link 29 with mobile devices such as cell phone 32 and tablet 33 running the SDNP 1335A application. Thus, these devices function as an SDNP client capable of interpreting data contained in data packet 1223D containing IP datagram B, including decrypting, deactivating, extracting, and mixing payload content with chunks of data from other data packets to play the original message or sound. ...

FIG. 19 depicts hypersecure Last Mile communication between SDNP and various cellular mobile devices using Last Line cellular radios. As shown in the figure, data packet 1223B, consisting of IP datagram B, is transmitted over a wire or fiber link 24 controlled by an NSP to network router 27, followed by data packet 1223C, also including IP datagram B, transmitted by the mobile operator. communication (MNO), wired or fiber-optic channel 24B to base station 17 to create a cellular network 25. Base station 17 provides Last Line communication using data packet 1223D, including IP datagram B over 3G, 4G / LTE over cellular communication 28 with mobile devices such as cell phone 32 and tablet 33 with 1335A SDNP app installed.

As in the previous example, since the intermediate Last Mile routing devices are not SDNP clients, the structure of the SDNP payload within IP datagram B remains unchanged as it travels through the Last Mile. In other words, data packets 1223B, 1223C, and 1223D are identical datagrams consisting of SDNP Datagram B with identical SDNP payloads — payloads that do not change as packets travel from device to device during the Last Mile.

FIG. 20 shows the hypersecure Last Mile communication between the SDNP network and various non-mobile (connected) Last Line devices over Ethernet. As shown in the figure, data packet 1223B, consisting of IP datagram B, is transmitted over a wired or fiber optic link 24, managed by an NSP, to network router 27, followed by data packet 1223C, also including IP datagram B, transmitted by the service provider. Internet service provider of 24A wired or fiber optic connection to 103A Ethernet router. Ethernet router 103A provides last-line communications with data packet 1223D, which includes IP datagram B over Ethernet 106A with associated devices such as desktop 36 with SDNP application 1335C and desk phone 37 with SDNP 1335B firmware. In the absence of SDNP hosts or SDNP clients in Last Mile, data packets 1223B, 1223C, and 1223D are identically constructed datagrams, all of which contain SDNP datagram B with identical SDNP payloads - payloads that do not change as packets move from device to device. device when driving on the "Last Mile".

FIG. 21 shows the hypersecure Last Mile communication between the SDNP network and cable clients. As shown in the figure, data packet 1223A, consisting of IP datagram B, is transmitted over the NSP 24 wire or fiber link to the cable CMTS 101, the cable operator's control, communications and content distribution center. These cable operators provide a wide range of services such as cable TV, pay TV, telephone services, Internet services, business services, and more. The central CMTS 101 is then connected to clients over cable 106 using a fiber or coaxial module in accordance with DOCSIS3 and trellis modulation (described in the reference section of this document) to optimize bandwidth and real-time services. Open to customers, the cable operator can support the datagram format or package IP datagrams into a proprietary datagram format. These data packets, hereinafter referred to as the CMTS datagram C, use cable-specific NAT addressing and encapsulate the SDNP payload as an embedded payload in data packet 1224C for transmission over cable 106.

As shown in the figure, CMTS cable 101 routes CMTS datagram C to cable modem 103, which in turn retrieves payload data packet 1223B containing IP datagram B with unmodified SDNP payload for Last Line delivery. Devices supporting the last communication with an SDNP client can operate in several formats, including Ethernet 106A on computer 36 running a 1335C SDNP client application, or over twisted pair 7 to phone 5A with firmware 1335B for an SDNP client. CMTS cable 101 also routes CMTS datagram C to cable modem 103, which in turn extracts the original IP datagram, such as IP datagram B, and sends it and other video content to the cable box via cable 106. The cable box then forwards the IP datagram B and content via HDMI-2 107 to iTV in ultra high definition 39 by launching SDNP application 1335D. Alternatively, the SDNP firmware can be hosted on the cable box 102.

FIG. 22 shows a hypersecure Last Mile connection between an SDNP network and a home Wi-Fi network connected through a cable service provider. As shown in the figure, data packet 1223B, consisting of IP datagram B, is transmitted over wire or fiber NSP line 24A to CMTS 101, which is the cable operator's control, communications and content distribution center. The CMTS 101 head unit then connects using a 24A wired or fiber optic connection over coaxial or fiber optic cable to a specific 100B client modem router (Wi-Fi) to create a Wi-Fi 26 access point. The 1224C data packet routing may include an IP datagram with Internet addresses or contain a proprietary CMTS datagram C with a NAT address. The routing between the SDNP 1201A gateway and the cable (Wi-Fi) modem router 26 is a wired, hypersecure Last Mile segment.

The last stage in the home network involves the Wi-Fi connection 29 of the connecting cable (Wi-Fi) of the modem of the router 26 to various home devices over the data packet 1223D containing the IP datagram B wirelessly. For hypersecurity, such devices must act as an SDNP client, either through software or firmware loaded on the device. For example, laptop 35 and desktop 36 operate as SDNP clients using computer application 1335C, mobile phone 32 and tablet 33 operate as SDNP clients using mobile application 1335A. IoT devices, in this case the 34K refrigerator, can act as an SDNP client if their control system is loaded with SDNP 1335E firmware. However, if such devices do not integrate or cannot integrate the client's SDNP software, then security must be ensured in other ways.

Security " Last Line " with identification - In cases where a connected device cannot act as an SDNP client, hypersecurity cannot be guaranteed from start to finish. In this case, using a remote SDNP gateway can extend the hypersecure connection to cover the Last Mile of the connection, excluding the Last Line. If the Last Line parameter, the part of the Last Mile connecting directly to the communication device, is not enabled as an SDNP node, then the security of the Last Line must be insured via the local area network (LAN) used to provide Last Line communication. ...FIG. 23 schematically illustrates the use of a SDNP 1350 remote gateway in a Last Mile connection. SDNP 1350 Remote Gateway includes any communication device running SDNP 1335H firmware as a remote gateway. Thus, an SDNP connection between an SDNP 1201A gateway and a remote SDNP 1350 gateway includes an IP datagram 1223A including a source and destination IP or NAT address and an SDNP payload 1222. SDNP payload 1222 includes an SDNP address not recognized by DNS servers and an embedded SDNP payload using special Last Mile security credentials. This hyper-secure SDNP connection supports identity verification and caller privacy.

Between the remote SDNP 1350 gateway and any connected device other than the SDNP client (eg, desktop computer 36), communication is via a local area network or LAN connection such as Ethernet, Wi-Fi, or other protocols. Security is ensured by local network security protocols and device pairing between the communication device and the remote SDNP gateway. Device pairing is the process by which an authentication sequence between two communicating devices establishes the identity of the two devices, preventing unauthorized access.

FIG. 24 using a router with SDNP 1351 support, i.e. router with SDNP 1335H firmware, acts as a remote SDNP gateway. This gateway converts data packet 1223A containing IP datagram A to data packet 1223B containing IP datagram B. Although the SDNP 1335H firmware can interpret the SDNP payload contained in IP datagram A, the connected devices are not SDNP clients. Instead, SDNP Router 1351 converts the SDNP payload into regular IP broadcast. Unless additional security measures are used on the device, the latter connection is not insecure. For home use, this insecure device connection is often not a problem since the last connection takes place inside the house. Unless a hacker physically invades the house to wire a wiretap, such wire connections cannot be eavesdropped. The latest non-SDNP wired home links include Ethernet 106A, shown with an example connected to a desktop computer 36 and a 103C or HDMI-2 modem connected to a TV 39.

Since SDNP connectivity and hypersecure connectivity only extend to the SDNP 1351 Router, the Last Line must rely on authentication and encryption to secure wired connections. For Ethernet, this security can use any number of security methods (http://www.computerweekly.com/feature/iSCSI-security-Networking-and-security-options-available), including iSCSI, which operate at levels 1 to 3, such how VLANs or VLANs work using encryption among authenticated devices. Alternatively, security can be achieved using Layer 4 to 6 methods using the "IP Security" or IPSec infrastructure. Originally developed for storage and promoted by Cisco as an industry standard, IPSec offers two security modes. In Authentication Header mode, the receiving device can authenticate the sender of the data. In this mode, the data field is encrypted, but the header uses a recognizable IP address. In Encapsulated Security Payload (ESP), also known as tunnel mode, the entire IP packet, including the IP header, is encrypted and embedded in a new unencrypted IP packet so that routing can work correctly and the packet can reach its destination on the network.

In any case, security depends on authentication devices allowing them to connect to the network. In home networks, such as personal networks connected to computers, shared storage, IoT, and other devices, the hardware connected to the network does not change frequently. In such cases, authentication essentially involves the process of registering a device accessing a network or router. Instead of identifying the identity of a specific user, this type of authentication is applied between devices, usually using a device tag, name, or ID number to identify and recognize devices that are allowed to connect. Establishing a network connection includes a setup step where the devices are first introduced to each other and approved by the user to connect, followed by an automatic authentication sequence every time a wired device is physically connected to another, or for Wi-Fi when two devices are within reach each other. The setup step, referred to herein as identification pairing, may also be referred to as registering a device, pairing a device, pairing a device, pairing, or pairing. A similar process is used with devices to connect Bluetooth headphones to a mobile phone, or to pair a Bluetooth mobile phone with a car audio system with a hands-free function. Protocols include Challenge Authentication Protocol or CHAP, Kerberos V5, Simple Public-Key Generic Security Services Application Programming Interface (GSSAPI), Secure Remote Password (SRP), and Remote Authentication Dial-In User Service (RADIUS). Some methods, such as RADIUS, are based on encryption methods that have been cracked but are still used in conjunction with other methods.

While Ethernet communication protects identity devices such as the 103C Ethernet modem, the modem's output, which is composed of analog telephone signals transmitted over twisted-pair copper wire from 7 to 5A cordless phone and 37 desk phone, the last line is not secure. In addition, the communication format of the 5A cordless telephone is not secure and must be eavesdropped and monitored. For this reason, the use of home telephones in a secure connection is not recommended.

Video distribution is also a security concern. For example, when transferring data between an SDNP 1351 router and an HDTV 39, a video communication format such as High Definition Multimedia Interface (HDMI), DisplayPort (DP), Digital Visual Interface (DVI), and the less popular Gigabit Video Interface (GVIF) or Unified Digital Interface ( UDI), usually involves a physical connection to an HDTV or monitor. Initially, the security of this connection and its data was a concern of film studios and content providers, with a focus on preventing illegal copying and distribution of copyrighted material. One of the security protocols developed by Intel Corp. to ensure the security of video communications, is High-bandwidth Digital Content Protection (HDCP) (https://en.wikipedia.org/wiki/High-bandwidth_Digital_Content_Protection). This system was originally intended to prevent playback of HDCP-encrypted content on unauthorized devices. Before sending content, the system checks the authorization of the TV receiver or display. Therefore, DHCP uses authentication to prevent receiving data without a license, encrypts data to prevent eavesdropping on information and revoking keys from compromised devices.

With HDCP, the content stream from the modem to the TV can be protected by authentication, i.e. using identity pairing. However, with the advent of smart TVs, data flow is becoming bi-directional. As a means of transmitting a data stream, i.e. From TV to modem or set-top box, since version 1.4 comes HDMI, which integrates a high-speed bi-directional data channel known as HEC or HDMI Ethernet Channel. This data link means HDMI connected devices can send and receive data over Ethernet at 100MC / sec, making them ready to work in an IP base like IP-TV. HDMI Ethernet Channel allows Internet-enabled HDMI devices to share an HDMI Internet connection without the need for a separate Ethernet cable. Thus, secure communication can be maintained over HDMI using the same security and authentication protocols as Ethernet.

FIG. 25 using Wi-Fi router 1352 with SDNP support, i.e. Wi-Fi router with SDNP 1335J firmware, acts as a remote SDNP gateway. This gateway converts data packet 1223A containing IP datagram A to data packet 1223B containing IP datagram B. Although the 1335J SDNP firmware can interpret the SDNP payload contained in IP datagram A, the connected devices are not SDNP clients. Instead, the SDNP Wi-Fi Router 1352 converts the SDNP payload into a regular IP payload and wirelessly communicates with connected devices via a Wi-Fi hotspot 26 to enable Wi-Fi 29 connectivity. Unless the device uses additional security methods, the last connection is not insecure. In the case of a Wi-Fi connection in a home or office, security is an issue as data packets can be eavesdropped from a distance. Examples of home and office devices connected to Wi-Fi include desktop 36, laptop 35, tablet 33, mobile phone 32, speakers 34B, printer / scanner 34A, and shared storage 34C.

Security between SDNP gateway, i.e. SDNP Wi-Fi Router 1352 and the connected device are provided using any number of standard protocols such as Wi-Fi Protected Access WPA-II or WPA2 (IEEE 802.11i-2004) as a replacement for the old WPA and its insecure predecessor WPE. WPA2 communication is secured using CCMP, a Counter Mode Cipher Block Cipher Message Authentication Code Protocol based on AES processing with a 128-bit key and a 128-bit block size. CCMP ensures data confidentiality, requires authentication, and enforces access control. Authentication involves binding credentials during configuration. Rebinding must be done manually. CCMP security, while good, is not hypersecure because it lacks the anonymous data packets and the dynamic nature of the SDNP connection provided by the SDNP client.

In the example of FIG. 26 , for devices connected to the IoT in the home network, using the 1352 Wi-Fi router with SDNP support, i.e. A Wi-Fi router with 1335J firmware acts as a SDNP remote gateway. This gateway converts data packet 1223A containing IP datagram A to data packet 1223B containing IP datagram B. Although the 1335J SDNP firmware can interpret the SDNP payload contained in IP datagram A, connected IoT devices are not SDNP clients. Instead, SDNP Wi-Fi Router 1352 converts the SDNP payload into regular IP load and communicates wirelessly with connected devices over Wi-Fi channel 29 from Wi-Fi hotspot 26. Unless additional security measures are implemented, the Last Line will be insecure. especially since Wi-Fi data packets can be monitored from a distance. Examples of Wi-Fi connected IoT devices in the home include 34D central heating and air conditioning, 34G lighting, 34F blinds, 34K large appliances, 34E portable and indoor HVACs, 34L garage doors, 34J home monitoring, and 34H home central security system.

Security between SDNP gateway, i.e. 1352 SDNP Wi-Fi router and the connected device is secured using any number of standard protocols such as the aforementioned Wi-Fi Protected Access Protocol WPA2 using CCMP, which ensures data confidentiality, requires authentication and establishes access control. WPA2 achieves security through identity binding, and device verification is implemented as a Layer 2 protocol. This method is cumbersome and involves manual authentication methods.

An alternative protocol used for local area networks recently introduced for IoT communications is a proximal network called the AllJoyn Framework. The framework discovers devices, creates sessions, and provides secure communications. The framework is designed to support IoT device connectivity using multiple Layer 2 transport layers including Wi-Fi, Ethernet, serial bus, and power line PLCs. Applications can be based on C, C ++, Obj. C and Java running on a variety of platforms including Linux, Windows, macOS, Android, iOS, RTOS (Real Time Operating System), and the Arduino open source development environment.

All AllJoyn compatible apps authenticate each other and exchange encrypted data for end-to-end security. Authentication and data encryption is performed at application layer 7. Transport layer 2, also called a router, carries security messages between application endpoints, but does not implement any security logic. A callback function known as "Auth Listener", also implemented in application layer 7, provides authentication using PINs, passwords, or authentication certificates. Security is achieved with AES128 peer-to-peer encryption. Like WPA, AllJoyn uses credential bindings in the authentication process before executing command and control sequences. The following authentication methods are supported: pre-shared key or PSK, secure remote password exchange (SRP), or login with username and password. The protocol also supports key exchange (Diffé-Hellman elliptic curve): (i) no authentication, (ii) pre-shared key authentication, and (iii) authentication with X.509 ECDSA certificate.

The same technology can be applied to commercial enterprises. In the example of FIG. 27 for devices connected to the IoT in the home network, using Wi-Fi and Ethernet 1352Z router with SDNP support, i.e. Ethernet and Wi-Fi router with SDNP 1335J firmware, serves as a remote SDNP gateway. This gateway converts data packet 1223A containing IP datagram A to data packet 1223B containing IP datagram B. Although the 1335J SDNP firmware can interpret the SDNP payload contained in IP datagram A, connected IoT devices are not SDNP clients. Instead, SDNP and Ethernet Wi-Fi Router 1352Z converts the SDNP payload into a regular IP payload, communicates with connected devices over Wi-Fi channel 29 and Ethernet 106A.

Unless additional security measures are implemented, the Last Line will be insecure, especially for Wi-Fi data packets that can be monitored from a distance. Examples of business IoT devices connected to Wi-Fi include 34D central heating and air conditioning, 34G lighting, 34J surveillance systems, 34H security systems, 38 POS terminals, and Wi-Fi hotspot-connected devices such as a tablet 33. Devices connected to an enterprise wired network depend on the nature of the business. In banking, the devices include a 38D ATM connected to an Ethernet network. At a gas station, devices include, for example, 38A gas pumps connected to an Ethernet network.

Thus, the Last Line can be protected by non-SDNP clients communicating with a remote SDNP gateway. Thus, most of Last Mile is hypersecure, while Last Mile uses encrypted identity-based protection.

SDNP communication bridges - As described above, Last Mile data transmission outside the SDNP cloud necessarily uses IP datagrams, i. E. data packets using Internet source and destination addresses, or, alternatively, the network operator's NAT addresses. For private networks, such as those operating within office buildings, or in collaboration with local network service providers who wish to host SDNP softswitches on their servers, SDNP datagrams can also be used to achieve hypersecurity of Last Mile connections.

As described above, hypersecure communication relies on servers using SDNP software or firmware and communicating using SDNP datagrams and anonymous addresses rather than IP datagrams. Within the SDNP cloud, these SDNP servers are referred to as SDNP nodes, as indicated in the notation of the M nodes_0.0, M_0.1, M_1.0, M_1.1, etc. The above US provision No. 14/803 869 also discloses communications between multiple independent SDNP clouds connected by SDNP bridges — SDNP gateways that route IP datagrams to other SDNP clouds.

The SDNP bridge concept can similarly be adapted for use in Last Mile links. To create SDNP subnets or mini-clouds within the Last Mile, two or more servers must be enabled using SDNP bridge software or firmware. Unlike SDNP client software or firmware running on the end device, i.e. at the calling device, the SDNP bridging operation is used to route the data rather than the communication as the final connection. Thus, two or more adjacent SDNP bridges can operate as a separate SDNP bridging network, SDNP mini-clouds, or SDNP ad hoc network. The SDNP bridging function, as described above, is a Layer 3 construction, similar to the operation of the Layer 2 bridging mode of a Wi-Fi router. In an SDNP bridge network or an SDNP bridge network, communication is carried out using SDNP datagrams. To communicate with an SDNP bridge outside the SDNP bridge or SDNP bridge network, IP datagrams with an SDNP payload are used.

The operation of the SDNP bridge over Last Mile is shown in FIG. 28 , consisting of an SDNP network with an SDNP 1201A gateway, an SDNP bridge with SDNP 1350 and 1352Z routers with SDNP 1335H and 1335J firmware, respectively, and a connected client device that is not an SDNP client, as shown in the figure as a laptop 35. As shown in the figure, The communication between the SDNP 1201A gateway and the SDNP 1350 bridge is a secure connection using a 1223A IP datagram with an IP address and SDNP payload. The SDNP 1222A payload, in turn, contains SDNP routing information and an SDNP secure payload encoded with specific zone security credentials. Thus, hypersecurity is achieved with the SDNP payload, even if IP address routing is used.

Inside the SDNP bridge, i.e. between the 1350 router and the 1352Z Wi-Fi router, the hypersecure connection is made using the 1222B SDNP datagram. SDNP routing information is retrieved from the SDNP addressing contained in the 1222A SDNP payload. Collectively, the SDNP Bridge and SDNP Link provide a wired, hypersecure Last Mile link capable of supporting account identification and verification, and confidentiality.

When connecting from the SDNP bridge of the 1352Z router to a client device other than SDNP, i.e. laptop 35, using a 1223B IP datagram with an IP address and payload over LAN, Wi-Fi, or Ethernet. The security of this latter connection, while not hyper-secure, is provided by any of the aforementioned Ethernet and Wi-Fi security protocols such as iSCSI, IPSec, WPA, AllJoyn and others.

An SDNP bridging implementation can occur between any two SDNP enabled devices supporting any number of physical media, which means that SDNP bridging is a Layer 3 protocol that operates agnostically with a Layer 1 and Layer 2 transport implementation. For example, in the uppermost circuit shown in FIG. 29A , two SDNP 1351A Bridging Routers with SDNP Ethernet Bridge and 1335H firmware support Ethernet (wired) bridge communication using the 1222 SDNP datagram. In the central wiring diagram, two 1352Z SDNP bridged routers, each with Ethernet and Wi-Fi connectivity and SDNP 1335J firmware, communicate over a Wi-Fi (wireless) bridge using the 1222 SDNP datagram. In the lowest diagram on a 1351A SDNP-Ethernet bridge router with SDNP 1335H firmware, communication is carried out over an Ethernet (wired) bridge using a 1222 SDNP datagram with a 1352Z router that supports Ethernet and Wi-Fi communication using the 1335J SDNP firmware. Thus, an SDNP bridge consisting of two or more SDNP-enabled routers can route or distribute SDNP datagrams across a building or private network, even if they operate outside the SDNP cloud in Last Mile.

The SDNP bridge can be extended to systems that use their own equipment, such as cable TV systems. For example, in the uppermost circuit shown in FIG. 29B , the two CMTS cable headend servers are modified to run SDNP firmware or 1335L software to act as cable CMTS SDNP bridges 101 and communicate over a cable or fiber optic (wired) bridge using SDNP datagram 1222. The SDNP bridge can extend from the CMTS head to the subscriber's home. As shown in the diagram in the center, a CMTS SDNP cable bridge 101 with SDNP firmware or 1335L software communicates using SDNP datagram 1222 over a cable (coaxial) bridge to a cable TV box or cable modem 102 with SDNP 1335M firmware. In this way, the SDNP bridge extends hyper-secure communications to the home or office.

The discussed SDNP bridge methods can also be used to transmit data over radio networks. In the lower diagram of FIG. 29B, two cellular base stations and radio towers with SDNP firmware or software 1335N function as cellular base stations SDNP bridges 17X and 17Y for wireless communication over a cellular network consisting of bridges 25X and 25Y using SDNP datagrams 1222. In the upper diagram, FIG. A 29C microwave ground base station with SDNP firmware or 1335O software functions as an SDNP 92C satellite terrestrial bridge for microwave satellite bridge communications using SDNP 1222 datagrams with an orbiting satellite with SDNP firmware or 1335P software, i.e. with satellite bridge SDNP 93. Then the satellite, in turn, communicates with subscribers or with other satellites.

SDNP bridging can be adapted to automotive applications that use vehicles as a dedicated peer-to-peer communication network. In the lower diagram of FIG. The 29C telematics module in a 1390A car with SDNP 1335F firmware communicates via a car radio bridge using SDNP datagram 1222 with the nearest 1390B car, which also has SDNP 1335F firmware installed. Each vehicle with SDNP firmware enabled forms another communication node in the bridge's SDNP dynamic telematics network. This communication is not the transmission of information to a specific vehicle or driver, but forms a communication network capable of transmitting information along the highway even in the absence of a cell tower in place.

The SDNP bridge network concept is especially useful for communications in large geographic regions, as well as for passenger and cargo transportation by cars, trucks, ambulances, trains, airplanes, boats and marine vessels. In particular, satellite networks are needed to ensure wide coverage of the entire territory of the communication network. Typically, this system involves connecting to a satellite operator's network, called a satellite bridge or backhaul network, and satellite communications with its customers and subscribers, also known as satellite distribution. FIG. 30 schematically represents various satellite connections adapted for hypersecure SDNP communications. As shown in the figure, the SDNP 1201A gateway communicates with the terrestrial satellite antenna 92C running firmware or software SDNP 1335O using a wired connection 94A carrying data packet 1222A consisting of SDNP datagram A and SDNP payload, which in turn transmit the same SDNP datagram A as data packet 1222B via satellite bridge 95A to satellite 93 containing the 1335P SDNP firmware or software.

The distribution of hypersecure communication data packets between different clients from the SDNP 93 satellite includes a 1222C data packet and an SDNP-A data packet with an SDNP payload. Satellite communications are bidirectional, with a downlink from satellite 93 to terrestrial clients capable of providing higher signal strength and higher data rates than the uplink. In other words, the satellite can transmit higher data rates and signal strengths to the terrestrial client than the client's response. Examples of satellite 93 communication channels with subscribers include satellite communication 95B for 92G antenna of 92G Internet subscriber running SDNP 1335T firmware, 92F satellite phone with SDNP 1335S firmware, 92H satellite antenna installed on high-speed train 1360C with SDNP 1335G firmware, installed satellite antenna network 92E on ocean-going ship 1360B with firmware SDNP 1335R, and installed satellite antenna network 92D on aircraft 1360A with firmware SDNP 1335Q.

In the case of large vehicles such as ships, airplanes and trains, each system connects this hypersecure satellite link to its own internal communications system or local area network. FIG. 31A , for example, illustrates a commercial aircraft where a satellite antenna module 92D with SDNP 1335X firmware installed on the fuselage of a 1360A aircraft connects to a central communications server 1361 running SDNP 1335Z software. The 1361 Central Communications Server connects to a variety of systems including 1367 gauges, 1368 datalogger and black box, 1363 data storage module and 1362 Wi-Fi router module, optionally with SDNP 1335L firmware. The 1362 Wi-Fi module of the router connects to a network of 1361 antennas located throughout the aircraft to provide Wi-Fi hotspot connectivity. All communications, with the exception of radio flight control, are carried out over a common satellite link using antenna module 92D, as shown in the example of FIG. 31B . The antenna module includes a transmitting satellite dish 1360A, a receiving satellite dish 1368A, a control unit 1369 and a 40W voltage regulator 1370. The satellite receiving antenna 1368A is smaller than the satellite transmission antenna 1360A because the power and signal strength of the satellite broadcast is greater than the broadcast power of the antenna and uplink capabilities.

The ship's ocean-going satellite communications vessel uses multiple satellite communications bands, including high-altitude and low-earth orbit satellites. For example, FIG. 32 illustrates the use of multiple communication bands, including the 1383A Ku-band satellite dish and the 1383B and 1383C LEO satellite dishes. High-altitude satellites lack or have limited uplink capabilities, but are capable of covering large areas from high altitudes, including geosynchronous orbits. Due to the high altitude, the coverage area of each satellite is significant, as shown in Map 1384. As shown in Map 1385, satellites in LEO cover smaller areas, which requires more satellites and therefore higher cost to cover the area. broadcasting. Depending on the course of the vessel, access to LEO satellites can be intermittent depending on the orbital position of the satellites.

Since the Ku-band 1383A satellite dish is mainly used for the distribution of television and film content, SDNP security is generally not required. Tracking and positioning is carried out using the control antenna 1383. The multichannel data from the satellite antenna 1383A is fed into the multichannel L-band 1381, separating the signals into fixed video signals transmitted to TV receivers and tuners 1382 and digital broadcasting of DVB data. Video content is fed to central 1380 communications servers. However, if secure communications are required, the 1383A Ku-band satellite dish can be adapted to work with SDNP software.

The data from the 1383B and 1383C LEO satellite antennas, running on SDNP 1335U and 1335V firmware, transmit information from the satellite dishes to the 1380 central communication servers running on SDNP 1335Z. In range overland, the communication system is also capable of communicating using a 4G / LTE cellular network 25 located at a cellular base station 17 with SDNP 1335N firmware. Communication through 1380 servers is distributed throughout the vessel using an SDNP Wi-Fi router 1362 with firmware SDNP 1335L. Wi-Fi hotspot 26 is distributed throughout the vessel using Wi-Fi 1361 antennas. Communication with SDNP clients such as cell phone 32 with SDNP 1335 application facilitates hyper-secure end-to-end connectivity. Devices not included as SDNP clients must rely on identity pairing using WAP, AllJoyn, or other security protocols.

FIG. 33 illustrates the application of multiband communication in high speed trains. As shown in the figure, the railroad data center server 1380 with SDNP 1335Z software connected to the SDNP 1201A gateway connects to the high speed train 1360C via several PHY connections, including satellite microwave communications 95B, radio 1372 400 MHz, and microwave 1373 60 GHz. During SDNP data exchanges, the SDNP 1380 datacenter transmits data via satellite dish 92C with SDNP 1335D firmware to satellite 93 with SDNP 1335P firmware. The satellite communicates with a 1383V rail antenna connected to a 1361 server running SDNP 1335Y software. Alternative communication is possible from SDNP data center 1380 to 400 MHz 1381 antenna or 60 GHz 1382 antenna located at regular intervals along the railway tracks. These satellites also communicate with the 1383B antenna connected to the 1361 SDNP training server running the SDNP 1335Y software. The communication received by SDNP Server 1361 is then distributed along the train via Wi-Fi bridges 1335Z, and to clients in the form of Wi-Fi hotspots.

The communication function in the automotive and professional transport industry is multifaceted and includes the following:

Voice communication

Navigation, maps, road information, alerts

Entertainment, hotspot services, infotainment

services

Wireless payments, fare

Emergency services, roadside assistance

Collision avoidance

Dispatch center working hours

Additional functions are also required for autonomous vehicles, i.e. for cars with automatic control. Based mainly on older cellular networks such as a CDMA (2.5G) managed central unit called a "telematics" module, existing automotive systems are extremely susceptible to hacker attacks, cyberattacks, and privacy attacks. To eliminate this vulnerability, the entire network must be protected without significant costs, i.e. installing a new network shouldn't be a financially problematic option. Instead, the security infrastructure should be imposed on top of the hardware network as security techniques deployed at Layers 3 through 7. This strategy is consistent with the SDNP Last Mile implementations described here.

FIG. 34 illustrates an example of a hypersecure Last Mile connection between a car and an SDNP cloud. As with previous Last Mile connections, the specific media involved in transporting packets across the Last Mile can vary significantly depending on location. Thus, an example is shown that represents hypersecure communication regardless of the communication media used. As shown in the figure, the SDNP gateway 1201A connects to the network router 67A through a wired or fiber connection 24 operated by a network service provider (NSP), converting data packet 1222A containing SDNP datagram A into data packet 1223A containing IP datagram B with payload SDNP. Network router 67A then forwards IP datagram B as data packet 1223B to cellular base station 17 over wire or fiber line 24A owned or operated by a mobile operator (MNO). The IP B data packet is then wirelessly transmitted over cellular network 25 as data packet 1223C containing SDNP datagram B with SDNP payload to vehicle telematics module 1390A using cellular 28 using either 2.5G, 3G, 3.5G, or 4G. / LTE depending on the mobile operator in the region. The SDNP 1335F firmware running in the telematics module interprets the SDNP payload embedded in the incoming 1223C data packet to terminate the hypersecure connection. Thus, the Last Line car cellular connection functions as part of the hypersecure Last Mile connection.

As shown in FIG. 35 , vehicle telematics module 1390A then uses secure information for various functions controlled by infotainment interface 1377. Indoor Wi-Fi access point 1362D also distributes data packets 1223B and 1223C containing IP datagram B and IP datagram C, respectively. IP Datagram B contains an SDNP payload that facilitates an end-to-end hypersecure connection to any SDNP client, such as a 32B cell phone with SDNP Application 1335. IP Datagram C using only regular IP payload is less secure but works with devices that are not working as SDNP clients such as mobile phone 32A and tablet 33A. Identity pairing can be used to improve Last Line security for non-SDNP devices using WPA, AllJoyn, or other protocols.

Another important function of automotive communication is vehicle-to-vehicle communication, also called V2V communication. V2V communication is primarily intended for collision avoidance. But according to the SDNP methods described here, V2V links can also function as ad hoc peer-to-peer hyper-secured networks. Such inter-transport SDNP communication is illustrated in FIG. 36 , where vehicles 1390A, 1390B and 1390C with SDNP 1335F firmware form a peer-to-peer network with each other and with base station 17 connected to the 1201A SDNP gateway. Communication between vehicles can be done using either IP datagrams or SDNP datagrams.

In case an SNP client or gateway communicates with a non-SDNP device, the communication is done using IP datagrams. For example, SDNP gateway 1201A converts SDNP datagram A with SDNP payload to data packet 1223A containing IP datagram B with embedded SDNP payload. As shown in the figure, base station 17 communicates with vehicle 1390A over 28A 2.5G or 3G cellular line using data packet 1223B containing IP datagram B with embedded SDNP payload, but is capable of communicating with vehicle 1390C over 28B 3.5G cellular line. or 4G / LTE using data packet 1223C, also containing IP datagram B with embedded SDNP payload. Thus, the SDNP payload is distributed independently of the network used to transmit the data packets.

Vehicles supporting SDNP 1335F firmware can also form dedicated peer-to-peer SDNP bridges or bridge networks. For example, vehicle 1390A communicates with vehicle 1390B over radio 1391A V2V using data packet 1222B containing an SDNP datagram C rather than an IP datagram. Similarly, vehicle 1390B communicates with vehicle 1390C over a 1391B V2V radio using data packet 1222C containing SDNP datagram D and does not rely on IP datagrams. Regardless of the type of datagram used, the embedded content remains hyper-secure with the SDNP payload.

Another feature of the ad hoc V2V SDNP network is its ability to perform tunneling functions, i.e. transfer data from one vehicle to another without the possibility of monitoring and interpreting the data through which the passing vehicle passes. In the event that cellular 28B fails due to vehicle 1390C being out of coverage, as an alternative path, cellular base station 17 can use an SDNP bridged network to reach the same subscriber, as exemplified by cellular 28A, V2V 1391A, and, finally, the V2V radio communication 1391B. During transmission, data packets 1223B, 1222B, and 1222C change from IP datagram B to SDNP datagram C and finally to SDNP datagram D. Since the SDNP payload for the 1390C vehicle is designed specifically for the target vehicle, the 1390B vehicle and its passengers cannot be hacked. or monitor the contents of SDNP datagrams C even if they are transmitting a 1222B data packet over an ad hoc network.

In addition to the traditional Last Mile communication, the same SDNP bridging technology can be used to transfer large amounts of data using hyper-protection over long distances, ie. digital backbone communication. Three such examples are shown in FIG. 37 , namely microwave 98, fiber-optic 90 and satellite 95A data links 95B. While this feature can be viewed as part of the SDNP cloud, the single data path is similar to the Last Mile communication route and therefore uses similar techniques to provide hypersecurity. For example, servers 21A and 21B running SDNP 1335Z software can communicate over microwave link 98 through stations 96A and 96B running SDNP 1335W firmware using data packet 1222 containing SDNP datagrams, or servers 21A and 21B can communicate data directly over optical channel 98, also using data packet 1222 containing SDNP datagrams. In global communications, such as the trans-Pacific link, servers 21A and 21B can communicate with satellite 93 running SDNP 1335B firmware using microwave satellite trunks 95A and 95B using terrestrial satellite antennas 92A and 92B, both running SDNP 1335U firmware. ... As with the examples of fiber optic and microwave towers, the satellite backbone uses data packet 1222 containing SDNP datagrams.

In conclusion, the security and privacy features offered in the Last Mile relationship depend on two interacting devices. FIG. 38 contrasts with four different combinations representing, in order from bottom to top, increased security and privacy. In each case, three factors are taken into account: i) security, the ability to prevent unauthorized access to communications, ii) verification of identity, the ability to authenticate the user and adjust access and privileges based on his identity, and iii) anonymity, the ability to hide the identity of callers from surveillance.

In the example below, an SDNP 1395 gateway communicates openly with a non-SDNP client with no security guarantees, using a 1223C data packet consisting of an IP datagram with a listening IP address and payload. Thus, the Last Mile connection is not secure or confidential. In the second example from the bottom, the SDNP 1395 gateway interacts with a non-SDNP client to offer authorization and device pairing functionality. Communication is carried out using data packet 1223B containing an IP datagram with an eavesdropping-vulnerable IP address, but using an encrypted payload containing ciphertext, where only a device with limited identity can decrypt. Although communication is not private or anonymous, it provides increased security, at least for a limited period of time.

The example above illustrates that an SDNP 1395 gateway can route communications through any 1397 bridge or router and still achieve hypersecurity, provided the 1223A data packet contains the SDNP payload in an IP datagram. The achieved level of security depends only on the end device and not on the router. In the example above, communication between SDNP 1395 gateway and SDNP Client 1396 using data packets 1222 containing SDNP datagrams with SDNP address, i.e. using source and destination addresses not recognized by DNS servers, and using secure SDNP payloads, it is hyper-secure, offering superior security, full confidentiality, and anonymous packet routing.

Routing packets within the hypersecure Last Mile - Regardless of the algorithm used and the methods of physical equipment and data transmission of the first and second layers, the routing of packets between the SDNP client or SDNP bridge and the SDNP gateway depends on IP datagrams for transporting and routing data packets through the Last Mile. Unlike the routing of data within the SDNP cloud, directed by SDNP signaling servers, the SDNP cloud or its signaling servers do not control IP datagrams passing through the Last Mile. As a result, some variability in Last Mile propagation delays should be expected. Fortunately, due to the limitation of Last Mile communication distances and the number of possible routes, this uncertainty is small compared to the overall end-to-end WAN propagation delay. The change in overall propagation delays due to Last Mile variability is estimated to be less than 10% of the cumulative delay.

FIG. 39 illustrates a single Last Mile connection route between SDNP Client 1400 and SDNP Gateway 1401 using fixed IP addresses. The IP datagram 1405 includes the destination IP address M _0,0 (SDNP gateway) and the source IP address of the data packet C _1,1 - the SDNP client. The last connection is on a single route 1404 to router 1402A. Data is routed through any number of R routers, such as 1402B, to an SDNP M _0.0 gateway.

An alternative representation of Last Mile Network Connection describes each communication device as an IP stack representing PHY, data link, and network connections as OSI layers 1, 2, and 3. For example, in FIG. 40A shows an IP stack that is a single-route hypersecure Last Mile connection using static IP addresses. Thus, a client device consisting of an SDNP C _1,1 client establishes a single Last Mile 1409 connection route with an SDNP 1401 gateway, including an SDNP M _0.0 gateway through routers 1402A and 1402B, where 1402A router enables Wi-Fi, and Router 1402B - Ethernet router. Client device 1400 connects to router 1402A through the "Back Line" 1404, where the Layer 1 PHY connection and the corresponding link layer 2 of the client IP stack 1411 are connected to the corresponding layers 1 and 2 in the router's IP stack 1412A.

In turn, the 1402A router connects to the 1402B router via Ethernet, where the Layer 1 PHY connection and the corresponding Layer 2 data link of the 1412A Wi-Fi router's IP stack are connected to the corresponding Layer 1 and Layer 2 in the 1412B Ethernet router's IP stack. Finally, the 1402B connects to the SDNP 1401 gateway server over Ethernet, where the Layer 1 PHY and the corresponding Layer 2 data link of the Ethernet IP Stack 1412B are connected to the corresponding Layer 1 and Layer 2 in the 1422 Gateway IP stack. routers transmit data without interference, so that Layer 3 network datagrams pass seamlessly from one IP stack to another, in particular from Layer 3 to the IP stack 1411-1412A, 1412B, and finally to 1422. Thus, the network transmits IP datagrams as a single route through the virtual Last Mile 1409 connection, even if the data is physically transmitted through multiple devices.

In other words, Layer 3 network traffic flows through the Last Mile regardless of the physical connections used to carry the IP data, ie. Last Mile Level 3 communication operates agnostically to the lower levels 1 and 2 used for data transmission. This principle can be simplified by removing the intermediate nodes from the schematic as shown in FIG. 40B , where client devices 1400 and SDNP gateway server 1401, including IP communication stacks 1411 and 1422, transmit data to and from the respective computations and storage functions 1410 and 1421. IP datagram 1405 traverses Last Mile 1409 regardless of the medium or number of routers used to deliver the data packets. Thus, "The Last Mile" can be viewed as a "data construct", ie. an abstraction meaning any and all physical means by which an IP datagram is transmitted between and between devices. The latter connection, however, is of greater physical importance since the connected caller's device cannot be established on the downlink router. For example, if the caller has a Wi-Fi-only tablet and is in a cafe with Wi-Fi, but does not have a WPA password for the Wi-Fi network, then the Last Line feature cannot be set and the caller cannot can connect to Last Mile, SDNP cloud, or make a call.

Another option for Last Mile is that the payload of the IP datagram 1405 contains all of the information for the upper OSI layers, including Transport Layer 4 data, Session Layer 5 data, Presentation Layer 6 data, and Application Layer 7 data. 4 required for the choice of UDP or TCP transport protocols, the rest of the data in the payload of the IP datagram is specific to the considered SDNP communication and cannot be interpreted by routers operating along the Last Mile unless they themselves use software or SDNP firmware. Accordingly, only end devices, i.e. the caller or SDNP client and SDNP gateway can interpret the Last Mile connection, even if the Last Mile network itself may be a fusion of various devices, carriers and ISPs.

Although the SDNP payload is protected by numerous secrets, including encryption, fragmentation, junk insertion and deletions, static formatting and dynamic encryption, the IP addresses of IP datagrams passing through the Last Mile network necessarily show the source and destination addresses of the client device. 1400 and the SDNP gateway on server 1401. To provide some degree of Last Mile anonymity, it is useful to mask addresses; misdirecting cybercriminals by dynamically changing the source and destination addresses in the IP datagram. Masking IP addresses can be accomplished by dynamically changing the IP address of the connected caller's device, referred to herein as "dynamic client addressing", or by communicating with multiple SDNP gateways, i. E. by the multi-route "Last Mile" connection.

The first of the described methods of spoofing IP addresses is to dynamically change the source address of sequential data packets. As shown in FIG. 41 , IP datagrams A, B, and C sent sequentially consist of three different source addresses. Specifically, IP datagram 1405A includes source address IP C _1,1 , IP datagram B 1405B includes source address IP C _1,2 , and IP datagram C 1405C includes source address IP C _1,3 . So while all packets entering router 1402A originate from SDNP 1400 client, the original address of client C _{1, n} changes dynamically, creating confusion between the true IP address and more than one transmitting device. To complete the charade, the MAC address of the transmitting device must also change accordingly with the dynamic source address.

This method is illustrated using the example of IP stacks in FIG. 42A , where devices 1400, 1402A, 1402B, 1401 communicate through the respective IP stacks 1411N, 1412A, 1412B, and 1422 using Wi-Fi and Ethernet, but where the third layer SDNP client network identity includes multiple C _1,1 IP addresses. C _1.2 and C _1.3 . As a result, the serial data packets arriving at router 1402A are sent from three different client devices, rather than one as shown in the "Last Line" schematic shown in FIG. 42B . The general PHY layer includes standard Wi-Fi frequencies, and the link layer that connects devices follows established standards such as 802.11ac or 802.11n.

1405N IP datagrams sent to 1402A router over 1408 network connection contain a fixed destination IP address IP M _0.0 and sequential source addresses IP C _1.1 , IP C _1.2 , IP C _1.3 , etc. represented in mathematical notation as IP C _{1, n} where n = 1, 2, 3, ... is the unique identification of each sequential packet. Each subsequent IP packet also includes the corresponding payload SDNP 1, SDNP 2, SDNP 3, and so on. Note that while this description applies to each IP address using the mathematical abbreviation IP C _{1, n} , it is understood that IP addresses are real IP addresses, created according to international IPv4 or IPv6 standards, and exclude any backup IP addresses.

Another option for increased security is the use of multi-route packet transport in Last Mile. Similar to the transmission of data within the SDNP cloud, audio and serial data is parsed and fragmented, then divided into separate packets and addressed to various SDNP gateways in multi-route mode. An example of multi-route data transmission using static IP addresses is shown in FIG. 43 , where the SDNP 1400 client interacts with multiple gateways 1401A, 1401B, and 1401C. As shown in the figure, the first data packet 1405A includes an SDNP payload 1 with a source IP address C _1,1 and a destination address M _0,0 . The data packet 1405A is then routed through the "Last Line" 1404A through routers 1402A and 1402B to the SDNP gateway 1401A. Similarly, second data packet 1405B includes SDNP payload 2 with source IP address C _1,1 and destination address M _0,1 . The data packet 1405B is then routed through the "Last Line" 1404B through router 1402C to the SDNP gateway 1401B. The third data packet 1405C includes an SDNP payload 3 with a source IP address C _1,1 and a destination address M _0.3 . The data packet 1405C is then forwarded on the last link 1404C through router 1402D and 1402E to SDNP gateway 1401C.

The path between client device 1400 and one of three gateways 1401A, 1401B, or 1401C shows IP datagrams being routed through multiple Back Lines 1404A, 1404B, and 1404C to multiple routers 1402A, 1402B, and 1402C. These routers can include (i) completely independent routers using the same physical media, such as Wi-Fi or Ethernet, (ii) multiple routing channels in a single hardware device, such as multiple mesh channels in a DOCSIS3 cable modem, or (iii) different physical media. communication medium, for example, one goes through Wi-Fi, the other through 3G, etc.

For example, FIG. 44A illustrates an IP stack depicting the aforementioned Last Mile multi-route hypersecured connection through the Last Line physical layer 1404 using static IP addresses. During operation, the SDNP C _1,1 client interacts with routers 1401A, 1402B, and 1402C as one device using a common PHY, data link and network. Masking of addresses is carried out using sequential IP datagrams containing the static client address IP C _1,1 , but with a change in the addresses of the SDNP gateway IP M _0.0 , IP M _0.1 and IP M _0.3 . Packet forwarding can occur algorithmically or randomly. For example, if every 10th datagram sent from the client 1400 is directed to the SDNP 1401C server, then the 10th outbound datagram from the client 1400 will contain the destination IP M _0.3 and the source IP address C _1,1 ... Replies from the gateway server SDNP 1401C are returned to the client device 1400 on the way back, i. E. with source IP address IP M _0.3 and destination IP C _1.1 .

As shown in the figure, the PHY and the data link between the client device 1400 and the routers 1402A, 1402D, and 1402C represent a single transmission medium such as Wi-Fi. Although the Last Line connections are represented as separate lines divided into three parts, it should be understood that all physical connections are point-to-point and not the electrical Y-connectors used to create parallel wires. Instead, the image means that the connections should show a connection effect, i.e. the physical layer PHY of the client IP stack 1411 expands one PHY connection by three, i.e. connection to the physical layer PHY of the IP stack 1412A, 1412C and 1412D. Functionally, this "Last Line" operates as one output to three input expansion modules, where one customer connects to three router functions, whether the router functions are contained in one common electronic device or split into separate routers. Note that, as shown in the figure, Last Line 1404 represents one type of transmission medium — cable, fiber, Wi-Fi, Ethernet, or cellular.

However, the remainder of the Last Mile may be any media not necessarily the same as Last Mile. The Last Line alternative includes several different physical PHY layers connecting to independent routers. With this implementation, an IP stack performing a Last Mile multipath hypersecure connection using static IP addresses over multiple physical PHYs on the latter is shown in FIG. 44B . Specifically, client device 1400 operates on a shared layer 3 network interface with a static client IP address C _1,1 , but uses separate and distinct Layer 1 and Layer 2 interfaces represented by IP stacks 1411A, 1411B, and 1411C. In operation, the 1411A IP stack connects to the 1402A router through the 1404A Last Line, which sends an IP datagram consisting of a source IP address C _1,1 and a destination IP address M _0,0 through router 1402B. Likewise, the 1411B IP stack connects to 1402C through the 1404B Last Line, sending IP datagrams consisting of the source IP address C _1,1 and the destination IP address M _0,1 . The 1411C IP stack connects to the 1402D router through the 1404C Last Line, sending IP datagrams consisting of a source IP address C _1,1 and a destination IP address M _0.3 through router 1402E.

The combination of dynamic source addressing and multi-route data transmission is shown in FIG. 45 , where the SDNP 1400 client interacts with multiple gateways 1401A, 1401B, and 1401C using dynamic source addresses. In this method, the first data packet 1405A includes an SDNP payload 1 with a dynamic source IP address C _1,1 and a destination IP address M _0,0 . The data packet 1405A is then routed through the "Last Line" 1404A through routers 1402A and 1402B to the SDNP gateway 1401A. Similarly, second data packet 1405B includes SDNP payload 2 with dynamic source IP address C _1,2 and destination IP address M _0,1 . The data packet 1405B is then routed through the "Last Line" 1404B through router 1402C to the SDNP gateway 1401B. The third data packet 1405C includes an SDNP payload 3 with a dynamic source IP address C _1.3 and a destination IP address M _0.3 . The data packet 1405C is then forwarded on the last link 1404C through routers 1402D and 1402E to SDNP gateway 1401C.

Thus, each subsequent data packet contains a changing SDNP payload, uses dynamically changing source addresses, directed to different last links to unique SDNP gateways. To transmit data over several "Back Lines", namely "Back Lines" 1404A, 1404B and 1404C, either one router with multiple IP inputs, such as a DOCSIS3 cable modem with trellis modulation (or trellis coding), is used, or through multiple media for example multiple Wi-Fi bands, radio and Wi-Fi combinations, or other wired and wireless combinations. In one example in FIG. 46A illustrates the IP stack of a Last Mile hypersecure multi-route connection using dynamic client IP addresses over a Single Layer Physical PHY of the Last Line 1404. Client device 1400, illustrates a generic physical interface consisting of Layer 1 and Layer 2 communication as shown in IP -stack 1411A. At the network layer, the 1411A IP stack generates a C _1,1 client address directed to the SDMP M _0.0 gateway, the 1411B IP stack generates a C _1,2 client address directed to the SDMP M _0.1 gateway, and the 1411C IP stack generates a C _1.3 client address directed to an SDMP M _0.3 gateway.

The same multi-route approach can be combined with dynamic client addressing and a few final PHY layers, as shown in the IP stack diagram in FIG. 46B . As shown in the figure, the client device 1400 contains three IP stacks 1411A, 1411B, and 1411C, transmitting IP datagrams with corresponding IP addresses C _1,1 , C _1,2, and C _1,3 on the Back Line 1404A, 1404B and 1404C to an SDNP gateway with IP addresses M _0.0 , IP M _0.1, and IP M _0.3 .

In many cases, the Last Line is a single route that uses multi-route data outside of the first router. FIG. 47, the SDNP 1400 client communicates with one router 1402A through the "Back Line" 1404. In addition to router 1402A, data packets are routed to multiple gateways 1401A, 1401B, and 1401C using dynamic source addresses. In this implementation, the first data packet 1405A includes an SDNP payload 1 with a dynamic source IP address C _1,1 and a destination IP address M _0,0 . The data packet 1405A is routed through the "Last Line" 1404 and through routers 1402A and 1402B to the SDNP gateway 1401A.

Likewise, second data packet 1405B includes SDNP payload 2 with dynamic source IP address C _1.2 and destination IP address M _0.1 . Data packet 1405B is routed through Last Line 1404 and through routers 1402A and 1402C to SDNP gateway 1401B. The third data packet 1405C includes an SDNP payload 3 with a dynamic source IP address C _1.3 and a destination IP address M _0.3 . Data packet 1405C is sequentially routed through Last Line 1401 and through routers 1402A, 1402D, and 1402E to SDNP gateway 1401C. Thus, each subsequent data packet contains a changing SDNP payload, uses dynamically changing source addresses, directed along the last common links to unique SDNP gateways.

This Last Mile connection is illustrated by the example of IP stacks in FIG. 48 , where IP stack 1411 on SDNP 1400 client device with Last Line function 1404 exclusively with router 1402A sends data packets at network layer 3 to stack 1412A with three different network addresses, namely IP C _1,1 , IP C _{1 , 2} and IP C _1.3 . Thus, the client device 1400 appears to router 1402A as three separate clients, when in fact it consists of one client. Once the IP datagrams reach Router 1402A, they split up and take different routes to different destination gateways. Packets with source IP C _1,1 , for example, can be routed through router 1402B to IP M _0,0 , packets with source IP address C _1,2 can be routed through router 1402C to IP M _0,1 , and packets with source IP address C _1.3 can be routed through routers 1402D and 1402E to destination IP M _0.3 . The routing table for directing a data packet with a given dynamic client address C _{1, n} to a specific SDNP gateway is not preset and can be dynamically changed. IP addresses can be assigned on a packet-by-packet basis, further complicating the fact that apparently unrelated data packets are part of a single fragmented connection between two callers.

Physical Implementation of Last Mile Routing - The physical implementation of the Last Mile can include communications over a variety of communication channels, including Ethernet, Wi-Fi, cellular or DOCSIS3-compliant cable and fiber lines. Regardless of the transmission medium used, the routing of data packets on the Last Mile is mainly controlled by three variables, namely:

Network card number (MAC address) of communication devices,

Source IP address of the IP datagram,

The destination IP address of the IP datagram.

Thus, MAC addresses control the physical media used to perform each hop on a Last Mile connection, i. E. Layer 1 and Layer 2 information, and the IP addresses identify the client device and SDNP gateway, i.e. devices at both ends of the Last Mile. Although the payload used in the hypersecure connection conforms to the protocols defined by the Secure Dynamic Network and Protocol, intermediate devices in the Last Mile, i. E. routers and other devices on the packet route between the client device and the gateway usually cannot perform SDNP functions due to the lack of executable SDNP code in such devices. Therefore, the SDNP payload does not affect the routing of the hypersecure Last Mile data packets.

One example is the use of Ethernet for Last Mile communications. By adapting the Ethernet data packet described above in FIG. 9E for Last Mile SDNP data transmission, FIG. 49 is a graphical representation of IPv4 and IPv6 datagrams for Ethernet data transmission with SDNP payload. As shown in the figure, Layer 1 Ethernet packet 188 contains a data frame header, i. E. preamble 180, SFD start frame separator 181, and Ethernet Layer 2 packet 189. Ethernet packet 189 includes MAC addresses 182 and source and destination 183, additional 802.1Q tag 184 for VLAN implementation, Ethertype 185 field to indicate the type of data transmission channel used (Ethernet II or IEEE802.3 length specification) and a 186 frame check including a 32-bit CRC for the entire data link packet. Ethernet packet 189 also contains a variable length MAC address payload 187 used to encapsulate the contents of SDNP 1430 into an IP datagram. In particular, MAC payload 187 contains IP header 434 and IP header 435, including transport header 436 and SDNP 1430.

The IP header 434 changes depending on whether the IP datagram follows IPv4 or IPv6 as defined by protocol field 447 containing binary entry 4 or protocol field 448 containing binary entry 6. Preambles 440 and 444 contain transport header 470 used to define the layer 4 transport to use, such as TCP, UDP, or ICMP and IGMP service functions. In particular, according to the secure dynamic communication network and protocol, TCP transport is used to transfer software and data files, and UDP is used to transfer real-time data such as VoIP and video. The length and format of transport header 436 varies depending on transport header 470. Header 434 contains source and destination IPv4 addresses 441 and 442 or source and destination IPv6 addresses 445 and 446.

The routing of Last Mile Ethernet packets depends on both IP addresses and MAC addresses, represented by sample device names that include IP or MAC addresses, such as MAC C _1,1 or IP M _0,0 . For clarity, instead of a numeric address, symbolic names are used, which are a numeric address made in accordance with the Internet protocol in the Ethernet format. Note that the IP C _1,1 IP address has different formats and uses different number of bytes for IPv4 and IPv6 names. In addition, the format of the MAC address depends on the used Layer 2 data link protocol. So the MAC C _1,1 MAC address for cellular radio is not the same MAC address for the same device communicating over Wi-Fi or Ethernet. MAC addresses are not related to IP addresses, i.e. The IP address and MAC address of the same client are not related to each other.

Serial routing of Last Mile Ethernet packets is shown in the examples in FIG. 50A of FIG. 50D . Each shape contains two Ethernet packets — the top one containing an IPv4 datagram and the bottom one containing an IPv6 datagram. Since IPv4 and IPv6 use different formats with different field lengths, the two Ethernet packets shown tend to be different lengths even with the same payload. In the first phase of data transfer, the SDNP-A payload moves from the SDNP client 1400 to the router 1402A through the Last Line 1404, and then through the gateway link 1414 to the SDNP gateway 1401. The response from the SDNP gateway to the client includes the SDNP G payload from the gateway 1401 through gateway link 1414 to router 1402A, then through Last Line 1404 to client 1400. SDNP client 1400 has numeric MAC and IP addresses C _1,1 and IP C _1,1 , router 1402A has numeric MAC address MAC R, and SDNP gateway has numeric MAC and IP addresses MAC M _0.0 and IP M _0.0 . The IP address of the 1402A router is not used in data packets.

Unlike the SDNP cloud, where SDNP datagram packet routing is entirely controlled by the SDNP network, in Last Mile IP datagram networks, the SDNP payload cannot be interpreted or influenced by routing, that is, every connection transmitted over the Last Mile "contains fixed source and destination IP addresses. The physical media or channels used to route Ethernet packets are controlled by the MAC addresses that connect each link in the Last Mile. For example, in FIG. 50A shows the IPv4 and IPv6 last-line Ethernet packets used for single-link routing by the 1402A, including source MAC address MAC C _1,1 , destination MAC address MAC R, source IP address C _1,1 , destination IP M _0,0 and SDNP payload. FIG. 50B illustrates corresponding Ethernet packets carrying SDNP payload over gateway link 1414. As described above, the source and destination IP addresses remain unchanged at IP C _1,1 and IP M _0,0 , and the source and destination MAC addresses are changed from their original values. on MAC R and MAC M _0.0 .

In reciprocal communication between the SDNP gateway 1401 and the client 1400, the SDNP payload G travels through the same network in reverse order, i. E. where source and destination addresses are exchanged. As shown in FIG. 50C , the source and destination IP addresses consist of IP M _0,0 and IP C _1,1 , respectively, and the MAC addresses include the source MAC address M _0,0 and the destination MAC address R. In a Last Line connection, shown in FIG. 50D , source and destination MAC address MAC R and MAC C _1.1 , and source and destination IP address remains the same as IP M _0.0 and IP C _1.1 .

One convenient way to represent Last Mile communication with an SDNP client is to use "truncated" data packets containing data fields containing source and destination MAC addresses, source and destination IP addresses, and SDNP payloads. The abbreviated form is convenient for illustrating the flow of data in any communication "session", i. E. constructing and replies to serial data packets transmitted through the Last Mile to the SDNP gateway. For example, serial Ethernet packets (shown in abbreviated form) sent from an SDNP client to an SDNP gateway are shown at the top of FIG. 51A . Each row represents sequential data packets containing the SDNP payload, A, B, and C. The left column shows the data packets in the "Last Line" and the right column shows the data packets containing the same payload across the gateway. As shown in the figure, all packets indicate IP C _1,1 as the source IP address and IP M _0,0 as the destination IP address. Since there is only one pair of IP addresses, Last Mile is referred to here as a single SDNP Last Mile connection. In addition, since the source IP address used by the SDNP client 1400 to transmit serial data packets is unchanged, "Client Static Addressing" is used in the "Last Line".

To facilitate Layer 2 connectivity between each site and its neighbors, the MAC addresses in the various Last Mile segments are necessarily changed. As shown in the figure, all subsequent packets on the last link from the client to the router use the source MAC and destination MAC addresses C _1,1 and MAC R. Since the client uses the same MAC address in subsequent data packets, The "Last Line" includes one physical transmission medium, i. E. one physical layer PHY "Last Line". Transport on the gateway channel uses the source and destination MAC addresses MAC R and MAC M _0,0 , respectively.

So while the data packet shown contains an SDNP payload, Last Mile routing necessarily uses intercepted MAC and IP addresses — addresses that can be interpreted by unauthorized listeners. By monitoring packets with identical source and destination IP addresses, an unauthorized listener can conclude that the data packets are likely part of the same conversation or session, and even if they cannot open the SDNP payload, they can collect metadata like like call time, file size, baud rate, etc. to create a caller profile. Moreover, by following MAC and IP addresses, which are metaphorically reminiscent of a trail of breadcrumbs, a hacker can trace the origin of the call to the end device, i.e. client device and then personally identify the caller.

In this document, the best way to prevent tracking of client devices, mask their associated call packets, and block metadata collection is to dynamically change MAC and IP addresses on Last Mile and Last Line connections. These inventive camouflage techniques include:

Sending data packets over alternating means of communication by dynamically changing the MAC addresses of the "Last Line", referred to in this document as "Multilayer Physical Connection" of the "Last Line",

Caller masking by dynamically changing the identity of the client device's IP address, called "dynamic client addressing"

Changing the path of serial data packets across the Last Mile by dynamically changing the link IP address to and from different SDNP gateway IP addresses, referred to herein as "Last Mile Multipathing".

The combination of feature-rich, high-speed, dynamic client addressing and Last Mile multi-routing makes monitoring and tracking Last Mile and Last Line connections extremely challenging as only the SDNP caller and SDNP gateway know which packets are part of the same call or session. These methods can be used individually or in combination.

For example, the lower half of FIG. 51A illustrates the use of a "Last Line" physical tiered connection in a single Last Mile static client addressing link. As shown in the figure, each line contains a pair of data packets used in communication between an SDNP client and an SDNP gateway - left side, representing the "Last Line" data packet, the right side describing the gateway channel data packet. Three lines represent three consecutive messages, the top line contains the first data set "SDNP A payload", the middle line contains the SDNP B payload, and the bottom line describes the third data packet containing the SDNP payload C. For one Last Mile communication route with a static client addressed to all subsequent data packets, the client's static IP address C _1,1 and the permanent IP address IP M _{0,0 are used} .

In order to perform the "multi-level physical connection of the Last Line", i. E. to forward data to the "Last Line" through multiple physical media, the MAC address of the SDNP client must be dynamically changed in serial data packets. Each MAC address corresponds to a specific physical PHY layer, such as Ethernet 100BASE-T and 1000BASE-T connections. In the case of three physical media, the client's MAC address dynamically changes sequentially from MAC C _1.1 to MAC C _1.2 and then to MAC C _1.3 . If only two media are available, MAC addresses can be arbitrarily changed to avoid pattern recognition, such as MAC C _1.1 , MAC C _1.2 , MAC C _1.2 , MAC C _1.1 , MAC C _1.2 , MAC C _1,1 , MAC C _1,2 , MAC C _1,2 , MAC C _1,1 , MAC C _1,1 ... Although the source MAC address is different, L can remain constant, that is, the destination of the latter of these, MAC R. Since all LBL routes terminate in a single router, the data path through the remainder of the Last Mile remains fixed as a single communications route. In other words, although Last Line uses tiered physical connections, Last Mile enters the SDNP cloud through a single gateway, and Last Mile contains a single-route connection.

Although the layered physical connection approach provides some degree of masking, packet sniffing of data packets from a specific call can still be identified as they share a common client IP address. This discovery method is blocked by dynamic client addressing, an operation in which the client changes its IP address with every packet it sends. By way of example, FIG. 51B illustrates the use of dynamic client IP addressing in a single Last Mile communication path. The top set of data packets illustrates a single Last Line physical connection, while the bottom set of data packets describes the implementation of multiple physical PHY connections. In SDNP Last Mile single-route data transmission, the destination IP address of the gateway remains constant with a numerical value of IP M _0.0 in all data packets, regardless of whether single-route or multi-route PHY methods are used.

As shown in the figure, dynamic addressing client data packets with SDNP A payload use dynamically selected source IP address 441, including IP C _1,1 , and data packets with SDNP payload B use dynamically selected source IP address C _{1 , 2} , the SDNP payload data packets C use the dynamically selected source IP address C _1,3, and so on. The number of dynamically selected addresses is practically unlimited, especially in IPv6. In addition, IP addresses can be used for so long that after a while, for example 1 second, they can be reused. In the case of dynamic client addresses with Back-end sibling, the source MAC address 183 remains constant, in this example at MAC C _1,1 , even if the source IP address changes. In the case of dynamic client addresses with multiple Back-of-Line physical connections, the original MAC address 183 changes sequentially from MAC C _1.1 to MAC C _1.2 and then MAC C _1.3 . There is no special mathematical relationship between a client's changing MAC address and its dynamic IP address.

Although dynamic client addressing includes messages sent from different users, data packets still travel most of the Last Mile (with the exception of Last Line layered physical link implementations) along the same route. A more advanced way to solve the problem of eavesdropping on Last Mile connections is to use "multipath" communications. In multi-route communication, more than one SDNP gateway IP address is used to connect the client to the SDNP cloud. Since SDNP network routing is prescribed by signaling servers and uses SDNP identification tags on every packet, the SDNP cloud can route packets to their destination, regardless of whether the data enters the SDNP cloud through a single gateway or through multiple gateways. FIG. 51C illustrates the use of Last Mile multi-route communication with static client addressing. In each data packet shown in the last link, the client's 441 source IP remains static with an IP C value of _1.1 , and the sequential data packets containing SDNP payloads A, B and C dynamically change the 442 destination IP from IP M _0.0 to IP M _0.1 and IP M _0.3 . SDNP gateway IP addresses are not chosen randomly, but are "selected" by SDNP signaling servers to represent gateways that are temporarily close to the caller, i.e. gateways with minimal statistical propagation delay between an SDNP client and a specific SDNP gateway. In this example, the dynamic destination addresses change regardless of the physical connections in the PHY layer. For example, the top set of data packets illustrates a Last Line sibling with client source MAC address 183 for Last Line having a numerical MAC value of C _1.1 , and the bottom set of data packets describes the implementation of a Last Line multilayer by modifying Source MAC address on different media, such as MAC C _1.1 , MAC C _1.2, and MAC C _1.3 . There is no consistent pattern or mathematical relationship between changing client MAC addresses and destination IP addresses of SDNP gateways.

The most effective way to cheat is to combine dynamic client addressing with Last Mile multipathing. This new combination of safety functions is shown in FIG. 51D for both the Last Line sibling physical connection function (shown at the top of the figure) and the Last Line physical layered version of the physical connection (shown at the bottom of the figure). In this fully dynamic version shown in the bottom half, the source IP address 441 dynamically and randomly changes from IP C _1.1 to IP C _1.2 and to IP C _1.3 , with the destination IP address 442 of the SDNP gateway changes independently from IP M _0.0 , to IP M _0.1 and to IP M _0.3 . The SDNP gateway address is chosen by the SDNP signaling servers to minimize propagation delays when the dynamic client address is changed in another way. As in the previous examples, the top set of data packets illustrates a Last Link physical peer-to-peer connection with a client source MAC address of 183 for Last Link having a MAC C of _1.1 , and the bottom set of data packets describes the implementation of multiple PHY layers varying MAC is the source address on different media, for example MAC C _1,1 , MAC C _1,2 and MAC C _1,3 . There is no consistent pattern or mathematical relationship between a change in a client's MAC address and a change in a client's or SDNP gateway's IP addresses. However, with multi-route Last Mile links, a multi-tiered Last Line physical connection may be more beneficial when connected to three separate routers R1, R2, and R3 than to route all of the data to a single router R.

The Last Mile concealment as described above represents ten different cases shown in the table of FIG. 52A , starting with the least secure implementation (shown at the bottom of the table in line 10), which includes one Last Mile route with a static client address and one Last Line PHY for more advanced masking offered by the Last Line PHY layered with dynamic source addressing and Last Mile multi-route connection on top row 1. Intermediate combinations are ranked in order of safety. The symbols C _{1, n} , M _{0, n,} and R _n refer to dynamically changing addresses for SDNP clients, SDNP gateways, and Last Line Router. Dynamic addresses are uncorrelated. Lines 7 through 10 describe one Last Mile communication route, i.e. use a single gateway M _0,0 , while lines 1 through 6 describe the Last Mile multipath communication with multiple gateways. Except for shaded lines 1 and 4, the Back-of-the-Line link connects to a single router with MAC address R. In contrast to multi-path links, the shaded lines 1 and 4 describe a Back-to-Back PHY layered physical connection with multiple routers with dynamic MAC addresses R _n .

Topologically, the operation of the Last Mile single-route connection is shown in Fig. 52B in four combinations - static client addressing with a Last Line single-layer physical connection and static client addressing with a Last-Line multi-layer physical connection, dynamic client addressing with a Last-Line single-layer physical connection "and dynamic client addressing with a Layered Last Line physical connection. Each box illustrates three consecutive packet data paths showing the data path being used. Solid lines represent a packet stream of data, while dashed lines illustrate possible unused paths. Shaded circles illustrate sites used in a Last Mile link, empty circles illustrate unused sites As shown in the figure, all examples complete the routing of Last Mile data through a single link between Router R and a gateway m SDNP M _0.0 .

In the case of a static addressing client with the Last Line sibling physical connection shown in the upper left corner, each subsequent packet travels the same path throughout the Last Mile using unchanged IP addresses. In the case of static addressing of a client with a multi-tiered "Last Line" physical connection shown in the lower left corner, each subsequent packet travels a different path through the "Last Line", as dictated by the dynamically changing MAC addresses. The remainder of the Last Mile consists of a single route specified by unchanged IP addresses. Despite the single-route transmission, the changing physical environments of the Last Line make it difficult to track the caller. In the case of dynamic addressing of a client with a sibling physical connection of the "Last Line" shown in the upper right corner, each subsequent packet travels the same path along the entire "Last Mile" using the same destination IP address and the client's constant MAC address for the "Last Line" Lines ". Instead, masking is achieved by changing the client's identity by changing the dynamic source IP address. In the case of single-route communication with both dynamic client addressing and the Last Line physical tiered connection shown in the lower right corner, the client MAC address and source IP address change dynamically and randomly, even if all packets are directed to the same SDNP gateway.

Dynamic client addressing is the process by which a client device uses one or more temporary ad hoc IP addresses. The process consists of two stages. In the first step, when the device first logs on to the network, it registers its presence on the local subnet by communicating with the nearest router. The router then redirects the connection to the closest DHCP server on the same subnet. DHCP, short for Dynamic Host Configuration Protocol (DHCP), is a network management protocol used to dynamically assign IP addresses. During the registration process, the client device downloads one or more IP addresses and stores them in the communication data register. As long as the assigned IP addresses are not updated by the local DHCP server, either by starting a new session or by requesting new addresses, whenever a client device communicates, it uses those IP addresses. Since addresses are dynamically allocated within a specific subnet, client device IP addresses are not Internet addresses.

In the second step, when the client device makes a call or enters the SDNP network, the device automatically contacts the SDNP signaling server based on the static IP address of the SDNP server. After receiving an incoming message, the SDNP server uploads the special IP address or addresses to the SDNP name server. The SDNP name server then assigns SDNP addresses as pseudocode to each temporary IP address. During operation, before routing, the original SDNP address of the packet is replaced with the local ad hoc IP address. In the case of dynamic SDNP addressing, the identity of the client device is masked by sending multiple packets with changing source addresses. Thus, dynamic masking obscures the true identity of the client device.

When the SDNP gateway is reached, the source addresses for outgoing packets are discarded the client IP addresses and replaced with the SDNP address of the gateway server. Each outgoing SDNP packet changes the local IP address of the device to a special one before transportation. Unlike Internet packet transmission, where the source and destination IP addresses remain constant and are required for responses, SDNP transmission uses a new IP address for each hop. Therefore, when the SDNP message finally reaches its destination, the source address of the client device is not included in the data packet. Instead, the signaling server informs the receiving device of the path to return the responses.

Topologically, the operation of a "multipath" Last Mile connection is shown in FIG. 52C in four combinations of static and dynamic client addressing, as well as single and multi-level physical connections "Last Line". In each multi-route connection, the destination IP address, i.e. the SDNP gateway is constantly changing, which means that the Last Mile route connects to various entrances to the SDNP cloud. The left column displays static addresses of clients, i.e. the caller's identity remains unchanged. The example in the upper left corner is using the Last Line sibling physical connection, which means that the client's MAC address also remains static. Even though communication occurs with different destination gateways, the unchanging physical environment of the Last Line and the unchanging client IP address makes the Last Mile vulnerable to call tracking. This problem can be resolved either by changing the Last Line transmission medium used for transmitting data packets, or by masking the caller's true IP address.

The example in the lower left corner uses a "Last Line" multi-tiered physical connection, which means dynamically changing the client's MAC address. This approach compensates for the fact that the client's identity maintains a static IP address. In an end-to-end multi-route Last Mile communication, each unique Last Line connects to individual routers in sequential packet transfers to individual SDNP gateways. Thus, the first packet is routed from the client with static IP C _1,1 to the router with MAC address R ₁ through the unique PHY, and then forwarded to the SDNP gateway with IP address M _0,0 . A second packet of identical client IP C _1,1 address is directed to another router with MAC media address R ₂ through the unique PHY before being finally routed to the SDNP gateway with IP address M _0,1 . Likewise, the third packet with a static client IP address C _{1,1 is} also forwarded to the router with the media MAC R ₃ through the unique PHY where it is then routed to the SDNP M _0.3 gateway. The use of multiple routers allows for the use of a multi-tiered Last Line physical connection to deliver a Last Mile packet along completely different paths, despite using a client with a single source IP address.

In the other variation, shown in the upper right corner, the identity of the client is dynamically changed, even if only one MAC address and one PHY connection is used. The client's displayed IP address dynamically changes from IP C _1.1 to IP C _1.2 to IP C _1.3 , and the physical medium remains constant with the source MAC address C _1.1 and destination MAC address R. The data is then forwarded to the gateways M _0.0 , M _0.1 and M _0.3 in random order determined by SDNP signaling servers.

Advanced security is achieved by combining all three methods of Last Mile masking, namely multi-route communication with multi-layer Last Line physical connection and dynamic client addressing. This example is illustrated in the lower right corner of FIG. 52C , where data packets sent over the Last Line physical tiered link and multiple routers are delivered from a client with dynamic IP addresses to multiple SDNP gateways over multiple routes. As shown in the figure, the first packet from a client with a dynamic source network address IP C _{1,1 is} sent along multiple routes to IP M _0,0 using the "Back Line" physical connection defined by the source and destination media addresses of MAC C _{1, 1} and MAC R ₁ . The second data packet from a client having a dynamically selected source network address IP C _1,2 is sent along multiple routes to _{destination IP M 0,1} using the "Last Line" multi-layer physical connection, defined by the source and destination media addresses MAC C _{1, 2} and MAC R ₂ . Finally, the third packet of data from a client with a dynamically selected source network address IP C _1,3 is sent along several routes to IP M _0,3 using a multi-layer physical connection "Last Line" defined by the source and destination media addresses MAC C _{1 , 3} and MAC R ₃ . Thus, the combination of client IP, SDNP gateway IP, client MAC, and router MAC changes dynamically, making call tracking and metadata collection nearly impossible.

Client device IP masking and Last Mile routing shadowing with dynamic IP addressing, multi-layer physical linking, and multi-gateway multi-route can be defined by either the client device or the signaling server. The redirection process can be achieved through random number generation or other pseudo-random algorithms. The key principle is that changes in routing and transport are unpredictable.

Two slightly less reliable versions of Last Mile packet data transmission over Ethernet over multiple routes are shown in FIG. 52D , where the left side of the illustration uses a static client addressing and a Last Line physical tiered connection, and the right side of the illustration uses a dynamic client addressing, also a Last Line tiered physical connection. The difference between these versions and the layered physical connection versions shown in FIG. 52C , is that earlier these versions used a single router R, rather than spreading data transmission across multiple routers. In multi-route transmission using a single router for the "Last Line" connection, the serial data from the client is distributed over several physical transmission media, i.e. a Last Line physical layered connection occurs, then reassembled by one router R and sent along the rest of the Last Mile, including multiple gateways and any other parallel Last Mile stretches (not shown) from this common router to multiple distinct destination gateways SDNP.

As an addition to Ethernet, Wi-Fi wireless can also be used for Last Mile communication between an SDNP client and an SDNP gateway. Wi-Fi communication requires a data packet with three or four MAC addresses, two for radio communication, one or two for a wired network connection, especially using Ethernet data packets. FIG. 53 illustrates the same Wi-Fi packet format adapted for Last Mile and Last Line SDNP communications. As an access point for Last Line communication, only three 6B MAC addresses are required, namely MAC address 1 field 235 for the base station or "receiver", MAC address 2 field 236 for the base station or "transmitter" and MAC -address 3 field 237 for a wired network connection to a Wi-Fi router, i.e. Ethernet or "internet". During operation, the digital values of the MAC addresses loaded into the data fields of the receiver and transmitter depend on the setting of the K or OT direction of the distribution system (i) whether the data packet is transmitted via radio or Ethernet (ii) and whether the incoming data is converted over Ethernet into radio communication ... The data field MAC address 4,239 is optional, it is used only if the Wi-Fi device is used as a radio bridge in "wireless distribution mode". Although this mode can be used over long distances in Last Mile networks as an alternative to cellular or microwave networks, for example in the desert, in general, SDNP Last Mile Wi-Fi use is usually focused on the Last Mile connection. "to the SDNP client. In this regard, the following discussion will focus on hotspot mode for Wi-Fi routers with the understanding that SDNP techniques are equally applicable when routing in over-the-air distribution mode.

Like Ethernet data packets, preamble 230 and SFD start frame separator 232 contain first layer data for data and device synchronization. The PLCP 232 physical layer convergence procedure includes a combination of Layer 1 and Layer 2 information (corresponding packet length, baud rate, header error checking, etc.). In accordance with IEEE 802.11 standards, the remaining data fields contain information about the second layer of data transmission, including Frame Control 233, which specifies the type of packet of the Wi-Fi version as the type of control, control, reservation or "data" used to deliver payloads SDNP.

Duration and ID 234 contains the duration of the NAV (Network Allocation Vector), unless the Wi-Fi device is in power saving mode, in which case the field contains the radio station ID. NAV is a virtual carrier discovery mechanism used to save energy in wireless communication systems. The NAV duration can be thought of as a counter, counting down to zero at the same rate, after which it determines if the radio is idle or communicating. In standby mode, the counter counts the NAV duration many times, checking to see if any radio activity requiring attention is detected. The Sequence Control or Sequence field 238 describes the sequence of packets and the chunk number identifying the frame of the second layer packet. The frame check 240 contains the 32-bit CRC of the entire data packet, i. E. to check the data connection for errors.

Wi-Fi payload 241 is a 0B to 2312B data field used to carry a Wi-Fi payload. In the Last Mile SDNP message, this field contains the IP datagram used in the Last Mile connection, including IP header 434, transport header 436, and SDNP payload 435.

The IP header 434 changes depending on whether the IP datagram follows IPv4 or IPv6 as defined by the 447 protocol field containing binary 4 or the 448 protocol field containing binary 6. Preambles 440 and 444 contain transport header 470 used to determine which Layer 4 transport is used, such as TCP, UDP, or ICMP and IGMP service functions. In particular, according to the secure dynamic communication network and protocol, TCP transport is used to transfer software and data files, and UDP is used to transfer real-time data such as VoIP and video. The length and format of transport header 436 varies depending on transport flag 470. Header 434 contains source and destination IPv4 addresses 441 and 442 or source and destination IPv6 addresses 445 and 446.

Like Ethernet data packets, the routing of Last Mile Wi-Fi packets depends on both IP addresses and MAC addresses, symbolically represented by device names, to which IP or MAC addresses belong. Serial routing of Last Mile Wi-Fi packets is shown in the examples of FIG. 54A of FIG. 54D. Each shape contains two Wi-Fi packets — the top one containing an IPv4 datagram and the bottom one containing an IPv4 datagram. Since IPv4 and IPv6 use different formats with different field lengths, the two Wi-Fi packets shown tend to have different lengths even with the same payload.

In the first phase of data transfer, the SDNP-A payload moves from the SDNP client 1400 to the base station / router 1402W via the Last Line 1404 as the Wi-Fi radio medium and over the wired line to the router 1402X on the BS 1415 channel. Then the router 1402X transmits a data packet over gateway 1414 to SDNP gateway 1401. Response from SDNP gateway to client includes SDNP payload G from gateway 1401 over wired link 1414 to router 1402X, over BL link 1415 to Wi-Fi router 1402W, and through Last Line 1404 to client 1400 using a Wi-Fi router as a communication medium. SDNP client has numeric MAC and IP addresses MAC C _1.1 and IP C _1.1 , 1402W Wi-Fi router has numeric MAC address MAC W, 1402A router has numeric MAC address MAC R, SDNP gateway has numeric MAC and IP - MAC addresses M _0.0 and IP M _0.0 . The IP addresses of the 1402W Wi-Fi router and 1402X wired router are not required in the display in this figure.

Unlike the SDNP cloud, where SDNP datagram packet routing is completely controlled by the SDNP network, in Last Mile networks using IP datagrams, the SDNP payload cannot be interpreted or influenced by routing, that is, every connection carried over the Last Mile "contains fixed source and destination IP addresses. The physical media or channels used to route Wi-Fi packets over radio and to route Ethernet packets over wired connections are controlled by MAC addresses that connect each site in the Last Mile.

For example, in FIG. 54A shows the Wi-Fi Back-end IPv4 and IPv6 packets used for single-layer routing of the PHY radio to Wi-Fi router 1402W through the 1404 Back-end MAC address C _1,1 MAC address and destination MAC address MAC W The 1402W Wi-Fi router also provides a BS wired line 1415 to the 1402X router with a clean destination MAC address R. The Layer 3 network includes only end devices; SDNP 1400 client with source IP C _1,1 and SDNP 1401 gateway with destination IP M _0,0 . Unlike an Ethernet data packet, a Wi-Fi packet contains three addresses - the MAC address of the transmitter or radio source MAC C _1,1 , the MAC address of the receiver or radio destination, the MAC address W, and the Ethernet MAC address "net". In this direction of data transfer, the 1402X router acts as the network destination of the Wi-Fi router device. Thus, the Wi-Fi data packet defines two transmission media, the Last Line Wi-Fi router 1404 and the BS Ethernet wired channel 1415. FIG. 54B illustrates corresponding Ethernet packets carrying SDNP A payload over gateway link 1414. As described above, the source and destination IP addresses remain unchanged as IP C _1,1 and IP M _0,0 , while the source and destination MAC addresses the assignments are changed from the original values to MAC R and MAC M _0,0 .

Communication in response involves changing the destination and source IP addresses and setting the MAC addresses accordingly. FIG. 54C illustrates Ethernet IPv4 and IPv6 packets for data transfer from SDNP gateway 1401 to wired router 1402X over gateway 1414. To obtain information about the third layer datagram, the source IP address 441 contains the network address of SDNP gateway 1401, i.e. IP M _0.0 , and the destination IP contains the value IP C _1.1 , the client's address. The MAC addresses for the gateway Ethernet packet are MAC M _0.0 for the source address 183 and MAC R for the destination MAC address 182.

FIG. 54D illustrates IPv4 and IPv6 Wi-Fi packets for wireless BS connections 1415 and last-line Wi-Fi radios 1404. Network layer 3 routing includes SDNP gateway 1401 IP address M _0,0 and SDNP client IP C _{1. 1} as source and destination addresses 445 and 446. The function of the MAC address field 237 marked "net" changes according to the radio mode. In the transmission mode shown here, this field contains the Ethernet MAC address of the source of incoming data to the radio, i.e. the numeric value of the MAC R of the 1402X router sending data packets to the Wi-Fi access point. In the receiver mode shown previously in FIG. 54A , this field defines the destination of the Ethernet data received as radio packets and converted to Ethernet packets. In the example shown, the "net" field 237 contains the same MAC address for router 1402X; MAC R, for transmit and receive mode, which means the Wi-Fi hotspot uses one Ethernet router for the Last Mile connection.

In Last Mile multi-route communication, a wired router is used to route the data packets received by the Wi-Fi access point, ie. in receive mode, may differ from that used to route data packets transmitted by the Wi-Fi access point, i.e. in data transfer mode. For example, the network MAC address 237 for radio transmissions in receiver mode may have a digital MAC address MAC R ₁ in transmit mode, the data may be changed to another MAC R ₂ , i. E. the BS channel can optionally comprise a direction-dependent multifunctional system. In transmission mode, Wi-Fi Last Line packets used for single-channel radio 1404 Last Line routing from Wi-Fi router 1402W to SDNP 1400 client contain the MAC address 236 of the transmitter with the numerical value MAC W and the MAC address of the receiver 235. containing the numerical value MAC C _1,1 . In this direction of data transmission, the wired router 1402A acts as the source of the data transmitted by the Wi-Fi router device. Thus, the Wi-Fi data packet combines the two media, the Last Line Wi-Fi radio 1404 and the Ethernet wired BS line 1415.

Cellular networks are another form of wireless communication that is adaptable for Last Mile SDNP communication. Cellular networks redistribute incoming Ethernet packets to Radio-Control Media Access Control (MAC) packets. Data can be transmitted and received by time division multiplexing (TDMA), code division (CDMA), or by spreading content over multiple subchannel frequencies (OFDM). In the case of 4G / LTE communication based on OFDM or orthogonal frequency multiplexing, the second layer data packets are stacked between three different layers of embedded service data units or SDUs within the second layer; the lowest layer includes a PHY PDU 299 containing a single-frame MAC SDU 304 along with a MAC header 303 and padding 305 distributed over 20 time slots 300, which includes the next MAC SDU 304, which in turn contains a radio link control function, or RLC SDU 308.

Radio Link Control (RLC) is a Layer 2 protocol used in 3G (UMTS) and 4G / LTE (OFDM) telephony. The radio channel control function consists in responding to high-level requests in one of three modes, i.e. acknowledgment mode, non-recognition mode, and transparency mode, as well as error detection, error correction, duplicate detection, and data batching in accordance with specified formats. Data packetization includes concatenation, segmentation, and reassembly of RLC SDUs, and sequencing and re-segmentation of RLC data PDUs. For example, after allocating time to perform radio transmissions, the one-frame RLC SDU 308 is inevitably limited by the length and size of the data file available for the transmission of the payload. The one-frame RLC SDU 308 must be segmented and displayed in a different second RLC layer format, the multi-frame RLC SDU 319.

As shown in FIG. 55 , the mapping of a single-frame RLC SDU 308 to various segments K, K + 1, K + 2 313, 314, 315, and other multi-frame RLC SDUs 319 does not occur on a one-to-one basis. As shown in the example, the mapping of the one-frame RLC SDU 308 ends in the middle of the K + 2315 segment. The portion of the remaining K + 1 segment that has not been transmitted is transmitted in a new one-frame RLC SDU 312, but only taking into account the offset time 310 required for synchronization clock radio and 311 RLC header processing. In this method, the transmission of data encapsulated in slot K + 2 resumes exactly where it was interrupted, as if the data flow had not been interrupted. The 4G function is similar to pausing a DVD encoded movie in the middle of a DVD section, waiting for a moment to perform some other functions, and then resuming playback exactly where it was paused. In this way, no data content is lost and the data rate on the cellular network is maximized without wasting radio throughput, excluding packet throughput (e.g., PDU headers), and minimizing data rate degradation as a result of the addition of synchronization time 310.

Multi-frame RLC SDUs 319 encapsulate PDCP PDUs 320 in one-to-one correspondence with each K segment.For example, Kth segment 313 carries PDCP header 321A and IP payload 323, (K + 1) th segment 314 carries PDCP- header 321B and IP payload 324, (K + 2) th segment 315 carries PDCP header 321C and IP payload 325, etc. The term PDCP is an abbreviation of the Packet Data Convergence Protocol, as defined in the 3G and 4G / LTE communication protocol, which performs functions such as compression, encryption, integrity, and control over the transmission of user data. PDCP headers differ depending on the type of data being transmitted, such as user data, control data, etc.

Since the data transmission in 4G data packets has a continuously combined data stream, the payload size is not quantized into blocks of a certain length, as in Ethernet and Wi-Fi data packets. Instead, the data fields 323, 324, 325 ... carried by the corresponding second layer data segments 313, 314, 315 ... can gradually support any size payload, as shown in the figure, including IP header 434 and IP header 435 containing the transport load 436 and SDNP 1430. Moreover, in OFDM communication, each time a slot simultaneously transmits data on several frequency subcarriers, this means that the total data throughput is determined not only by the length of time on one channel, as it happens in TDMA. However, for convenience, it is often convenient to maintain the size of the IP datagram in accordance with Ethernet or Wi-Fi standards.

As shown in the figure, header 434 changes depending on whether the IP datagram follows IPv4 or IPv6, as defined by protocol field 447, which includes binary 4, or protocol 448, which includes binary 6. Preambles 440 and 444 contain transport header 470. used to determine which Layer 4 transport is used, such as TCP, UDP, or ICMP and IGMP service functions. In particular, according to the Secure Dynamic Network and Protocol, TCP transport is used to transfer software and data files, while UDP is used to transfer real-time data such as VoIP and video. The length and format of transport header 436 varies depending on bit 470 of the transport header. Header 434 contains the source and destination IPv4 addresses 441 and 442, or the source and destination IPv6 addresses 445 and 446.

As an example of 4G communication using IPv6 datagrams, FIG. 56A illustrates Last Line cellular radio 1404 routing to cell tower and base station 1402Q. Specifically, in the source field of the MAC address 300A, the RLC PDU defines the source address of the cellular data as MAC C _1,1 , client device. Similarly, the MAC address assignment field 300B defines the cellular receiver media address as a MAC BS describing the cell tower and base station. Layer 3 network routing includes only Last Mile endpoints; SDNP 1400 client with source IP C _1,1 and SDNP 1401 gateway with destination IP M _0,0 . As described above, data fields 323, 324, and 325 do not necessarily correspond to specific data sections of an IPv6 datagram, where data field 323 includes the source IP address 445, the destination IP address 446, and a portion of the SDNP A 435 payload, including transport header 436. Fields Data 324 and 325 contain the remainder of the SDNP 435 payload that was not transmitted.

FIG. 56B illustrates data packets for payload G of an SDNP response message over a Cellular Back-end 1404 connection from cell tower and base station 1402Q to mobile client device 1400, where the source and destination addresses from the previous data packets have been replaced, namely the source address of the cellular communication 300A comes with the BS media MAC address as the load, 300B the cellular destination address is set in the MAC C _1,1 field, the IP address of the client's MAC address in the IP _0,0 field, the data source MAC address is set in the M6 field. Routing between network router 1402X and cell tower and base station 1402Q over BS 1415 uses Ethernet data packets as in the previous examples.

A Back-to-Back Layered Physical Connection may include any of the aforementioned media used in various combinations. Layer implementations can include multiple wired connections that carry data at the same or different baud rates and use common or different Layer 2 protocols such as USB, Ethernet 10BASE-T, 100BASE-T, 1000BASE-T, or DOCSIS3. Physical media can include standardized Ethernet or USB network cables, coaxial cables, fiber optic connections, or even DSL twisted-pair copper connections, albeit at reduced performance levels.

Wireless multi-layer physical connection can include combinations of Wi-Fi, cellular, satellite, or proprietary radio formats operating in RF and microwave frequencies. Last Line wireless may also include short-range technologies such as Bluetooth or microcellular networks such as PHS in Japan. Wireless protocols can include 2G, 2.5G, 3G, and 4G / LTE cellular formats including, for example, analog, TDMA, GSM, CDMA, UMTS and OFDM, 802.11a, 802.11b, 802.11g, 802.11n, and 802.11 Wi-Fi protocols n, as well as proprietary satellite communication formats or special radio channels. Since Layer 2 protocols differ depending on the physical environment of Layer 1, the term "multi-layer interworking" as used in the context of this specification means a combination of OSI physical and link layers, i.e. levels 1 and 2, and should not be construed solely as limiting the requirements for physical environments of level 1.

Examples of multichannel high-speed communication using a common layer 2 protocol are shown in FIG. 57A including Ethernet, Wi-Fi and cellular implementation. In the topmost example of a layered physical Ethernet connection, router 27 communicates with personal computer 36 using two Ethernet cables consisting of 24A and 24B wired or fiber optic lines operating over 100BASE-T and 1000BASE-T, respectively. To enable hypersecure communication over the Last Mile, the figure shows a laptop 36 running SDNP 1335C software.

In the central part of the figure there is a multi-level Wi-Fi connection, Wi-Fi router 100 communicates with laptop 35 through two Wi-Fi channels, shown as Wi-Fi connections 29A and 29B, the first one operates on the 801.11n protocol at 2.4 GHz, and the second uses 802.11ac for 5GHz band communications. To operate in tiered mode, the Notebook 35 must be turned on to transmit and receive signals simultaneously on multiple frequencies using the 26B multi-band antenna built into the Notebook PC. Likewise, a Wi-Fi router must be able to transmit and receive signals on multiple frequencies simultaneously using multi-band antennas 26. To enable hypersecure Last Mile communication, the figure depicts a laptop 35 running SDNP 1335C software.

In the lower part of the figure showing multiband cellular communications, base station 17 simultaneously communicates via multiband cellular tower 18A to tablet 39 using two different radio channels consisting of cellular lines 28A and 28B with respective frequencies of 1.8 GHz and 900 MHz. In the example shown, cellular is a 4G / LTE network. As shown in the figure, the tablet 39 must be turned on to simultaneously transmit and receive signals on multiple frequencies using the internal multi-band antenna 18B. To enable hypersecure communication over the Last Mile, the figure depicts a laptop 35 with the SDNP 1335A application installed.

This multi-layered interaction using a common Layer 2 protocol is confusing for cyber attackers, as the attacker must gain physical access to two different Layer 2 data links, each of which can include its own security. In addition, if the client is using SDNP 1335C software, SDNP application 1335A, or SDNP firmware 1335B (not shown), routing the SDNP payload over the tiered connection uses unique dynamic security credentials, making it too difficult to intercept and interpret SDNP packets to be cracked in real life. time.

Examples of layered data transmission using mixed Layer 2 and Layer 2 protocols are shown in FIG. 57B . In these examples, Last Line data is transmitted using combinations of cellular, Wi-Fi, and satellite systems. In the upper example of a mixed multi-RF communication, Wi-Fi router 100 communicates with personal computer 36 using a combination of a wired or fiber 100BASE-T Ethernet 24B connection and an 802.11ac 29B Wi-Fi link operating at 5 GHz. To ensure hyper-secure communication through the Last Mile, the figure depicts a personal computer 36 with SDNP 1335C software installed. Such an example is a combination of wired and wireless communications where capturing wireless packets does not allow capturing or viewing wireline data. This mixed Ethernet + multiband Wi-Fi last mile distribution is particularly well suited for deploying corporate office networks of secure PCs in a building or campus that communicate with closed servers in closed, restricted areas.

In the middle mixed layered connection diagram shown in FIG. 57B , a cell phone 32 with an internal multiband antenna 18C communicates using two different wireless technologies. One Wi-Fi connection 29C connects to Wi-Fi router 100 and antenna 26 using, for example, the 802.11n protocol at 5GHz. The second connection, Cellular 28C, uses a 1.8 GHz 4G / LTE operator to provide Last Line connectivity to Cell Tower 25 and Base Station 17. Since Cell Tower 25 and Wi-Fi Antennas 26 operate on unrelated systems, this approach to layering completely obscures any connections between packets of data transmitted by multiple physical media on the "Last Line". To provide hyper-secure communications over the Last Mile, the figure depicts a mobile phone 32 with the SDNP 1335A application installed.

A similar method of achieving multi-layer connection in the "Last Line", combining cellular and satellite communications, is shown in the lower illustration of FIG. 57B , where satellite / cell phone 32Z is running the SDNP 1335A application and communicates over two long-distance networks - cellular 28D with cell tower 25 and base station 17 at 1.8 GHz and satellite communication 95W with satellite 92, for example 1, 9 GHz. Satellite 92, in turn, communicates with the terrestrial satellite antenna and base station 92B over broadband communication channel 95X, not necessarily on the same frequency as the client communication.

FIG. 57C illustrates yet another form of multichannel high-frequency communication - multiple physical environments using common protocols, but capable of simultaneously using multiple frequency division links. Such a system requires a high throughput of the environment in order to operate without heavy loads, i.e. where performance degrades as more users consume bandwidth and media bandwidth. Only three such media are readily available with such high bandwidth, namely: i) DOCSIS3 cabling systems using coaxial cable; ii) DOCSIS 3 cable systems using optical fiber; and iii) satellite-based communications systems with a frequency of several GHz in low Earth orbits. Specifically, the topmost illustration of a multiband cabling system shows a 102B set-top box or cable modem with SDNP 1335M firmware connecting to CMTS 101 cable over multiple bands over coaxial or fiber 105 using DOCSIS3 protocol.

The lower diagram shows a satellite network with multiple connections in which a 32Z cell phone with SDNP 1335A installed communicates with communication satellite 92 using multiple 95Z carrier frequencies formatted with a proprietary communication protocol. Communication between satellite 92 and the terrestrial satellite antenna and base station 92B uses the 95X trunk protocol mixing thousands of calls, making identification and interception of a specific call problematic for a hacker, and the use of multi-channel multi-band communication provides hyper-secure line communication for the 95Z client.

Another example of data packets used in the routing of the Last Line layered connection is shown in FIG. 58 , where the SDNP 1400 client communicates with the 1402A router over two separate connections that include 24A and 24B Ethernet wired or fiber links such as 100BASE-T and 1000BASE-T, respectively. Router 1402A, in turn, connects to SDNP Gateway 1401 over link 1414. Both Ethernet packets identify the source IP address 445, i.e. client device as IP C _1,1 and the destination IP address 446 of the SDNP gateway as IP M _0,0 . Ethernet packet A, carried over the network over wired or fiber optic line 24A, includes a destination MAC address 182 including MAC R and a source MAC address 183 including MAC C _1,1 . Ethernet packet B, carried over a connection implemented over wired or fiber optic line 24B, includes a destination MAC address 182 containing a MAC R and another source MAC address 183 containing a MAC C _1,2 specifying an alternate connection.

Changing the source media address from MAC C _1.1 to MAC C _1.2 redirects the Ethernet communication packet from 2.6 GHz 100BASE-T to 1000BASE-T connection. In operation, data packets from the SDNP 1400 client device are fragmented and then distributed to the SDNP A and SDNP B payloads according to SDNP algorithms and shared secrets. Fragmented data transmission over the "Last Line" of the multilayer connection occurs with the SDNP A payload carried over the Ethernet packet A over the 24A wired or fiber link and the SDNP B payload carried over the Ethernet B packet over the 24B wire or fiber link.

Another example of data packets used in the routing of the Last Line layered connection is shown in FIG. 59 , where the SDNP 1400 client communicates with the 1402W Wi-Fi router over two separate connections containing Wi-Fi connections 29A and 29B, using, for example, 802.11n at 2.4GHz and 802.11ac at 5GHz, respectively. Router 1402W, in turn, connects to router 1402X via BS 1415, and router 1402X connects to SDNP 1401 gateway via gateway 1414. Both Wi-Fi packets determine the source IP address 445, i.e. client device as IP C _1,1 and the destination IP address 446 of the SDNP gateway as IP M _0,0 . Wi-Fi A packet routed over Wi-Fi 29A includes the MAC address of the radio source 236, including MAC C _1,1 , the MAC address of the radio receiver 235 and the MAC address of the receiver 235, the MAC address of the network destination 237, MAC -recipient address 237, Wi-Fi MAC address, packet B routed over Wi-Fi 29B includes the recipient MAC address 2.236, radio signal receiver MAC address 2.

Changing the source media address from MAC C _1.1 to MAC C _1.2 redirects the transmission from the 2.6 GHz Wi-Fi radio to the 5 GHz transceiver. In operation, data packets from the SDNP 1400 client device are fragmented and then distributed to the SDNP A and SDNP B payloads according to SDNP algorithms and shared secrets. Fragmented data transmission over the Layered Last Line connection occurs with SDNP A payload transmitted over Wi-Fi channel 29A by packet A, and SDNP B payload transmitted over Wi-Fi packet B over Wi-Fi channel 29B.

Another example of data packets used in the routing of the Back-to-Back PHY Layer is shown in FIG. 60 , where the SDNP 1400 client interacts with the 1402Q cell tower over two separate PHY connections involving cell lines 28A and 28B using, for example, 4G / LTE at 1.8 GHz and 4G / LTE at 900 MHz, respectively. Router 1402Q, in turn, connects to router 1402X over BS 1415, and router 1402X connects to SDNP 1401 over gateway 1414. Both cellular radios determine the source IP address 445, i.e. client device as IP C _1,1 and the destination IP address 446 of the SDNP gateway as IP M _0,0 . Cell packet A, which is routed over the PHY connection implemented over cellular link 28A, includes source MAC addresses 300A, including MAC C _1,1 , and destination MAC addresses 300B containing the BS MAC. Cell packet B, which is routed over the PHY connection implemented over cellular link 28B, includes a transmitter MAC address 300A including MAC C _1,2 and a recipient MAC address 300B including a BS MAC.

Changing the source media address from MAC C _1.1 to MAC C _1.2 redirects transmission from the 1.8GHz 4G / LTE cellular radio to 900MHz. In operation, data packets from the SDNP 1400 client device are fragmented and then distributed to the SDNP A and SDNP B payloads according to SDNP algorithms and shared secrets. Fragmented data transmission over the Layered Last Line PHY connection occurs with the SDNP A payload carried by Cell A over Wi-Fi channel 28A, and SDNP payload B carried by Cell B over Wi-Fi channel 28B.

As described above, PHY layered communication can also include various communication media. In such cases, the data packet for each connection must be formatted according to the Layer 2 protocols for the respective physical media. For example, in FIG. Figure 61 shows a hybrid last-line connection involving Ethernet and Wi-Fi, in which the SDNP 1400 client communicates with the 1402W Wi-Fi router via two separate PHY connections, including a wired or fiber-optic Ethernet 24A and Wi-Fi 29B link using, for example, 100BASE-T and 802.11ac at 5GHz, respectively. Router 1402W, in turn, connects to router 1402X over BS 1415, and router 1402X connects to SDNP 1401 gateway over gateway 1414. Both Wi-Fi packets determine the source IP address 445, i.e. client device as IP C _1,1 and the destination IP address 446 of the SDNP gateway as IP M _0,0 . Ethernet routing over a PHY link over wired or fiber 24A includes a source MAC address 183 including MAC address C _1,1 and destination MAC address 182 including MAC address W. Wi-Fi packet B, the PHY connection carried over Wi-Fi line 29B includes a source MAC address 236 including a C _1,2 MAC address, a 235 MAC address including a W MAC address, and a destination MAC address 237.

Changing the source media address from MAC C _1.1 to MAC C _1.2 redirects the transmission from Ethernet to Wi-Fi. In operation, data packets from the SDNP 1400 client device are fragmented and then distributed to the SDNP A and SDNP B payloads according to SDNP algorithms and shared secrets. Fragmented data transmission over a Layered Last Line PHY connection occurs with SDNP A payload over Ethernet A packet over a 24A wired or fiber connection and SDNP payload B over Wi-Fi over Wi-Fi packet B over Wi-Fi 29B.

FIG. 62 illustrates a hybrid "Last Line" connection involving Wi-Fi and cellular, where the SDNP 1400 client interacts with more than two separate PHY connections to two different wireless base stations, namely a 29A Wi-Fi connection with a Wi-Fi router. The 1402W operates on 802.11n 2.4GHz and 28B with a cellular base station 1402Q operates on 4G / LTE over 900MHz. Routers 1402W and 1402Q, in turn, connect to router 1402X over BS channel 1415A and 1415B, respectively, and router 1402X connects to SDNP gateway 1401 through gateway 1414. Both Wi-Fi and 4G cellular packets determine the source IP address 445. those. client device as IP C _1,1 and the IP address of the SDNP gateway receiver 446 as IP M _0,0 . The Wi-Fi A packet that is routed over the PHY connection implemented over Wi-Fi line 29A includes the MAC address of the radio transmitter 236, including the MAC address C _1,1 , the MAC address of the radio 235 including MAC W, and the MAC -source network address 237, including MAC R. Cell station B, which is PHY-routed, implemented over Wi-Fi line 29B, includes a source MAC address 300B, including a MAC address C _1,2 and a MAC address of a receiver 330B including BS MAC address.

Changing the source media address from MAC C _1.1 to MAC C _1.2 redirects data transfer from the Wi-Fi LAN network to the cellular network. In operation, data packets from the SDNP 1400 client device are fragmented and then distributed to the SDNP A and SDNP B payloads according to SDNP algorithms and shared secrets. Fragmented data transmission over the Last Line PHY layered connection occurs with SDNP A payload transmitted over Wi-Fi packet A over Wi-Fi channel 29A, and payload B transmitted over cellular packet B over cellular channel 28B.

Another form of PHY layering involves physical communication media capable of supporting multiple channels at different frequencies and using different protocols for different data packets. This implementation can be simplified with a DOCSIS3 based cable distribution system running SDNP software. The OSI communication stack for the SDNP-compliant DOCSIS3 cabling system is shown in FIG. 63 , including the Layer 1 PHY connection, Layer 2 data link and Layer 3 network for both the CMTS 101 cable modem terminator and the CM 103 cable modem or STB 102 video converter. In particular, the CMTS 101 cable modem terminator and an associated stack 378 comprises a layer 1 network interface 361 connected to cloud servers 22 and the Internet 20, or optionally to a cable headend, IPTV system, or VoIP system (not shown). The combination of network interface 361 and link layer 366 is included in the communication stack 378 of the terminal device interface of the CMTS 101 cable modems. On the second link, data is transferred from the network interface communication stack to the network cable interface communication stack through the forwarding function 370, namely to the communication layer controller LLC 369. 802.2 Level Control LLC 369 is a device-independent protocol defined in accordance with the IEEE 802.2 specification. The packet data is then modified by a security function 368 to provide basic packet security, primarily to prevent unauthorized viewing of content such as pay-per-view broadcasts.

The Layer 1 362 PHY cable interface then sends data frames over the distribution network 102 containing coax 104 or fiber 91 to the corresponding Layer 1 363 PHY cable interface in the CM 103 cable modem or STB 102 video converter. The 363 cable interface is the physical layer of the cable network interface, shown as the OSI 379 communication stack of the CM 103 cable modem or the STB 102 video converter. Upon receipt of the data packet, the cable MAC interface 371 interprets the cable MAC addresses, transmitting its payload to secure the connection 372 for decryption and ultimately resulting in hardware independent link layer control 802.2 LLC 373 for interpretation. The input data of the CM or STB cabling stack is then passed through transparent bridging 374 to the device CM or STB interface stack, namely the device's independent 802.2 LLC 375 link layer control in accordance with the IEEE 802.2 specification. The packet is then sent to either HSD & IPTV MAC block 376 or Wi-Fi 802.11 MAC block 377 to update the MAC addresses of the packet. In the case of Wi-Fi communication, the data packet is transmitted from the block 377 of the 802.11 MAC address to the Wi-Fi radio interface of the physical layer 1 365 for transmission to the Wi-Fi antenna 26. In the case of wired connections, the data packet is then transmitted from the MAC address of the HSD and IPTV block 376 to an Ethernet or HDMI 364 interface block for connection to a TV 39 or a personal computer 36.

The physical and link layers, as described above, establish connections between a CMTS cable modem end system and any number of CMs cable modems. In the CMTS 378 and CM 379 communication stacks, data packets are provisioned at layer 3 OSI 360A and 360B, respectively, as IPv4, IPv6, or ICMPv6 IP datagrams using IP addresses recognized by the cabling or DNS servers. For Last Mile, SDNP data packets using IPv4 or IPv6 data packets with SDNP source and destination IP addresses are typically not used because attached devices not supported by SDNP software or firmware have no way of interpreting SDNP data routing addresses.

Transport Layer 4 operation on a cable modem network is device-specific. In the case of CMTS 101, Transport Layer 4 of Layer 1420 of the OSI Communication Stack 378 exclusively uses UDP as its operation requires real-time communications such as video streaming. From this point of view, cable 102 is more like a real-time SDNP network than the Internet. Since the cable modem has interoperability with both the Internet and the cable network as a client, i.e. end communication device, transport layer 4 layer 1420B in the communication stack 379 OSI CM 103 or video converter STB 102 uses UDP for real-time operations and uses TCP for internet data. This use is problematic for OTT operators using VoIP telephony, as the cable network will interpret IP datagrams as data, automatically using TCP and the transport protocol and degrading the quality of service and propagation delay of real-time communications. This issue does not occur with SDNP-enabled cable modems - where the CM or STB is running SDNP firmware or software, the SDNP software contextually determines when TCP is warranted (for software and files) and when not. those. for real-time data.

Application layers, namely OSI layers 5 through 7, are located at the top layer of transport operations 1420A in CMTS 101 and 1420B in CM 103 or STB 102. In CMTS 101, these applications are usually associated with communication tasks such as SNMP 1431A, the standard Internet protocol to collect and organize information about connected devices in IP networks. Other features include DHCPv4 1432A and DHCPv6 1433A. DHCP, an abbreviation for Dynamic Host Configuration Protocol, is a protocol for clients and servers that automatically provides an IP host with the necessary routing information, including a dynamically generated (non-static) IP address, default gateway, and subnet mask. Although the generation on the Internet is generation specific, i.e. for IPv4 or IPv6, the dynamic IP address generation function like NAT or SNMP gateway is generic and equally applicable in DOCSIS3 cabling for CMTS 101 and CM 103 or STB 102.

The application layer implementation of the secure dynamic communications network and protocol described here, implemented as SDNP 1430A firmware running on top of the CMTS 101 operating system, can perform any number of unique tasks, including:

Pass-through operation without interpreting the SDNP 1430 payload, in which case CM 103 must be enabled to open and read the SDNP payload, i.e. CM 103 must be an SDNP client.

Work as a remote SDNP Last Mile gateway, ie. interpreting the content of the SDNP payload and converting the content into a DOCSIS3 custom message (including link security) for transmission to CM 103. In such cases, CM 103 does not require the use of SDNP client software or firmware.

Acts as SDNP Last Mile Bridge, converts IP datagrams to SDNP datagrams and transfers SDNP data to CM 103. In such cases, CM 103 must work with SDNP client software or firmware to connect to SDNP Bridge, ie. to form a special "floating" SDNP network.

As shown in the figure, the OSI 379 communication stack for CM 103 and STB 102 includes a variety of applications classified as OSI Layer 5 through Layer 7, including the aforementioned SNMP 1431B, DHCPv4 1432B, and DHCPv6 1433B applications. Another feature, the TFTP 1434B utility or "trivial file transfer protocol" is primarily used in DOCSIS3 as a means to download software and software updates from the CMTS to cable modems and video converters throughout the cable network. On cable networks, HTTP 1435B, or Hypertext Transfer Protocol, is primarily intended for rendering dynamic menus used in smart TVs. Other applications (denoted by the "Otr" abbreviation 1436B) include gaming applications, diagnostics, IPTV applications, video recording functions, and more. SDNP 1430B firmware running on CM 103 or STB 102 is expandable - Hyper Protected Last Mile provides user and Last Mile communication whether the CMTS 101 is using SDNP software or not.

FIG. 64 illustrates the construction of a DOCSIS3 data packet adapted for delivery of SDNP payload 1430. As shown in the figure, layer 1 includes a physical medium device frame 390 of variable length and duration containing MAC address data of the second layer, including preamble 391, variable payload lengths or codewords 392 and a time window 393. Depending on the direction of communication, the preamble 391 contains either an upward preamble or a downward preamble. In the case of the uplink preamble, the preamble 391 contains a physical medium device PMD 398, a MAC header 399A, and PDU data 400A. In the case of a downstream preamble, preamble 391 contains an MPEG header 401, a MAC header 399B, and PDU data 400B. Both the PDU data 400A in the upstream preamble and the data PDU 400B in the downstream preamble contain a destination MAC address (DA) 403B and a source MAC address (SA) 403A. Variable length payload content 392 may include short codeword 394 or long codeword 397.

Short codeword 394 contains payload 395A including data A and error correction 396A containing FEC A. In the case of long codeword 397, the payload is divided into multiple blocks 395A, 395B, and 395C with data A, B, and C, respectively, with each payload the load contains its own error checking blocks 396A, 396B and 396C, including the corresponding data FEC A, FEC B and FEC C, respectively. After error checking, the DOCSIS3 data includes data blocks 395A, 395B and 395C in the case of a long codeword, and only data block 395A in the case of a short codeword. The combination of data A, B, and C is combined into a contiguous IP datagram, in this example an IPv6 datagram containing source IP 445, destination IP 446 and data field 435 with SDNP payload 1430 and transport header 436 with Layer 4 data. Thus, DOCSIS3 transfers data flexibly over the cable network using the packet-switched data protocol.

As shown in FIG. 65A , data packets are transmitted over multiple channels over a hybrid fiber optic cable network, i.e. at different frequencies. In DOCSIS 3.0, data channels range from 5 MHz to 1002 MHz, including analog TV signals 1440 (triangles), QAM data 1441, and a 1443 control channel diplexer. In the first phase of DOCSIS3.1, the frequency range is extended to 1218 MHz, and DOCSIS3 is added .1 data channels 1442 to facilitate OFDM modulation, mainly in bandwidth above existing channels dedicated to QAM.

OFDM is preferred over QAM modulation techniques because the channels can be more densely spaced on top of each other. Comparing modulation schemes, the QAM 1445A frequency distribution has a wider spectral content spread than the 1445B OFDM frequency distribution. In particular, the spectral sideband width is from f ₀ to f _-50 , i. E. the width from the edge of the carrier to the frequency where the signal falls by -50 dB is 4.3 normalized frequency units in the 1445A QAM frequency distribution, and in the case of the 1445B OFDM frequency distribution, only 0.4 normalized frequency units. Since the spectral width is smaller, more communication channels can be packed into one spectrum, which increases the total bandwidth and the maximum total data transfer rate on the network. In the second phase of the DOCSIS 3.1 deployment, the frequency range is extended to 1794 MHz. Many of the bands originally assigned for QAM data 1441 are being replaced by new channels assigned specifically for OFDM data 1442.

On a DOCSIS-enabled cable network, one CMTS supports multiple CMs that manage the available channels. Although the CMTS can dynamically allocate inbound communications and channel selection, uplink communications require contention resolution as needed to alleviate the situation when multiple CMs try to send data at the same time. Therefore, each modem must request an uplink from the CMTS before sending data. This process is shown in FIG. 65B and includes a communication flow between CMTS 101 running SDNP application 1335L and CM 103 running SDNP 1335M firmware. IP datagram routing in a multifunctional network uses IP CMTS and IP CM1 IP addresses and multiple MAC addresses such as MAC CM1 for CM 103 and MAC CMTS1, MAC CMTS2, MAC CMTS3 and CMTS4 MAC for CMTS 101. In the topmost figure showing a frequency versus time plot, the CM 103 is requesting to transmit the RQST 1445A signal on a dedicated channel.

When no response is received, a second RQST 1445B is sent, causing the CMTS 101 to send the response over another channel in the form of a MAP 1446 data packet. The contents of the MAP 1446 data packet tells the CM103 when to send data and which communication channels it can use for its upstream communications. After receiving data packet 1446, the MAP CM 103 sends its outgoing data simultaneously on two channels in upstream data packets 1447A and 1447B. Separating data transmitted simultaneously on two channels, as shown in the figure in the center, is called channel bonding. Channel bonding is a means by which you can increase the throughput and data rate between the CMTS and the CM. It is also a dynamic method to ensure that there is no unused available bandwidth. The figure below shows the responses of the CMTS 101 on four communication channels, namely 1448A, 1448B, 1448C and 1448D, with simultaneous but different transmission times.

In both the uplink and downlink over a hybrid fiber network, bandwidth is dynamically allocated across multiple channels, divided into small time slots called "minislots". FIG. 65C illustrates upstream communication between CM 103 and CMTS 101. Such preliminary communications usually include a message or a request for transfer. In this example, the data is transmitted over frequencies f ₁ and f ₂ , consisting of five minislots. As shown in the figure, minislots 1, 2 and 3 are transmitted at frequency f ₁ in intervals K, (K + 1) and (K + 2), and minislots 4 and 5 are transmitted at frequency f ₂ in intervals K and (K + 1 ), but not in the interval (K + 2). Preliminary data packet 1450A, shown in abbreviated form, indicates the source IP address "IP CM1" and the destination IP address of the Last Mile connection, i.e. "IP M _0,0 ", gateway node of the SDNP network located on the server 1201A.

For Last Line communications, data packet 1450A defines "MAC CM1" as the source MAC address of the cable modem and the PHY medium, in this case the channel at frequency f ₁ as the destination MAC address "MAC CMTS1". The 1450A data packet containing the SDNP A payload occupies a total of three minislots, namely 1, 2, and 3, although together they carry one data packet and payload. On the other hand, minislot-4 and minislot-5 contain only one data packet each, i.e. 1450B and 1450C with corresponding SDNP B data payload and SDNP C data payload. Like data packet 1450A, both packets 1450B and 1450C indicate the destination IP address of the SDNP cloud, more specifically the gateway node SDNP M _0.0 .

However, for the destination MAC address, instead of specifying the same MAC address and physical medium as the first packet, both packets 1450B and 1450C contain the destination MAC address "CMTS2 MAC". This address can be used to indicate that the 1450B and 1450C data packets should be transmitted at a different frequency from the 1450A data packet — in this case, at f ₂ , not f ₁ . The actual frequency values are dynamically displayed on the CMTS 101 and are not specifically identified. Thus, DOCSIS3 is a multifunctional solution that allows a single CMTS device to simultaneously communicate with a cable modem or video converter on multiple frequencies and use multiple protocols such as 256 QAM or OFDM.

Instead of allowing the CM and CMTS to determine which data packets are using a common bearer or frequency, as is usually the case in DOCSIS3 systems, according to the described Secure Dynamic Network and Last Mile protocol, the SDNP CM 103 client specifies different Destination MAC addresses to support communication on multiple frequencies and channels, i.e. to enforce multi-layer PHY connection operations. Since the CM 103 data packets 1450A and 1450B / C provide different destination MAC addresses, namely the CMTS1 MAC and CMTS2 MAC respectively, the data packets automatically cause a Back-to-Back PHY layered connection. Alternatively, if the CMTS allows other means to request a unique allocation of channels, for example by command and control request, the use of the MAC address to invoke the multilayer PHY connection can be replaced by alternative means.

FIG. 65D illustrates the serial data stream from CMTS 101 to CM 103, depicting the use of channel bonding to achieve high data rates in multi-stream communications. As shown in the figure, all data packets indicate the source IP address "IP CMTS", the destination IP address "IP CM1" and the destination MAC address "MAC CM1". The layered PHY connection is controlled by specifying the source MAC address of the CMTS 101. As shown in the figure, the data packet 1450G containing the SDNP G payload indicates the source MAC address "CMTS6 MAC" corresponding to the communication at frequency f ₆ carrying data in the mini slots 15 and 16. Data packet 1450H contains the SDNP H payload and indicates the source MAC address "MAC CMTS7" corresponding to communication on frequency f ₇ transmitting data in mini-slots 17 through 20. Data packet 1450I containing the SDNP I payload defines the MAC source MAC CMTS8, corresponding to the communication on frequency f ₈ transmitting data in mini-slots 21, 22 and 23. Finally, data packet 1450J containing the SDNP payload J indicates the source MAC address of the MAC CMTS9, corresponding to communication on frequency f ₉ with data in mini-slots 24 and 25. Thus, bound and unbound data packets can be simultaneously sent from CMTS 101 to CM 103 using multi-layer PHY connection methods without end channel flickers or data collisions with matching upstream data.

Hyperprotected call out routing - Routing of hypersecured calls, carried out in accordance with a secured dynamic communication network and protocol, can be carried out using one of three control and monitoring methods.

Three-channel communication, in which the routing of a call or message is controlled by three sets of servers, namely SDNP media servers for transferring audio, video or data files; SDNP signaling servers to select call routing and SDNP nameservers to store dynamic mapping of phone numbers to their respective SDNP addresses,

Two-way communications, in which the call or message routing control uses two sets of servers, namely SDNP media servers to transfer audio, video, or data files; and SDNP signaling servers for routing the call and for performing the function of mapping telephone numbers to the corresponding SDNP addresses,

Single-link communications where data transmission, route planning, and SDNP address map are performed by a single set of servers.

In general, three-channel communication provides greater security against cyber attacks, since no set of servers contains all the information about the call. In any case, however, the SDNP network uses distributed processing to limit the information held on any server. In addition, when transmitting data over one, two or three communication channels, SDNP media servers connect to servers of the fourth type - DMZ. DMZ servers are used to store shared SDNP secrets required to handle SDNP payloads, including encryption, splitting, mixing, insertion and deletion of unnecessary data, and encryption. During operation, incoming data packets received by the media server are delivered to the DMZ server, where the data packets are modified and sent back to the media server. The media server does not know how the data packets were modified or what logic or algorithm was used to process the data. The executable code and tables stored on the DMZ server are encrypted to prevent code parsing. In addition, DMZ servers operate offline with no network or Internet connection.

The following graphs illustrate an example implementation of three-channel SDNP communication and the sequence used to initiate a call or send a file over the network. Dual-link operation can be viewed as a minor modification of three-link communication, in which the SDNP nameserver functions are bundled into signaling servers. Single-link communication involves the integration of all three operations into a network of multifunctional servers acting as SDNP communication nodes.

While fragmented data transfers within the SDNP cloud are typically done using dynamic mesh routing, Last Mile offers fewer routing options, especially where serial data packets can either (i) be directed to a single SDNP gateway, ie. as in a Single Route Last Mile link, or (ii) directed to multiple SDNP gateways, i.e. as in the "Last Mile" multi-route connection. Other Last Mile routing options include dynamic source addressing and Last Line multicast. These delivery parameters are specified in the IP data packets generated by the signaling servers. Although these SDNP data packets indicate the source and destination IP and MAC addresses, the exact path that a particular data packet takes in the Last Mile is unknown. Instead, the intermediate path is determined by the operation of routers, devices owned by LAN operators, mobile operators and network service providers serving the Last Mile, not by SDNP signaling servers. Thus, the Last Mile connection is similar to a rope, where the two ends are fixed, but they are connected by many unique paths.

Repeating for clarity, the term "single-route, multi-route, and mesh" refers to the route of media packets, i. E. the path "content" runs between subscribers, and the terms "three-channel, two-channel and single-channel communications" refer to the command and control system used to control transport over the SDNP node network. With the above in mind, the following set of illustrations shows the sequence of steps, i.e. a "process" used when making a call or initiating a message in accordance with a secure dynamic communications network and protocol.

FIG. 66 illustrates an abstract representation of a single-route Last Mile network for three-link communications including SDNP 1600 client, IP routers 1602A, 1602B, and 1602C, signaling server 1603A, SDNP name server 1604A, and SDNP gateway 1601. These computer servers contain SDNP communication nodes used to provide network interactions with network hostnames and IP addresses, including SDNP Client C _1,1 , R routers, SDNP signaling server Node S, SDNP NS name server, and SDNP gateway Node M _0,0 . The 1610 network connection provides the Last Link between client C _1,1 and the nearest 1602A router; network connection 1611 - between the SDNP M _0,0 gateway and the nearest 1602B router; network connection 1612 - between gateway 1603A and the nearest router 1602C; and network connection 1616 - between the topologically located routers 1602A and 1602C. Since the IP addresses of routers are not used as source or destination in IP datagrams, the name "R" is common to all routers at Layer 3. For Layer 1 and Layer 2 descriptions, each router has a unique identity, but this the aspect is not relevant to the description of call routing at layer 3 of the IP network. The SDNP Signaling Server 1603A (Node S) connects to the SDNP Name Server 1604A (Node NS) through the 1613 network connection and to the nodes of the M _{0, n} SDNP cloud via a series of 1614 network connections. The 1603A Signaling Server also connects to other Signaling Servers (not shown) over network connection 1615.

When using the SDNP network to make a call, i.e. the establishment of a "session" requires the following sequence of steps initiated by the SDNP client making the call, i. e. "the caller".

1. Request for SDNP call (or call out)

2. Request SDNP address

3. Delivery of SDNP address

4. SDNP routing instructions

5. Start SDNP call SDNP (or call out)

The first step, “Call Request”, is depicted in FIG. 67 , where the caller, client 1600 with address "IP C _1,1 ", communicates with signaling server 1603A at "IP S" on routes 1610, 1616, and 1612 with IP datagram 1620. The command and control payload of datagram 621 contains Layer 4 data transport using TCP to ensure data accuracy and defines a number of requested call parameters, including delivery, urgency, security credentials, and called party contact information. In case of calling another SDNP client, i.e. "SDNP call", this contact information includes the confidential identification (CID) of the called client, data available in the client's SDNP phone book. In the case of a "call", a call to a non-SDNP customer, the contact information includes a telephone number. Although the SDNP Client CID is inherently anonymous and known only to the SDNP name server, the phone number is not masked. To protect the privacy of the called subscriber, the telephone number in the control unit is encrypted. Alternatively, the entire payload of the control system 1621 can be encrypted. The payload 1621 can be in cipher text, and the IP addresses of the IP datagrams 1620 cannot be encrypted, otherwise routers 1602A and 1602C will not be able to forward the datagram.

The second step, "Request SDNP Address", is shown in FIG. 68 , where the SDNP signaling server with address "IP S" contacts the SDNP name server at "IP NS" on path 1613 with IP datagram 1622. The command and control payload of the datagram specifies the Layer 4 data transport as TCP and contains either a CID, or the encrypted telephone number of the called party. In the case of a protocol call, SDNP name server 1604A translates the CID into the SDNP address of the called client. In the event of a call, the 1604A name server decodes and converts the called party's phone number to the SDNP gateway address closest to the called party. As shown in FIG. 69 , name server 1604A then transmits the client or gateway SDNP address over IP datagram 1623 from the source address "IP NS" to the signaling server 1603A at "IP S".

Signaling Server 1603A uses the caller and called party SDNP addresses to route the call between them, either as a hypersecure connection if the called party is an SDNP client, or as the nearest SDNP gateway if the called party is not an SDNP client. The process used to prepare routing instructions and propagate to all media nodes required to complete a caller's connection is shown in FIG. 70 . As shown in the figure, the caller's delivery request contained in the delivery and urgency fields of the payload 1621A, after matching with the account details, is used to select a delivery method for the datagram, as shown in operation 1650. Delivery methods including regular, VIP, guaranteed or special delivery, affect the routing of packets or subpackets (if packets are split or fragmented). For example, in VIP delivery, the fastest routes are used for data transfer, while the loading of the same routes by other customers is minimized. With guaranteed delivery, duplicate pieces of data packets are sent over the network, i.e. using redundancy to ensure that the fastest data packets are delivered on time and ignore late arrivals. Combined with the SDNP address data obtained from the 1623A control system, operation 1651 maps the best routes from the caller to the called SDNP address, or to the nearest gateway if the called party is not an SDNP client. The urgency request data contained in document 1621A is used to select expedited operation 1652, including the order of decreasing propagation delays — slow delivery, normal delivery, priority delivery, and urgent delivery.

The urgent request information is used to select routing and zones for sub-packet routing in operation 1653. These parameters, along with any applicable credentials 1621B, are combined to synthesize routing commands and control packets through operation 1660. These management and certification packets are delivered to the sites. " Last Mile "using the Layer 4 transport specified by TCP, but contain routing information that, when delivering data in real time, uses UDP as the Layer 4 transport protocol. For example, Last Mile routing based on zone credentials U1, generated as an IP datagram 1625 with a command post payload 1626, used to route data from client node C _1,1 to SDNP gateway node M _0,0 . IP datagram 1625 is delivered to the SDNP client using TCP data transmission, but the Last Mile U1 Routing payload 1626 contains data used to route packets in real time, which requires UDP as the Layer 4 transport mechanism. The SDNP 1660 C&C also generates many other C&C messages delivered as TCP data packets to nodes within the SDNP cloud. One example of a cloud command data packet is the 1627A IP datagram containing the 1628A payload used to route data from SDNP M _0.0 to SDNP M _0.1 . As shown in FIG. 71 , these SDNP routing instruction packets are distributed to media nodes, including client nodes C1,1, over serial links 1612, 1616, and 1610, and SDNP gateway M _0.0, and other nodes in the SDNP cloud over links 1614.

The start of the call is shown in FIG. 72 , where an SDNP media datagram 1630 containing SDNP data such as audio, video, text, etc. is added to an IP header containing data packet 1626 and is routed from IP C _1.1 to IP M0.0 from an SDNP 1600 client through a Back-end 1601 network connection to routers 1602A and 1602B. The tag data fields, security zones, preambles, and SDNP information fields together constitute the payload of the SDNP media packet contained in the SDNP media datagram 1630.

The routing of the above SDNP call, i.e. A hypersecure call from an SDNP gateway M0.0 to an SDNP client C7.1 containing a mobile phone 32 with the SDNP 1335A application installed is shown in the simplified network diagram of FIG. 73A . SDNP datagram 1631A, containing SDNP A media payload and header 1628A, is routed between media nodes with SDNP addresses M _0.0 and M _0.1 . Note that SDNP Gateway 1601 has two addresses - IP M0.0 for Last Mile communication and SDNP M _0.0 for SDNP Cloud communication. The content of each SDNP datagram changes as the packet passes through the SDNP cloud so that the content — sound, video, and text — contained in SDNP media files A, B, and C — is markedly different and can include content from twenty different conversations or messages. The mechanisms for routing data and securing packets within the SDNP cloud are disclosed in the aforementioned US patent application No. 14 / 803,869 entitled Dynamic Secure Communications Network and Protocol, which describes how the content and encryption of data packets moving anonymously through the SDNP cloud changes dynamically and constantly, only by connecting on the client device.

Accordingly, SDNP datagram 1631B containing SDNP media with payload B and header 1628B is routed between media nodes with IP addresses M0,4 and M0, f. Data exiting the SDNP cloud through SDNP gateway 1601B is converted from SDNP datagram to IP datagram 1632. IP datagram 1632 with header 1628C and SDNP media payload uses security credentials for zone U2, which is a zone that includes "Last A mile. " IP datagram 1632 is then routed over Last Mile over wired or fiber 24 to network router 27, and then over cellular 25 and cellular line 28 to cell 32. Since cell 32 is an SDNP client, Last Mile connections "remain hyper-protected. In this simplified example, all data packets leaving the cloud for the Last Mile are routed from a single SDNP 1601B gateway. In fact, more than one SDNP gateway can be used to route Last Mile data.

The "Last Mile" communication for "call out" is shown in FIG. 73B . Although routing through the SDNP cloud uses the same SDNP 1631A and 1631B datagrams as when calling the SDNP client, the SDNP 1601B gateway is the last server running SDNP software. The Last Mile link in the outgoing call uses IP datagrams with a non-SDNP payload; IP datagram 1635 is routed from gateway IP M _0.0 to PSTN at IP address IP C _7.9 , transmitting audio as VoIP. The PSTN then converts the VoIP call format to a regular phone call using the phone number and analog audio in the 1636 audio packet. In such cases, Last Mile is not a hypersecure connection.

In the Last Mile multi-route connection shown in FIG. 74 , the command and data control packets distributed by the 1603A SDNP signaling server include the 1625X command and control packet directed to client 1600 on channels 1612 and 1610, the 1627X control packet directed to the SDNP 1601X gateway on the 1614X line, and the 1627Y control packet directed to SDNP gateway on data line 1614Y. Other data packets (not shown) are sent over the channels 1614X to other servers that host the media nodes. A 1625X test packet is sent from IP S to IP C _1,1 , which contains the controller payload that includes U1 Last Mile routing. Last Mile Routing U1 includes two different routing commands - from "IP C _1.1 " to "IP M _0.0 " with tag 1 and preamble 1, and from "IP C _1.1 " to "IP M _0.1 " with tag 2 and preamble 2. As an example, we can cite packets of command and control data sent to communication nodes within the SDNP cloud, including from "IP S" to "IP M _0,0 ", containing instructions SDNP Cloud Routing 1, and from "IP M _0.1 " containing SDNP Cloud Routing 2.

Group SDNP calls - routing media packets on the Last Mile from an SDNP 1600 client to multiple SDNP gateways, as shown inFIG. 75A, includes two data packets 1630X and 1630Y, including headers 1626X and 1626Y, respectively, and media data SDNP X and SDNP Y. Header 1626X with tag 1 and preamble 1 is transmitted from the address "IP C_1.1"to address" IP M_0.0", and the header 1626Y with tag 2 and preamble 2 from the address" IP C_1.1"to address" IP M_0.1".

Data flowing back from the SDNP cloud to the client using multi-channel communication, as shown in FIG. 75B include data packet 1630U containing header 1626U, tag 8, preamble 8, SDNP U data, source SDNP gateway address M0.0, and destination address "IP C _0.0 ". At the same time, the data also includes a 1630 B data packet containing a 1626 B header, tag 9, preamble 9, SDNP data V, SDNP gateway address of the source M0,1 and the destination address "IP C _0,0 ". The SDNP program running on the SDNP 1600 client then concatenates the incoming SDNP Data U, SDNP Data V, and other packets to recreate the message text or voice (sound).

The delivery of C&C data packets with routing instructions can be extended to initiate three-way or group calls, group messaging, and other multi-client communication options. In the messages of such a group or "conference calls", the client message is sent to several subscribers at the same time. This group function is triggered by the caller whose group call request first identifies the group of clients to be contacted, then the signaling server which instructs the necessary media nodes how to handle the routing of data packets associated with a particular group call. An example of routing group calls is shown in FIG. 76 , where signaling server 1603P transmits routing instructions over data link 1614A to SDNP client 1600A and 1614Z to multiple media servers 1600Z within the SDNP cloud.

Thus, a TCP 1627A data packet with Last Mile U1 routing is sent from the 1603P signaling server at IP S1 to the SDNP client at IP C _1,1 to “set up” the group call with the caller. C&C data packets, represented by a typical TCP data packet 1627Z, are simultaneously distributed across the SDNP cloud for zone Z1 over communication links 1614Z from the signaling server address "IP S1" to various destination addresses "IP M _{0, y} ", where y is an integer variable. The SDNP Cloud Routing instructions establish the routing of packets from the caller's gateway through the SDNP cloud to two or more SDNP gateways located near the called SDNP clients.

As shown in the example, other SDNP clients can be located in different geographic regions and within separate security zones, such as U7 and U9. In some cases, these clients may be far enough away from the 1603P signaling server that another 1603Q signaling server can be used to schedule packet routing for these SDNP clients. Signaling Server 1603Q transmits U9 routing commands to SDNP client 1600M on data link 1614M and to SDNP client 1600L on data link 1614L. For example, C&C data packet 1625M transmits U9 Last Mile routing commands from the signaling server to "IP S4" to the SDNP client 1600M at "IP C _9,1 ". Another C&C packet (not shown) is also sent to the SDNP client at IP C _9.4 . Data packet 1627H containing U7 Last Mile routing instructions is sent over channel 1614H from 1603Q signaling server over IP S4 to 1600H client at IP C _7,1 .

Signaling servers 1603P and 1603Q at nodes S1 and S4 also exchange information in the form of C&C data packets over channel 1613Z. This information is used to determine which parts of the routing should be performed by the signaling server 1603P and which by the signaling server 1603Q, substantially dividing the routing task across multiple signaling servers. In the example shown, the signaling server node S1 manages the Last Mile routing for the U1 zone and for the SDNP cloud, and the signaling node S4 manages the Last Mile communication for the U7 and U9 zones.

The routing of data during a conversation or messages is shown in FIG. 77A , where the voice carried by SDNP data 1 in data packet 1630A is routed by header 1626A from the caller with the IP address "IP C _1,1 " to the nearest media gateway node SDNP M0,0. The data packet is repackaged for transmission to the SDNP cloud and sent to the media nodes M _0.4 and M _0.8 gateways. The routing of packets within the SDNP cloud is unknown to any of the conference participants, has no centralized control, and dynamically changes depending on the network conditions. In this example, all SDNP data packets within the SDNP cloud use fragmented mesh data transport with anonymous addressing and dynamic encryption, as well as dynamic encryption, mixing, splitting, adding and removing unnecessary data. In the example shown, the cloud engine redirects incoming connections from SDNP gateway node M _0.0 to other gateways, in this case SDNP gateway nodes M _0.4 and M _0.8 .

Data packet 1630H with caller voice i.e. SDNP data 1 exits gateway node M _0.4 and is routed via header 1626H from media node "IP M _0.4 " to client 1600H with "IP C _7.1 " using U7 security credentials. Header 1626H was sent to client 1600A as part of C&C data packet 1627A prior to preparing the media packet as described in FIG. 76 . In this way, each media packet containing real-time data can be prepared without delay when the content is ready for data transmission. In real-time networks, high QoS depends on the timely routing of dynamic data. Otherwise, unacceptably long propagation delays may occur.

Once routed through the SDNP cloud, the SDNP-1 data payload is delivered to U9 conference call participants, namely SDNP clients 1600M and 1600L, from Media Gateway M _0.8 to "IP C _9.1 " client IP addresses and "IP C _9.4 ". These Last Mile data packets 1630M and 1630L contain headers 1626M and 1626L defining the identification tags of the packets tag8 and tag9 used to recognize the content associated with the same conversation, a preamble 9 of information used to convey embedded SDNP instructions, keys, initial values, etc. and a data field "L4" used to support Layer 4 transport as UDP. Although the routing instructions sent by the signaling server use the TCP transport protocol to ensure accuracy, the content of the media packets is real-time data, so it is beneficial to use UDP Layer 4 protocols instead of TCP.

FIG. 77B illustrates the same conversation where content from the U7 client 1600H zone appears, that is, when the C _7,1 client starts talking. To compare this data with the voice content of client C _1,1 , the payload is identified in all data packets as "SDNP data 5". Aside from the unique payload, the only difference from the previous scheme is that the Last Mile source and destination IP addresses for 1630H and 1630A data packets change. Specifically, for a user in SDNP zone U7, the source IP address for data packet 1630H is changed to IP C _7.1 and its destination becomes the SDNP gateway IP M _0.4 address. For zone U1, the called party's IP address for data packet 1630A is changed to IP C _1,1 and its source address becomes the SDNP IP M _0,0 gateway address. It should be understood that multiple participants in a conference call may be speaking at the same time and that data packets from an SDNP C _1,1 client node sent to other call participants, including a C _7,1 client node, may occur concurrently with a C _7,1 client node answering to the client node C _1,1 .

There are no collisions of traffic data in the opposite direction on the network layer 3 of the Last Mile link. However, on the physical layer and link layer 1 and 2, Last Mile communications may include time division multiplexing to avoid disputes over the same communications channel. However, this mediation is so fast that communication can appear to be full duplex with no delays in voice packets. Note that in FIG. 77A , and FIG. 77B, the direction of data flow displayed to the clients of zone U9 remains unchanged, i.e. the data stream is sent from the cloud to the client. FIG. 77C , however, starts talking to the U9 C _9.1 client node. In this case, all client nodes C _9.4 , C _1.1, and C _7.1 become the recipients of the vote, i.e. voice data SDNP 6.

In an alternative embodiment shown in FIG. 78 , the group call may include a combination of SDNP client calls and "call out" calls to regular telephone numbers. By analogy with the telephone conversation or messages presented in FIG. 77A , the voice carried by SDNP data 1 in data packet 1630A is routed over header 1626A from the subscriber with the IP address "IP C _1,1 " to the nearest SDNP gateway containing media node M _0,0 . The data packet is repackaged for transmission to the SDNP cloud and sent to the media nodes M _0.4 and M _0.8 gateways.

In the example shown, the cloud engine redirects incoming connections from SDNP gateway node M0.0 to other gateways, in this case SDNP gateway nodes M _0.4 and M _0.8 . Data packet 1630H with caller voice i.e. SDNP data 1 exits gateway node M _0.4 and is routed with header 1626H from media node "IP M _0.4 " to client 1600H with "IP C _7.1 " using U7 zone security credentials. The SDNP data payload 1 is also delivered to the conference call participants via the Media Gateway M _0.8 . The last mile connection to this SDNP gateway consists of two different types of connections, namely a hypersecure connection to the 1600M SDNP client and an unsecured "call out" connection to the PSTN 1, which includes a conventional telephone system without VoIP or packet protocols. Last Mile data packet 1630M is delivered to U9 SDNP client area at IP C _9.1 containing header 1626M with packet ID tag 9 used to recognize content associated with the same conversation, preamble 9 information used for passing inline SDNP instructions, keys, seed values, and the "L4" field to set the Layer 4 transport as UDP.

Gateway Node M0.8 also sends IP packet 1635 to PSTN 1 at IP C7.9. Instead of carrying a payload consisting of SDNP 1 data, in this case the IP payload has been converted into a VoIP audio packet that can be intercepted while listening to the packets. PSTN Telephone Switching System 1 converts the unsecured IP packet into an analog POTS telephone connection, shown by POTS data 1636, followed by an analog connection between telephone 37 and PSTN 1. Since this and any other connections are not hypersecure, the content of the called Last Line is exposed to the risk of hacking, wiretapping and other methods of surveillance. If some hierarchical structure is not implemented that defines the access rights of clients, the security of the entire call will be compromised by the weakest link, i.e. everyone in a group call can hear everything.

This is evidenced by the table in FIG. 79A , where the group call includes participants on the hyperprotected client nodes of the SDNP network C _1.1 , C _7.1 , C _9.1 and C _9.4 , as well as participants in telephone calls "Ph # 1" and "Ph # 2" ... As shown in the figure, the SDNP C _1,1 client is the host of the group, the SDNP C _7,1 , C _9,1 clients are members, that is, they can listen and speak, and the SDNP C _9.4 client is the "listener", that is can listen to the call, but cannot speak or be heard by the participants. The participant when called to the telephone number "Ph # 1" is also a participant capable of listening and speaking, and the caller to the telephone number "Ph # 2" is authorized only as a "listener" who cannot speak on the group call. The group host assigns these rights, i.e. user authorization during call setup.

Referring to the table in the "regular call" column, please note that all participants in the group call, i.e. subscribers admitted by the organizer have the opportunity to listen to the call. Subscribers trying to hack a call or not admitted by the host have no way to connect to the call, or even the ability to determine that a call is going through. The same techniques apply to group chats, where members can read and write messages, but only members can view only comments, but cannot enter their own text into the chat.

By using authentication and authentication to control network access under this disclosure, SDNP offers privacy features not available in conventional group chats and conference calls. This function is invoked by selecting a private mode, for example, by clicking on the lock symbol or other privacy icon before sending SMS or speaking. In such cases, communication is only sent to authenticated SDNP clients, not SDNP clients who have not yet verified their identity, or listeners or participants on unsecured devices. This point is clarified in the above table, where in a private call under the column "unauthenticated SDNP client" all group call clients mute the microphone and speaker, and in the column "Authenticated SDNP client" all SDNP clients can listen, participants C _1,1 , C _{7 , 1} and C _9,1 can also speak, but all callers have their own microphone and speakers, while the customer can only hear the comments. This point is clarified in the above table, where in a private call under the column "unauthenticated SDNP client" all group call clients have their microphone and speaker disabled, while in the column "Authenticated SDNP client" all SDNP clients can listen, participants C _1,1 , C _7.1 and C _9.1 can also speak, but all callers will have their speakers and microphone muted so that only authorized customers can hear or comment privately. Thus, a group call with verified SDNP clients and with connections of unknown subscribers can mutually participate in the public part of the call, without the possibility of disclosing confidential information to the calling devices.

Unauthenticated callers are removed from private conversations if any SDNP member clicks on the lock icon before talking or sending a message. After a confidential conversation, the button is released and the contacts are reconnected. During the disconnection of the subscriber, i.e. when it is in standby mode, the SDNP system can either play music, be silent, or play white noise (such as ocean or rain sounds).

Text messages in a group chat can also be managed in a similar way. In regular group chat, all text messages are sent to the SDNP app on SDNP client devices and SMS to all chat participants. Text messages can only be sent by members. Text messages sent from listeners or read-only chat participants are ignored and will not be forwarded to the chat group. If a member clicks on the lock icon before sending a message, the message will only be sent to SDNP clients, not a call out to clients. For SDNP clients receiving a private message, if they are authorized, the message will be visible for reading. If they have not authenticated their identity, the message will be hidden, closed, or represented by an icon, such as a padlock, until the user authenticates to verify their identity.

By combining identity authentication with privacy privileges governed by SDNP network authorization, hacking into a device will not be enough to open text or eavesdrop on a private conversation, even in group chats and group calls. This feature cannot be guaranteed by relying solely on the device's security settings - information that can be compromised locally. System parameters are much more difficult to trick as fake credentials will not match the system logs and will be rejected as invalid SDNP clients.

An extra degree of privacy can also be added when making group calls and group chats. This unique embodiment of the Last Mile hypersecure relationship described in the table in FIG. 79B is referred to here as hyper-private call or hyper-private chat. Hyper-confidentiality requires the caller or message to meet four criteria:

All recipients of messages in a group call must be SDNP clients, not call out devices,

Call or text should be selected as hyper-private message, be it a call, text, image, etc.

The recipient of group call or chat messages must verify their connection in order to verify their identity.

The recipient of any hyper-private message must be pre-selected as a "private" participant or a private listener.

While the first three criteria are basically the same as in the previous example for private callers in a group call, the fourth criterion, the requirement that any caller who is allowed to receive private calls or text should be loaded into a predefined list of clients as " private "SDNP client" is unique and additionally restricts access to important information. For example, as shown in the table, clients of SDNP member C _1,1 and C _7,1 and client of SDNP listener C _{9.4 are} designated as "private" members in the group call. In contrast, the SDNP C _9.1 client is only designated as a member and not as a private member. By definition, no call participant or listener can be registered as a private subscriber.

As in the previous example, during a regular call, all participants, i.e. SDNP clients C1,1, C7,1 and C9,1 and call out participant Ph1, can hear all conversations and read all text messages, and speak or send messages at any time, and "listeners" including clients C9,3 and Ph # 2, can hear all conversations and see text, but cannot speak or transmit messages in a group. However, in a group conversation in the hyper-private conversation mode, choosing a switch or icon to indicate a hyper-private message automatically blocks not only all unconfirmed subscribers, but also disconnects all except "private" ones. It also disconnects all call out connections and all unacknowledged users. Thus, in work, when any private member chooses the privacy icon, only private members (including the group organizer) can see, read, talk, or write in the group. All other participants' microphones and speakers are muted and cannot receive or send texts or attach files to them. In particular, in hyper-private mode, after authentication, only C1,1 and C7,1 clients can both listen and speak, and read and send text, while C9,4 private client can only listen to a conversation or read a group text.

The above Last Mile Routing Control capabilities allow you to manage group calls and group chats in different ways. For example, the organizer of a group call can determine who can join the call or group, who can speak and write messages, and who can only listen and read. With standard private calling, choosing private mode allows all SDNP clients, after authentication, to participate in the conversation with the same privileges as in standard group communication. In hyper-private mode, only SDNP clients defined as private participants and private listeners can communicate in hyper-private mode.

Choosing who can qualify as a participant or listener in hyper-private communication, i.e. who is identified as a private participant or listener and who is not can be established in several ways. In a one-time group hyper-private communication, the group organizer decides who is a private subscriber and who is not. In SDNP "system" group hyper-private communication, the SDNP network operator pre-determines who is a private subscriber and who is not. In rule-based group hyper-private communication, the SDNP network has defined rules for determining who is allowed to be a private subscriber and who is not. These rules can be based on the list of company employees, for example, when only the VP and superiors can participate in private telephone conversations. In government agencies and security services, criteria can be established by admission to the national security service, passport number, police badge number, etc. The SDNP-supported Last Mile communication methods described here can support either of these examples or use any other criteria to divide the population into two groups, thereby creating those that have access to hyper-private communication and those that do not. access.

Although this concept can be extended to more than one group, hierarchical access criteria are generally more applicable to professional communications systems than to telephone communications. Therefore, the application of SDNP methods for professional communication in this context will not be further considered.

One problem with group calls is that everyone tries to talk at the same time. Overlapping speech is confusing, difficult to hear, and can lead to unwanted static discharges. This problem can be solved by using the "push-to-talk" function, which simulates a walkie-talkie or CB radio. In PTT or push-to-talk mode, only one participant can talk at a time. When a participant wishes to speak, pressing the switch mutes all other network microphones, putting all other participants in the group call into listen-only mode. As shown in the table in FIG. 80A , during regular PTT talk, by pressing the PTT button as shown in the Host PTT column, they take precedence over the group call and override all other callers, even those who pressed the talk button. All other callers, including telephone connections, automatically mute their microphones and become just listeners. If the host does not press the PTT button as shown in the Other PTT column, then the PTT function will be transferred to any other SDNP participant on a first come, first served basis. SDNP nodes designated as listeners and callers, such as C9,4 and Ph1, can listen to PTT conversations, but their microphones are muted during a group call.

By using the SDNP Last Mile communication capability to identify subscribers who have logged into the network, PTT can be extended to private communication functions. Selecting the privacy icon removes all unacknowledged callers from the group call by muffling their speakers and microphones. Call connections, by definition, cannot be authenticated and are therefore disconnected as well. Muting is bi-directional, preventing excluded participants from eavesdropping on the conversation and also mute the microphones of excluded participants. For authenticated participants, the operation precedes normal PTT, where the host has priority in the conversation and any authenticated participant can use the PTT feature of a first-hand conversation.

The table in FIG. 80B illustrates the concept of a private group call, which can be extended to a PTT function. In normal operation, the PTT function is the same as described above. But in hyper-private mode, only authenticated individuals who were previously identified as private participants or private listeners can engage in hyper-private conversations. For example, in hyper-private mode, SDNP clients C _9.1 and C _{9.5 are} cut off from talking or listening because they were not previously listed as private participants or listeners. Likewise, all connected devices are disconnected while working in hyper-private mode. In this way, access to different callers in a PTT group call can be clearly controlled. Muting is the process of excluding some participants (for example, listeners) from receiving data packets that carry the audio of a conversation, while still delivering data packets to participants that are not muted. In this method, data packets are individually sent to all participants in a normal conversation and only to a part of the list when the client user mutes the sound.

Alternatively, the data packets are broadcast to all participants in the group call, but using different encryption methods. In the case of regular conference calls, data packets are sent to all users using encryption, where all participants have a copy of the decryption key. In private or mute mode, data packets sent to users use a different encryption, in which the decryption key is only sent to select users. Those with the key can participate in the conversation, and those without the key are excluded. The advantage of using a broadcast packet is that it requires less bandwidth for Last Mile communications than for sending individual packets. In another variant, one packet is sent to the gateway, and the signaling server clones the packet for distribution to all participants in the usual call mode and selection of subscribers in private or silent mode.

Hyper Protected File Storage “Although secure dynamic communications network and protocol were invented and developed as a hypersecure communications system for telephony and real-time data transmission, the inherent security mechanisms of the network and SDNP make it ideal for hypersecure storage of files and data. In short, if a hypersecured call includes an anonymous fragmentary transfer of encrypted data from one subscriber to another, i.e. end-to-end connection from one SDNP client to another SDNP client, then hyper-secure storage of files and data can be considered as a communication message that stops halfway and is stored indefinitely in the buffer until the next call. Another name for distributed hyperprotected file storage is disaggregated data storage.

The simplified description is that the store is a link that stops in the middle of the package delivery process, and this description is technically more accurate than it might seem at first glance. In the above US Patent Application No. 14 / 803,869, buffering data packets until other packets are detected has been explicitly disclosed and described. Although buffering within SDNP cloud nodes occurs in milliseconds rather than months, SDNP has the ability to wait or store data without losing the recovered information to return the original content. Of course, this simplified implementation lacks some of the functionality needed for long-term file management, such as directories, menus, file recycling, credential updates, and other similar functions.

An example of data transfer from a client to a fragmented storage network is shown in FIG. 81 . As shown in the figure, an SDNP 1700A client with IP C1,1 transmits a series of data packets over the SDNP cloud to SDNP 1700H, 1700M, and 1700L file storage servers with corresponding IP addresses F7,1, IP F9,1, and IP F9 ,4. During operation, client node C1,1 sends a series of 1730X data packets with corresponding 1726X headers from IP address C1,1 to SDNP gateway M _0,0 . The 1730X data packets are illustrated by the 1730H, 1730L, and 1730M data packets with corresponding headers 1726H, 1726L, and 1726M. For accuracy, Layer 4 transport uses TCP rather than UDP. Packages include an SDNP Zip or other X identification tag that is used to identify them when routing, in the case of 1730H, 1730L, and 1730M data packets, tag1, tag2, and tag3. A portion of the payload of each packet contains unique data, such as in the three-part fragmented file SDNP File 1, SDNP File 2, and SDNP File 3. The Last Mile security credentials in zone U1 are used with the corresponding preamble 1.

After the data packets arrive at the SDNP cloud, they are directed to various destinations according to their identification and signaling server instructions (not shown). Data packet 1730H with header 1626H and tag 1 with SDNP file 1 is forwarded to the SDNP M0.4 gateway node. The SDNP M0.4 gateway node then routes the 1730H packet to the F7.1 file storage node using the security credentials for the U7 zone. Meanwhile, a 1730L packet with tag ID 2 with SDNP file 2 is independently routed to the gateway of SDNP node M0.8. SDNP gateway node M0.8 then routes the 1730L packet to file vault node F9.4 using the security credentials for zone U9.

At almost the same time, a 1730M tag-ID packet containing SDNP file 3 is also independently routed to the SDNP gateway of node M0.8, not necessarily using the same routing mesh as the 1730L tag-ID packet 2. SDNP Gateway Node M0.8 also directs tagged 1730M packet 3 to file storage node F9.1, also using security credentials for zone U9.

Thus, SDNP file 1 is uploaded to F7,1 file storage node using security credentials for zone U7, and SDNP files 2 and 3 are uploaded to F9.4 F9,1 file storage nodes, respectively, using security credentials for zone 9. Although the files are owned by the client node C1,1, the client does not have access to the security credentials used to encrypt and protect the contents of the files. Since no single file storage node contains all of the data, and the client, the owner of the data, does not have access to the credentials used for storage, it is difficult for a hacker to steal their contents because (i) they are separated into incongruous and unusable parts (ii) all files use different security credentials to encrypt and scramble data on the SD network (iii) they are stored in different locations and on different Last Mile networks and (iv) it is impossible to determine that the different stored data comes from the same original SDNP file. Zones containing file storage servers can also be referred to as storage zones, different from the zone in which the file owner resides, i.e. on opposite sides of the SDNP cloud. By this definition, zone U1 is the SDNP client zone, also called the file owner zone, and zones U7 and U9 are storage zones.

The use of SDNP network communication protocols on file storage is further illustrated in FIG. 82A showing a "write operation", the general steps in which the SDNP client and file owner write data to hypersecure file storage servers. As shown in the figure, the SDNP client 1700A splits the unparsed file 1705 using the SDNP splitting operation 1057 and the parsing function 1052 to create a multi-part file or document, as shown in the three-part file 1706A, 1706B, and 1706C. Optionally, the contents of the file can be encrypted before splitting. These three files are then transferred over the SDNP network as unrelated data or information. The steps involved in routing through the SDNP network to the final destinations use the same methods as described above for hypersecure Last Mile and SDNP cloud routing.

Specifically, Last Mile 1707 hypersecured data forwarding uses security credentials consistent with Zone U1. 1708 Hypersecured Mesh File Transfer in SDNP Cloud uses Z1 security credentials. Although these hypersecured data transfers are large chunks, packet transport actually occurs through a network of routers, servers, and softswitches, as described in this section, using a distributed system that lacks a master key, central control, and access to packet content. ...

While U1 Last Mile routing may involve sending data packets over infrastructure with limited routing options, the techniques described for hypersecure Last Mile communications, including multifunctional Last Line routing, routing sequential packets to multiple SDNP gateways and using dynamic source addressing, i.e. changing the name of the client's IP address is equally applicable to operations in the hypersecured file storage. Once data packets reach the SDNP cloud, their forwarding uses anonymous mesh routing with dynamically encrypted data, which makes it difficult to track the contents of the file or even the metadata associated with the communication. Ultimately, all three data packets go to different SDNP 1700H, 1700M, and 1700L file storage servers with corresponding SDNP node names F7.1, F9.1, and F9.4 located in different security zones. After the network transfer, the parsed file 1 is processed in accordance with the U7 file security operation 1709A and stored in the SDNP F7.1 file storage node. Processed files 2 and 3 are analyzed in accordance with the file security operations for zone U9 1709B and 1709C and stored on SDNP file storage nodes F9.1 and F9.4. Thus, no file contains all the data, and no security account can unlock all component files to recreate the original.

In the "read" operation of the hypersecured file shown in FIG. 82B , data transfer sequence between file storage servers and SDNP client, i. E. the owner of the file is reversed. Reading a hyperprotected file means canceling the process by which the file was originally saved in reverse order, including (i) identifying the processed files on each storage server, (ii) removing the local storage security clauses from each processed file (iii) transferring each recovered file back to SDNP client via SDNP cloud and Last Mile hypersecured link, (iv) collecting processed files from different messages, and (v) merging (non-splitting) and, if possible, parsing files using the client's local credentials to restore the original file.

To further describe the hypersecure file "read" operation, the corresponding contents of the 1700H storage server stored in file storage node F7,1 are processed using File Security Zone U7 operations 1709A to recover processed file 1. Regardless of parsing files 2 or 3, the parsed file 1 is sent back to the client node SDNP C1,1 using the SDNP cloud, shown in simplified form in hypersecure transfer operation 1708, using the security credentials of zone Z1 and then zone U1 of hypersecure Last Mile Forwarding 1707. Parallel to this file storage server 1700M, stored in file storage node F9,1, is processed by U9 file security operation 1709B to recover parsed file 2. Regardless of file parsing 1 or 3, parsed file 2 is sent back to the client node SDNP C1,1 with SDNP cloud shown in simplified handicap me in hypersecure transfer operation 1708, using the security credentials of zone Z1 and then zone U1 in hypersecure last mile communication transfer operation 1707. Meanwhile, the corresponding contents of file storage server 1700L stored in file storage node F9.4 are processed using file security operations in zone U9 1709C to recover parsed file 3. Regardless of file parsing 1 or 2, parsed file 3 is transferred back to the client node SDNP C1,1 using the SDNP cloud, shown in simplified form in hypersecure transfer operation 1708 using the security credentials of Zone Z1 and then Zone U1 in a hypersecure Last Mile Handover operation 1707.

Independent batch routing of the three constituent files during a read operation is shown in FIG. 83 , where the server node 1700H sends the data packet 1731H with the SDNP file 1 and the identifier "tag 7" using the TCP protocol from the file storage address IP F7,1 to the server of the SDNP gateway at IP address M0,4. The 1731H packet includes a 1727H header containing preamble 7 and other information that was previously provided in a three-way communication in a command and control packet by the signaling server.

Meanwhile, server node 1700L sends data packet 1731L with SDNP file 2 and ID "tag 9" using TCP from the file storage address IP F9.4 to the SDNP gateway server at IP address M0.8. Packet 1731L includes header 1727L containing preamble 9 and other information that was previously provided by the signaling server in a command and control packet on a three-way connection. Independently and in parallel, the 1700M server node sends a 1731M data packet with SDNP file 3 and tag 8 using TCP from the IP F9.1 file storage address to the SDNP gateway server, also at IP M0.8.

The packet 1731M includes the header 1727M, contains the preamble 9 and other information provided in the three-way communication, previously using the command and control packet provided by the signaling server. Three 1731H, 1731L, and 1731M data packets pass through the SDNP cloud using Z1 credentials until they finally exit the SDNP M0.0 gateway hosted on the 1701U SDNP cloud server, where data packets are sequentially transmitted in 1731X sequential data packets using the corresponding 1727X zone headers and U1 zone credentials to the 1700A client device at IP C1,1.

Referring to FIG. 82B , after the three parsed files 1, 2, and 3, namely 1706A, 1706B, and 1706C, are independently routed to the SDNP 1700A client device, they will be merged into one file 1705 by mixing operation 1061, and then a descrambling operation (not shown) in accordance with the security authority of the U1 zone.

Rather than adding additional file server operations to protect stored data, operations 1709A, 1709B, and 1709C actually involve hypersecure Last Mile communication between the SDNP cloud and the corresponding storage servers 1700H, 1700M, and 1700L. As an artifact of Layer 3 network connectivity using the SDNP communication protocol, SDNP file storage is inherently hypersecure, consisting of scrambled, fragmented, encrypted data stored on distributed non-volatile disks, including the use of data manipulation techniques such as entering unnecessary data and unnecessary files. In addition to the data protection methods described above, hypersecure storage uses anonymous file names without any meaningful metadata, traceability to the file owner, routing through which the file was delivered, or identifying any other file storage server with missing components from the original file.

Despite the interoperability in the SDNP network, the physical implementation of storage servers, i.e. their implementation of the physical first layer and the transport of the second physical layer, protocols can differ significantly without compromising storage functionality, access times or global availability. FIG. 84A illustrates the physical implementation of SDNP file storage servers, including the topmost drawing of an SDNP 1701B gateway connected to an SDNP 1740A file storage server through Router 27. To improve network performance and resilience to attacks, the middle figure shows a direct connection between the SDNP 1701B gateway and SDNP file storage server. 1740A using fiber-optic cable 91 without the use of intermediate routers. As shown in the example below, a file storage server can consist of more memory with a 1740B server controller and 1740C and 1740D drives. Disks can include any storage medium, including a hard disk or non-volatile memory based on a flash drive. To further restrict access, the SDNP gateway and SDNP file storage server can be physically located in the same location and room with a fiber-only cable connection. They may even be in the same room, for example, physically locked in a vault, with tightly controlled access control and surveillance of everyone who enters the room.

FIG. 84B also shows that some portion of a fragmented data file may be stored locally at the owner of the file. As shown in the figure, the desktop of the file owner 36 can store the distributed file on multiple devices, including (i) a local file storage server 1740A accessed via Wi-Fi router 1352, which is connected to an SDNP M0.0 gateway node on server 1701A, ( ii) a 1740B file storage server with access to an SDNP M0.4 gateway node; and (iii) a 1740C file storage server with an M0.8 gateway. Because the data is fragmented across the 1740A, 1740B, and 1740C mapped disks, other devices, including laptop 35, tablet 33, and mobile phone 29, cannot access the saved file even if the 1740A local file server and file owner 36's desktop are connected to the same Wi -Fi 1352.

The process of storing each parsed file portion in a unique way on separate file storage servers, called non-redundant hypersecure file display, is shown in FIG. 85A . The 1700A client device, which includes the client node SDNP C1,1, stores the processed file 1706A exclusively on the server 1700H, the processed file 1706B exclusively on the server 1700M, and the processed file 1706C exclusively on the server 1700L, which corresponds to the mapping of files 1, 2, and 3 to nodes F _{7 , 1} , F _9.1 , and F _9.4 , respectively. File delivery uses a hypersecure Last Mile link to transfer and store data. One of the disadvantages of non-redundant file mapping is that the loss of any of the file storage servers, both temporary and permanent, compromises file access and recovery. In the context of this statement, the terms "resilience" and "resilient" are used to define guaranteed and timely access to a data store, i. E. confidence that the stored data will not be lost or difficult to access for a long time. For this reason, non-redundant hyperprotected file mapping exhibits poor resilience because a single point failure prevents file access. Poor fault tolerance can be overcome by a redundant system in which the same data is stored on more than one file storage server.

Another metric that characterizes or evaluates the resilience of a storage system is the metric defined here as the read redundancy factor (RRF), a term that defines the number of redundant systems that provide access to data in the event that the main data store is unavailable. In the example shown, there is one location for each unique piece of data. This results in a zero read redundancy factor, mathematically RRF = 0, which means that a single point connection or file server failure can result in temporary or permanent data loss as the file cannot be read by the owner.

An alternative mapping of files with a redundancy factor of RRF = 1 is shown in FIG. 85B . In this example, parsed file 1 is on file storage server F9.4 and F7.1, parsed file 2 is on file storage server F9.1 and F7.1, and parsed file 3 is on file storage server F9.4 and F9. 1. In this implementation, if the F9.1 file storage server becomes unavailable or corrupted, parsed file 3 can still be accessed from the F9.4 file storage server, and parsed file 2 can still be accessed from the F7.1 file storage server. Thus, any failure of a single storage node will not interfere with read access to hyperprotected files. FIG. 85C illustrates the display of hyper-protected files with RRF = 2. The file storage mapping retains the 1700L, 1700M, and 1700H servers, but adds a second set of 1700J, 1700E, and 1700F servers to implement the F8.2, F4.4, and F6.8 file storage servers, respectively. Thus, the 1700J storage server acts as the 1700L standby server, the 1700E acts as the 1700M standby server, and the 1700F acts as the 1700H standby server. Although the examples provided include a file that is disassembled into 3 parts, it will be appreciated that a document can be disassembled into more parts if desired. To provide hyper-secure storage, the original file should never be parsed into less than two, and ideally no less than three pieces.

To illustrate the process of storing and reading redundant files with hypersecure file storage, it is useful to show the flow of messaging and file transfer functions overlaid on top of the SDNP network used to support the storage process. The network shown in FIG. 86 , for example, includes a client device 1700A implementing client node C1,1, router 1702G, signaling server 1715 implementing SDNP node S, name server 1714 implementing SDNP node NS, cloud servers 1701U implementing SDNP nodes M0,0, M0, 4 and M0.8 and SDNP file storage servers 1700H, 1700F, and 1000F implementing file storage nodes F7,1, F9,4 and F9,1, respectively.

FIG. 87A, the client device 1700A at the address "IP C1,1" makes a file request to the signaling server 1715 at the address "IP S" using the data packet 1710A, including the payload of the command and control system 1711A, containing a description of the file size and the required level of security and reservation. FIG. 87B signaling server 1715 sends data packet 1710B to server 1714 requesting the IP or SDNP addresses of nodes F7,1, F9,4, and F9,1 of the file storage server. The selection of file address server nodes to use can be randomly selected from a list of storage nodes or geographically based on a single node available near the client or in disaster free regions. The selection may also be based on performance parameters such as unused node memory, time to propagate file storage to a node, site reliability, and other similar factors. FIG. 87C, name server 1714 sends to signaling server 1715 a data packet 1710C containing the IP or SDNP addresses of nodes F7.1, F9.4, and F9.1 of the file storage server. Signaling Server 1715 computes Last Mile and mesh cloud delivery of processed files to 1700H, 1700L, and 1700M storage servers.

FIG. The 87D signaling server 1715 sends the data packet 1710D to the client 1700A, and the packet is routed from IP S to IP C1,1 through router 1702G. Data packet 1711D contains the 1711D command and control payload containing Last Mile routing for upcoming file transfers in zone U1, client zone, namely routing multiple packets from IP C1,1 to SDNP gateway over IP M0, 0 "with tag 1, tag 2 and tag 3 identifying each package (labeled as" tag X "for convenience). At the same time, the signaling server 1715 also sends a 1710E data packet to the SDNP 1701U gateway, the packet is forwarded from IP S to IP M0.0. The package includes a 1711E Command and Control payload showing cloud SDNP routing using Z1 credentials for a packet with ID tag X, in this case from the SDNP gateway address "SDNP M0,0" to the next node in the cloud, for example, at "SDNP M0.5" (not shown). In accordance with Dynamic Secure Communication Network and Protocol, the routing of data packets through the SDNP cloud using anonymous fragmentary transfer is dynamically selected based on the current state of the network in real time. In particular, the routing within the SDNP cloud of real-time data packets arriving at any SDNP gateway depends on the propagation delays of data packets between nodes within the SDNP cloud and the urgency of each real-time data packet assigned by signaling servers.

FIG. 87E signaling server 1715 sends command data packets to Last Mile nodes located on the storage side, i.e. in zones U7 and U9. As shown in the figure, data packet 1710F is sent to SDNP M0.4 gateway, packet is sent from IP S to IP M0.4 containing payload 1711F, signaling that tag 1 data packet should be anticipated by the gateway. node M0.4 and, upon receipt, is directed to the Last Mile address "IP F7.1". The second data packet 1710G is transmitted from the signaling server 1715 to the file storage server 1700H at the address "IP F7,1". The C&C payload for storage in zone U7 identifies an inbound packet with ID tag 1 from the source address "IP M0,4", but since the node function is storage and not communication, the destination field is blank; filled with a null value. Once the command and control data packets have been distributed over the network, subsequent file uploads are possible.

FIG. 88 illustrates the transport of fragmented data during hypersecure file storage when the client device 1700A sends a series of data packets 1712X with SDNP data files 1, 2, and 3 from the address "IP C1,1" to the SDNP gateway at the address "IP M0,0" using TCP protocol. Each data packet has a unique identifier, namely tag 1, tag 2, and tag 3. These files are then transferred through the SDNP cloud to other gateways, namely SDNP gateway nodes M0.4 and M0.8. A packet containing SDNP data 1 arriving at gateway M0.4 is transmitted in data packet 1712A from IP M0.4 to IP F7.1 over TCP with zone credentials U7, and data packets 2 and data 3 arriving at the gateway М0.8, with the credentials of the zone U9 in the data packets 1712B and 1712C from the addresses "IP M0.8" to the addresses "IP F9.4" and "IP F9.1", respectively. The vault can also include local encryption on the file server to prevent scanning of data on disk. This encryption process is local and not related to SDNP security. SDNP 1, SDNP 2, and SDNP 3 data packets contain the actual fragmented files in storage.

The preamble in each data packet, such as preamble 1 in data packet 1712A, may also contain an encryption key supplied by the client as part of symmetric encryption. Using a symmetric encryption key, the SDNP C1,1 client node generates a split key, one for encryption and its complement for decryption. The symmetric encryption key is then delivered to the F7,1 file storage server node, which is supplied by data packet 1712A in this example. In the future, when a client requests to read or access the contents of a stored file, the F7,1 file storage server node encrypts the requested file with this encryption key before sending the file back to the client. Since only the client has the corresponding decryption key, only the client can open the file for reading. While this method provides an additional layer of protection, it has the disadvantage that only one client can access a file for reading, preventing multiple owners of the file from being required to provide redundant access in the event of theft, damage, or loss of the original client device.

During the process of transmitting and storing data, the signaling server 1715 also sends "reply link" routing instructions to the 1700H, 1700L, and 1700M servers. The response link is a packet of data and a control system payload that confirms to the client that the write operation was successful and storage of each parsed file is complete. These messages are sent to the owner of the client file independently of each file storage server involved in storing the transferred parsed files. File servers send their write acknowledgment responses to the client independently and without knowledge, and write acknowledgment responses are sent using independent security credentials, including unique states other than those in effect at the time of writing. The routing of these messages does not necessarily use the reverse direction of the same routing path as for file transfers. This response could potentially be used by cybercriminals to track down the owner of the file. Instead, the response link uses the batch ID to notify the client that the saved files are part of the same file and are stored as part of the same fragmentary write operation.

During operation, the signaling server sends message routing on the response link to the file storage servers, the client owner, and to all SDNP intermediate nodes involved in the response routing. Signaling server 1715 coordinates the routing of response messages, and as shown in FIG. 89A uses data packets containing a command and control payload, for example, a 1700H file storage server receives a 1721G data packet containing a 1722G command and control payload containing header data for routing "link response 1" from IP address F7,1 to the IP address M _0.4 . SDNP M _0.4 gateway node receives data packet 1712F containing payload 1722F describing the routing of tag 1 data packet from address "SDNP M _0.4 " to another node within SDNP cloud (not shown), in this case address "SDNP M _0.4 ". Likewise, the signaling server 1715 sends to the storage server 1700M a data packet 1721M containing the link response tag 3 of tag 3 of the Last Mile routing instruction packet from IP F9.1 to IP M _0.8 . Although the routing of file data packets from the Last Mile store and their corresponding link response messages may be identical or similar, the routing of response messages through the SDNP cloud is likely to differ due to the dynamic nature of the SDNP cloud.

The actual routing of the response link message from the participating file storage servers is shown in FIG. 89B . As shown in the figure, the storage server 1700H responds with a data packet 1720A identified by tag 1 and carrying the "FS link 1" payload. The packet is routed from IP F7.1 to the SDNP gateway at IP M _0.4 using the U7 zone credentials. From the SDNP gateway, tag 1 data packet is forwarded through the SDNP cloud to the client-side gateway at "SDNP M _0,0 ", where the address is converted into Last Mile data packet 1720X and forwarded from "IP M _0,0 " to the address " IP C _1.1 "using TCP and U1 zone security credentials and contains tag 1 data, namely preamble 1 and FS reference 1.

Likewise, the storage server 1700L responds with a data packet 1720B identified by tag 2 and carrying the "FS link 2" payload. The packet is routed from IP F9.4 to the SDNP gateway at IP M _0.8 using U9 zone credentials. From the SDNP gateway, the identified tag 2 data packet is forwarded through the SDNP cloud (routing not shown) to the client-side gateway at SDNP M _0,0 , where the address is converted to Last Mile data packet 1720X and forwarded from IP M _{0 , 0} "to the address" IP C _1,1 "using TCP on the credentials of zone U1, namely preamble 2 and tag 2, for data transmission.

The third part of the parsed file, identified by tag 3 and carrying the "FS link 3" payload, is sent from the 1700M file storage server via a 1720C data packet. Tag packet 3 is routed from IP F9.1 to the SDNP gateway at IP M _0.8 using the U9 zone credentials. From the SDNP gateway, the identified tag 3 data packet is forwarded through the SDNP cloud to the client-side gateway at SDNP M _0,0 , where the address is converted to Last Mile data packet 1720X and forwarded from IP M _0,0 to the address "IP C _1,1 " over TCP using zone credentials U1 and contains tag 3 data, namely preamble 3 and FS connection 3.

FIG. 89C illustrates an example of the contents of a FS 1720A channel data packet directed from a storage server 1700H back to a client and file owner. As shown in the figure, the data packet includes Last Mile routing from IP F7,1 to the SDNP gateway at IP M0,4 using TCP in a packet with ID tag 1 generated in secure area U7. The 1719A response preamble describes the 1741A payload as well as additional security credentials used to execute or enhance the security of the 1720A data packet sent to the client for the FS channel. However, in three-way communications, the response security credentials contained in the 1719A response preamble are generally not required and are not associated with data used by the client to subsequently access and open hyper-secured files. The access credentials required to create a client link to a file stored on file share node F7,1 are contained in data field 1741A, including:

A unique network tag, SDNP address, or pseudo-address required to identify the file storage server that stores this portion of the fragmented file.

A description of the zone that defines the security credentials used to encrypt the file in the storage-side security zone (not the client zone).

An initial value of 1, which may contain numeric material or the time or state 920 used during file encryption prior to saving.

The initial value is 2, which can contain the numeric value 929, which is used to encrypt files as part of a save operation.

Key 1 containing a decryption key 1030 for decrypting the encryption on the "storage side" of the U7 zone. This key can be used in conjunction with shared secrets stored on the DMZ server running as part of the file storage server, or it can be a partial decryption key that can only be used in conjunction with other security credentials such as a numeric key.

Key 2 containing the encryption key 1022 sent to the client and used to send secure instructions from the client to the file storage server using a symmetric encryption key.

The file name or other information used to help the customer identify the saved file without showing how it is stored.

The above data packet is used for illustrative purposes and should not be construed as limiting the contents of the data packet to the exact elements or format as shown in the example. FS links 1720X received by the client node SDNP C1,1 after they are received from the file storage servers involved in storing the fragmented file are then processed to create a file connection for the client device. As shown in FIG. 89D , this operation combines FS references 1741A, 1741B, and 1741C using a blend operation 1753 to create an aggregate FS "file store read reference" 1754. The file store reference 1754 is hosted in the client's hypersecure text messenger or file management system, making it possible to invoke the hypersecure file at the touch of a button. Hyper-secured operations are invisible to the user. The owner of the file should not be bothered by the fact that the file is actually fragmented, encoded, and stored on a distributed file storage system. The file is called as if the file was located locally. Therefore, the FS link is a key element for accessing any file stored in the distributed file storage system.

A simplified representation of the FS link is shown in FIG. 90A , where all three file storage servers send their respective FS links to the client node C1,1 and their corresponding client 1700A, namely the 1700H file storage server sends FS reference 1, the 1700M file storage server sends FS reference 2, and the 1700L file storage server sends FS link 3. On the 1700A client device, the SDNP application software on client node C1,1 concatenates the three incoming FS links 1, 2, and 3 to form a link to the saved file. This combined link is displayed in SDNP Messenger as proof of file storage. When managing non-redundant files, the FS link information is sent only to the client device. To manage user files, the link can be named either at the time of a file storage request or after receiving a confirmation message.

Because the link to the file store is sent to the client directly from the file storage servers and not through the signaling server, only the client with the link has access to the file. This FS link is needed to call and read the fragmented file. Without a link, the saved file and its contents will be lost forever and become irreversible and irrevocable. To reduce the risk of losing the FS link, an alternative approach sends the FS link to two client devices - the client device and the secondary device. The accessory can be a second device owned by the customer or, in business cases, a second device owned by the company. Alternatively, the second device may consist of another server with its own security login and user identity verification.

Redundant link access to fragmented distributed files created in accordance with this invention can be applied to both redundant file storage systems, i. E. RRF ≥ 1, and not excessive. The use of a redundant reference in a distributed hyperprotected memory system without read redundancy (RRF = 0) is shown in FIG. 90B . In such systems, the mapping of files between parsed files 1706A, 1706B, and 1706C and the corresponding storage servers 1700H, 1700M, and 1700L is not redundant. As shown in the figure, FS links 1, 2, and 3 are sent to two client devices, namely a 1700A hosting an SDNP client node C1,1 and an additional client device 1700B hosting a backup client C2,1. If one of the FS links is lost or unavailable for any reason, you can use the FS link on the backup client to restore the files. In this regard, the distributed storage system SDNP describes the implementation of non-redundant read with redundancy on one channel, i.e. RRF = 0 and LRF = 1.

An example of hypersecured memory with link reservation is shown in FIG. 90C , where parsed files 1, 2, and 3 are mapped to two file storage servers, i.e. to implement the redundancy ratio RRF = 1, with each FS link sent to two clients to achieve the channel redundancy ratio LRF = 1. The storage system's immunity to read and connection failures means that the system can be viewed as a truly redundant hyperprotected file management system with an overall redundancy factor of 1 SRF. We define a storage redundancy factor SRF equal to the smallest RRF and LRF values. For example, if RRF = 0 and LRF = 1, SRF = 0, if RRF = 3 and LRF = 2, then the total storage redundancy is SRF = 2. To implement a common SRF = 3 system, each file must be stored on four separate file storage servers (as shown earlier in Fig. 85C ) and FS links must be sent to four separate clients.

Thus, SRF is a direct measure of the fault tolerance of a distributed storage system. This principle is summarized in FIG. 91 , where the abscissa describes the number of file storage servers used in the storage system and the ordinate describes the number of FS links sent to individual clients. As shown in the figure, one file storage server is not redundant, i. E. RRF = 0. Increasing the number of file storage devices improves read redundancy, but does not affect link redundancy. In contrast, sending a link to a single client does not provide channel redundancy, i.e. LRF = 0 regardless of the number of available file storage servers. In any case, i.e. for one storage server or one client connection, the overall SRF = 0, which means that the storage file system is not resilient, as shown graphically in the L-shaped area.

As shown in the figure, storing a 3-part parsed file on 3 storage servers results in a read redundancy of RRF = 1. If at least two clients receive an FS link, an LRF ≥ 1 link reservation is achieved. Combining LRF = 1 or RRF = 1 gives an L-shaped region 1724B where SRF = 1, i.e. provides some degree of system stability. Note that even with 6 servers, if FS links are sent to only two clients, the system still exhibits only a limited degree of robustness, i.e. SRF = 1.

By sending FS links to 3 clients and maintaining data redundancy across 6 storage servers, the 1724C region determines the conditions under which SRF = 2 provides a reasonably high degree of storage resiliency. Region 1724D illustrates further resiliency improvements when SRF = 3 using six file storage servers and four clients receiving keys. Thus, the bottom-most row and the left-most column have the lowest fault tolerance, and the top-right one has the highest.

The distributed hyperprotected file storage created in accordance with this disclosure provides long-term resilient security through adaptation, i.e. reusable, numerous innovative SDNP communication elements. These innovative elements include:

Parsing a file and distributing its fragmented content across multiple disconnected network file storage servers,

Transferring files between the client server and the file storage server using an end-to-end hypersecure connection containing a dynamically encrypted SDNP encrypted anonymous fragmentary data transport without using a master key,

Storing fragmented files on servers so that storage servers do not have access to the client security credentials that were used to initially fragment and encrypt data, i.e. so that the file storage server does not have "client-side" Last Mile security credentials to decrypt, access, or read the file.

Optional encryption of fragmented files on storage servers so that the client (file owner) does not have the security credentials required to decrypt the stored data, except for a secure connection, i.e. when the client side of the Last Mile does not have the security credentials of the “storage side” of the Last Mile used to decrypt files locally.

Limiting the number of links to the file storage required to find and open a file, and limiting the user's access to such links to the client device of the owner of the file along with backup or backup devices,

Requiring multi-factor authentication and client identity verification to create a link to a file and perform a read or delete operation,

Using anonymous data packet routing and anonymous file names, where even when using a link to retrieve data, no hypersecure storage location or encryption information is displayed, and where, apart from the link, no SDNP network or hypersecure file storage routing information is stored,

Distributing a fragmented file across multiple storage servers using undisclosed file server locations, excluding a file storage reference, using anonymous names unknown to the client, SDNP network, or other storage servers,

The use of three-link communications where SDNP signaling servers used to schedule file routing for distributed storage do not have access to the contents of fragmented files or security credentials used to encrypt files and where SDNP nodes used to transport files use SDNP data packets one hop without identification or client or file storage server address,

Regular use of dynamic file renaming and data movement after multiple access to files, recovery of security credentials during file overwrite operation; and

Local encryption of the file storage server directory to prevent file parsing.

With that said, the lack of any visible file identification, the use of a fragmented file distributed across the network (possibly globally), and the use of security credentials for specific zones makes it impossible to access the hyper-protected file and reconstruct it without accessing the storage link files. Such FS links, limited in number and distributed only through the SDNP communications system, are additionally protected by identity verification.

The execution of the above functions for a file hyper-secured storage can be schematically represented in the same way as the interaction of a hyper-secure communication using the functional symbols shown earlier in FIG. 9A. For simplicity, as shown in the upper illustration of FIG. 92 , any combination of scrambling function 926, junk data insertion 1053, parsing 1052 and splitting 1057, and encryption 1026 by state or time 926C may be represented as SDNP encryption function 1750. Similarly, decryption function 1751 includes decryption 1032, mixing 1061, deleting unnecessary data 1053B, and descrambling 928 using state or time 926B.

Using the aforementioned security functions, the upper illustration in FIG. 93A shows a client-side encrypted distributed file storage process. As shown in the figure, file 1705 is parsed 1052 and split 1057 to create a parsed file 1706 on client device 1700A used to implement SDNP client C1,1. The resulting file fragments are then encrypted using the U1 credentials by SDNP encryption operation 1750B for Last Mile communications in accordance with the methods described in this statement. File fragments transmitted over the Serial or Multi-Route Last Mile link are then received by the SDNP M0.0 gateway and decrypted using the SDNP 1751C decryption operation according to the U1 security data, allowing the processed file 1706 to be recovered. The processed file 1706 is then reapplied encrypted with SDNP encryption operation 1750C according to the security data of zone Z1 of the SDNP cloud. During mesh transfer, after a series of Z1 decryption and encryption operations in the SDNP cloud (not shown), the final data packets arrive at the appropriate SDNP gateways, including, for example, the M0.8 gateway, where the SDNP 1751D decryption operation recovers the parsed file 1706, then re-encrypts it using the SDNP 1750D encryption operation according to the security requirements of the U9 zones. In the example 1706 shown, the parsed file is split into two files, and the parsed files 2 and 3 of the parsed file 1706 are recovered using the 1751E SDNP decryption function and stored on file storage server 1740B and 1740C, respectively. In this method, the data files stored on the file storage servers are fragmented, but otherwise (with the exception of encrypting the local disk) the files will be available during a cyber attack on the disk data. Thus, security is achieved by file fragmentation and distributed storage.

A higher level of file protection is achieved by using the process shown in the lower illustration of FIG. 93A , which demonstrates the process of distributed file storage with full encryption on the client side. As shown in the figure, file 1705 is processed by SDNP encryption operation 1750A to create a scrambled, encrypted, parsed file 1706 on client device 1700A used to implement SDNP client C1,1. Operation 1750A also includes splitting file 1706 into three fragmented files 1, 2, and 3. Fragmented files 1, 2, and 3 are then encrypted using the U1 credentials with SDNP encryption operation 1750B for Last Mile communication, performed according to the methods described in this statement. File fragments transmitted over the Serial or Multi-Route Last Mile link are then received by the SDNP M0.0 gateway and decrypted using the SDNP 1751C decryption operation according to the U1 zone credentials, thus recovering the scrambled, encrypted, processed file 1706. Processed file 1706 is then re-encrypted with SDNP encryption operation 1750C according to the security data for zone Z1 of the SDNP cloud.

During mesh transfer, after a series of Z1 decryption and encryption operations in the SDNP cloud (not shown), the final data packets arrive at the appropriate SDNP gateways, including, for example, the M0.8 gateway, where the 1751D SDNP decryption operation recovers the scrambled, encrypted, processed file 1706, then re-encrypts it using SDNP 1750D encryption operations according to the U9 zone credentials. The fragmented files 2 and 3 of the scrambled, encrypted, and parsed 1706 file are recovered using the 1751E SDNP decryption function and stored on the file storage server 1740B and 1740C, respectively. Therefore, the file is protected not only by fragmented distributed storage, but also by a combination of scrambling, unnecessary data, and encryption known only to the client security zone. Similarly, file 1 is transferred via the SDNP cloud to gateway M0.4, where it is stored in file storage 1700H in zone U7, as shown with packet 1712A in FIG. 88 .

In both of the examples described above, a higher level of security can be achieved by eliminating the last SDNP 1751E decryption operation shown in the illustrations of FIG. 93B . Therefore, files stored on the file storage servers remain encrypted using the SDNP 1750D encryption operation using the security credentials of the U9 zone. In the top figure, the files are fragmented by the client, but encrypted according to the storage-side security credentials for zone U9. In the bottom figure, files are encrypted according to the client-side U1 security credentials, and then encrypted a second time according to the storage-side security credentials for the U9 zone. Such a double-encrypted file, in addition to being protected by fragmented distributed file storage, is a nested hyper-secure storage, since the file encrypted with the U9 zone credentials contains the file encrypted with the U1 security credentials. The advantage of nested security is that neither the client nor the storage server has the necessary information to open the stored file.

A brief description of exemplary methods for implementing disaggregated hypersecure file storage is provided in FIG. 94 . In the examples provided, the encryption and decryption used for hypersecure communications and SDNP cloud routing have been removed, which only gives the final effect of file encryption. The upper left corner shows an example of client zone fragmentation, where the document is fragmented according to the U1 credentials, but without any additional security measures from the NAS side. The lower left corner shows an example of client area encryption where the document is encrypted with operation 1750B, i.e. scrambled, junked, fragmented, encrypted according to U1 credentials, but without introducing any security measures on the NAS side.

The upper right corner shows the case of fragmentation of the U1 client zone, but where is the additional SDNP encryption step, i.e. scrambling, junk file insertion, fragmentation and encryption, introduced on the storage side according to the U9 zone. The lower right corner shows an example of a full nested file hypersecured storage, where the file is encrypted and fragmented according to the SDNP 1750B encryption operation from the U1 side of the client's credentials, and then the file is re-encrypted according to the security data of the U9 zone on the Last Mile storage side. ...

To revoke and read a file, the revocation of data must use security operations including anti-functions performed in the exact reverse order as shown in FIG. 95. In the upper left corner to revoke fragmented client zone data, parsed file 1706, called from various file storage servers, is combined using merge operation 1061 to restore the original file 1705. In the lower left corner, client zone encrypted data revocation, parsed file 1706 revoked from various file storage servers is recovered to access the original file 1705 using the SDNP decryption operation 1751H, the exact anti-function of the 1750B split operation, including mixing, decryption, descrambling. In the upper right corner, where the storage of encrypted files fragmented by the client zone is shown, the reverse operation first performs the SDNP 1751F decryption operation to undo the consequences of the U9 zone protection operations to restore the parsed file 1706, then the file merge operation 1061 to undo the effect of the file splitting operation 1057 in accordance with with zone credentials Z1.

In the lower right example, to read a fully nested hyperprotected file, data stored on various storage servers is decrypted by an SDNP 1751D decryption operation using the U9 zone credentials to recover file 1706, which is still scrambled, junked, parsed, and encrypted into according to the credentials of zone Z1. The SDNP decryption operation in zone Z1 of the 1751H then performs sequential 1750B anti-encryption functions including mixing, decryption, and descrambling to revoke the original 1705 file. The sequential file recovery anti-function operation must be performed in reverse order of the sequence used to create it. For example, if encryption involves splitting, then scrambling, then encryption, anti-function, i.e. decryption, should include the operational sequence of decryption, then descrambling and then mixing. If, however, encoding sequentially includes scrambling, then encryption, and then packet splitting, then an anti-function, i. E. decoding should include a sequence of mixing, decryption and finally descrambling of data packets.

To perform a revocation or "read files" operation, the client clicks on the "read file storage" link to initiate the steps required to revoke and read files stored on the hypersecure storage system of the system. The reading process includes the following steps as shown in FIG. 96A :

The file owner and 1700A client or authorized user clicks on the read file storage link in an SDNP application such as the 1196 SDNP hypersecure messenger, file manager, or other SDNP-enabled interface.

Using the 1765 dialog interface or command line, the 1700A client specifies a request for a 1761 file, including reading a file, editing a file (making a copy of a file with write access), deleting a file (deleting), updating a link (reissuing credentials), or redistributing a file (moving fragments of a file to various storage servers and release a new link for reading by the file owner or clients).

In a "verify clients" operation 1762, the SDNP signaling server 1715 verifies the identity of the client or clients requesting the file (authentication). In the dialog box 1767, the customer must verify their identity using a PIN and optionally a second factor that identifies the device or security token. Alternatively, the SMS message can be sent to another device belonging to the same customer. For files requiring access approval from multiple clients, the identity of each user must be verified (multi-authentication).

In a Privilege Check operation 1763, the signaling server 1715 confirms that the requesting client 1700A has read or read / delete (authorization) access to the requested file. The result is displayed in the 1768 dialog box before confirming that the user still wants to download or read the file. If the identity is not verified, the requester may be instructed to try again. After a certain number of unsuccessful attempts, the 1700Z file administrator (if any) will be informed of the unsuccessful attempts and the account will be blocked. A dialog box can inform the user of a problem, asking them to contact the file administrator, or, if a hack is suspected, the window can remain blank or even "kick" the user out of the SDNP application.

During the administration of the document request 1764, the SDNP signaling server 1715 informs the file storage administrator 1700Z of the file access request and the nature of the request (administration). This administrative step can (i) be skipped entirely, (ii) register a file access request with the file storage administrator account, (iii) send a message to the file storage administrator immediately informing him of an attempt to access files, or (iv) request permission of the file vault administrator through the 1769 dialog box before granting access to the client.

After these authentication, authorization and administration (AAA) steps, upon approval, the client makes a request to access the file using the steps shown in the flowchart in FIG. 96B, which is used here to illustrate a read request. These steps include the following:

When the 1770 read request is made, the requesting client 1700A sends a file read request to the SDNP signaling server 1715.

In the storage server name query 1771 mode, the SDNP signaling server 1715 sends a file storage server name query to the SDNP name server 1714, querying the current SDNP addresses of the respective file storage servers, such as the file storage server 1700M. According to the SDNP method, the SDNP address for SDNP clients (including file servers) is changed at least once a day to prevent long-term tracking of the client.

In a store name delivery operation 1772, the SDNP name server 1714 transmits the requested file names "FS addresses" to the SDNP signaling server 1715, whereby the SDNP signaling server routes file revocation.

In a 1773 routing operation, the SDNP signaling server sends file routing instructions to the 1700A client, nodes in the SDNP cloud, such as the 1700U server, and file storage servers with zone credentials, such as the 1700M file storage server with U9 zone security credentials, including status or time 920, digital key 923, encryption key 1030 and additional encryption key 1022 (used in symmetric key encrypted communication mode).

In a local file restore operation 1774, using appropriate security credentials, including file state or time information, the DMZ server on each storage side decrypts and recovers the parsed file and arranges the data into one or more data packets in preparation for transfer.

In 1775 file delivery, each parsed file is delivered to the requesting client using independent delivery over the SDNP network according to SDNP signaling server routing instructions, such as when the 1700M file storage server sends the file to the 1700A client.

Incoming parsed data files are decrypted according to the credentials of the client zone, and the parsed file is merged to recreate the original file, ready for viewing or transmission.

The steps are presented in the following sequence of illustrations. FIG. 97A client device at IP C1,1 makes a file read request to signaling server 1715 at IP S with data packet 1810A, which includes payload 1811A indicating TCP, file header information, and two or more FS links ... FS links anonymously describe the location of saved file chunks using tags or pseudo-addresses that must be translated to SDNP addresses or IP addresses for routing. Signaling server 1715, however, does not know the current SDNP address for these named user IDs and must request current information from the SDNP name server 1714. FIG. 97B, signaling server 1715 sends data packet 1810B to server 1714 requesting the IP or SDNP addresses of nodes F7.1, F9.4, and F9.1 of the file storage server. FIG. 97C, name server 1714 sends to signaling server 1715 a data packet 1810C containing the IP or SDNP addresses of file storage server nodes F7.1, F9.4, and F9.1. The signaling server 1715 then computes the Last Mile and the mesh cloud upload of the parsed files to the storage servers.

FIG. 97D signaling server 1715 sends command and control data packets to Last Mile nodes located on the storage side, i.e. to zones U7 and U9. As shown in the figure, a data packet 1810G is transmitted from a signaling server 1715 at S to a storage server 1700H at IP F7,1 with a payload including File Read Instruction 1 1811G. This packet instructs the file storage server to send a file with id tag 1 from IP F7.1 to the SDNP gateway at IP M0.4 using U7 security credentials. Simultaneously, data packet 1810F is sent to SDNP gateway M0.4, the packet is sent from address "IP S" to "IP M0.4" containing payload 1811F, informing that data packet with tag 1 should be anticipated by gateway node M0.4 and when received, redirected to SDNP cloud using security credentials Z1.31 for example SDNP address M0.

The second data packet 1810I is sent from the SDNP signaling server 1715 at IP S to the storage server 1700M at IP F9,1 containing the payload 1811I containing the File Read Instruction 3. This instruction instructs the 1700M File Storage Server to send a file with Id Tag 3 to the SDNP Gateway at IP M0.8 using the U9 zone credentials. Other command and control packages (not shown) are also sent to other file storage servers and gateways, such as nodes F9.4 and M0.8, as well as nodes in the SDNP cloud.

FIG. 97E, signaling server 1715 sends data packet 1810D to client device 1700A, and the packet is routed from IP S to IP C1,1 through router 1702G. The 1810D data packet contains the 1811D command and control payload informing the client that multiple inbound data packets with tag 1, tag 2, etc. can be expected from the SDNP 1701U gateway at IP M0.0 using zone U1 credentials. .d. At the same time, the signaling server 1715 also sends data packet 1810E to the SDNP 1701U gateway, the packet is forwarded from "IP S" to "IP M0,0". This package includes the 1811E command and control payload for Last Mile routing in U1, which is applicable to incoming data packets identified as tag packets 1, 2, and 3 from the SDNP cloud.

Once the command and control data packets have been distributed over the network, file transfers may follow. The first transmission step is shown in FIG. 98, where the 1741R data packet, including FS link 3, provides information on the 1751R SDNP decryption operation, including example state 920, numeric key 929, decryption key 1030, and encryption key 1022. On behalf of the 1751R SDNP decryption operation, this information is processed by the 1752 DMZ server to perform functions related to shared secrets, such as decrypting 1032R packets, 1061R mixing, 1053R junk file deletion, and 928R unscrambling, all are performed in state 920, in which the file being processed was last encrypted. Note that encryption key 1022 is not specifically required to decrypt the file, but can be used in symmetric encryption to send the parsed file back to the client and the owner of the file.

File routing and data transfer are shown in FIG. 99 including TCP data packet 1720A containing file 1 with address "IP F7.1" to "IP M0.4" using credentials U7, TCP data packet 1720B with address "IP F9.4" to "IP M0.8 "with credentials U9, TCP data packet 1720C with addresses" IP F9 "and data packet U1.0 with credentials M8.3 to" IPF9 ". After forwarding over the SDNP cloud (not shown), the 1720X series of data packets are delivered from the SDNP gateway at IP M0,0 to the client IP C1,1.

During the read process, the data is loaded into the SDNP application in read-only form. As long as the file is sandwiched in the SDNP application, it is protected by the application and SDNP network functions and is independent of the login procedures and inadequate security of the device operating system. It is widespread in business to have access to private documents for reading. Files prepared by finance, legal, manufacturing, engineering, and control departments illustrate sample materials that often contain read-only information. In many cases, these confidential company files must be transferred, i.e. distributed electronically to company executives for review prior to distribution.

Accidental or premature disclosure of transmitted information can have catastrophic consequences, entail severe economic and even legal consequences for the company and personal liability of its officials. For example, the unpublished financial statements of a public company are strictly confidential until they are published. In the United States, the “fair disclosure” rule means that information must be released to the public for everyone's access at the same time, without any preference. If any outside party gains access to this information before it is released, it is a violation of the "fair disclosure" rule. If the court determines that the violation of the “good faith disclosure” provision was due to the company's negligence in fulfilling its obligations to preserve and maintain the confidentiality of the document, then the company can be punished for the violation, and its officials can be held personally liable, even if selective disclosure was not followed by insider trading.

In the SDNP application, the resulting file is split into parts (in an isolated environment) to prevent data transfer from one account to another, i.e. files cannot be transferred between personal and business accounts. Depending on the access rights of the reader, the user may or may not be allowed to download the extracted file from the SDNP application and save it unencrypted to the device's memory. Uploading a file outside of an SDNP-enabled application compromises the security of the file and the data it contains. For data stored in the SDNP app, access is controlled, user actions are restricted, and both the device and the SDNP network must verify the user's identity. This multi-level and multi-factor authentication is much more difficult to bypass than the usual 4-digit PIN code required to open the phone. However, once a file is downloaded to a computer, tablet, or mobile phone, it is nearly impossible to prevent unauthorized access, determine who has access, or who made a copy of the file.

Thus, using SDNP communication, the owner of the file can block, i.e. Divide confidential documents and files into parts so that others can read them, but not download them to their phone. Additional measures can be taken to prevent screen shots or photographs of the LCD monitor. In other cases where security or privacy is not required, file transfers from the SDNP application to the phone memory are allowed and available for use without restrictions.

During the editing process, the edited form of the file is loaded into the device and transferred to the application needed to process the file. To execute a file request and exchange data on the SDNP network, there is no fundamental difference between a request to read a file and a request to edit a file, except in the operation of the SDNP client application - from the point of view of data transfer over the SDNP network, these operations are functionally equivalent. Therefore, the differences between read and edit operations can be viewed primarily as differences in the performance of operations at levels 5 to 7, which includes application-specific files.

To edit the resulting file, the application can be (i) an application built into the device (for example, Simpletext), originally used by the operating system of the device, but running outside the SDNP application, (ii) a third-party application running on top of the device OS, but outside the SDNP application, for example , Microsoft Word, Adobe Acrobat, etc. or (iii) a secure application running inside the SDNP application and not directly accessible from its OS. For example, a corporate press release can be edited in the SDNP app sandbox, but it cannot be loaded into the phone memory. As an additional condition to ensure the security of any file owned by the company, i.e. sandboxed at the SDNP Business Account branch cannot be transferred to a personal SDNP account, even if both profiles are running in the same SDNP application.

Once edited, saving the edited file back to SDNP storage servers does not overwrite existing data unless specifically requested by the owner of the file. Instead, the second version is kept in addition to the first, and removing the previous version will require the user to perform a delete operation. Since hyperprotected file vault invariably requires authentication, the process of saving an edited file may involve unique system functions that are not available from the file vault without special network interaction with the hyperprotected network. In this case, such a unique feature is the signature verification function used for the signature and date (in Asia for print / select and date) of the file. The signature feature can include a registered receipt sent to the owner of the document and the originator of the original document.

For a hypersecured data store created in accordance with this invention, the delete operation involves overwriting all existing parsed files with random numbers and an optional overwrite after an hour to further hide small but potentially noticeable changes in the electric or magnetic field of the stored bit. The file write will also be overwritten to make the process of writing the file to the data disk more confusing. After deleting the data and writing the file, the link to the client device is destroyed using the self-destruct function of the SDNP system message, and all remnants of the FS link are removed from the SDNP system. However, if a file system administrator monitors the activity of his user base using third-party software, he can retain metadata about the history of a file, including its owner, creation date, who and when accessed the file, when and how it was deleted, even if he has no access to the file itself.

SDNP and Last Mile hypersecure communication features can also support a variety of features and operating procedures for corporate accounts, not just personal accounts. As described above, the deletion operation on a personal account includes overwriting unnecessary data into the file, clearing the disk index record of the file's existence, and destroying all FS links to the previous file storage locations using self-destruct messages. For corporate accounts, however, the repository administrator may need to authorize them in advance to permanently destroy the file, for example, through an approval process similar to the dialog box 1769 in FIG. 96A , but sent to the administrator, not the owner of the file.

If the company file administrator does not allow file deletion, several scenarios can occur, including (i) notifying the owner of the file that (i) the file will not be deleted and the read link is stored in the SDNP application or the program's SDNP message history, (ii) notification the owner of the file that the file will not be deleted, that is, the file will be saved for "archival needs", but their personal link to read the file will be removed from the SDNP application using SDNP system self-destructing messages, that is, when trying to delete a file, only the administrator file storage will be able to restore it, or (iii) the link to read the file will be removed from the file owner's SDNP application using SDNP system self-destruct messages, but they will not be notified by the company because the file was saved.

Because the hypersecure Last Mile link is inherent in the functioning of a disclosed anonymous fragmented distributed file storage system, without a "file storage read link" saved files cannot be restored even by the system administrator.

For the administrator to be able to access the file, every time the file is saved or edited, there must be a corresponding read link from the file storage. While this level of control is possible for a corporate account, the sheer amount of data generated by tracking every change to every file will inevitably overwhelm any file management system. The smart filter available in SDNP only monitors file deletion attempts. With this approach, the administrator does not track the process of creating files, but only tracks attempts to delete them. Whenever the file owner tries to delete the file, a read link to the file store is passed to the database or the admin console for approval or archiving.

The size of the database can be further minimized by identifying the specific employees and contractors to be monitored. For example, if a company is involved in a financial audit or patent process, the parties are usually informed that they will not delete the relevant data or erase files. Through the file management features of the SDNP file storage system, any attempts by employees involved in an investigation can be tracked by recording attempts to remove or sending a copy of the file vault link to an administrator or, as the case may be, an independent investigator. This is useful because it limits the amount of data that needs to be monitored and naturally alerts management to suspicious activity that might attempt to conceal illegal activities. To prevent accidental or malicious loss of the link to the file storage as a result of the destruction of the device itself by the client and the owner of the file, you must use the backup links to the file storage described above. In the corporate segment, the backup can be stored on a computer located in a secure office or on a centralized company server.

In extreme security conditions, for example, for national security purposes, deleting a file can involve a multi-step method, including: i) overwriting the file with random data, ii) copying all other files from the drive to another storage device; iii) performing a bulk erase of the disk; iv) reformatting the disk; v) overwriting storage fields with random numbers; vi) copy saved files. Unlike conventional file overwriting, the bulk erase process affects the storage medium itself, automatically changing its electrical, magnetic or optical properties at random at the molecular level. A large electromagnet can be used for bulk removal on a magnetic drive, bulk removal on a flash drive can raise the temperature of the microcircuits and possibly expose them to ionizing radiation at an increased operating voltage. Mass deletion on magneto-optical storage devices can be performed using high-frequency magnetic fields. Bulk erasure on rewritable optical discs can be done with a bright scanning laser that scans the disc's tracks. In any case, mass deletion is an exceptional case when a storage medium, after deletion, either completely loses data, or is at risk of damage, which can lead to the impossibility of its reuse.

Another important factor in a distributed hyperprotected file storage system is maintaining the integrity of file data and link access. To prevent accidental loss of the link, it is useful to restore from time to time, i.e. validate the file share link and re-issue credentials. This process, referred to here as the " update link " command, can be initiated by the client or performed automatically, and can also be initiated from the file storage server after a certain period of time. For client-initiated requests, the SDNP signaling server associates command and control packets with the appropriate servers. After initializing the link update, as shown in FIG. 100, the files are read and decrypted by an SDNP 1751F decryption operation in state 320X, the "old" state at time t1, in which they were previously created using the credentials of zone U9. The file is then re-encrypted with an SDNP encryption operation 1750D using the new state 920Y at time t2 and stored in the drive. The updated vault link, such as link 3 FS, is then sent over the SDNP network back to the owner of the file, the 1700A client device. The resulting file contains encrypted data, updated with the credentials of zone U9 at time t2. However, the customer credentials in zone U1 used to generate and parse the file are not initially updated. To read the file, the read operation must first decrypt it using the U9 credentials in the state corresponding to the time t2, and then, after transferring to the client node C1,1, decrypt the file using the Z1 credentials associated with the file creation time.

As another security enhancement, the redistribution operation moves each parsed file of a specific link to the store of a new or different file storage server. The operation can send parsed files to brand new servers, or the files can be redistributed between existing storage nodes. In each case, the credentials are updated and a new FS link to the file is issued and sent to the client or clients who have access to the file. This operation is shown in FIG. 101 , where the contents of the SDNP file storage node F7,1 in zone U7 are decrypted by the SDNP 1751H decryption operation in state 920X, state t1 at the time the file was created. The file is then transferred over the SDNP network (not shown) to the file storage of the SDNP node F9,4, where the SDNP 1750L encryption operation is performed using the credentials of the U9 zone in the state 920Y corresponding to the time t2. The file is then saved, and the updated FS link is sent to the file owner and other clients who have access to the files.

Simultaneously with the aforementioned file transfer, the storage contents of the SDNP node F9,4 in zone U9 are amenable to the SDNP 1751L decryption operation using state 920X, the state that was observed during the creation of file t1. The file is then transferred over the SDNP network (not shown) to the file storage of the SDNP node F9,1, where it is encrypted with the SDNP 1750M encryption operation using the credentials of the U9 zone, at state 920Y which corresponds to the time t2. The file is then saved, and the updated FS link 3 is sent to the file owner and other clients who have access to the files. Similarly, the contents of the file store SDNP node F9,1 in zone U9 are decrypted by the SDNP 1751M decryption operation using state 920X, which was observed on the moment the t1 file was created. The file is then transferred over the SDNP network (not shown) to the file storage of the SDNP node F7,1, where it is encrypted with the SDNP 1750H encryption operation on the U7 zone account in the state 920Y, corresponding to the time t2. The file is then saved, and the updated FS link 1 is sent to the file owner and other clients who have access to the files. Thus, all three files are moved and given new security credentials, and clients with permissions are given new links to read the file store based on updated FS links 1, 2 and 3.

Another necessary support function performed by the hypersecure file storage system is the scanning of files that do not have direct links, i.e. "Zombie Files". This operation is similar to the update link operation, except that the file storage server and not the client or file owner initiates it. During operation, each file storage server keeps track of the time elapsed since the last time the file was accessed. If the last operation on a file exceeds a specified time interval, such as a month of inactivity, the file storage server contacts the client or clients to confirm that the link is still active. The file storage server can communicate with the client using the same method as for sending the FS link. While storing the file, the vault server stores the SDNP zip code or pseudo-address of the client.

If no action occurs within the specified time interval, the file vault server will contact the SDNP signaling server and ask for confirmation that the connection remains active. The SDNP signaling server then schedules a delivery route for the FS link check request for each participating file storage server. Each file storage server then sends a request to the client over the SDNP network. Each SDNP client node involved in the process responds with an acknowledgment that the file link is still present on the device. If the link to the file is confirmed, the client will have the opportunity to update the link. If, however, no device responded, i.e. the active link to read the file has not been saved, then the storage server reports the disappearance or loss of the file, and after some time, for example, after a month or three, the unclaimed file will be permanently and irrevocably deleted.

Registered link - Another feature of the SDNP communication created in accordance with this invention is the ability of the network to deliver or store "registered links". Registered communication includes hypersecure delivery of information or hypersecure file storage in the form of messages signed with a temporary seal, including the ability to electronically sign and electronically rewrite for purposes of establishing the legal force of the message. The registered communication also includes the ability to send a "certified message" with a handshake acknowledging receipt of a document or file using a timestamped signed response. All registered communication initiated by the SDNP application on the client device is certified through the Last Mile communication, i.e. SDNP Last Mile links. Any attempt by the client to fraudulently alter the confirmation signature will result in a mismatch between the message and the network confirmation record, i.e. receipt report.

Due to the use of "state" in SDNP communication, i.e. time and other unique variables used to create special credentials to ensure the security of messages in communication and file storage, time stamping is an integral part of SDNP communication. An example is the SDNP application window 1800 shown in FIG. 102 , where each text message sent and received has a corresponding set of timestamps 1801A and 1801B indicating when the message was sent, when it was received, and when it was read. Time information, containing a pointer to the total time set by the SDNP signaling server, is delivered to the client over the Last Mile network. The SDNP client application then integrates the timestamp into the information display.

In a registered connection, the communiqué generates an official seal. One example of a registered communication process is shown in FIG. 103 , where the hypersecure message is executed starting at the optional file attachment step 1802, including a dialog box 1803, where the client sending the message or file, i. E. sender, selects whether to attach the file to the message, using the directory browser to locate the file. Dialog box 1804 is used to send a registered message in accordance with the dialog box 1805, in which the delivery method is selected - regular or registered. The message is then sent using a hypersecure link prepared in accordance with this invention.

In step 1806 "Message Accepted", the recipient performs a series of steps required to verify the identity to access the message and send an authenticated statement confirming acceptance of the incoming message and file. This process begins with a receive authentication operation 1807 where the recipient is asked to verify his identity. Without authentication, the recipient will not be able to access the message, the message will be destroyed, and the sender will be notified of the failed authentication process. This way, the sender can be alerted that the recipient may have stolen their device. After the identity is verified, the recipient is asked by the receive authorization operation 1808 if they want to accept and reject the incoming message or attachment. If the message is rejected, the sender will be notified.

If the recipient accepts the message by selecting "yes", he must follow the administrative step 1809 to sign it by choosing an electronic signature (e-sign) and / or choosing a seal / stamp (e-chop). The sender can specify the required parameters. In some countries, both the stamp and signature must be legally binding. A subsequent dialog box (not shown) instructs the user to find his signature or stamp in the device's file directory. Audio / video can also be used as confirmation. The recipient will be instructed on what to read while writing. Once the message is signed, it becomes visible to the recipient, and the attached file becomes available for viewing and possibly downloading, depending on the sender's requirements.

Upon receipt of a document, a notification of receipt of a message indicating the time 1811 identifying the recipient of the message, the received text and attached file name, data and time of receipt of the message, a signature including an electronic signature or stamp, an audio-video recording or a combination thereof, is sent to the sender in confirmation operations 1810. In the archive message receipt notification option 1812, the sender has the option to save a copy of the signed message with a time stamp 1811 to a hypersecure file storage system for which the sender will receive a link to read the file 1813 necessary to revoke the message. Alternatively, message receipt notification 1811 may be available for download to the sender's device.

Encryption-based security issues - State security authorities claim that in the modern world of corporate fraud, theft of intellectual property, cybercrime, hacking, criminal gangs, drug cartels, mafia, yakuza, jihadists and terrorists, any communication system that provides callers with untraceable anonymous communication, that is, a system with encryption for protecting data and hiding identity is an irresponsible business practice for network operators, application developers and device manufacturers.

Unfortunately, communication based on encryption for security does protect both criminals and law-abiding citizens. As previously mentioned, the topic has been the subject of countless news stories about the criminal activities of ISIS terrorists and their attacks on Paris and Belgium via the Telegram phone app. This application enables secure communications using end-to-end encryption, also known as end-to-end encryption. Since decryption keys are held by only two parties and not on the network or the intervening operator, end-to-end encryption makes life difficult for security services. Anti-Telegram security forces argue that end-to-end encryption using large keys poses a threat to national and even global security by allowing terrorists to covertly operate using open communications. The case for Telegram supports privacy at all costs.

Privacy disputes re-emerged in the December 2, 2015 shooting in San Bernardino, California, which killed 14 and injured 22, when a federal judge ruled in favor of the FBI for ordering Apple to help "open" a locked phone, allegedly owned by the shooter. In an article published February 17, 2016 in the Washington Post, entitled "Apple vows to resist FBI requests to hack iPhone associated with attacks on San Bernardino." Apple and their CEO cited several reasons why they refused to comply with the court order. The text of the article can be found on the Internet at (https://www.washingtonpost.com/world/national-security/us-wants-apple-to-help-unlock-iphone-used-by-san-bernardino-shooter/ 2016/02/16 / 69b903ee-d4d9-11e5-9823-02b905009f99_story.html),

In particular, Apple has steadfastly argued that it was unable to unlock its new iPhone for law enforcement even when police officers receive a warrant because they are designed in such a way that the decryption key is not in Apple's possession, which, in fact, creates another example of the problem. end-to-end encryption. Apple claims that only the user of the phone or someone who knows the password can unlock the phone. The government denied that they did not need to unlock the encryption feature by simply disabling features that erase the phone's memory after ten failed login attempts. In an online address, Apple CEO Tim Cook countered the move against the dangerous security degradation of the iPhone. “Once created,” he wrote, “the method could be used over and over again, on any number of devices. In the physical world, it would be equivalent to a master key capable of opening hundreds of millions of locks - from restaurants and banks to shops and houses. the person will not find it acceptable. " He continued, "Opposing this order is not an easy task. We believe we must speak up in the face of what we consider to be excessive US government interference."

Apple's latest thesis that the US Department of Justice has exceeded its mandate is a legal argument, not a technical stance, that echoes the view of constitutionalists and privacy advocates that the state has no legal right to control communications or infringe on privacy. person for no good reason. While the particular San Bernardino case clearly meets the requirements of a probable cause, the idea of creating a universal backdoor that any communication device can open is said to encourage abuse by the authorities. In an article on February 23, 2016, The Atlantic agreed that "Apple is right: the FBI wants to hack a bunch of phones." On the same day, The Guardian reported that "the FBI is looking for access to a dozen iPhones, Apple claims."

Ironically, the same stance in favor of confidentiality has been taken by the United States Congress. On March 1, in a follow-up to the Guardian story titled "Congress tells the FBI that forcing Apple to unlock its iPhone is a" stupid task, "US lawmakers accused the US Department of Justice of abuse of power and undermining privacy." The road to hell begins with a backdoor, "the general said Microsoft attorney Brad Smith at the RSA conference in San Francisco Smith challenged the computer security industry represented at the meeting to "join Apple on this important cause."

During the firestorm, many security experts, including NSA whistleblower Edward Snowden, made public the position that unlocking a phone is not as difficult as the FBI had assumed. Speaking via video link from Moscow to the Common Cause program project at the Great Democracy Conference (March 8-9), Snowden said: “The FBI says Apple has 'exclusive hardware' to unlock the phone. With all due respect, this is bullshit. . " The FBI said that even before the case went to trial, they had already found a way to hack the locked iPhone. On March 29, 2016, an article in Fortune magazine stated: "The FBI may not tell Apple how they managed to jailbreak the iPhone."

The legal and geopolitical implications in the Apple-FBI case are long-term. Following the FBI's initiative, other countries are expected to push backdoors on all communication devices connected to their network, including the phones of US citizens traveling overseas. Moreover, now that the iPhone has been successfully jailbroken, criminals are bound to discover or reinvent these methods to engage in new forms of cybercrime and identity theft. To avoid being tricked by criminals, governments may seek to use the same techniques to expand surveillance and espionage, and even different departments within the same government may use these techniques to spy on each other's activities. In relevant articles, representatives of various government agencies are considering limiting the level of encryption used in end-to-end communications.

Taken together, these events clearly confirm the realization that no visible combination of security and privacy practices currently available in the public domain, at least without assisting criminals and terrorists, provides security and privacy. The problem arises from the exclusive reliance on encryption to achieve network security or end-to-end communications, and the associated confidentiality of information. Increasing the security of text, voice or files by increasing the bit size of the encryption key makes any communication safer and more difficult to break. Enhanced Security protects businesses and law-abiding citizens in terms of security and privacy, and in the fight against identity theft. Unfortunately, the same security enhancements indiscriminately protect criminals and terrorists from detection, allowing them to operate in secrecy and with impunity.

This aspect is illustrated in FIG. 104A , where the caller 1825A calls 1825Q over an unsecured network, such as the Internet 1821, which is susceptible to various cyber attacks, i. E. has a large "attack surface" vulnerability. To reduce the "attack surface", encryption 1026 and decryption 1032 are used to form an encrypted channel or tunnel 1820 with a smaller "attack surface" than network 1821. The problem is that a large encryption key must be used. As shown in Table 1824, the larger the encryption key, the more combinations exist and the more difficult it is to break the encryption key. Encryption is used for two purposes: (i) to provide network security to prevent man-in-the-middle attacks, and (ii) to ensure the confidentiality of caller information through end-to-end security. As you can see from line 1823, any improvement in network security results in an equivalent increase in endpoint security. Strong network security is useful for preventing malicious attacks, but excessive end-to-end encryption is a double-edged sword. If a large key size is used, such as AES256 or AES512, the system provides "top secret" network performance and, of course, the same level of security for callers. However, in the event that the caller is suspected of crime or terrorism, neither the network operator nor the government will be able to detect or monitor their activities.

The key size tradeoff is complex. If the encryption key is too small, attackers can attack the network and its users. If the encryption key is too large, criminals can use the network to hide their illegal activities and thwart the investigator's efforts to identify ongoing fraud and misconduct. In a corporate setting, a company's security policy may opt out of end-to-end encryption altogether because it interferes with employee tracking or compliance with corporate investigations and lawsuits regarding intellectual property protection.

Even determining which key size can be broken and which is secure is a daunting task that changes with advances in technology. Referring to table 1824, the number of possible combinations to be analyzed in a brute-force attack is calculated as a function of the cipher key size. Whereas a 16-bit key has only 65 thousand combinations, a 56-bit key has 10 ¹⁶ combinations, and a 128-bit key has more than 10 ³⁸ combinations. A 256-bit key has combinations exceeding a 128-bit key by 39 orders of magnitude. Ignoring the use of pattern recognition, a brute-force attack attempts to break the code with any combination. In an EETimes article entitled "How Reliable Is AES Protected Against Brute Force Attacks?" force "at a speed of about 10.5 petaflops per second. Petaflops is 1,000 trillion, or 1015 floating point operations per second, or 1,000 teraflops. Thus, a 56-bit key requires only 399 seconds, a 128-bit key requires 1.02 × 1018 years, a 192-bit key requires 1.872 × 1037 years, and a 256-bit key requires 3.31 × 1056 years.

The time it takes to launch a brute force attack also varies. Since this article was written, the speed of the world's fastest computer has already tripled. In a July 30, 2015 BBC news article entitled "Supercomputers: Obama Orders the World's Fastest Computer," the researchers reported that the target speed of the next-generation supercomputer is twenty times that of the record-breaking machine. a machine capable of performing one ex-flop, or a billion floating point operations per second. This means that the time it takes to break encryption is getting shorter every year. Another, newer, approach to cracking encryption is massive parallel processing, similar to how bitcoins are mined. Rather than using a single supercomputer, using thousands or millions of computers at the same time will allow attackers to be attacked simultaneously, proportionally reducing the brute force attack time. Today's fastest microprocessors have already broken 1.1 teraflops, so thirty thousand best-in-class microprocessors working together are nearly equal to the fastest computers in the world. Only one million microprocessors are needed to implement the exaflops of a computer. Specialized ASICs could further weaken security, while quantum computing promises to change computing power by many orders of magnitude.

In conclusion, it should be noted that encryption with a large end-to-end encryption key is not a good solution for ensuring confidentiality and security in communication. An alternative approach supported by SDNP networks and Last Mile hypersecure communication separates end-to-end encryption and network security as described in this document. As shown in FIG. 104B , communication between SDNP 1700A and 1700Q clients representing the caller and called subscriber, respectively, is carried out over the SDNP 1831 network. A small network attack surface is implemented by anonymous, multi-route and mesh data transmission traffic using dynamic encryption, fragmentation, garbage insertion, encryption on each hop, routed using a three-way link for control. Although Last Mile communication and each hop within the SDNP cloud is associated with a dynamic credential change, this process is simplified through the SDNP 1832 encryption operation and the SDNP 1833 decryption operation.

As described in table 1834 and illustrated by line segment 1830, these methods, in various combinations, provide security equivalent to secret or top secret encryption standards without relying solely on encryption. Since line segment 1830 is flat, it means there is no relationship between end-to-end encryption, shown on the y-axis, and network security, shown on the x-axis. Instead, the level of network security can be adjusted from case A to case D using various SDNP security techniques. These security operations are performed by SDNP software in such a way that the caller and called party do not know the security credentials used to transport data packets over the SDNP 1831 network and its various security zones. In particular, the interlocutors deliberately do not participate in any key exchange of the "Last Mile" network. In a distributed network, the use of encryption in the SDNP cloud is not related to the security of the Last Mile, and there are no master keys for the system. Thus, the security of the SDNP 1831 network is independent of end-to-end encryption performed by encryption 1026 and decryption 1032 to create an encrypted channel or tunnel 1820.

The encryption used by SDNP 1831 does not need to use keys of the same size as the 1820 end-to-end tunnel encryption. As shown in the graph, commercial and enterprise applications can use a 128-bit encryption key to secure end-to-end encryption (for example, AES128 ), shown by dashed line 1835, even if AES256 is used in SDNP cloud SDNP dynamic encryption. In fact, end-to-end encryption can use RSA or other ciphers without compromising network security. SDNP 1831 is still protected by military-grade FIPS140-2 AES encryption, even though the 1820 encryption tunnel is not end-to-end. As described above, SDNP 1831 protects against all external cyberattacks and man-in-the-middle attacks. The 1820 encrypted end-to-end tunnel protects subscribers from mobile operator interference and other hacker attacks. As such, end-to-end encryption in this disclosure is primarily used to ensure the privacy of the callers and not to secure the transmission of data packets.

Since end-to-end encryption can be increased or decreased in power, or even eliminated without compromising network security, this method can be adapted to a wide variety of applications. For example, if the encryption of a 128-bit key, shown by the dotted line 1835, is too complex for small businesses or personal use, the number of bits can be reduced without compromising security. In military or government applications, the encryption key length can be increased to 192 bits, 256 bits, or even 512 bits as needed. In this regard, the disclosed SDNP system eliminates the shortcomings of modern encrypted communication, offering functions that are not available for any alternative application, device or network.

Security administration “Another key feature of SDNP communications is its unique approach to security administration. Security administration is necessary in many situations, including:

Tracking the communication options of employees in accordance with HR policy or investigations carried out by employees,

Tracking and recording employee requests for financial audit, forensic accounting or financial reporting,

Documentation of intra-corporate communications within the framework of a takeover and merger transaction,

Documenting intercompany communications in intellectual property litigation or corporate disputes,

Compliance with communiqué and document requirements in accordance with subpoenas and criminal investigations,

Compliance with legal regulations regarding accounting information, tracking calls and messages, and access to files on national security issues.

With the appropriate authorization, the SDNP network administrator can allow SDNP network traffic to be accessed by a designated "SDNP security agent" to monitor communications and control data. The SDNP Security Agent creation and enablement process includes a multi-layered approval and authentication process that must be completed prior to monitoring. To prevent abuse, no one can initiate surveillance on their own, not even the SDNP network administrator. Due to the dynamic nature of SDNP as a distributed network devoid of centralized management, having no host network keys, and using dynamic encryption and SDNP decryption, performed using special zone security credentials operating autonomously in DMZ servers, there is no mechanism for data recovery and call invocation post facto ... Data is only stored on the SDNP network for a short period of time, typically less than 100 milliseconds. As a distributed system, the SDNP network inherently lacks centralized management, without which even the metadata of previous calls is not available. Thus, the SDNP network only supports security monitoring a priori, i.e. Tracking by a designated SDNP security agent must be carried out prior to interception.

Moreover, due to the dynamic nature of fragmented communication within the SDNP cloud, no SDNP node inside the cloud, i.e. outside the SDNP gateway, does not carry full conversation data packets. Most nodes transmit no more than 5% of the data and usually only 10ms at a time before re-routing. In accordance with the SDNP protocol, dynamic routing constantly redirects communication through various media servers. Therefore, cloud access as such is not useful for recovering or monitoring information. While SDNP cloud data packets can be intercepted, they are a useless mix of unrelated sounds, data, conversations, and junk data. Instead, snooping with a designated SDNP security agent can only be productively performed in the Last Mile, where the entire set of relevant data packets must pass either inside the client device or, preferably, in the SDNP gateway.

An example of routing data packets for security surveillance is shown schematically in FIG. 105A, where the SDNP 1840 security agent monitors communication between the SDNP 1600A client device and the SDNP 1600H client device. While the conversation takes place using data packets sent from the client SDNP 1600A through the 1602G Last Mile router to the SDNP 1701U gateway and through the SDNP cloud, the data packets sent from the 1600A client are closed by the SDNP 1700U gateway and reliably routed to the designated security agent SDNP 1840. In particular, when transmitted over UDP, the Last Mile data packet 1630A transmits SDNP data 1 from the SDNP client at IP C1,1 to the SDNP gateway at IP M0,0, which leaves the gateway SDNP at "IP M0,4" and is forwarded over the U7 "Last Mile" zone to the "IP C7,1" SDNP client address. During authorized surveillance, the cloned SDNP-1 data is securely transmitted to the SDNP Security Agent 1840 at the SDNP IP SA. Cloned Surveillance Data Package 1841 works the same as SDNP Group Call, except that duplicate data clones are invisible to callers. Therefore, the callers do not know that they are being monitored.

Security tracking works for incoming calls as well. FIG. 105B, SDNP-7 data is being sent from the 1600H client device at IP C7,1 to the SDNP gateway at IP M0,4. After being transferred through the SDNP cloud, the data from the SDNP gateway is delivered to the IP M0,0 address to two destinations. The first destination, client 1600A at IP C1,1, receives a 1640A response packet containing SDNP 7 data. The second destination, SDNP 1840 security agent, receives an identical payload containing cloned SDNP data 7 via packet data 1842. The delivery of data packet 1842 is invisible to callers, so they do not know that they are being monitored.

The same approach applies to monitoring fragmented distributed file storage. However, instead of intercepting fragmented data files, the security agent should only obtain a copy of the corresponding FS links. For example, in FIG. 106 shows that the SDNP 1700H file storage device sends a 1740H data packet containing FS reference 1 from IP F1.1 to the IP M0.4 gateway address, which is routed through the SDNP cloud to client 1600A over the 1740A data packet. The cloned FS link 1 payload is also forwarded to SDNP 1840 at IP SA on data packet 1843 sent from IP M0,0 gateway. As with real-time communication, the owner of the file, client 1600A, is unaware that it is being monitored by an SDNP security agent.

The same surveillance mechanism works for Last Mile multi-path communication when data packets enter and leave the SDNP cloud through more than one SDNP gateway. This case is illustrated in FIG. 107 , where Last Mile communication from client device 1600A includes discrete data packets 1630A containing SDNP payload data 1 and data packet 1630B containing SDNP payload data 2 entering the cloud via SDNP gateways 1701U and 1701V, respectively. After SDNP cloud routing, data packets are recombined and displayed out of the cloud as a single 1630L data packet with a payload containing combined SDNP 3 data data. During operation, SDNP gateways with addresses "IP M0,0" and "IP M0,11" are transmitted signaling server to create clones of incoming data SDNP 1 and SDNP 2 from the client node C1,1 and send them to the security agent SDNP 1840 at the address "IP SA". The cloned data is sent in data packets 1841A and 1841B using the same hypersecure communication methods as for all SDNP data transfers, except that the security agent operates in its own unique security zone, i.e. SA zone using credentials not available to any other device. As such, there is no record or evidence that the designated security agent ever followed this or that conversation.

Since SDNP's surveillance activities are covert and inherently equivalent to an invisible conference call, it is essential that SDNP uses independent checks to approve and confirm the use of network surveillance, and to appoint and validate an SDNP security agent authorized to perform surveillance. An SDNP Security Agent can be any SDNP client other than a network administrator. To protect against system damage, any SDNP network operator or SDNP administrator is not allowed to act as an SDNP security agent, i.e. those who operate the network cannot disrupt its ability to use it for themselves, even if they are threatened or blackmailed.

An SDNP security agent can be an individual, a government agent, an authorized government representative, or a legal officer. The specific qualifications required for a designated security agent vary by company or country in accordance with applicable local laws. An SDNP security agent may include a communication device or computer server capable of recording, storing data, and comprehensively decrypting data. All messages sent from the SDNP network to the SDNP authorized security agent are transmitted using the same hypersecure communication as the client messages themselves, and therefore security surveillance does not violate the confidentiality of the call or the confidentiality of the caller, except for surveillance by the authorized security agent ...

Moreover, the implementation of the traceability and allowed capabilities of an authorized SDNP agent in no way compromises the integrity and security of the network. No operational details or DMZ shared secrets are disclosed to the network operator or any security agents - SDNP operates automatically and autonomously, without human intervention or intervention, while DMZ servers provide security using zone-specific credentials that are not available via online access. Thus, security tracking does not compromise the security of the system or make the SDNP network vulnerable to cyberattacks.

The data payload is delivered to the SDNP security agent in the same form as generated by the caller. As part of delivery to the SDNP security agent, all SDNP network encryption is decrypted so that the delivered data packets do not contain network security provisions . However, if the client uses end-to-end encryption , the SDNP security agent will need to break the client's end-to-end encryption, unless the client agrees in advance to share end-to-end encryption keys with the network or use an independent key server available on the SDNP network. Again, such end-to-end encryption and decryption keys are primarily included in the SDNP method for privacy purposes and are not associated with any encryption used in the SDNP dynamic encryption function.

To minimize the risk of tracing abuse, SDNP administration used to create and authorize a designated SDNP security agent to track a client or group of clients is a multi-step process. While the SDNP system includes provisions for oversight, the lawful use of this function is the responsibility of the network operator, network administrator, and the designated agency or agents. Together, these parties are personally responsible for ensuring that surveillance is carried out lawfully and in accordance with the laws of the country in which it is being monitored.

The need for supervision can arise from any number of situations. In a company, a whistleblower complaint or sexual harassment report may trigger a personnel investigation or expedited forensic investigation. Subpoena related to litigation (potentially including a nondisclosure order) may also be required in tracing. In corporate matters, communication using the company's SDNP network is generally limited to corporate messages and does not extend to private and private messages. In most countries, private messages are protected, unless there is suspicion of criminal intent. In cases of national security or law enforcement action, both public and private SDNP accounts of the caller may be traceable. In such cases, the company's corporate SDNP network operator will monitor the company's communications, while the independent telecommunications network operator SDNP will be the only provider capable of monitoring the caller's private communications. In some countries, the government must submit a subpoena approved by a judge to begin surveillance of private citizens, while in other countries the government may assert the right to monitor any private connection on a de facto basis. In cases of international communications, it is more difficult to determine which laws apply and what the position of the network should be to allow call tracking.

One example of an AAA process used to enable surveillance is illustrated in FIG. 108 . The client surveillance approval process includes a network administrator 1850 used to organize surveillance, a security agent 1840 in charge of client surveillance, and three authorized agents 1851A, 1851B, and 1851C used to approve the surveillance process, preferably operating autonomously and independently of the operator. network or network administration. The process begins with the 1850 network administrator seeking an 1862 surveillance request in response to a request for an investigation or court order. Using the command dialog box 1862, the administrator specifies the telephone number of the person for whom tracking is requested. If the request for surveillance concerns a group of individuals, they can be entered one at a time into the system in a file that lists all parties and their respective telephone numbers can be loaded into the system.

At the authorization stage 1863, the network administrator 1850 identifies the recommended security agent 1840 for the monitoring function using the dialog box 1864. In corporate matters, an individual can be a human resources manager, legal advisor, member of the audit committee and representative of an independent audit firm, and also independent investigator. In legal matters, the security agent can be a legal officer, a district attorney, an FBI agent, or another duly appointed member of an investigative committee, for example, in cases of government abuse, such as a special board of inquiry of a committee of inquiry. The system then checks the SDNP 1714 nameserver to ensure that the security agent has an SDNP account and adheres to company or network operator policies. In some cases involving national security, a follow-up investigation may be conducted into the credentials and criminal records of security agents prior to their approval.

Once the security agent is approved at authorization stage 1865, a surveillance request is sent to authorized agents 1851A, 1851B, and 1851C, who review the information provided in the 1866 dialog box, including the item description name, name or title of the security agent tasked with the surveillance task. the expected duration of the observation and the reason for the observation. Each authorized agent can accept or reject the request. The network operator's or company's rules determine whether a surveillance operation will be approved based on unanimous approval from approving agents or by simple majority. The identity of authorized agents may be known, and in corporate or criminal cases, their identity may remain anonymous, protected by the anonymous means of communication of the SDNP network.

After surveillance has been approved, in administration step 1867, the client database 1868 is updated on name server 1714 to mark the SDNP client to be monitored, and the shaded line is used in this example to identify an SDNP client authorized as a security agent data. SDNP addresses in this database are updated daily as SDNP addresses are reshuffled to maintain the relationship between the monitored client and the designated security agent. Upon expiration of the validity period, the monitoring channel is automatically terminated. In an administrative step 1869, a link is sent to the SDNP security agent 1840 allowing it to receive all ongoing communications from an identified monitored client. The use of this information is not a matter of the SDNP network. Unauthorized disclosure by a security agent of a person's personal information may constitute a crime for which the security agent is fully responsible.

With this innovative surveillance method, the SDNP network is thus able to support criminal investigations into misconduct and potential terrorist activity, while providing a secure communication environment for law-abiding citizens. The SDNP network is able to securely provide private communications for clients to authorities in accordance with legal court orders, without risking the privacy of innocent civilians and without compromising the security of the SDNP global communications network. Because no backdoor or master key is used to enforce court orders, further communication over the SDNP network remains anonymous and hypersecure. In this way, the secured network and dynamic communications protocol and its hypersecure Last Mile communications are able to offer security features that are not available in any other way, and completely eliminate the risk of contributing to crime and terrorism arising from over-reliance on end-to-end encryption used by OTG and virtually everyone. messaging apps.

Overcoming SS7 Protocol Vulnerabilities - If suddenly the disagreements between the FBI and Apple could seem such that they do not sufficiently convey the existing problems in the field of telecommunications and security, then the video "Hack in 60 minutes" (http://www.cbsnews.com/news/60-minutes-hacking-your -phone /) clearly demonstrated a serious security vulnerability in signaling protocol 7 or SS7 (or SS7), the signal control channel for conventional wireless telephony. As demonstrated in the series, the SS7 vulnerability exposes every smartphone and connected device to the potential risk of eavesdropping and cyberattacks, allowing you to eavesdrop on conversations wirelessly and view SMS messages, attachments, and pictures just by knowing the person's phone number.

Channel 7 Signaling System is a telephone signaling protocol developed in 1975 and used in all forms of digital telephony around the world. It includes a messaging or "MTP" portion operating at physical layer 1, link layer 2, and network layer 3 to handle call routing. End-to-end routing is controlled by the signaling connection control part or "SCCP" operating at transport layer 4. The protocol also includes a number of application layer 7 functions related to charging, roaming, and call authorization. SS7, while necessary, is extremely vulnerable to attacks and poses a serious security risk to conventional telephony.

In April 2016 (https://en.wikipedia.org/wiki/Signalling_System_No._7), the US Congressional Oversight Committee reported that “the exploitation of vulnerabilities is virtually limitless: from criminals tracking individual targets to foreign organizations carrying out economic spying on US companies, down to national states tracking US government officials. " ... Vulnerability has serious implications not only for individual privacy, but also for American innovation, competitiveness and national security. "Many digital security innovations, such as multi-factor authentication using text messages, may be useless."

Cyberattacks against the SS7 protocol, in fact, fall into the category of packet eavesdropping, interception of both content and metadata using specific formatting of SS7 information as instructions. The SS7 protocol essentially provides an information template with which packet information can be interpreted. As shown in FIG. 109 , the problem starts with a SIM or "Subscriber Identity Module" containing various kinds of personal information about a subscriber and his account. As shown in the figure, the mobile operator SIM 1880, typically issued by the mobile operator, is used to identify telephone 32 on the cellular network, illustrated by antennas 25A, 25B, and 25C with corresponding radio channels 28A, 28B, and 28C. Each SIM card includes a unique identifier, ICCID, or "Integrated Circuit Card ID", an 18- or 19-digit number used to identify the SIM card internationally. The International Mobile Subscriber Identity or IMSI identifies an individual operator's network, i.e. the internal network on which the SIM card operates. The local network service provider uses the IMSI number to communicate with the SIM card for making calls.

The SIM also includes a three-digit "mobile country code" (MCC) to identify the country in which the SIM was manufactured. When making international calls from a mobile phone, the MCC is required as part of the dialing sequence. Examples of MCCs include 310-316 for the US, 234-235 for the UK, 460 for China, 208 for France, 250 for Russia, 262 for Germany, 302 for Canada, and 724 for Brazil. MCC is used in conjunction with the mobile network code (MNC) to identify the network provider who issued the SIM card. For a complete list of codes, see https://en.wikipedia.org/wiki/Mobile_country_code. The SIM also includes a 15-digit "International Mobile Station Subscriber Number" or MSISDN to uniquely identify the subscriber and the type of network on which the SIM is operating. The SIM card also contains the subscriber's phone number and SMS text directory with a record of incoming and outgoing calls and sent texts, as well as information about the time and date. In recent years, telecom operators have begun to use specialized SIM cards with so-called secure elements to store credit card details in order to simplify mobile payments.

Since MCC, MNC and MSISDN codes are transmitted as part of the connection process, the country of origin and bearer of any SIM card and associated subscriber phone number can be easily identified through SS7 injection and packet sniffing. The transmitted data 1881 can be easily used to track the identity of the caller using telephone directories, online information or social networks, i.e. through profiling. Once identified and matched, the phone number and SIM card can be used to monitor the subscriber's activities, regardless of where he may travel. Encryption does not protect basic call information or metadata. Even with end-to-end encryption, data packets can be easily identified as packets of the same conversation, intercepted and stored for subsequent decryption attempts.

Besides metadata and content, caller location is also at risk of SS7 vulnerability. On any cellular network, the phone sends messages to local cell towers to determine if it is available on a particular cellular network. These registration packages are sent out at regular intervals. Monitoring these packages allows you to determine the location of the phone with a specific SIM card, even if the phone is not talking on the phone and the GPS is turned off. Thus, the location and movement of the subscriber can be tracked without his knowledge.

Despite SS7's inherent vulnerabilities, Last Mile hypersecured communications, implemented over a secured dynamic network and protocol, fend off attacks on SS7 by masking critical Last Line call data. In particular, Last Mile's hyper-secure communications offer significant security benefits over traditional telephony or OTT Internet communications, including the following:

Last Mile hypersecure communication does not reveal the phone number or IP address of the called or sending party, even if that party is not an SDNP client.

Hypersecure Last Mile communication does not determine whether sequential data packets are part of the same call or are unrelated data packets with different destinations.

By hiding the specifics of data packet calls, the hypersecure Last Mile link hides the call time metadata.

Last Mile hypersecure communication dynamically encodes the payload, preventing unauthorized access to package contents and protecting the confidentiality of voice, video and text communications, as well as images, files and other content.

So, as described above, interaction using the described secure dynamic network and protocol and hypersecure Last Mile communication is not affected by the SS7 vulnerability. Since SDNP communication is proprietary and uses an encrypted payload, call data or content cannot be extracted from an SDNP data packet, even for packets transmitted over an open, unencrypted channel such as 2G, 3G and 4G / LTE telephony. ... Thus, packet sniffing is ineffective in carrying out cyber attacks with SDNP encryption and fragmented data transmission.

SDNP masking - Given the above, the only impact that SS7 vulnerability has on SDNP communication is in the location of the caller. Since the phone number in the operator's SIM card is associated with the identification of each user, when the mobile phone is turned on, it is sure to contact the nearest cell towers, even if there is no phone call. This cell tower information can be used to triangulate the user's location and track the subscriber's travels even when GPS is off. Since this unauthorized tracking relies on the SS7 protocol, devices using regular carrier SIM cards are vulnerable to location tracking, even those that act as SDNP clients.

As shown in the simplified network diagram of FIG. 110 , the enhancement to Last Mile hypersecure communication, referred to herein as "SDNP masking," prevents subscriber tracking altogether. To implement this function, the regular SIM 1880 is replaced with an SDNP SIM 1882. The SDNP SIM is registered in the name of the SDNP network operator, not the subscriber's name, so the SDNP 1882 SIM does not contain any personal information about the subscriber. The SDNP 1882 SIM is similar to a prepaid mobile SIM in that it has access to the network but does not contain personal data. Instead, the personal information of the account holder is securely stored on SDNP name servers and is not accessible to hackers or susceptible to cyber attacks.

In service, SDNP masking hides the true identity of the owner using a SIM 1882 known only to the SDNP network operator. Thus, the phone number inside the SIM card is used to establish the Layer 1 and Layer 2 connection 28B between the mobile phone 32 and the mobile tower 25B, but not to provide routing. Instead, the source and destination addresses of data packets for Last Mile routing are controlled by the SDNP 1335A application and the SDNP 1601A gateway as instructed by the SDNP 1603A signaling server.

When passing through the 1601A SDNP gateway, calls from the SDNP application are displayed with a number other than the SIM card number. This transfer from the physical SIM card number to the SDNP phone number is performed by the SDNP 1604A name server, which, during call routing, translates the SDNP phone number into a SIM card number according to the 1885 translation table, thereby disguising the physical SIM card number for any user ... With SDNP masking, the true identity of the owner of the phone is completely hidden. To make a call to an SDNP client, external callers make an SDNP # call, even if they are not SDNP clients themselves. The SDNP network automatically routes the call to the SDNP client, never revealing the phone number on the SIM card. Likewise, an SDNP client makes a call to a non-SDNP client, and the recipient of the call sees the incoming call from SDNP # and not from the SIM card number. Thus, SDNP performs in telephony functions similar to the NAT gateway in Internet communications, except that the SDNP system is a real-time network, and the Internet is not.

Since the true identity of the user of telephone 32 is never revealed by calling 28B, triangulating the location of the telephone is not useful since its user and all communications remain anonymous. As such, tracing the location of unidentified mobile phones is not beneficial to hackers, but solves the problem of the vulnerability of the SS7 protocol. In case an SDNP client travels around the world, the traveler can purchase a local prepaid SIM card and bind it to their SDNP number. An SDNP subscriber will still receive calls to his SDNP number, but the Last Line will be done using the local SIM card, thus avoiding roaming charges. Thus, one SDNP telephone number functions as a global number without the cost of long distance calls.

SDNP subnets - Using its unique switches based on software communication nodes, the SDNP communication cloud can be deployed remotely in any network of interconnected computers, both private and public. Examples of server networks include private, publicly leased networks such as those hosted by Microsoft, Google, and Amazon. OnFIG. 111 shows two SDNP clouds deployed on two separate server networks. As shown in the figure, SDNP communication nodes M_0.0, M_0,4, M_0.7 and M_0.8, respectively. A second SDNP cloud consisting of servers 1902A, 1902B, and 1902C hosts SDNP Nodes M_10.0, M_10.1 and M_10.2 respectively. Since they use separate security credentials, zones Z0 and Z10 respectively, both SDNP clouds are completely different from each other and cannot directly exchange information. A single SDNP client, shown as a mobile phone 32 running the SDNP 1335 application, can, however, with proper authorization, access both clouds, even if they are hosted by different computer server rental providers. As shown in the example, SDNP Client C_1.1 has access to SDNP gateway node M_0.7 in the Z0 cloud using hypersecure Last Mile communication through Router 1910 and access to SDNP Gateway Node M_10.0 in the Z10 cloud using hyper-secure Last Mile interoperability through the same 1910 router, without the risk of mixing conversations or data packets.

The two independent clouds are accessed through a common 1920 UI / UX communications application. Access to each cloud is split into separate dialog sandboxes 1921A and 1921B. While information can be downloaded from a personal 1921A sandbox account to your phone, exporting data from a 1921B sandbox business account is dependent on the company's business and security administration.

Connecting a device to SDNP clouds requires the SDNP application, either software or firmware, to be installed on the device. Installation includes (i) downloading an application (ii) verifying device identification using an SDNP generated authorization code (iii) establishing an identity, and (iv) obtaining permission to connect to a specific SDNP cloud. Upon activation, the SDNP application creates a hypersecure Last Mile connection to the independent SDNP cloud. In many cases, user authentication and user authentication for an enterprise account is more complex than that required to access a personal account and may require multi-factor authentication.

Due to the fact that SDNP communication is software based, with different and separate security accounts for each communication cloud, there is no interoperability between any established SDNP communication networks, even if they are hosted on the same servers. Because zone-specific security credentials uniquely identify each configurable SDNP cloud, no two SDNP clouds are alike and therefore cannot communicate directly. The advantage is that multiple SDNP clouds can coexist on the same server network without the risk of data leakage. Access to the business network is controlled according to the requirements of the cloud owner. As such, merging two accounts and communication clouds is prohibited when sharing shared host servers operating with the same security as if it required two different phones to connect to two separate networks. The autonomy of SDNP zonal clouds, or "subnets", is further illustrated in FIG. 112 , where servers 1901A, 1901B, 1901C and 1901D host two clouds at the same time - one cloud consisting of zonal communication nodes Z0 SDNP M _0.0 , M _0.4 , M _0.7 and M _0.8 , respectively, and the second consisting of zonal communication nodes SDNP Z7 M _7.0 , M _7.4 , M _7.7 and M _7.8 , respectively. Despite working within the same servers, hypersecure communication using established SDNP protocols prevents any direct communication. Access is thus driven by the Last Mile link rather than direct cloud-to-cloud communication.

SDNP communication is not limited to private rented publicly available servers, but can also be customized for different types of corporations or government agencies. In general, private corporations often choose to host their own networks, especially in business-critical applications. Examples of private networks are FedEx, Walmart, IBM, etc. For privacy reasons, networks used by research institutes, universities, and medical centers are also often chosen to be hosted on their own. Private server networks are also used to host global cloud business applications such as SalesForce.com, Box.com, Dropbox, eTrade, SAP, etc .; e-commerce platforms and comparison shopping networks such as eBay, Amazon.com, Priceline.com, e-Insurance; streaming media services such as YouTube, Amazon Prime, Netflix, Hulu, Comcast Xfinity; as well as social media such as Facebook, Twitter and Snapchat.

In larger corporations, the IT department may decide to manage separate networks for the parent company and its subsidiaries. However, in many private companies, infrastructure costs are considered an important factor in network design. Instead of supporting two completely different hardware systems, SDNP provides a company with the ability to deploy its networks using a combination of separate and shared server resources. As shown in FIG. 113 , two legal entities, such as a parent corporation and its subsidiary, co-host a server network consisting of both separate and shared servers. In particular, servers 1903, 1904B, 1904C and 1904D host the corresponding communication nodes of the zone Z7 M _7.0, M _7.4 , M _7.7 and M _7.8, respectively, for the parent corporation, and servers 1901A, 1901B, 1901C and 1903 located the corresponding communication nodes of the zone Z0 M _0.0 , M _0.4 , M _0.7 and M _0.8 for the local subsidiary. As shown in the example, server 1903 hosts two SDNP communication nodes, namely node M _7.0 for the parent company and node M _0.8 for the subsidiary. Due to their different security policies, no data is transferred directly between the parent and child SDNP clouds, even though Server 1903 and others (not shown) are shared by both organizations. While employees are generally limited to access only to their employer's "clouds", for corporate employees, access to both "clouds" may be required. Properly authorized users, as shown in the SDNP UI / UX 1920 applet, enable separate dialog sandboxes 1921C and 1921D for different legal entities. Thus, one mobile phone or tablet can access several SDNP clouds of different legal entities without the risk of data mixing, as if the user had several phones.

An SDNP application's multidisciplinary feature that uses hyper-protected Last Mile security credentials to allow or deny access to multiple SDNP clouds, supports unlimited account profiles from a single SDNP application. FIG. 114 , for example, an SDNP C _1,1 client can make global calls without toll charges in the Z99 zone of the SDNP global telecommunications node, consisting of 1909A - 1909E servers hosting SDNP nodes M99.1 - M99.5, respectively, and also receive access to other clouds, such as the hypersecure Last Mile cloud, which provides access to multiple accounts, such as the Z9 corporate cloud, which includes servers 1905A, 1905B and 1905C hosting SDNP M _9.0 nodes, M _9.4 and M _9.8 , as well as to call subscribers of the cloud zone Z0 through servers 1901A, 1901B and 1901C, hosting SDNP nodes M _0.0 , M _0.4 and M _0.8 , respectively. Access privileges to any given cloud are implemented through the Last Mile link to the SDNP gateway and are controlled by the SDNP system signaling server and the SDNP name server used to administer authorized users.

SDNP communications are equally applicable in highly secure and restricted access networks required by government and security. For example, in the United States, limited access communications are required by various agencies, including local and state law enforcement agencies, the FBI, the US National Guard, the US National Security Agency, the US military (individually and collectively), the US Department of State, and server networks. Congress and Legislatures. Other countries also have separate networks for different government agencies.

To support "as needed" access to a particular cloud, nested subnetwork architectures can be implemented using SDNP communication techniques and technologies. For example, in FIG. 115 nested cloud SDNP includes a secure cloud consisting of rented computer servers 1907A and 1907D hosting SDNP communication nodes M _0.0 , M _0.4 , M _0.5, and M _0.9 , respectively. Communication in this external network "shell" includes the security credentials of zone Z0 and is displayed in the "secret" level dialog in the 1912E "sandbox" as shown in the SDNP communicator 1920. The nested "cloud" also includes an internal enhanced security kernel with zone Z8 security credentials, consisting of government-hosted servers 1906A, 1906B, and 1906C and SDNP-compliant server nodes M _8.0 , M _8.2, and M _8.4 . In order for client C _{1,1 to} gain access to the core of zone Z8, he must have "top secret" access to classified information, and communicate through the secure communication "sandbox" 1921F. One example of the use of this technology in government is the US Department of State, where top-secret communications in Zone Z8 are restricted to ambassadors and secretaries of state, while other US embassies around the world are restricted to "secret" hyper-secure communications through Zone Z0 security policies.

Claims (35)

1. A method for transmitting data packets from a client device to the cloud, and the data packets are contained in the communication package, the cloud contains many media nodes and many gateway nodes, and the method contains the steps at which: transmitting, by the client device, a call request to the signaling server, the call request comprising contact information related to the called party; by means of the signaling server, routes are developed for a communication message directed to the called party, wherein the first route contains the first gateway node and the second route contains the second gateway node, and neither the first gateway node, nor the second gateway node, nor any other media node has information, describing either the first route, or the entire second route; transmitting through the signaling server packets with routing instructions to the client device, the first gateway node and the second gateway node, respectively; in response to the packet with routing instructions, the client device transmits the first data packet in the communication message from the client device to the first gateway node and the second data packet in the communication message from the client device to the second gateway node. 2. The method of claim 1, comprising transmitting the first data packet from the client device to the first gateway node over the first physical medium and transmitting the second data packet from the client device to the second gateway node over the second physical medium. 3. The method of claim 2, wherein the first physical medium comprises a cellular telephone line and the second physical medium comprises a Wi-Fi channel. 4. The method of claim 2, comprising providing the first data packet with a first source IP address and providing the second data packet with a second source IP address. 5. The method of claim 1, comprising providing the first data packet with a first source IP address and providing the second data packet with a second source IP address. 6. The method of claim 1, wherein before the signaling server transmits the routing instruction packets to the client device, the first gateway node and the second gateway node, respectively, the signaling server accesses the name server with contact information related to the called party. 7. The method of claim 6, wherein the contact information related to the called party comprises the confidential identification of the called party, the name server converts the confidential identification to the SDNP address of the called party, wherein the signaling server uses the SDNP address of the called party during development. routes for a communication message from the client device to the called party. 8. The method of claim 6, wherein the called party contact information comprises a telephone number, the name server translates the telephone number to a gateway node address closest to the called party's location, wherein the signaling server uses the closest gateway node address. to the location of the called party, when developing routes for the communication message from the client device to the called party. 9. The method of claim 6, wherein the client device sends information to the name server whenever the device connects to the network. 10. The method of claim 1, wherein the routing instruction packet sent by the signaling server to the client device comprises a first routing instruction to send a first data packet to a first gateway node and a second routing instruction to send a second data packet to a second gateway node. 11. The method of claim 10, wherein each of the first gateway node and the second gateway node has a first address for communicating with a client device and a second address for communicating with a cloud. 12. The method of claim 5, wherein the client device transmits the first and second data packets to the first and second gateway nodes, respectively, through the router, the method further comprising providing the first data packet with a first source MAC address and providing the second packet data with the second source MAC address. 13. The method of claim 1, comprising providing a plurality of signaling servers, wherein the signaling servers share the task of routing packets from the client device to the called party, wherein no single signaling server has information describing the entire route of the packet. 14. The method of claim 1, further comprising the step of hiding the contents of at least one of the first data packet and the second data packet using a combination of hiding techniques, the hiding methods comprising encryption, scrambling, unwanted data insertion, splitting and / or mixing and based on condition. 15. The method of claim 14, wherein the state comprises time, node number, network identifier, or GPS location. 16. The method of claim 2, wherein the first physical medium comprises a cellular telephone line modulated using a first carrier frequency and the second physical medium comprises a cellular telephone line modulated using a second carrier frequency. 17. The method of claim 2, wherein the first physical medium comprises a Wi-Fi channel modulated using a first carrier frequency and the second physical medium comprises a Wi-Fi channel modulated using a second carrier frequency. 18. A method for transferring data packets from a client device to the cloud, and the data packets are contained in the communication package, the cloud contains many media nodes and many gateway nodes, and the method contains the steps at which: transmitting the first data packet from the client device to the first gateway node through at least one router; provide the first data packet with a first source IP address and a first source MAC address; transmitting the second data packet from the client device to the second gateway node through at least one router; provide the second data packet with a second source IP address and a second source MAC address; 19. The method of claim 18, comprising: transmitting the first data packet from the client device to the first gateway node over the first physical medium and transmitting the second data packet from the client device to the second gateway node over the second physical medium. 20. The method of claim 19, wherein the first physical medium comprises a cellular telephone line and the second physical medium comprises a Wi-Fi channel. 21. The method of claim 19, wherein the first physical medium comprises a cellular telephone line modulated using a first carrier frequency and the second physical medium comprises a cellular telephone line modulated using a second carrier frequency. 22. The method of claim 19, wherein the first physical medium comprises a Wi-Fi channel modulated using a first carrier frequency and the second physical medium comprises a Wi-Fi channel modulated using a second carrier frequency. 23. The method of claim 18, further comprising the step of hiding the contents of at least one of the first data packet and the second data packet using a combination of hiding techniques, the hiding methods comprising encryption, scrambling, unwanted data insertion, splitting and / or mixing and based on condition. 24. The method of claim 23, wherein the state comprises time, node number, network identifier, or GPS location. 25. A method for transmitting data packets from a client device to a cloud through at least one router, and the data packets are contained in a communication message, the cloud contains a plurality of media nodes and a plurality of gateway nodes, the method comprising the steps of: provide the first data packet with a first source IP address and a first source MAC address; and provide the second data packet with a second source IP address and a second source MAC address.

Images