KR20220154248A - Methods and apparatus for hypersecure last mile communication - Google Patents

Abstract

Various techniques are disclosed for obscuring the content of communications between a client device, such as a cell phone or laptop, and a network or cloud of media nodes. Among such techniques, it routes data packets in the communication to different gateway nodes in the cloud, transmits the packets over different physical media, such as Ethernet cables or WiFi channels, and obscures the packets by giving them different source addresses. Also disclosed is a highly secure method of storing description and data files for muting specific participants in a conference call.

Description

Method and apparatus for secure last mile communication {METHODS AND APPARATUS FOR HYPERSECURE LAST MILE COMMUNICATION}

CROSS REFERENCES TO RELATED APPLICATIONS

On July 20, 2015, this application claims priority from U.S. Provisional Application No. 62/480,696, filed on April 3, 2017, and reclaims priority from U.S. Provisional Application No. 62/107,650, filed on January 26, 2015. It is a continuation-in-part of U.S. Application Serial No. 14/803,869, entitled “Secure Dynamic Communication Network And Protocol,” filed dated.

The entirety of each of the foregoing applications is incorporated herein by reference.

technology field

The present invention relates to methods and apparatus for facilitating hypersecure “last mile” communications between a device and a gateway to a network or cloud.

Improved means of communication have fueled the progress of civilization from the earliest inception of mankind. From the use of couriers and messengers traveling on foot or on horseback, through the delivery of mail by train, truck, and airplane, through telegraph and telegraph, telephone, radio, television, computer, cell phone, Internet, e-mail and world wide web Until the advent of, more recently, through social media, internet telephony, machine-to-machine (M2M) connectivity, Internet of Things (IoT), and Internet of Everything (IoE). You can get a lot of information. And the communication of the Internet of Everything has always played a leading role in the development of the latest technology of the era. With each new communications technology used, the number of people connected and the rate at which information is transmitted has also increased.

The impact of this trend is that people are more connected than ever before in history, and people are trusting and trusting communications technology to safely and reliably deliver their personal, personal, family, and financial information only to those they intend to contact. are dependent Knowledge and information can now be distributed to millions of people in seconds, and friends and family can connect halfway around the world as routinely as pressing a button. “The world has become a very small place,” it is often said.

While these advances are immensely beneficial to everyone, there are also negative consequences of our high dependence on technology. When a communication system fails to perform, for example during an earthquake or bad weather, it is not surprising that people are confused or perplexed by being "unplugged", even temporarily. Therefore, the quality of service (QoS) of a communication system or media is an important measure of the performance of a communication network. People's peace of mind, financial assets, identity and even their lives depend on reliable and secure communications.

Another key consideration of communication networks is their ability to guarantee privacy, safety, and security to the clients using them. As communication technologies have evolved, so have the sophistication of criminals and “hackers” who intend to cause pranks, disrupt systems, steal money, or harm others accidentally or maliciously. Credit card fraud, stolen passwords, identity theft, and unauthorized disclosure of confidential information, personal photos, files, emails, text messages, and private tweets (embarrassing or threatening theft) are just a few examples of modern cyber-crime. is only

In order to shed light on the prevalence of security problems in today's open communication networks, notable examples of privacy breaches and cybercrimes at the time of this patent application are (listed in chronological order):

* "Target: Stolen information of at least 70 million people". CNBC, January 10, 2014

* "Hacker creates smart fridge, TV sends malicious email". BGR (www.bgr.com), 20 January 2014

* "Nest Google Privacy Row Resumes With Hacked Thermostat", Slash Gear (www.slashgear.com), 24 Jan 2014

* "Account hijacking requires Question Line to secure Line's data. Line, a free calling and messaging application, was recently caught in a data security breach. I have seen hundreds of user accounts accessed illegally by ". Nikkei Asian Review, July 2, 2014

* "Ordinary American Caught in NSA Data Sweep Reports Claim". AP, July 6, 2014

* "Smart LED bulbs leak WiFi passwords." BBC News, 8 July 2014

* "Six people charged a prime ticket to the StubHub Scam. StubHub is a network of hackers who use stolen passwords and credit card numbers to buy and sell thousands of tickets for pop music concerts and Yankees games. targeted, New York authorities said". Bloomberg, 24 July 2014

* "Study Shows 'Internet of Things' Highly Sensitive to Hacking" International Business Times (www.ibtimes.com), 4 Aug 2014

* "Russian Hackers Amass 1 Billion Internet Passwords". The New York Times, August 5, 2014

* "New Leaker Represents U.S. Secrets, Government Concludes," CNN, Aug. 6, 2014

* "Hacker Roots Google's Nest Thermostat in 15 Seconds", The Enquirer (www,theinquirer.net), 11 Aug 2014

* "Dairy Queen Hacked by Same Malware Hitting Target", Christian Science Monitor, 29 Aug 2014

* "Celebrity Victims of Nude Photo Leaks - iCloud Accounts Vulnerable," CBS News, September 1, 2014

* "Home Depot may be the latest target in credit card disputes. Home Depot disputes may be bigger than target (40M cards stolen over 3 weeks)", Fortune, 9/2014 2nd of the month

* "Mysterious Fake Cell Phone Towers Are Intercepting Calls Across America." Business Insider, September 3, 2014

* "Hacking attacks, banking to retail, signs of cyber warfare?" Yahoo Finance, September 3, 2014

* "Home Depot confirms hacked payment systems in US and Canadian stores". Fox News, September 9, 2014

* "Yahoo Fights with US Government Over Surveillance." CBS/AP, September 11, 2014

* "Your medical records are more valuable to hackers than your credit cards." Reuters, 24 Sep 2014

* "Red Alert: HTTP S Hacked. Browser exploitation of SSL/TLS (BEAST) attack is probably one of the worst hacks, as it compromises browser connections that hundreds of millions of people rely on every day". InfoWorld, 26 Sep 2014

* "Sony cyberattack, first nuisance, quickly went up in flames". New York Times, December 30, 2014

With cybercrime, security breaches, identity theft, and privacy invasions seemingly on the rise, the question arises: "How are all these cyber-attacks possible, and what can be done to prevent them?" At the same time as society seeks greater privacy and security, consumers also want better connectivity, cheaper high-quality communications, and greater convenience in conducting financial transactions.

To understand the performance limitations and vulnerabilities of modern communications networks, data stores, and connected devices, how today's electronic, radio, and optical communications operate and transmit data, including files, emails, text, audio, and video images. It is of the utmost importance to understand whether, and how to store

Circuit-switched telephone network operation

Electronic communication involves various hardware components or devices connected within networks of wire, radio, microwave or fiber optic links. Information is transferred from one device to another by transmitting electrical or electromagnetic energy over this network, and by using various methods to embed or encode the information "content" within the data stream. Theoretically, the laws of physics set the maximum data rate of these networks to the speed of light, but in most cases, data encoding, routing and traffic control, signal-to-noise quality, and electrical, magnetic and optical noise, unwanted parasitics Practical limitations to overcome impede or inhibit information flow limiting the functionality of the communication network to a fraction of its ideal performance.

Historically, electronic data communication was first achieved using dedicated "hardwired" electrical connections forming a communication "circuit" between or between two or more electrically connected devices. In the telegraph case, to manually make and break the direct current (DC) electrical circuit, a mechanical switch was used, which magnetized a solenoid and moved a metal lever in turn, causing a listening device or “relay” to follow in the same pattern the caller pressed the switch. Make them click in the same place. Then, to encode the information into the pulse stream, the caller used an agreed upon language, namely Morse code. The listener also needs to interpret the message by understanding Morse code, which is a series of long and short pulses called dots and dashes.

Later, Alexander Graham Bell developed the first telephone, using the concept of "undulating current", now referred to as alternating current (AC), to transmit sound through an electrical connection. A telephone network consists of two magnetic transducers connected by an electrical circuit, each magnetic transducer consisting of a movable diaphragm and coil or "voice coil" surrounded by a fixed permanent magnet enclosure. When speaking in a transducer, the change in air pressure from sound causes the voice coil to move back and forth within the surrounding magnetic field, inducing an AC current in the coil. On the listener side, a time-varying current flowing in the voice coil induces the same waveform and time-varying magnetic field that opposes the waveform and surrounding magnetic field, moving the voice coil back and forth in the same way as a transducer that captures sound. The resulting movement reproduces sound in a manner similar to a device that captures sound. In modern vernacular, when the transducer converts sound into electric current, it acts as a microphone, and when the transducer converts electric current into sound, it acts as a speaker. Also, since the electrical signals conducted are similar to the audio waveforms carried as elemental pressure waves in air, i.e. sound, today these electrical signals are referred to as analog signals or analog waveforms.

As mentioned above, since transducers are used for both speaking and listening, both parties in the conversation must know when to talk and when to listen. Similar to two tin cans connected by a string in this system, the caller cannot speak and be heard at the same time. This one-way operation, called "half-duplex" mode, may sound old-fashioned, but it is used in modern walkie-talkies, and also known as "push-to-talk" or PTT. It is still used in practice for wireless communication in modern telephony technology.

Later, full-duplex (i.e., two-way or send-and-receive) telephones with separate microphones and speakers became commonplace, allowing parties to talk and listen at the same time. But even in modern times, feedback, the receiver's sound, is picked up by the microphone and fed back to the caller, avoiding the confusing echo and sometimes uncomfortable whistle-problem that plagues long-distance telephony in particular. To do this, care is also required to operate full-duplex telephony.

Early telegraph and telephone systems suffered from one other problem, privacy. In these early incarnations of communication networks, everyone connected to the network heard everything communicated on the wire, even if they did not want to. In rural telephone networks, these shared lines were known as "party lines". Since then, telephone systems have evolved rapidly into multi-line networks in which dedicated lines connected the telephone branch office directly to the individual client's phone. Within the branch exchange office, the system operator manually connected callers to each other through the switchboard using jumper cables, and also had the ability to connect one point to another to form the first "long distance" telephone call service. . Large banks of relays forming a network of telephone "switches" gradually replaced human operators, which were then replaced by electronic switches containing vacuum tubes.

After Bell Laboratories developed the transistor in the late 1950s, telephone switches and point swaps replaced those brittle, hot vacuum tubes with cool solid-state devices containing transistors and ultimately integrated circuits. As networks grew, phone numbers expanded from a 7-unit prefix and personal number to include an area code and ultimately a country code to handle international calls. Soon copper cables carrying voice calls covered the world and crossed the oceans. Despite the size of the network, the principle of operation has remained constant, and the call represents a direct electrical connection or "circuit" between the caller with voice carried by the analog signal and the routing of the call determined by the telephone switch. did These telephone systems eventually became known as "circuit-switched telephone networks" or colloquially as plain old telephone systems or POTS. Circuit-switched telephony reached its peak in the 1980s, and since then has been relentlessly replaced by "packet-switched telephony" described in the next section.

Evolving almost parallel to the telephone network, regular radio communications began with radio broadcasts in the 1920s. The broadcast was unidirectional, emanated from a radio station on a designated government-licensed frequency, and received by any number of radio receivers tuned to the designated broadcast frequency or radio station. The broadcast signal carried an analog signal, using either amplitude modulation (AM) or, later, a respective frequency modulation (FM) method on a dedicated portion of the licensed radio spectrum. In the United States, the Federal Communications Commission or FCC has evolved to administer the allocation and regulation of these licensed bands. The broadcasting concept was extended to public television programming using wireless transmission, first with black-and-white content and later with color. Later, television signals could also be carried into people's homes by microwave satellite dishes or via coaxial cable. The term "multicast" is now being used for such unidirectional multi-listener communication since any listener tuned to a given broadcast frequency can receive the broadcast.

Simultaneously with the advent of radio broadcasting, the first two-way communications began on commercial and military marine vessels, and also during World War II, the radio was a walkie-talkie hand-held radio transceiver, a device that combined a transmitter and receiver into a single unit. developed Like telephony, early two-way radio transmissions operated in a "simplex" mode, allowing only one radio to broadcast on a single radio channel while the others listened. Combining the transmitter and receiver at different frequencies allows simultaneous transmission and reception at each end of the radio link, enabling full-duplex mode communication between the two parties.

However, to prevent duplicate transmissions from multiple parties, a protocol called half-duplex or push-to-talk (PTT) is commonly used for channel management, allowing anyone to transmit exclusively on a designated channel on a first-come, first-served basis. Industry standard radio types that use analog modulation include amateur (ham or CB) radio, marine VHF radio, UNICOM for air traffic control, and FRS for personal walkie-talkie communications. In these two-way radio networks, radios transmit their data on designated frequency "channels" to a central radio tower, which towers amplify and repeat the signal and transmit it to the entire radio network. . The number of available frequencies carrying information about the broadcast area establishes the total bandwidth of the system and the number of users that can communicate independently on the radio network at one time.

The concept of a cellular network in which a large area was divided into smaller parts or radio "cells" to expand the overall capacity of a radio network to handle a large number of callers was demonstrated in the 1970's and became widespread within the following decade. The cellular concept was to limit the broadcasting range of a radio tower to a smaller area, i.e. shorter distances, so that the same frequency band could be reused to simultaneously handle different callers present in different cells. To do so, software has been created to manage the handoff of a caller passing from one cell into an adjacent cell without "dropping" and without abruptly disconnecting the call. Like radio and television broadcasting, early cellular networks, like POTS, two-way radio, were analog in nature. To control call routing, a telephone number system has been employed to determine the appropriate wireless electrical connection. This choice also had the advantage of seamlessly connecting the new wireless cellular network to the "wired" plain old phone system, providing interconnection and interaction through the two systems.

Beginning in the 1980s, telephone and radio communications, along with radio and TV broadcasts, are used to reduce power consumption and increase battery life, to improve quality with a better signal-to-noise ratio, and to carry data and text with voice. The inexorable transition from analog to digital communications methods and formats, driven by the need to begin addressing the needs, has begun. Radio formats such as EDACS and TETRA have emerged that can simultaneously use one-to-one, one-to-many, and many-to-many communication modes. . Also, cellular communications were quickly converted to digital formats such as GPRS, as was TV broadcasting.

By the 2010s, most countries had either stopped or were in the process of suspending all analog TV broadcasting. Unlike broadcast television, cable TV carriers are not required to convert to a digital format, and have maintained hybrid composites of analog and digital signals through 2013. That eventual move to digital, not by government standards, expands the network's allowable number of channels, can deliver HD and UHD content, and allows for more payper-view (PPV, "universal"). (also known as "unicast"), and was prompted by commercial reasons to enable high-speed digital connection services to its clients.

While it is common to equate the migration of global communications networks from analog to digital formats with the advent of the Internet, and more specifically with the widespread adoption of the Internet Protocol (IP), the transition to digital formats marked the commercial acceptance of IP in telephony. Earlier, it enabled, if not facilitated, the universal migration to IP and "packet-switched networks" (described in the next section).

The resulting evolution of circuit-switched telephony technology exists schematically as the PSTN, which includes the amalgamation of radio, cellular, PBX, and POTS connections and sub-networks, each including a "public switched telephone network" or dissimilar technology. The networks are connected by high-bandwidth trunk lines and include, for example, POTS gateways, cellular networks, base station PBXs, and PSTN gateways connected via wired connections to a two-way radio network. Each sub-network operates independently, driving similar types of devices.

The PSTN is also connected to the circuit-switched cellular network via base stations 17 running AMPS, CDMA, and GSM analog and digital protocols. Through cellular towers, circuit-switched cellular network base stations connect to mobile devices, such as cell phones, using the standardized cellular radio frequencies of the cellular link. For GPRS networks, an improvement on GSM, circuit-switched cellular network base stations can also connect to tablets carrying low-speed data and voice simultaneously. Two-way radio networks such as TETRA and EDACS connect the PSTN to handheld radios and large in-dash and desktop radios via high-powered radio towers and cellular links. Commonly used by police cars, ambulances, paramedics, fire departments, and even port authorities, these two-way radio networks, also referred to as professional communications networks and services, target governments, municipalities, and emergency responders rather than consumers. (Note: As used herein, the terms “desktop,” “tablet,” and “notebook” are used as shorthand references to computers bearing these names).

Unlike POTS gateways, cellular network base stations, and PBXs, which use traditional phone numbers to complete call routing, two-way radio networks use dedicated (rather than phone numbers) to establish a radio link between a tower and the mobile device it operates on. of RF radio channels. Thus, there is a distinct presence of professional wireless communications services, and also uniquely different from consumer cellular telephone networks.

Thus, the PSTN network flexibly interconnects sub-networks of various technologies. Forming the ability to interoperate between sub-networks, which is an inherent weakness of today's circuit-switched networks, is very diverse. Because the various sub-networks do not communicate with any common control protocol or language, and because each technology handles the transmission of data and voice differently, calls can be made over PSTN backbones or trunk lines. Aside from its limited ability to do so, the various systems are basically incompatible. For example, during the September 11 terrorist attack on the World Trade Center in New York City, all of the United States gathered in Manhattan to help fight the disaster, just to learn its radio communications system and walkie-talkie. Many of the first responders were incompatible with volunteers from other states and cities, making it impossible to administer central command and control of relief efforts. Because there is no standardization in the radio's communication protocol, the radios simply cannot connect to each other.

Furthermore, by direct electrical and RF connections in circuit-switched telephone networks, especially using analog or non-secure digital protocols, hackers equipped with RF scanners can find active communication channels and sniff, sample, listen to, Or blocking is a simple matter. Because the PSTN forms a "tethered" link or circuit between communicating parties, it is possible to conduct cyber surveillance legally or illegally, prohibited, or unauthorized by governments operating under federal court-ordered wiretapping. Criminal law by crime or government, there is plenty of time for hackers to identify and "eavesdrop" on a connection. The definition of legal and illegal espionage and surveillance, and the obligation to comply with cooperation by network operators, vary widely from country to country, and are also heating up debate among global companies such as Google, Yahoo, and Apple that operate across international borders. Communications networks and the Internet are global, and have no borders or borders, but the laws governing this electronic information are then limited to the jurisdiction of governments governing communications and commerce both domestically and internationally.

Regardless of legality or ethics, electronic wiretapping today ranges from the monitoring of the ubiquitous security cameras on and above street corners on every road or subway to the sophisticated hacking and cracking of codes carried out by national security agencies and agencies in various countries. and surveillance is routine. All networks are vulnerable, but the PSTN's outdated and weak security regulations make them particularly susceptible to hacking. Thus even a PSTN connected to a modern secure modem network represents a weakness in the overall system, creating a weakness for security breaches and cybercrime. Nonetheless, it will take years, if not decades, to retire the global PSTN network and completely replace it with IP-based packet-switched communications. Although these packet-based networks (described below) are more modern than the PSTN, they are still insecure and subject to security breaches, hacking, denial of service attacks, and invasions of privacy.

Packet-switched communication network operation

If two tin cans connected by a string represent a metaphor for the operation of modern circuit-switched telephones, the post office represents a similar metaphor for packet-switched communications networks. In this approach, text, data, voice, and video are converted into files and streams of digital data, which are then parsed into quantized "packets" of data and passed over the network. The delivery mechanism is based on an electronic address that uniquely identifies where a data packet is going and where it is coming from. In addition, formats and communication protocols are designed to contain information according to the nature of the data contained in packets, including content specific to the program or application for which they will be used, and the physical links carrying the packets and the hardware that facilitates the electrical or radio connection. .

Born in the 1960s, the concept of packet-switched networks was created during the editorial era of Sputnik's Cold War. At that time, the US Department of Defense (DoD) said that a space-based nuclear missile launch could disrupt the entire communications infrastructure of the United States, rendering it incapable of combating a USSR pre-emptive strike, and leaving it virtually vulnerable to such an attack. expressed concern that it could provoke Thus, the DoD sponsored the development of redundant communications systems, or grid-like "networks," in which the network's ability to transmit information between military installations could not be disrupted by destroying designated data links or even numerous links within the network. . Known as ARPANET, this system became the famous parent of the Internet and modern digital communications.

Despite the creation of packet-switched networks, the Internet's explosive growth led to the first easy-to-use Web browser, Mosaic, the advent of hypertext-defined Web pages, the rapid adoption of the World Wide Web, and widespread use of e-mail. It didn't happen until the 1990s when it spread the global acceptance of Internet platforms as a whole. Because no country or government can stop it (or even fail to fully recognize its global link), and also because its user base includes consumers using those newly acquired personal computers, its basic views, Either the lack of central control, or the need for a central mainframe, has in part propelled the Internet to ubiquity.

Another significant impact of Internet growth was the standardization of the Internet Protocol (IP) used to route data packets through networks. By the mid-1990s, Internet users recognized that it could also be used to carry data, and shortly thereafter "Voice over Internet Protocol" or VoIP was born. The concept theoretically allowed anyone with an Internet to freely communicate by voice over the Internet, but propagation delay across the network, or latency, made voice quality poor and often difficult. Latency has improved with the adoption of fast Ethernet links, high-speed WiFi connectivity, and 4G data to improve connection quality at the “last mile,” but the Internet itself was created to ensure the correct delivery of data packets, and packets There is no guarantee of the time required for delivery, ie the Internet was not created to operate as a real-time network.

Therefore, the dream of using the Internet to replace expensive long-distance telecommunication carriers or "telcos" is "over the top" such as Skype, Line, Kakao Talk, Viper, etc. Despite the availability of over-the-top" (OTT) providers, they are largely lacking. OTT telephony suffers from poor quality of service (QoS) resulting from uncontrolled network latency, poor sound quality, dropped calls, echoes, reverberations, feedback, choppy sound, and sometimes the inability to initiate a call. The poor performance of OTT communications is not inherently a weakness of VoIP-based protocols, but a weakness of the network itself, in which OTT carriers cannot control the path data takes or the delays encountered by communications. Essentially, OTT carriers cannot guarantee performance or QoS because OTT communications operate as Internet hitchhikers. Paradoxically, the companies that can best leverage VoIP-based communications today are long-distance carriers with dedicated, low-latency, hardware-based networks, and that's what Telco has the least incentive to do.

Aside from its inherent network redundancy, one of the greatest strengths of packet-switched communication is that data is placed in packets conforming to Internet protocols, and also from any source, as long as the communication device is connected and linked to the Internet. It is its ability to convey information to any destination. The Internet Protocol manages the ability of a network to deliver a payload to its destination without care or concern about what information is carried or what applications will use it, eliminating any need for custom software interfaces and expensive proprietary hardware. avoid all In many cases, even application-specific payloads set a predefined format, for example for reading mail, opening a web page in a browser, viewing a photo or video, viewing a Flash file, or reading a PDF document, etc.

Because its versatile file format avoids reliance on proprietary or company-specified software, the Internet is an "open source" capable of communicating with the widest range of devices ever connected, ranging from "computers" to cell phones, from vehicles to consumer electronics. It can be considered a "source" communication platform. The latest phrase to describe this pervasive connectivity is the "Internet of Everything" (IoE).

As shown, a large computer array containing high-speed cloud servers and cloud data storage is interconnected by high-bandwidth connections, typically fiber optics, between countless other servers (not shown) to form an Internet cloud. do. The cloud metaphor is appropriate because there is no well-defined boundary defining which servers are considered part of the cloud and which are not. Day by day and even minute by minute, the server is online while it can be taken offline for maintenance without affecting the functionality or performance of the Internet. This is the benefit of a true redundant distributed system, there is no single point of control and thus no single point of failure.

The cloud may be connected to users or connected devices via any of a variety of wired, WiFi or wireless links. Wireless packet-switched capable telephony includes 4G/LTE (or long-term evolution) as well as cellular protocol 3G, including HSUPA and HSDPA, enabling phone calls from one cell to another even if the cells operate with different protocols. Refers to a network standard that guarantees interoperability with various cellular protocols, including the ability to seamlessly handoff. Note: By definition, "last mile" as used herein refers to the link between any type of client device, such as a tablet, desktop or mobile phone, and the cloud server. Directionally, the term "first-mile" is sometimes used to designate the connection between the device initiating the data transfer and the cloud server. In this case, the "last mile" link is also a "first mile" link.

For short-range communication, WiFi access points connect to smartphones, tablets, laptops, desktops or connected devices, and can also be used for local wireless applications in homes, cafes, restaurants, and offices. WiFi includes communications that operate according to IEEE-defined standards for single-carrier frequency specifications 802.11a, 802.11b, 802.11g, 802.11n, and most recently for the dual-frequency band 802.11ac format. WiFi security based on a simple fixed login key is primarily used to prevent unauthorized access to a connection, but is not intended to protect data indefinitely from sniffing or hacking.

Wired distribution units, i.e. routers, are wired to laptops, desktops, telephones, televisions by fiber optic, coaxial cable, or Ethernet, or by twisted copper wire pair telephone lines to floating locations including hotels, factories, offices, service centers, banks, and homes. It can be connected to a point of sale terminal operating on or a fixed wire. A wired connection is the distribution of fiber optic or coaxial cable to a locally connected home, office, factory, or business via a modem to convert a high-speed data (HSD) connection to WiFi, Ethernet, or twisted pairs of copper wires. can include In remote areas where fiber optic or cable cannot be used, digital subscriber line (DSL) connections are still used, but with significant compromises in data rate and connection reliability. Counting access via wireless, WiFi, and wired connections, the number of objects connected to the Internet is expected to reach 20 billion worldwide by 2020.

Unlike the circuit-switched networks, which establish and maintain direct connections between devices, packet-switched communications use addresses to “route” packets across the Internet to their destination. Thus, in the packet-switched communication network, there is no single dedicated line that maintains the connection between communication devices, nor does data traveling through the Internet travel in a single consistent path. Each packet must find its way through a maze of interconnected computers to reach its target destination.

In routing IP packets from a laptop to a desktop using packet-switched network communication, for example, a first packet of data sent from a laptop to a local WiFi router via a wireless connection is directed towards an array of DNS servers, the DNS being a domain name server. is an acronym for The purpose of the array of DNS servers is to translate the text name or phone number of the destination device, in this case the desktop, into an IP address. Once identified, the IP address is passed from the array of DNS servers to the source address, i.e. back to the laptop. These addresses, which unambiguously identify the communication device, are used in the routing of data packets through the network.

After that, the laptop assembles those IP data packets and starts sending them to their destination successively, e.g. first via the WiFi radio to the local WiFi router, then to a network of routers and servers acting as intermediate routers. It transmits to its destination through the work. Routers and computer servers together act as nodes in the Internet or as points of presence, or POPs, i.e., gateways of limited connectivity to access the Internet. Some routers or servers acting as POPs are connected to the Internet through a small number of nearby devices, while other servers are interconnected to many devices and are also sometimes referred to as “super POPs”. For the sake of clarity, it should be recognized that the term POP in network vernacular should not be confused with the application name POP, or the plain old post office used for email applications.

Each router or server acting as a router contains in its memory file a routing table identifying addressable IP addresses and possibly addresses addressable by the routers above it. These routing tables are automatically downloaded and installed on all routers the first time they connect to the Internet, and are generally not loaded as part of routing packets through the network. When an IP packet enters a router, POP or super POP, the router reads enough IP addresses, usually the most significant digits of the address, to know where to direct the packet on its journey to its destination. For example, a packet destined for Tokyo from New York is first routed to Chicago, then through servers in San Francisco, Los Angeles, or Seattle before connecting to Tokyo.

Because the number of routers a packet traverses, and the available data rate of each connection between routers, varies by infrastructure and by network traffic and loading, there is no way to determine a priori which route is the fastest or best.

Unlike circuit-switched telephony, which uses packet-switched data to establish and maintain direct connections between clients, it monitors the Internet to route packets, determining which path is best, appropriate, or faster. There is no general intelligence to determine the best route to route a packet while doing so, nor is there any guarantee that two consecutive packets will even take the same route. Thus, a packet "finds" its way through the Internet based on the priorities of the routers it traverses and the companies operating the servers. Each router, in essence, contains certain routing tables and routing algorithms that define its preferred route according to network conditions. For example, a router's preference may prioritize sending packets to other routers owned by the same company, balancing traffic between connections with neighboring routers, finding the shortest delay to the next router, minimizing or to strategic business partners, or create fast lanes for VIP clients by skipping intermediate routers where possible. When a packet enters a router, there is no way to know whether the routing choice made by the designated POP is in the best interest of the sender or network server operator.

So in a sense, the route a packet takes is a matter of timing and luck. In the previous New York to Tokyo routing example, routing and resulting QoS can vary substantially based on small perturbations in the path, the so-called "butterfly effect" in non-linear equations. Considering the case where a packet from New York passes through "Router A" in Chicago, it is forwarded to Mexico City rather than California because California temporarily has high traffic. The Mexico City router then forwards the IP packet back to Singapore, from which it is finally sent to Tokyo. The next packet sent is routed through Chicago "Router B", which directs the packet to San Francisco and then directly to Tokyo in only two hops, due to low traffic at that point. In this case, the second packet may arrive in Tokyo before the first packet is routed through the longer, rounder path. This example highlights the problem of using the Internet for real-time communications, such as live video streaming or VoIP, that the Internet was not designed to guarantee delivery times or control network latency when delivery was performed. Latency can vary from 50 ms to 1 second or more depending on whether the packet is routed through only 2 servers or only 15.

The Internet's lack of routing control is problematic for real-time applications and also a problem of poor QoS, especially for carriers trying to provide Internet-based telephony by capturing free rides on top of the OTT carrier-Internet infrastructure. Because OTT carriers do not control routing, they cannot control delay or network latency. Another problem with packet-switched communication is that it is easy to exfiltrate data without being detected. If pirates intercept packets and identify source or destination IP addresses, they intercept data from intervening routers and sniff or redirect traffic through their own pirate networks to spy on conversations or even decrypt encrypted files. A variety of methods can be used.

Source and destination IP addresses and other important information used to route packets (and also used by pirates to hack packets) are strings of digital data called IP packets, IP datagrams, or TCP/IP packets. is designated as The IP packets contain digital information that defines the physical connections between devices, how the data is organized to link devices together, the network routing of packets, whether useful data (payload) has been delivered correctly, and what kind of data is in the payload. and then the payload data itself is used by various applications.

IP packets are sequentially sent and received as strings of digital bits, organized in a specific way called the Internet Protocol, established by various standards committees, including the Internet Engineering Task Force, among others. This standard ensures that any IP packet conforming to a specified protocol can be communicated and understood by any connected device conforming to the same IP standard. Ensuring the communication and interactivity of devices and applications connected to the Internet is a hallmark of the Internet, and also to prevent companies, governments or individuals from controlling the Internet or limiting its accessibility or functionality, open source initiatives ( Open Source Initiative) or OSI's guiding principles.

The OSI Model, an abstract concept involving seven layers of functionality, specifies precisely the format of an IP packet and what each segment of the packet is used for. Each part or "segment" of an IP packet corresponds to data that applies to a specific OSI Layer 4 function. The roles of the seven OSI layers are:

* Layer 1, the physical layer or PHY layer, contains hardware specific information that represents the physical characteristics of communication as electrical, RF, and optical signals, and how these signals can be converted into bits for use in a communication system. WiFi radio, Ethernet, serial port, fiber optic, 3G or 4G cellular radio, DSL over twisted pair copper wire, USB, Bluetooth, cable or satellite TV, or converting digital broadcasting of audio, video, or multimedia content into a bit stream This is the operation of the PHY layer. In an IP packet, the preamble represents Layer 1 data, and is used to synchronize the entire data packet, or "frame," to the hardware sending and receiving it.

* Layer 2 , the data link layer, contains bits arranged as frames and defines the rules and means by which the stream of bits delivered from PHY Layer 1 are converted into interpretable data. For example, a WiFi radio based bit stream may conform to any number of IEEE defined standards including 802.11a, b, g, n and ac; 3G radio communications can be modulated using HSDPA or HSUPA, which are high-speed packet access methods; An electrical signal on an optical or coaxial cable modulated in an optical fiber can be decoded into data according to the DOCSIS 3 standard. In an IP packet, layer 2 data encapsulates its payload into a datagram with a preceding "data link header" and a trailing "data link trailer", and a mechanism to ensure that the encapsulated transmitted payload is not lost in the transmission process. start and stop as One key element of layer 2 data is the MAC or media access address used to direct data traffic to or from a specific Ethernet address, RF link, or hardware specific transceiver link.

* Layer 3 , the Network or Internet layer, determines whether or not the packet contains IPv4 or IPv6 data and corresponding source and destination IP addresses, i.e. the type of transport protocol used, as well as information about the nature of the payload contained within the packet. Internet Protocol (IP) used to route IP packets, including whether it includes Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or something else It contains packets called "datagrams" that contain information. Layer 3 also includes functionality to prevent immortals where IP packets are never delivered but never die. ICMP, a layer 3 packet of a specific type, is used to diagnose the health of a network, including the well-known "ping" function. In an IP packet, the Layer 3 contains an "IP header" 82, which also encapsulates its payload, including transport and higher layer segments.

* Layer 4 , the transport layer, contains segments of data that define the characteristics of the connection between communicating devices, where UDP is the minimum description of the payload for connectionless communication, i.e. how large the payload is, any bits lost and which application services (ports) use the forwarded data. The UDP is considered connectionless because it does not verify delivery of the payload, but relies on acknowledging error or lost data on the application. The UDP is typically used for time-sensitive communications such as broadcasting, multicasting, and streaming, where retransmitting packets is not an option. In contrast, TCP guarantees a virtual connection by verifying packets, reliably delivering the payload before the next packet is sent, and retransmitting missed packets. TCP also includes the ability to check the data integrity of forwarded packets using checksums, and also to reassemble out-of-order packets in their original order. Both TCP and UDP define source and destination ports, a description of a higher layer service or application, e.g. a web server or email server, related information contained within a layer 4 payload. For IP packets, layer 4 contains the TCP/UDP header and also encapsulates the data/payload containing the content used by the upper OSI layers 5, 6 and 7.

* Layers 5, 6, 7 , higher or application layers describe the content delivered by the Internet as data/payload. Layer 7, the "Application" layer, represents the highest level in the OSI model and also relies on the six lower OSI layers to support both open source and proprietary application software. Commonly used Level 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. do. Proprietary applications include Microsoft Office suites (Word, Excel, PowerPoint), Adobe Illustrator, and Photoshop, Oracle and SAP database applications; Quicken, Microsoft Money, and QuickBooks financial software; In addition, document readers such as Adobe Acrobat Reader and Apple Preview (such as iTunes, QuickTime, Real Media Player, Windows Media Player, and Flash) ) includes audio and video players. Level 7 applications are syntactically defined by a Level 6, "Presentation" layer, which includes the presentation of documents, typically text, graphics and pictures, sound and video, XML or PDF, along with security features such as encryption. using embedded objects. Level 5, the "session" layer, establishes connectivity between applications, such as importing one object into another program file, and also controls starting and ending sessions.

As explained, the OSI 7-layer model defines the functionality of each layer, and corresponding IP packets encapsulate data for each other (one inside the other in a manner similar to a babushka or Russian nesting doll). wooden dolls in which there is one doll within another, and this continues). The outer packet, or Layer 1 PHY, defines the entire IP frame, including information related to all higher levels. Within this PHY data, the Layer 2 data frame describes the data link layer and includes the Layer 3 network datagram. This datagram again describes the Internet layer as its payload with layer 4 segment data describing the transport layer. The transport layer delivers higher layer data as a payload containing layer 5, 6 and 7 content. Seven-layer encapsulation is sometimes referred to as "everyone seems to need data processing", which sequentially lists the seven OSI layers from top to bottom as Application, Presentation, Session, Transport, Network, Data Link, and Physical layers. It is referred to as a mnemonic symbol.

While the lower physical and link layers are hardware-specific, the middle OSI layer, encapsulated within IP packets describing the network and transport information, is typically completely agnostic to the hardware used to communicate, transport and deliver IP packets. Moreover, upper layers encapsulated as the payload of the transport layer specify only applications that apply and operate completely independent of how packets are routed or delivered over the Internet. This segmentation allows each layer to be monitored essentially independently, supporting numerous technology and user combinations without the need for administrative approval of packet formatting or validation of packet payloads. Incomplete or inappropriate IP packets are simply discarded. In this way, the packet-switched network can route, transport, and deliver various application-related information over disparate communication media in a consistent fashion among any Internet-connected device or entity.

In conclusion, switched circuit networks are packet-switched network communications that divide documents, sound, video, and text into multiple packets and use multiple network paths (using best efforts to provide timely delivery). two or more parties communicate (similar to common implementation telephone systems a century ago) while forwarding these packets through a ) requires a single direct connection between A comparison between circuit-switched PSTN and packet-switched VoIP is summarized in the table below.

network PSTN Internet technology circuit switched packet switched connect dedicated electrical connection Each packet is routed through the internet data forwarding real time (line) Best effort delivery (packets) signal analog or digital Digital, IP, VoIP contents voice voice, text, data, video data rate lowness height error checking none, or minimal extensive Effects of broken lines dropped or short call Call rerouting Blackout Effects network delivers power battery backup required

While the PSTN operates using real-time electrical line connections, packet-switched networks are designed to deliver packets and payloads, unlike post offices that ultimately use different trucks and forwarders to deliver mail even if it arrives late. It should be recognized that content is delivered using a "best effort" method to find a way. The operation and communication of packet-switched networks is described in more detail in the background section of a related patent application entitled "Secure Dynamic Communication Network and Protocol", of which this disclosure is a continuation. Considering the capabilities of the network, the following Several factors are taken into account.

* Data Rate i.e. Bandwidth

* Quality of Service

* Network and data security

* User privacy

Of the above considerations, data rates are easily quantified in millions of bits per second, or Mbps. Quality of Service or QoS, on the other hand, includes several factors including latency, sound quality, network reliability, intermittent operation or frequent service outages, synchronization or connection failures, low signal strength, delayed applications, and functional network redundancy during emergency conditions. do. Cyber security and cyber privacy prevent attacks on the network, prevent cyber crime, cyber surveillance, IP packet sniffing, port interrogation and denial of service attacks, profiling, fraud, packet hijacking, cyber-infection, surveillance, piracy management and intrusion. Prevent unauthorized access to data traffic and content, including

service quality

Quality of service describes the performance of a network in terms of capacity, bandwidth, latency, data transfer rate, scalability, sound quality data integrity, and data bit error rate. For programs, files and security-related verification, data accuracy is an important factor. Which elements are important depends on the nature of the payload being carried over a packet-switched network. In contrast, for voice and video constituting real-time applications, factors that affect packet delivery time are important. Quality factors and how they affect various applications such as video, voice, data and text depend on the application. Good network conditions typical of constant high-speed data IP packet waveforms are minimal time delay, clear strong signal strength, no signal distortion, stable operation, and no packet transmission loss.

Intermittent networks with intermittent low data rate packet waveforms have the greatest impact on video functionality, causing painfully slow video downloads and unacceptable video streaming. A congested network operating at a lower effective data throughput with short period blocks exemplified by IP packet waveforms will not only severely degrade video by jittery intermittent motion, fuzzy video, and inappropriate color and brightness. Rather, distortions, echoes, and even entire sentences degrade speech or voice communication by missing dialogue or sound tracks. However, in congested networks, repeated requests for rebroadcasts can still transfer data using TCP.

In the extreme, unstable networks exhibit low data throughput with many data outages of unpredictable cycles. In addition, the unstable network contains corrupted IP packages, as represented by the dark shaded packets in waveform 610D, which must be retransmitted in TCP-based transports and simply discarded as corrupted or irrelevant data in UDP transports. At the level of network degradation, even email becomes intermittent, causing IMAP file synchronization to fail. Because of its lightweight data format, most SMS and text messages are delivered with some delay in delivery even in the face of severe network congestion, but attachments will not be downloaded. In an unstable network, all applications may fail, causing the normal operation of the computer or mobile phone to stop and waiting for expected files to be delivered. In these cases, the video freezes, the sound becomes choppy and incomprehensible, and the VoIP connection disconnects repeatedly a dozen or more times within a few minutes, and in some cases completely disconnects. Likewise, e-mail freezes or lags with a computer icon spinning round incessantly. All progress bars are stopped. Even text messages are bouncing and "undeliverable".

A number of factors can contribute to network instability, including power failures on key servers and super POPs, overloaded call capacity, transmission of large data files or UHD movies during severe denial of service attacks on selected servers or networks. , the main factors used to track the QoS of a network are its packet loss rate and packet latency. Dropped packets occur when an IP packet cannot be delivered and "times out" permanently, or when a router or server detects a checksum error in an IP packet header. For packets using UDP, packets get lost, and the layer 7 application has to be smart enough to know what was corrupted. If TCP is used for layer 4 transport, packets will be requested to be resent, further potentially adding loading to an already overloaded network.

Another factor that determines QoS, propagation delay, can be measured quantitatively in several ways, such as the delay of IP packets from node to node or the round-trip delay from source to destination in one direction, or alternatively from source to destination again. can The effect of propagation delay on packet delivery is different using UDP and TCP transport protocols. As the integrated network propagation delay increases, the time required to conduct a round-trip communication such as a VoIP conversation increases. In the case of UDP transmission, round-trip delay increases linearly with propagation delay. Since longer propagation delays are associated with higher bit error rates, the number of lost UDP packets increases, but since UDP requires retransmission of lost packets, the round-trip time remains linear with increased delay. TCP transport exhibits substantially longer round-trip times for each packet transmitted than UDP, due to the handshaking required to confirm packet delivery. If the bit error rate is low and most packets do not require retransmission, the TCP propagation delay increases linearly with the integrated propagation delay. However, if the communication network becomes unstable as the propagation delay increases, the round-trip time due to the TCP transmission increases exponentially due to the protocol's need for retransmission of dropped packets. Therefore, TCP is contraindicated for time-sensitive applications such as VoIP and video streaming.

Since all packet communication is statistical, with no two packets having the same propagation time, the best way to estimate the single-way latency of a network is by measuring the round-trip time of a large number of similarly sized IP packets, and the single-way latency This is done by dividing by 2 to estimate . Latency up to 100 ms is significant, up to 200 ms is considered quite good, and up to 300 ms is still considered acceptable. For a propagation delay of 500 ms, which is easily encountered by OTT applications running on the Internet, the delay is inconvenient for users and also interferes with normal conversation. In voice communications, especially these long propagation delays can sound "bad" and also reverberate, creating a "twangy" or metallic sound that will cause the other party to wait until the last moment to get your response. Interrupts normal conversation while waiting for a response to one's last comments, possibly resulting in distorted or incomprehensible speech.

For the sake of clarity, the one-way latency of the communication is in part because ICMP packets are generally lightweight compared to real IP packets, because ping tests don't use TCP's "resend requests", and because they're not very specific to the Internet's public networks. It differs from ping tests performed by layer 3 ICMP utilities (such as the free network test at http://www.speedtest.net) in that, since there is no reward, the root of the ping test matches the actual packing root. do. Essentially, when a ping experiences a long delay, there is something wrong with the network or some link between the device and the network, for example a WiFi router or the last mile, but a good ping result by itself is the actual packet's low propagation delay. There is no guarantee.

To improve network security, encryption and verification methods are often used to prevent hacking, sniffing, or spying. However, excessive encryption and multi-key encryption protocols constantly re-verify the identity of the talking party, causing additional delays, thereby increasing effective network latency and reducing QoS at the cost of improving security.

Cyber Security and Cyber Privacy

The other two major considerations in communications are cyber security and cyber privacy. Although related, the two issues above are somewhat different. “Cybersecurity, including network security, computer security, and secure communications, monitors, blocks, and prevents unauthorized access, misuse, modification, or denial of data contained within computer or communications networks, network-accessible resources, or network-connected devices. Data may include personal information, biometric data, financial records, health records, personal communications and records, as well as personal photographic images and video records. Networked devices are point-of-sale ( Mobile phones, tablets, laptops, desktops, file servers, email servers, web servers, databases, personal data, as well as publicly shared devices used by individuals, such as point of sale (POS) terminals, gas pumps, ATMs, etc. This includes storage, cloud storage, internet-connected devices, and connected cars.

Clearly, cybercriminals and computer hackers who attempt to gain unauthorized access to secure information are committing crimes. If the illegally obtained data contains personal information, the attack is an invasion of the personal privacy of the victim. Conversely, however, privacy breaches can occur without the need for cybercrime, and are also virtually unstoppable. In today's networked world, unauthorized use of an individual's information can occur without the need for a security breach. In many cases, a company that collects data for one purpose may sell its database to other clients who want to use the data for another purpose. Even Microsoft buys hotmail, it is well known that mailing lists are sold to advertisers interested in spamming potential clients. Whether such action should be considered a cyber-privacy invasion remains a matter of opinion.

"Cyberprivacy", which includes internet privacy, computer privacy, and private communications, includes the collection, storage, display, or sharing of information with others, to control that private and individual information and its rights, Include rights or obligations. Personal information may include personally identifiable information, including height, weight, age, fingerprints, blood type, driver's license number, passport number, social security number, or any personal information useful for identifying an individual whose name is not known. have. In the future, even a person's DNA map could become a legal record. In addition to personally identifiable information, non-personal private information includes the brands of clothes we buy, the websites we visit frequently, whether we smoke, drink alcohol, or own guns, what kind of car we drive, and what kind of car we drive. It can include what diseases we may have in our life, what diseases or a history of diseases our family members have, and even what kinds of people we are attracted to.

This personal information, combined with public records related to personal income, taxes, property deeds, criminal records, traffic violations, and any information posted on social media sites, forms a powerful data set for stakeholders. The intentional collection of large data sets that capture demographic, personal, financial, biomedical, and behavioral information and collect data on patterns, trends, and statistical correlations is known as "big data." . The healthcare industry, which includes insurance companies, healthcare providers, pharmaceutical companies and even medical lawyers, is strongly interested in personal information stored as big data. Automotive and consumables companies likewise want access to these databases to manage market strategies and advertising budgets. In recent elections, even politicians are starting to look to big data to better understand voter opinions and political issues to avoid.

The question of cyberprivacy today is not whether big data captures personal information (which is already standard procedure), but whether said data set holds enough personally identifiable information to identify you by name or without knowing it. whether there is For example, the original US government said that once a personal healthcare account was set up, personal information collected by the healthcare.gov website used to sign up for the Affordable Care Act would be destroyed. Then, in a recent posting, a third-party company that facilitates data collection for the US government has previously signed government contracts giving it the right to retain and use the data it collects, thus revealing personal privacy to the US government. The information was not actually private.

Finally, it should be mentioned that surveillance is carried out by both governments and criminal organizations using similar technological methods. While criminals clearly have no legal right to collect this data, instances of unauthorized government surveillance are more murky, varying dramatically from country to country. For example, the US NSA has repeatedly pressured Apple, Google, Microsoft and others to provide access to their clouds and databases. Even government officials have eavesdropped and intercepted their conversations and presentations. Asked if Skype, a division of Microsoft, monitors callers' content, the Skype chief information officer suddenly replied, "No comment."

Cyber Crime and Cyber Surveillance Methods - Focusing on the topic of cybersecurity, numerous means for unauthorized access to devices, networks, and computer data, including various malware and hacker techniques used to commit cybercrime and achieve unauthorized intrusion into secure networks this exists

For example, an individual using an internet-connected tablet can make a call to an office phone, send a message to a TV, call a friend in a country that still uses line-switched POTS networks with the phone, or use web storage. You can download a file from , or send an e-mail through an e-mail server. While all applications represent normal applications and global interconnectedness of the Internet, many opportunities exist for surveillance, cybercrime, fraud, and identity theft throughout the entire network.

For a tablet that connects to the network, for example, through a cellular radio antenna and LTE cellular base station, or through a short-range radio antenna and public WiFi base station, an unauthorized intruder can monitor the radio link. Similarly, LTE calls over cellular links can be monitored or "sniffed" by an blocking radio receiver or sniffer. The same sniffer monitors the WiFi link and can be tuned on the receiving end on the cable between the cable CMTS and the cable modem.

In some cases, LTE calls may be intercepted by a pirate faux tower, establishing a diverted communication path between the tablet and the cellular tower. Communications sent over packet-switched networks to routers, servers, servers, and cloud storage may be subject to man-in-the-middle attacks. The wired tap can intercept calls on the POTS line from the PSTN gateway to the phone and calls on the cooperating PBX line between the PBX server and the office phone.

Through a series of security breaches, spyware can install itself on a tablet or laptop, on a router, on a PSTN bridge, on cloud storage, on a cable CMTS, or on a desktop computer. Trojan horse software can install itself on tablets or desktops to phish passwords. The worm can also attack the desktop, especially if the computer is running a Microsoft operating system with the ActiveX feature enabled. Finally, to launch a denial of service attack, a virus can attack any number of network-connected devices, including servers, desktops, and tablets.

As such, malware can operate on different parts of communication networks and infrastructure, and cyberattacks can include viruses, man-in-the-middle attacks, government surveillance, and denial of service attacks. The last mile of the communications network presents an even broader opportunity for malware and cyberattacks, which are divided into three zones: local telco/network, last link, and device. Local telco/networks as shown include high speed wired or fiber optic links, routers, cable CMTS, cable/fiber, cable modems, WiFi antennas and LTE radio networks. In this part of the network, radio sniffers, spyware, viruses, and man-in-the-middle attacks are all possible.

For the last link, in the local connection to the device, network connections include wired connections exposed to spyware, radio sniffers, wiretap, and dummy towers, WiFi links, and LTE/radio cellular links. Devices themselves including, for example, tablets, notebooks, desktops, smart phones, smart TVs, POS terminals, and the like are exposed to many attacks including spyware, Trojan horses, viruses, and worms.

These surveillance methods and spy devices, including devices used to monitor traffic on Ethernet local area networks, devices for monitoring WiFi data, and devices for monitoring cellular communications, are readily available in commercial and online marketplaces. Although sniffing of fiber optic cloud connections was not initially identified as a threat, recently non-intrusive data sniffers for optical communications have emerged, i.e. one that does not need to break the fiber or even temporarily impair its normal operation. Data sniffers now exist.

Besides using hacking and spying methods, various commercial spyware can be readily used to monitor cell phone conversations and Internet communications. Today, commercially available spyware programs advertise many features, such as the ability to beneficially spy on your employees, your children, and your spouse. This set of characteristics together includes many ways to violate cyber privacy in a surprisingly convincing way: phone calls, photos and videos, SMS/MMS text messages, third-party instant messaging, email, GPS location tracking, internet usage, address books, Incredibly comprehensive, including monitoring of calendar events, eavesdropping, control applications, and even remote control functions. Indeed, cyber-attacks are now becoming all too frequent, and they are tracked every day. Initiating a cyberattack usually requires several steps or a combination of techniques, such as:

* IP packet sniffing

* Port interrogation

* profiling

* fraud

* Packet Stealing

* Cyber infection

* watch

* Pirate Management

IP Packet Sniffing - Using a radio monitoring device, cybercriminals can obtain important information about users, their transactions, and their accounts. In packet sniffing, the content of an IP packet can be obtained or "sniffed" anywhere on the path between two users. For example, when a user sends a file, e.g. a picture or text, as an IP packet from his laptop to his friend's phone, cyber pirates hijack the sender's last link, by hijacking the sender's local network. , by hijacking the cloud, by hijacking the recipient's local telco, or by hijacking the recipient's last link, IP packets can be found in many random places. The observable data contained in the intercepted IP packet is the Layer 2 MAC address of the device used for communication, the Layer 3 address of the sender on the receiving side, i.e. the destination of the packet, including the transport protocol, e.g. UDP, TCP, etc. include The IP packet also contains the layer 4 port numbers of the transmitting and receiving devices and the data file itself, potentially defining the type of service requested. If the file is not encrypted, the data contained in the file may be directly read by cyber pirates.

If the payload is not encrypted, textual information such as account numbers, login sequences, and passwords can be read and, if valuable, stolen or misappropriated for criminal purposes. If the payload contains video or pictographic information, some additional action is required to determine the layer 6 application format the content uses, but once identified, the content can be publicly viewed or posted. or possibly used to intimidate one or both of the communicating parties. These cyber-attacks are referred to as “man-in-the-middle attacks” because the cyber pirates do not personally know the communicating parties.

As already described, monitoring of the cloud is more difficult because the routing of IP packets in the cloud is unpredictable, because cyber pirates have to capture important information in IP packets when they first appear, so that subsequent packets are identical. This is because it cannot follow routes and sniffed packets. Intercepting data in the last mile has a greater chance of observing a series of related packets containing the same conversation, so that the local router will follow the specified routing until the packet reaches the POP outside the client's own carrier. Because it follows the table normally. Comcast's clients, for example, will traverse IP packets up the routing chain using an entirely Comcast-owned network until the packet travels geographically beyond Comcast's reach and client service area.

If a sequence of packets between the same two IP addresses occurs for a sufficiently long time, it is possible to recreate the entire conversation piecemeal. For example, if an SMS text message passed over the same network in the last mile, cyber pirates could, via IP address and port number, multiple IP packets carrying the text establish a conversation between the same two devices, a cell phone and a laptop. can be identified. Thus, even if account numbers and passwords are textually written in different messages or incompletely disseminated for many packets, the consistency of packet identifiers still allows cyber pirates to reconstruct conversations and steal account information. Once account information has been stolen, they can take over account privileges by transferring money to an offshore bank or even changing account passwords and security questions, which temporarily identifies the theft.

Even if the payload is encrypted, the rest of the IP packet including the IP address and port # is not encrypted. After repeatedly sniffing a large number of IP packets, a cyber pirate with access to sufficient computing power can systematically try every combination by brutal shear force until they break the encryption password. Once the key is destroyed, the packet and all subsequent packets can be decrypted and used by cyber pirates. The probability of cracking a login password by "guessing a password" is greatly improved when packet sniffing described below is combined with user and account "profiling". In a “man-in-the-middle attack,” communication devices are generally not involved because cyber pirates do not have direct access to them.

Port Interrogation - Another way to break into a device is to interrogate a number of layer 4 ports and use its IP address to see if any request receives a response. Once the cyber pirate identifies the IP address of the target device from packet sniffing or other means, the cyber pirate can initiate a series of interrogations of ports on the device to find insecure or open ports, service and maintenance ports, or application backdoors. have. While a hacker's interrogation program can systematically cycle through all port #, the attack will typically use port # 7 for ping, port # 21 for FTP, port # 23 for telnet terminal emulation, and port # 23 for simple email. Focus on notoriously vulnerable ports, such as #25. Each time the pirate sends a packet to which the device responds, the pirate learns more about the target device's operating system.

In the course of port interrogation, cyber pirates do not want to reveal their real identities, so they will use disguised pseudo-addresses to receive messages that cannot be personally traced. Alternatively, cybercriminals can use stolen computers and accounts, making it look like someone else is trying to hack the target device, and if they do track it, it turns the investigator back to an innocent person rather than them.

Profiling - User and account profiling is when cyber pirates use publicly available information to decipher passwords, identify accounts, and determine assets about a target, its accounts, and its personal records. It is a learning process. Once the hacker has obtained the target's IP address using sniffing or other methods, a traceroute utility can be used to find the DNS server of the device's account. Then, by using a "Who is" function on the Internet, the account holder's name can be found. In profiling, cybercriminals search the Internet to collect all available information about the account holder. Sources of information include public records such as property deeds, vehicle registrations, marriages and divorces, tax liens, parking tickets, traffic violations, criminal records, and the like. In many cases, web sites from universities and professional societies include home addresses, email addresses, phone numbers, and birth dates of individuals. By examining social media sites such as Facebook, LinkedIn, Twitter and others, cybercriminals can find names of family and friends, pets, as well as photos and video files, including embarrassing incidents, family secrets, and personal enemies. It can collect important information such as previous home addresses, classmates, other people's major events and photos.

The cyber pirate's next step is to use this profile to "guess" the user's password based on that profile to hack the target device and other accounts of the same individual. Once cybercriminals have cracked one device password, they are more likely to break into other accounts, as people tend to reuse passwords to make them easier to memorize. At that point, it is possible to steal people's identities, transfer money, make them the target of police investigations, steal all of their wealth, and radically destroy other people's lives. For example, as described at the outset of this invention, which gathers long lists of passwords from stolen accounts, cybercriminals use the same passwords and login information to illegally purchase multi-million dollar premium tickets to concerts and sporting events. password was used.

Imposters - Cyber pirates act as "imposters" when they impersonate someone or use illegally obtained cybersecurity credentials to gain access to communications and files by pretending to be an authorized person or device. A scammer type of cyberattack is where the cybercriminal has sufficient information or access to an individual's account in order to take over the victim's account, send messages on their behalf, and misrepresent them as the owner of the compromised account. Recently, for example, a personal friend of one of the inventors had his "Line" personal messenger account hacked. After taking over the account, the cybercriminal misrepresented that "she needed the money for an emergency loan due to a car accident" and sent a message to her friend that included sending instructions where to send the money. Unaware that her account had been hacked, she thought her friend's request was real and immediately offered financial help. For the avoidance of doubt, the request sent to each friend was no more than $1,000. Fortunately, just before sending the money, one of her friends called her to double-check the wired information and the fraud was exposed. Without the phone, no one would have known that the request came from a scammer, and the Line account holder would never have known that a wire transfer was sent or requested.

Another form of misrepresentation occurs when a device is granted security privileges and is able to exchange information with a server or other networked device, and also somehow the cyber pirate device disguises itself as an authorized server, thereby disguising the victim's device , unaware that the server is a fraudster, and willingly hand over files and information to the pirate server. This method was used to trick celebrities into backing up their personal photo files to iCloud, except that Backup Cloud is a scam.

Another form of fraud occurs when a person with physical access to a person's phone or open browser performs a fraudulent activity, such as sending an email, answering a phone call, or sending a text message from another person's account or device. The receiving party assumes that they are associated with a known device or account and that the person operating the device or account is the owner. Scams can be pranks, such as friends posting embarrassing comments on Facebook, or more personal in nature, such as someone's spouse answering a personal phone call or intercepting personal text messages of a personal nature. Unauthorized access can result in jealousy, divorce, and revenge legal proceedings. If the device goes unmonitored for a while in an office or cafe, for example going to the bathroom, scammers can quickly access personal or corporate information, as described in the next section titled “Infection,” or There are other risks of sending emails, transferring files, or downloading some form of malware onto your device.

Fraudster-based cyberattacks are important even when a device is stolen. In this case, even if the device is logged out, the thief has enough time to destroy the login code. The "Find My Computer" feature, which locates stolen devices on computers and erases computer files the first time cyber pirates log on to a device, is because tech-savvy criminals know to only activate devices that don't currently have a cellular or WiFi connection. doesn't work anymore This risk is especially great for mobile phones where pass line security is a simple 4-digit personal ID number or PIN. Breaking the PIN is only a matter of time as there are only 9999 possible combinations.

A major issue for keeping devices secure is preventing fraudsters from gaining access. Deterring fraudsters requires robust means of authenticating users' identities at regular intervals and ensuring that they are authorized to access only the necessary information and privileges. Device security is often the weakest link in the chain. Once the security of the device has been compromised, it is not worth considering strong network security.

Packet Hijacking - Packet hijacking involves a cyberattack in which the normal flow of packets through a network is diverted through a hostile device.

For example, if the integrity of a router is compromised by a cyber attack from a cyber pirate, IP packets passing through the router can be rewritten into revised IP packets, and IP packets can be rewritten to a different destination address and port of the cyber pirate device. # can be switched. The cyber pirate device can then get all the information it needs from the payload of the IP packet and change the contents of the payload of the IP packet. Fraudulent payloads can be used to commit any number of fraudulent crimes, gather information, and download malware to mobile phones, as described in the "Infections" section below.

The hijacked packet is then reconstructed to look like the source IP address of the original IP packet, except that the packet goes through a new and different path. Alternatively, the hijacked IP packets can be returned to the compromised router and then sent to the cloud as before. To maximize the criminal gains of packet hijacking, cyber pirates need to conceal their identities in packet hijacking, for that reason disguising the actual routing of IP packets, so that even the layer 3 ICMP function "trace route" can will have difficulty identifying the actual path of However, in cases where hijacking adds significant delay in packet routing, the anomalous latency can be immediately investigated by network operators.

Cyber-infections - One of the most insidious categories of cyber-attacks is to gather information, commit fraud, redirect traffic, infect other devices, compromise or block systems, or cause denial of service failures. It is a "cyber infection" that causes malware to thereby install malware on the target device or devices. Cyber infections can spread through email, files, websites, system extensions, applications or networks. One common classification of malware, “spyware,” collects all kinds of processing information and passes it on to cyber pirates. In the case of "phishing", a wen page or application shell that looks like a familiar login page asks for information about account logins or personal information and passes the information to the cyber pirates. Other malware infections can take control of hardware, eg controlling routers to perform the aforementioned packet hijacking. In these cases, cyber pirates seek to gain information or control interests for their own purposes.

Other classes of cyber-infections, including viruses, worms, and Trojans, are designed to overwrite important files or repeatedly execute meaningless functions, preventing the device from performing its normal operation. Basically, it denies service, degrades performance or kills the device outright. These malicious infections are destructive in nature and are used for malicious purposes, thereby preventing a competitor's business from functioning normally, or simply for fun motives to see if a hacker is capable.

Surveillance - Intrusion and surveillance go beyond cybercrime. In such cases, a private detective or acquaintance is hired or forced to install a device or program on a target's personal device to monitor voice conversations, data exchanges, and location. Because the detective needs temporary access to the target device without the subject's knowledge, this is a greater risk of being caught. For example, SIM cards that can copy a cell phone's network access rights are commercially available, but at the same time can transmit information to cybercriminals monitoring a target's call and data traffic.

Other forms of surveillance include monitoring a person's every action and phone calls using secret video cameras, just like being in a casino. Through video monitoring, it is possible to obtain the password or PIN of a device simply by observing the user's keystrokes during the login process. If enough cameras are in place, eventually the login process is recorded. In order to gain unsuspecting access to camera networks, cyber pirates can hack existing camera surveillance systems in buildings, stores, or streets and access other people's networks to monitor the unsuspecting victim's actions. The combination of video surveillance and packet sniffing provides a more comprehensive data set for launching subsequent cyberattacks.

Pirate Administration (Infiltration) - Another avenue cyber pirates can use to gain information is to hack and gain access to system administration privileges on a device, server or network. Thus, one user By hacking the system administrator's login, rather than gaining unauthorized access to the system's account, cyber pirates can exploit significant access and privileges without the system user's knowledge. There is no one to catch criminal activity, and in a system or network with essentially corrupt administrators, there is no one to oversee the police.

Conclusion - The ubiquity and interoperability brought about by the almost universal adoption of the Internet, Packet-Switched Networks and the 7-Layer Open Source Initiative network model have in the last 20 years brought an incomparable expansion of global communications, from smartphones to tablets to computers to smart TVs. , provided a wide range of devices ranging from automobiles, home appliances and light bulbs. The worldwide adoption of Internet Protocol, or IP, as the foundation for Ethernet, cellular, WiFi and cable TV connectivity has made unified communications as well as the challenge of hackers and cybercriminals to break into as many devices and systems as possible greatly simplified. Given the many software and hardware methods that can attack current communications networks, no single security method as a single defense is sufficient. Instead, a systematic approach is desired to secure all devices, end links, local telcos/networks and cloud networks to ensure their protection against sophisticated cyber attacks. The method employed must provide intrinsic cybersecurity and cyberprivacy without sacrificing QOS, network latency, video or sound quality. While encryption must remain an important component of these next-generation developments in secure communications and data storage, the security of networks must not rely solely on encryption methodologies.

In accordance with the present invention, data (broadly defined to include text, audio, video, graphics and any other kind of digital information or files) is transmitted over a secure dynamic communications network and protocol (SDNP) network or "cloud". . An "SDNP" cloud consists of multiple "nodes", also referred to as "media nodes", individually hosted on servers or other types of computer or digital equipment (collectively referred to herein as "servers") located anywhere in the world. include It is possible for two or more nodes to be located on a single server. Typically, data is transmitted between media nodes by light carried over fiber optic cables, by radiowaves in the radio or microwave spectrum, by electrical signals conducted on copper or coaxial cables, or by satellite communications. Although transmitted, the present invention broadly refers to the transmission of digital data from one point to another. The SDNP network is a "last mile" link between the SDNP cloud and client devices such as cell phones, tablets, laptop and desktop computers, mobile consumer electronics and devices such as the Internet, as well as Internet of Things devices and electronics, automobiles, and other vehicles. as well as the SDNP cloud. Last mile communications also include cell phone towers, residential cable or fiber, and public WiFi routers. In the last mile, the link between the client device and the nearest cell phone tower or other re-transmitter is referred to as the "last link".

When transmitted between media nodes in the SDNP cloud, data is in the form of "packets", which are discrete strings of digital bits that can be of fixed or variable length, and the data is also subject to the following techniques: scrambling, encryption or splitting. or its reverse process, unscrambling, decryption and mixing (note: as used herein, unless the context dictates otherwise, the word "or" is used in a conjunctive (and/or) sense) disguised by using

Scrambling involves rearranging data within data packets; For example, data segments A, B, and C appearing in that order in a packet are rearranged into sequences C, A, and B. The opposite of the scrambling operation is referred to as "unscrambling" and involves rearranging the data within the packet in the order in which A, B and C first appeared in the above example. The combined operation of unscrambling and then scrambling the data packet is referred to as "re-scrambling". When re-scrambling an already scrambled packet, the packet may be scrambled in the same or different manner as the previous scrambling operation.

The second operation, "encryption", encodes the packet's data into a form called ciphertext, which is transparent to the sender and other authenticated persons, and who must perform the reverse operation - "decryption" - to do so. can only be understood by The combined action of decrypting a packet of ciphertext data and re-encrypting it is typically, but not necessarily using a method different from that already used to encrypt it, referred to herein as "re-encryption". is referred to as

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 recombining two or more packets into a single packet. Splitting previously split and then mixed packets may be the same as or different from previous splitting operations. The sequence of operations is reversible, so that no division can be performed by mixing, and conversely, mixing multiple inputs into one output cannot be done by division to recover the components by division (Note: : Because scrambling and unscrambling, encryption and decryption, and splitting and mixing are inverse processes, knowledge of the algorithms or methods used to perform them is required to do the opposite, so here special scrambling, encryption, or Regarding the segmentation algorithm, it should be recognized that knowledge of the algorithm permits performing the reverse process.)

In accordance with the present invention, data packets traversing the SDNP cloud are either scrambled or encrypted, or in combination with segmentation, undergo one or both of these operations. Also, "junk" (i.e. meaningless) data may be added to the packets to make the packets more difficult to decipher or to fit the packets to a required length. Moreover, packets can be parsed, i.e. broken into separate fragments. In computing languages, to parse is to break a computer language statement, computer instruction, or data file into parts that are useful to a computer. Parsing may be used to obscure the purpose of a command or data packet or to arrange data into data packets with a specified data length.

Even though the format of the data packets conforms to the Internet protocol, within the SDNP cloud, the addresses of media nodes are not standard Internet addresses, i.e. they cannot be identified by any Internet DNS server. Thus, although a media node can technically receive data packets over the Internet, the media node does not recognize addresses or respond to queries. Furthermore, even if Internet users contact the media node, they cannot access or inspect the data inside the media node, as the data within the media node may be perceived as a fraudster who does not have the necessary identification credentials as an SDNP media node. . In particular, unless a media node is registered as a valid SDNP node running on a SDNP name server or an equivalent capable server, data packets sent from that node to other SDNP media nodes will be ignored and discarded. In a similar way, only clients registered with SDNP name servers can contact SDNP media nodes. As with unregistered servers, data packets received from sources other than registered SDNP clients will be ignored and immediately discarded.

In a relatively simple embodiment, referred to as "single route", a data packet traverses a single path through a series of media nodes in the SDNP cloud, where it is scrambled at media nodes entering the cloud and also media packets exiting the cloud. node (these two nodes are referred to as "gateway nodes" or "gateway media nodes"). In a slightly more complex embodiment, packets are re-scrambled at each media node using a different scrambling method than that used at the previous media node. In another embodiment, a packet is encrypted at the gateway node where it enters the cloud and decrypted at the gateway node where it exits the cloud, and the packet can also be re-encrypted at each media node it passes through in the cloud. Because a given node uses the same algorithm each time it scrambles or encrypts a packet, this embodiment is described as "fixed" scrambling and encryption.

When a packet is subjected to two or more operations, e.g. scrambled and encrypted, the reverse operations are preferably performed in the reverse order of the operations themselves, i.e. in reverse order. For example, if a packet is scrambled and then encrypted before leaving a media node, it is first decrypted and then unscrambled when it arrives at a subsequent media node. The packet is recreated in its original form only while within the media node. While packets are being transmitted between media nodes, they are scrambled, split, mixed, or encrypted.

In another embodiment, referred to as "multi-route" data transmission, packets are split at the gateway node, and the resulting multiple packets traverse the cloud in a series of "parallel" paths, with no path other than the gateway node. Do not share media nodes with other routes. Multiple packets are typically mixed to recreate the original packet at the egress gateway node. So even if a hacker can understand the meaning of a single packet, they will only get part of the whole message. The packet may be scrambled and encrypted at the gateway node before or after it is split, and the multiple packets may be re-scrambled or re-encrypted at each media node they pass through.

In other embodiments, packets do not travel through only a single path or series of parallel paths in the SDNP cloud, but rather packets can travel through multiple paths, many of which intersect each other. Since the picture of possible routes in this embodiment resembles a mesh, it is referred to as "meshed transport". As in the previous embodiment, packets can be scrambled, encrypted, and split or mixed as they pass through individual media nodes in the SDNP cloud.

The path of a packet through the SDNP network is determined by a signaling function, which is implemented by a separate signaling node running on a dedicated signaling server to a segment of the media node itself or preferably "dual-channel" or "triple-channel" example can be performed. The signaling function determines the route of each packet as it leaves the sending client device (eg mobile phone) based on network conditions (eg propagation delay) and the priority and urgency of the call, which determines the packet It informs each media node along the route that receives the , and also commands the node to transmit it. Each packet is identified by a tag, and the signaling function instructs each media node which tag to apply to each packet node it transmits. In one embodiment, the data tag includes, in an SDNP header or sub-header, a data field appended to each data sub-packet used to identify the sub-packet. Each sub-packet may contain a segment of data from one or multiple sources stored in a designated data "slot" in the packet. During data transmission between any two media nodes, there may be multiple sub-packets within one large data packet.

The routing function aligns with the splitting and mixing function, because once a packet is split, the path of each of the split sub-packets must be determined, and the node on which the sub-packets are reassembled must be instructed to mix them. because it does Packets can be split once and then mixed, as in the multi-route embodiment, or split and mixed multiple times as they exit the gateway node through the SDNP network. Determining at which nodes a packet will be split, how many sub-packets will be split, each path of the sub-packets and at which nodes the sub-packets will be mixed to recreate the original packet is determined by separate signaling. Whether performed by the server or not, all are under the control of the signaling function. The segmentation algorithm may specify which data segments in the communication are to be included in each sub-packet, and the order and location of the data segments in the sub-packets. The mixing algorithm reverses this process at the node where the sub-packets were mixed to recreate the original packet. Of course, if so directed by a signaling function, the node may also re-segment the packet according to a different segmentation algorithm corresponding to the time or condition in which the segmentation process occurs.

When a media node is commanded by a signaling function to send multiple packets to a particular destination media node on the "next hop" over the network, whether these packets are split packets (sub-packets) or they are different messages , a media node may be used, especially when multiple sub-packets share a common destination media node for their next hop (similar to a post office that puts a group of letters intended for a single address into a box and sends the box to the address). , packets can be combined into a single large packet.

In the "dynamic" embodiment of the present invention, individual media nodes in the SDNP cloud cannot use the same scrambling, encryption, or splitting algorithms or methods on successive packets passing through them. For example, a given media node may scramble, encrypt, or split one packet using a particular scrambling, encryption, or splitting algorithm, and then scramble, encrypt, or split the next packet using a different scrambling, encryption, or splitting algorithm. can be divided "Dynamic" operation greatly increases the difficulty a hacker may face because they have only a short time (e.g. 100 msec) to understand the meaning of a packet, and even if they succeed, that The usefulness of knowledge will be short-lived.

In a dynamic embodiment, each media node is associated with what is known as a "DMZ Server", which can be viewed as part of a node isolated from a data transfer port, and which media node can apply to outgoing packets. It has a database containing a list or table ("selector") of possible scrambling, encryption and splitting algorithms. The selector is part of a body of information referred to as a "shared secret" because the information is not known even to the media node, and also because all DMZ servers use the same selector at any given time.

When a media node receives a scrambled packet, in a dynamic embodiment, it also receives a "seed" which is used to indicate to the receiving node which algorithm will be used to unscramble the packet. A seed is a fake number that has no meaning in itself but is based on a constantly changing state, such as the time a packet was scrambled by a conventional media node. When the conventional node scrambled a packet, its associated DMZ server generated a seed based on its state. Of course, that state was used by the relevant DMZ server in selecting the algorithm used to scramble the packet, which was sent to the sending media node in the form of instructions on how to scramble the packet. Thus, the transmitting node has received both an instruction on how to scramble the packet and a seed to be transmitted to the next media node. The seed generator, running within the DMZ server, created the seed using an algorithm based on the state of the process when it was running. Even though the seed generator and its algorithms are part of the media node's shared secret, the generated seed is not secret because it does not access algorithms that numerical seeds do not have meaning for.

Thus, the next media note on the packet's route receives the scrambled packet and a seed derived from the state associated with the packet (e.g., the time it was scrambled). The seed may be included in the packet itself, or it may be transmitted to the receiving node prior to the packet along the same route as the packet or through some other route, such as through a signaling server.

Regardless of how it receives the seed, the receiving node sends the seed to the DMZ server. Since that DMZ server is part of the shared secret and therefore has a selector or table of scrambling algorithms identical to the selector in the sending node's DMZ server, it can use the seed to identify the algorithm that was used to scramble the packet; It can also instruct the receiving node how to unscramble the packet. Accordingly, the receiving node regenerates the packet in its unscrambled form, thereby restoring the original data. Typically, the packet will be scrambled again according to another scrambling algorithm before being transmitted to another node. If so, the receiving node cooperates with the DMZ server to obtain a scrambling algorithm and seed, and the process repeats.

Thus, as a packet progresses through the SDNP network, it is scrambled by each node according to a different scrambling algorithm, and a new seed is generated at each node that allows the next node to unscramble the packet.

In an alternative embodiment of the present invention, actual state (e.g., time) may be transmitted between nodes (ie, the sending node does not need to send a seed to the receiving node). The DMZ servers associated with both the sending and receiving media nodes contain, at a given point in time, a covert number generator containing the same algorithm (again, part of the shared secret). The DMZ server associated with the sending node uses the state to determine a scrambling algorithm from a selector or table of possible scrambling algorithms by generating a concealment number and a concealment number. The transmitting node transmits the status to the receiving node. Unlike the seed, the stealth number is never propagated over the network, but exclusive private communication is maintained between the media node and its DMZ server. When the receiving media node receives the status of the incoming data packet, the concealment number generator and its associated DMZ server use the status to generate the same concealment number, which then uses a selector to identify the algorithm to be used for unscrambling the packet. or used in tables. The status may be included in the packet or may be transmitted from the sending node to the receiving node prior to the packet or via some other route.

The techniques used for dynamic encryption and splitting are similar to those used in dynamic scrambling, but in dynamic encryption a "key" is used instead of a seed. The shared secret held by the DMZ server contains selectors or tables of encryption and splitting algorithms and key generators. In the case of symmetric key encryption, the sending node sends a key to the receiving media node used by the receiving node's DMZ server to identify the algorithm used to encrypt the packet and decrypt the file accordingly. In the case of asymmetric key encryption, the media node requesting the information, i.e. the receiving node, first sends the encryption key to the node containing the data packet to be transmitted. After that, the sending media node encrypts the data according to the encryption key. Only the receiving media node that generates the encryption key retains the corresponding decryption key and the ability to decrypt the ciphertext generated using the encryption key. Importantly, in asymmetric encryption, access to the encryption key used for encryption does not provide any information on how to decrypt the data packet.

In case of splitting, the media node from which the packets were split sends a seed to the media node where the resulting sub-packets will be mixed, and also the DMZ server associated with the mixing node identifies the splitting algorithm and thus the algorithm to be used when mixing the sub-packets. use that seed to do

As discussed above, in a dual or triple channel embodiment, signaling functions are performed by signaling nodes operating in separate server groups known as signaling servers. In this embodiment, the seed and key may be transmitted through a signaling server instead of directly from the sending media node 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 mentioned above, since the signaling server is responsible for designing the path of the packets, the signaling server knows the next media node to which each packet is directed.

To make it more difficult for a hacker, a list or table of possible scrambling, splitting, or encryption methods in a selector is periodically (e.g., hourly or daily) " can be shuffled. Thus, the encryption algorithm applied by a given media node to packets created at time t1 on day 1 may be different from the encryption algorithm it applies to packets created at the same time t1 on day 2.

Each DMZ server is physically associated with one or more media nodes, typically in the same "server farm". As mentioned above, a media node can request instructions on what to do with a received packet by providing a seed or key to its associated DMZ server (e.g., based on the time or condition at which the packet was created). However, the media node cannot access the shared secret or any other data or code within the DMZ server. The DMZ server may respond to this request by using a seed or key to determine which method the media node should use when unscrambling, decrypting, or mixing packets. For example, if a packet is being scrambled and the media node wants to know how to unscramble it, the DMZ server can look in the scramble algorithm list (or selector) to find the specified algorithm corresponding to the seed. The DMZ then instructs the media node to unscramble the packets according to its algorithm. That is, the media node sends queries issued on the seed or key to the DMZ server, and the DMZ server responds to these queries with instructions.

Although media nodes are accessible via the Internet (even if they do not have DNS-resolved IP addresses), the DMZ server is completely isolated from the Internet with only local network connections to media servers networked via wire or fiber.

In a "single channel" embodiment, the seed and key may be transmitted between the sending media node and the receiving media node as part of the data packet itself, or they may be transmitted in separate packets as data packets prior to the data packet on the same route. For example, when encrypting a packet, media node #1 may include an encryption key in the packet based on the time the encryption was performed. When the packet arrives at media node #2, media node #2 sends the key to its associated DMZ server, which can select a decryption method in its selector and use the key to perform decryption. Media node #2 can ask the DMZ server how it should re-encrypt the packet before sending it to media node #3. Again, the DMZ server consults with the selector, informs media node #2 which method to use when encrypting the packet, and delivers to media node #2 a key reflecting the state corresponding to the encryption method. Media node #2 performs the encryption and sends the encrypted packet and key (separately or as part of the packet) to media node #3. The key can then be used in a similar manner by media node #3 to decrypt the packet. As a result, there is no single fixed decryption method that hackers can use to decrypt packets.

The use of time or dynamic "state" conditions in the above example as a determining factor in the scrambling encryption or splitting method to be implemented on a seed or key is illustrative only. Any variable parameter, for example the number of nodes a packet has traversed, may be used as the "state" of a seed or key to select a specific scrambling, encryption, or splitting method to be used.

In a "dual channel" embodiment, the seed and key may be transmitted between media nodes over a second "command and control" channel made up of signaling servers, rather than directly between media nodes. Signaling nodes may also provide routing information to media nodes, and may also inform media nodes along a packet route how packets are split or mixed into other packets, and they also allow the next media node(s) to recognize the packet(s). It is transmitted by applying an identification "tag" to each media node so that The signaling server preferably supplies only the last and next media nodes of packets traversing the network to a given media node. Individual media nodes cannot know the entire route of a packet through the SDNP cloud. In some embodiments, the routing function may be split between two or more signaling servers, with one signaling server determining the route to a particular media node, and a second signaling server from there to other media nodes and Determine the route to the egress gateway node. In this way, a single signaling server does not know the complete routing of data packets.

In the "triple channel" embodiment, a third group of servers called "name servers" are used to identify elements within the SDNP cloud and also store information about devices connected to the SDNP cloud and their corresponding IP or SDNP addresses. do. The name server also continuously monitors media nodes in the SDNP cloud, maintaining a current list of active media nodes and a propagation delay table among all combinations of media nodes in the cloud. In the first step of placing a call, a client device, such as a tablet, sends an IP packet to a name server requesting the address and other information for the destination or person to be called. Also, a separate dedicated name server is used to act as a first contact whenever a device first connects, eg registers, on the cloud.

As an additional security benefit, separate secure "zones" with different selectors, seed and key generators, and different shared secrets can be set up within one SDNP cloud. Adjacent zones are connected by a Bridge Media Node, which holds the shared secret of the two zones and also converts data formatted according to the rules of one zone into data formatted according to the rules of the other zone, and vice versa. can do.

Similarly, for communication between different SDNP clouds hosted by different service providers, full-duplex (i.e., two-way) communication links are established between the interface bridge servers of each cloud. Each interface bridge server has access to the relevant shared secrets and other security items for each cloud.

An important advantage of the disclosed invention is that in SDNP networks there is no single point of control and no node or server in the network has a complete picture of how a given communication takes place or how it can change dynamically.

For example, signaling nodes running on signaling servers know the route (or in some cases only some routes) that communication takes place, but they do not have access to the data content being communicated, and who the actual sender or client is. do not know Furthermore, since the signaling node does not have access to the shared secret of the media node's DMZ server, it does not know how the data packets in transit are encrypted, scrambled, split, or mixed.

SDNP name servers know the actual phone number or IP address of the caller, but do not have access to the data being communicated or to route the various packets and sub-packets. Like the signaling node, the name server does not have access to the shared secret of the media node's DMZ server, so it does not know how data packets in transit are encrypted, scrambled, split or mixed.

The SDNP media node actually transmitting the media content does not know who the sender it is communicating with is nor does it know the route the various fragmented sub-packets are taking through the SDNP cloud. In practice, each media node only knows which data packets are to arrive (identified by their tags or headers) and where to send them next, i.e. the "next hop", but the media node knows only that the data is encrypted, scrambling It doesn't know how to split, mix, or split files, nor how to select algorithms or decrypt files using state, numeric seeds, or keys. The know-how required to correctly process the data segment of an incoming data packet is known only to the DMZ server using its shared secret, an algorithm that is not accessible over the network or by the media node itself.

Another inventive aspect of the disclosed subject matter is the ability to reduce network latency and minimize propagation delay to control the size of data packets to provide better quality of service (QoS) and eliminate echo or dropped calls; That is, sending smaller packets of data in parallel through the cloud rather than relying on a single high-bandwidth connection. Dynamic routing in SDNP networks uses knowledge of the network's node-to-node propagation delays to dynamically select the best route for any communication at that moment. In another embodiment, for high-priority clients, the network can facilitate race routing and send redundant messages in fragmented form through the SDNP cloud selecting only the fastest data to recover the original sound or data content. can

Among the many advantages of the SDNP system according to the present invention, in the parallel and "meshed transport" embodiments, packets can be fragmented as they traverse the SDNP cloud, allowing potential hackers to avoid individual sub-packets or groups of sub-packets. and, in the "dynamic" embodiment, the scrambling, encryption, and segmentation methods applied to the packets are constantly changing, so that at any given point in time, a potential hacker can move away from successfully decrypting the packet. refuses to take any significant advantage. Many additional advantages of embodiments of the present invention will become readily apparent to those skilled in the art upon review of the following description.

Similar security techniques can be applied generally at the "last mile" between the SDNP cloud and the client device, eg a mobile phone or tablet. The client device is typically deployed in a secure enclave separate from the cloud, which may first become an authenticated SDNP client, and a step is to download a software package specific to the device's secure enclave, typically via download from an SDNP management server. Including installing on the client device. Client devices are linked to the SDNP cloud through a gateway media node (sometimes just referred to as a "gateway") within the cloud. The gateway media node has access to the shared secret associated with both the cloud and the secure area of the client's device, but the client device does not have access to the shared secret associated with the SDNP cloud.

As an added level of security, client devices can directly exchange seeds and keys with each other via the signaling server. Thus, the sending client device can directly transmit the seed and/or key to the receiving client device. In such an embodiment, the packets received by the receiving client device will be in the same scrambled or encrypted form as the packets leaving the sending client device. Accordingly, the receiving client device can use the seed or key it receives from the sending client device to unscramble or decrypt the packet. The direct exchange of seeds and keys between client devices adds to the SDNP network's own dynamic scrambling and encryption, and thus represents an added level of security referred to as nested security.

Also, the client device or the gateway node that the client device uses to communicate can send data of the same kind - e.g., a voice packet, a text message file, a document, a piece of software, or a different type of data - before the packet reaches the SDNP network. It is possible to mix packets representing information, e.g. one voice packet and one text file, one text packet, and one video or photographic image, egress gateway node or destination client device being mixed. The original packet can be restored by splitting the packet. This is in addition to any scrambling, encryption or splitting occurring in the SDNP network. In such a case, the sending client device may send a seed to the receiving client device describing how to split the packets in order to reproduce the original mixed packets at the sending client device or gateway media node. Successful implementation of blending and splitting may involve a linear sequence of operations, or alternatively utilizes a nested architecture, where the client implements its own security measures and accordingly the SDNP cloud.

To further confuse a possible hacker, a client device can send successive packets (or sub-packets) in a single communication to different gateway nodes, and/or the client device can send them to different physical media links (cellular , WiFi, Ethernet cable, etc.) - a process sometimes referred to herein as "multiple-PHY" transmission. To add to that confusion, it can also include different source addresses within successive packets, thereby preventing a hacker from identifying packets as originating from the same client device.

The invention also includes a unique development in the handling of telephone conference calls. In a typical conference call, packets are sent to all call participants. In accordance with the present invention, by preventing a client device or other node from sending packets to the muted participant or participants, a specific designated participant may be “muted”, i.e., excluded from the call. In an alternative embodiment, the data packet is transmitted in broadcast mode to all participants in the group call, but using different encryption methods. In the case of a typical conference call, data packets are sent cryptographically to all users, where all participants have copies of the decryption key. In private or silent mode, data packets broadcast to users use a different cipher, where only selected users share the decryption key.

The security mechanisms inherent in communications using the SDNP network and protocol also make it perfectly suited for secure file and data storage. Since normal communication over SDNP networks typically involves the anonymous fragmented data transfer of scrambled, encrypted data from one client device to another, in effect, stopping communication in the transfer and the original client File and data storage can be realized by storing them in one or more buffers indefinitely until the device wants to retrieve them. Such distributed file storage is sometimes referred to herein as distributed data storage.

In the drawings listed below, generally like elements are given the same reference numerals. However, it should be recognized that all components to which a given reference number is assigned are not necessarily identical to other components having the same reference number. For example, an encryption operation with a designated reference number is not necessarily the same as another encryption operation with the same reference number. Also, groups of components, eg, servers in a network that are collectively identified by a single reference number, are not necessarily necessarily identical.

1 is a schematic diagram illustrating typical packet transmission across a network.
2A is a schematic diagram illustrating a packet scrambling process.
Fig. 2b is a schematic diagram illustrating a packet unscrambling process.
Fig. 2c is a schematic diagram illustrating various packet scrambling algorithms.
Fig. 2d is a schematic diagram showing fixed parameter packet scrambling.
Fig. 2e is a schematic diagram showing dynamic scrambling with hidden digits.
3 is a schematic diagram illustrating a packet re-scrambling process;
Fig. 4a is a schematic diagram illustrating a packet encryption process.
Fig. 4b is a schematic diagram illustrating a packet decryption process.
Figure 5 is a schematic diagram illustrating the process of encrypted scrambling and its inverse function.
Fig. 6 is a schematic diagram showing the process of DUSE re-packeting including re-scrambling and re-encryption;
Fig. 7a is a schematic diagram showing the process of fixed-length packet splitting.
Fig. 7b is a schematic diagram showing the process of fixed-length packet mixing.
8 is a schematic diagram illustrating various packet-mixing methods.
9A is a table summarizing SDNP security functions and adverse functions.
9B is a block diagram illustrating SDNP security operations implemented on incoming and outgoing data packets for single route last mile communication.
9C is a block diagram illustrating SDNP security operations implemented on incoming and outgoing data packets for multi-route last mile communication.
9D is a block diagram illustrating audio, video, text, and file content creation, data packet preparation, data packet recognition, and content reproduction in an SDNP client device.
9E is a graphical diagram of an SDNP data packet using a 7-layer OSI model to describe hierarchical data encapsulation.
9F is a graph and bar plot of SDNP payload.
9G is a block diagram illustrating inbound last mile data packet processing at an SDNP gateway using tri-channel communication.
9H is a block diagram illustrating inbound last mile data packet processing at an SDNP gateway using single-channel communication.
9I is a block diagram illustrating outbound last mile data packet processing at an SDNP gateway using tri-channel communication.
10 is a schematic diagram of SDNP cloud.
11 schematically illustrates an example of unsecured last mile communication without identification.
Figure 12 illustrates unsecured last mile communication over a common old telephone system (POTS) without caller identification.
13 schematically illustrates an example of unsecured last mile communication with identity verification.
14 illustrates unsecured last mile communication over a similar public service telephone network (PSTN) with operator-based identification.
15 illustrates unsecured last mile communication over a wired digital network with login- or token-based identification.
16 illustrates unsecured last mile communication over a wired analog network with PEST- or credit card-based identification.
17 schematically illustrates an example of hypersecure last mile communication that may support identity verification.
18 illustrates identity-verifiable hypersecure last mile communication over a WiFi wireless network.
19 illustrates identity-verifiable hypersecure last mile communication over a cellular wireless network.
20 illustrates identity-verifiable hypersecure last mile communication over an Ethernet wired network.
21 illustrates identity-verifiable hypersecure last mile communication over a cable wired network.
22 illustrates identity-verifiable hypersecure last mile communication over a combined cable wired and home WiFi wireless network.
23 schematically illustrates an example of a last mile communication involving an identity-verifiable hypersecure communication leg coupled to an identity-pairing secure LAN last link.
24 illustrates last mile communication involving an identity-verifiable hypersecure wired communication leg connected by wire to an identity-paired secure device and to an unidentified unsecured device.
25 illustrates last mile communication involving an identity-verifiable hypersecure wired communication leg connected by a WiFi LAN to an identity-pairing WPA-secured computing and communication device for home and business use.
26 illustrates last mile communication involving an identity-verifiable hypersecure wired communication leg connected by a WiFi LAN to an identity-pairing WPA-secured home IoT device.
27 illustrates last mile communication involving an identity-verifiable hypersecure wired communication leg connected by Ethernet or by WiFi LAN to a business identity-pairing WPA-secured device.
28 schematically illustrates an example of last mile communication involving an identity-verifiable hypersecure communication leg connected to an identity-pairing secure wired or secure wireless LAN last link.
Fig. 29a schematically illustrates wired and wireless hypersecurity bridges including Ethernet and WiFi applicable in last mile communication.
Fig. 29b schematically illustrates wired and wireless hypersecurity bridges using applicable satellite and automotive networks in last mile communication.
29C schematically illustrates wired and wireless hypersecurity bridges using cable and cellular networks applicable in last mile communication.
30 includes identity-enabled hypersecure wireless communications via satellite uplinks and downlinks to a variety of devices, including sat phones, aircraft, trains, ships, and home satellite receivers (set-top boxes). shows last mile communication.
31A is an example of last link hypersecure communication between devices in an onboard aircraft communications network with satellite connectivity.
31B is an example of an aircraft satellite communication and antenna module.
32 is an example of last link hypersecure communication between devices in an onboard ocean cruise ship communication network with multi-channel satellite connectivity.
33 is an example of last mile hypersecure communication between devices in an onboard train communications network with radio and satellite connectivity.
Figure 34 shows hypersecure last mile communication to automotive telematics module with cellular last link connectivity.
35 is an example of last link communication between a telematic module and an in-cabin WiFi connected device in a vehicle communication network with cellular connectivity.
36 is an example of hypersecure intervehicle communication with cellular connectivity.
37 illustrates hypersecure trunk line communications across microwave, satellite, and fiber networks.
38 illustrates a comparison of security, identity verification, and caller anonymity features for hypersecure, secure, and unsecured communication networks.
Figure 39 is a schematic diagram of a single-route last mile hypersecure communication with a fixed IP address.
Figure 40a is a schematic IP stack diagram of a single-route last mile hypersecure communication using a fixed IP address.
40B is a simplified diagram of single-route last mile hypersecure communication using a fixed IP address.
Figure 41 is a schematic diagram of single-route last mile hypersecure communication with dynamic client IP address.
42A is an IP stack diagram of single-route last mile hypersecure communication using dynamic client IP addresses.
42B is an alternative IP stack diagram of single-route last mile hypersecure communication using dynamic client IP addresses.
Figure 43 is a schematic diagram of multi-route last mile hypersecure communication with a fixed IP address.
Figure 44a is an IP stack diagram of a multi-route last mile hypersecure communication with a fixed IP address using a single PHY last link.
Figure 44b is an IP stack diagram of multi-route last mile hypersecure communication with static IP addresses using multiple PHY last links.
Figure 45 is a schematic diagram of multi-route last mile hypersecure communication with dynamic client IP address.
Figure 46a is an IP stack diagram of a multi-route last mile hypersecure communication with dynamic client IP address using a single PHY last link.
Figure 46B is an IP stack diagram of multi-route last mile hypersecure communication with dynamic client IP addresses using multiple PHY last links.
47 is a schematic diagram of an alternative version of multi-route last mile hypersecure communication with dynamic client IP addresses.
48 is an IP stack diagram of an alternative version of multi-route last mile hypersecure communication with dynamic client IP addresses.
Figure 49 is a graphical diagram of IPv4 and IPv6 datagrams for Ethernet communications executing SDNP payloads.
50A is a graphical diagram of IPv4 and IPv6 Last Link Ethernet packets used in a client for SDNP-to-Cloud communication.
50B is a graphical diagram of IPv4 and IPv6 gateway link Ethernet packets used in clients for SDNP-to-cloud communication.
50C is a graphical diagram of IPv4 and IPv6 Gateway Link Ethernet Packets used in SDNP-Cloud for client communication.
Fig. 50D is a graph diagram of IPv4 and IPv6 Last Link Ethernet Packets used in SDNP-Cloud for client communication.
51A shows a contiguous Ethernet data packet (abbreviated) used in single path last mile communication with fixed client addressing.
51B shows a continuous Ethernet data packet (abbreviated) used in single path last mile communication with dynamic client addressing.
51C shows a contiguous Ethernet data packet (abbreviated) used in multi-path last mile communication with fixed client addressing.
51D shows a continuous Ethernet data packet (abbreviated) used in multi-path last mile communication with dynamic client addressing.
52A is a table summarizing SDNP last mile routing over Ethernet.
52B is a topological description of single path last mile communication over Ethernet.
52C is a topological description of multi-path last mile communication over Ethernet.
52D is an additional topological description of multi-path last mile communication over Ethernet.
53 is a graphical diagram of IPv4 and IPv6 datagrams for WiFi communication carrying SDNP payloads.
Fig. 54A is a graph diagram of IPv4 and IPv6 Last Link WiFi packets used in a client for SDNP-to-Cloud communication.
Fig. 54B is a graphical diagram of IPv4 and IPv6 gateway link WiFi packets used in a client for SDNP-to-cloud communication.
Fig. 54C is a graphical diagram of IPv4 and IPv6 gateway link WiFi packets used in SDNP-Cloud for client communication.
Fig. 54D is a graph diagram of IPv4 and IPv6 Last Link WiFi packets used in SDNP-Cloud for client communication.
55 is a graphical diagram of IPv4 and IPv6 datagrams for 4G cellular communications carrying SDNP payloads.
56A is a graphical diagram of IPv4 and IPv6 Last Link 4G Cellular Data Packets used in a client for SDNP-to-Cloud communication.
Figure 56B is a graphical diagram of IPv4 and IPv6 Last Link 4G Cellular Packets used in SDNP-Cloud for client communication.
57A is a graphical diagram of single-media multi-PHY last link communication.
57B is a graphical diagram of mixed-media multi-PHY last link communication.
57C is a graphical diagram of an alternative implementation of multi-PHY last link communication.
Figure 58 is a graphical diagram of a serial client to SDNP to cloud last link communication using IPv6 datagrams carried over multi-PHY Ethernet.
Figure 59 is a graphical diagram of a serial client to SDNP to cloud last link communication using IPv6 datagrams carried over multi-PHY WiFi.
Figure 60 is a graphical diagram of a serial client to SDNP to cloud last link communication using IPv6 datagrams carried over a multi-PHY 4G cellular network.
Figure 61 is a graphical diagram of a serial client to SDNP to cloud last link communication using IPv6 datagrams using multi-PHY delivery over Ethernet and WiFi. 62 is a graphical diagram of a serial client to SDNP to cloud last link communication using IPv6 datagrams using multi-PHY delivery over WiFi and 4G cellular networks. Figure 63 is a schematic diagram of the OSI layer stack configuration of a DOCSIS cable modem communications network showing layer 1 through layer 7 functionality.
64 is a graphical diagram of a DOCSIS3 based communication packet for a cable system carrying an SDNP payload.
65A is a graphical diagram of spectrum allocation and carrier modulation methods for various DOCSIS3 protocols.
65B is a graphical diagram of a DOCSIS3.1 communication sequence between CTMS and CM.
65C is a graphical diagram of DOCSIS3.1 upstream communication. 65D is a graphical diagram of DOCSIS3.1 downstream communication.
Figure 66 is a schematic diagram of a three-path SDNP network for last mile communication.
Figure 67 is a schematic diagram of a "call request" operation in tri-channel SDNP last mile communication.
Fig. 68 is a schematic diagram of "request address" operation in tri-channel SDNP last mile communication.
Fig. 69 is a schematic diagram of "address transfer" operation in tri-channel SDNP last mile communication.
70 is a flow diagram illustrating SDNP command and control packet synthesis.
Figure 71 is a schematic diagram of a "routing indication" operation in single-path triple-channel SDNP last mile communication.
Figure 72 is a schematic diagram of "SDNP call" operation in single-path triple-channel SDNP last mile communication from SDNP client to SDNP cloud.
Fig. 73A is a schematic diagram of SDNP cloud and last mile triple-path communication to a SDNP client in a SDNP call. Fig. 73B is a schematic diagram of SDNP cloud and last mile three-path communication implemented as a "call out" to non-SDNP clients.
Figure 74 is a schematic diagram of a "routing indication" operation in multi-path tri-channel SDNP last mile communication.
Fig. 75A is a schematic diagram of "SDNP call" operation in multi-path triple-channel SDNP last mile communication in direction from SDNP client to SDNP cloud.
Fig. 75B is a schematic diagram of "SDNP call" operation in multi-path triple-channel SDNP last mile communication in direction from SDNP cloud to SDNP client.
Figure 76 is a schematic diagram of group-call "routing indication" operation in single-path triple-channel SDNP last mile communication.
Fig. 77A is a schematic diagram of a "SDNP Group Call" using SDNP multi-path cloud transport and SDNP last mile communication in the direction from zone U1 clients to clients in other zones.
Fig. 77B is a schematic diagram of a "SDNP Group Call" using SDNP multi-path cloud transport and SDNP last mile communication in the direction from zone U7 clients to clients in other zones.
Fig. 77C is a schematic diagram of a "SDNP Group Call" using SDNP multi-path cloud transport and SDNP last mile communication in direction from zone U9 client to other clients on the same zone and in other zones.
Figure 78 is a schematic diagram of "SDNP Group Call" using SDNP multi-path cloud transport and last mile communication for both SDNP clients and unsecured PSTN devices.
Figure 79A is a bar diagram of normal and private call operation in SDNP group calls.
Figure 79B is a bar diagram of normal calling and hyper-private calling operation in SDNP group calling.
Figure 80A is a bar diagram of regular and private push-to-talk operation in SDNP PTT group calls.
80B is a bar diagram of regular and hyper-private push-to-talk operation in SDNP PTT group calls.
Fig. 81 is a schematic diagram of data transfer for a write-operation in hypersecure file storage of fragmented data.
Fig. 82A is a schematic diagram of the data flow for a write-operation in hypersecure file storage of fragmented data.
Fig. 82B is a schematic diagram of the data flow for a read-operation in hypersecure file storage of fragmented data.
Fig. 83 is a schematic diagram of data transfer for a read-operation in hypersecure file storage of fragmented data.
84A shows various examples of SDNP clouds connected to file storage solutions.
Fig. 84B is a schematic diagram of a distributed hypersecure file storage network including local and cloud connected storage servers.
85A is a file mapping for non-redundant (RRF = 0) hypersecure file storage.
Figure 85B is a file mapping for RRF = 1 read redundant hypersecure file storage.
85C is a file mapping for RRF = 2 read redundant hypersecure file storage.
86 is a network map for a distributed hypersecure file storage system using tri-channel network communication.
87A illustrates a file write request operation in a distributed hypersecure file storage system.
87B illustrates file server name request operation in a distributed hypersecure file storage system.
87C illustrates signaling server planning operations within a distributed hypersecure file storage system.
Fig. 87d shows signaling server client-side last mile and SDNP cloud record routing instructions in a distributed hypersecure file storage system.
Fig. 87e shows signaling server store-side last mile and SDNP cloud record routing instructions in a distributed hypersecure file storage system.
88 illustrates file delivery within a distributed hypersecure file storage system.
89A illustrates a link response verification file storage and recording operation in a distributed hypersecure file storage system.
Fig. 89B illustrates file storage server link delivery within a distributed hypersecure file storage system. 89C shows a file storage server record confirmation data packet including FS link.
Fig. 89D shows the composition of the file store read link in the client's SDNP messenger.
90A is a file map for non-redundant RRF = 0 hypersecure file storage with LRF = 0 non-redundant FS links.
90B is a file map for non-redundant RRF = 0 hypersecure file storage with LRF = 1 redundant FS links.
90C is a file map for non-redundant RRF = 1 hypersecure file storage with LRF = 1 redundant FS links.
91 is a graph showing storage elasticity according to the number of file storage servers and client FS links.
Figure 92 is a schematic diagram of SDNP-encoding and SDNP-decoding functions.
Fig. 93A is a schematic diagram of SDNP distributed file storage with client-side file security and hypersecure file transfer.
Fig. 93B is a schematic diagram of SDNP Distributed File Storage with Nested File Security and Hypersecure File Transfer.
Figure 94 is a simplified schematic diagram of hypersecure encoding in SDNP Distributed File Store Write operation.
Figure 95 is a simplified schematic diagram of hypersecure decoding in SDNP Distributed File Store Read Operations.
96A is a flow diagram illustrating AAA operation in a hypersecure file reading operation.
Fig. 96B is a flow diagram illustrating file access and SDNP transfer in a hypersecure file read operation.
97A illustrates a file read request operation within a distributed hypersecure file storage system.
97B illustrates file storage server name request operation in a distributed hypersecure file storage system.
97C illustrates file storage server name forwarding and signaling server planning operations in a distributed hypersecure file storage system.
Fig. 97d shows the signaling server storage side last mile and SDNP cloud routing read instructions in a distributed hypersecure file storage system.
Fig. 97E shows signaling server client-side last mile and SDNP cloud reading routing instructions in a distributed hypersecure file storage system.
98 illustrates storage-side file decoding during a read operation within a distributed hypersecure file storage system.
99 illustrates file data transfer within a distributed hypersecure file storage system during a read operation.
100 illustrates file data transfer within a distributed hypersecure file storage system during link refresh.
101 illustrates file data transfer within a distributed hypersecure file storage system used to redistribute files.
102 shows time stamps in SDNP text messaging.
Fig. 103 is a flow diagram of SDNP registered communication.
104A illustrates end-to-end encryption in Internet OTT communications.
104B illustrates end-to-end encryption in hypersecure communication.
Fig. 105A is a schematic diagram of "SDNP call" operation, where the SDNP security agent performs invisible monitoring of outgoing calls.
Fig. 105B is a schematic diagram of "SDNP call" operation, where the SDNP security agent performs invisible monitoring of an incoming call.
Figure 106 shows file storage server link forwarding in a distributed hypersecure file storage system, where SDNP security agents perform invisible monitoring of FS link routing.
Fig. 107 is a schematic diagram of "SDNP Call" operation in which the SDNP security agent performs invisible monitoring of outgoing calls using multi-path last mile communication.
108 is a flow diagram of steps for specifying and authenticating SDNP security agents.
Figure 109 shows a cell phone to tower communication exposed to an SS7 vulnerability.
110 illustrates SDNP communication using phone number concealment to repel SS7 attacks.
111 illustrates the connectivity of SDNP Softswitch-based clouds hosted on separate servers.
112 illustrates the connectivity of an SDNP softswitch-based cloud hosted on shared servers.
113 illustrates the connectivity of an SDNP softswitch-based cloud hosted on overlapping networks. Figure 114 shows the connectivity of SDNP softswitch-based cloud accessing global SDNP cloud telcos.
115 is an example of a nested SDNP subnet.

After nearly 1.5 centuries of circuit-switched telephony, today's telecommunications systems and networks have been packet-switched using Internet protocols such as Ethernet, WiFi, 4G/LTE, and DOCSIS3 data carried over cable and optical fiber in just 10 years. All moved to communication. The use of redundant paths to ensure reliable IP packet delivery - voice, text, picture, video, including the reason the Internet was created, with an unparalleled level of system interoperability and worldwide connectivity. and the benefits of providing data are many. But for any innovation, the strength of the challenges it creates often coincides with the advantages it induces.

Disadvantages of existing telecom operators

As detailed throughout the Background of the Invention, communications today have many disadvantages. Today, the highest-performing telecom systems, including custom digital hardware owned by the world's major long-distance carriers such as AT&T, Verizon, NTT, Vodafone, and others, typically deliver superior sound quality. However, it includes expensive monthly fees, connection fees, long-distance fees, complex data plans, long-distance roaming fees, and various service fees. Because these networks are private, actual data security is not publicly known, and security breaches, hacks and intrusions are generally not disclosed. Given the number of landlines and privacy breaches in the press today, private carrier communications security is still questionable, at least in the last mile connection, if not in the private cloud.

"Internet Service Providers" or ISPs form another link in the global communication chain. As described in the Background of the Invention, voice carried over the Internet using VoIP or "Voice over Internet Protocol" suffers from a number of quality of service or QoS issues, including:

* As a packet-switched network, the Internet was not designed to deliver IP packets in a timely manner or to support real-time applications with low latency and high QoS.

* Routing of IP packets takes an unpredictable path, resulting in ever-changing delays, bursts of high data error rates, and unexpected dropped calls.

* IP packet routing is at the discretion of the Internet Service Provider, which controls the network to which packets are routed and either load balances its own network or suffers a degradation of the link quality of normal traffic passing through that network to its VIP. Routing can be tweaked to better serve clients.

* Over-the-top or OTT providers such as Line, KakaoTalk, and Viber that free ride on the Internet act as Internet hitchhikers, and also have no control over networks or factors that affect QoS.

* Use of heavy audio codecs that do not provide audio of reasonable voice quality even at moderate data rates

* VoIP based on the TCP transport protocol suffers from high latency and degraded audio quality caused by delays induced during handshaking and rebroadcasting of IP packets. Unassisted UDP transport does not provide payload integrity.

Aside from QoS issues, the security of today's devices and networks is abysmal, making them completely unacceptable to support the future demands of global communications. As detailed in the Background section, entitled Secure Dynamic Communications Networks and Protocols, network security includes spyware, trojans, infections, and phishing; In Last Link, including spyware, IP packet sniffing, eavesdropping, and call interception of cyber pirate “fake” cell phone towers; And in the local network or telco portion of last mile connectivity, it is vulnerable to an array of massive cyberattacks on communication devices, including spyware, IP packet sniffing, infections such as viruses, and cyberpiracy "man in the middle attacks". The cloud itself may be subject to unauthorized access by security breaches at any cloud gateway, by infections such as viruses, from man-in-the-middle attacks, denial of service attacks, and unauthenticated government surveillance. In summary, today's communications security is compromised by a variety of vulnerabilities that are easily exploited by cyber pirates and useful for cybercrime and cyberprivacy breaches, including:

* Exposure of the IP packet's destination, including destination IP address, destination port # and destination MAC address

* Source exposure of IP packets, including source IP address, source port # and original MAC address.

* Layer 4 transport type and port used # Type of service requested and exposure of application data encapsulated in the payload of the IP packet.

* In unencrypted files, all application and file data encapsulated in the payload of IP packets, including personal and confidential information, login information, application passwords, financial records, videos and photos.

* A dialog in the communication that allows cyber parties to have repeated opportunities to destroy encrypted files.

* Many opportunities to install malware, including spyware and phishing programs and trojans, within communication devices and routers using FTP, email and web page-based infections.

A fundamentally inherent weakness of packet-switched communication networks using the Internet Protocol, repetition of the key point is that any adversary party or cyber pirate can intercept IP packets and determine which devices are involved in generating the data contained in the IP packets. , where the IP packet is coming from, where the IP packet is being sent, how the data is being sent, i.e. UDP or TCP, and what kind of service is being requested, i.e. what kind of application data is in the payload. is included, etc. In this regard, cyber pirates can determine the "context" of a conversation, improving their chances of cracking passwords, breaking password security, and gaining unauthorized access to files, data, and payload content.

Encryption - To defend against various cyberattacks as described, today's network administrators, IT professionals and applications primarily rely on a single defense - encryption. Encryption is the process of transforming recognizable content, also known as “plaintext”, into meaningless strings of text characters, whether it be readable text, executable programs, viewable videos and pictures, or intelligible audio. A means of converting to an alternative file type known as "ciphertext".

The encryption process of converting an unprotected file into an encrypted file uses a logical or mathematical algorithm, referred to as a cypher, to change data into equivalent textual elements without revealing any apparent pattern of the encryption conversion process. Include steps. The encrypted file is then transmitted over a communication network or medium until received by the destination device. Upon receiving the file, the receiving device using a process called "decryption" then decrypts the encoded message back to its original content. The study of encryption and decryption, popularly known as “cryptography,” blends elements of mathematics, including number theory, set theory, and algorithm design, along with computer science and electrical engineering.

In simple "single key" or "symmetric key" encryption techniques, a single keyword or phrase known a priori by both parties can unlock the file encryption and decryption process. In World War II, for example, submarines and sea vessels communicated over open radio channels using encrypted messages. Initially, encryption was based on a single key. By analyzing cipher patterns, Allied cryptologists were sometimes able to find cryptic key words or patterns, and then read encrypted files without discovery. As encryption methods become more complex, manually breaking the code becomes more difficult.

Code evolved into machine-based cryptography, an early form of computing. At the time, the only way to break the code was to steal the encryption machine and decrypt the message using the same tool that encrypts the file. The problem was how to steal a crypto machine without the stealing being detected. If the code machine is known to be compromised, the adversary simply needs to change the code and update the already working crypto machine. This principle is still practiced today, and the most effective cyber attacks are those that go undetected.

With the advent of computing and the Cold War, cryptography became more complex, but the speed of computers used to crack cryptographic codes also increased. At each stage of the development of secure communications, the technology and know-how to encrypt information and the ability to crack encryption codes has hardly advanced at that rate. The next major evolutionary step in cryptography came with the innovation of double-key cryptography in the 1970s that is still in use today. One of the best-known two-key cryptography methods is the RSA public-key cryptosystem, named after its developers Rivest, Shamir, and Adleman. Despite being aware of the published RSA, contemporaneous developers devised the same principles independently. RSA uses two cryptographic keys based on two large prime numbers kept secret from the public. One algorithm is used to convert these two prime numbers into a cryptographic key, referred to herein as an E-key, and a different mathematical algorithm is used to convert the same two secret prime numbers into a secret cryptographic key, also referred to herein as a D-key. An RSA user who selects a prime number of a secret, referred to herein as a "key revealer," distributes or "reveals" an algorithmically generated E-key, typically containing sizes between 1024b and 4096b, to anyone wishing to encrypt files. do. Because this key can be distributed to many parties in unencrypted form, the -E key is known as a "public key".

A party wishing to communicate with a key publisher uses this public electronic key in conjunction with a publicly available algorithm, typically provided in the form of commercial software, to encrypt any file to be sent to a particular key publisher. Upon receipt of the encrypted file, the key publisher then uses that secret D-key to decrypt the file, returning it to plaintext. A unique feature of the two-key method in general and the RSA algorithm in particular is that the public E-key used to encrypt the file cannot be used for decryption. Only the secret D-Key possessed by the publisher of the key has the ability to decrypt the file.

The concept of double key, split key or multi-key exchange in file encryption and decryption is not specifically limited to RSA or any one algorithmic method, but methodologically specifies the communication method as a sequence of steps. In a dual-key exchange over a switched packet communication network, a laptop wishing to receive a secure file from a device, e.g., a mobile phone, first uses a predetermined algorithm to obtain two keys, namely the E-key for encryption and the E-key for decryption. Generates a D-key. The notebook then sends the E-key to the mobile phone using public network communications accompanied by IP packets. An IP packet in unencrypted form is, as its payload, an encrypted copy of the transport protocol (TCP) and E-Key, as well as the destination IP address "CP" of the mobile phone and the corresponding port, together with the laptop's MAC address, IP source address "NB" and port address.

Then, using the agreed-upon encryption algorithm or software package, the cell phone uses the encryption algorithm and the encryption E-key to generate the encrypted file, or cipher text, carried as the payload of IP packets in secure communication from the cell phone to the laptop. to process plain text files. Upon receipt of the IP packet, the algorithm uses the secret decryption key, the D key, to decrypt the file. Since the D-key is made to match its corresponding E-key, in essence the algorithm uses knowledge of both keys to decrypt the ciphertext and return it back to plaintext in the clear. Although the payload of the IP packet is secured in the form of an encrypted file, i.e. cipher text, the rest of the IP packet is unencrypted, and also contains the source IP address "CP" and port and the destination IP address "NB" and the associated port. It can be sniffed and read by any cyber pirate. So even if the payload itself cannot be opened, the communication can be monitored.

Virtual Private Network - Another security method that relies on encryption is that of a "virtual private network" or VPN. In VPN, a tunnel or secure pipe is formed in a network using encrypted IP packets. Rather than encrypting only the payload, the entire IP packet is encrypted in the VPN and then encapsulated into another unencrypted IP packet that acts as a mule or carrier that transports the encapsulated packet from one VPN gateway to another. do. Originally, a VPN is a way to connect disparate local area networks together over long distances, using the same function to connect different, for example, private networks in New York, Los Angeles and Tokyo, sharing one global private network. Used when you want to interconnect LANs.

The basic VPN concept is that a first server as part of one LAN supporting a large number of devices, e.g. wirelessly via rf and via wired connections, creates a "virtual network" containing encrypted content across the VPN tunnel. It can be thought of as an encrypted communication between two devices, connected by a private network" or VPN, to a desktop, laptop, and a second server that has a wired connection to another WiFi-based station.

In addition to this relatively narrow bandwidth link, the first server may also be connected to the supercomputer through a wide bandwidth connection. The resulting data communication includes a sequence of data packets including inner VPN packets embedded within outer IP packets. In operation, an outer IP packet from server A, specifying the source IP address and source port #, is sent to server B at the destination IP address and destination port #. These outer IP packets establish communication between the first and second servers to form encrypted tunnels to each other for data transfer. The VPN payload accompanied by the outer packet includes the last mile IP packet, including the end device, e.g., a desktop with source IP address "DT" and its corresponding ad hoc port #, and another end device, e.g. source IP Provides direct communication between notebooks with address "NB" and its corresponding ad hoc port #. Although any communication session may be initiated, in one example the request for file transfer is carried out over a VPN tunnel.

To set up such a transfer securely using a virtual private network, a VPN tunnel is created and a session is started before actual communication begins. In enterprise applications, VPN tunnels are not carried over the Internet, but instead are often carried by dedicated ISPs or carriers that own their own fiber and hardware networks. These carriers often sign annual or long-term contractual agreements with companies requesting VPN service, guaranteeing a specified bandwidth for a given cost. Ideally, high-speed dedicated links are direct, with no intermediate or "last mile" connections interfering with the VPN's performance, QoS, or security.

In operation, a typical VPN requires a two-step process - a second step to create or “log in” to the VPN, and pass data within the secure pipe or tunnel. The concept of tunneling includes layers 1 to 4, layer 5 is used to create a virtual VP session 723, and layer 6, a presentation layer, is used to form a VPN gateway-to-gateway pipe between servers. It can be thought of as hierarchical as the outer IP packets executed by the 7-layer communication stack (used to accompany VPN connections), which are used to facilitate the necessary encryption. Although VPN connections use the Internet Protocol to transmit IP packets, the VPN's PHY Layer 1 and VPN Data Link Layer 2 are often supported by dedicated carriers to minimize unpredictable routing across the Internet. Application layer 7 data, carried as e.g. device-to-device communication between communicating desktops, is tunneled data that includes all 7 OSI layers needed to establish communication as in the case where a VPN does not exist. is transmitted as In this way, a VPN can be thought of as a communication protocol operating within Layer-7 used to transport packets inside the VPN.

In operation, an outer IP packet, once passed from one communication stack to another, is opened to expose the actual message of the packet, the encapsulated data. In this way, end-to-end communication ignores the details used to create the VPN tunnel, except that the VPN tunnel must be established before any attempt to communicate and must be closed after the conversation has ended. and it is done Failure to open the VPN tunnel first will result in unencrypted transmission of IP packets, which are vulnerable to IP packet sniffing, hijacking, infection, etc. Failure to close the VPN after the conversation is complete may provide cybercriminals with an opportunity to hide their illicit activity in someone else's VPN tunnel, resulting in possible criminal penalties imposed against the innocent person whose interception occurs. .

While VPNs are a common way for multiple private local area networks to interconnect with each other using private connections with dedicated capacity and bandwidth, the use of VPNs over public networks and the Internet presents challenges in two-party communication. One problem with VPN is that the VPN connection must be pre-established, prior to use, rather than on a packet-by-packet basis. For example, in a VoIP call connected across a packet-switched network, a VPN session must first be established before the cell phone can contact the intended callee of the second cell phone. To do this, the VPN connection application must first be loaded on the caller's mobile phone. The caller must then send an IP packet to the VPN host, typically to the service provider. These packets pass through any available last mile routing, e.g., from the cell phone to a nearby WiFi-based base station via wireless communication, then to the local router via wired communication, and then to the VPN host via wired communication. Once the session between the caller's mobile phone and the VPN host is established, the caller's mobile phone must then instruct the VPN host to create a VPN tunnel from the caller's mobile phone to the VPN host. When layer 5 sessions within the tunnel are encrypted by layer 6, this leg of the VPN tunnel is facilitated.

Once the VPN connection is established, the caller's mobile phone can place the call to any other phone via any VoIP phone app. In the case where the called phone is not connected to the same VPN, the application must establish a "call out" link that spans the last mile from the VPN host closest to the destination calling phone, i.e., the person being called. If the VoIP application cannot be used or is not authorized for use, the call will fail and be terminated immediately. Otherwise, the inner IP packet will establish an application layer 5 session between the calling cell phone and the destination cell phone, verifying that the IP test packet can be properly decrypted and understood.

In order to place a call, the call must come from the caller's phone, a layer 7 application running on the phone app that uses the carrier's data plan, and not from the phone's normal dial function, which means that the phone carrier's SIM card in the phone This is because it is incompatible with VPN tunnels. When a call is initiated, the caller's mobile phone sends a series of IP packets representing small snippets or "snippets" of sound, depending on the communication application. These packets are sent from an application in the caller's cell phone through the network, e.g. over a WiFi link to a nearby WiFi-based base station, then over a wired connection to the router, and finally over a wired connection to the VPN host. . The data is then securely transmitted to the VPN host via the VPN tunnel to the VPN network's end device, which is the destination VPN gateway. In this example, the VPN tunnel does not extend to the destination cell phone at all, but instead breaks before reaching the device being called. Beyond the VPN's destination gateway, data is no longer encrypted, since the VPN carrier is no longer involved. On data packets leaving the VPN tunnel, the VPN host continues to forward the data to a nearby router via the destination device's last mile connection, e.g., a wired connection, and then by wired connections to the local cell phone system and towers, 2G, The call is transmitted as a normal cellular phone call using 3G or 4G telephony. The process of making a call from a mobile phone app to a phone that is not running the same app is referred to as a "call out" feature.

The foregoing example highlights another problem with connections to VPNs over public networks - the last mile link from the VPN host to the person being called is not part of the VPN and, as such, does not guarantee security, performance or call QoS. . Specifically, the caller's last mile containing connections are all open to sniffing and open to cyber-attacks. When the call is complete and the caller's mobile phone hangs up, the VPN link must be terminated, whereby VPN Layer 5 coordinates the closure of the VPN session and the caller's mobile phone is disconnected from the VPN host.

Adaptation of virtual private networks, originally created for computer-to-computer data transfer, presents several major challenges.

* Last mile communication from the destination VPN gateway to the destination cell phone is not secure and is subject to sniffing and monitoring risks.

* Last mile communication between the caller's mobile phone and the VPN gateway is secure only when the caller uses a data communication-based app. In the case where the caller connects to the VPN gateway using a telephony link, i.e. the dial feature, the last mile communication from the caller's mobile phone to the nearest VPN gateway is not secure and is subject to sniffing and surveillance risks.

* A call is secure end-to-end only if both parties are using data communication and not using telephony over their associated last-mile link, and if both parties know they are joining the same VPN prior to initiating the call. can be the end A final important point highlights the paradox of secure VPN communication - the person being called needs to know that they are being called before they are called, in order to join the network. To let them know that they are being called, before the call starts, they must first connect and be instructed to log in to the VPN. Essentially, in order to connect to a secure phone call, they must receive an unsecured phone call. Unsecured phone calls are easily hacked, sniffed, and monitored. In addition, the metadata of an unsecured call exposes who is calling, who is calling, and when the call is taking place. Call metadata is very useful in tracking a person's activities or profiling them as a target for a crime.

Ignoring security concerns, there is no guarantee that placing a call or sending documents through a VPN will not fail for any of the other reasons including:

* VPNs may not operate with low enough latency to support real-time applications, VoIP or video.

* A VPN last mile connection from the caller to the VPN gateway or from the VPN gateway to the call receiver may not operate with low enough latency to support real-time applications, VoIP or video.

* The VPN gateway closest to the caller or intended receiver, or "last mile", can be very far away, possibly much greater than the distance to the call receiver without a VPN, making the connection suffer from excessive latency, network instability, Uncontrolled routing through unknown networks, multiple QOS, and exposure to numerous opportunities for man-in-the-middle attacks on unprotected parts of the connection.

* A VPN last mile connection from the VPN gateway to the call receiver may not support "call out" connections and packet forwarding or supporting links to local telcos.

* Local carriers or government inspectors may block calls or connections to or from known VPN gateways for national security or regulatory compliance reasons.

* When using a corporate VPN, VoIP calls may be restricted to and from only corporate employees and designated authorized users, financial transactions and video streaming may be blocked, and private emails to public email servers such as Yahoo, Google, etc. It can be blocked, and many websites like YouTube, chat programs or Twitter can be blocked according to company policy.

* In the case of an unstable network, the VPN can keep a persistent session open and connected to the caller's device until manually reset by the VPN operator. This may result in a loss of bandwidth for subsequent connections or expensive connection costs.

Network Comparison - Comparing communication systems provided by "over the top" or OTT providers and communication systems that use public networks to connect to ad hoc VPNs, other than the VPN link itself, most of the two communication systems have nearly identical components and connections. It can be easily seen that it has Specifically, the caller's last mile including cell phone WiFi wireless connection, WiFi base station, wired connection and router represent the same last mile connectivity in both implementations. Similarly, on the other party's last mile, the caller's cell phone, cell phone connection, cell base station and tower, wired connection and router are the same for both Internet and VPN versions. The main difference is that the VPN tunnel with secure communication between VPN hosts in the public network is replaced by a server/router with unsecured communication throughout the cloud. Another difference is in OTT communication, calls are available instantly, when using a VPN, extra steps are required to set up the VPN and terminate the VPN session before and after the call.

In both examples, last mile connectivity provides unpredictable call QOS, exposure to packet sniffing, and cyberattack risk. Since the servers/routers are managed by different ISPs in different locales, we can interpret the servers as different existing clouds. For example, a public open network owned by and operated by Google, Yahoo, Amazon, and Microsoft, although all linked to each other by the Internet, could be considered as different clouds, e.g., the "Amazon Cloud". can

A competitive or less popular topology, a peer-to-peer network or PPN, involves a network consisting of a large number of peers with packet routing managed by the PPN rather than by a router or ISP. Although peer-to-peer networks have existed in hardware for decades, it was Napster that popularized the concept as a means of avoiding the control, cost, and regulation of Internet service providers. When sued by US government regulators for music piracy, Napster's forerunners got out and broke into early OTT carrier Skype. At that time, Skype's network had transitioned from a traditional OTT to a Napster-like PPN.

In PPN operation, every device that forms a login connection to the PPN becomes one or more nodes in the PPN. For example, in one geographic location, when a mobile phone with PPN software installed logs into a peer-to-peer network, all other connected devices in that area become part of the network. When you make a call from one device to another, the other device connects to the other device connected to the PPN. For example, if a cell phone uses its PPN connection to make a call to another PPN connected device, e.g. a cell phone, that call follows a detour through any device(s) physically located in the PPN between the two parties. . For example, a call coming from the caller's cell phone would go by WiFi through the local WiFi cell tower to a nearby desktop, then to someone else's laptop, then to another desktop, then another desktop, and finally to the local cell phone tower and tower. connected to the destination mobile phone via In this way, all routing was controlled by the PPN, and the Internet was not included in the management of routing. As used by both parties, the PPN software used to connect to the network acts as an application for VoIP-based voice communication.

In case one cell phone wants to talk to a non-PPN device cell phone on the other side of the globe, the routing may necessarily include the Internet on some link, especially to send packets across an ocean or mountain range. The first part of the routing at the local geographic location proceeds in a manner similar to the previous example, starting with the caller's cell phone and routing through WiFi base stations, desktops, laptops, other desktops, etc. At this point, if the nearest laptop is connected to the network, the call will be routed through it, otherwise the call will be routed through the local cell tower and cell phone to the cell phone, after which, before continuing to transmit it, the call will be routed through it. return to

If a call crosses the Pacific Ocean, computers and cell phones cannot carry traffic across an ocean, so the call must be made to an internet third-party server/router in the hosted cloud and to a third-party server/router in another cloud. It is routed forward through the connection. For example, when it approaches its destination, the call leaves the Internet and first enters the PPN in the destination geographic location via the desktop, which in turn connects to WiFi, then to the laptop, and then to the base station. Because WiFi does not run PPN apps, the actual packets entering WiFi must travel to the tablet or phone within the WiFi subnet and return to WiFi before being sent over the wired connection onto cell towers and cell towers. Finally, the caller's cell phone call connects to the destination cell phone, not to the PPN-enabled device. Thereby, the connection constitutes a "call out" for the PPN, as it exits the PPN network. When using this PPN approach, as with VPN, placing a call involves first registering the calling device with the PPN network, by completing a PPN login. After that, the call can be placed using the PPN app. The advantage of the PPN approach is that it requires little or no hardware to carry calls over long distances, and also because every device connected to the PPN regularly updates the PPN operator regarding its status, loading, and latency, so the PPN operator can It is possible to determine the routing of packets to minimize delay.

A disadvantage of this approach is that packets traverse networks containing many unknown nodes, which represent a potential security threat and also have an unpredictable impact on call delay and call QoS. Thus, except for Skype, peer-to-peer networks operating at or above Layer 3 are not generally used in packet-switched communication networks.

A comparative summary of ad hoc VPN providers, internet OTT providers, and PPN peer networks is contrasted in the table below.

network virtual private vpn Internet OTT Peer-to-Peer PPN node Public/Hosted Server Public router/server PPN user node ability known infrastructure known infrastructure mixed, unknown cloud bandwidth guaranteed unpredictability unpredictability last mile bandwidth provider dependent provider dependent PPN dependent waiting time unmanageable unmanageable optimal action network stability unmanageable unmanageable, redundant optimal action call settings complicated login not required login user identity username phone number username VoIP QoS variable to good variable variable cloud security Encrypted payload only unencrypted unencrypted last mile security unencrypted unencrypted unencrypted sniffable Packet Header (Cloud)
Whole Packet (Last Mile) full packet full packet

As shown, VPNs and the Internet constitute a fixed infrastructure, but the nodes of a peer-to-peer network depend on who logs in and the devices connected to the PPN. Cloud bandwidth, defined in the context of this table as a high-speed long-distance connection of a network, eg, a network that crosses oceans and mountains, is contractually guaranteed only in the case of a VPN and otherwise unpredictable. Last mile bandwidth depends on both Internet and VPN providers, local providers, but PPNs are entirely dependent on who is logged in. Latency, the propagation delay of continuously transmitted IP packets, is unmanageable for OTT and VPN. This is a limited ability to use best efforts to direct traffic between nodes that are online at that time in a particular geographic location, while the provider does not control routing in the last mile, but instead relies on the local telco or network provider. because it has Similarly, for network stability, PPNs can reroute traffic to keep the network alive, but it is entirely dependent on who logs in. On the other hand, the Internet is inherently redundant and guarantees delivery are certain, but not necessarily timely. Network stability for an ad hoc VPN depends on the number of nodes authorized to connect to the VPN host. When these nodes go offline, the VPN is disabled.

From a call setup point of view, the internet is always available, PPNs require the extra step of logging into the PPN before making a call, and VPNs can involve complex login procedures. Furthermore, most users consider OTT use of a phone number as a major advantage in ease of use rather than separate login IDs used by VPNs and PPNs. All three networks listed suffer from flexible VoIP QoS, and generally lag far behind commercial telephony carriers.

From a security point of view, all three options are bad by the last mile completely exposed to sniffing packets with readable addresses and payloads. A VPN provides encryption of the cloud connection, but exposes the IP address of the VPN host. Therefore, the network option shown is not considered secure. Thus, encryption is used by various applications as an embedded part of layer 6 protocols or layer 7 applications themselves to prevent hacking and cyberattacks.

Overtrust in encryption - whether used to encrypt IP packets or to set up VPNs, today's network security relies almost entirely on encryption alone, which also represents a weakness in modern packet-switched based communication networks. . For example, a lot of research has been done on how to attack RSA encryption. Restricting prime numbers to large sizes greatly reduces the risk of breaking decryption D-key codes using brute force methods, whereas polynomial element methods have been successfully demonstrated in cracking keys based on smaller prime number-based keys. It became. There are concerns that the evolution of “quantum computing” will eventually lead to practical ways to break RSA-based and other cryptographic keys in reasonable cyberattack times.

To overcome the previously existing risk of code breaking, new algorithms and "larger key" encryption methods have emerged, such as the "Advanced Encryption Standard" adopted by US NIST in 2001 or the AES cipher. Based on the Rijndael cipher, a design principle known as a substitution-permutation network combines text substitutions and permutations using different keys and block sizes. In its current form, the algorithm includes a fixed block size of 128 bits with keys containing variable lengths of 128, 192 bits and 256 bits, and the corresponding iteration numbers used to transform the input file are 10, 12, and 256 bits. 14 cycles. As a practical matter, AES ciphers can be executed efficiently and quickly in software or hardware, regardless of key size. In cryptographic vernacular, AES-based encryption using 256b keys is referred to as AES256 encryption. AES512 encryption using 512b keys is also available.

While new generations improve cryptography to create better encryption methods and break them quickly, profit-seeking cybercriminals often focus on their targets rather than simply using computing power to destroy encrypted files. As already described, using packet sniffing and port interrogation, cyber pirates can get valuable information about conversations, corporate servers or even VPN gateways. By cyber profiling, it may be easier to launch a cyber attack on a company's CFO or CEO's personal computers, laptops and cell phones rather than attacking the network itself. Sending an email to an employee that automatically installs malware and spyware when the embedded link is opened completely bypasses firewall security, since they enter the network from "the inside", where they must connect and operate.

If data travels through the network without alteration, i.e. statically, the probability of breaking the encryption increases. For example, in the network of Figure 1, the underlying data of packets 790, 792, 794, and 799 do not change as the packets travel through the network. Each data packet shown contains a sequence of data or sounds arranged sequentially in unaltered time or pages in its original order when it was created. If the content of the data packet is text, then reading the unencrypted plaintext file in sequence 1A-1B-1C-1D-1E-1F will result in "readable" text for communique number "1". If the content of the data packet is audio, the conversion, or "playback", of the unencrypted plaintext file in the sequence 1A-1B-1C-1D-1E-1F is via the corresponding audio codec, which is essentially a software-based D/A converter. It will appear as a sound for the audio file number "1".

In any case, throughout the present invention, each data slot represented by a fixed size box contains a specified number of bits, for example two bytes (2B) in length. The exact number of bits per slot is flexible as long as all communicating nodes in the network know the size of each data slot. Each data slot contains audio, video or text data, and text is indicated after the number in the drawing. For example, as shown, the first slot of data packet 790 contains content 1A where the number "1" represents designated communication #1 and the text "A" represents the first portion of data for communication #1. includes Similarly, the second slot of data packet 790 contains the text "1B" where the number "1" indicates that it is part of the same Communication #1 and the text "B" is the data from Communication #1 following the sequence of 1A. and content 1B representing the second part of

For example, if the same data packet contains virtually embedded content "2A", the data represents the first packet "A" in a different communication, specifically for communication #2 unrelated to communication #1. A data packet comprising a homogeneous communication, e.g. all data for communication #1, is easier to parse and read than a mix of different communications. Sequentially arranged data in the proper order, whether it be audio, text, graphics, photos, video, executable code, etc., makes it easy for cyber attackers to interpret the nature of the data.

Moreover, in the illustrated example, since the source and destination IP addresses of the packets are kept constant, that is, the packets remain unchanged during transmission through the network in the same form as the incoming or outgoing gateway servers 21A, 21F. If it does, the hacker has a better chance of intercepting the data packets, and also has a better chance of analyzing and opening files or listening to conversations, because the underlying data is not changed. Relying solely on simple transport and one-dimensional security, i.e., encryption for protection, increases the risk of cyber-attacks because success is more likely in the oversimplified use of the Internet as a packet-switched network.

Real-time network and connected device security

To improve the quality of service (QoS) of telephony, video and data communications while addressing the plethora of security vulnerabilities plaguing today's packet-switched networks, a new, innovative and systematic approach to controlling IP packet routing is required, including heterogeneous technologies. managing a global network that supports end-to-end security at the same time. The goals of this original packet-switched network include the following criteria.

1. Ensure security and QoS of the global network or telco, including dynamically managing the routing of real-time voice, video and data traffic throughout the network.

2. Ensure security and QoS of the "local network or telco" in the last mile of the telecommunications network.

3. Ensure security and QoS of the “last link” of the communication network, including providing secure communications over unsecured lines.

4. Verify the security of communication devices and authenticate users to prevent unauthorized or falsified access or use.

5. Promote security measures to store data on devices or online networks or cloud storage to prevent unauthorized access.

6. Provide security and privacy protection of all non-public personal information including financial, personal, medical and biometric data and records.

7. Provide security and privacy for all financial transactions, including online banking and shopping, credit cards and electronic payments (e-pay).

8. Provides security, privacy protection and, where necessary, anonymity in processing and information exchange, including machine-to-machine (M2M), vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2X) communications. .

Of the foregoing objectives, the inventive subject matter covered by this disclosure is directed to the second topic listed in item #2, namely, “Security and QoS of a local network or telco within the last mile of a communication network”. These topics can be regarded as secure last mile connectivity without sacrificing real-time communication performance.

term definition

Unless the context requires otherwise, terms used in the description of secure dynamic communications networks and protocols have the following meanings.

Anonymous Data Packet: A data packet lacking information about its original or final destination.

Client or Client Device: A device connected to the SDNP cloud via the last mile, typically a mobile phone, tablet, laptop, desktop, or IoT device.

Concealment: An encoding process that uses any sequential combination of security operations such as scrambling, splitting, junk data insertion, and encryption to render the contents of an SDNP packet or part thereof unrecognizable. Recovery of obscured data requires the execution of reverse functions or decoding processes in reverse order, eg decryption, junk data removal, shuffling and unscrambling.

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

Disaggregated data storage: The process of fragmenting a data file and obscuring its contents before storing the various fragmented files on different data storage nodes.

DMZ Server: A computer server that is not directly accessible from the SDNP network or the Internet, used to store selectors, seed generators, key generators, and other shared secrets. A DMZ may also be referred to as an "air gapped" server, i.e. a computer that does not have a wired network connection or access.

Dynamic encryption/decryption: Encryption and decryption that rely on dynamically changing keys as data packets traverse the SDNP network.

Dynamic mixing: A mixing process in which the mixing algorithm (inverse function of the segmentation algorithm) dynamically changes as a function of the seed based on conditions such as time, state, and zone when a mixed data packet is created.

Dynamic scrambling/unscrambling: Scrambling and unscrambling that relies on algorithms that change dynamically as a function of state, such as the time a data packet was created or the region in which it was created.

Dynamic segmentation: A segmentation process in which the segmentation algorithm dynamically changes as a function of the seed based on conditions such as time, state, and region when a data packet is segmented into multiple sub-packets.

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

Fragmented Data Transmission: Routing of fragmented and mixed data through the SDNP network.

Junk Data Deletion (or “De-junking”): Removal of junk data from data packets to restore the original data or restore the original length of the data packet.

Junk Data Insertion (or “juncking”): The intentional introduction of meaningless data into a data packet to obfuscate the actual data content or to manage the length of the data packet.

Key: A disguised digital value created by entering a state, such as time, into a key generator that uses a secret algorithm to create a key. The key is used to select an algorithm from the selector to encrypt or decrypt the data in the packet. Keys can be used to securely pass information about state across public or insecure lines.

Key Exchange Server: To prevent any possibility of network operator espionage, public encryption key to the client and optionally to the server using symmetric key encryption, in particular client-managed key management i.e. end-to-end encryption A computer server, often hosted by a third party and independent of the SDNP network operator, used to distribute to clients based on the SDNP network.

Last Link: The network connection between a client's device and the first device in the network it communicates with, typically a radio tower, WiFi router, cable modem, set-top box or Ethernet connection. In the case of Ethernet communications, the last link includes a physically “tethered” (i.e., wired) connection to a cable modem or fiber optic modem. For a WiFi connection (e.g. at a cafe), the last link includes a WiFi router connected to a DSL, cable, or fiber network. In a cellular network, the last link includes a radio link between a cellular tower and a mobile phone, which may include, for example, 3G or 4G/LTE.

Last mile: A network connection between a client and a gateway media node within an SDNP or other type of network or cloud, including a last link. The last mile typically includes communications across networks owned and operated by local telco and cable companies, such as Comcast cable, Verizon cellular, Korean Telecom, British Telecom, and the like.

Mixing: Combining data packets from different sources, which may contain different data types, to create one longer data packet (or series of smaller sub-packets) with unrecognizable content. In some cases, previously segmented data packets are mixed to restore the original data content. Mixed operations may also include junk data insertion and deletion and parsing.

Multiple PHY or multi-PHY: Communications involving alternating transmission of related sequential data packets across multiple physical media, eg fiber and 4G, different WiFi channels and frequencies, 4G and WiFi, Ethernet WiFi, etc.

Parsing: A numerical operation that breaks data packets into shorter sub-packets for storage or transmission.

Router: A device that directs the routing of datagrams to the destination address specified within its IP header. For packet routing outside the SDNP network, the IP address used may represent a valid Internet IP address (an address recognized by a DNS server), or may be submitted to a network address translator (NAT) operated by a local network provider. (eg Comcast assigns its own internal IP address for communication within Comcast cable/fiber networks).

Scrambling: An operation in which the order or sequence of data segments in a data packet is changed from its natural order to an unrecognizable form.

Splitting: The act of splitting a data packet (or series of serial data packets) into multiple sub-packets that are routed to multiple destinations. Partitioning operations may include inserting and deleting junk data.

SoftSwitch: Software containing executable code that performs the functions of telecommunications switches and routers.

SDNP: Abbreviation for "Secure Dynamic Communication Network and Protocol", which means a hyper-secure communication network built according to the present invention.

SDNP address: The address used to route SDNP packets through the SDNP cloud or across the ad hoc IP address of the next destination device, i.e., the last mile containing only enough information to make a single hop.

SDNP Administration Server: A computer server used to distribute executable code and shared secrets to SDNP servers worldwide or in designated areas.

SDNP Bridge Node: A SDNP node that connects one SDNP zone or cloud to another zone or cloud with different security credentials.

SDNP client or client device: A networked device running an SDNP application to connect to the SDNP cloud, typically a mobile phone, tablet, laptop, desktop or IoT device, connecting via the last mile.

SDNP Cloud: A network of interconnected SDNP servers running SoftSwitch executable code to perform SDNP communication node operations.

SDNP Gateway Node: A media node that connects the SDNP Cloud to client devices via the last mile. SDNP gateway nodes require access to at least two zones (of the SDNP cloud, and of the last mile).

SDNP Media Node: Special identification tag on command from the Signaling Server or other computer that performs signaling functions, including encryption/decryption, scrambling/unscrambling, mixing/splitting, tagging, and SDNP header and subhead generation. Softswitch executable code that processes incoming data packets. The SDNP media node is responsible for identifying incoming data packets with a specific tag and then forwarding the newly created data packets to their destination.

SDNP Media Server: A computer server hosting a softswitch that performs the functions of an SDNP Media Node in dual-channel and triple-channel communications and also performs the operations of SDNP Signaling Node and SDNP Name Server Node in single-channel communications.

SDNP Name Server: A computer server hosting a softswitch that performs the functions of an SDNP Name Server node in three-channel communication.

SDNP Name Server Node: Softswitch executable code that manages a dynamic list of all SDNP devices connected to the SDNP cloud.

SDNP Network: Not just the SDNP Cloud, but the entire hyper-secure communications network extending from client to client, including last link and last mile communications.

SDNP Node: A SDNP communication node that includes a software-based "softswitch" running on a computer server or alternatively a hardware device connected to the SDNP network, and functions as a SDNP node as a media node, signaling node or name server.

SDNP Server: A computer server that includes a SDNP Media Server, SDNP Signaling Server or SDNP Name Server and also hosts SoftSwitch functionality applicable to operate as an SDNP Node.

SDNP Signaling Node: Initiates a call or communication between parties, determines all or part of multiple routes for transmitting fragmented data based on caller criteria, and instructs SDNP media how to manage incoming and outgoing data packets. Softswitch executable code that does.

SDNP Signaling or Signal Server: A computer server that hosts a softswitch that performs the functions of an SDNP Signaling Node in dual-channel and triple-channel SDNP communications, and also performs the duties of an SDNP Name Server Node in dual-channel communications.

SDNP tag: A source address, SDNP zip code, or any other code used to identify a received data packet or sub-packet thereof.

Security Operation: The process of modifying a data packet to effect obscuration (or to recover the contents of an obscured packet) using state-dependent security credentials associated with the zone and state of where the packet was created.

Security Settings or Security Credentials: A set of seeds and keys generated by a seed generator or key generator using a secret algorithm with a constantly changing input state, such as network time, and thus capable of being safely transmitted over public or non-secure lines. same digital value.

Seed: A disguised digital value created by inputting a state, such as time, into a seed generator that uses a secret algorithm to create a seed. The seed is used to select an algorithm for scrambling, encrypting or splitting the data in the packet from the selector. Seeds can be used to securely pass information about state over public or non-secure lines.

Selector: A list or table of possible scrambling, encryption or splitting algorithms that is part of a shared secret and is used in conjunction with a seed or key to select a particular algorithm for scrambling, unscrambling, encrypting, decrypting, splitting or mixing packets or packets.

Shared Secrets: Algorithms used by seed generators, key generators, zone information and algorithms stored locally on DMZ servers that are not accessible via the SDNP network or the Internet. Scrambling/unscrambling, encryption/decryption, and mixing, as well as the shuffling process. /Confidential information about SDNP node operation, including tables or selectors of splitting algorithms.

Single PHY: Communication of related packets of data transmitted over a single physical medium, eg fiber optic, or Ethernet, or WiFi, or only over a cellular network.

State: Inputs such as location, zone, or network time used to dynamically generate security settings such as seeds or keys, or select algorithms for specified SDNP operations such as mixing, splitting, scrambling, and encryption.

Time: Universal network time used to synchronize communications across SDNP networks.

Unscrambling: The process of restoring the data segments of a scrambled data packet in their original order or sequential order. Unscrambling is the inverse function of scrambling.

Zone: A network of designated interconnected servers that share common security credentials and shared secrets. Last mile connections include a separate zone from them in the SDNP cloud.

Secure Dynamic Communication Network and Protocol (SDNP) Design

To prevent cyber-attacks and hacking of packet-switched communications while minimizing real-time packet latency, ensuring reliable call connectivity, and delivering the highest integrity of voice communications and video streaming, an open, secure dynamic communications network and protocol, or SDNP, has been established. It is designed according to a number of guiding principles including:

* Real-time communication must always occur using the shortest latency path.

* Unauthorized inspection or sniffing of data packets should not provide information about the packet's origin, where it went, or what was inside it.

* Data packet payloads must be dynamically re-encrypted. That is, it must be decrypted and re-encrypted using a different encryption algorithm, without risk of being hacked at any reasonable time.

* Even after they are decrypted, all data packet payloads still contain unintelligible payloads containing irrelevant data mixed with a dynamic scrambled mix of multiple conversations and junk packet fillers. Implementation of such instructions includes various inventive methods, functions, features and implementations including, in various embodiments, some or all of the following.

* SDNP uses one or more dedicated clouds containing telcos, i.e. telecommunications systems, soft-switch functions realized using proprietary command and control software not accessible via the Internet.

* All intra-cloud communications occur using dedicated SDNP packet routing within a proprietary cloud based on SDNP addresses and dynamic ports (i.e., proprietary NAT addresses) rather than DNS-aware IP addresses. SDNP addresses are not available or routable on the Internet or outside the SDNP cloud.

* The SDNP network continuously identifies and dynamically routes all real-time communications over the lowest latency path available.

* Secure or real-time communications are not routed outside the SDNP cloud or over the Internet, except for cloud-to-cloud and last-mile communications and generally using single-hop routing to invisible addresses.

* Routing data contained in data packets identifies routing for a single hop between two adjacent devices, identifying only the SDNP or IP addresses of the last and next servers.

* The phone numbers or IP addresses of the caller and receiver, i.e., the respective source and destination addresses of the clients, are not present in the IP packet header nor in the encrypted payload.

* Shared secrets related to command and control reside in system software installed on secure DMZ servers that are not accessible over the Internet.

*SDNP packet communication is achieved through three independent channels: "Name Servers" used to identify elements within the SDNP Cloud, "Media Servers" used for content and data routing, and "Signaling" used for packet and call command and control. It can happen through "server".

* Routing information, along with key and numerical seed (if necessary), is supplied to all participating media servers via an independent signaling channel prior to call or communiqué, no content is supplied. The signaling server supplies the media server with only the last and next destinations of packets traversing the network.

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

* Special security methods are used to protect first and last mile communications, including separating signaling server related communications from media and content related packets.

* Packet transport can be voice and real-time video based on enhanced UDP, along with signaling packets, command and control packets, data files, application files, system files, and other files that are sensitive to packet loss or have latency using TCP transport. It is content type dependent with stream.

* Special security and authentication methods are used to verify that the device is a real client and not a clone, and also to verify that the person communicating is the true owner of the device and not a scammer.

* To ensure secure communications with low latency and high QoS, the described “Secure Dynamic Networks and Protocols” or SDNP utilizes a proprietary “dynamic mesh” network that includes:

* Low latency dynamic adaptive multipath and mesh routing

* Dynamic packet scrambling

* Dynamic fragmentation using packet splitting, mixing, parsing and junk bit packet filler.

* Dynamic intra-node payload encryption across networks or clouds.

* Dynamic network protocol with address spoofing and need-to-know routing information.

* Multi-channel communication separating media and content from signaling, command and control, and network addresses

* Dynamically adaptive real-time transport protocol by data type specified characteristics and contextual routing.

* Support of client encrypted payload by user key management.

* Lightweight audio codec for high QoS in congested networks.

As mentioned above, SDNP communication relies on multipath and meshed communication to dynamically route data packets. In SDNP communications according to the present invention, unlike the contrast single route packet communications used in Internet OTT and VoIP communications, the contents of data packets are carried serially by coherent packets containing information from a common source or party. but in a fragmented form that dynamically mixes and remixes content coming from multiple sources and parties, where the data is data, content, voice, video, and incomplete parts of files of similar data types that are aggregated as junk data fillers. do. An advantage of the described realization of data fragmentation and transmission is that unencrypted and unscrambled data packets are nearly impossible to interpret because they represent unrelated combinations of data and data types.

By combining fragmented packet mixing and packet scrambling with packet scrambling and dynamic encryption, these dynamically encrypted, scrambled, fragmented data hybridized packets generate shared secrets, keys, numerical seeds, data, packets, and Contains meaningless packets that are completely incomprehensible to any party or observer without time and state variables used to dynamically repacket them.

Also, the fragmented content of each packet, and the secret used to create it, is only valid for a few seconds before the packet is reconstructed with new fragments and new security rules such as modified seeds, keys, algorithms and ciphers. The limited period at which cyber pirates can destroy and unseal state-dependent SDNP data packets further enhances SDNP security, requiring a processing period of 100,000 per second, and a 12-fold challenge greater than the time to destroy them. .

The combination of the foregoing methods promotes multidimensional security that goes well beyond the security obtainable from static encryption. The secure dynamic communication networks and protocols thus described are referred to herein as "hypersecure" networks.

Data Packet Scrambling - According to the disclosed invention, secure communication over a packet-switched network relies on several factors to prevent hacking and ensure security, one of which includes SDNP packet scrambling. SDNP packet scrambling rearranges the data segments out of order, rendering the information incomprehensible and useless. As shown in FIG. 2A , unscrambled data packets, i.e., data packets 923, processed through scrambling operation 924 appear as scrambled data packets 925. The scrambling operation may use any algorithm, numerical method, or sequencing method. The algorithm may represent a static equation, or may include dynamic variables or numeric seeds based on “states” such as the time scrambling occurred 920 and the numeric seed 929 generated by the seed generator 921; It may generate the seed 929 using an algorithm that depends on conditions such as time 920 when scrambling. For example, if each date is converted to a unique number in monotonically ascending order, then all seeds 929 are unique. Time 920 and seed 929 may be used to select a specified algorithm, or may be used to select or calculate a specified scrambling operation 924 selected from a list of available scrambling methods, i.e., from scrambling algorithm 922. have. In a data flow diagram, it is convenient to depict this packet-scrambling operation and sequence using a schematic or symbolic representation, as shown here by symbol 926.

The unscrambling operation shown in FIG. 2B illustrates the inverse function of scrambling operation 924, specifically unscrambling operation 927, wherein the state or time 920 used to generate scrambled data packet 925 and the corresponding Seed 929 is reused to return unscrambled data, specifically unscrambled data packet 923. Using the same state or time 920 that was used when packet scrambling first occurred, the same scrambling method should be used again in the scrambling operation 927, as selected from the scrambling algorithm list 922. Scrambling Algorithm List 922 references the term "scrambling," and the same algorithm table is used to identify and select the inverse functions needed to perform "unscrambling," i.e., scrambling algorithm list 922 scrambles data packets and It also contains the information needed to unscramble the data packet. Listing 922 can be renamed as “Scrambling/Unscrambling” Algorithm Listing 922 because both functions involve the same steps performed in reverse order. However, for the sake of clarity, the table is presented by function only, not by half function.

If the scrambling algorithm selected to perform the unscrambling operation 927 does not match the original algorithm used for packet scrambling, or if the seed 929 or state or time 920 does not match the time scrambling that occurred, unscrambling Operation will fail to recover the original unscrambled data packet, and the packet data will be lost. For data flow diagrams, it is convenient to describe this packet unscrambling process and sequence using a schematic or symbolic representation, as shown here by symbol 928.

In accordance with the disclosed subject matter, a number of algorithms perform scrambling operations as long as a reversible process, which means repeating steps in the reverse order of the original process, returns each data segment to its original and proper position in a given data packet. can be used to Mathematically, an acceptable scrambling algorithm is a reversible algorithm, i.e. a function F(A) has an anti-function F ^{- 1} (A) or alternatively a variant has a corresponding inverse function, such that F ^-1 [F(A)] = A, which means that the data file, sequence, text string, file, or vector A processed by function F is subject to subsequent processing using the inverse function F ^-1 It means to restore the original input (A) which is not corrupted in value or sequence.

An example of such a reversible function is illustrated by the static scrambling algorithm shown in Fig. 2c including mirroring and phase shifting algorithms. In a mirroring algorithm, a data segment is swapped as a mirror image with another data segment around a line of symmetry defined by a module or "mod" of the mirroring process. For mode-2 mirroring as shown, every two data segments of the original input data packet 930 are exchanged, i.e., 1A and 1B are centered between the first and second data segments, the third and second data segments. To generate an output data packet 935 scrambled with a line of symmetry centered between the fourth data segments, or mathematically as 1.5 ^th , 3.5 ^th , 5.5 ^th , ..., (1.5 + 2n) ^th positions Positions are swapped, such as 1C and 1D, 1E and 1F, and so on.

In mode-3 mirroring, the first and third data segments of every three data segments are swapped, while the middle packets of each triplicate remain in their original positions. Thus, to produce scrambled data packet output 936, data segments 1A and 1C are swapped, while 1B remains in the center of the triplet, data segments 1D and 1F are swapped, and 1E is It is held in the center of three pairs. For mode-3 mirroring, the line of symmetry is centered at positions 2 ^th , 5 ^th , 8 ^th , ..., (2 + 3n) ^th .

For mode-4 mirroring, to generate a scrambled output data packet 937 from an input data packet 931, the first and fourth data segments and the second and third data segments of every four data segments are are swapped Thus, data segment 1A is swapped with 1D, and data segment 1B is swapped with 1C. For mode-4 mirroring, the line of symmetry is centered between every 4 pairs of the second and third data segments, e.g., between the second and third data segments, the sixth and seventh data segments, etc., or Mathematically, it is located at 2.5 ^th , 6.5 ^th , ..., (2.5 + 4n) ^th . For mode-m mirroring, the m-th data segment of the input data packet 932 is swapped with the first, 0 ^th data segment; The 0 ^th data segment is swapped with the m ^th element, and similarly the n ^th element is swapped with the (mn) ^th data segment to produce scrambled output data packet 938.

Another scrambling method, also shown in FIG. 2C, is frame shift, in which all data segments are shifted to the left or right by one frame, two frames, or more frames. For example, in a single frame phase shift, all data segments are shifted by one frame to produce scrambled output data packet 940, where the first data segment is shifted to a second position; The second data segment is shifted into the third frame. Frame 1F, the last frame of the input data packet 930 in the illustrated example, is shifted to the first frame previously occupied by data segment 1A.

In a two-frame phase shift, the first data segment 1A of the input data packet 930 is shifted by two frames into the position already occupied by the data segment 1C, and the fourth frame 1D is scrambled. The last position of the output data packet 941 is shifted, the next of the last data segment (1E) is shifted to the first position, and the last position (1F) is shifted to the second position. Similarly, in a 4-frame phase shift, the data segments of input data packet 930 are replaced by 1E, 1B, 1A where the first frame 1A replaces 1F to produce scrambled output data packet 942. It is shifted to the fourth position with the first frame 1A replacing the frame already held by 1C. In the case of maximum phase shift, the first frame replaces the last, the second frame retained originally by 1B becomes the first frame of the output data packet 943, the second element is shifted to the first position, The third position is shifted to the second position. Phase shifting one frame beyond the maximum phase shift results in unaltered output data from the input. The example shown includes a phase shift where the data is shifted to the right. This algorithm works for phase shifts that shift to the left but result in different phases.

The foregoing algorithm and similar methods as disclosed are referred to herein as static scrambling algorithms because the scrambling operation occurs in a single time to transform an input data set into a unique output. Moreover, the algorithms already shown do not rely on the values of the data packets to determine how the scrambling takes place. As shown in Fig. 2d, in accordance with the disclosed invention, parametric scrambling is based on values derived from data contained within the data packet itself, a table of scrambling algorithms for which scrambling methods are possible, e.g. Class # A, Class # means selected from B. Assume, for example, that each data segment can be converted to a number based on a computation of the data contained within the data segment. One way to determine the number of data segments is to use the same decimal or hexadecimal number as the bit data in the data segments. If a data segment contains multiple terms, the number can be found by summing the numbers in the data segment. The data segment data is combined with a single number or "parameter", which is then used to select which scrambling method is used.

In the illustrated example, the unscrambled data packet 930 is converted in step 950 to a data table 951 that contains a number for each data segment as a parameter. As shown in data segment 1A, data segment 1A, which is the 0th frame, has a numerical value of 23, and data segment 1B, which is the first frame, has a numerical value of 125. A single data packet value is extracted in step 952 for the entire data packet 930. In the illustrated example, sum 953 represents the linear sum of all data segment values from table 951 that parametrically all equal 1002, which parametrically sums to 1002. In step 954 this parametric value, sum 953, is compared to sum 953 over a number of non-overlapping ranges of numbers in table 955 to determine what kind of sorting routine should be used: It is compared against a state table, which is a predefined set of states in software. In this example, the parameter value 1002 is in the range 1000 to 1499, which means that class # C should be used. Once the sorting routine has been selected, parameter values are no longer required. The unscrambled data input 930 is then scrambled by the method selected in step 956 to produce a scrambled data packet output 959. In the illustrated example, classification # C summarized in table 957 includes a set of relative movements for each data segment. The 0th frame, which is the first data segment of the scrambled data packet 959, is determined by shifting the 1D data segment 3 times, that is, shifting it to the left by 3 shifts. The first frame contains a data segment 1B that has not changed from its original position, ie a movement of zero places. The second frame contains a data segment, 1E, shifted to the left by moving twice from its original position. The same is true for the third frame containing the data segment 1F shifted to the left from its original position. The fourth frame of scrambled data packet output 959 includes data segment 1C shifted right from its original position, i.e. +2 shift. The fifth frame contains the data segment 1A shifted to the right 5 times, i.e. +5, from its original position.

In this way, summarized in table 957 for Class #C, every data segment is uniquely moved to a new location to create a parametrically determined scrambled data packet 959. To unscramble a scrambled data packet, to ensure that the same algorithm is chosen to perform the unscrambling operation, the data packet's parameter value 953 cannot change as a result of the scrambling operation. For example, using a linear sum of parameter values from all data segments produces the same number regardless of the order of the numbers.

Dynamic scrambling uses a system state, eg time, to be able to identify conditions when a data packet was scrambled, so that the same method can be selected to perform the unscrambling operation. In the system shown in Figure 2e, the state is used to generate a forged numeric seed that is sent to the sender or receiver of the package, and then uses the seed to select a scrambling algorithm from a table. Alternatively, the state itself may be transmitted to the sender or receiver, and the state may be used by a covert digit generator located at the sender or receiver to generate a covert digit used to select a scrambling/unscrambling algorithm. Thus, in FIG. 2E , a state, e.g. time 920, is used to generate a hidden number 961 using a hidden number generator 960 and select a scrambling method from a list of scrambling algorithms 962. The concealment number generator 960 can also input the concealment number HN 961b directly into the scrambling operation 963, where HN can serve as a variable in scrambling operation execution. A scrambling operation 963 then converts the unscrambled data packets 930 into scrambled data packets 964. As shown in FIG. 2F , state 920 may be passed directly to covert number generator 960 , or state 920 may be passed to covert number generator via seed generator 921 .

The advantage of using concealed digits to select scrambling algorithms instead of numerical seeds is the likelihood that cybercriminals will recreate the scrambling table by analyzing the data stream, that is, by statistically relating repeated sets of scrambled data to the numerical seeds of their counterparts. is that it removes Although the seed may be visible in the data stream and thus exposed to espionage, the covert number generator and covert number (HN) are based on a shared secret. This means that the concealed number (HN) does not exist in the data stream or is exposed to espionage or sniffing, and is not transmitted over the network, but is generated locally from a numeric seed. This mathematical operation of the covert number generator adds an extra layer of security to thwart hackers, since the purpose of the number seed is disguised.

Once an algorithm is selected, the numeric seed may be used as an input variable in the algorithm of the scrambling process 963. The dual use of a numerical seed is a confusing analysis because the seed does not directly select the algorithm, but works with it. Determine the final sequence of scrambled data segments. In a similar manner, to scramble a dynamically scrambled data packet, the seed 929 (or alternatively state or time 920) is a node or It must be passed to the device.

In accordance with the disclosed subject matter, the seed generation algorithm 921, the covert number generator 960, and the list of scrambling algorithms 962 are "shared secrets", stored in the DMZ server (as described below) and stored by the sender of the data packet or Indicates information unknown to the recipient. The shared secret is pre-established and possibly unrelated to the communication data packets to be transmitted during code installation where various authentication procedures are used to ensure that the secret is not leaked. As will be described below, shared secrets are restricted to "zones" so that a hacker cannot gain access to an entire communication network or intercept real-time statements if one set of stolen secrets is known.

In dynamic scrambling, where the scrambling algorithm changes during data packet transmission, in addition to any shared secret, a "state" based seed is required to scramble or unscramble data. This state on which the seed is based is time, as long as there is no ambiguity about the state used to generate the seed, and some means of telling the next node which state was used to last scramble the data packet. It may contain any physical parameters such as communication node number, network ID or GPS location. The algorithm used by the seed generator to generate the seed is part of the shared secret, and thus knowledge of the seed does not allow determining the state on which the seed is based. A seed can be passed from one communication node to the next by embedding it within the data packet itself, transmitting it over another channel or path, or some combination thereof. For example, the state used to generate the seed may include a random number generated by a counter and subsequently incremented by a constant number each time a data packet traverses a communication node, each count dependent on a specific scrambling algorithm. indicates

In one embodiment of dynamic scrambling, during the first instance of scrambling, a random number is generated to select a scrambling method to be used. This random number is embedded in the data packet in the header or part of the data packet that is reserved for command and control and not exposed to scrambling. When the data packet arrives at the next node, the embedded number is read by the communication node and used by the software to select an appropriate algorithm to unscramble the incoming data packet. The number or "count" is then incremented by one count or some other predetermined integer, the packet is scrambled according to an algorithm associated with this new number, and the new count is stored in the data packet output overwriting the previous number. do. The next communicating node repeats the process.

In another embodiment of the counter-based method described for selecting a scrambling algorithm, a random number is generated to select an initial scrambling algorithm, which number is used by all communication nodes to transmit a designated data packet as a "shared secret". is forwarded to For example, a count starting with zero is also embedded in the data packet in the header or portion of the data packet that is reserved for command and control and not exposed to scrambling. The data packet is then forwarded to the next communication node. When the packet arrives at the next communication node, the server reads the value of the count, adds the count to the initial random number, identifies the scrambling algorithm used to final scramble the data packet, and unscrambles the packet accordingly. The count is then incremented by one or any predetermined integer, and the count is stored again in the header of the data packet or any portion of the data packet reserved for command and control and not exposed to scrambling, overwriting the previous count. Random numbers serving as shared secrets are not communicated in communication data packets. When the data packet reaches the next communication node, the server adds a random number shared secret that is added to the modified counter value extracted from the data packet. This new number uniquely identifies the scrambling algorithm used by the last communication node to scramble incoming packets. In this way, a cyber pirate who does not know what the data means can only intercept meaningless count numbers in the unscrambled portion of the data packet.

In another alternative method, the obscurity number can be used to communicate the status of the packet and what algorithm was used to scramble it. The covert number is a secret number, i.e. a shared secret, usually involving a numeric algorithm, together to generate a "covert number" that is never communicated between communicating nodes and is therefore impossible to sniff or discover to any man in the middle attacker or cyber pirate. Bind time-varying states or seeds together. The concealment digit is used to select the scrambling algorithm used. A state or seed is meaningless unless you know the algorithm used to calculate the hidden number, since the shared secret algorithm can be stored behind a firewall that is not accessible over the network or the Internet, thus reducing the amount of monitoring of network traffic. Because it doesn't reveal a pattern. To further complicate matters, the location of a seed may represent a shared secret. In one embodiment, the number carried by the unscrambled portion of the data packet and observable by data sniffing, e.g., 27482567822552213, contains a long number representing the seed, in which only part of the number is. For example, if the third to eighth numbers represent the seed, the actual seed is not the whole number, but the bold number 27482567822552213, that is, the seed is 48256. This seed is combined with a shared secret algorithm to generate a hidden number, which is used to select a dynamically changing scrambling algorithm throughout the network.

The application of scrambling of data packets in SDNP networks is described in US application Ser. No. 14/803,869, filed July 20, 2015 and entitled “Secure Dynamic Communication Network and Protocol”. The application of data packet scrambling in last mile communication will be described in more detail in this disclosure.

As explained, data traversing the network, even if scrambled, may be referred to as "plaintext" because the actual data is present in the data packet, i.e., the packet is not encrypted with ciphertext. In contrast, in ciphertext, a text string containing the original data, scrambled or not, is translated into a sequence of nonsensical text using an encryption key, and cannot be restored to its original plaintext form without a decryption key. The role of encryption in the described SDNP-based communications is discussed in more detail in the section "Cryptography" below.

In order to change the order of data packets during transmission over the network, packet "re-scrambling" is required, as shown in FIG. The process of packet re-scrambling returns a scrambled data packet to its unscrambled state with a new scrambling algorithm before scrambling it again. Thus, the term "rescramble" as used herein typically means unscrambling a data packet and then scrambling it again, typically with a different scrambling algorithm or method. This approach avoids the risk of data corruption caused by scrambling a previously scrambled package and also losing the sequence track needed to restore the original data. As shown, once initially scrambled by packet scrambling operation 926, scrambled data packet 1008 is first subjected to unscrambling operation 928 using the inverse operation of the scrambling algorithm used to scramble the data. It is “rescrambled” by unscrambling and then scrambling the data packet with a new scrambling operation 926 that uses a different scrambling algorithm than that used in the previous scrambling operation 926. The resulting re-scrambled data packet 1009 is different from the previous scrambled data packet 1008. Re-scrambling operation 1017 includes the continuous application of unscrambling followed by scrambling, referred to herein as “US re-scrambling”. Here, “US” is an abbreviation for “unscrambling-scraambling”. To recover the original data packet 930, the last packet unscrambling operation 928 requires using the inverse of the same algorithm used to last re-scramble the data packet.

In accordance with the disclosed invention, static and dynamic scrambling of data renders interpretation of unscrambled data meaningless, reordering sound into unrecognizable noise, reordering video into video snow, reordering text, and recovering data. scramble code that cannot be By itself, scrambling provides a great level of security. However, in the SDNP method described herein, scrambling is only one element used to provide and ensure communications free from hacking, cyberattacks, cyberpirates, and man-in-the-middle attacks.

Packet Encryption - According to the disclosed invention, secure communications over packet-switched networks rely on several factors to prevent hacking and ensure security, one of which includes SDNP encryption. Encryption, which in Greek means "conceal, conceal, obscure," as already described, is the conversion of plain information or data, commonly referred to as "plaintext," into "ciphertext," which contains an incomprehensible format that cannot be read without secret knowledge. indicate means. In modern communications, this secret knowledge usually involves sharing one or more "keys" used to encrypt and decrypt data. The key generally includes a pseudo-random number generated by an algorithm. Many articles and texts today include "Cryptography" by Neal Stephenson © 1999, "The Code Book: The Secret Science of Quantum Cryptography from Ancient Egypt" by Simon Singh © 1999, Niels Ferguson Ferguson) © 2013, “Encryption in Practice,” and “Decryption: A Study of Ciphers and Their Solutions,” first published in 1939, can be used to discuss the pros and cons of various cryptographic techniques.

Although the concept of cryptography or cryptography is old and well known to those skilled in the art, the application of cryptography in the disclosed secure dynamic communications networks and protocols is unique, and independent of any client's own encryption, end-to-end to the network architecture itself. It promotes both encryption and single-hop node-to-node dynamic encryption. SDNP communication consists of ground rules given enough time, and also that any static encrypted file or message, regardless of the encrypted ciphertext, will eventually be destroyed and the information stolen. While this assumption may be incorrect in practice, the proposition need not be proven or disproved, since the opposite case, i.e., waiting for the specified encryption method to fail, would lead to unacceptable and irreversible consequential damage.

Instead, SDNP communication is based on the premise that all encrypted files have a limited "period of validity", i.e. encrypted data is only safe for a finite period, secret data must be dynamically re-encrypted at regular intervals, It also means metaphorically that it ideally occurs much more often than the best estimate of the time required to crack that encryption with a state-of-the-art computer. For example, if it is estimated by a cryptographer that an opposing server farm of cryptographic engines can crack a given cipher in one year, then in SDNP communications data packets will be re-encrypted every second or even every 100 ms, Shorter than the ability of the best technology can crack it. SDNP encryption is therefore necessarily dynamic, i.e. time-varying, and also spatially i.e. dependent on the position of a communication node in a packet-switched network or geographic location. Thus, as used herein, the term “re-encryption” or “re-encryption” refers to decrypting a data packet and then re-encrypting it, typically with a different encryption algorithm or method.

Thus, SDNP encryption repeatedly converts data from unencrypted plaintext into ciphertext repeatedly, rendering the information incomprehensible and useless. Even if the data encryption of a given packet is miraculously broken by using SDNP's dynamic encryption method, the next data packet uses a completely different encryption key or cipher, and also requires an entirely new effort to crack the encryption. By restricting the entire contents of each uniquely encrypted data packet, the potential harm of unauthorized access is mitigated, since the exposed data packets themselves are too small to contain meaningless or useless data files by cyber pirates. Because. Furthermore, by combining dynamic encryption with the SDNP scrambling method described above, communication security is greatly improved. Even in its unencrypted form, an intercepted data file contains only small snippets of data, voice or video scrambled into meaningless and incomprehensible sequences of data segments.

To avoid lifetime security issues, SDNP encryption is dynamic and state-dependent. As shown in FIG. 4A , unencrypted data packets containing plaintext 930 processed through encryption operation 1020 appear as encrypted data packets containing ciphertext 1024 or 1025 . In the case of ciphertext 1024, the entire data packet of plaintext 930 is entirely encrypted, and data segments 1A to 1F are treated as a single data file. In the case of ciphertext 1025, each data segment 1A-1F is individually and explicitly encrypted and is not merged with other data segments. The first data segment 1A is encrypted to a corresponding first ciphertext data segment, shown by a text string containing digits or a long text string not shown that starts with 7 $ for illustrative purposes. Similarly, the second plaintext data segment 1B is encrypted into a second encrypted ciphertext data segment comprising a long text string shown for illustrative purposes beginning with *^. Text 7 $ and *^ are meant to indicate the beginning of nonsensical symbols, digits and alphanumeric text strings, and do not limit or impose anything on the data specified in the plaintext source or the length of the text string to be encrypted.

Encryption operation 1020 may use any available algorithm, encryption or encryption method. While algorithms may represent static equations, cryptographic operations in one embodiment are performed by a cryptographic generator 1021 to generate dynamic variables such as time 920 or "state" and "E-key" 1022 when encryption occurs. ), which may depend on conditions such as the time 920 when encryption was performed. For example, the date and time of encryption can be used as a numerical seed to generate an encryption key that cannot be recreated even if the encryption algorithm is discovered. Time 920 or other "state" may be used to select a specified algorithm from encryption algorithm list 1023, which is a list of available encryption algorithms. In the data flow diagram, it is convenient to describe these packet encryption operations and sequences using diagrammatic or symbolic representations, as illustrated by the symbols shown for encryption operation 1026. Throughout the present invention, padlocks may also symbolically represent secure and encrypted data. A padlock with a clock face located on top of the padlock specifically represents a secure delivery mechanism, eg an encrypted file, which, if not received within a specified interval or time, self-destructs and is lost forever.

The decryption operation shown in FIG. 4B illustrates the inverse function of encryption operation 1020, specifically decryption operation 1031, where the decryption key or “D-key” generated by D-key generator 1029 and Together, the state or time 920 and the other states used to generate the ciphertext 1024 are used to undo the encryption, i.e., to create unencrypted data containing the original plaintext data packet 990, i.e., file reused for detoxification. The same encryption operation selected from the encryption algorithm list 1023 can be used again in the decryption operation 1031, using the same state or time 920 that was used when the packet encryption first occurred. Although encryption algorithm list 1023 refers to the term “encryption,” the same algorithm table is used to identify and select the inverse function needed to perform “decryption,” i.e., encryption algorithm list 1023 is used to encrypt and decrypt data packets. Include the necessary information. Table 1023 may be renamed "Encrypt/Decrypt" Algorithm Table 1023 because both functions involve the same steps performed in reverse order. However, for the sake of clarity, the table is only labeled by function and not labeled as half-function.

If the encryption algorithm selected to perform decryption operation 1031 does not match the inverse of the original algorithm used in packet encryption operation 1020, if the time or state 920 does not match the time at which encryption occurred, or D - if the key 1030 does not have a predefined numeric relationship to the E-key 1022 used during encryption, the decryption operation 1031 does not recover the original unencrypted data 990, nor does the packet data will be lost In the data flow diagram, it is convenient to depict this packet decryption operation and sequence using a schematic or symbolic representation, as shown by the symbols shown for decryption operation 1032.

As already described herein, knowledge regarding the use of encryption and decryption keys in cryptography, and the use of common encryption algorithms such as symmetric public key cryptography, RSA cryptography, and AES256 cryptography, is common and in the present technology. It is well known to those skilled in the art. However, the application of these known cryptographic methods in the described SDNP communication system is not easily susceptible to hacking or cracking because of the hidden information, shared secrets, and time-dependent dynamic variables and states inherent to the described SDNP communication. .

Thus, even if cyber pirates have sufficient computing power to break strong cryptographic methods, they lack any information embedded in the SDNP network as a private or shared secret necessary to perform decryption operations, and in fractions of a second before the encryption is changed. You have to crack the encryption. In addition, every data packet traversing the described SDNP network uses a different encryption method with a unique key and dynamic state. The combination of missing information, dynamic state, and limited information content contained within a given packet results in meaningful data theft from any given data packet, both a challenge and an exclusion to cyber pirates.

The application of dynamic encryption and decryption of data packets within SDNP networks is described in the aforementioned US Application Serial No. 14/803,869 entitled "Secure Dynamic Communication Network and Protocol". The application of data packet ciphertext in last mile communication will be discussed in greater detail in this disclosure.

In order to intercept an entire document, video stream, or voice conversation and reconstruct a coherent data sequence, a cyber attacker must successively crack and decrypt not one, but thousands of contiguous SDNP packets. The daunting challenge of serial hacking of a series of SDNP packets is further exacerbated by combining dynamic encryption with the previously described methods of scrambling data packets. As shown in FIG. 5, the generation of encrypted scrambled data packets 1024 first converts unscrambled plaintext data packets 990 into scrambled plaintext data packets 1008 and then the ciphertext of the scrambled data packets. (1024) includes the successive combination of scrambling operation (926) and encryption operation (1026). To return the encrypted scrambled package, first by decryption operation 1032 to recover the scrambled plaintext data packet 1035 and then by unscrambling operation 928 to recover the next unscrambled plaintext data packet 990 The inverse functions must be applied in reverse order by

As shown, scrambling and encryption represent complementary techniques in achieving secure communications. Unencrypted scrambled data traversing the network is referred to as "plaintext" because the actual data is present in the data packet, i.e. the packet is not encrypted with ciphertext. Encrypted data packets, or ciphertext, include scrambled or unscrambled text strings that have been converted using an encryption key into a nonsensical series of nonsensical text, and cannot be restored to their original plaintext form without a corresponding decryption key. Depending on the algorithm used, the encryption and decryption keys may include the same key or distinct keys that are mathematically related by a predefined mathematical relationship. Scrambling and encryption therefore represent complementary techniques in achieving secure communications according to the invention described for SDNP communications.

The two methods, namely scrambling and encryption, can be used independently, even if used in combination, except that the sequence used to recover the original data packet from the encrypted scrambled data packet must occur in the reverse order used to create it. can be considered For example, if data packet 990 is first scrambled using scrambling operation 926 and then encrypted using encryption operation 1026, to recover the original data packet, the encrypted scrambled data packet 1024 ) must first be decrypted using decryption operation 1032 and then unscrambled using unscrambling operation 928. Mathematically, if a scrambling operation (F) scrambles a series of bit strings or text strings into equivalent scrambled versions and an unscrambling operation (F ^-1 ) undoes the scrambling, then F ^-1 [F(A)] = A , and similarly, if the encryption operation (G) encrypts the plaintext string into an equivalent ciphertext, and the decryption operation (G ^-1 ) cancels the encryption, then G ^-1 [G(A)] = A, and then , the successive operations of scrambling and then encryption and decryption and unscrambling in combination restore the original argument (A), the unscrambled plaintext data packet. Thus, F ⁻¹ {G ⁻¹ [G(F(A))]} = A, since the sequence occurs in reverse order, in particular [G ⁻¹ ] encrypted scrambled packet [G(F(A) )] restores the scrambled plaintext data packet F(A) Subsequent unscrambling operation [F(A)] of the scrambled plaintext packet F(A) restores the original data packet A .

If the linear method provided is used, the sequence is reversible. For example, if a data packet is first encrypted and then scrambled, then to recover the original data packet, the scrambled ciphertext must first be unscrambled and then decrypted. Therefore, G ^-1 {F ^-1 [F(G(A))]} = A.

Sequence changes do not work. Decrypting a previously encrypted and then scrambled data packet without first unscrambling will not recover the original data packet, i.e. F ^-1 {G ^-1 [F(G(A))]} ≠ A.

Likewise, decryption of a scrambled and then encrypted packet will also not recover the original data packet, since G ^-1 {F ^-1 [G(F(A))]} ≠ A.

In summary, if a plaintext packet is scrambled before being encrypted, it must be decrypted before being unscrambled, and if a plaintext packet is encrypted before being scrambled, it must be unscrambled before being decrypted.

In one embodiment of the SDNP method according to the present invention, scrambling and encryption can be performed in either order, but encryption and decryption occur more frequently than scrambling during network transmission, and therefore do not reverse as shown in FIG. Rather, encryption should occur only after scrambling and decryption occurs before unscrambling. For convenience, we have defined the combination of packet scrambling operation 926 followed by encryption operation 1026 as scrambled packet encryption operation 1041, and vice versa, packet unscrambling operation 928 followed by decryption operation ( 1032) was defined as the decrypted packet scrambling operation 1042. These hybrid operations can be used for static and dynamic SDNP communications in accordance with the present invention.

One means to improve security in any implementation that uses static scrambling encryption is to include a change in the state, seed, and/or key at the time each data packet enters the communication network (t ₁ ), such that the transmitted It is to ensure that each data packet is exposed to different scrambling and/or encryption methods.

However, a more robust alternative is to dynamically change the encryption or scrambling, or both, of data packets as they traverse the network in time. To expedite the necessary data processing to implement a fully dynamic version of SDNP communication, each packet is “re-scrambled” (i.e., unscrambled and scrambled) as it passes through each communication node in a packet-switched communication network and It is necessary to combine the previously defined process to re-encrypt (i.e. decrypt and then encrypt). As used herein, the terms "repacket" or "repacketing" sometimes refer to a combination of "rescrambled" and "re-encrypted" depending on whether they are initially decrypted before being unscrambled or unscrambled before being decrypted. will be used to In any case, the unscrambling and decryption operations at a given node must be performed in the reverse order of the scrambling and encryption operations when the packet leaves the previous node, i.e., if the packet was scrambled at the previous node and then encrypted, then at the current node. It has to be decrypted first and then unscrambled. Typically, packets will be scrambled upon leaving the current node and then encrypted.

A “repacket” operation in a communication node is illustrated in FIG. 6, where an incoming ciphertext data packet 1040 is first decrypted by a decryption operation 1032 and then unscrambled, containing the contents of the original packet. To recover the plaintext data packet 990 it is unscrambled by an unscrambling operation 928. If any information in the packet must be inspected, parsed, split, or redirected, an unscrambled plaintext file is the best format for performing these operations. The plaintext data packet 990 is then scrambled again using scrambling operation 926 followed by a new encryption performed by encryption operation 1026 to produce a new scrambled ciphertext data packet 1043. . Since the repacket operation of an incoming scrambled ciphertext data packet 1040 occurs sequentially by decryption, unscrambling, scrambling, and encryption, the abbreviation DUSE repacket operation 1045 denotes a technique herein described in accordance with the present invention. used here for In a dynamic security network, the state or time used to perform the decryption operation 1032 and the unscrambling operation 928, the decryption key and any seeds are preferably the state or time used to perform the scrambling operation 926 and the encryption operation. It is different from time, seed or encryption key.

The application of repacketing of data packets in SDNP networks is described in the aforementioned US Application Serial No. 14/803,869 entitled "Secure Dynamic Communication Network and Protocol". The application of data packet repacketing in last mile communication will be described in more detail in this disclosure.

Packet Mixing and Splitting - Another key element of the secure dynamic communication networks and protocols described herein is to divide data packets into sub-packets, direct these sub-packets into multipath, and sub-packet packets. Its ability to mix and recombine the data to form complete data packets. The process of packet splitting is shown in FIG. 7A, where data packets 1054 are combined with an algorithmic parsing operation 1052 and a junk operation 1053 with the ability to insert or remove non-data "junk" data segments. Divided using segmentation operation 1051 . Similar to junk DNA present in the human genome, junk data segments are inserted by junk operation 1053 to extend or control the length of the data packet, or to remove it as needed. Junk operation 1053 is particularly important when there is an inadequate amount of data to fill the packet. The presence of junk data segments embedded within data packets makes it difficult for cyber pirates to distinguish real data from noise. As used herein, a “junk” packet or data segment is a packet or data segment composed of completely meaningless data (bits). These junk bits can be introduced into a stream of data packets that obfuscate the actual data in a sea of meaningless bits.

The purpose of parsing operation 1052 is to divide data packet 1054 into smaller data packets, e.g., data sub-packets 1055 and 1056, to process each component. Splitting the data packet 1054 into smaller pieces is such as to support multi-path transmission, i.e., to transmit the data packet over multiple and different paths, and using different encryption methods to distinguish the constituent sub-packets. provides unique benefits such as facilitating secure encryption.

The split operation may use any algorithm, numeric method or parsing method. The algorithm may represent a static equation, or a dynamic one such as the time 920 when an incoming input data packet 1054 was first formed by many sub-packets and the numerical seed 929 generated by the seed generator 921. It may include a variable or numeric seed or "state", which may also depend on a state, such as time 920 at the time of creation of the data packet. For example, if each date was converted to a unique number in monotonically ascending order, then all seeds 929 are unique. Time 920 and seed 929 can be used to identify a specific algorithm selected from a list of available methods, namely algorithms 1050. Packet splitting or non-mixing involves the process of mixing, using the same algorithm executed in the precise inverse sequence used to create the specified packet. Ultimately all used actions are undone, but not necessarily in one step. For example, a scrambled encrypted data packet may be decrypted but remain scrambled. When processed by segmentation operation 1051, the undivided incoming data packet 1054 is converted into multiple data packets of fixed length, e.g., using parsing operation 1052 to algorithmically perform the above operation. Split packets 1055 and 1056. In the data flow diagram, this packet split operation including parse 1052 and junk operation 1053 using a schematic or symbolic representation, as shown here by the symbols shown for split operation 1057. It is convenient to describe (1051).

Thus, as used herein, the term "splitting" includes parsing, which refers to the splitting of a packet into two or more packets or sub-packets, which also includes junk in the resulting "parsed" packet. insertion of packets or sub-packets or deletion of junk packets or sub-packets in the resulting “parsed” packets or sub-packets.

The inverse, packet-mixing operation 1060 shown in FIG. 7B combines multiple packets 1055 and 1056 together to form a mixed packet 1054. Like packet splitting, packet mixing operations can use any algorithm, numerical method, or blending method. The algorithm may represent a static equation, or may include a dynamic variable such as time 920 or a numeric seed or "state" used to specify conditions when incoming data packets 1055 and 1056 are mixed. . The blending operation used to generate the data packet may utilize a numeric seed 929 generated by seed generator 921 which may depend on conditions such as time 920 . Time 920 and seed 929 may be used to identify a designated mixing algorithm selected from a list of available mixing methods, namely mixing algorithm 1050 . In the data flow diagram, it is convenient to describe this packet mixing operation using a schematic or symbolic representation, as shown here by the symbol shown for mixing operation 1061.

In accordance with the present invention, packet mixing and splitting may utilize any of a number of possible algorithms. Figure 8 shows three of the many possible blending methods including concatenation, interleaving or algorithmic methods. Upon concatenation, the sequence of data segments from data packet 1056 is added to the end of data packet 1055, creating a mixed packet 1054. In interleaving, the data segments of data packets 1055 and 1056 are combined in an alternating fashion, i.e., 1A, 2A, 1B, 2B, etc., to form mixed data packet 1065. Other methods used for packet mixing include algorithms. In the illustrated example, the algorithm involving interleaved reflection symmetry intersects the data segments in the order 1A, 2A, 1B, 2B, 1C, 2C in the first half of the mixed packet 1066, and in reverse order in the second half, That is, they intersect in the order of 2D, 1D, 2E, 1E, 2F, and 1F.

The application of data packet mixing and splitting in SDNP networks is described in the aforementioned US Application Serial No. 14/803,869 entitled "Secure Dynamic Communication Network and Protocol". Fig. 9a schematically shows SDNP functional elements, including functions and their corresponding inverse operations, ie inverse functions, as well as dynamic components of the corresponding functions, i.e. the state or time of each function when executed on a data packet. The SDNP function includes scrambling operations including packet scrambling 926 and its inverse packet unscrambling 928; Encryption operations including encryption (1026) and decryption (1032), along with fragmentation operations including splitting (1057) and its inverse mixing (1061), deception operations including junk insertion (1053) and junk removal (1053B). includes All of these actions occur specifically according to a time or state variable 920 .

Applying data packet mixing and splitting, along with scrambling, unscrambling, encryption, decryption, and spoofing in last mile communications collectively includes SDNP last mile security operations. These SDNP last mile security operations are “directive”, meaning that the operation performed on and for all outgoing data packets is different from the operation performed on incoming data packets.

SDNP last-mile security operations are also symmetric and reversible across the last mile, which when using local security credentials, such as keys, seeds, and shared secrets specific to a particular last mile, enforces on outbound data packets in the client's device. This means that an operation is undone at the SDNP gateway, typically by performing a reverse function, i.e., a mathematical reciprocal, or any functional operation originally executed by the client's device, but in reverse sequence. Thus, the SDNP gateway can restore the original content in preparation for routing through the SDNP cloud. Similarly, to introduce data packets into the client's device using zone-specific security credentials for the last mile, the SDNP last mile security operation executed on the client device is executed by the SDNP gateway by executing the reverse sequence of functions. Undo each security operation performed. In this way, the client device can restore the original data in every received data packet.

SDNP last mile security operations are dynamic and local, i.e. zone specific, to determine what parameters were used when a data packet was prepared and what area, geographic location, or locale was specific to a particular last mile; Use state-dependent conditions, i.e. location, time, etc. By being localized, data packet preparation conducted in different areas and in different last mile connections never has the same coding or uses the same security credentials. Also, these last mile security credentials are always different from those used in the SDNP cloud. Also, dynamically, the state used to create a data packet is constantly changed, further confusing the actual security process performed on each data packet and making no two data packets alike.

The algorithmic application of dynamic scrambling, dynamic fragmentation, dynamic spoofing, and dynamic encryption, made in the present invention, by the unique combinatorial application of specific directional, symmetric, reversible, dynamic localized security operations to each last mile communication: It ensures hyper-secure communication that cannot be achieved with the use of simple static encryption methods. A comprehensive application of the dynamic method, valid for a duration of only a few tens of milliseconds, not only makes interpretation almost impossible, but also gives the hacker no time to decrypt or interpret the data packet before another arrival. In practice, SDNP last mile security operations can be implemented using software, firmware, hardware, dedicated security ICs, or any combination thereof.

Although innumerable combinatorial sequences are possible, one example of SDNP last-mile secure operation, especially for serial SDNP payloads used in single-path last-mile communications, is shown in FIG. Communicate with the SDNP gateway. Such a process includes two directional action sequences, one for outgoing data packets and the other for incoming data packets. In the case of outgoing data packets, shown in the top half of the figure, the “transmitted data” is first scrambled using packet-scrambling operation 926, followed by deception by insertion of junk data 1053A. In some cases, the entire packet may contain junk data as a whole, further confusing data mining attempts by hackers.

These packets are then divided into multiple fragments by segmentation operation 1057 using parsing operation 1052 and sent separately to encryption operation 1026. Each fragment is then encrypted using a common or distinct encryption key, and the resulting cipher text is arranged into a serial SDNP payload, shown as data packet 1199A. Then, in preparation for communication over the last link and last mile, the packets are formatted into IP data packets, i.e., "IP packet ready". All actions performed are dynamic, occurring at specific times or in specific states 920A during security process execution.

In the case of the received data packets shown in the lower half of the figure, the received data from the last link containing the serial SDNP payload 1199B, i.e. from "IP Packet Recognition", is first decoded to recover the actual data stream. By operation 1032 and subsequent blending operation 1061, fragments or whole are decoded. Then, to recover the "received data", the data packet is dejunked, i.e., the junk data is removed from the data packet, using dejunk operation 1053B and subsequent packet unscrambling operation 928. All operations performed on incoming data packets use the state 920B that the SDNP gateway used when creating the data packet, i.e., at the birth of the packet, which contains information about a specific time or having a specific state 920B. shall. This state information may be transmitted over different communications by the signaling server, or may be accompanied within received data packets as plaintext or alternatively as static ciphertext, i.e. as ciphertext with a known decryption key by means of SDNP last mile security operations. can However, details about state 920B cannot be decrypted using a key that requires state information contained within state 920B, or otherwise the code will not be able to open and use its own security credentials.

Another example of a SDNP last mile secure operation, especially for parallel SDNP payloads used in multi-path last mile communication, is shown in FIG. 9c , where a client's device communicates with multiple SDNP gateways. Like its single-path counterpart described above, such a process involves two directional sequences of actions, one for outgoing data packets and one for incoming data packets. In the case of outgoing data packets, shown in the top half of the figure, the “transmitted data” is first scrambled using packet-scrambling operation 926, followed by deception by insertion of junk data 1053C. In some cases, the entire packet may contain junk data as a whole, further confounding data theft attempts by hackers.

These packets are then split into a number of sub-packets by segmentation operation 1057 using parsing operation 1052 and sent separately to encryption operation 1026. Each fragment is then encrypted using a common or distinct encryption key, and the resulting ciphertext is arranged into multiple SDNP payloads, shown as data packets 1199C, 1199D, and 1199E. Then, in preparation for communication over the last link and last mile, the packet is formatted into separate and segmented IP data packets, i.e. "IP packet ready". All actions performed are dynamic, occurring at specific times or in specific states 920C during the security process execution.

In the case of the received data packets shown in the lower half of the figure, the received data from the last link containing the parallel SDNP payloads 1199F, 1199G, and 1199H, i.e. from "IP Packet Recognition", is first the actual data stream is decrypted in a piecewise manner by decryption operation 1032 and subsequent blending operation 1061 to recover . Then, to recover the "received data", the data packet is de-junked, i.e., the junk data is removed from the data packet, using a de-junk operation 1053D followed by a packet unscrambling operation 928. All operations performed on received data packets use the state 920D that the SDNP gateway used when creating the data packet, i.e., at the time of the packet's birth, including information about a specific time or having a specific state 920D. shall. This state information may be transmitted over different communications by the signaling server, or may be accompanied within received data packets as plaintext or alternatively as static ciphertext, i.e. as ciphertext with a decryption key already known by SDNP last mile security operations. can

SDNP last mile security operations need not use the same algorithm or method on both incoming and outgoing data packets. As illustrated in FIG. 9D, outgoing data packets use SDNP last mile security operation 1190A, while incoming data packets use SDNP last mile security operation 1190B. Referring to the upper half of the figure, outgoing data packets may carry data representing any combination of real-time data sources from transducers or sensors, or may include files created prior to communication. For example, a sound 1198A converted into an electrical signal by the microphone 1180 and a video signal from the camera 1181 are converted into an equivalent digital format by the audio video codec 1182A. The generated formats typically include standards such as png, pic, mpeg, mov, etc. that are interpretable and interoperable with standard devices according to OSI Layer 6, the presentation layer. Using a standard audio video format avoids the need to pass proprietary code to open a file between source and destination addresses.

The digital output of the audio video codec 1182A is then mixed with the text data from the virtual keyboard 1183 (keypad realized on the touch screen) and with the data file 1179A, using the content mixer 1184. . This mixer, in turn, sends the data files to SDNP last mile security operation 1190A and provides SDNP header information to IP packet preparation operation 1191A to identify and label real-time data packets from static files. SDNP last mile security operation 1190A then passes the secure data packet to IP packet preparation operation 1191A, which then, according to routing instructions received by SDNP signaling server 1603, converts the SDNP payload to IP Embedding into data packets. A data packet can be distributed into multiple IP packets for multi-path last mile communication, or can be concatenated into a serial data string and embedded and fit into one or more serial data packets for single path last mile communication. These packets are then forwarded to client PHY operation 1192A to append layer 1 and layer 2 data to complete the IP data packets.

In the reverse operation shown in the lower half of the figure, the received data from the last link received by client PHY 1192B is passed to IP packet recognition operation 1191B, which passes the received data as a valid message or unknown and possible Identifies it as a malicious data packet. Valid messages are identified using SDNP tags, seeds, keys, and other identifiers previously communicated by signaling server 1603 to client devices and to IP packet recognition operation 1191B.

Depending on the personification, IP packet recognition operation 1191B expects and even expects valid received data packets. Unexpected data packets that do not have proper identification are discarded and never opened or processed further. In this way, the hacker cannot disguise himself and send valid data to any SDNP node without first registering his identity in the SDNP cloud.

IP packet recognition operation 1191B passes valid data packets to SDNP last mile security operation 1190B, which in turn contains the actual content of the data packets - a serially arranged mix of video, audio, text, and data files. - Performs all necessary operations to reconstruct the data. Then followed by content demultiplex 1193, which is a demultiplexer that undoes the blending operation used in data packet generation, e.g. is used to separate different file types. The output of content demultiplex 1193 includes text shown displayed in messenger window 1196, data file 1179A, and real-time data transmitted to audio video codec 1182B. An audio video codec 1182B converts the digital presentation layer data into a live video image 1195 or through a speaker 1194 to sound 1198B.

For last mile data transmission, data must be embedded or wrapped in a multi-layered arrangement as shown in FIG. 9E, similar to the traditional Russian nested doll model described above. Accordingly, SDNP payload 438 represents transport payload 437, which includes IP payload 435 along with transport header 436. The combination of IP payload 435 and IP header 434 represents an IP datagram, equivalent to MAC payload 432. Wrapping the MAC payload 432 within a MAC header 431 and a MAC footer 433 results in a MAC "frame", such a frame as an electrical signal, light, radio wave, or microwave. Equivalent to the physical layer 490, also known as PHY layer 1 content, which includes physical media.

In SDNP routing, the MAC header 431 in layer 2 describes the MAC connection for the last link, that is, the connection between the client device and the first device in the last mile link. Header 434 in layer 3, by using the source and destination addresses of the client device and SDNP gateway, specifies the endpoint of the routing over the last mile. However, since the last mile is not part of the SDNP cloud, the exact path a data packet takes across the last mile cannot be explicitly described or controlled. In SDNP last mile communication, transport header 436 in Layer 4 is used for SDNP real-time payload, and also ad hoc assigned SDNP port address used in each packet - changes dynamically to prevent port query cyber-attack strategy Address to be - is specified.

The SDNP payload 438, which is the payload of the last mile IP packet, includes the SDNP preamble 1198, which contains zone information, a key, and a seed, and SDNP data, which is a serial string of multiple segments of independently encrypted ciphertext. field 1199A. The decrypted form of the ciphertext includes plaintext files 1197A, 1997B, and 1197C, each of which has its own specific SDNP header, and corresponding data files data 91, data 92, and data 93 ) includes each. Individual sub-headers contain information with tag, home, address, urgency, and QoS data as applicable.

The roles of the SDNP preamble and header vary depending on the command and control method used. In a three-party last mile communication, the signaling server instructs the client device and the SDNP gateway or gateways how to communicate with each other to make a call, send a file, or open a session. Thus, instructions are communicated to both devices using command and control data packets with TCP transmissions before sending any media data packets. Thus, the minimum data required in last mile communication between a client and an SDNP gateway is a tag or address used to identify received packets. In some cases, for example if the signaling server is unreachable, in an alternative embodiment, the SDNP data packet may carry additional data within its preamble and packet header.

The data packet shown in FIG. 9F and accompanying table 1177 depicts one exemplary format used to carry SDNP information within SDNP payload 438. The data packet includes an SDNP preamble 1198 and one to eight data field headers 1178X with its corresponding data field "data X field". Each data field, such as "Data 1 field", "Data 2 field", etc., is preceded by its corresponding header (Hdr 1, Hdr 2, etc.) accompanies the content. The number of data fields can vary between 1 and 8 as determined by the 4b length field #, i.e. binary 0001 to binary 1111. The length of the SDNP preamble 1198 and SDNP payload 438 is affected by the field # specification. If only one field is selected, i.e. if field # = 0001 binary, the SDNP preamble 1198 will contain only L Fld 1 (L Fld 2 to L Fld 8 will be removed) and the SDNP payload ( 438) will contain only the Hdr 1 and Data 1 fields. If a maximum of 8 fields is selected, i.e. if field # = 1111 binary digits, the SDNP preamble 1198 will contain 8 length specifications (L field 1 to L field 8), and the SDNP payload 438 will be , Hdr 1, Data 1 field, Hdr 2, Data 2 field, ...Hdr 8, Data 8 field, and will contain 8 data fields and a header. As shown, the SDNP preamble 1198 includes field length specifications (L Fld 1, L Fld 2 and L Fld 8). A small gap between L Fld 2 and L Fld 8 is meant to indicate sequence continuation, and does not indicate a gap in the data.

The length of each data field specified by L Fld X can vary from 0 or 0B (no data field) to a maximum hexadecimal length of FFFF or 65,535B. For practical reasons related to compatibility with Ethernet, the maximum data packet length for any one field is preferably limited to 1500B or 05DC hex, and the total length of all data fields is 9000B, or a jumbo packet size of 2328 hex. should not exceed The specified length of each data field can be changed independently. For example, L Fld 8 = 0000 hexadecimal, a field length of 0 results in the removal of the corresponding data 8 field, but does not remove the corresponding header (Hdr 8). Headers are removed only by field # specification.

According to this SDNP protocol, the allocation of content across various data fields is very flexible. Data directed to a single destination may be contained within a single data field, or may be split into multiple data fields for deceptive purposes and merged with junk data. The size of the data fields can vary independently. A data field containing only junk data may also be included, or alternatively an entire data packet containing only junk data may be generated. However, for efficient packet routing, data targeting different destinations must be partitioned into separate data fields, each with its own specific header.

The SDNP packet format can be applied for end-to-end transport across the entire SDNP network, including spanning multiple clouds and zones, such as in SDNP cloud or last mile communications. Although the contents of SDNP data packets change as they traverse the network, the SDNP packet format remains unchanged. Since this format includes minimal data overhead, the SDNP data packet format is equally applicable for large payloads or for time-critical real-time communications. The packet format is cloud-specific for bi-directional data flow, i.e., for data flow from the last mile to the SDNP gateway and across the SDNP cloud, or conversely, exiting the SDNP gateway for transmission across the last mile to the destination client device. It can be applied to deliver data packets generated from

In operation, the direction of SDNP data routing is determined by the network layer 3 source and destination addresses described in IP header 434 of FIG. 9E. At the time a media node prepares a packet for forwarding to the next media node on its path, each packet is loaded with its source and destination addresses, and in tri-channel communication, the SDNP or IP address of the packet's destination is Prior to preparation, it is passed from the signaling server to the media node as a command and control (C&C) packet. In general, a signaling server can send C&C instructions to all nodes in a communication path including both the sending (caller) and destination (called party) devices. In cases where only single channel communication is available, eg on links with long propagation delays, the signaling server cannot forewarn what to do with the media node of the received packet or anything like that. In that case, the routing address is accompanied within the received data packet within the SDNP payload 438. In such cases, the media server follows default instructions on how to process received packets using data fields included in received SDNP packets that contain routing and state information as well as security credentials.

The payload 438 consists of two parts: a readable part containing the preamble 1198, and an unreadable part 1199a containing the data in "cloaked form". The contents of these packets may use any number of obscuration techniques to obscure their contents, such as encryption, scrambling, and possible inclusion of junk data. The concealment method must be undone in order to extract useful content 1197a, 1997b and 1197c. This packet contains the destination address of future outgoing packets. The address only exists in unobscured or decrypted form for only a brief moment before the next packet can be prepared and encrypted.

As described, the SDNP preamble 1198 contains information related to the entire packet. In addition to the data field specifications, FIG. 9F shows SDNP preamble 1198 which also includes the SDNP zone from which the SDNP packet was created, e.g. zone U1, two numeric seeds, and two keys. These keys and seeds can be used as zone specific security credentials in scrambling/unscrambling, junk insertion/removal, mixing/splitting, and encryption/decryption processes. The seed and key may be used as an exclusive means for the delivery of security credentials necessary to open and read data fields, or to a client's device from a network of signaling servers, command and control computers that are not included in accompanying communiqué content within media packets. and command and control packets sent to the SDNP gateway.

The seed and key can be securely communicated in the public, i.e. in non-encrypted form, since the data does not contain the information necessary for its use - they contain only part of the security credential. Other parts of the security credential, lost fragments, may have already been transmitted in other data packets, or may contain shared secrets, look-up tables, and codes of algorithms that are not carried over the network and are not part of the message. The encryption key may be a symmetric key, wherein both the sender and the recipient may hold the key, or may hold the public key, in which case the public, including the sender, may have access to the encryption key, but only the recipient, i.e. Only the party that generates the encryption key holds the decryption key. Additionally, all security credentials are bound to a specific security zone, eg U1, and are dynamic, bound to a specific time or state that expires if not used within a specific time. If the seed and key data fields are not used as security credentials, for example because the Signaling Server independently instructs the SDNP device involved in security operations, these fields can be filled with numerical values that erroneously look like cryptographic keys, allowing cyber-attackers to can misguide you into wasting time analyzing the decoy security key.

In last mile communication, intermediate routers between the client's device and the SDNP gateway do not process, interpret, or open the transmitted data packets, since they are not part of the SDNP network and can query or interpret the SDNP packet data contained within. because they don't have the ability. Instead, all security operations are executed exclusively at the two end points, the SDNP client and the SDNP gateway, since only these devices act as SDNP communication nodes. Because each end point dynamically executes the SDNP protocol, last mile communications are hypersecure throughout the entire last mile. If the other calling party is also running the SDNP software, the second party's last mile is also secured by the aforementioned SDNP method, and hypersecure communications are "end-to-end" - from one caller to another. up to - guaranteed.

However, if the end device is not an SDNP client, the router closest to the caller, i.e., the last link router, may be enabled with the SDNP firmware, and the last link, even if not SDNP based, is implemented by the SDNP based router. It can be reasonably secured from special functions. This alternative last link security method is described in more detail in subsequent sections of this disclosure and will not be discussed in more detail in this section. The described method can be applied to last link communication security, but it is not sufficient to protect other parts of the last mile.

Referring again to FIG. 9F, each and every SDNP data field is accompanied by a SDNP data field header 1178X that contains information specifically applicable to the associated data field but not useful for other data fields. Specifically, in the disclosed embodiment, each header defines what kind of data is contained within the associated data field, a destination address field used to identify a particular data field and its destination, and a forward zone from one zone to another. It contains a data type field that describes the urgency and delivery information, as well as the fields section used to convey the information. As shown, each SDNP data payload 438 includes one SDNP preamble 1198, and one or more SDNP data field headers 1178X and corresponding data x fields, where x is the size of the payload. and the number of separate payloads, which can range from 5 to 50 depending on urgency.

Although the signaling server can supply most of the descriptive information to SDNP clients and SDNP gateways, one basic component necessarily carried by a last mile data packet is the "address field" or tag needed to identify the data packet. The field referred to as the destination address of the SDNP payload (abbreviated "Dest Addr" in the figure) may contain any specific identifier sufficient to distinguish the identity of one data field from another. Its purpose is similar to the function of barcodes used at airports to tag and track bags or boxes shipped by carriers. Address types may include, for example, numeric tags, SDNP collections, IPv4 or IPv6 addresses, NAT addresses, or even POTS regular phone numbers, as long as the identifier is specific enough to avoid collisions in the identification of data packets. have. The size of the destination address field depends on the type of address type selected.

To maintain packet anonymity during routing, it may be desirable to use a secret code, such as an SDNP zip code, as the SDNP destination address instead of a real phone number or IP address. 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 for an identifying destination address. Before the data header can be inspected, the data packet must be decrypted or processed to undo the obscuration method used in the packet's creation. In case of dual-channel or tri-channel communication, as shown in Fig. 9G, Signaling Server 1603 notified the SDNP Gateway in advance of the planned arrival of data packets and their corresponding identification markings and security credentials. Thus, when the SDNP gateway receives the data packet 438A containing the last mile communication sent from the SDNP client, the gateway converts the SDNP payload from the ciphertext into the plaintext data packet 438B, so that the SDNP last mile Security operation 1190D is performed. Security operations describe the processing of modifying outgoing data packets to obscure content and processes and modifying incoming data packets to reveal content.

Specifically, the security operations performed on incoming data packets include using decryption to undo encryption, unscrambling to undo scrambling, dejunking to remove junk insertion, and undo segmentation. It is used to restore its content by undoing any concealment operations performed prior to its transfer, including blending to return to . This process is carried out according to the state and zone of the data packet when it is created. On outgoing data packets, security operations include concealing the contents of the data packet prior to transmission by enforcing encryption, scrambling, junk insertion, and packet fragmentation according to state and zone when the data packet is created. The unencrypted seed and key data fields in data packet 438A may be ignored or optionally used in conjunction with the signaling server information to decrypt the ciphertext. The resulting action illuminates Data Field 1 and its associated Data Field Header 117D, denoted Hdr 1, which contains the Data Field's destination address, data type, urgency and forwarding information. In such a case, the destination address is not a routing address but just an SDNP house, i.e. the tag used to identify the packet is part of the specific conversation.

If a particular data field is found to contain an identified destination address, e.g. SDNP zip code, that matches the indication from signaling server 1603, then the data field is extracted and optionally another by mixer 1184Z. It is mixed with relevant content and then rewrapped into a new IP or SDNP datagram by SDNP packet preparation operation 1191Z for delivery to its destination. A new data packet destined for the cloud includes an SDNP header 434Z, which contains the SDNP payload 435Z, the destination and data content of the new packet. Destinations supplied to gateway media nodes by Signaling Server 1603 as IP addresses or SDNP addresses may include other SDNP servers acting as SDNP cloud nodes, or may include last mile communications to other SDNP clients. In the case of such tri-channel communication, the destination address is not the actual address but a means for identifying the packet, where the next destination is already known by the SDNP gateway. If the packet's destination is for SDNP cloud routing, the data packet is processed by SDNP cloud security operation 1190Z according to the Z1 security credentials for the cloud, not the U1 credentials used in the last mile.

In single channel communication, as shown in Fig. 9h, the signaling server cannot advertise the SDNP gateway prior to the imminent arrival of data packets and their data fields, because (i) there is no signaling server operating on the local network, or (ii) ) the signaling server is temporarily offline, or (iii) the signaling server is too busy and cannot preferentially route packets in time. In such a case, data packet 438A from the SDNP client is required to decrypt the data packet using SDNP last mile secure operation 1190D, which converts ciphertext data packet 438A to plaintext data packet 438B. It must accompany the security credential section (U1), seed 1, seed 2, key 1 and key 2. The standard SDNP data packet format preserves these data fields even if the contents of the fields are not required by a particular media node. For example, if the particular obscuration process used to create the data packet does not use the Key 2 field, then the data in that field is meaningless and not used by the destination node. Nonetheless, data packets reserve the same number of bytes for used or unused fields, so that all SDNP data packets are in a homogeneous format. Once decrypting the ciphertext in data packet 438A, the SDNP gateway extracts the contents of the data packet data 1 field and its associated Hdr 1 field header 1178D from plaintext data packet 438B. From these data packets, the IP packet recognition process 1191D operates for two reasons - firstly to check if a received packet is expected in triple-channel communication, and secondly to generate a new SDNP address - Combine the data fields for type A and destination address from the Hdr 1 field header 1178D with . This new SDNP address is combined with the D type, urgency and delivery fields, and processed by SDNP packet preparation operation 1191Z to generate SDNP header 434Z within the outgoing data packet. The contents of the Data 1 field are also extracted from the received plaintext data packet 438B, and the contents are optionally mixed 1184Z with other outgoing content to create the outgoing SDNP payload 435Z. The packet is then processed by the SDNP cloud security 1190Z in preparation for forwarding. In this way, the address field performs multiple functions: to identify incoming data packets and, if necessary, to provide a forwarding address.

If the media node receives a data packet without first receiving instructions from the signaling server, the media node will revert to default instructions on how to process the incoming data packet and how to prepare the outgoing data packet. In case the media node does not have any instructions on how to handle unannounced received packets, the data packets will be discarded. If the media node is enabled with instructions on how to process unidentified packets, the media node will first check if the packet is a valid SDNP packet according to the security credentials and process it accordingly. However, if the sender cannot be identified, for example if the encryption code, seed, or source address is invalid, the packet will be discarded as a forgery.

Referring again to FIG. 9F , packet fields marked “Field Zone” describe the zone in which the particular field was created, i.e. whether past encryption or scrambling was done with eg U1 or U2 zoning. In the case of a nested security protocol or other nested obscuration method, it requires additional information, such as a key, seed, time or state, to undo the unscramble, decryption, or obscuration of data packets, in which case " Packet fields marked “field other” may be used to convey field-specific information. Generally, these fields are not used, except in nested security protocols, for example, where the encrypted data fields are then scrambled or encrypted a second time. Care must be taken when using nested security methods to perform data restoration in the exact reverse order of preparation of the data packets, or the content will be lost forever.

Packet fields marked "Data Type", when used, do not require real-time communication from data packets containing time-sensitive information such as voice and live video, context-specific routing, distinct data, pre- It facilitates recorded video, text and computer files, ie distinguishes real-time routing from non-real-time data. Data types include voice, text, real-time video, data, software, and more.

Packet fields marked "urgency" and "delivery" are used together to determine how best to route data in a particular data field. Urgency includes snail, normal, priority, and urgent classifications. Delivery includes various QoS markers for general, redundant, special, and VIP classification. In one embodiment of the present invention, the binary size of the various data fields as shown in table 1177 are chosen to minimize the required communications bandwidth. For example, the data fields as shown can range from 0 to 200B, whereby 8 data fields of 200B per data field means that an SDNP packet can carry 1,600B of data.

Both Figures 9g and 9h show the case where the client device transmits a data packet to the gateway node via the last mile in zone U1. The gateway node then processes the incoming data packets to undo the last mile security using the zone U1 security credentials and the concealment method used. The gateway node will then mix the contents of the packet with the contents of other packets in a mixing process 1184Z to create a new packet (or packets) for transmission through the SDNP cloud using the security credentials of zone Z1. can

A similar process is used when the SDNP gateway receives data packets from the cloud and sends data packets to the client device, e.g., from the SDNP cloud for the client's phone (called party). As shown in FIG. 9I, the dual-channel or triple-channel communication signaling server 2603 notified the SDNP gateway in advance of the planned arrival of data packets coming from the cloud and their corresponding identification marking and security credentials. Accordingly, when the SDNP gateway receives data packet 2438A from the SDNP cloud, the gateway performs SDNP cloud security operation 2190D to convert the SDNP payload from the ciphertext into plain text data packet 2438B. . The unencrypted seed and key data fields in data packet 2438 A may be ignored or optionally used in conjunction with the signaling server information to decrypt the ciphertext. The use of the data field depends on the algorithm used in concealing the payload of the packet. For example, if encryption is not used, the field containing the encryption key is ignored.

The resulting operation extracts a large number of data fields. Subsequent operations segment these data fields in content-segmentation operation 2184Z to extract specific content including data field 1 and its associated data field header 2117D, denoted Hdr 1, using recognition operation 2191D. . The header (Hdr 1) contains the destination address, data type, urgency, and delivery information of the data field. The extracted data fields are then re-wrapped into new IP or SDNP datagrams by SDNP packet preparation operation 1191Z for forwarding to the next destination. A new data packet destined for the cloud contains an SDNP header 2434Z, which contains the SDNP payload 2435Z, the new packet's destination (IP address corresponding to the person's phone number) and data content. Egress packets are then processed by the SDNP last mile security operation 2190Z according to the U1 security credentials for the last mile rather than the Z1 credentials used in the cloud.

If the signaling server is not available, i.e. in single-channel communication, the media node must process the received data packet using the previously communicated indication as the default indication. In such a situation, the incoming data packet is checked against criteria necessary to confirm that the sender is a valid SDNP client (such as an SDNP zip code or authentication code previously delivered as a predetermined shared secret). If the packet is determined to be valid, the packet is processed according to the default instructions. Otherwise, the packet is discarded.

The foregoing methods are illustrative and are not intended to limit the processing and routing of data packets to a particular data packet format.

Security and privacy in communications

An important consideration in last mile communication is the ability of the network to support both secure and private communication. Although privacy and security are often related, they are not the same thing. Security, as the term is used in communications, is considered "controls to prevent unauthorized access to communicate data in a recognizable form." Security, however, does not include instances where individuals or agencies have the authority to access or monitor communications.

Privacy is defined as "the state or condition of not being observed or disturbed by others and free from public attention". The legal term for privacy is defined as the right of individuals to control access to their information.

In telecommunications, individuals' privacy rights in their voice calls, video, text, e-mail, personal messaging, etc. vary greatly from country to country. The role of complying with applicable governmental regulations for providing legally valid access to communications is described in subsequent sections. Beyond that, an ideal network and communication system should be able to prevent hacking of communications, that is, be absolutely secure, and ensure that all communications are restricted to those who have the right to know, that is, be private.

When evaluating a network's privacy and security capabilities, the network's last mile and its connected devices should be carefully considered. Depending on the security credentials used to establish information access privileges, the last mile and its connecting devices frequently determine the security and privacy of a network, i.e., the last mile represents the weakest link. Four possible combinations of communication networks have to be considered:

* Secure and private network. From an individual's point of view, this case represents ideal network performance, ensuring both the security of information and privacy for individuals. At these extremes, a truly secure private network is one in which meaningful communications cannot be stolen by any individual, government, agency, or company, and privacy regarding an individual's behavior, actions, contacts and colleagues, his personal preferences and activities, etc. This means that data cannot be obtained. Although privacy rights claims regard the ideal secure private network as the gold standard in confidential communications, governments, security agencies, and corporations view absolute autonomy in communications as problematic, allowing individuals to commit crimes with absolute security and impunity. activity and terrorism.

* Unsecured networks lacking privacy. A network that is not secure and does not have privacy regulations (eg, today's Internet OTT carriers) represents a significant risk to individuals, groups, clubs, companies or governments using the communication channel. Because cyber-hackers can easily access calls and data, any ill-intentioned party can use this information for any purpose they choose. In the case of real jokers and spammers, unsecured communication channels can be ordered to cause confusion, flood networks with spam, initially deny service attacks, and create detrimental repercussions. In the case of ideological adherents, policy activists, and religious cults, unsecured communications can be used to leak sensitive information, which can lead to policy changes, distrust of government officials, incitement to riots, or even the overthrow of governments (e.g., solidaristic interstate riots). See the historical fiction film "The Fifth Estate" (DreamWorks ⓒ 2013), like the WikiLeaks exposure of hundreds of thousands of sensitive government documents that caused a sensation). In the case of organized crime and economically motivated cyber-crime, such as those associated with the mafia, attacks may include financial crimes such as theft, fund diversion, fraud, identity theft, money laundering, extortion, blackmail, and other felonies. focus on To plan and commit a violent crime, such as an attack, kidnapping, murder, bombing, or act of terrorism, in the case of persons involved in fear and intimidation, such as drug cartels, gangs, and terrorists, their competitors, enemies, and target victims; Unsecured communications can be monitored to track the location, movement, and behavior of Finally, in the case of a cyber-attack on an individual, using unsecured communications, an individual's private information, including social security numbers, passports, banking information, credit card information, medical records, and other personal confidential information, may be captured. The database can be illegally hacked.

* Secure network with no privacy. An example of a secure network lacking privacy is usually the right and authority for information technology (IT) managers or security departments to monitor all corporate communications to ensure that inappropriate or illegal communications do not occur across the corporate network. Branches include company accounts. Although networks are secure from hackers and cyber-crimes, communications on such networks are not private, and unauthorized personal use of corporate communications infrastructure, corporate espionage, breaches of confidentiality agreements, unauthorized disclosure of intellectual property (IP leaks), Detect misconduct including sexual harassment, violations of Fair Disclosure Rules (registered FDs), insider trading, violations of the Foreign Corrupt Practices Act (FCPA), bribery, bribery, fraud, financial reporting violations, security breaches, and others It can be monitored by an authorized agent to do so. In corporate communications, the individual is notified upon entry that the individual's corporate communications are not private and may be monitored, including corporate phone calls, emails, texts, personal messaging and SMS, and other communications. In the case of court precedents, their communiques, whether civil or criminal, may also be subpoenaed in court and presented as evidence, even if personal information is mixed with company information. Essentially, when a company's employees use company communications, devices, and networks for personal use (except in the case of agent-client privilege), all information must be made impartial and not considered private. For these and other reasons, the mixed use of personal messengers such as Line and KakaoTalk for business and personal use is particularly problematic, as employees have privacy rights that can prevent scrutiny of their text chats, photos, and files. Because you can't claim it.

* Semi-private, unsecured networks. A quasi-private insecure network is one in which private transactions can be conducted in secret, even if the network carrying the data is hacked, eg wire tapped, but the lack of security provided certain conditions are met. In this way, privacy is established by verifying the identity of the caller (or callers) by various means using a shared secret, which cannot be exposed even by a hacker who intercepts the call. A common example of private unsecured communications is voice banking transactions. The caller asks a series of ever-changing questions that the scammer may have difficulty answering, such as "I know you had dinner last night and paid with our credit card. Can you tell us what city you had dinner in?" Can you?" or "You get regular bills from a winery. Which winery?" Another example question is "Can you tell me the last name of your favorite elementary school teacher?" In these identification methods for operation, the bank has access to non-public information (such as credit card statements) or the bank and its clients, generally electronically and in person, when an account is first created, share a secret You have to build a set. In the case of a verified identity of the caller, the client may instruct the authority to take certain actions that may not be advantageous to cybercriminals. For example, "Move $10,000 from my savings into my checking account." However, when the money is transferred to another bank, stricter authentication must be performed to ensure the privacy of the client. In any case, privacy relies on fulfillment of the condition that communications cannot electronically or audibly reveal shared secrets, otherwise all privacy is lost and the account may be at risk. Accordingly, such authenticated communications over unsecured lines are referred to as quasi-private, meaning conditional privacy. Another example or quasi-private communication over an unsecured network may be effected by the use of a security token, a bank-issued device owned only by the client. A pseudo-random number generated by the device to the bank operator who verifies that the number matches the bank's authorized number. Since those numbers are 8 or more digits, the chances of guessing the right code the first time are slim. In case an incorrect token number is recorded, the call is terminated, the account is frozen, and the fraud department is alerted to investigate. In any such case, the importance of ensuring privacy across unsecured networks relies on being able to make calls without verbally revealing any confidential details, such as account numbers, PINs, credit card information, etc., i.e. Communication is only quasi-private.

Identity Verification and AAA - The concept of security and privacy relies on accurate and reliable identification, i.e. who the talking party is.

Identification, also known as "authentication", is important in validating the use of data and communications and in preventing illegal or unauthorized access. Reliable identification is important in national security, law enforcement, IP ownership, business enterprises, and individual rights. Examples of the importance of identification include:

* For the national security of a country, caller identification is important in tracking criminals, spies, terrorists, drug traffickers, and anyone else who exposes state secrets or threatens national security. It is equally important to be able to identify authorized individuals for access, reading, or transmission of confidential, secret, or top secret communications, data, and files.

* For law enforcement, caller identification is important in identifying individuals or entities involved in criminal activities such as theft, arson, drug trafficking, smuggling, prostitution and human trafficking, extortion, blackmail, and other felonies. . It is equally important to be able to identify individuals who are certified law enforcement agents, including police, firefighters, paramedics, park sheriffs, air security, TSA and airport security, port authorities, customs, and coast guard services.

* For IP owners, such as movie studios, identification is important in identifying individuals, institutions, and entities involved in privacy and unauthorized distribution of copyrighted subject matter, such as music, films, books, and videos. This is equally important in ensuring valid and lawful distribution of IP and copyrighted subject matter.

* For a business enterprise, the identification of its employees, in tracking the intentional or accidental disclosure of nonpublic material information, in identifying persons involved in commercial espionage, in identifying individuals involved in illegal disclosure of intellectual property, And it is important in identifying people who have committed other crimes, such as fraudulent or personal use of company communications. This is important in verifying the identity of people who may have access to confidential company information, and in particular in authenticating the specific types of data they can access. For example, a company's engineering department should not have access to the marketing department's personal records in order to compare how much marketing employees are paid.

* In the case of individuals, identity verification is important in ensuring the "privacy" of the caller by verifying that the person or persons making the call is not an impostor.

Accordingly, the role of identification is to verify the identity of an individual, i.e., to authenticate that he or she is the person making the claim, and to identify, block, and eventually arrest anyone misrepresenting that identity. Authentication is the first "A" of the Triple-A security model, or AAA stands for "Authorization, Authentication, and Management". Many methods such as PIN codes, passwords, fingerprints, tokens, and challenge and answer methods are used to verify the identity of individuals and to authenticate that they have an account in the system.

Once authenticated, the valid user's identity is used to determine access rights and privileges to communiques, data, files, system operations, etc. These privileges and access rights are collectively referred to as the "authentication" of users as granted by the system, i.e., authenticated users have access only to the communications, data, files and system features for which they have been authorized. Accordingly, authentication is synonymous with "privilege" or "access".

The third "A" in AAA represents management. Management is the bookkeeping of logging authorized access to networks and files, for example, for usage-based billing management and to monitor and record unauthorized access attempts to networks, files, and system operations. Management is also important in tracking changes to security credentials, PINs, passwords, etc. required for authentication operations.

The ability of the network to implement the AAA process takes precedence over ensuring privacy and preventing fraudulent use of the network from unauthenticated users or network operators. Arbitrary networks that cannot guarantee the user's identity can be misused for illegal purposes. Illegal network use by unauthenticated users is an unavoidable problem in OTT communication because there is no means to verify the identity of the caller. Unauthorized access and network communication by unauthorized users, i.e., anonymous persons, is a significant risk in modern communications.

Anonymity - The principle of anonymity in communications is the intentional concealment of the identity of the caller in order to communicate without traceability. An almost iconic example of anonymous communication is payphone. In Payphone calls, payment is made in untraceable cash, Payphone numbers are public, anyone can use such a phone, meaning that the identity of the caller is not known and there is no specific means of determining who the caller is. means there is no Because the phone number is not listed, the individual does not own the number and there is no way to identify the caller's identity (except through sophisticated voice recognition software). In the case of a registered device such as a cell phone, the identity of the owner of the device may be traced through the phone number, but the identity of the caller may still remain unknown. For example, the phone may have been stolen, or a usage-based charging SIM card may be used to hide the true identity of the caller. Alternatively, a laptop, tablet, or cell phone could be connected via WiFi in a public cafe, providing anonymity similar to any public payphone or phone booth.

Some OTT carriers have chosen to operate VoIP phone services, such as Payphone, without subscriber identification. For example, in an online report (http://money.cnn.com/2015/11/17/technology/isis-telegram/), CNN Money says "Telegram is a popular new app among jihadists." announced. According to research, the Telegram application was a tool of ISIS terrorists in their secret plans to attack Paris. In that article, "Telegram's developers were aware that Isis used such apps for communication before the Paris attacks" (http://www.independent.co.uk/life-style/gadgets-and-tech /news/telegram-knew-isis-communicate-paris-pavel-durov-a6742126.html),

Telegram developer Pavel Durov said: 'The right to privacy outweighs our fear of something bad like terrorism happening'.

Another example of privacy and anonymity used in press-reported crimes is that of BitTorrent - an application and data network often used to illegally download and share copyrighted material. In CNN Money Tech's news article titled "50,000 BitTorrent Users Sued for Illegal Downloading" (http://money.cnn.com/201l/06/10/technology/bittorrent_lawsuits/), users , reported to be sued under new anti-privacy laws for illegally downloading the movie "The Hurt Locker" and other copyrighted works. Network operator BitTorrent has taken the payphone position that it is not responsible for those who use the network for personal activities. Free speech advocates support this position, while law enforcement and government, national security, and IP rights advocates abhor this attitude as thoughtless and irresponsible. Irrespective of that policy, discussions about stopping anonymous calls are purely academic, unless telecommunications systems are capable of enforcing caller identification.

Caller identification and authentication includes intellectual property, engineering development, product evaluation, manufacturing know-how, confidential financial reports and projections, business conditions, sales forecasts, inventory and WIP, quality investigations, business and IP contracts, customer lists, employee records, and Controlling access to confidential company data, including other trade secrets, is especially important for corporations and business enterprises. When accessing company communications, the access privileges granted to any employee, contractor, or officer are dependent on their identification. In conference calls involving investor calls, identity verification is important in verifying who is on the call and in ensuring that no one who does not need to know is not listening.

Paradoxically, while caller authentication is used to deter crime and corporate espionage, the same user authentication is advantageously useful in ensuring caller privacy. If both parties in a call or text chat verify their identities through some signed authentication process, the fraudster does not have access to the call or its data, thus protecting the call from criminal attacks.

Finally, a distinction must be made to distinguish anonymous callers from anonymous calls. An anonymous caller is a person who disguises his true identity from the network with which he communicates. However, an anonymous call does not require the caller to have anonymity from the network, only to obfuscate its true identity in call data packets during communication. A registered account holder on the SDNP network, consistent with this disclosure, can place calls or send data using anonymous data, even if the network knows their identity and phone number. In this way, law-abiding citizens can communicate anonymously, without having to hide their identities from SDNP network operators. When callers are involved in general private calls, entertainment, or business, their SDNP calls remain private and secure, even though the network knows their identities as stored in the SDNP name server database.

An example of the need for legal anonymous communication includes global gaming where it is important to protect the identity of the gamer, especially that of children. Another case where anonymity can be beneficial is vehicle-to-vehicle (V2V) communication to protect drivers of reckless driving from harsh retaliation, by identifying other drivers' personal data that aggravates their driving. In contrast, if the caller engages in criminal or other heinous conduct in the communication, law officials may (subject to applicable law) access the call and data transmission. In this way, network operators can satisfy the requirements of court orders and subpoenas without exposing the identities of law-abiding citizens or disclosing their currencies.

In summary, using the disclosed SDNP communication method, only identifiable SDNP subscribers can place an anonymous call. Unidentified callers do not have access to the SDNP network or ability to place anonymous calls.

National Security and Privacy - The nature of secure and private communications becomes more confusing when the role of government and laws are considered. All countries claim their sovereignty to control communications within their borders. However, with the advent of the Internet and dynamically routed packet-switched data networks, network surveillance and monitoring faces many technical and legal challenges. One concern is monitoring server-to-server networks "through" traffic - data packets traversing the country uninterrupted. Because Internet traffic is dynamically routed, network operators are not interested in what data packets the server's network carries. Of course, any country can intercept and decode this surrogate big data, but due to encryption, access without knowing the encryption key is difficult, especially for real-time monitoring. And since the caller may not reside within the country, a particular country does not have jurisdiction to subpoena or require the encryption key used to locate the currency. Such network transit-data is analogous to radio wave traffic traversing the earth's atmosphere. Even if radio waves pass through, there is no practical way to stop them. Similarly, there is no practical way to stop network pass-through data traffic other than completely isolating the country's infrastructure from the Internet.

A more pragmatic solution for controlling communications is to focus on monitoring last mile communications, that is, to intercept and monitor calls and call data when the source and/or destination of the call originates within the borders of a country. This approach means that (i) the size of the data is smaller, i.e. more manageable for analysis, (ii) the last mile carrier or network operator is subject to the laws of the country of residence; (iii) that the last mile carrier or network operator may be subpoenaed for provision of any available encryption key; (iv) that the caller's device itself must be electronically "registered" in order to connect to the last mile network; and Doing so passes information about the caller, and (v) large amounts of pass-data, including that the location of any network connected device can be determined using network addresses, GPS data, or radio signal triangulation. It has several advantages over traffic.

Aside from the legal and technical challenges associated with enforcing network pass-through data regulations, laws governing last-mile communications and call termination are, as a whole, a right of the countries where last-mile network operators reside. Depending on national privacy laws, national controls may enforce the level of access required for last mile communications, including combinations of:

* No right to monitor any data or calls without a court subpoena based on the cause of the problem. By court order, the right to confidentially monitor any call or data communication.

* Right to monitor metadata of any currency, without court order.

* Right to monitor all calls and data communications, without court order.

* The right to intercept, monitor and, as necessary, intercept any and all communications.

For example, various governments, such as the United States, have taken the position of holding the right to monitor the "metadata" of a currency without a court order. Metadata includes data packet information related to who is talking to whom, how long the call was, where the caller was located during the call, and the like, without actually accessing the call data itself. Essentially, metadata includes the data header of an IP packet, but not its payload. In contrast, monitoring of calls and data communications involves access to header data as well as the payload itself. In those cases where the payload can be encrypted, the government can insist on providing the master encryption key (if any) to the network operator. One issue raised by privacy advocates is the government's abuse of power. Specifically, where a network relies on a set of master encryption keys, giving up these keys in response to a court order to enable government surveillance of specific individuals, even if the court order is limited to individuals or groups, , but it allows the government to monitor all currencies. This issue is often referred to as the question of "Who should be the police for the police?" Another consideration concerns the privacy rights of individuals placing international currencies. In such a case, the caller should be aware that the relevant laws for government access vary depending on the location of both parties, i.e. where the two last mile networks originate. Calls from the United States to China will be subject to US law to callers in the United States and Chinese laws to callers within China. In such circumstances, currency access by one government may be greater than the other. Thus, callers in countries with greater privacy rights can consider their privacy being violated by the governments of other countries, but cannot complain because they are calling countries that do not have a legal basis.

In the case of communications using the previously disclosed secure dynamic telephony networks and protocols, it is virtually impossible to intercept pass-through data in hypersecure cloud communications of fragmented, scrambled and dynamically encrypted data packets transmitted anonymously across the SDNP network. Thus, the privacy and security of hypersecure calls are determined by the device and the last mile communication. By adapting the disclosed SDNP method to last mile communication, last mile capable of hypersecure communication and great-integrity privacy can be realized as disclosed herein.

Also disclosed is a mechanism to adjust the security and privacy settings of the SDNP network to accommodate regional laws governing last mile communications for each country. These methods include safeguards that do not expose call data to hackers and cyber-criminals, and allow authorized security authorities to monitor communications in accordance with law and court order. Thus, in the hypersecure last mile communications disclosed herein, the use of a "back door" vulnerable to cyber-attacks is not utilized.

Hyper secure last mile communication method and device

To ensure end-to-end hypersecurity, the application of the previously disclosed method for routing encrypted and scrambled anonymous fragmented data packets within the SDNP cloud should be similarly configured for last-mile communication. Ensuring last mile communication is particularly problematic, as data may be carried on networks not hosted by SDNP operators, packet routing may include conventional IP packet routing, and the inherent nature of last mile networks may be This is because security can be unknowingly compromised by cybercriminals, possibly with the complicity of last mile network operators.

In accordance with the present invention, last mile communication essentially involves the transmission of IP datagrams outside the data cloud network using a different packet format than the data packets within the SDNP cloud. As shown in FIG. 10 , an SDNP cloud containing a server 1201 (represented schematically by soft-switch based SDNP nodes M _0,0 to M _0,f ) includes exemplary data packets 1222B and 1222C. , and 1222F) to transmit VoIP, video, text, and data using SDNP datagrams. SDNP datagrams contain SDNP Layer 3 source and destination addresses, but do not contain Internet IP addresses. SDNP addresses differ from IP addresses in that they can only be recognized by SDNP name servers or other servers that perform the functions of SDNP name servers, and not by DNS name servers on the Internet.

As described in the aforementioned US application Ser. No. 14/803,869, SDNP packets change dynamically as they travel through the network, with routing addresses updated according to shared secrets and dynamic "states" (such as time). and a continuous change of the payload is performed. For example, data packet 1222B transmitted by node M _0,0 includes a layer 3 SDNP datagram (B) with a specific SDNP address and a specific encrypted payload. Downstream, data packet 1222C output from node M _0,1 contains a layer 3 SDNP datagram (C) with a different SDNP address and re-encrypted payload. After a few tens of milliseconds, the same payload arrives at node M _0,f , which processes the data and forwards data packet 1223G containing IP datagram G over the last mile.

Since the change is implemented according to the prescribed state, the original packet data can be restored by carrying out a series of inverse operations executed in the reverse order to those in which they were performed. For example, an SDNP functional sequence comprising the steps of scrambling, inserting junk (deception), and encrypting, if the same state used for executing the function is implemented to implement the corresponding inverse function, decrypts the reverse sequence, removes junk, and It can be returned to its original state by unscrambling. State data for a packet may be embedded within the packet's payload and accompanied as a time, seed, or key, or may be pre-sent in the packet. Data transmission and processing within the SDNP cloud is operated using SDNP cloud specific shared secrets and security credentials. Media nodes that share a common set of shared secrets and security credentials may be referred to as a secure "zone". Areas used for secure credentials operated within the SDNP cloud cannot be exposed to any user communication outside the SDNP cloud. Therefore, all last mile communications must include SDNP security zones that are different from SDNP clouds.

In the illustrated example, server 1201A and server 1201F hosting the corresponding nodes M _0,0 to M _0,f act as SDNP gateways, ie they are devices outside the SDNP cloud as well as SDNP in other clouds. communicate with the node.

Communications from these gateways to communication devices outside the cloud represent “last mile” communications. Thus, gateway nodes must understand the area security credentials of both the SDNP cloud and the last mile network to which they connect, and act as translators during packet routing. Semantically, the term last mile is an abstract concept meaning communication outside the SDNP cloud, and does not specifically refer to a distance of one mile. Instead, the term last mile includes any communication between a client device at any distance and the SDNP cloud, ie operating SDNP application software or firmware, regardless of whether the client device is operating as an SDNP client. or not

The term last mile also applies to both the client device initiating the call and the client device being called. Literally speaking, the caller's data represents the "first mile" of the call, instead of the last - the distinction between the first mile and the last mile is arbitrary. Specifically, in any duplex conversion or in any IP communication “session,” the device receiving the call essentially responds to the call or session request by sending a response to the calling party. In any two-way communication, the first mile connection therefore necessarily serves as the last mile in the response data path. Essentially, the first mile for the caller is at the same time the last mile for the answerer. Accordingly, the defined term last mile is used throughout this application to mean both the first mile and the last mile, regardless of which device initiated the call or communication session.

Communication outside the SDNP cloud to any device other than the SDNP client is essentially done using IP datagrams and not by means of SDNP IP datagrams. For example, referring again to FIG. 10, data packet 1223A includes an "IP datagram (A)" constructed using an SDNP payload that has an IP address, but not an SDNP address. Similarly, IP datagram G includes data packet 1223G containing SDNP payloads routed using the IP address. The IP source and destination addresses represent any IPv4 or IPv6 addresses that can be recognized by the network through which routing is taking place. The IP address may include an Internet address recognized by a DNS server of the Internet, or alternatively may include a NAT address used for routing across a local network established by a local network service provider.

Because the hardware and firmware used in last mile communications can vary considerably and can include telephone lines, fiber communications, cable TV networks, 3G and 4G wireless networks, microwave communications towers, and satellites, an analysis of last mile communications will: Consideration must be given to the various layer 1 physical networks used and their corresponding layer 2 data link formats. Formats may include, for example, analog (POTS), Ethernet, WiFi, 3G, 4G/LTE, and DOCSIS3. The corresponding security and privacy capabilities of each last mile implementation are considered on a case-by-case basis in the section below on SDNP “call out” communications.

SDNP Call Out Over Unsecured Lines - As a term in the art , any call leaving a regulatory network transmitted across a separate (and usually different) network is commonly referred to as a "call out". , which means that data or voice leaves one network to be transmitted to another network. For example, while communication between clients running the Skype application is commonly referred to as a Skype call, placing a call from a Skype client to a regular or mobile number is referred to as a Skype call out feature, or "Skype out" call. do. Calling out to a regular phone usually involves some additional cost, either as a subscription fee or as usage-based billing.

In the context of this disclosure, communication from the SDNP cloud over an unsecured last mile connection to any device other than an SDNP client is referred to herein by the defined term "SDNP call out". Figure 11 schematically shows two examples of SDNP call outs routed on the unsecured last mile. In the upper example, communication is made to an analog device such as a telephone or payphone 6A using an analog signal. In such a case, the SDNP gateway must include a digital-to-analog converter. If not, a modem or conversion device may be added to the gateway. Information is carried by analog signal 1221, not by data packets. Analog telephone signals, while effective for carrying voice, are not suitable for high-speed data communication.

In the bottom case, the SDNP call out is generated over the digital network to a digital device (e.g., cell phone 32) that is not enabled as a SDNP client, i.e., is not enabled with SDNP software or firmware. . In such a case, data packet 1223 carries a call or data, generally using an IP packet format according to the Internet Protocol, i.e., the 7-layer OSI model. An IP datagram contains IP or NAT addresses within its source and destination address fields, and IP or VoIP data as its payload. The digital conduit may contain various forms of digital data, such as Ethernet, WiFi, or 4G/LTE depending on the last mile connection.

In one example schematic, as last mile communication data is carried outside the SDNP network through an unsecured communication channel or network, the call is unsecured and exposed to hacking, spying, wire tapping, and other cyber attacks. As described in the background section of this application, unsecured lines and connections for the last mile, whether over twisted-pair copper wire, coaxial cable, fiber, Ethernet, WiFi, cellular, or satellite, require special security methods such as encryption to end- Unless embedded within the two-end data path, it is inherently insecure. The security of the most secure data cloud or VPN is thus compromised by the weakest link - in this example, the last mile. Even encryption does not guarantee security, especially in one well-formed electrical, microwave, or radio wave connection. In addition to the lack of security, the schematic example does not include any mechanisms for identity verification. In the absence of authentication, the last mile does not guarantee privacy. Accordingly, the exemplary schematic depicts an unsecured last mile network lacking caller privacy.

Figure 12 shows SDNP executing SDNP call outs for unsecured last mile lack privacy, connecting to a public switched telephone network or PSTN gateway 1A over a digital network service provider NSP hosted wired or fiber link 24. Gateway 1201A is shown. The PSTN gateway 1A is then routed via an analog communication connection 4 to a common prior art telephone system (POTS) switch 3. The POTS switch 3 then places a normal telephone call to the home telephone 6, to the wireless telephone system 5, or to the pay phone 6A via the twisted pair copper wire 7. The entire last mile is neither private nor secure. Although the communication of data packet 1222A containing SDNP datagram (A) uses SDNP addressing and SDNP payload within the SDNP network, the benefits are lost if the data enters last mile hypersecurity. For example, data packet 1223B containing IP datagram B carried by NSP network hosted wired or fiber link 24 uses normal IP addressing recognizable by Internet DNS servers and uses any contains a typical IP payload that can be sniffed by cyber-pirates of Analog lines 4 and 7 are equally vulnerable because they carry simple analog audio signals as analog call data 1221. Although SDNP gateways can support non-secure non-private call outs, SDNP secure calls are misdirected to connect to non-secure last mile networks that lack privacy support.

Using identification, some improvement over the unsecured last mile implementation described above can be achieved. Figure 13 schematically illustrates an example SDNP call out routed on the last mile unsecured but with two different types of authentication. The upper example shows a SDNP call out from the SDNP gateway 1220A to the business office desktop phone 9 via analog or POTS. As shown, operator 1225 passively performs authentication, confirming the identity of the account holder and verifying its account ID. Although authenticated, the call carried by the analog sound 1221 is unsecured and private only if no secrets or account information are voiced in the conversation, i.e., if no secrets are exposed, then the information is private, is exposed, the communication is no longer private. Accordingly, the term quasi-private is used herein to refer to an authenticated call over an unsecured line, i.e., a conditionally private call.

The lower schematic shows SDNP call outs from SDNP gateway 1220A onto the unsecured digital last mile. Data conveyed by IP datagram 1223 to an electronic device, such as desktop PC 36, is unsecured, but may be authenticated using an electronic identity verification method, such as token 1226, to which a cyber-attacker has no access. can Because the line is unsecured and can be sniffed, care must be taken in the digital dialog not to reveal account numbers or secret data.

Specific examples of quasi-private unsecured calls are shown in several examples below. In Fig. 14, an unidentified, unsecured last mile communication is shown between the SDNP network and an office desktop phone 9, e.g., the private banker's phone. The account holder's call may be routed internationally using hypersecure communications within the SDNP network, for example if making an international call, and finally connected to the last mile as an SDNP call out through the SDNP gateway 1201A. The long-distance portion of the call is generated using a dynamically changing SDNP datagram, such as data packet 1222A containing an SDNP datagram (A) with an SDNP payload. Data packet 1222A is then converted by SDNP gateway 1201A from SDNP datagram (A) to IP datagram (B) shown by data packet 1223B. Unlike SDNP datagrams (A), IP datagrams (B) contain sniffable IP payloads. Data packets 1223B are transmitted to the public switched telephone network or PSTN gateway 1A by an operating wire or fiber link 24 to a network service provider (NSP). Again, this gateway is connected to the company switchboard 8A via POTS line 4 carrying analog call 1221. The company switchboard 8A is connected to the desktop phone 9 via an analog private branch exchange or to the desktop phone 9 via a PBX line 7A and also to the personal authentication operator 1225. During the call, the account holder contacts the private banker on the desktop phone 9, but before being able to initiate any transaction agreement, the personal authentication operator 1225 joins the call, verifies the identity of the caller, and After leaving the call, the privacy of the caller is thereby maintained. However, since calls are not secure, private bankers and account holders alike must take care not to voice confidential information such as account numbers, passwords, or PINs. Thus, the call is quasi-private, ie conditionally private.

In FIG. 15 , an unsecured last mile communication is shown between an SDNP network and a desktop computer 36 . In a digital communication session, desktop computer 36 communicates to SDNP gateway 1201A using IP datagrams (B) carried over some digital medium. In the first leg, Ethernet 106A carries data packet 1223D containing IP datagram B from desktop computer 36 to Ethernet-based local router 27B. The Ethernet local router communicates to the network router 27 over an Internet Service Provider (ISP) wired or fiber link 24 using data packets 1223C, which in turn contain IP datagrams (B). Network service provider line (NSP) operating wired or fiber link 24 transmits data packet 1223B containing IP datagram B on the last leg of the last mile between network router 27 and SDNP gateway 1201A. carry Since IP datagrams are used, the last mile is insecure. Digital methods for identity verification, such as login window 1227 and security token 1228, can be used for authentication to ensure communications remain semi-private. These digital certificates should be limited to a single use to prevent use by fraudsters. For example, if a token generates a number and it is used to gain access, the combination is no longer valid for that use, and if a hacker intercepts the token, the token is useless because it expires. because it is no longer valid.

Another example of non-secure last mile communication with identity-verified is shown in FIG. 16 , where SDNP gateway 1201A communicates with point of sale (POS) terminal 38 and gas pump POS terminal 38A as SDNP call outs. do. The last mile communication as shown is a mixture of digital and analog connections involving NSP wired or fiber links 24 carrying data packets 1223B containing IP datagrams B to network routers 27; Wired or fiber link 24A then carries IP datagram B within data packet 1223C, and POTS or analog line 30B connects point of sale (POS) terminal 38 and gas pump POS terminal 38A. ), which carries digital PCM (Pulse Code Modulation) data. Authentication in financial transactions is based on bank card data 1229, which may include electronic authentication based on smartcard integrated circuitry, and may be by means of a dynamic PIN 1228. Authentication involves verifying with a financial institution 1230 connected to the SDNP network through the SDNP gateway 1201A or other last mile.

Hypersecure Last Mile Communication - By adapting the technology of secure dynamic communications networks and protocols, hypersecure communications can be achieved via the last mile. To facilitate hypersecurity, connected devices must run SDNP code as "SDNP clients". The SDNP client contains operational instructions, shared secrets, and SDNP connectivity information hosted on the connected communication device. SDNP clients may include software running on an operating system, firmware running on a microcontroller or programmable IC, or within dedicated hardware or integrated circuits. 17 schematically illustrates an exemplary hypersecure communication over the last mile using “SDNP Connection”. As shown, SDNP gateway 1201A is connected to a device running an SDNP client, in this example SDNP app 1335 running on desktop computer 36. SDNP clients are hardware and operating system specific. In mobile devices, separate apps are required for the different mobile device platforms using Android, iOS, and Windows Mobile. Similarly, separate OS-specific applications are required for notebooks, desktop PCs, and servers, including Windows 10, MacOS, Unix and Linux, and the like. Hardware hosting of SDNP clients in devices that do not have a higher level operating system, such as POS terminals, hotspots, IoT, etc., must be adapted to the programmable device executing the code. Programmable integrated circuits often require programming in chip-specific development environments specific to the IC's vendor, eg Qualcomm, Broadcom, Intel, AMD, NVidia, Microchip, etc.

Since SDNP Gateway 1201A and SDNP App 1335 communicate using SDNP payload 1222, the caller identity and call payload cannot be understood from packet sniffing, specifically SDNP payload 1222 It contains source and destination SDNP pseudo-addresses that are not recognized by the DNS server, and the payload contains SDNP data that can be scrambled, fragmented, mixed with junk data inserts, and dynamically encrypted. The SDNP payload 1222 is embedded within the IP datagram 1223, which uses, instead of the SDNP address, the IP address or NAT address of the cellular, cable or ISP carrier's network used for last mile connectivity to obtain the last mile. Orient routing across

Another aspect of SDNP-based hypersecure last communication is that any SDNP client can inherently do authentication and identity verification. As such, the privacy feature is not based on the network's ability to achieve privacy to support AAA, but on whether the client software or firmware is designed to facilitate the authentication process. It should be understood that the hypersecure last mile example below applies to both private and non-private secure communications, since any hypersecure last mile is identifiable. Unlike insecure last mile networks, which thus have quasi-privacy characteristics, private communications across the hypersecure last mile are determined by the SDNP client, not the network, and any degree of single-factor or multiple-factor desired by the client. It can support factor authentication process.

Specific examples of hypersecure calls are shown in several examples below. In FIG. 18, hypersecure last mile communication is shown between an SDNP network and various cellular mobile devices having a WiFi last link. As shown, data packet 1222A containing SDNP datagram A and containing SDNP payload is received by SDNP gateway 1201A for last mile communication as an IP datagram also containing SDNP payload. (B) is converted to data packet 1223B containing. The SDNP payload in IP datagram (B) is the SDNP datagram because the hypersecure last mile uses a different shared secret, numerical seed, encryption key, and other zone-specific security credentials instead of using the SDNP cloud. It differs from the SDNP payload in (A). In other words, the SDNP gateway 1201A, by changing the payload from one secure zone to another, and embedding the SDNP routing information as a source and address SDNP address that cannot be recognized by the DNS server, Converts SDNP datagrams to IP datagrams.

This zone-specific SDNP payload is then wrapped, within an IP datagram packet, with an IP header containing the last mile network-specific IP address, either a NAT or Internet address, and thus the SDNP gateway 1201A and the communication device , that is, to help route packets between the tablet 33 and the mobile phone 32 acting as SDNP clients. Since the intermediate devices in the last mile routing are not SDNP clients, the composition of the SDNP payload in IP datagram (B) remains fixed as it travels across the last mile. In other words, data packets 1223B, 1223C, and 1223D are identically constructed datagrams, all of which have the same SDNP payload - a payload that does not change as the packet hops from device to device along the last mile. Contains the SDNP datagram (B). In simple summary, only SDNP network nodes or SDNP clients, whether IP datagrams or SDNP datagrams, can reconstruct SDNP payloads embedded within level 3 datagrams.

As shown, data packet 1223B containing IP datagram B is carried by NSP operated wired or fiber link 24 to network router 27, and then data packet 1223C is also transferred to ISP operated IP datagram (B) carried by wired or fiber link 24A to WiFi router 26. WiFi router 26 then directs data packets (including IP datagrams B) over WiFi link 29 to mobile devices such as cell phones 32 and tablets 33 on which SDNP app 1335A is running. 1223D) to promote last link communication. Accordingly, such a device is capable of decrypting, de-junking, unscrambling, and mixing the contents of the payload with data fragments from other data packets to recreate the original message or sound, IP datagram (B) It functions as an SDNP client capable of interpreting the data contained in the data packet 1223D containing

In FIG. 19, hypersecure last mile communication is shown between an SDNP network and various cellular mobile devices having a cellular radio last link. As shown, data packet 1223B containing IP datagram B is carried by NSP operating wire or fiber link 24 to network router 27, and then data packet 1223C is also sent to the cellular network. (25) contains an IP datagram (B) that is carried to the cellular base station (17) by a mobile network operator (MNO) wired or fiber link (24B) to generate (25). Cellular base station 17 then transmits IP datagram B over 3G, 4G/LTE 28 to mobile devices such as cell phones 32 and tablets 33 on which SDNP app 1335A is operated. Facilitates last link communication using data packet 1223D.

As in the previous example, since intermediate devices in the last mile routing are not SDNP clients, the composition of the SDNP payload in IP datagram (B) remains fixed as it travels across the last mile. In other words, data packets 1223B, 1223C, and 1223D are identically constructed datagrams, all of which have the same SDNP payload - a payload that does not change as the packet hops from device to device along the last mile. Contains the SDNP datagram (B).

In FIG. 20, hypersecure last mile communication is shown between an SDNP network and various tethered (non-mobile) devices with an Ethernet last link. As shown, data packet 1223B containing IP datagram B is carried by NSP operating wire or fiber link 24 to network router 27, and then data packet 1223C also provides Internet service IP datagram (B) carried by provider (ISP) wired or fiber optic link 24A to Ethernet router 103A. Ethernet router 103A then connects desktop computer 36 running SDNP app 1335C and SDNP firmware (over Ethernet 106A) using data packets 1223D containing IP datagram B 1335B) facilitates last link communication with a tethered device such as a desktop phone 37 that is operated. When there is no SDNP network node or SDNP client within the last mile, data packets 1223B, 1223C, and 1223D are identically constructed datagrams, all of which have the same SDNP payload - the packet hops from device to device along the last mile. SDNP datagram (B) with a payload that does not change when

In FIG. 21, hypersecure last mile communication is shown between an SDNP network and a cable service client. As shown, data packet 1223A containing IP datagram B is transported by NSP wired or fiber link 24 to cable CMTS 101, i.e., the cable operator's command, communication and content distribution center. do. Such cable operators provide a variety of services such as cable television, pay-as-you-go, telephone service, Internet connectivity, business services, and others. The CMTS 101 head unit is then coupled to the client via cable 106 using fiber or coaxial modulated according to DOCSIS3 and trellis formatting (described in the background section of this disclosure) to provide bandwidth and optimize real-time services. Transparent to the client, the cable operator may retain the datagram format or alternatively may package the IP datagram into a proprietary datagram format. These data packets, referred to herein as CMTS datagrams (C), use cable-specific NAT addressing and, for delivery over cable 106, SDNP payloads as n nested payloads within data packets 1224C. encapsulate

As shown, cable CMTS 101 routes CMTS datagram (C) to cable modem 103, which in turn contains IP datagram (B) with an unchanged SDNP payload for last link delivery. Extract payload data packet 1223B. The last link for SDNP client-based devices is either over Ethernet 106 to desktop computer 36 running SDNP client app 1335C, or to wireless phone 5A running SDNP client firmware 1335B. It can be produced in several formats, including over copper strands 7 for Cable CMTS 101 also routes CMTS datagrams (C) to cable modem 103, which in turn extracts the original IP datagrams, e.g. IP datagrams (B), and transmits these and other video content. It transmits to the cable TV set-top box via cable 106. The cable set top box then forwards the IP datagram (B) and the content via HDMI-2 107 to the UHD interactive TV 39 on which the SDNP app 1335D is running. Alternatively, the SDNP firmware may be hosted by the cable TV set top box 102.

In FIG. 22, hypersecure last mile communication is shown between an SDNP network and a WiFi home network connected through a cable service provider. As shown, data packets 1223B containing IP datagrams B are transported by NSP wired or fiber links 24A to cable CMTS 101, i.e., the cable operator's command, communication and content distribution center. do. The CMTS 101 head unit then connects to a particular client's cable (WiFi) modem router 100B using a coaxial or over-fiber wired or fiber link 24A to create a WiFi access point 26. Routing of data packet 1224C may include IP datagrams with Internet addresses, or may include proprietary CMTS datagrams (C) with NAT addressing. The routing between the SDNP gateway 1201A and the cable (WiFi) modem router 26 represents the wireline leg of the hypersecure last mile.

The last leg in the home network includes a WiFi link 29 that connects the cable (WiFi) modem router 26 to various home devices wirelessly by means of data packets 1223D containing IP datagrams (B). To facilitate end-to-end hypersecurity, a device must operate as an SDNP client using software or firmware loaded on the device. For example, laptop 35 and desktop computer 36 operate as SDNP clients using computer app 1335C, and cell phone 32 and tablet 33 operate as SDNP clients using mobile app 1335A. it works IoT devices, which in this case are registers 34K, can act as SDNP clients when SDNP firmware 1335E is loaded into their control system. However, in cases where such a device does not or cannot be embedded with the SDNP client's software, end-to-end security may be achieved by other means.

Identity - Paired Last Link Security - Hypersecurity cannot be guaranteed end-to-end if the connected device cannot act as an SDNP client. In such cases, the use of SDNP remote gateways can extend hypersecure communications to cover the last mile of communications excluding that last link. The last link, i.e., the portion of the last mile that is directly connected to the communication device, is not enabled as an SDNP host, and last link security must be ensured over the local area network (LAN) used to facilitate last link communications. 23 schematically illustrates the use of SDNP remote gateway 1350 in last mile communication. SDNP remote gateway 1350 includes any communication device enabled by SDNP firmware 1335H to function as a remote gateway. Thus, an SDNP connection between SDNP gateway 1201A and SDNP remote gateway 1350 includes IP datagram 1223A containing IP or NAT source and destination addresses and SDNP payload 1222. SDNP payload 1222 contains SDNP addresses that cannot be recognized by the DNS server using last mile zone specific security credentials and the nested SDNP payload. These SDNP connections are hyper-secure, capable of supporting identity verification and call privacy.

Between the SDNP remote gateway 1350 and any connected device other than the SDNP client (e.g. desktop computer 36), communication is effected by a local area network or LAN connection, e.g. Ethernet, WiFi or other protocols. . Security is facilitated by LAN security protocols and devices paired between the communication device and the SDNP remote gateway. Device pairing is the process by which an authentication sequence between two communicating devices establishes the identity of the two devices to prevent unauthorized access.

In Fig. 24, an SDNP-enabled router 1351, i.e., a router on which SDNP firmware 1335H is running, implements the function of a remote SDNP gateway. This gateway converts data packet 1223A containing IP datagram (A) into data packet 1223B containing IP datagram (B). Although the SDNP firmware 1335H can interpret the SDNP payload contained in IP datagram (A), the connected devices are not SDNP clients. Instead, the SDNP router 1351 converts the SDNP payload to normal IP payload. Unless an additional secure method is introduced into the device, this last link is insecure. In home use, this unsecured device connection is often not a concern, since the last link takes place within the home. Unless a hacker physically breaks into a home to connect to a wiretap, such a wireline connection cannot be sniffed. An example of a wired in-home last link to a non-SDNP device is Ethernet 106A, illustrated by example connected to HDMI-2 or modem 103C connected to desktop computer 36 and connected to TV 39. includes

Since SDNP connections and hyper-secure communications only extend up to the SDNP router 1351, the last link must rely on authentication and encryption to achieve security in wireline connections. In Ethernet, such security can be achieved by any number of security methods, including iSCSI operating on layers 1 to 3, such as VLANs or virtual local area network operation using encryption between authorized devices. .com/feature/iSCSI-security-Networking-and-security-options-available). Alternatively, security may be achieved using "IP Security" or Layer 4 to Layer 6 methods using the IPSec framework. Originally developed and promoted by Cisco as an industry standard for data storage, IPSec provides two modes of security. In "authentication header" mode, the receiving device can authenticate the sender of the data. In this mode, data fields are encrypted, but headers use recognizable IP addresses. In secure payload encapsulation (ESP), also known as tunnel mode, the entire IP packet including the IP header is encrypted and nested within a newly decrypted IP packet, so that routing can function properly and the packet does so. The exact network destination can be reached.

In either case, security relies on the authentication device to be able to connect to the network. In a home network, such as a personal network connected to computers, shared storage drives, IoT and other device connections, network-connected hardware is not frequently exchanged. In such cases, authentication essentially involves the process of registering a device to gain access to a network or router. Instead of identifying the identity of a particular user, this type of authentication typically uses some device tag, name, or ID number to identify and recognize devices authorized for connection, i.e. between devices, i.e. devices It consists of -to-device. Establishing a network connection involves a setup phase when the devices are first introduced to each other and the connection is approved by the user, then whenever a wireline device is physically connected to another or in the case of WiFi two devices Whenever they come within range of each other, an automated authentication sequence takes place. The setup phase, referred to herein as identity pairing, may also be referred to as device registration, device association, device pairing, pairing, or pairing association. A similar process is used with devices to connect Bluetooth headphones to a cell phone or pair a Bluetooth cell phone to a vehicle's hands-free audio system. The protocols include challenge handshake 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, rely on encryption methods that have been broken but still used for combination with other technologies.

Ethernet communication is of an identity-paired device, e.g. Ethernet modem 103C, a modem comprising an analog telephone signal transmitted via twisted pair copper conductor 7 to wireless telephone 5A and to desktop telephone 37. Although the output is protected, the last link is not secure. Also, the communication format of wireless telephone 5A is not secure and is open to interception and monitoring. For this reason, the use of home telephones in secure communications is not recommended.

Distribution of video content is another concern in security. For example, in SDNP router 1351 communication to HDTV 39, High Definition Multimedia Interface (HDMI), DisplayPort (DP), Digital Visual Interface (DVI), and the less popular Gigabit Video Interface (GVIF), Alternatively, video communication formats such as Unified Digital Interface (UDI) typically include a physical connection to an HDTV or display monitor. Originally, the security of these connections and their data was a concern of film studios and content providers, with a focus on preventing illegal copying and distribution of copyrighted works. HDCP (High-bandwidth Digital Content Protection) is one security protocol developed by Intel Corp. to maintain the security of video links (https://en.wikipedia.org/wiki/High-bandwidth Digital Content Protection). ). Originally such a system was intended to prevent HDCP-encrypted content from being played on unauthorized devices. Such systems check the authenticity of a TV receiver or display before transmitting content. As such, DHCP uses authentication to prevent non-licenses from receiving data, which encrypts data and revokes compromised device keys to prevent information eavesdropping.

With HDCP, the flow of content from the modem to the TV can be secured by authentication, i.e. by use of identification pairing. However, with the advent of smart TVs, the data flow is bi-directional. As a means to facilitate upstream data flow, i.e. data flow from the TV to the modem or set-top box, starting with revision 1.4, HDMI now embeds a high-speed bi-directional data channel known as the HEC or HDMI Ethernet Channel. These data channels mean that HDMI connected devices can transmit and receive data over lOOMC/sec Ethernet, thus making them ready for IP-based applications such as IP-TV. The HDMI Ethernet Channel allows Internet-enabled HDMI devices to share an Internet connection through an HDMI link, without requiring a separate Ethernet cable. Thus, secure communication can be facilitated over HDMI using the same secure protocol and identity pairing available in Ethernet.

In FIG. 25 , the use of a SDNP enabled WiFi router 1352 , i.e. a WiFi router running SDNP firmware 1335J implements the function of a remote SDNP gateway. This gateway converts data packet 1223A containing IP datagram (A) into data packet 1223B containing IP datagram (B). Although the SDNP firmware 1335J can interpret the SDNP payload contained in IP datagram (A), the connected devices are not SDNP clients. Instead, the SDNP WiFi router 1352 converts SDNP payloads into normal IP payloads and communicates wirelessly with connected devices using the WiFi access point 26 to facilitate communication over the WiFi link 29. do. Unless an additional secure method is introduced into the device, this last link is insecure. In the case of WiFi communication in a home or office, security is a concern because data packets can be sniffed at a distance. Examples of WiFi connected home and office devices include desktop computers (36), laptops (35), tablets (33), cell phones (32), speakers (34B), printers/scanners (34A), and shared data drives (34C). includes

Security between the SDNP gateway, i.e. the SDNP WiFi router 1352, and connected devices is based on WiFi Protected Access (WPA-II or WPA2) (IEEE 802.1 li-2004), which replaces the older WPA and its unsecure predecessor WPE. This is accomplished using any number of industry standard protocols, such as WPA2 communications are secured using the Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP) based on AES processing with a 128-bit key and 1280-bit block size. CCMP provides data reliability, requires authentication, and establishes access control. Authentication involves identity pairing in the setup. Re-pairing must be done manually. CCMP security, while good, is not hypersecure and does not have the anonymous data packets and dynamic nature of SDNP communications provided from SDNP clients.

In FIG. 26 , as an example of an IoT connected device in a home network, the use of an SDNP enabled WiFi router 1352, i.e. a WiFi router running SDNP firmware 1335J, implements the function of a remote SDNP gateway. This gateway converts data packet 1223A containing IP datagram (A) into data packet 1223B containing IP datagram (B). Although the SDNP firmware (1,335 J) can interpret the SDNP payload contained in IP datagram (A), connected IoT devices are not SDNP clients. Instead, the SDNP WiFi router 1352 converts the SDNP payload to a normal IP payload and uses the WiFi link 29 from the WiFi access point 26 to wirelessly communicate with the connecting device. Unless additional security measures are implemented, this last link is insecure - especially WiFi data packets can be sniffed at a distance. Examples of WiFi connected IoT devices in the home are central heating and air conditioning (34D), lights (34G), blinds (34F), large appliances (34K), portable and indoor heating, ventilating, and air conditioning (HVAC) (34E) , garage door 34L, home monitoring 34J, and home central security system 34H.

Security between the SDNP gateway, i.e. the SDNP WiFi router 1352, and connected devices is achieved using any number of industry standards, such as the aforementioned WiFi Protected Access protocol (WPA2) using CCMP, which promotes data confidentiality; Require authentication and set access control. WPA2 achieves security using identity pairing, device identification implemented as a layer 2 protocol. This method is cumbersome including manual authentication methods.

An alternative protocol used for local area networks recently introduced for IoT communication - Proximity Networks referred to as the AllJoyn framework. Such a framework helps discover devices, create sessions, and secure communications. The framework is designed to support IoT device connectivity using a number of Layer 2 transport layers, including WiFi, Ethernet, serial bus communications, and power line PLC. Applications run in C, C++, Obj. on numerous platforms including Linux, Windows, MacOS, Android, iOS, RTOS real-time operating systems, and the open source development environment Arduino. It can be based on C, and Java.

AllJoyn flexible applications enable end-to-end application level security by authenticating one another and exchanging encrypted data. Authentication and data encryption are performed at application layer 7. Transport Layer 2, also referred to as the router layer, transports security-related messages between application endpoints but does not implement any security logic itself. Also known as "Auth Listener" implemented at application layer 7, a reverse call function assists authentication using a PIN, password, or authentication credential. Security is achieved using AES128 peer-to-peer encryption. Like WPA, AllJoyn uses identity pairing in an authentication process prior to execution of command and control sequences. Supported authentication methods include login using a pre-shared key or PSK, secure remote password (SRP) key exchange, or username and password. The protocol also supports transient (elliptic curve Diffe-Hellman) key exchanges: (i) no authentication, (ii) authenticated with a pre-exchanged key, and (iii) authenticated with an X.509 ECDSA certificate.

The same technique can be applied to business enterprises. In FIG. 27 , as an example of an IoT connected device within a home network, the use of a SDNP enabled WiFi and Ethernet router 1352Z, i.e. an Ethernet and WiFi router running SDNP firmware 1335J, implements the function of a remote SDNP gateway. do. This gateway converts data packet 1223A containing IP datagram (A) into data packet 1223B containing IP datagram (B). Although the SDNP firmware 1335 J can interpret the SDNP payload contained in IP datagram (A), connected IoT devices are not SDNP clients. Instead, the SDNP and Ethernet WiFi router 1352 converts SDNP payloads into normal IP payloads and uses both WiFi link 29 and Ethernet 106A to communicate with connected devices.

Unless additional security measures are implemented, this last link is insecure - especially WiFi data packets that can be sniffed from a distance. Examples of WiFi connected IoT business devices are WiFi hotspot connected devices such as central heating and air conditioning (34D), lighting (34G), surveillance system (34J), security system (34H), POS terminal (38), and tablet (33). includes Business Enterprise Wire-connected devices vary according to the nature of the business. In banking, the device includes an Ethernet connected ATM machine 38D. In a gas filling station, the device comprises a gas pump 38A with an Ethernet connection, for example.

In summary, the last link can be secured with a non-SDNP client communicating with the SDNP remote gateway. In this way, most of the last mile is hypersecure, while the last link uses identity-paired encrypted security.

SDNP Bridge Communication - As mentioned above, last mile data transfers outside the SDNP cloud are IP datagrams, i.e. data packets, that use Internet source and destination addresses, or alternatively the network operator's NAT address. essential use of In the case of a private network operating within an office building, for example, or cooperating with a local network service provider who wants to host an SDNP soft-switch on a server, SDNP datagrams can be used to achieve hypersecure communications on the part of the last mile. can

As mentioned above, hypersecure communication relies on servers to host SDNP soft-switch software or firmware and to communicate using SDNP datagrams and anonymous addresses, rather than IP datagrams within the SDNP cloud, such SDNP Soft-switch based servers are referred to as SDNP nodes, as indicated by the SDNP node notation (M _0,1 , M _1,0 , M _1,1 , etc.). The aforementioned US application Ser. No. 14/803,869 also discloses communication between multiple independent SDNP clouds connected by SDNP bridges - SDNP gateways that route IP datagrams to other SDNP clouds.

The concept of an SDNP bridge can be similarly configured for the part of last mile communication. To create a SDNP sub-network or mini-cloud within the last mile, two or more servers must be enabled by the SDNP bridge software or firmware. Unlike the SDNP client software or firmware that runs on the end device, ie on the calling device, the SDNP bridge operates not as an end connection, but is used to route data. Thus, two or more adjacent SDNP bridges can operate as a standalone SDNP bridge network, SDNP mini-cloud or SDNP ad hoc network. The SDNP bridge function represents a layer 3 configuration similar to the layer 2 description of the bridge mode operation of a WiFi router, as described above. In an SDNP-Bridge or SDNP Bridge network, communication takes place using SDNP datagrams. Communication to the SDNP-Bridge from outside the SDNP-Bridge or SDNP-Bridge network uses IP datagrams with SDNP payloads.

The operation of the SDNP bridge in last mile communication is illustrated in the schematic diagram shown in Fig. 28, which shows an SDNP network with SDNP gateway 1201A, SDNP bridge routers 1350 and 1335J running SDNP firmware 1335H and 1335J respectively. 1352Z), and a connected client device, shown here as a notebook 35, that is not an SDNP client. As shown, communication between SDNP gateway 1201A and SDNP-bridge 1350 involves a secure connection using IP datagram 1223A with an IP address and SDNP payload. SDNP payload 1222A again includes SDNP routing information and secure SDNP payload encoded using zone specific security credentials. Thereby, although IP address routing is used, hypersecurity is achieved using the SDNP payload.

Within the SDNP-Bridge connection, i.e. between the SDNP Bridge Router 1350 and the WiFi-based SDNP Bridge Router 1352Z, hypersecure communication takes place using SDNP datagrams 1222B. SDNP routing information is extracted from SDNP addressing contained within SDNP payload 1222A. Together, the SDNP-Bridge and SDNP Connection include a hypersecure wireline leg of last mile communication that can support identity and account verification and can support privacy.

The connection from the SDNP-bridge router 1352Z to the non-SDNP client device, i.e. notebook 35, uses an IP datagram 1223B with an IP address and IP payload over a local area network, i.e. WiFi or Ethernet. The security of this Last Link, although not hypersecure, is secured by any of the aforementioned Ethernet and WiFi security protocols such as iSCSI, IPSec, WPA, AllJoyn, and others.

An implementation of SDNP bridging can occur between any two SDNP-based devices involved by any number of physical media, in which layer SDNP bridging operates agnostic from layer 1 PHY and layer 2 transport layer realizations. 3 protocol. For example, in the top schematic diagram shown in FIG. 29A, two SDNP bridged Ethernet routers 1351A, each running SDNP firmware 1335H, communicate across an Ethernet (wireline) bridge using SDNP datagrams 1222. do. In the central schematic, two SDNP-bridge routers 1352Z, each capable of Ethernet and WiFi communication and running SDNP firmware 1335J, communicate across the WiFi (wireless) bridge using SDNP datagrams 1222 . In the bottommost schematic diagram, an SDNP-Bridge Ethernet router 1351A running SDNP firmware 1335H has an SDNP datagram ( 1222) to communicate across an Ethernet (wireline) bridge. In this way, an SDNP bridge comprising two or more SDNP-based routers can route or distribute SDNP datagrams throughout a building or across a private network, even though operating outside the SDNP cloud within the last mile.

The SDNP-Bridge can be extended to systems using proprietary hardware, such as cable TV systems. For example, in the topmost diagram shown in FIG. 29B, two cable CMTS “head” servers are modified to run SDNP firmware or software 1335L and thereby act as cable CMTS SDNP bridges 101 and send SDNP datagrams. 1222 to communicate over a cable or fiber (wireline) bridge. An SDNP-bridge can extend from the CMTS head to the subscriber's home. As shown in the central schematic diagram, a cable CMTS SDNP bridge 101 running SDNP firmware or software 1335L uses SDNP datagrams 1222 across the cable (coaxial) bridge to drive SDNP firmware 1335M. Communicates to a cable TV set top box or cable modem (102). In this way, the SDNP bridge extends hypersecure communications into the home or office.

The disclosed SDNP-Bridge method can also be used to transmit data across radio networks. In the bottom schematic diagram of FIG. 29B, two cellular base stations and radio towers running SDNP firmware or software 1335N function as cellular base station SDNP bridges 17X and 17Y, forming a cellular bridge 25X using SDNP datagrams 1222. and 25Y). In the top schematic diagram of FIG. 29C, a terrestrial microwave base station running SDNP firmware or software 1335O functions as a ground-to-satellite link SDNP bridge 92C, using SDNP datagrams 1222 as a microwave satellite bridge using SDNP firmware or to the orbiting satellite on which software 1335P is running, i.e. to the satellite SDNP bridge 93. The satellite then again communicates with subscribers or other satellites.

SDNP bridge communication can be adapted for automotive applications using automobiles as a peer-to-peer ad hoc communication network. In the bottom schematic diagram of FIG. 29C , a telematics module inside car 1390A with SDNP firmware 1335F running, using SDNP datagrams 1222, via a car radio bridge, SDNP firmware 1335F is also running. Communicate with a vehicle 1390B in the vicinity. Each vehicle enabled with SDNP firmware forms another communication node within the dynamic telematics SDNP bridge network. These communications do not represent information being transmitted to a particular vehicle or driver, but instead form a communications network capable of conveying information along highways, even where cell towers do not exist locally.

The concept of an SDNP bridge network is particularly advantageous for communications over large geographies and in the transportation and shipping industries, including vehicles, trucks, emergency vehicles, trains, aircraft, boats and ocean vessels. In particular, to achieve wide coverage for communications, a satellite network is required. The system typically includes network connectivity to a satellite operator, referred to as a satellite bridge or backhaul, and satellite links to its clients and subscribers, also known as satellite distribution. 30 schematically illustrates various satellite connections configured for SDNP hypersecure communication. SDNP gateway 1201A shown is a terrestrial satellite running SDNP firmware or software 1335O using wireline connection 94A carrying data packets 1222A containing SDNP datagrams (A) and SDNP payloads. Communicates with antenna dish 92C, which in turn relays the same SDNP datagram (A) as data packet 1223B via satellite bridge 95A to satellite 93 on which SDNP firmware or software 1335P is running.

The distribution of hypersecure communication data packets from the SDNP-based satellite 93 to the various clients includes SDNP data packet-A and data packet 1222C containing the SDNP payload. Satellite communication is bi-directional, and downlinks from satellites 93 to terrestrial clients allow for stronger signal strength and faster data rates than uplink connections. In other words, a satellite can transmit to a client on Earth at a higher data rate and with a stronger signal strength than the client's response. Examples of satellite 93 links to subscribers are for a Dish Internet subscriber 92G running SDNP firmware 1335T, for a satellite phone 92F running SDNP firmware 1335S, for a satellite phone 92F running SDNP firmware 1335G. SDNP firmware 1335R for satellite antenna array 92H located atop high speed rail 1360C in operation, satellite antenna array 92E located atop ocean vessel 1360B in operation, and SDNP firmware ( 1335Q) includes a satellite link 95B, to a satellite antenna array 92H located atop aircraft 1360A on which it operates.

In the case of large vehicles such as ships, aircraft, and trains, each system connects this hyper-secure satellite communications link to its own internal communications system or local area network. For example, FIG. 31A shows a commercial aircraft where a satellite antenna module 92D running SDNP firmware 1335X mounted on top of the fuselage of aircraft 1360A is a communications central server running SDNP software 1335Z. (1361). The communication central server 1361 includes an appliance 1367, a data recorder and black box 1368, a media storage module 1363, and a WiFi router module 1362, optionally running SDNP firmware 1335L. Linked to various systems. A WiFi router module 1362 is coupled to an array of WiFi antennas 1361 located throughout the aircraft to support WiFi hotspot communications. All communications except for radio-based flight control occur over a common satellite communications link, for example using antenna module 92D shown in FIG. 31B. The antenna module includes a satellite transmission antenna 1360A, a satellite reception antenna 1368A, an antenna control unit 1369, and a 40W voltage regulator 1370. The satellite receive antenna 1368A is smaller than the satellite transmit antenna 1360A because the satellite broadcast power and signal strength are greater than the broadcast strength and uplink capability of the antenna.

Maritime satellite vessel communications utilize multiple bands of satellite communications, including high-altitude and near-Earth orbiting satellites. For example, FIG. 32 illustrates the use of multi-band communications including a Ku band satellite antenna 1383A and low-Earth-orbiting satellite antennas 1383B and 1383C. High-altitude satellites offer limited or no uplink capabilities, but can cover large areas from high altitudes, including geostationary orbit. Due to its high altitude, the local coverage of each satellite is substantial, as shown in map 1384. As shown in map 1385, low earth orbit satellites cover a smaller area, require more satellites, and therefore cost more to cover the broadcast area. Depending on the ship's route, access to low earth orbiting satellites may be intermittent depending on the satellite's orbital position.

Since the Ku band satellite antenna 1383A is primarily used for distribution of TV and movie content, SDNP security is generally not required. Tracking and positioning is performed by antenna control 1383. Multi-channel data from the satellite antenna 1383A is fed into an L-band multiswitch 1381 that separates the signal into fixed video broadcast data and digital video broadcast DVB data that are routed to the TV receiver and tuner 1382. The video content is fed into a central communication server 1380. However, if secure communication is required, the Ku band satellite antenna 1383A can be configured to run SDNP software.

Data from low-Earth-orbiting satellite antennas 1383B and 1383C running corresponding SDNP firmware 1335U and 1335V transfers information from the satellite antennas to a central communications server 1380 running SDNP software 1335Z. relay Within terrestrial range, the communication system may also communicate using the 4G/LTE cellular network 25 hosted by the cellular base station 17 on which the SDNP firmware 1335N is operated. Communication through the server 1380 is distributed throughout the ship using the SDNP WiFi router 1362 in which the SDNP firmware 1335L is operated. The WiFi hotspot communication of the WiFi access point 26 is distributed throughout the vessel using WiFi antennas 1361. Communication to an SDNP client, such as a mobile phone 32 on which the SDNP app 1335 is running, facilitates end-to-end hypersecure communication. Devices that are not enabled as SDNP clients must resort to identity pairing using WAP, AllJoyn, or other secure protocols.

33 shows an application example of multi-band communication applied to a high-speed train. As shown, the train data center server 1380 running the SDNP software 1335Z connected to the SDNP gateway 1201A includes a satellite microwave 95B, a 400 MHz radio 1372, and a 60 GHz microwave 1373. Communicate on high-speed train 1360C through multiple PHY connections. During SDNP communication, SDNP data center 1380 relays data to satellite 93 running SDNP firmware 1335P via satellite antenna 92C running SDNP firmware 1335D. The satellite communicates with a train antenna array 1383V connected to a server 1361 on which SDNP software 1335Y runs. Alternative communications occur from the SDNP data center 1380 via 400 MHz antennas 1381 or 60 GHz antennas 1382 placed at regular intervals along the train tracks. These satellites also communicate with an antenna array 1383B coupled to a train communications SDNP server 1361 on which SDNP software 1335Y is run. Communications received by SDNP server 1361 are then distributed by WiFi bridge 1335Z throughout the train and to clients as WiFi hotspots.

Communication functions in automotive and professional trucking are multi-faceted, including:

* Voice communication

* Navigation, maps, road information, warnings

* Entertainment, hotspot service, infotainment

* Wireless payment, toll

* Emergency services, roadside assistance

* Collision Avoidance

* Flight scheduling (professional, riding together)

Additional functionality for autonomous vehicles, ie self-driving vehicles, is also desired. Existing automotive systems, primarily based on conventional cellular networks such as CDMA (2.5G) controlled central units referred to as “telematics” modules, have been found to be highly vulnerable to hacking, cyber-attacks, and privacy attacks. To eliminate these vulnerabilities, the entire network must be secured without significant outlay, i.e. installing a new network is not a financial option. Instead, security infrastructure, such as the security methods deployed at Layers 3 through 7, must be deployed over the hardware network. This strategy is compatible with the SDNP last mile implementation disclosed herein.

34 illustrates an exemplary hypersecure last mile connection between a carrier and an SDNP cloud. As with previous last mile connections, the particular data carriers involved in transmitting packets across the last mile can vary greatly from location to location. Thus, an example is shown for presenting hypersecure communication regardless of the data carrier involved. As shown, SDNP gateway 1201A connects to network router 67A via network service provider (NSP) managed wire or fiber link 24 to send data packets 1222A containing SDNP datagrams A. to data packet 1223A containing IP datagram (B) containing SDNP payload. Network router 67A then sends IP datagram B as data packet 1223B to cellular base station 17 over a wired or fiber link 24A owned or operated by a mobile network operator (MNO). route to IP data packet B is then sent over cellular network 25 as data packet 1223C containing SDNP datagram B containing an SDNP payload, using cellular link 28, i.e., area Communicate wirelessly to the telematics module in car 1390A using 2.5G, 3G, 3.5G, or 4G/LTE depending on the mobile network operator in the car. Then, the SDNP firmware 1335F operating within the telematics module interprets the SDNP payload embedded in the received data packet 1223C to complete the hypersecure communication link. Thus, the automotive cellular last link functions as part of a hypersecure last mile communication.

As shown in FIG. 35 , the telematics module within car 1390A then uses the secure information for various functions controlled by infotainment interface 1377 . Internal WiFi hotspot 1362D also distributes data packets 1223B and 1223C containing IP datagrams (B) and IP datagrams (C), respectively. IP datagram B contains an SDNP payload that facilitates end-to-end hypersecure communication to any SDNP client, such as mobile phone 32B on which SDNP app 1335 is running. IP datagram C, which uses only a normal IP payload, is less secure, but work devices do not operate as SDNP clients, such as cell phones 32A and tablets 33A. Identity pairing can be used to improve last link security for non-SDNP devices using WPA, AllJoyn or other protocols.

Another important function in vehicle communication is that of vehicle-to-vehicle communication, also referred to as V2V communication. The purpose of V2V communication is mainly for collision avoidance. However, according to the SDNP method disclosed herein, V2V communication can also function as a hypersecure ad hoc peer-to-peer network. Such vehicle-to-vehicle SDNP communication is illustrated in FIG. 36, where vehicles 1390A, 1390B, and 1390C running SDNP firmware 1335F communicate with each other and with cellular base station 17 connected to SDNP gateway 1201A and peer-to-peer. Form a two-peer network. Communication between vehicles can be carried out using IP datagrams or SDNP datagrams.

When an SNP client or gateway communicates with a non-SDNP device, communication occurs using IP datagrams. For example, SDNP gateway 1201A converts an SDNP datagram (A) having an SDNP payload into a data packet 1223A containing an IP datagram (B) having an SDNP payload embedded therein. As shown, cellular base station 17 transmits data packets 1223B containing IP datagrams B with embedded SDNP payloads to a vehicle 1390A over a 2.5G or 3G cellular link 28A. , but communicates over a 3.5G or 4G/LTE cellular link 28B to an automobile 1390C using data packet 1223C that also includes an IP datagram B with an embedded SDNP payload. can do. In this way, the SDNP payload is distributed independently of the network used to carry the data packets.

Vehicles enabled with SDNP firmware 1335F can also form ad hoc peer-to-peer SDNP bridges or bridge networks. For example, car 1390A communicates with car 1390B over V2V radio link 1391A using data packets 1222B that contain SDNP datagrams (C) instead of IP datagrams. Similarly, car 1390B communicates with car 1390C over V2V radio link 1391B using data packets 1222C containing SDNP datagrams (D) and does not rely on IP datagrams. Regardless of the type of datagram used, the embedded content is hypersecure using the SDNP payload.

Another feature of the SDNP ad hoc V2V network is its ability to perform a tunneling function, ie pass data from one vehicle to another without intervening vehicles being able to monitor or interpret the passing data. If cellular link 28B fails due to car 1390C being out of range, such as the other route, cellular base station 17, in the illustrated example, connects cellular link 28A, V2V radio link 1391A, and finally It is possible to use the SDNP bridge network to reach the same caller through the V2V radio link 1391B. During data transmission, data packets 1223B, 1222B and 1222C are changed from IP datagrams (B) to SDNP datagrams (C) and finally to SDNP datagrams (D). Since the SDNP payload intended for car 1390C is generated specifically for the destination car, car 1390B and its occupants, although relying on data packet 1222B over the ad hoc network, will receive SDNP datagrams ( C) You may not hack or monitor the contents of

In addition to normal last mile communication, the same SDNP bridge technology can be used to transmit large amounts of data over long distances in hyper-secure or digital trunk communication. Three such examples are shown in FIG. 37: microwave trunk 98, fiber trunk 90, and satellite trunks 95A and 95B. Although these functions can be considered part of the SDNP cloud, the single data path is similar to that of last mile communications, and therefore uses similar methods to ensure hypersecurity. For example, servers 21A and 21B running SDNP software 1335Z use data packets 1222 containing SDNP datagrams to power microwave towers 96A and 96B running SDNP firmware 1335W. via microwave trunk 98, or alternatively servers 21A and 21B can communicate directly over fiber trunk 98 which also uses data packets 1222 containing SDNP datagrams. have. In global communications, e.g., in a transpacific data link, servers 21A and 21B use earth-based satellite antennas 92A and 92B, on both of which SDNP firmware 1335U is running, to operate a microwave satellite trunk ( 95A and 95B) to communicate with satellite 93 on which SDNP firmware 1335V is operated. As with the fiber and microwave tower examples, satellite trunk communications use data packets 1222 containing SDNP datagrams.

In conclusion, the security and privacy features provided in last mile communication depend on the two communication devices. Figure 38 contrasts four different combinations representing, in order from bottom to top, increasing security and privacy. In each case, three factors: (i) security, i.e. the ability to prevent unauthorized access to the communique, (ii) identity verification, being able to authenticate a user and based on that identity access and privileges (iii) anonymity, i.e. the ability to conceal the identity of the caller from surveillance.

In the bottom example, SDNP gateway 1395 communicates openly with a non-SDNP client without any security provisions using data packet 1223C containing an IP datagram with a sniffable IP address and an IP payload. Thus, the last mile connection is neither secure nor private. In the second example from the bottom, the SDNP gateway 1395 communicates with a non-SDNP client providing features of device authorization and identity pairing. Communication is effected by data packet 1223B containing an IP datagram with a sniffable IP address, but using an encrypted payload containing ciphertext that only the identity-paired device can effect decryption. Although the communication is neither private nor anonymous, it provides enhanced security, at least for a limited duration.

The example following the top achieves hypersecurity if SDNP gateway 1395 routes the communication through any bridge or router 1397 and data packet 1223A contains SDNP payload within an IP datagram. Show that you still achieve. The level of security achieved depends only on the end device and not on the router. In the top example, SDNP using data packet 1222 containing SDNP datagrams with SDNP addressing, i.e., using source and destination addresses that cannot be recognized by Internet DNS name servers, and using SDNP security payloads. Communication between gateway 1395 and SDNP client 1396 is hypersecure, providing excellent security, providing complete privacy, and anonymous packet routing.

Hypersecure Last Mile Packet Routing - Regardless of the layer 1 physical hardware and layer 2 data link algorithms and methods used, the routing of packets between SDNP clients or SDNP-bridges and SDNP gateways carries and routes data packets across the last mile. It relies on IP datagrams to do this. Unlike data routing within the SDNP cloud directed by the SDNP signaling server, the SDNP cloud or its signaling server does not control IP datagrams traversing the last mile. Thus, some variability in last mile propagation delay is expected. Fortunately, these uncertainties are small compared to the overall end-to-end propagation delay of global communications, as the distance and number of possible routes of last mile communications is limited. The variation in total propagation delay due to last-mile variability is estimated to be less than 10% of total delay.

39 illustrates single path last mile communication between SDNP client 1400 and SDNP gateway 1401 using a static IP address. IP datagram 1405 includes the IP destination address of M _0,0 (the SDNP gateway), and the IP address of the source (C _1,1 ) of the data packet, which is the SDNP client. Last link communication occurs over single path 1404 to router 1402A. Data is routed to the SDNP gateway M _0,0 through any number of routers R, for example router 1402B.

An alternative diagram of last mile network connectivity shows each communication device as an IP stack representing network connectivity as PHY, data link, and OSI layers, 1, 2 and 3. For example, FIG. 40A is a schematic IP stack diagram of a single-route last mile hypersecure communication using a fixed IP address. Thus, a client device comprising an SDNP client (C _1,1 ) has a single path last mile connection 1409 with an SDNP gateway 1401 comprising an SDNP gateway M _0,0 via routers 1402A and 1402B ), where router 1402A includes a WiFi router and router 1402B is an Ethernet router. Client device 1400 is connected via last link 1404 to router 1402A, where the PHY layer 1 physical connection of client IP stack 1411 and the corresponding data link layer 2 are connected to the corresponding data link layer 2 in router IP stack 1412A. Tier 1 and Tier 2 are connected.

Again, router 1402A is connected to router 1402B using Ethernet, where the PHY layer 1 physical connection of the WiFi router's IP stack 1412A and the corresponding data link layer 2 are connected within the Ethernet router IP stack 1402B. Corresponding Tier 1 and Tier 2 connections. Finally, the router 1402B is connected to the SDNP gateway server 1401 using Ethernet, where the PHY layer 1 physical connection of the Ethernet router's IP stack 1412B and the corresponding data link layer 2 are connected to the gateway's IP stack ( 1412B) to the corresponding layer 1 and layer 2. In operation, the router carries data without interruption, so that network layer 3 IP datagrams are transferred from one IP stack to another, specifically from layer 3 in IP stack 1411 to IP stacks 1412A, 1412B. and finally flows transparently to the IP stack 1422. In this way, the network carries IP datagrams as single-path data across the virtual last mile connection 1409, even as the data physically passes through multiple devices.

In other words, layer 3 network data flows over the last mile independent of the physical link used to carry IP datagrams, i.e. layer 3 last mile communications depend on the basic layer 1 and layer 2 implementations used for data delivery. It operates agnostic to By removing intermediate nodes from the schematic diagram as shown in Fig. 40B, this principle can be shown in a simplified form, in which the client device 1400 including the communication IP stacks 1411 and 1422 and the SDNP gateway server ( 1401) transfers data to and from corresponding computing and data storage functions 1410 and 1421. IP datagram 1405 flows over last mile connection 1409, regardless of the number of routers or media used in the data packet forwarding process. As such, the last mile can be viewed as a "data structure", meaning any and all physical means of transporting IP datagrams between devices, and can be considered an abstract concept. However, the last link has more physical meaning, since the connected device of the caller must be able to connect to the upstream router of the communication link that cannot be established. For example, if the caller has a tablet computer with only a WiFi connection and is sitting in a cafe with WiFi, but the caller does not have the WPA password for the WiFi network, the last link cannot be formed and the caller is on the last mile. , cannot connect to the SDNP cloud, or cannot place a call.

Another consideration of last mile communication is that the payload of IP datagram 1405 is all for upper OSI layers, including transport layer 4 data, session layer 5 data, presentation layer 6 data, and application layer 7 data. that contains information. Other than the layer 4 data necessary to select the UDP or TCP transport protocol, the remaining data within the payload of an IP datagram is specific to open SDNP communications and operates along the last mile, unless itself running SDNP software or firmware. cannot be interpreted by routers that are Thus, although the last mile network itself may contain a mix of different devices, carriers, and network operators, only the end device, i.e. the caller or SDNP client and SDNP gateway, can interpret the last mile communication. .

Although SDNP payloads are secured by a number of secrets, including scrambling, fragmentation, junk data insertion and deletion, state-dependent formatting, and dynamic encryption, the IP addresses of IP datagrams traversing the last mile network are essential. exposes the source and destination addresses of the client device 1400 and the SDNP gateway server 1401. To provide a degree of anonymity over the last mile, address spoofing is advantageous, i.e. dynamically changing source and destination addresses within IP datagrams to mislead cyber-attackers. IP spoofing is achieved either by dynamically changing the IP address of the caller's connected device, referred to herein as “dynamic client addressing,” or by communicating with multiple SDNP gateways, i.e., multi-path last mile communication.

The first method of IP address spoofing described involves dynamically changing the source address of sequential data packets. As shown in Figure 41, successfully transmitted IP datagrams (A, B, and C) contain three different source addresses. Specifically, IP datagram (A) 1405A includes an IP source address (C _1,1 ), IP datagram (B) 1405B includes an IP source address (C _1,2 ), and IP Datagram (C) 1405C includes an IP source address (C _1,3 ). Thus, even though all packets entering router 1402A come from SDNP client 1400, the client source address (C _1,n ) changes dynamically, confusing the true IP address and having more than one communicating device. make it look like To complete the charade, the MAC address of the communication device must also be correspondingly changed along with the dynamic source address.

This method is illustrated using an IP stack in FIG. 42A, where devices 1400, 1402A, 1402B, and 1401 communicate via corresponding IP stacks 1411N, 1412A, 1412B, and 1422 using WiFi and Ethernet. However, the SDNP client's network layer 3 identity includes multiple IP addresses (C _1,1 , C _1,2 , and C _1,3 ). As a result, sequential data packets entering router 1402A appear to be transmitted from three different client devices, rather than one, as shown in the last link schematic shown in FIG. 42B. The shared PHY layer includes WiFi standard frequencies, and the data link layer connecting the devices follows a defined standard such as 802.11ac or 802.11n.

IP datagram 1405N sent along network connection 1408 to router device 1402 has fixed destination IP addresses IP M _0,0 and IP C _1,n as sequential source addresses IP C _1, expressed in mathematical notation. ₁ , IP C _1,2 , IP C _1,3 , etc., where n = 1, 2, 3, ... uniquely identifying each sequential packet. Each sequential IP packet also contains a corresponding payload (SDNP 1, SDNP 2, SDNP 3, and others). Although this description refers to each IP address using the mathematical abbreviation IP C _1,n , the IP address includes the actual IP address constructed according to international standards for IPv4 or IPv6 and excludes any conserved IP address. It should be noted that it is necessary to understand that

Another option to improve security is to use multipath packet transmission in the last mile. In a manner similar to data transfer within the SDNP cloud, in multipath last mile communication, audio and sequential data are parsed and fragmented, then split into separate packets and addressed to different SDNP gateways. An example of multipath data transfer using static IP addresses is shown in FIG. 43, where SDNP client 1400 communicates with multiple gateways 1401A, 1401B, and 1401C. As shown, the first data packet 1405A includes a payload SDNP(1) with an IP source address (C _1,1 ) and a destination address (M _0,0 ). Data packet 1405A is then routed to SDNP gateway 1401A via routers 1402A and 1402B via last link 1404A. In a similar manner, the second data packet 1405B includes payload SDNP(2) having an IP source address (C _1,1 ) and a destination address (M _0,1 ). Data packet 1405B is then routed to SDNP gateway 1401B via router 1402C via last link 1404B. A third data packet 1405C includes payload SDNP(3) with an IP source address (C _1,1 ) and a destination address (M _0,3 ). Data packet 1405C is then routed to SDNP gateway 1401C via routers 1402D and 1402E via last link 1404C.

In the passage between the illustrated client device 1400 and one of the three gateways 1401A, 1401B or 1401C, an IP datagram is routed through a number of last links 1404A, 1404B, and 1404C to a number of routers 1402A, 1402B. , and 1402C). These routers can be (i) completely independent routers using the same physical media such as WiFi or Ethernet, (ii) multiple router channels within a common hardware device, e.g. multiple trellis channels within a DOCSIS3 cable modem, or (iii) It may include different physical media for communication, eg one physical media routed over WiFi, another physical media over 3G, etc.

For example, FIG. 44A shows an IP stack diagram of the aforementioned multi-route last mile hypersecure communication over a common PHY last link 1404 using a fixed IP address. In operation, SDNP clients C _1,1 communicate with routers 1401A, 1402B, and 1402C as a single device connection, using a common PHY, data link, and network layer. Address spoofing uses successive IP datagrams containing a fixed client address IP C _{1, 1} , but with changing SDNP gateway addresses IP M _0,0 , IP M _0,1 , and IP M _{0, 3} . It is carried out. Misdirection of packets can occur algorithmically or randomly. For example, if every 10th datagram of the datagrams transmitted from the client device 1400 is directed to the SDNP server 1401C, the 10th outgoing datagram from the client device 1400 has the destination address IP M _0,3 and the source IP address IP C _1,1 . The response from SDNP gateway server 1401C is returned to client device 1400 on the opposite path, that is, on the path with source IP address IP M _0,3 and destination address IP C _1,1 .

As shown, the PHY and data links between client device 1400 and routers 1402A, 1402D, and 1402C include a single media, eg, WiFi. Although the last link connection is shown as a single line split into three, it should be understood that the physical connection is all made point-to-point rather than an electrical Y connection used to create parallel wires. Instead, the diagram shows the effect of connection, that is, the PHY layer of client IP stack 1411 extends one PHY connection into three, i.e., the PHY layer of IP stack 1412A, 1412C, and 1412D means connected. Functionally, this last link acts as a single input to a three input expander, where the router function is contained in one common electronic device or divided into distinct and separate routers, regardless of whether one The clients of are connected to the three router functions. As shown, it should be noted that last link 1404 constitutes a single type of communication medium - cable, fiber, WiFi, Ethernet, or cellular.

However, the remainder of the last mile may contain any media, not necessarily the same as the last link. An alternative last link includes a number of different PHY layers connected to independent routers. One such implementation, an IP stack implementing multi-path last mile hypersecure communications using static IP addresses across multiple PHY last links, is shown in FIG. 44B. Specifically, client device 1400 uses a common network layer 3 interface with a fixed client address IP C _1,1 , but separate and distinct layer 1 and It operates using a layer 2 interface. In operation, IP stack 1411A directs IP datagrams containing source address IP C _1,1 and destination address IP M _0,0 across router 1402B across router 1404A. (1402A). Similarly, IP stack 1404B is coupled to router 1402C over last link 1404B directing IP datagrams containing source address IP C _1,1 and destination address IP M _0,1 . IP stack 1411C directs IP datagrams containing source address IP C _1,1 and destination address IP M _0,3 across router 1402E to router 1402D over last link 1404C. Connected.

A combination of dynamic source addressing and multipath data transfer is shown in FIG. 45, where SDNP client 1400 communicates with multiple gateways 1401A, 1401B, and 1401C using dynamic source addresses. In this way, the first data packet 1405A includes a payload SDNP(1) with a dynamic IP source address (C _1,1 ) and destination address (M _0,0 ). Data packet 1405A is then routed to SDNP gateway 1401A via routers 1402A and 1402B via last link 1404A. In a similar manner, the second data packet 1405B includes a payload SDNP(2) with a dynamic IP source address (C _1,2 ) and destination address (M _0,1 ). Data packet 1405B is then routed to SDNP gateway 1401B via router 1402C via last link 1404B. A third data packet 1405C includes payload SDNP(3) with a dynamic IP source address (C _1,3 ) and destination address (M _0,3 ). Data packet 1405C is then routed to SDNP gateway 1401C via routers 1402D and 1402E via last link 1404C.

Thus, each successive data packet contains a varying SDNP payload, uses a dynamically changing source address, and is routed to a specific SDNP gateway via a different last link. Through multiple last links, i.e. last links 1404A, 1404B, and 1404C, a single router with multiple IP inputs, such as a DOCSIS3 cable modem with trellis encoding, or over multiple forms of media, e.g. A combination of radio and WiFi or another combination of wireline and wireless communication is used to transmit data, for example over multiple WiFi bands. In one example, FIG. 46A illustrates an IP stack of multi-route last mile hypersecure communication using dynamic client IP addresses over a single PHY last link 1404. Client device 1400 illustrates a shared physical interface, including Layer 1 and Layer 2 communications, shown in IP stack 1411A. At network layer 3, IP stack 1411A generates a client address (C 1,1 ) directed to SDNP gateway M _0,0 , and IP stack 1411B generates a client address (C _1,1 ) directed to SDNP gateway M _{0, 1} . C _1,2 ), and IP stack 1411C creates a client address (C _1,3 ) directed to the SDNP gateway M _0,3 .

As shown in the IP stack diagram of FIG. 46B, the same multi-path approach can be combined with dynamic client addressing and multiple PHY last layers. As shown, client device 1400 sends IP datagrams with corresponding IP addresses IP C _1,1 , IP C _1,2 , and IP C _{1, 3} to corresponding last links 1404A, 1404B, and 1404C. It includes three IP stacks 1411A, 1411B, and 1411C that transmit to SDNP gateways having IP addresses IP M _0,0 , IP M _0,1 , and IP M _{0, 3} via

In many cases, the last link includes a single path, where multipath data transmission beyond the first router is used. In FIG. 47 , an SDNP client 1400 communicates over a last link 1404 with a single router 1402A. Beyond router 1402A, data packets are directed to multiple gateways 1401A, 1401B, and 1401C using dynamic source addresses. In this implementation, the first data packet 1405A includes payload SDNP(1) with a dynamic IP source address (C _1,1 ) and destination address (M _0,0 ). Data packet 1405A is routed via last link 1404 and via routers 1402A and 1402B to SDNP gateway 1401A.

In a similar manner, the second data packet 1405B includes a payload SDNP(2) with a dynamic IP address (C _1,2 ) and a destination address (M _0,1 ). Data packet 1405B is routed via last link 1404 and via routers 1402A and 1402C to SDNP gateway 1401B. A third data packet 1405C includes payload SDNP(3) with a dynamic IP source address (C _1,3 ) and destination address (M _0,3 ). Data packet 1405C is successively routed to SDNP gateway 1401C via last link 1401 and via routers 1402A, 1402D and 1402E. Thus, each successive data packet contains a varying SDNP payload, uses a dynamically changing source address, and is routed over a common last link to a specific SDNP gateway.

This last mile connection is illustrated using an IP stack in FIG. 48 , where IP stack 1411 in SDNP client device 1400 with last link 1404 having only router 1402A is sends a data packet to stack 1412A comprising three different network addresses, specifically IP C _1,1 , IP C _1,2 , and IP C _1,3 . Thus, while actually containing a single client, client device 1400 appears to router 1402A as three separate clients. When an IP datagram reaches router 1402A, it is split and takes different routes to different destination gateways. A packet with source address IP C _{1, 1} can be routed to destination IP M _{0, 0} via router 1402B, for example, and a packet with source address IP C ₁ , 2 can be routed through router 1402C. can be routed to destination IP M _0,1 via routers 1402D and _{1402E ,} and packets with source addresses IP C 1,3 can be routed to destination IP M _0,3 via routers 1402D and 1402E. The routing table for directing data packets with a given dynamic client address (C _1,n ) to a particular SDNP gateway is not pre-fixed and can vary dynamically. IP addresses can be assigned on a per-packet basis, further complicating the fact that apparently unrelated data packets are all part of a single fragmented communication between two parties.

Physical Realization of Last Mile Routing - A physical realization of last mile routing may include communication over a variety of media, including Ethernet, WiFi, cellular, or DOCSIS3 based cable or fiber links. Regardless of the media used, the routing of data packets over the last mile is primarily controlled by three variables:

* the media access control (MAC) address of the communication device;

* The source IP address of the IP datagram,

* The destination IP address of the IP datagram.

Thus, the MAC address controls the physical media used to carry information each hop in the last mile communication, layer 1 and layer 2, while the IP address controls the client device and the SDNP gateway, i.e. the two ends of the last mile. Identifies the device located in Although the payload used in hypersecure communication conforms to protocols defined by secure dynamic communication networks and protocols, intermediate devices within the last mile, i.e. routers and other devices on the packet's path between the client device and the gateway, are generally SDNP It is not enabled to execute functions, since there is no SDNP executable code in such a device. As such, the SDNP payload is not involved in the routing of last mile hypersecure data packets.

One example is the use of Ethernet for last mile communication. In the adaptation of Ethernet data packets described above in FIG. 9E for SDNP last mile communication, FIG. 49 is a schematic diagram of IPv4 and IPv6 datagrams for Ethernet communication carrying an SDNP payload. As shown, a layer 1 Ethernet packet 188 includes a data frame header, i.e., a preamble 180, a start frame delimiter (SFD) 181, and a layer 2 Ethernet packet 189. An Ethernet packet 189 contains destination and source MAC addresses 182 and 183, an optional 802.1Q tag 184 for VLAN implementation, and an Ethernet field 185 (Ethernet II) used to specify the type of data link being used. or length specification according to IEEE802.3), and a frame check 186 including a 32-bit CRC checksum of the entire data link packet. The Ethernet packet 189 also includes a variable length MAC payload 187 used to encapsulate the SDNP content 1430 of the IP datagram.

Specifically, the MAC payload 187 includes an IP header 434 and an IP payload 435 including a transport-header 436 and an SDNP payload 1430.

IP header 434 depends on whether the IP datagram conforms to IPv4 or IPv6 as determined by protocol field 447 containing binary 4 or protocol field 448 containing binary 6. Both preambles 440 and 444 contain transport header flags 470 that are used to determine the Layer 4 transport method used, e.g., TCP, UDP or the maintenance functions ICMP and IGMP. Specifically, according to secure dynamic communication networks and protocols, TCP transport is used for software and data files, while UDP is used for real-time data such as VoIP and video. The length and format of the transport header 436 depends on the transport header 470. The IP header 434 includes IPv4 source and destination addresses 441 and 442 or IPv6 source and destination addresses 445 and 446.

The last mile routing of Ethernet packets depends on both the IP address and the MAC address, denoted by the example name of the device to which the IP or MAC address refers, eg MAC C _1,1 or IP M _0,0 . For brevity, a symbolic name representing a numeric address made according to the Ethernet formatted Internet protocol is used instead of the numeric address. It should be noted that the IP address IP C _1,1 follows different formats and uses different numbers of bytes for IPv4 and IPv6 names. Also, the format for the MAC address depends on the layer 2 data link protocol being used. Thus, the MAC address MAC C _{1, 1} for the cellular radio is not the same as the MAC address for the same device communicating using WiFi or Ethernet. A MAC address has nothing to do with an IP address, i.e. an IP address and a MAC address for the same client have nothing to do with it.

Sequential last-mile routing of Ethernet packets is illustrated in the example of FIGS. 50A-50D. Each figure contains two Ethernet packets - an upper Ethernet packet containing an IPv4 datagram and a lower Ethernet packet containing an IPv6 datagram. Because IPv4 and IPv6 use different formats with different field lengths, the two Ethernet packets shown are generally not the same length, even when carrying the same payload. In the first step of the communication sequence, SDNP payload (A) is moved from SDNP client 1400 to router 1402A via last link 1404 and then to SDNP gateway 1401 via gateway link 1414. . The response from the SDNP gateway to the client is the SDNP payload (G), which is moved from the SDNP gateway 1401 to the router 1402A via gateway link 1414 and then to the client 1400 via last link 1404. include SDNP client 1400 has numeric MAC and IP addresses MAC C _1,1 and IP C _{1, 1} , router 1402A has numeric MAC address MAC R, SDNP gateway has numeric MAC and IP address MAC M _0,0 and IP M _{0, 0} . The IP address of router 1402A is not used in data packets.

Unlike in the SDNP cloud, where SDNP datagram packet routing is fully controlled by the SDNP network, in last mile communications using IP datagrams, SDNP payloads cannot be interpreted or affect routing, which is This means that each communication carried has a fixed source and destination IP address. The physical media or channels used to direct Ethernet packets are governed by the MAC addresses linking each communication node within the last mile. For example, FIG. 50A shows a router 1402A that includes a source MAC address MAC C _1,1 , a destination MAC address MAC R , a source IP address IP C _1,1 , a destination address IP M _0,0 , and an SDNP payload. Shows IPv4 and IPv6 Last Link Ethernet packets used for a single PHY routing to 50B shows the corresponding Ethernet packet carrying the SDNP payload (A) across the gateway link 1414. As explained, the source and destination IP addresses remain unchanged at IP C _1,1 and IP M _0,0 , while the MAC source and destination addresses change from their original values to MAC R and MAC M _0,0 . It changes.

In response communication from SDNP gateway 1401 to client 1400, the SDNP payload (G) traverses the same network in response sequence, i.e. the source and destination addresses are swapped. As shown in FIG. 50C, the source and destination IP addresses include IP M _0,0 and IP C _1,1 , respectively, while the MAC address includes source address MAC M _0,0 and destination MAC R. In the last link communication shown in FIG. 50D, the MAC address is changed to the source address MAC R and the destination MAC C _1,1 , while the source and destination IP addresses are not changed to IP M _0,0 and IP C _1,1 .

One convenient means of representing a last mile communication from an SDNP client is to use a "abbreviated" data packet containing data fields containing source and destination MAC addresses, source and destination IP addresses, and the SDNP payload. The abbreviated form is convenient to describe the flow of data in any communication “session”, consisting of successive packets of data passed across the last mile to the SDNP gateway and their responses. For example, a sequence of Ethernet packets (shown in abbreviated form) sent from an SDNP client to a SDNP gateway is shown in the upper portion of FIG. 51A. Each row represents successive data packets containing SDNP payloads (A, B and C). The leftmost column shows data packets in the last link, while the right column carries the same payload across the gateway link. shows a data packet that As shown, every packet specifies IP C _{1, 1} as the source IP address and IP M _{0, 0} as the destination IP address. Since only one pair of IP addresses is used, the last mile is referred to herein as SDNP single path last mile communication. Also, since the source IP address used by the SDNP client 1400 to carry successive data packets does not change, the last link uses "fixed client addressing".

In order to facilitate layer 2 interconnection between each communication node to a neighbor, the MAC addresses in different segments of the last mile are essentially changed. As shown, all successive packets traveling across the last link from the client to the router use the source and destination MAC addresses MAC C _1,1 and MAC R. Since a single MAC address is used for clients in successive data packets, the last link includes a single physical media, i.e. a single PHY last link. Transport across the gateway link uses the source and destination MAC addresses MAC R and MAC M _0,0 respectively.

Thus, although the data packets shown contain SDNP payloads, routing over the last mile necessarily uses sniffable MAC and IP addresses - addresses that can be resolved by monitoring by unauthenticated listeners. By tracking packets with the same source and destination IP addresses, an unauthenticated listener knows that the data packets are likely part of the same conversation or session, and that even though they cannot open the SDNP payload, they still have the duration of the call, It can be assumed that metadata such as file size, data transfer rate, etc. can be collected to create a profile of the caller. Also, by following the MAC and IP addresses, metaphorically like tracing a trail, a hacker can potentially trace the origin of a call to an end device, i.e. a client device, and then personally identify the caller .

As disclosed herein, a better way to prevent client device tracking, to further obfuscate related call packets, and to prevent collection of metadata is to dynamically map MAC and IP addresses in last mile and last link communications. is to change it to This deception method of the present invention:

* Data packet transmission over a changing communication medium by dynamically changing the last link MAC address, referred to herein as "multi-PHY last link" communication;

* obscuring the caller by dynamically changing the identity of the IP address of the client device, referred to as “dynamic client addressing”;

* Changing the communication path of successive data packets over the last mile by dynamically changing the IP addresses of communications to and from different SDNP gateway IP addresses, referred to herein as "multi-path last mile" communications. to do

The combination of multi-PHY, dynamic client addressing, and multi-path last-mile communications makes tracking and detection of last-mile and last-link communications extremely difficult, since only SDNP callers and SDNP gateways can because it knows that it is part of These methods may be used separately or in combination.

For example, the lower half of FIG. 51A shows the use of multi-PHY last link communication in single path last mile communication with fixed client addressing. As shown, each row contains a pair of data packets used in communication from the SDNP client to the SDNP gateway - the left side represents a Last Link Data Packet and the right side represents a Gateway Link Data Package. The three rows represent three consecutive messages, the top row contains the first data set "SDNP payload (A)", the middle row contains the SDNP payload (B), and the bottom row contains the SDNP payload The third consecutive data packet containing (C) is described. In single path last mile communication with fixed client addressing, all successive data packets use a fixed client address IP C _1,1 and a fixed destination address IP M _0,0 .

In order to utilize multi-PHY last link communication, i.e. to route data in the last link across multiple physical media, the SDNP client's MAC address must change dynamically within sequential data packets. Each MAC address corresponds to a specific PHY layer, eg Ethernet 100BASE-T and 1000BASE-T connectivity. In the case of three physical media, the MAC address of the client is a packet that dynamically and continuously changes from MAC C _1,1 to MAC C _1,2 and then to MAC C _1,3 . If only two media can be used, the MAC addresses are: 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, 1} , etc. are changed to random patterns to prevent pattern recognition. While the source MAC address changes, the MAC destination for the last link may remain constant, namely MAC R. Since all of the multi-PHY paths of the last link terminate within the same router, the data path through the remainder of the last mile remains fixed as a single path communication. In other words, while the last link uses multi-PHY connectivity, the last mile enters the SDNP cloud through a single gateway, and the last mile involves single-path communication.

Although the multi-PHY approach provides some degree of deception, packets sniffing data packets from a particular call can still be identified because they share a common client IP address. This detection method is prevented by using dynamic client addressing - the act of a client changing its IP address with each packet it sends. As an example, FIG. 51B illustrates the use of client dynamic IP addressing in single path last mile communication. The top set of data packets represents a single PHY last link connection, while the bottom set of data packets describes a multi-PHY implementation. In SDNP single-path last mile communication, the destination IP address 442 of the SDNP gateway is fixed to the numeric value IP M _0,0 within every data packet, regardless of whether single-PHY or multi-PHY methods are used. maintain.

As shown, the dynamic client addressing data packet carrying the SDNP payload (A) uses a dynamically selected source IP address 441 containing IP C _{1, 1} , while the packet carrying the SDNP payload (B) The data packet uses a dynamically selected source IP address containing IP C _1,3 , etc., and the data packet carrying the SDNP payload (C) uses a dynamically selected source IP address containing IP C _{1, 3} . . The number of dynamically selected addresses is almost unlimited, especially in IPv6. Further, an IP address may be reused as long as a predetermined time, for example one second, elapses before the address is recycled. In the case of a dynamic client address with a single-PHY last link, although the IP source address changes, in this example MAC C _1,1 , the value of the source MAC address 183 remains constant. In the case of a dynamic client address with multi-PHY last link, the value of the source MAC address 183 changes continuously, changing from MAC C _{1, 1} to MAC C _{1, 2} and then to MAC C 1, ₃ . There is no particular numerical correspondence between a client's changing MAC address and its dynamic IP address.

Although dynamic client addressing appears to involve messages sent from different users, data packets still traverse most of the last mile (other than the last link in multi-PHY implementations) over a single path. A more advanced method to further confuse packing sniffing of last mile communications is to use "multi-path" communications. In multi-path communication, more than one SDNP gateway IP address is used to connect a client to the SDNP cloud. Because SDNP network routing is defined by the signaling server and uses an identifying SDNP tag on each packet, regardless of whether data enters the SDNP cloud through a single gateway or through multiple gateways, the SDNP cloud directs packets to their destination. can be routed. 51C illustrates the use of multi-path last mile communication with fixed client addressing. In every data packet shown within the last link, the client's source IP address 441 remains fixed at the numeric value IP C _1,1 , while the contiguous data containing the SDNP payloads A, B and C _The packet dynamically changes the destination IP address 442 from IP M _0,0 to IP M _{0,1 and} then to IP M _0,3 . The IP address of the SDNP gateway is not chosen randomly, but is "chosen" by the SDNP signaling server to represent a gateway temporarily proximate to the caller, i.e. the gateway with the minimum statistical propagation delay between the SDNP client and the particular SDNP gateway. In this example, the dynamic destination address changes regardless of the PHY connection. For example, the top set of data packets show a single PHY last link connection with the client source MAC address 183 for the last link with the numeric value MAC C _1,1 , while the bottom set of data packets show different media , e.g., a multi-PHY implementation that changes the MAC source address across MAC C _1,1 , MAC C _1,2 , and MAC C _1,3 . There is no corresponding pattern or numerical relationship between the MAC address of the client being changed and the destination IP address of the SDNP gateway.

The most effective degree of deception combines dynamic client addressing with multi-path last mile communication. This novel combination of security features is shown in FIG. 51D for the single-PHY last link implementation (shown in the top half of the figure) and for the multi-PHY last link version shown in the bottom half. In this fully dynamic version shown in the lower half, the source IP address 441 dynamically and randomly changes from IP _{C 1,1} to IP C _1,2 to IP C 1,3 _, while independently _The destination IP address 442 of the SDNP gateway changes from IP M _0,0 to IP M _{0,1 and} then to IP M _0,3 . The SDNP gateway address is chosen by the SDNP signaling server to minimize propagation delay while the dynamic client address changes in an unrelated manner. As in the previous example, the top set of data packets shows a single PHY last link connection with the client source MAC address 183 for the last link with the numeric value MAC C _1,1 , while the bottom set of data packets describes a multi-PHY implementation that changes the MAC source address across different media, eg MAC C _1,1 , MAC C _1,2 , and MAC C _1,3 . There is no corresponding pattern or numerical relationship between the MAC address of the client being changed and the IP address of the client or SDNP gateway being changed. However, in multi-path last mile communication, a multi-PHY last link may be advantageously connected to three distinct routers (R ₁ , R ₂ , and R ₃ ) instead of centralizing all data into a single router (R). can

The last mile deception as described above is located in top row #1 from the minimum secure implementation (shown at the bottom of the table as row #10) that includes a single path last mile with a fixed client address and single-PHY last link. Ten different cases, as summarized in the table of FIG. 52A, range up to better deception provided by multi-PHY last link with dynamic source addressing and multi-path last mile communication. Intermediate combinations are ranked in order of security. The notations (C _1,n ), (M _0,n ) and R _n refer to dynamically changing addresses for SDNP clients, SDNP gateways, and last link routers. Dynamic addresses are not calibrated. Rows 7 through 10 describe single-path last-mile communications, using a single gateway (M _0,0 ), while rows 1-6 describe multi-path last-mile communications with multiple gateways. Except for shaded rows 1 and 4, the last link communication is connected to a single router with a MAC address (R). In contrast, in multi-path communication, shaded rows 1 and 4 describe multi-PHY last link communication to multiple routers with dynamic MAC addresses (R _n ).

The operation of single-path last mile communication is in four combinations - fixed client addressing with single-PHY last link, fixed-client addressing with multi-PHY last link, dynamic client addressing with single-PHY last link, and multi-PHY. Dynamic-client addressing with last link - topographically shown in Fig. 52b. Each box shows three consecutive data packet communications showing the data path used. The solid line represents the data packet flow, while the dotted line depicts a potential path that is not utilized. Shaded circles represent communication nodes used in last mile communication, while empty circles represent unused communication nodes. As shown, all examples end up routing last mile data over a single connection between router R and SDNP gateway M _0,0 .

In the case of fixed client addressing across the single-PHY last link shown in the upper left corner, each successive packet takes the same path across the entire last mile using an unchanging IP address. In the case of fixed client addressing across the multi-PHY last link shown in the lower left corner, each successive packet takes a different path across the last link as defined by the dynamically changing MAC address. The remainder of the last mile contains a single route as specified by an unchanging IP address. Despite single-path transport, Last Link's changing physical media makes tracing the caller more difficult. In the case of dynamic client addressing across the single-PHY last link shown in the upper right corner, each successive packet is the same across the entire last mile with a constant client MAC address and an unchanging destination IP address for the last link. take the aisle Instead, deception is achieved by changing the identity of the client by changing the dynamic source IP address. In the case of single path communication with dynamic client addressing and multi-PHY last link, shown in the lower right corner, all packets are routed to a single SDNP gateway, but the MAC address and source IP address of the client are dynamically and randomly be changed

Dynamic client addressing is the process by which a client device uses one or more temporary ad hoc IP addresses. The process includes two stages. In the first stage, when a device logs onto the network for the first time, it registers its presence on the local subnet by contacting the nearest router. The router then redirects the connection to the nearest DHCP server on the same subnet. DHCP, an acronym for dynamic host configuration protocol (DHCP), is a network management protocol used to dynamically assign IP addresses. In the registration process, the client device downloads one or more IP addresses and stores the addresses in its communication data register. Until such time that the assigned IP address is updated by the local DHCP server, it uses this IP address whenever the client device communicates, either by starting a new session or requesting a new address. Because the address is dynamically generated within a specific subnet, the IP address of the client device is not an Internet address.

In the second stage, when a client device places a call or log into the SDNP network, the device automatically contacts the SDNP signaling server based on the SDNP server's static IP address. Upon receiving the received message, the SDNP server uploads the ad hoc IP address or addresses to the SDNP name server. The SDNP name server then assigns SDNP addresses as pseudo-code for each of the temporary IP addresses. In operation, immediately prior to routing, the packet's SDNP source address is replaced by its local ad hoc IP address. In the case of SDNP dynamic addressing, the identity of the client device is hidden by repeatedly sending packets whose source address changes. In this way, dynamic deception hides the true identity of the client device.

When the SDNP gateway arrives, the source address for outgoing packets discards the client IP address and substitutes the gateway server's SDNP address instead. Then, each outgoing SDNP packet exchanges the device's local IP address with its local ad hoc IP address immediately prior to transmission. Unlike Internet packet transport, where source and destination IP addresses are constant and required for a response, in SDNP transmission, each hop uses a new IP address. Accordingly, 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 notifies the destination device regarding the return path for a response.

The operation of “multi-path” last mile communication is topographically illustrated in FIG. 52C with four combinations of single-PHY and multi-PHY last links, as well as fixed and dynamic client addressing. With each multi-path communication, the destination IP address, i.e. the SDNP gateway, is constantly changing, meaning that the last mile path connects to different inputs to the SDNP cloud. In the left column, the client address remains fixed, meaning that the identity of the caller does not change. The upper left corner example uses a single-PHY connection for the last link, meaning that the MAC address for the client also remains static. Even though the communication takes place to different destination gateways, the unchanged last link physical media and the unchanged client IP address allow the last mile to be easily traced to the call. This vulnerability can be remedied by changing the last link medium used to transmit data packets or by disguising the true identity of the caller's IP address.

The lower left corner example uses a multi-PHY connection for the last link, meaning that the MAC address for the client changes dynamically. Such an approach compensates for the fact that the identity of the client retains a static IP address. As part of an end-to-end multi-path last mile communication, each specific last link connects to separate routers in the journey of successive packets to separate SDNP gateways. Thus, the first packet carries specific PHY media from the client with fixed address IP C _{1, 1} to the router with MAC address MAC R ₁ before finally being routed to the SDNP gateway with IP address IP M _{0, 0} . routed through In the second packet, the same client address IP C _1,1 is routed via specific PHY media to another router with media address MAC R ₂ before finally being routed to the SDNP gateway with IP address IP M _{0, 1} . Similarly, a third packet also with static client IP address C _1,1 is routed via specific PHY media to the router with media address MAC R ₃ , where it is subsequently routed to SDNP gateway M _0,3 do. The use of multiple routers opportunistically uses multiple PHY last links to forward last mile packets on entirely separate trajectories, despite using a client with a single source IP address.

In another embodiment, shown in the upper right corner, only one MAC address and PHY connection are used, but the identity of the client is dynamically changed. The IP address of the illustrated client dynamically changes from IP _{C 1,1} to IP C _1,2 to IP C 1,3 _, while the physical media is constant with source media address MAC C _1,1 and destination address MAC R are kept The data then continues to be routed to the gateways M _0,0 , M _0,1 and M _0,3 in random order as determined by the SDNP signaling server.

Greater security is achieved by combining all three methods of last mile deception, multi-path communication using multi-PHY last link and dynamic client addressing. This case is shown in the lower right corner of FIG. 52C, where data packets transmitted using multi-PHY last links and multiple routers are delivered from clients with dynamic IP addresses via multiple paths to multiple SDNP gateways. do. As shown, _{a first} packet from a client with a dynamic source network address IP C 1,1 can, via multiple paths, receive multiple paths defined by source and destination media addresses MAC C _1,1 and MAC R ₁ . -PHY It is transmitted to the destination IP M _0,0 using the last link. A second data packet from a client with a dynamically selected source network address IP C _1,2 is sent over multiple paths to a multi-PHY defined by source and destination media addresses MAC C _1,2 and MAC R ₂ . It is transmitted to the destination IP M _0,1 using the last link. Finally _, a _third data packet from a client with a dynamically selected source network address IP C 1,3, via multiple paths, is defined by the source and destination media addresses MAC C _1,3 and MAC R ₃ It is transmitted to the destination IP M _0,3 using the multi-PHY last link. In this way, the combination of the client IP address, the SDNP gateway IP address, the client's MAC address and the router's MAC all dynamically change in a random fashion, making call tracing and collection of metadata nearly impossible.

Concealment of client device IP addresses and confusion of last mile routing by dynamic IP addressing, multiple PHY transmissions and multi-path transmissions to multiple gateways can be determined by the client device or by the signaling server. The misleading process may be accomplished using random number generation or other pseudo-random algorithms. An important principle is that routing and transport changes cannot be predicted.

Two slightly less robust versions of last mile data transmission of Ethernet packets over multiple paths are shown in FIG. 52D , where the left diagram uses fixed client addressing and multi-PHY last link connectivity, while the right diagram also Indicates dynamic client addressing, with multi-PHY last link connectivity. The difference between this implementation and the multi-PHY version previously shown in FIG. 52C is that this version uses a single router R instead of spreading data transmission across multiple routers. Briefly, in multi-path transmission using a single router for last-link connectivity, sequential data from clients is spread across multiple physical media, i.e., multiple-PHY last links, and then re-collected by a single router (R). Multiple gateway links and from this common router to multiple SDNP gateways defined by distinct destination IP addresses, over the rest of the last mile including parallel sections of any other last mile (not shown).

As an adjunct to Ethernet, WiFi wireless communication can also be used for last mile communication between SDNP clients and SDNP gateways. WiFi communication requires data packets with three or four MAC addresses, two for radio links and one or two for wired network connections, and specifically uses Ethernet data packets. 53 shows the same WiFi packet format configured for SDNP last mile and last link communication. As an access point applicable to last link communication, only three 6B-length MAC addresses are required, specifically MAC address 1 field 235 for a receiving radio base station or "receiver", a transmitting radio base station or "xmeter" A MAC address 2 field 236 for the WiFi router, i.e. a MAC address 3 field 237 containing the MAC address of the wired network connection to the Ethernet or "net" is required. In operation, the numeric value of the MAC address loaded into the receiver and Xmeter data fields determines whether (i) it is a data packet received at the radio and forwarded to the Ethernet, or (ii) received data on the Ethernet that is converted to radio communication. To do so, it depends on the setting of the directivity to/from the DS. The MAC Address 4 data field 239 is optional and is used only when the WiFi device is used as a radio bridge in "radio distribution mode". While such a mode can be used in last mile communications over long distances, for example in the desert, as an alternative to cellular or microwave networks, the use of WiFi communications in SDNP last mile is generally not for SDNP clients. The focus is on the last link connection. Accordingly, the following description will focus on the access point mode for WiFi routers, with the understanding that the SDNP techniques herein are equally applicable in wireless distribution mode routing.

Similar to Ethernet data packets, preamble 230 and start frame delimiter (SFD) 232 contain Layer 1 data for synchronizing data and devices. The physical layer convergence procedure (PLCP) 232 includes a mix of layer 1 and layer 2 information (relevant packet length, data rate, error check in header, etc.). In accordance with the IEEE 802.11 standard, the remaining data field is a layer 2 containing frame control 233 specifying the WiFi version packet type, such as management, control, preservation, or "data", which is the type used in SDNP payload delivery. Contains data link information.

Duration and ID 234 includes the NAV duration, in case the WiFi device is not in power saving mode, in which case the field includes the station ID. NAV or Network Allocation Vector is a virtual carrier-sensing mechanism used for power saving in wireless communication systems. The NAV duration can be viewed as a counter that counts down to zero at a uniform rate, then it senses the media to determine if the radio is idle or still communicating. In idle mode, the counter repeatedly counts the NAV duration and checks to determine if any radio communication activity request interest has been detected. Sequence control or "sequence" field 238 describes the packet sequence and fragment numbers that define a layer 2 packet frame. Frame check 240 includes a 32-bit CRC checksum of the entire data packet, i.e. an error check data link tracker.

The WiFi payload 241 is a data field of 0B to 2,312B length used to carry the WiFi payload. In SDNP last mile communication, this field contains the IP datagram used in last mile communication, including IP header 434, transport-header 436 and SDNP payload 435.

The IP header 434 depends on whether the IP datagram conforms to the IPv4 or IPv6 protocol as determined by the protocol field 447 containing binary 4 or the protocol field 448 containing binary 6. Both preambles 440 and 444 contain transport header flags 470 that are used to determine the Layer 4 transport method used, e.g., TCP, UDP or the maintenance functions ICMP and IGMP. Specifically, according to secure dynamic communication networks and protocols, TCP transport is used for software and data files, while UDP is used for real-time data such as VoIP and video. The length and format of transport header 436 depends on transport header flags 470. The IP header 434 includes IPv4 source and destination addresses 441 and 442 or IPv6 source and destination addresses 445 and 446.

Similar to Ethernet data packets, the last mile routing of a WiFi packet depends on both the IP address and the MAC address, symbolically indicated by the name of the device to which the IP or MAC address refers. Sequential last-mile routing of WiFi packets is shown in the examples of FIGS. 54A-54D. Each diagram includes two WiFi packets - an upper WiFi packet containing an IPv4 datagram and a lower WiFi packet containing an IPv4 datagram. Because IPv4 and IPv6 use different formats with different field lengths, the WiFi packets shown are generally not the same length, even when carrying the same payload.

In the first step of the communication sequence, the SDNP payload (A) is transmitted as WiFi radio media from the SDNP client 1400 over the last link 1404 to the WiFi base station/router 1402W and over the wireline to the BS link 1415. ) to the router 1402X. Router 1402X then forwards the data packets over gateway link 1414 to SDNP gateway 1401. The response from the SDNP gateway to the client is sent by wireline from SDNP gateway 1401 to router 1402X via gateway link 1414, across BL link 1415 to WiFi router 1402W, and via the communication media contains the SDNP payload (G) that is moved across the last link 1404 to the client 1400 using the WiFi radio. SDNP client has numeric MAC and IP addresses MAC C _{1, 1} and IP C _{1, 1} , WiFi router 1402W has numeric MAC address MAC W, router 1402A has numeric MAC address MAC R , the SDNP gateway has numerical MAC and IP addresses MAC M _0,0 and IP M _{0, 0} . The IP addresses of WiFi router 1402W and wireline router 1402X are not required in the illustrated last mile communication.

In contrast to SDNP cloud, where SDNP datagram packet routing is fully controlled by the SDNP network, in last mile communications using IP datagrams, SDNP payloads cannot be interpreted or affect routing, which is This means that each communication carried over includes a fixed source and destination IP address. The physical media or channels used to direct WiFi packets in radio communications and to direct Ethernet packets in wireline communications are governed by MAC addresses connecting each communication node within the last mile.

For example, FIG. 54A shows the example used for a single-PHY radio routing to a WiFi router 1402W via the last link 1404, including an exmeter MAC address MAC C _1,1 and a receiver MAC address MAC W. Shows IPv4 and IPv6 last link WiFi packets. WiFi router 1402W also provides a BS link wireline 1415 routing to Ethernet router 1402X with a "net" MAC destination address MAC R. Layer 3 network routing involves only end devices, i.e. SDNP Client 1400 with IP address IP C _{1, 1} and SDNP Gateway 1401 with destination address IP M _0,0 . Unlike Ethernet data packets, WiFi packets contain three addresses - the Xmeter or source-radio MAC address MAC C _1,1 receiver or radio-destination MAC address MAC W, and the Ethernet "net" address MAC R. In this direction of data transfer, wireline router 1402X acts as a network destination for WiFi router devices. Thus, the WiFi data packet specifies two media: WiFi radio last link 1404, and Ethernet wireline BS link 1415. 54B shows the corresponding Ethernet packet carrying the SDNP payload across gateway link 1414. As explained, the source and destination IP addresses remain unchanged as IP C _1,1 and IP M _0,0, while the MAC source and destination addresses _{change from their original values to MAC R and MAC M 0,0 .} It changes.

Response communication involves swapping destination and source IP addresses, and adjusting MAC addresses accordingly. 54C shows IPv4 and IPv6 Ethernet packets for data transport from SDNP gateway 1401 over gateway link 1414 to wireline-based router 1402X. For layer 3 datagram information, the IP source address 441 contains the network address of the SDNP gateway 1401, i.e. IP M _{0, 0} , and the IP destination address contains the value IP C ₁ , 1, which is the address of the client. includes The MAC addresses for the gateway link Ethernet pack are MAC M _0,0 for the source address 183 and MAC R for the destination MAC address 182 .

54D shows IPv4 and IPv6 WiFi packets for wire line BS link 1415 and WiFi radio based last link 1404. Network layer 3 routing includes SDNP gateway 1401 address IP M _0,0 and SDNP client address 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 wireline source of the radio's incoming data, i.e., the numerical value MAC R of the router 1402X transmitting the data packet to the WiFi access point.

In the receiver mode previously shown in FIG. 54A, this field defines the Ethernet destination of data received as radio packets and converted to Ethernet packets. In the illustrated example, the "net" field 237 contains the same MAC address of router 1402X, i.e., MAC R, for both transmit mode and receive mode, indicating that the WiFi access point is a single unit for last mile connectivity. This means using an Ethernet router.

Optionally, in multipath communication over the last mile, a wireline router used to route, in receive mode, data packets received by the WiFi access point, in transmit mode, transmits data packets transmitted by the WiFi access point. It can be different from the one used for routing. For example, the network MAC address 237 for radio packets in receiver mode can have a numeric MAC address MAC R ₁ , while in transmit mode the data can be changed to a different router connection MAC R ₂ , which is This means that the BS link can optionally include multi-PHY implementations that vary in direction. In transmit mode, the last link WiFi packet used for single-PHY radio 1404 last link routing from WiFi router 1402W to SDNP client 1400 is Xmeter MAC address 236 with numeric value MAC W and a receiver MAC address 235 comprising the numeric value MAC C _1,1 . In this direction of data transmission, wireline router 1402A acts as a source of data transmitted by the WiFi router device. Thus, the WiFi data packet specifies two media: WiFi radio last link 1404, and Ethernet wireline BS link 1415.

Cellular networks represent another form of wireless communication that can be configured for SDNP last mile communication. Cellular networks re-partition incoming Ethernet packets into radio-specific media access control (MAC) packets. Data may be transmitted and received by time division (TDMA), code division (CDMA), or spreading of content across multiple sub-channel frequencies (OFDM). In the case of 4G/LTE communication based on OFDM or orthogonal frequency division multiplexing, layer 2 data packets are stacked across three different levels of all embedded service data units or SDUs in layer 2; Specifically, the lowest level is a PHY PDU 299 containing a single frame MAC SDU 304 with padding 305 spread over 20 time slots 300 containing a MAC header 303 and PHY layer 1 data. includes The MAC SDU 304 again includes a radio link control or RLC SDU 308.

Radio Link Control (RLC) is a Layer 2 protocol used in 3G (UMTS) and 4G/LTE (OFDM) based telephony. The function of radio link control is to respond to upper layer requests in one of three modes: acknowledged mode, unknown mode, and transparent mode, as well as error detection, error correction, duplicate detection, and specified It is to provide packetization of data according to the format. Packetization of data includes concatenation, segmentation, and reassembly of RLC SDUs along with rewriting and re-segmentation of RLC data PDUs. For example, after allocating time to implement the radio overhead function, the single frame RLC SDU 308 is inevitably limited in duration and data file size that it can use to carry the payload. Accordingly, the single frame RLC SDU 308 must be segmented and mapped to a different RLC layer 2 format - multi-frame RLC SDU 319.

As shown in FIG. 55, mapping a single-frame RLC SDU 308 to various K, K+l, K+2 segments 313, 314, 315, etc. of a multi-frame RLC SDU 319 is one It does not occur on a -to-one basis. For example, as shown, the mapping of the single-frame RLC SDU 308 ends in the middle of the K+2 segment 315. The untransmitted portion of the remaining K+1 segments is, instead, within a new single-frame RLC SDU 312, but only after allowing padding time 310 necessary for radio clock synchronization and after RLC header 311 processing. , is sent. In this way, transmission of the data encapsulated within K+2 slots resumes exactly, where it is left as if the data flow had never been interrupted. Optionally, 4G is similar to stopping playback of a DVD encoded movie in the middle of a DVD chapter, waiting a certain moment to perform some other function, and then resuming playback exactly where it stopped. Thus, the RF data transfer rate of the cellular system is maximized without losing any data content, no radio bandwidth other than packet overhead (such as PDU headers) is wasted, and data-rate degradation resulting from the clock synchronization padding time 310. is minimized.

The multi-frame RLC SDU 319 encapsulates the PDCP PDU 320 in a one-to-one correspondence with each K segment. For example, the Κth segment 313 carries an IP payload including a PDCP header 321A and data 323, and the (K+l)th segment 314 carries a PDCP header 321B and data ( 324), the (K+2)th segment 315 carries an IP payload including a PDCP header 321C and data 325, and so forth. The term PDCP is an acronym for Packet Data Convergence Protocol, as specified in 3G and 4G/LTE communication protocols, and implements functions such as compression, encryption, integrity assurance, as well as user and control data transfer. The PDCP header varies depending on the type of data being transmitted, eg user data, control data, and the like.

Because data transmissions within 4G data packets carry streams of data concatenated continuously, the payload size is not quantized into blocks of defined length as is the case with Ethernet and WiFi data packets. Instead, the data fields 323, 324, 325... carried by the corresponding layer 2 data segments 313, 314, 315,... are, as shown, transport-header 436 and Any size payload can be incrementally supported, including IP header 434 and IP payload 435, which includes SDNP payload 1430. Also, in OFDM-based communications, each time slot simultaneously carries data on multiple frequency subcarriers, which means that the total data throughput is not simply determined by the duration across a single channel, as in TDMA. means that However, for convenience, it is often convenient to keep the IP datagram size in line with the size of the Ethernet or WiFi standard.

As shown, IP header 434 determines whether the IP datagram conforms to IPv4 or IPv6 as determined by protocol field 447 containing binary 4 or protocol field 448 containing binary 6. varies depending on Both preambles 440 and 444 contain transport header flags 470 that are used to determine the Layer 4 transport method used, e.g., TCP, UDP or the maintenance functions ICMP and IGMP. Specifically, according to secure dynamic communication networks and protocols, TCP transport is used for software and data files, while UDP is used for real-time data such as VoIP and video. The length and format of transport header 436 depends on transport header bits 470. The IP header 434 includes IPv4 source and destination addresses 441 and 442 or IPv6 source and destination addresses 445 and 446.

As an example of 4G communication using IPv6 datagrams, FIG. 56A shows a cellular radio 1404 last link routed to a cell tower and base station 1402Q. Specifically, in the MAC source field 300A, the RLC PDU specifies a cellular source media address, such as MAC C _{1, 1} , which is the client's device. Similarly, the MAC destination field 300B specifies the cellular receiver media address as the MAC BS describing cell towers and base stations. Layer 3 network routing involves only the last mile end device, i.e. SDNP Client 1400 with IP address IP C _{1, 1} and SDNP Gateway 1401 with destination address IP M _0,0 , shown in the Source Data field. do. As described above, data fields 323, 324, and 325 do not necessarily correspond to specific sections of the IPv6 datagram data payload, and data field 323 includes an IP source address 445, an IP destination address ( 446), and the portion of the SDNP payload (A) 435 that includes the transport header 436. Data fields 324 and 325 carry the remaining untransmitted portion of the SDNP payload 435.

56B shows data packets for response message SDNP payload (G) over cellular last link 1404 from cell tower and base station 1402Q to mobile client device 1400, whereby the source from previous data packets and the destination address has been swapped, that is, the cellular source media address 300A is loaded with the media address MAC BS, the cellular destination media address 300B is set to MAC C _1,1 which is the MAC address of the client, and in the IPv6 datagram The IP source field 445 is set to IP M _0,0 , and the IP destination field 445 is set to IP C _1,1 . Routing between network router 1402X and cellular tower and base station 1402Q across BS link 1415 uses Ethernet data packets consistent with the previous example.

Multi-PHY communication over the last link may include any of the aforementioned media used in various combinations. A multi-PHY implementation is multiple wireline connections carrying data at the same or different data rates and using a common or distinct Layer 2 protocol such as USB, Ethernet 10BASE-T, 100BASE-T, 1000BASE-T, or DOCSIS3. can include Wireline physical media can include Ethernet or USB compliant network cables, coaxial cables, fiber optics, or even twisted pair copper connections for DSL, albeit at a reduced performance level.

Wireless multi-PHY communications may include WiFi, cellular, satellite, or a combination of proprietary radio formats operating in radio frequency and microwave bands. Wireless last link communication may also include short-range technologies such as Bluetooth or micro-cellular networks such as Japan's PHS. Wireless protocols include, for example, analog, TDMA, GSM, CDMA, UMTS, and OFDM, WiFi protocols such as 802.11a, 802.11b, 802.llg, 802.11n, and 802.11ac, as well as satellite communications or conventional radio cellular formats for 2G, 2.5G, 3G, and 4G/LTE, including proprietary formats for links. Since Layer 2 protocols vary with Layer 1 physical media, the term multi-PHY communication as used in the context of this disclosure refers to a combination of both the OSI physical and data link layers, i.e. Layer 1 and Layer 2. and should not be construed as limiting the scope of the claims to mean only Tier 1 physical media.

An example of multi-PHY communication using common Layer 2 protocols, including Ethernet, WiFi, and cellular implementations, is shown in FIG. 57A. In the top-level example of multi-PHY Ethernet, router 27 connects desktop computer 36 using two Ethernet cables, each containing wired or fiber links 24A and 24B with 100BASE-T and 1000BASE-T operating respectively. communicate to A desktop 36 is shown running SDNP software 1335C to facilitate hypersecure communications over the last mile.

In the central example of multi-PHY WiFi, WiFi router 100 communicates to laptop 35 over two WiFi channels, shown as WiFi links 29A and 29B, the former operating with the 801.11n protocol above 2.4 GHz. and the latter communicates over a 5 GHz channel using 802.11ac. To operate in multi-PHY mode, notebook 35 must be able to simultaneously transmit and receive signals on multiple frequencies using multi-band antenna 26B within the notebook. Similarly, a WiFi router should be able to simultaneously transmit and receive signals on multiple frequencies using multi-band antennas 26 . A notebook 35 is shown running SDNP software 1335C to facilitate hypersecure communications over the last mile.

In the lower example illustrating multi-PHY cellular communication, cellular base station 17 uses two different radio channels comprising cellular links 28A and 28B with corresponding frequencies of 1.8 GHz and 900 MHz to establish a multi-band cellular communication. It communicates simultaneously to the tablet 39 via the tower 18A. In the illustrated example, the cellular link includes a 4G/LTE network. As shown, tablet 39 should be able to simultaneously transmit and receive signals on multiple frequencies using internal multi-band antenna 18B. A tablet 39 is shown running the SDNP app 1335A to facilitate hypersecure communications over the last mile.

Such multi-PHY communication using a common Layer 2 protocol confuses cyber attacks, since a hacker must gain physical access to two different Layer 2 data links, each of which can contain its own security. In addition, when SDNP software 1335C, SDNP app 1335A, or SDNP firmware 1335B (not shown) is running on the client, routing of SDNP payloads across multiple-PHY connections can be performed in real time for real-time hacking. It uses specific dynamic security credentials that make interception and interpretation of SDNP packets very difficult.

An example of multi-PHY communication using mixed Layer 1 media and Layer 2 protocols is shown in FIG. 57B. In this example, last link data is implemented using a combination of cellular, WiFi, and satellite systems. In the top example of mixed media multi-PHY communication, the WiFi router 100 uses a combination of a 100BASE-T Ethernet wired or fiber link 24B and an 802.11ac WiFi link 29B operating at 5 GHz to connect to a desktop computer. Communicate with (36). A desktop 36 is shown running SDNP software 1335C to ensure hypersecure communications over the last mile. Such an example represents a combination of wireline and wireless communications, where wireless packet sniffing cannot intercept or observe wireline data. This mixed Ethernet + WiFi multi-PHY last link distribution method is particularly well suited for deploying corporate office networks that include secure desktop computers within buildings or campuses communicating to private servers locked in access restricted server rooms.

In the middle diagram of mixed-medium multi-PHY communication shown in FIG. 57B, cell phone 32 with internal multi-band antenna 18C communicates using two different radio technologies. One PHY connection, WiFi link 29C, communicates to WiFi router 100 and antenna 26 using, for example, the 802.11n protocol at 5 GHz. A second PHY connection, cellular link 28C, uses a 1.8 GHz carrier operating with 4G/LTE protocol to facilitate last link connectivity to cellular tower 25 and base station 17. Since cellular tower 25 and WiFi antenna 26 operate on unrelated systems, this multi-PHY approach completely obscures all relationships between data packets carried by multiple physical media within the last link. let it Cell phone 32 is shown running SDNP app 1335A to ensure hyper-secure communications over the last mile.

A similar method for achieving multi-PHY last link communication combining cellular and satellite is shown in the bottom diagram of FIG. Communicates across the network—cellular links 28D to cellular towers 25 and base stations 17 at 18 GHz, and satellite links 95W to communication satellites 92, for example at 1.9 GHz. Satellite 92 communicates with the terrestrial satellite antenna and base station 92B over wide bandwidth link 95X, again not necessarily on the same frequency as the client communication.

57C illustrates another variety of multi-PHY communication-multiple physical media that share a common protocol but are capable of multiple simultaneous communication channels using frequency division. Such systems require large bandwidth media for operation without significant loading effects, ie performance decreases as more users occupy the media's bandwidth and throughput capacity. Only three such media can readily exploit such large bandwidths: (i) a DOCSIS3 cable system using coaxial cable, (ii) a DOCSIS3 cable system using optical fiber, and (iii) a multi-GHz satellite communications system in low Earth orbit. can Specifically, the topmost diagram of the multi-PHY cable system shows the SDNP firmware 1335M communicating with the cable CMTS 101 using multiple bands via coax or fiber 105 running the DOCSIS3 protocol. Shows set top box or cable modem 102B in operation.

The bottom diagram shows a multi-PHY satellite network, in which a satellite-based cell phone 32Z running SDNP app 1335A communicates with satellites 92 using multiple carrier bands 95Z formatted with a proprietary communications protocol. communicate with Communication between the satellite 92 and the terrestrial satellite antenna and base station 92B utilizes trunk line protocol 95X intermixing thousands of calls, using multi-PHY communications across multiple bands within client link 95Z. While ensuring hyper-secure communications for this client, it makes it difficult for hackers to identify and interpret specific calls.

Another example of a data packet used in multi-PHY last link routing is shown in FIG. 58, where the SDNP client 1400 connects, for example, to an Ethernet wired or fiber link operating protocols 100BASE-T and 1000BASE-T, respectively. It communicates with router 1402A through two separate PHY connections including 24A and 24B. Router 1402A is connected to SDNP gateway 1401 again via gateway link 1414. Both Ethernet packets specify the source IP address 445, the client device as IP C _1,1 and the SDNP gateway's destination IP address 446 as IP M _0,0 . An Ethernet packet (A) routed across a PHY realized by wired or fiber link 24A has a MAC destination address 182 containing MAC R and a MAC source address 183 containing MAC C _{1, 1} include An Ethernet packet (B) routed across a PHY realized by a wired or fiber link 24B includes a MAC destination address 182 containing MAC R and MAC C _1,2 forming an alternate PHY connection. Other MAC source addresses 183 are included.

A change in the source media address from MAC C _1,1 to MAC C _1,2 redirects Ethernet communications from a 2.6 GHz 100BASE-T connection to a 1000BASE-T connection. In operation, data packets from the SDNP client device 1400 are fragmented and then allocated into SDNP payloads (A) and SDNP payloads (B), according to SDNP algorithms and shared secrets. Fragmented data transport across the multi-PHY last link is SDNP payload (A) accompanied by Ethernet packet (A) across wire or fiber link (24A) and Ethernet packet (B) on wire or fiber link (24B). It consists of an SDNP payload (B) accompanied by

Another example of a data packet used in multi-PHY last link routing is shown in FIG. 59, where the SDNP client 1400 uses WiFi using the protocols of, for example, 802.11n at 2.4 GHz and 802.11ac at 5 GHz, respectively. It communicates with WiFi router 1402W via two separate PHY connections comprising links 29A and 29B. Router 1402W is in turn connected to router 1402X via BS link 1415, and router 1402X is connected to SDNP gateway 1401 via gateway link 1414. Both WiFi packets specify the source IP address 445, i.e. the client device as IP C _1,1 and the SDNP gateway's destination IP address 446 as IP M _0,0 . The WiFi packet A routed over the PHY realized by the WiFi link 29A has an Xmeter MAC radio source address 236 including MAC C _{1, 1} , and a MAC radio receiver destination address including MAC W ( 235), and MAC network destination 237 including MAC R. The WiFi packet (B) routed across the PHY realized by the WiFi link 29B has an Xmeter MAC radio source address 236 containing MAC C _1,2 , and a MAC radio receiver destination address containing MAC W ( 235), and MAC network destination 237 including MAC R.

A change in the source media address from MAC C _1,1 to MAC C _1,2 redirects the transmission from the 2.6 GHz WiFi radio to the 5 GHz transceiver. In operation, data packets from the SDNP client device 1400 are fragmented and then allocated into SDNP payloads (A) and SDNP payloads (B), according to SDNP algorithms and shared secrets. Fragmented data transport across the multi-PHY last link is carried by SDNP payload (A) carried by WiFi packet (A) over WiFi link 29A and WiFi packet (B) on WiFi link 29B. It consists of the SDNP payload (B).

Another example of a data packet used in multi-PHY last link routing is shown in FIG. 60, where the SDNP client 1400 uses, for example, 4G/LTE at 1.8 GHz and 4G/LTE at 900 MHz protocols, respectively. to communicate with cell tower 1402Q over two separate PHY connections comprising cellular links 28A and 28B. Router 1402Q is in turn connected to router 1402X via BS link 1415, and router 1402X is connected to SDNP gateway 1401 via gateway link 1414. Both cellular radio packets specify the source IP address 445, i.e. the client device as IP C _1,1 and the SDNP gateway's destination IP address 446 as IP M _0,0 . A cellular packet (A) routed across the PHY realized by the cellular link (28A) is an Xmeter MAC radio source address (300A) containing MAC C _1,1 and a MAC cell tower destination (300B) containing MAC BS. ). A cellular packet (B) routed across the PHY realized by the cellular link (28B) is an Xmeter MAC radio source address (300A) containing MAC C _1,2 and _a MAC cell tower destination (300B) containing MAC BS. ).

A change in the source media address from MAC C _1,1 to MAC C _1,2 redirects the transmission from the 1.8 GHz 4G/LTE cellular radio to 900 MHz. In operation, data packets from the SDNP client device 1400 are fragmented and then allocated into SDNP payloads (A) and SDNP payloads (B), according to SDNP algorithms and shared secrets. Fragmented data transport across the multi-PHY last link is carried by SDNP payload (A) carried by cellular packet (A) over WiFi link 28A and cellular packet (B) on WiFi link 28B. It consists of the SDNP payload (B).

As noted above, multi-PHY communication may also involve different media. In that case, the data packets for each connection must be formatted according to the Layer 2 protocol for the corresponding physical media. For example, FIG. 61 illustrates hybrid last link communication including Ethernet and WiFi, where the SDNP client 1400 is Ethernet wired or fiber using, for example, 100BASE-T and 802.11ac at 5 GHz, respectively. It communicates with WiFi router 1402W via two separate PHY connections, including link 24A and WiFi link 29B. Router 1402W is in turn connected to router 1402X via BS link 1415, and router 1402X is connected to SDNP gateway 1401 via gateway link 1414. Both WiFi packets specify the source IP address 445, i.e. the client device as IP C _1,1 and the SDNP gateway's destination IP address 446 as IP M _{0,0 .} Ethernet (A) routed across the PHY realized by wired or fiber link 24A includes a MAC source address 183 containing MAC C _{1, 1} and a MAC destination address 182 containing MAC W do. The WiFi packet (B) routed across the PHY realized by the WiFi link 29B has an Xmeter MAC radio source address 236 containing MAC C _1,2 , and a MAC radio receiver destination address containing MAC W ( 235), and MAC network destination 237 including MAC R.

A change in the source media address from MAC C _1,1 to MAC C _1,2 redirects the transmission from Ethernet to WiFi. In operation, data packets from the SDNP client device 1400 are fragmented and then allocated into SDNP payloads (A) and SDNP payloads (B), according to SDNP algorithms and shared secrets. Fragmented data transport across the multi-PHY last link is accomplished by SDNP payloads (A) followed by Ethernet packets (A) over wired or fiber links (24A) and WiFi packets (B) on WiFi links (29B). It consists of an accompanying SDNP payload (B).

62 illustrates hybrid last link communication, including WiFi and cellular communication, where SDNP client 1400 spans two separate PHY connections to two different radio base stations, specifically 802.11n operation at 2.4 GHz. WiFi link 29A to WiFi router 1402W, which is connected, and cellular link 28B to cellular base station 1402Q with 4G/LTE operation over a 900 MHz carrier frequency. Routers 1402W and 1402Q are in turn connected to router 1402X via BS links 1415A and 1415B, respectively, and router 1402X is connected to SDNP gateway 1401 via gateway link 1414. Both WiFi and 4G cellular packets specify the source IP address 445, i.e. the client device as IP C _1,1 and the SDNP gateway's destination IP address 446 as IP M _{0,0 .} The WiFi packet (A) routed at the PHY layer through the connection including the WiFi link (29A) is an Xmeter MAC radio source address (236) including MAC C _1,1 and a MAC radio receiver destination (MAC W). address 235, and a MAC network destination 237 including the MAC R. Cellular B, routed as a PHY layer connection realized by WiFi link 29B, includes MAC source address 300B including MAC C _{1, 2} and MAC destination 300B including MAC BS.

A change in the source media address from MAC C _1,1 to MAC C _1,2 redirects the transmission from the WiFi LAN to the cellular network. In operation, data packets from SDNP client device 1400 are fragmented and then allocated into SDNP payloads (A) and SDNP payloads (B), according to SDNP algorithms and shared secrets. Fragmented data transport across the multi-PHY last link is carried by SDNP payload (A) carried by WiFi packet (A) over WiFi link 29A and cellular packet (B) on cellular link 28B. It consists of the SDNP payload (B).

Another form of multi-PHY communication involves a physical medium capable of supporting many channels of different frequencies and using a separate protocol for different data packets. Such an implementation may be facilitated using a DOCSIS3-based cable distribution system running SDNP software. The OSI communication stack for SDNP based DOCSIS3 cable distribution system is shown in FIG. For example, it includes an overlapping layer 3 network for both a cable modem CM 103 or set top box (STB) 102. Specifically, the cable modem end system device CMTS 101 and its associated stack 378 are connected to the cloud server 22 and the Internet 20 or alternatively to a video headend, IPTV system, or VoIP system (not shown). Layer 1 PHY network interface 361 connected thereto. The combination of network interface 361 and data link layer 366 is included within device interface communication stack 378 of CMTS 101 . At data link layer 2, data is passed from the network interface communication stack to the cable network interface communication stack via a forwarding function 370, specifically into a link level control (LLC) 369. The link level control 802.2 LLC 369 includes a hardware-independent protocol defined according to IEEE Specification 802.2. The packet data is then modified by link security 368 to provide rudimentary packet security and primarily to prevent unauthorized viewing of content such as pay-as-you-go unicast broadcasts.

Layer 1 PHY cable interface 362 then sends data frames to cable modem (CM) 103 or set top box (STB) over distribution network 102, including coaxial cable 104 or fiber optic 91. to the corresponding layer 1 PHY cable interface 363 in (102). Cable interface 363 represents the PHY layer of the cable network interface, shown as OSI communication stack 379 of cable modem (CM) 103 or set top box (STB) 102 . Upon receiving the data packet, the cable MAC interface 371 then interprets the cable MAC address, passes the payload to the link security 372 for decryption, and finally the hardware independent link layer control 802.2 LLC ( 373). The input data to the CM or STB cable network communication stack is then transmitted via transparent bridging 374 to the CM or STB device interface communication stack, specifically to the Device Independent Link Layer Control 802.2 LLC 375 according to specifications for IEEE 802.2. is forwarded to The packet is then passed to the HSD & IPTV MAC block 376 or WiFi 802.11 MAC block 377 to update the MAC address of the packet. In the case of WiFi communication, data packets are then passed from the 802.11 MAC block 377 to the WiFi PHY layer 1 radio interface 365 for transmission on the WiFi antenna 26. In the case of a wireline connection, data packets are then passed from the HSD & IPTV MAC block 376 to the Ethernet or HDMI interface block 364 for connection to the TV 39 or desktop 36.

The PHY and data link layers as described establish connections from the CMTS to any number of cable modems (CMs). Within the CMTS communication stack 378 and within the CM communication stack 379, data packets are routed to the OSI Layer 3 layers 360A and 360B using IP addresses recognized by the cable network or by DNS name servers in the Internet. ) are prepared as IP datagrams IPv4, IPv6 or ICMPv6, respectively. In last mile communications, SDNP datagrams using IPv4 or IPv6 data packets with SDNP source and destination IP addresses are generally not used, since connected devices that are not enabled by SDNP software or firmware can use the SDNP datagram routing address. because they do not have the ability to interpret

Transport layer 4 operation within a cable modem network is modified by the device. In the case of the CMTS 101, the layer 4 transport layer 1420 of the OSI communication stack 378 uses UDP exclusively because its operation requires real-time communication, e.g., streaming of video data. . From this point of view, cable communication 102 is more like an SDNP real-time network than is the case of the Internet. Since the cable modem has information processing interoperability with both the Internet and cable networks as a client, i.e. end communication device, the Layer 4 transport layer 1420B within the OSI communication stack 379 of the CM 103 or STB 102 is It uses UDP for operation and TCP for internet data. Such use is problematic for OTT carriers using VoIP over the Internet, where cable networks interpret IP datagrams as data, automatically using TCP and transport protocols and reducing real-time communication QoS, latency, and propagation delay. because it will do This problem does not occur with SDNP-based cable modems - if the CM or STB is the operating SDNP firmware or software, the SDNP software, contextually, when the use of TCP (for software and files) is guaranteed, and For real-time data, decide when not to.

The application layer, i.e. OSI Layers 5 through 7, sits on top of layer transport operation 1420A in CMTS 101 and on top of transport layer 1420B in CM 103 or STB 102. In the CMTS 101, these applications typically include communication tasks such as SNMP 1431A, an Internet-standard protocol for collecting and configuring information-connected devices over an IP network. Other functions include DHCPv4 (1432A) and DHCPv6 (1433A). DHCP, an acronym for Dynamic Host Configuration Protocol, is a protocol for both clients and servers to automatically supply IP hosts with the necessary routing information, including a dynamically generated (non-static) IP address, default gateway and subnet mask. . Although the function of dynamic IP address generation for Internet generation specific, i.e. IPv4 or IPv6, is common and DOCSIS3 cabling system for both CMTS (101) and CM (103) or STB (102), similar to NAT gateway or SNMP. equally applicable to

The secure dynamic communications network and protocol application layer implementation disclosed herein, when realized as SDNP firmware 1430A running on top of the CMTS 101 operating system, performs any number of specific tasks, including:

* Acts as a pass not interpreting the SDNP payload 1430 as the case where the CM 103 must be enabled to open and read the SDNP payload, i.e. the CM 103 must be a SDNP client.

* Acting as a last mile remote SDNP gateway, i.e. interpreting the contents of the SDNP payload and converting the contents into DOCSIS3 specific messages (including link security) for forwarding to the CM 103. In such a case, the CM 103 need not have SDNP client software or firmware running.

* Acting as a last mile SDNP bridge, converting IP datagrams to SDNP datagrams, and communicating SDNP datagrams to CM 103. In such a case, the CM 103 must run the SDNP client software or firmware to connect to the SDNP-Bridge, i.e. form an ad hoc SDNP "floating" network.

As shown, the OSI communication stack 379 for the CM 103 and the STB 102 is OSI Layer 5, including the aforementioned communication-related apps SNMP 1431B, DHCPv4 1432B, and DHCPv6 1433B. to a number of applications classified as Tier 7. Another function, utility TFTP 1434B or "Small File Transfer Protocol", is primarily used in DOCSIS3 as a means to download software from CMTS over cable networks to cable modems and set-top boxes and to perform software updates. In cable networks, HTTP 1435B or hypertext delivery protocol is primarily for painting dynamic menus useful in smart TVs. Other applications (denoted "Otr" 1436B for short) include gaming apps, diagnostics, IPTV apps, video recording functions, and others. SDNP firmware 1430B running on CM 103 or STB 102, regardless of whether CMTS 101 is running SDNP software, extends all hyper-secure last mile communications to users and last links. let it

64 shows the structure of a DOCSIS3 data packet configured to carry SDNP payload 1430. As shown, PHY Layer 1 is of variable length and duration, comprising Data Link Layer 2 MAC data comprising a preamble 391, a variable length payload or codeword 392 and a guardtime 393. Physical media device frame 390. The preamble 391 includes an upstream preamble or a downstream preamble, depending on the communication direction. In the case of the upstream preamble, the preamble 391 includes a physical media device PMD header 398, a MAC header 399A and a data PDU 400A. In the case of a downstream preamble, the preamble 391 includes an MPEG header 401, a MAC header 399B and a data PDU 400B. The data PDU 400A in the upstream preamble and the data PDU 400B in the downstream preamble include a MAC destination address (DA) 403B and a MAC source address (SA) 403A. The contents of the variable length payload 392 may include short codewords 394 or long codewords 397.

Short codeword 394 includes payload 395A containing data A and error correction 396A containing FEC A. In the case of a long codeword 397, the payload is divided into multiple payload blocks 395A, 395B, and 395C, each carrying data A, data B, and data C, respectively. The payload of A contains its own error checking blocks 396A, 396B, and 396C containing the corresponding data (FEC A, FEC B, and FEC C). After error checking, data transferred from DOCSIS3 includes data blocks 395A, 395B and 395C in case of long codewords and only data block 395A in case of short codewords. The combination of data (A), data (B), and data (C) includes an IP source address (445), an IP destination address (446), and a transport header (including the SDNP payload 1430 and layer 4 data). 436), which is merged into an IPv6 datagram in this example. In this way, DOCSIS3 uses a packet-switched data protocol to deliver data resiliently over cable networks.

As shown in FIG. 65A, data packets are carried in multiple channels across the hybrid cable-fiber network, i.e., on different frequencies. In DOCSIS 3.0, data channels range from 5 MHz to 1,002 MHz, including analog TV signal 1440 (triangle), QAM data 1441, and "diplexer" control channel 1443. In phase 1 of DOCSIS 3.1, the frequency range is extended to 1,218 MHz, and in a frequency band exceeding the existing channels allocated primarily to QAM, a DOCSIS3.1 data channel 1442 is added to help with OFDM modulation.

OFDM is preferred over the QAM modulation method because the channels can be spaced more tightly. Comparing the modulation schemes, the QAM frequency distribution 1445A exhibits a broader tail in spectral content than the OFDM frequency distribution 1445B. Specifically, the spectral sideband width from f ₀ to f _-50 , that is, the width from the carrier edge to the frequency at which the signal is dropped by -50 dB is 4.3 normalized frequency unit widths in the QAM frequency distribution 1445A, or the OFDM frequency distribution ( 1445B) is only 0.4 normalized frequency units wide. Because the spectrum width is narrower, more communication channels can be packed into the same spectrum to increase the overall bandwidth and maximum aggregate data rate of the network. In the Phase 2 deployment of DOCSIS 3.1, the frequency range is extended to 1,794 MHz.

Many of the bands originally allocated for QAM data 1441 are replaced with new channels explicitly allocated for OFDM data 1442.

In a DOCSIS-based cable network, one CMTS unit supports many CMs managing available channels. Although the CMTS can allocate downstream communications and dynamic channel selection as needed, upstream communications require contention management to help when multiple CMs are attempting to send data simultaneously. Therefore, each modem must request an uplink channel from the CMTS before transmitting data. This process is shown in Fig. 65B, which includes a sequence of communication operations between the CMTS 101 on which the SDNP App 1335L is running and the CM 103 on which the SDNP firmware 1335M is running. The routing of IP datagrams in multi-PHY communication is performed using IP addresses "IP CMTS" and "IP CM1" and multiple MAC addresses, e.g. "MAC CM1" for CM 103 and "MAC" for CMTS 101. CMTS1", "MAC CMTS2", "MAC CMTS3", and "MAC CMTS4" are used. In the topmost diagram showing a graph of frequency versus time, CM 103 transmits a request to transmit RQST 1445A on a designated channel.

If there is no response, a second RQST 1445B is transmitted, resulting in a response from the CMTS 101 on a different channel in the form of a MAP data packet 1446. The content of MAP data packet 1446 instructs CM 103 when to transmit and which channel to use for its upstream communication. After receiving MAP data packet 1446, CM 103 simultaneously transmits its upstream data spread over two channels in uplink data packets 1447A and 1447B. The division of simultaneously transmitted data across the two channels shown in the center diagram is referred to as channel bonding. Channel bonding is a means by which the communication bandwidth and data rate between the CMTS and CM can be increased. It is also a dynamic method to ensure that unavailable bandwidth is not used. In the bottom diagram, CMTS 101 responds by channel bonding four channels, namely 1448A, 1448B, 1448C, and 1448D, and transmitting data simultaneously but of different durations.

For both upstream and downstream communications across hybrid fiber-cable networks, bandwidth is dynamically allocated between multiple channels, divided into small time segments called "minislots". 65C shows upstream communication from CM 103 to CMTS 101. Such upstream communication typically includes messages or requests to transmit. In this example, data is transmitted over frequencies f ₁ and f ₂ comprising a total of 5 time minislots. As shown, minislots 1, 2, and 3 are transmitted at frequency f ₁ during intervals K, (K+l), and (K+2), while minislots 4 and 5 transmit at intervals (K, (K+l), and (K+2)). It is transmitted on frequency f ₂ during K and (K+l)), but not during interval K+2. Upstream data packet 1450A, shown in simplified form, has the IP source address "IP CMl" of the last mile communication and the IP destination address, i.e., "IP M _0, " which is the gateway node of the SDNP network hosted by server 1201A. ₀ "specified.

In last link communication, upstream data packet 1450A specifies “MAC CM1” as the source MAC address of the cable modem and the PHY media, in this case the channel of frequency f ₁ as the MAC destination “MAC CMTS1”. . Data packet 1450A containing SDNP payload (A), although carrying a single data packet and payload together, occupies a total of three minislots: minislots 1, 2 and 3. In contrast, minislot-4 and minislot-5 each contain only a single data packet, namely 1450B and 1450C with SDNP payload (B) and SDNP payload (C), respectively. Like data packet 1450A, both packets 1450B and 1450C specify the destination IP address of the SDNP cloud, specifically the SDNP gateway node M _{0,0 .}

However, in the MAC destination address, instead of specifying the same MAC address and physical media as the first packet, both packets 1450B and 1450C specify the MAC destination address of "MAC CMTS2". Using these addresses, data packets 1450B and 1450C should be followed on a different frequency than data packet 1450A—in this case, frequency f ₂ , not frequency f ₁ . The actual value of the frequency is dynamically mapped by the CMTS 101 and is not specifically identified. Thereby, a DOCSIS3 based system represents a multi-PHY solution whereby a single CMTS unit can simultaneously communicate to a cable modem or set top box across multiple frequencies and using multiple protocols such as 256 QAM or OFDM.

SDNP client CM (103 ) specifies different MAC destination addresses, forcing communication across multiple frequencies and channels, i.e., forcing multi-PHY operation. Because the CM 103 data packets 1450A and 1450B/C specify different destination MAC addresses, MAC CMTS1 and MAC CMTS2, respectively, the data packets automatically perform multi-PHY operation across the last link. Alternatively, if the CMTS promotes other means of requesting specific channel assignments, e.g. using command and control requests, the use of MAC addresses to effect multi-PHY communication may be replaced by other means. can

65D shows downstream data from CMTS 101 to CM 103, showing the use of bonding to achieve large data rates in multi-PHY downstream communications. As shown, every data packet specifies an IP address of "IP CMTS", a destination IP address of "IP CM1", and a MAC destination address of "MAC CM1". Multi-PHY communication is controlled by the specification of the MAC source address of the CMTS (101). As shown, data packet 1450G containing SDNP payload (G) has a MAC source address “MAC CMTS6” corresponding to communications at frequency f ₆ carrying data in minislots 15 and 16. to be specific Data packet 1450H contains an SDNP payload (H) and specifies a MAC source address “MAC CMTS7” corresponding to communications at frequency f ₇ carrying data in minislots 17 and 20. Data packet 1450I containing SDNP payload (I) specifies the MAC source address “MAC CMTS8” corresponding to communications at frequency f ₈ carrying data in minislots 21, 22 and 23 . Finally, data packet 1450J containing SDNP payload (J) specifies the MAC source address “MAC CMTS9” corresponding to communications on frequency (f ₉ ) carrying data in minislot numbers 24 and 25. do. In this way, related and unrelated data packets can be transmitted simultaneously from CMTS 101 to CM 103 using a multi-PHY method without channel contention or data collisions with concurrent upstream data.

HyperSecure Call Routing — HyperSecure Call Routing built in accordance with the disclosed secure dynamic communications networks and protocols may be implemented using one of the following three methods for command and control.

* Triple-channel communications, where the routing of calls or communiques consists of three sets of servers: SDNP Media Servers for carrying audio, video or data files; controlled using an SDNP signaling server for selecting routing of calls, and an SDNP name server for storing dynamic mappings of phone numbers to their corresponding SDNP addresses;

* As a dual-channel communication, routing control of a call or communique is carried out by two sets of servers: SDNP media servers for carrying audio, video or data files; and an SDNP signaling server for routing calls and performing functions of the SDNP name server for mapping phone numbers to their corresponding SDNP addresses;

* As a single-channel communication, data transfer, path planning and SDNP address maps are all implemented with a single set of servers.

In general, tri-channel communication provides greater immunity to cyber-attacks, since one set of servers does not contain all information about a call. In all cases, however, SDNP networks use distributed processing to limit the information contained within any given server. Also, during data delivery in single-, dual- or triple-channel communication, the SDNP media server is connected to a fourth type of server - the DMZ server. The DMZ server is used to accommodate SDNP shared secrets needed to process SDNP data payloads, including scrambling, splitting, mixing, junk data insertion and removal, and encryption. In operation, incoming data packets received by the media server are forwarded to the DMZ server, where the data packets are modified and forwarded back to the media server. The media server does not know how the data packets have been modified or what logic or algorithms have been used to process the data. Executable code and tables stored on the DMZ server are encrypted to prevent analysis of the code. Also, the DMZ server operates offline without being connected to the network or the Internet.

The figure below shows one example implementation of a sequence used in tri-channel SDNP communications and initiation of a call or transmission of a file across a network. The operation of dual-channel communication can be regarded as a minor modification to triple-channel communication, where the SDNP name server function is merged into the signaling server. Single-channel communication involves integrating all three operations into a network of multifunction servers acting as SDNP communication nodes.

Although fragmented data transmission within the SDNP cloud is generally carried out using dynamically meshed routing, last mile communication specifically involves sending successive data packets (i) to a single SDNP gateway, i.e., as single-path last mile communication. routed, or alternatively (ii) routed to multiple SDNP gateways, i.e., as multi-path last mile communication. Other last mile routing options include dynamic source addressing and multi-PHY last link connectivity. These delivery options are specified within IP data packets generated within the Signaling Server. Despite the fact that these SDNP data packets specify their source and destination IP and MAC addresses, the exact path a particular data packet will take in the last mile is unknown. Instead, the intermediate path is determined by the operation of the router, the device owned by the local network operator, the mobile network operator, and the network service provider serving the last mile, and not by the SDNP signaling server. Thus, last mile communication is similar to a jump rope, where the two ends are fixed but a specially shaped labyrinth of passages connects them.

To reiterate succinctly, the terms single-path, multi-path, and meshed-path communication refer to the passage of media packets, i.e., passage "content" traversal between callers, while triple-channel, dual-channel The terms , , and single-channel communication refer to the command and control system used to control transmissions across a network of SDNP nodes. In view of the foregoing, the set of figures below depicts a sequence of steps, or “processes,” used to initiate a call or initiate a communiqué in accordance with the disclosed secure dynamic communications networks and protocols.

66 shows a single-channel communication for tri-channel communication including SDNP Client 1600, IP Routers 1602A, 1602B, and 1602C Signaling Server 1603A, SDNP Name Server 1604A, and SDNP Gateway 1601. Schematic diagram of route last mile network. These computer servers are network nodes as shown including SDNP client C _1,1 , router (R), SDNP signaling server node (S), SDNP name server node (NS), and SDNP gateway node M _0,0 Hosts an SDNP communication node used to facilitate network communication with a name and IP address. Network connection 1610 facilitates a last link between client C _{1 , 1} , and its nearest router 1602A; network connection 1611 facilitates a gateway link between SDNP gateway M _{0, 0} and its nearest router 1602B; network connection 1612 facilitates a gateway link between SDNP signaling server 1603A and its nearest router 1602C; Network connection 1616 is interconnected to geographically adjacent routers 1602A and 1602C. Because a router's IP address is not used as a source or destination address in an IP datagram, the term "R" is shared by all routers on layer 3. In the case of layer 1 and layer 2 descriptions, each router has a specific identity, but this aspect is not relevant to the description of IP network layer 3 call routing. The SDNP Signaling Server 1603A (Node S) is connected to the SDNP Name Server 1604A (Node NS) via a network connection 1613 and to the SDNP cloud node M _0,n via a number of network connections 1614. . Signaling server 1603A is also coupled to other signaling servers (not shown) via network connection 1615 .

Using the SDNP network, placing a call, or establishing a "session", involves the following sequence of steps initiated by the SDNP client making the call, i.e., the "caller":

1. SDNP call (or call out) request

2. SDNP address request

3. Send SDNP address

4. SDNP routing instructions

5. Initiate an SDNP call (or call out)

The first step, "call request" is schematically shown in FIG. 67, where the caller, client 1600 with address "IP C _{1, 1} ," has IP datagram 1620 on channel 1610. , 1616, and 1612 with the signaling server 1603A at address “IP S”. The command and control payload 621 of the datagram includes Layer 4 data transmission using TCP to ensure data accuracy, delivery, urgency, security credentials, and contact information of the "called party" being called. Specifies a number of requested currency parameters, including In the case of a call to another SDNP client, or "SDNP call", this contact information includes the called client's credit identification (CID), which is data that exists within the client's SDNP phone directory. In the case of a “call out”, a call to a party other than the SDNP client, the contact information includes a phone number. While the SDNP client's CID is essentially anonymous and known only to the SDNP name server, the phone number is not obscured. To protect the privacy of the called party, the phone number in the C&C payload is encrypted. Alternatively, the entire C&C payload 1621 may be encrypted. While the C&C payload 1621 may be in the form of ciphertext, the IP address of IP datagram 1620 cannot be encrypted, in which case routers 1602A and 1602C cannot route the datagram.

The second step, “Request SDNP Address,” is shown in FIG. 68, where an SDNP signaling server with address “IP S” via path 1613 with IP datagram 1622 addresses “IP NS” Contacts the SDNP Name Server at The datagram's command and control payload defines Layer 4 data transfer as TCP and contains the CID or encrypted phone number of the party being called. In the case of SDNP calls, name server 1604A translates the CID into the SDNP address of the client being called. In the case of a call out, name server 1604A decodes the phone number of the called party and translates it to the SDNP address of the SDNP gateway closest to the called party's location. As shown in Figure 69, Name Server 1604A then forwards the client's SDNP address or gateway in IP datagram 1623 at address "IP S" from source address "IP NS" to Signaling Server 1603A. .

Signaling server 1603A then uses the SDNP addresses of the calling party and the called party to place the call between them, either as a hyper-secure connection if the called party is an SDNP client, or as a closest connection if the called party is not an SDNP client. Route to the SDNP gateway. The process used to prepare routing instructions and distribute them to all media nodes needed to complete a caller's connection is shown in FIG. As shown, the caller's delivery request contained in the delivery and urgency fields of the C&C payload 1621A, once validated with respect to the account information, is a method of delivery of datagrams, as shown by operation 1650. is used to select Delivery methods, including normal, VIP, guaranteed, or special delivery, affect the routing of packets or sub-packets (if packets are fragmented or fragmented). In VIP delivery, for example, the fastest path is used for data transmission, while loading of the same path by other clients is minimized. In guaranteed delivery, duplicate data packet fragments are sent across the network, i.e., using redundancy, to ensure timely delivery of the earliest packet and disregarding late arrivals. Operation 1651 then, combined with SDNP address data from C&C payload 1623A, maps the optimal route from the caller to the called party's SDNP address, or to the nearest gateway if the called party is not a SDNP client. do. Propagation delay reduction in order, using urgency request data included in C&C payload 1621A - package emergency operations 1652, including snail delivery (no rush), normal delivery, priority delivery, and urgent delivery ) is selected.

The urgency request information is then used to select a route and zone for sub-packet routing by operation 1653. These parameters, along with any applicable security credentials 1621B, are combined through operation 1660 to synthesize routing command and control packets. These C&C data packets are delivered to participating communication nodes in the last mile using TCP-specified layer 4 transport, but contain routing information using UDP as its layer 4 transport protocol when used in real-time data delivery. For example, a last mile routing made according to zone (U1) security credentials includes a C&C payload 1626 used to route data from client node C _1,1 to SDNP gateway node M _0,0 . It is generated as IP datagram 1625. IP datagram 1625 is delivered to the SDNP client using TCP data transport, but C&C payload 1626, referred to as "Last Mile Routing U1", contains the data used to route the packet in real time, Layer 4 requires the use of UDP as a transport mechanism. The SDNP C&C packet composition operation 1660 also creates many other C&C messages that are delivered to nodes in the SDNP cloud as TCP data packets. One example of a cloud-directed data packet is IP datagram 1627A containing a C&C payload 1628A used to route data from SDNP M _0,0 to SDNP M _0,1 . As shown in FIG. 71 , this SDNP routing indication packet is sent to media nodes including client node C _1,1 over serial connections 1612, 1616, and 1610, and to SDNP gateway node M over connection 1614. _0,0 and distributed to other nodes within the SDNP cloud.

The start of a call is shown in FIG. 72 , where a media SDNP datagram 1630 containing SDNP data, e.g. sound, video, text, etc., is placed over an IP header containing a C&C data packet 1626. Attached, IP C _1,1 to IP M _0,0 from SDNP client 1600 via last link network connection 1601 to routers 1602A and 1602B and finally across gateway link 1611 to SDNP gateway Routed to 1601. The identification tag, security area, preamble, and SDNP data fields together make up the payload of the SDNP media packet contained within media SDNP datagram 1630.

The routing of the aforementioned SDNP call involving mobile phone 32 running SDNP app 1335A, i.e. hypersecure call from SDNP gateway M _0,0 to SDNP client C _7,1 , is shown in the simplified network diagram of FIG. 73A. is shown as SDNP datagram 1631A, including media SDNP payload (A) and header 1628A, is routed between media nodes with SDNP addresses M _0,0 and M _0,1 . It should be noted that the SDNP gateway 1601 has two addresses - an IP address "IP M _0,0 " for last mile communication, and a SDNP address "SDNP M _0,0 " for communication within the SDNP cloud. The content of each SDNP datagram changes as the packet traverses the SDNP cloud, and accordingly the contents contained within SDNP media payloads (A, B, and C) - sound, video and text are distinctly different, 20 It may include content from several different conversations or communiques. Mechanisms of data routing and packet security within the SDNP cloud are disclosed in U.S. Application Serial No. 14/803,869 entitled "Secure Dynamic Communication Network and Protocol", which includes content and encryption of data packets moving anonymously through the SDNP cloud. Describes how β changes dynamically and continuously and converges only within the client's device.

Thus, SDNP datagram 1631B, including media SDNP payload (B) and header 1628B, is routed between media nodes with IP addresses M _0,4 and M _0,f . Data exiting the SDNP cloud via the SDNP gateway 1601B is converted from SDNP datagrams to IP datagrams 1632. IP datagram 1632 with header 1628C and SDNP media payload (C) uses security credentials for zone U2, which is the zone that contains the last mile. IP datagram 1632 is then routed through the last mile via wired or fiber link 24 to network router 27, then via cellular network 25 and cellular link 28 to cell phone 32 ) is routed to Since cell phone 32 is an SDNP client, communications over the last mile remain hypersecure. In this simplified example, all data packets exiting the cloud on the last mile are routed from a single SDNP gateway 1601B. In practice, more than one SDNP gateway may be used in last mile data routing.

Last mile communication for a “call out” is shown in FIG. 73B . Although routing through the SDNP cloud uses the same SDNP datagrams 1631A and 1631B as in calls to the SDNP client, the SDNP gateway 1601B is the last server running the SDNP software. Accordingly, last mile communication in call out uses IP datagrams with non-SDNP payloads, i.e. IP datagram 1635 is sent from IP address IP C _7,9 to gateway IP M _0,0 to PSTN. and carries voice in the form of VoIP. The PSTN then uses the phone # and analog sounds in sound packet 1636 to convert the VoIP call format into a normal phone number. In such cases, the last mile does not constitute hypersecure communication.

In the multipath last mile communication shown in FIG. 74, command and control data packets distributed by SDNP signaling server 1603A are C&C data packets 1625X transmitted over data links 1612 and 1610 to client 1600. , C&C data packet 1627X sent over data link 1614X to SDNP gateway 1601X, and C&C data packet 1627Y sent over data link 1614Y to SDNP gateway 1601Y. Other C&C data packets (not shown) are sent over data link 1614X to other servers hosting media nodes. From address "IP S", C&C data packet 1625X is sent to address "IP C _{1, 1} " The last mile routing (U1) has two different routing instructions - a routing instruction from "IP C _1,1 " to "IP M _0,0 " with tag 1 and preamble 1, and "IP C with tag 2 and preamble 2" _{. 1,1} " to "IP M _0,1 ". A C&C data packet sent to a communication node in the SDNP cloud, shown as an example, is sent from "IP S" to "IP M _{0, 0} " with the indication SDNP cloud routing 1, and SDNP cloud routing 2 included. including those transmitted as "IP M _0,1 ".

SDNP Group Call —shown in FIG. 75A , the routing of last mile media packets from an SDNP client 1600 to multiple SDNP gateways includes respective headers 1626X and 1626Y and SDNP media payload SDNP data ( X) and two data packets 1630X and 1630Y containing SDNP data (Y). Data header 1626X with tag 1 and preamble 1 is routed from address “IP C _1,1 ” to “IP M _0,0 ”, while data header 1626Y with tag 2 and preamble 2 is routed to address “IP C _1,1 " to "IP M _0,1 ".

As shown in FIG. 75B, data flowing in the reverse direction from the SDNP cloud to the client using multi-path communication includes header 1626U, tag 8, preamble 8, SDNP data (U), source address SDNP gateway address M _{0, 0} and destination address “IP C _0,0 ”. At the same time, data is also sent to data packet 1630V, which includes header 1626V, tag 9, preamble 9, SDNP data (V), source address SDNP gateway address M _0,1 , and destination address “IP C _0,0 ”. includes Then, the SDNP application program running on the SDNP client 1600 combines the received data packets SDNP data (U), SDNP data (V), and others to recreate the message text or voice (sound).

C&C data packet delivery of routing instructions can be extended to initiate three-way or group calls, group messaging, and other multi-client communications. In such group communiques or “conference calls,” client messages are sent simultaneously to multiple recipients. This group function is initiated by a caller, and the caller's request for a group call first specifies the group of clients it wishes to contact, and then, by the signaling server, how to handle the routing of data packets associated with that particular group call. , points to the requested media node. An example of a group call routing instruction is shown in FIG. 76, where signaling server 1603P routes routing instructions to SDNP client 1600A over data link 1614A and over data link 1614Z to a number of media within the SDNP cloud. It communicates with the server 1600Z.

Accordingly, the TCP data packet 1627A containing the last mile routing (U1) is delivered from the signaling server 1603P at address “IP S1” to the SDNP client at address “IP C _1,1 ” to communicate with the caller. "set up" a group call for The C&C data packets provided by the example TCP data packet 1627Z are sent over data link 1614Z from the signaling server address “IP S1” to the various destination addresses “IP M _0,y ” to the SDNP cloud for zone Z1. Distributed simultaneously throughout the whole, where y represents an integer variable. Collectively, the SDNP cloud routing instructions establish packets routed from the caller's gateway through the entire SDNP cloud to two or more other SDNP gateways located closest to the calling SDNP client.

As shown by way of example, different SDNP clients may be located in different geographic areas and may be in separate security zones, for example zones U7 and U9. In some cases, these clients may be far enough away from signaling server 1603P that another signaling server 1603Q may be used to plan packet routing for these SDNP clients. Signaling server 1603Q communicates routing instructions within zone U9 to SDNP client 1600M over data link 1614M and to SDNP client 1600L over data link 1614L. C&C data packet 1625M communicates a last mile routing instruction (U9) from the signaling server, eg, located at “IP S4” to SDNP client 1600M, located at address “C _9,1 ”. Another C&C data packet (not shown) is similarly sent to the SDNP client located at address "IP C _9,4 ". Data packet 1627H containing instructions for last mile routing (U7) is sent over data link 1614H from signaling server 1603Q located at “IP S4” to a client located at address “IP C _7,1 ”. (1600H).

Signaling servers 1603P and 1603Q located at nodes S1 and S4 also exchange information as C&C data packets over data link 1613z. This information configures which parts of the routing will be done by signaling server 1603P and which parts will be done by signaling server 1603Q, essentially splitting the routing task across multiple signaling servers. used In the illustrated example, signaling server node S1 manages the last mile routing for zone U1 and for the SDNP cloud, while signaling server node S4 manages last mile communications within zones U7 and U9. do.

Data routing during a call or communique is shown in FIG. 77A, where voice followed by SDNP data 1 in data packet 1630A is the caller with IP address “IP C _{1, 1} ” by header 1626A. is routed to the nearest SDNP gateway media node M _0,0 from Data packets are re-packetized for SDNP cloud transport and sent to gateway media nodes M _0,4 and M _0,8 . Path packet routing taken in the SDNP cloud is not known to any of the conference call participants, has no central control and changes dynamically based on network conditions. In this example, all SDNP data packets within the SDNP cloud use fragmented meshed data transmission with anonymous addressing and dynamic encryption, as well as dynamic scrambling, mixing, splitting, junk data insertion and removal. In the illustrated example, cloud transport directs incoming communications at 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 accompanying the caller's voice, SDNP data 1, exits gateway node M _0,4 and, using header 1626H, uses zone U7 security credentials to read "IP M _{0, 4} " to the client 1600H at "IP C _7,1 ". The header 1626H was supplied to the client 1600A in the C&C data packet 1627A prior to preparing the media data packet, as described in FIG. 76 . In this way, all media packets carrying real-time data can be prepared without delay when the content is prepared for data transmission. In real-time networks, large QoS relies on timely routing of dynamic data. Otherwise, unacceptably long propagation delays may result.

Once routed through the SDNP cloud, the SDNP data 1 payload is sent from the gateway media node M _0,8 to the client IP addresses "IP C _9,1 " and "IP C _9,4 " to the zone (U9) conference call participants. to the SDNP-clients 1600M and 1600L. These last mile data packets 1630M and 1630L contain identification packet tags, tag 8 and tag 9 used to recognize content associated with the same conversation, preamble 9 information used to carry the SDNP embedded indication, key , seed, etc., and headers 1626M and 1626L specifying the "L4" data field used to specify layer 4 transport as UDP. Although the data routing instructions delivered by the signaling server to ensure correctness use the TCP transport protocol, the media packet content represents real-time data and thus advantageously uses the UDP layer 4 protocol instead of TCP.

FIG. 77B shows the same conversation in which content from zone U7 client 1600H occurs - namely when client C _7,1 starts talking. To contrast this data with the voice content from client C _1,1 , the payload is identified as "SDNP Data 5" within every data packet. Other than the specific payload, the only change from the previous schematic is that the last mile source and destination IP addresses for data packets 1630H and 1630A are swapped. Specifically, for zone U7 SDNP user, the source IP address for data packet 1630H is changed to IP C _7,1 and its destination becomes SDNP gateway address IP M _0,4 . In zone U1, the called party destination IP address for data packet 1630A is changed to IP C _1,1 , and its source address becomes SDNP gateway address IP M _0,0 . that several conference call participants can speak simultaneously and that a data packet from SDNP client node C _1,1 sent to another call participant including client node C _7,1 is a client node C responding to client node C _1,1 It should be understood that it can occur simultaneously for _7,1 .

At network level 3 of last mile communication, data collisions of traffic in the opposite direction do not occur. However, at physical and data link layers 1 and 2, last mile communication may include time division to prevent contention for the same communication link. However, these adjustments occur quickly, so communication tends to appear to be in a completely synchronous fashion, with no delays within voice packets. It should be noted that in both Figures 77a and 77b, the direction of data flow shown for zone U9 clients remains unchanged, ie data flows from the cloud to the client. However, in FIG. 77C, zone U9 client node C _9,1 starts speaking. In this case, client nodes C _9,4 , C _1,1 , and C7 _,1 are all receivers of voice, i.e., SDNP voice data 6 .

In an alternative embodiment shown in FIG. 78, the group call may include a mix of SDNP calls to SDNP clients and “call out” calls to regular phone numbers. Similar to the call or communique shown in FIG. 77A, a voice accompanied by SDNP data 1 in data packet 1630A is sent by header 1626A from the caller with IP address “IP C _{1, 1} ” to the media node M Routes to the nearest SDNP gateway containing _0,0 . Data packets are re-packetized for SDNP cloud transport and sent to gateway media nodes M _0,4 and M _0,8 .

_In the illustrated example, cloud transport directs incoming communications at 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 accompanying the caller's voice, i.e. SDNP data 1, exits gateway node M _0,4 and, using header 1626H, uses zone U7 security credentials to read "IP M _{0, 4} " to the client 1600H at "IP C _7,1 ". The SDNP data 1 payload is also delivered to the conference call participant through the gateway media node M _0,8 . Last mile communications from these SDNP gateways can be performed on PSTN 1, which includes two different types of connections, specifically a hypersecure connection to the SDNP-client (1600M) and a conventional phone system that does not use VoIP or packet protocols. Includes secure "call out" connections. Last mile data packet 1630M, delivered to zone U9 SDNP client at address “IP C _9,1 ”, carries SDNP embedded indication, identification packet identifier tag 9, used to recognize content associated with the same conversation. header 1626M that specifies the preamble 9 information, key, seed, etc. used to do so, and the "L4" data field used to specify Layer 4 transport as UDP.

Gateway node M _0,8 also sends IP packet 1635 to PSTN 1 at address IP C _7,9 . Instead of carrying a payload containing SDNP data 1, in this case the IP payload was converted into a VoIP sound package, which could be intercepted by packet sniffing. The phone switch system, PSTN 1, then sends these unsecured IP packets, followed by a continuous analog circuit connection between phone 37 and PSTN 1, as shown by POTS data 1636, which contains the phone number being called. Converts to an analog POTS phone connection for 37. Because these and any other call out connections are not hypersecure, the content carried by the call out last link is at risk of hacking, wiretapping, and other surveillance techniques. If some hierarchical structure defining the access privileges of the clients is not implemented, the security of the entire call can be compromised by the weakest link, meaning that everyone on the group call can hear everything.

This point is illustrated in the table shown in FIG. 79A, where a group call is made, with call out participants at phone numbers "Ph #1" and "Ph #2", SDNP network client node C _1,1 , Includes hypersecure participants on C _7,1 , C _9,1 , and C _9,4 . As shown, SDNP clients C _{1,1 are group hosts, SDNP clients C 7,1 and C 9,1} are participants, meaning they listen and speak, and SDNP clients C _9,4 are "listeners". , which means that they can hear the call but not speak or the participant can hear The participant at call out phone number "Ph #1" is also a participant who can hear and speak, while at "Ph #2" A participant in is only authenticated as a call out “listener” and cannot speak in a group call The group host, when setting up a call, defines these listen speak privileges, i.e. user authentication.

Referring back to the table, it should be noted that in the column labeled Regular Calls, everyone on the group call, i.e., the caller authorized by the host, can listen to the call. A caller who wants to hack a call but is not authorized by the host has no means to connect or break into the call or even the ability to determine if the call is taking place. The same method can be applied to group chats, where participants can read and write messages, but observe-only members can only read comments and cannot insert their text into the chat.

When using authentication and identification to control network access made in accordance with this disclosure, the SDNP system provides privacy features not available in traditional group chats and group calls. This feature is created by selecting private mode, eg clicking on a lock symbol or other privacy icon, before writing or speaking text. In such case, communications are sent only to authenticated SDNP clients, not to SDNP clients that have not yet been identified through authentication, and not to any call out listeners or participants on unsecured devices. This point is noted in the foregoing table, where in a private call under the column labeled "unauthenticated SDNP clients", all group call clients have both their microphones and speakers muted, while "authenticated SDNP clients In the column labeled ", all SDNP clients can hear, and participants C _1,1 , C _7,1 , and C _{9, 1} can also speak, but all call out devices have their microphones and speakers muted and , which means that only authenticated SDNP clients in private mode can hear and speak. In this way, a group call with a mix of SDNP clients of certain identities, and a call out connection with an unknown party, can inter-participate in the public part of the call, but without exposing confidential information to the call out device. A “call out” party can be removed from a private discussion simply by clicking on any SDNP participant's private icon prior to speaking or composing text. At the end of the private discussion, the private button is released and they are reconnected. During the time the call out party is not connected, i.e. essentially placed on "call waiting", the SDNP system may play music on hold, be quiet, or play white noise (such as the sound of waves or rain).

Text messages in group chats can also be managed in the same way. In a regular group chat, all text messages are sent to the SDNP app on the SDNP client device and sent to all call out chat members by SMS text message. Text messages can only be sent by participants. Text messages sent from "Listener" or "Diary Only" chat members will be ignored and will not be forwarded to the chat group. If a participant clicks the lock or privacy icon before sending a message, the message will only be sent to SDNP clients and not to all call out clients. At SDNP clients receiving private messages, if they have authenticated their identity, the messages will be visible for reading. If they do not authenticate their identity, the message will be covered, covered, hidden, or marked with an icon, eg a padlock, until the observer performs authentication to verify that identity.

By combining identity verification with privacy privileges regulated by SDNP network system authentication, hacking a device is insufficient to open private texts or listen to private calls, even in group chats and group calls. This feature cannot be guaranteed by relying only on device security parameters - information that can be hacked locally. System parameters are much harder to fake, since fake security and identity credentials will not match system logs and will be rejected as invalid SDNP clients.

An additional degree of privacy can also be added to the conduct of group calls and group chats. This particular embodiment of the hypersecure last mile described in the table shown in FIG. 79B is referred to herein as Hyper-Private Call or Hyper-Private Chat. Hyper-Privacy requires verification of a caller or message against four criteria:

* All receivers of communiques on group calls must be SDNP clients and not call out devices.

* A call or text, whether call, text, video, etc., must be selected as a hyper-private communique a priori.

* Recipients of communiques on group calls or chats must have an authenticated connection to ensure their identity.

* Recipients of any hyper-private communique must be pre-selected as “private” participants or private listeners.

Although the first three criteria are essentially the same as those in the example of a private party in a group call described above, the fourth criterion, any caller entitled to receive a hyper-private call or text, is "private". "The requirement that a predefined list of clients be loaded as SDNP clients further restricts access to specific and sensitive information. For example, as shown in bar form, SDNP participant clients C _1,1 and C _7,1 , and SDNP listener clients C _9,4 are all designated as “private” parties in a group call. In contrast, SDNP client C _{9, 1} is designated only as a participant, but not as a private participant. By definition, a call participant or listener cannot be registered as a private party.

As in the previous example, during a regular call all participants, i.e. SDNP clients C _1,1 , C _7,1 , and C _9,1 and callout participant Ph #1 can hear all conversations and read all text messages. can speak and text at any time, while "listeners", including clients C _9,3 and Ph #2, can hear all conversations and see texts, but cannot speak or send messages in group calls or chats. can't However, in a hyper-private call, selecting the switch or icon to designate the hyper-private communique automatically blocks all unauthenticated parties on the group call or chat, as well as blocking all non-"private" parties. Disable. It also disables all call out connections and all unauthenticated users. Thus, in operation, when any private participant selects the privacy icon, only the private participant (including the private group host) can view, read, speak and compose text for the group. All other parties' microphones and speakers are muted, and likewise cannot receive or transmit text or attachments to the group. Specifically, in hyper-private mode, once authenticated, both clients C _1,1 and C _{7, 1} can listen and speak as well as read and transmit text, while private client C _9,4 listens to conversations. or group text can only be read.

With the aforementioned last mile routing control capabilities, group calls and group chats can be managed in any number of ways. For example, a group call host can determine who can participate in a call or group, who can speak or text, and who can only listen and read. In standard private calls, selection of private mode enables all SDNP clients, once authenticated, to join the communique with the same privileges they have during standard non-private group communications. In hyper-private mode, only SDNP clients defined as private participants and private listeners can communicate during hyper-private mode operation.

The selection of who qualifies for a portion of the hyper-private communique, i.e., who has been identified as a private participant or listener, and who does not, can be configured in several ways. In ad hoc hyper-private group communication, the group host determines who is a private caller and who is not. In SDNP "system-defined" hyper-private group communications, SDNP network operators pre-determine who is a private caller and who is not. In rule-based hyper-private group communication, the SDNP network prescribes rules for determining who is entitled to be a private caller and who is not. Such a rule may be based on a company employment list, for example, only a vice president or higher may participate in a hyper-private call. In government and security agencies, criteria may be established by national security clearance, passport number, police badge number, and the like. The SDNP-based last mile communication methods defined herein may support any of these example scenarios, or may utilize any other criterion for dividing a population into two groups, thereby enabling hyper-private communique access. Branches constitute groups and groups that do not.

Although such a concept can be extended to more than one group, hierarchical access criteria are generally more applicable to dispatcher-based professional communication systems than to telephony communication. Accordingly, the application of the SDNP method for professional communication will not be further described herein.

One challenge for group calls is when everyone wants to talk at the same time. Overlapping speech is confusing, difficult to hear, and can also result in unwanted noise. This problem can be solved by using the push-to-talk feature, a function that mimics a walkie-talkie or CB radio. In a push-to-talk or PTT operation, only one participant can speak at a time. When a participant wishes to speak, pressing the switch mutes all others on the network microphone, putting all other parties in the group call into listen-only mode. As shown in the table of FIG. 80A, in a regular PTT conversation, when the host presses the PTT button, they take precedence over the group call, as shown in the column marked Host PTT, even when other parties press their talk button, takes precedence over all other callers. All other callers' microphones are automatically muted, including the call-out phone connection, and you are just a listener. In case the host does not press its PPT button, the PTT capability passes to any other SDNP participant in execution order, as shown in the column marked "Other PTT". SDNP nodes and call out devices designated as listeners, eg C _9,4 and Ph #1, can hear the PTT conversation during the entire group call, but their microphones are muted.

When using the SDNP last mile capability to identify a caller whose identity has been authenticated to the network, the PTT feature can be extended to a private push-to-talk function. Whenever the privacy feature or icon is selected, all unauthenticated parties are removed from the group call and their speakers and microphones are muted. Call out connections by regulation cannot be authenticated and therefore also muted. Muting is two-way and prevents the excluded party from hearing the conversation, but also disconnects the excluded participant's microphone. In the case of an authenticated party, the operation proceeds the same as a regular PTT, where the host takes precedence in speaking, otherwise any authenticated participant may have the PTT talk feature in the order of execution.

The table in FIG. 80B shows that hyper-private group calls can be extended with PTT functionality. In normal operation, the PTT functionality is the same as in the case described above. However, in hyper-private mode, only authorized parties previously designated as private participants or private listeners can participate in hyper-private conversations. For example, in hyper-private mode, SDNP clients C _9,1 and C _9,5 are blocked from speaking or listening because they were not previously listed as private participants or listeners. Similarly, all call outs connected to the device are muted during hyper-private mode operation. In this way, access to multiple parties within a PTT group call can be explicitly controlled. Muting is the process of excluding some participants (eg, call out listeners) from receiving data packets carrying the sound of a conversation, while continuing to supply data packets to participants who are not muted. In this disclosed method, data packets are sent individually to all participants in the general conversation and only to a subset of the list when muting is activated by the user of the client.

In an alternative embodiment, the data packet is transmitted in broadcast mode to all participants in the group call, but using different encryption methods. In the case of a typical conference call, data packets are sent cryptographically to all users, where all participants have copies of the decryption key. In private or silent mode, data packets broadcast to users use a different cipher, where only selected users share the decryption key. Those who have the key can participate in the call and those who do not have it are excluded. The advantage of using broadcast packets is that they require less bandwidth in last mile communications than sending separate packet requests. In another embodiment, a single packet is sent to the gateway, and the signaling server duplicates the packet for distribution to all participants in normal calling mode and for selecting callers in private or mute mode.

Hypersecure File Storage - Although secure dynamic communications networks and protocols were invented and developed as hypersecure communications systems for telephony and real-time data transmission, the security mechanisms inherent in SDNP networks and protocols are perfectly suited for hypersecure file and data storage. do. In its simplest description, a hypersecure call is an end-to-end communication from one caller to another, i.e., from one SDNP client to another SDNP client, anonymous fragmented data of scrambled encrypted data. When involving transfers, hypersecure file and data storage can be thought of as communications that are stored in buffers indefinitely until interrupted and recalled. Another name for hypersecure distributed file storage is fragmented data storage.

This simplified explanation that storage is a communications interruption in the middle of packet forwarding is technically more accurate than first thought. In the aforementioned US application Ser. No. 14/803,869, temporarily buffering data packets until another packet arrives is specifically disclosed and operatively described. Although buffering within the nodes of the SDNP cloud occurs on the scale of milliseconds, not months, the SDNP system has the ability to hold or hold data to restore the original content without losing the information being restored. Of course, such a simplified implementation lacks the specific features required for long-term file management, such as directories, menus, file recycling, renewing security credentials, and other such features.

An example of data transfer from a client to a fragmented data storage network is shown in FIG. 81 . As shown, an SDNP client 1700A with IP addresses IP C _{1, 1} sends a series of data packets through the SDNP cloud to corresponding IP addresses IP F _7,1 , IP F _9,1 , and IP F _{9 , 4} to the SDNP file storage servers 1700H, 1700M and 1700L. In operation, client node C _{1, 1} transmits a series of data packets 1730X with corresponding headers _1726X from address IP C 1, 1 to SDNP gateway M _{0, 0} . Data packet 1730X is illustrated by data packets 1730H, 1730L, and 1730M with corresponding headers 1726H, 1726L, and 1726M. To ensure accuracy, layer 4 transport uses TCP instead of UDP. A packet contains tag X, tag 1, tag 2, tag 3 in the case of data packets 1730H, 1730L and 1730M, SDNP collection or other ID marked tag X, which is used to identify the packet for routing purposes. The payload portion of each packet carries specific data, for example within the three partial fragmentation files SDNP File 1, SDNP File 2, and SDNP File 3. The security credential within the last mile uses zone (U1) information with corresponding preamble 1.

When data packets enter the SDNP cloud, they are routed to different destinations according to their identity and instructions from a signaling server (not shown). Data packet 1730H with tag 1 carrying header 1626H and SDNP file 1 is routed to SDNP gateway node M _0,4 . SDNP gateway node M _0,4 then routes packet 1730H to file storage node F _7,1 using the security credentials for zone U7. Meanwhile, packet 1730L with its ID as tag 2 carrying SDNP file 2 is independently routed to SDNP gateway node M _0,8 . SDNP gateway node M _{0,8 then routes packet 1730L to file storage node F 9,4 using the} security credentials for zone U9.

At about the same time, a packet 1730M with its ID as tag 3 carrying SDNP file 3 is also independently routed to SDNP gateway nodes M _{0, 8} , same mesh as data packet 1730L with ID of tag 2. It is not necessary to use routing passages. SDNP gateway node M 0,8 then routes packet _1730M with tag ₃ to file storage node F _9,1 also using the security credentials for zone U9.

In this way, SDNP file 1 is passed to file storage node F _7,1 with security credentials for zone U7, while SDNP file 2 and SDNP file 3 both have security credentials for zone U9. It is delivered to the file storage nodes F _{9 and 4} F _{9 ,1} respectively using . Although the file is owned by client node C _1,1 , the client does not have access to the security credentials used to encode and protect the contents of the file. Because a single file storage node does not contain all the data, and because the client that owns the data does not have access to the security credentials used for data storage, it is difficult for a hacker to steal the contents of a file, which is (i ) they are fragmented into disjoint and unusable pieces, (ii) every file uses different security credentials for scrambling and encryption of data, (iii) they are stored in different locations and on different last mile networks and (iv) it is not known that the various stored data come from the same SDNP source file. The zone containing the file storage server is also referred to as the “storage side” zone to distinguish it from the zone where the file owner is located, i.e. the zone on opposite sides of the SDNP cloud. By this definition, Zone U1 is the SDNP Client Zone, also referred to as the "File Owner" Zone, while Zones U7 and U9 are the "Storage Side" Zones.

Application of the SDNP network communication protocol to file storage is further shown in the flow diagram of FIG. 82A showing a "write operation", a general step in which SDNP clients and file owners store, i.e., write, their data to a hypersecure file storage server. is shown As shown, SDNP client 1700A performs an SDNP split operation to create a multi-part file or document, which in the illustrated example is a 3-part file that includes parsed files 1706A, 1706B, and 1706C. Using 1057 and the parsing function 1052, the unparsed file 1705 is split. Optionally, the content of the file may be scrambled prior to splitting. These three files are then transmitted across the SDNP network as unrelated data or communiques. The steps involved in routing to the final destination across the SDNP network use the same methods disclosed herein for hypersecure last mile communication and described above for meshed routing in the SDNP cloud. Specifically, the last mile hypersecure transfer 1707 uses security credentials according to zone U1. Hypersecure meshed transport 1708 in the SDNP cloud uses zone (Z1) security credentials. Although these hypersecure data transfer operations are shown in large blocks, packet transfers are actually performed as described in this disclosure, using a decentralized system with no master key, no central control, and no access to packet content. It occurs across networks of routers, servers, and soft-switches.

Although zone (U1) last mile routing may involve sending data packets across an infrastructure that includes a limited number of routing choices, multi-PHY last link routing, routing of sequential packets to multiple SDNP gateways, and The method described for hypersecure last mile communication, including the use of dynamic source addressing, i.e., changing the name of the client's IP address, is equally applicable to hypersecure file storage operations. When a data packet arrives at the SDNP cloud, its transmission uses anonymous meshed routing with dynamically scrambled encrypted data, preventing monitoring of file content or even metadata associated with the communication. Finally, all three data packets are transferred to different SDNP file storage servers (1700H, 1700M, and 1700L) with corresponding SDNP node names F _7,1 , F _9,1 , and F _9,4 located in different security zones. ) is reached. After network transport, parsed file 1 is processed according to zone (U7) file security operation 1709A and stored in SDNP file storage node F _7,1 . Parsed files 2 and 3 are processed according to zone (U9) file security operations 1709B and 1709C and stored on SDNP file storage nodes F _9,1 and F _9,4 . In this way, no single file contains all data, and no single security credential unlocks all component files to recreate the original one.

In the “read operation” of the hypersecure stored file shown in FIG. 82B, the sequence of data transfer between the file storage server and the SDNP client, i.e., the file owner, is reversed. Reading of a hypersecure file involves undoing the process that originally saved the file in the reverse order, which process (i) identifies the parsed file within each storage server, (ii) identifies each parsed file removing local storage security provisions from the files, (iii) sending each restored parsed file back to the SDNP client, across the SDNP cloud and hypersecure last mile, (iv) sending the parsed files to various related including collecting from communiques, and (v) merging (unsplitting) and, where applicable, scrambling, the parsed files using the client's local security credentials to restore the original files. do.

Further explaining the described hypersecurity file “read operation”, in order to restore the parsed file 1, the related contents of the file storage server 1700H stored in the file storage node F _7,1 are stored in the zone U7 file security operation ( 1709A). Independently of parsed file 2 or 3, parsed file 1 is sent by hypersecure transfer operation 1708 using zone (Z1) security credentials, followed by zone (U1) last mile hypersecure transfer operation 1707 , is communicated back to the SDNP client node C _1,1 using the exemplary cloud shown in simplified form. Concurrently, to restore parsed file 2, the relevant content of file storage server 1700M stored in file storage node F _9,1 is processed using zone U9 file security operation 1709B. Independently of parsed file 1 or 3, parsed file 2 is sent by hypersecure transfer operation 1708 using zone (Z1) security credentials, followed by zone (U1) last mile hypersecure transfer operation 1707 , communicated back to the SDNP client node C _1,1 using the SDNP cloud shown in simplified form. On the other hand, to recover the parsed file 3, the relevant contents of the file storage server 1700L stored in the file storage node F _9,4 are processed using the zone U9 file security operation 1709C. Independently of parsed file 1 or 2, parsed file 3 is sent by hypersecure transfer operation 1708 using zone (Z1) security credentials, followed by zone (U1) last mile hypersecure transfer operation 1707 , communicated back to the SDNP client node C _1,1 using the SDNP cloud shown in simplified form.

Independent packet routing of a three component parsed file during a read operation is illustrated in FIG. , using TCP transmission, from the file storage address IP F _7,1 to the SDNP gateway server at address IP M _0,4 . Packet 1731H includes a header 1727H containing preamble 7 and other information previously provided in command and control packets carried by the signaling server in tri-channel communication.

On the other hand, server node 1700L, using TCP transmission, carries SDNP file 2 and sends data packet 1731L with ID “tag 9” from file storage address IP F _9,4 to address IP M _0,8 Send to the SDNP gateway server. Packet 1731L includes a header 1727L containing preamble 9 and other information previously provided in command and control packets carried by the signaling server in tri-channel communication. Independently and concurrently, server node 1700M, using TCP transport, carries SDNP file 3 and sends data packet 1731M with ID “tag 8” from file storage address IP F _9,1 to address IP M _{0 ,8} to the SDNP gateway server as well.

Packet 1731M includes a header 1727M containing preamble 9 and other information previously provided using command and control packets carried by the signaling server in tri-channel communication. The three data packets 1731H, 1731L, and 1731M traverse the SDNP cloud using zone (Z1) security credentials until they finally come from the SDNP gateway M _{0, 0} hosted by the SDNP cloud server 1701U. traverse, and data packets from the SDNP cloud server 1701U are sent to the client device at address IP C _1,1 by successive data packets 1731X using the corresponding zone header 1727X and zone U1 security credentials 1700A) are transmitted sequentially.

Referring again to FIG. 82B, after the three parsed files 1, 2, and 3, namely (1706A, 1706B, and 1706C) are delivered to the SDNP client device 1700A using independent routing, they are mixed operation 1061 ) into one unparsed file 1795, and, if applicable, an unscrambling operation (not shown) is subsequently performed according to zone U1 security credentials.

Without adding additional file server operations for stored data security, security operations 1709A, 1709B, and 1709C actually include last-mile hypersecure communications between the SDNP cloud and corresponding storage-servers 1700H, 1700M, and 1700L. . As a by-product of Layer 3 network connectivity using the SDNP communication protocol, SDNP file storage is inherently hypersecure, including the use of data spoof methods such as junk data insertion and junk file data stored across distributed, non-volatile data drivers. Includes scrambling, fragmentation, and encrypted data. Other than the data security methods described above, hypersecure storage as disclosed herein has no meaningful metadata, no traceability to the file owner, no routing to deliver files, or loss components from the original source file. It uses an anonymous filename, without the identity of any other file storage server that maintains

Despite the physical realization of the storage server, i.e. its layer 1 PHY implementation and layer 2 transport, interoperability over the SDNP network, the protocol is subject to change very significantly without affecting storage functionality, access time, or global accessibility. can 84A shows a physical realization of the SDNP file storage server including, for example, a top view showing SDNP gateway 1701B connected to SDNP file storage server 1740A via router 27. For better network performance and additional resiliency to attacks, the middle diagram shows a direct connection between SDNP gateway 1701B and SDNP file storage server 1740A using optical fiber 91 with no intervening routers. As shown in the lower bound example, the file storage server may include a large memory array having a server controller 1740B and storage drives 1740C and 1740D. The drive may include any media including a hard disk drive or flash drive based non-volatile memory. To further restrict access, the SDNP gateway and SDNP file storage server can be physically located in the same location and facility with only a fiber link connecting them. They can even share a common space and be physically locked within a vaulted ceiling, for example, with access controls tightly managed and anyone entering the facility supervised.

84B further illustrates that some portions of a fragmented data file may be stored locally at the file owner's site. As shown, the file server's desktop 36 includes (i) a local file storage server 1740A accessed over a WiFi router 1352 connected to SDNP gateway node M _0,0 on server 1701A, (ii) ) file storage server 1740B connected to SDNP gateway node M _0,4 , and (iii) file storage server 1740C connected to SDNP gateway node M _0,8 . . Because data is fragmented when stored across distributed drives 1740A, 1740B, and 1740C, even though local file server 1740A and file owner desktop 36 share the same WiFi 1352, notebook 35 , tablets 33, and other devices including mobile phones 29 do not have access to the stored files.

The process of specifically storing each parsed portion of a file on a separate file storage server, referred to as non-redundant hypersecure file mapping, is illustrated in FIG. 85A. As shown, client device 1700A, including SDNP client nodes C _{1, 1} , parsed files 1, 2, and 2, each having storage nodes F _7,1 , F _9,1 , and F _9,4 Corresponding to the one-to-one file mapping between the three, the file 1706A parsed only on the file storage server 1700H, the file 1706B parsed only on the file storage server 1700M, and the file storage server 1700L ) only stores the parsed file 1706C. The transfer of files uses hypersecure last mile communications to secure the transfer of data as well as its storage. One disadvantage of non-redundant file mapping is that the loss of either of the file storage servers, temporarily or permanently, jeopardizes file access and restoration. In the context of this application, the terms “resilience” and “restorative” are used to define guaranteed and timely access to stored data, i.e., that the stored data is not lost or that access is not compromised for a significant duration. Used to define certainty. By this token, the illustrated non-redundant hypersecure file mapping exhibits poor resiliency, since a single point of failure prevents file access. Poor resiliency can be overcome by a redundant system, where the same data is stored in more than one file storage server.

Another metric that describes or evaluates the resiliency of a data storage system is defined herein as read redundancy factor (RRF), a term that defines the number of backup systems that provide data access in case the primary data store is unavailable. is a standard of measurement. In the illustrated example, there is one location for each specific piece of data. This results in a read redundancy factor of zero, or mathematically RRF = 0, meaning that a single point connection or file server failure can result in temporary or permanent data loss because the file cannot be read by the file owner. do.

An alternative file mapping with a read redundancy factor of RRF = 1 is shown in FIG. 85B. In this example, parsed file 1 is stored on file storage server nodes F _9,4 and F _7,1 , parsed file 2 is stored on file storage server nodes F _9,1 and F _7,1 , and parsed file 2 is stored on file storage server nodes F 9,1 and F 7,1 . File 3 is stored on file storage server nodes F _9,4 and F _9,1 . In such an implementation, if the file storage server node F _9,1 is damaged or unavailable, the parsed file 3 can still be accessed from the file storage server node F _9,4 and the parsed file 2 is the file storage server node F 9,4. It can still be accessed from server node F _7,1 . Thus, failure of any one storage node will not disrupt read access to hypersecure files. 85C shows hypersecure file mapping with RRF = 2. _The file mapping maintains file storage servers _{1700L , 1700M} , and 1700H, but a second set of file storage servers ( 1700J, 1700E, and 1700F). Thus, file storage server 1700J serves as a backup for file storage server 1700L, file storage server 1700E serves as a backup for file storage server 1700M, and file storage server 1700F serves as a backup for file storage server 1700F. It serves as a backup for storage server 1700H. Although the illustrated example includes a file parsed into three sections, it will be appreciated that a document may be parsed into a larger number of sections if desired. To ensure hypersecure storage, the original file should not be parsed into less than 2 sections and ideally less than 3 sections.

To describe the process of allowing duplicate files to be stored and read using hypersecure file storage, it is advantageous to describe the transactional sequence of communiques and file transfer functions overlying the SDNP network used to facilitate the storage process. The network shown in FIG. 86 includes, for example, a client device 1700A implementing client node C _{1 , a} router 1702G, a signaling server 1715 implementing SDNP node S, and implementing SDNP node NS. name server 1714, cloud server 1701U implementing SDNP cloud nodes M _0,0 , M _0,4 and M _0,8 , and SDNP file storage nodes F _7,1 , F _9,4 , and F _{9 ,} and SDNP file storage servers 1700H, 1700L, and _1700M respectively realizing .

In FIG. 87A , a client device 1700A at address “IP C _1,1 ” sends a data packet ( By 1710A), a file write request is made to the signaling server 1715 at the address "IP S". In FIG. 87B, signaling server 1715 sends data packet 1710B to naming server 1714 requesting the IP or SDNP addresses of file storage server nodes F _7,1 , F _9,4 , and F _9,1 do. The selection of the file address server node to use may be randomly selected from the list of storage nodes, or based on one node available geographically near the client or based on a node within a disaster-free area. The selection may also be based on performance parameters such as the node's unused memory capacity, propagation time to the file storage node, the node's uptime reliability rating, or other such considerations. In FIG. 87C, name server 1714 sends data packet 1710C containing the IP or SDNP addresses of file storage server nodes F _7,1 , F _9,4 , and F _9,1 to signaling server 1715. transmit Signaling server 1715 then computes last mile and meshed cloud delivery of the parsed files to file storage servers 1700H, 1700L and 1700M.

In FIG. 87D, signaling server 1715 sends data packet 1710D to client device 1700A, and the packet is routed from address “IP S” to “IP C _1,1 ” via router 1702G. Data packet 1711D is routed through last mile routing for impending file delivery within zone U1, the client zone, specifically tag 1, tag 2, and tag 3 of each packet (denoted "tag X" for brevity). C&C payload 1711D, which includes routing of a number of packets from address “IP C _1,1 ” with identification to the SDNP gateway at “IP M _0,0 ”. At the same time, signaling server 1715 also sends data packet 1710E to SDNP gateway 1701U, and the packet is routed from address "IP S" to "IP M _0,0 ". These packets are sent from the SDNP gateway address "SDNP M _{0, 0} " in this case using zone (Z1) security credentials for packets with ID tag X, e.g. from address "SDNP M _0,5 " (not shown). ), to the next node in the cloud, contains a C&C payload 1711E showing SDNP cloud routing. According to secure dynamic communication networks and protocols, the routing of data packets through the SDNP cloud using meshed, anonymous, fragmented transport is dynamically selected based on the current conditions of the real-time network. Specifically, the routing within the SDNP cloud of real-time data packets arriving at any SDNP gateway depends on the node-to-node propagation delay within the SDNP cloud and the urgency of each real-time data packet assigned by the signaling server.

In FIG. 87E, signaling server 1715 transmits C&C data packets to last mile nodes located on the storage side, i.e. zones U7 and U9. As shown, data packet 1710F is sent to SDNP gateway M _0,4 , the packet is routed from address “IP S” to “IP M _0,4-- ”, and the packet is data with tag 1 It contains a C&C payload 1711F that communicates that the packet should be expected by gateway node M _0,4 and, when received, should be forwarded on the last mile address “IP F _7,1 ”. A second data packet 1710G is forwarded from signaling server 1715 to storage server 1700H located at address “IP F _7,1 ”. The C&C payload for storage in zone U7 defines a received packet with ID tag 1 from source address "IP M _0,4 ", but since the node's function is storage and not communication, the destination field is left empty. , i.e. filled with invalid values. Once command and control data packets are distributed over the network, file delivery can occur.

88 illustrates fragmented data transfer during file hypersecure storage, where client device 1700A sends a series of data packets 1712X carrying SDNP data files 1, 2, and 3 using TCP data transfer. Transmits from address "IP C _{1, 1} " to SDNP gateway located at address "IP M _0,0 ". Each data packet has a specific identifier ID: tag 1, tag 2, and tag 3. These files are then transferred to other gateways via the SDNP cloud, namely SDNP gateway nodes M _0,4 and M _0,8 . A packet containing SDNP data 1 arriving at gateway node M _0,4 is a data packet from address “IP M _0,4 ” to “IP F _7,1 ” using TCP with zone (U7) security credentials ( 1712A), while arriving at gateway node M _0,8 , data 2 and data 3 packets are sent from address “IP M _0,8 ” along with zone (U9) security credentials in data packets 1712B and 1712C. It is sent to the addresses "IP F _9,4 " and "IP F _9,1 ", respectively. To prevent data scanning of the drive, storage also includes local encryption within the file server. This encryption process is local and not related to SDNP security rules. Contents of Data Packets SDNP Data 1, SDNP Data 2, and SDNP 3 include the actual fragmented files that are stored.

The preamble in each data packet, e.g., preamble 1 in data packet 1712A, may also contain an encryption key supplied by the client as part of the symmetric key encryption operation. Using symmetric key cryptography, SDNP client node C _{1, 1} generates a partition key, one for encryption and its complement for decryption. The symmetric encryption key is then supplied to the file storage server node F _7,1 conveyed by data packet 1712A in this example. In the future, whenever a client requests reading or accessing the contents of a stored file, the file storage server node F _{7, 1} uses this encryption key to encrypt the requested file before sending the file back to the client. Since only the client has the decryption key associated with it, only the client can open the read file. Although this method provides an extra layer of protection, only a single client can access a file as a read operation, and many are needed to help redundant access in case the original client device is stolen, damaged, or lost. has the disadvantage of preventing the use of the "owner" of the client file.

At approximately the time of the data transfer and file storage process, signaling server 1715 also sends instructions to file storage servers 1700H, 1700L, and 1700M regarding routing a “link response” message. The link response is a data packet and C&C payload that confirms to the client that the write operation was successful and that the storage of each parsed file is complete. This message is sent to the client file-owner independently of each file storage server involved in the storage of the forwarded parsed file. The file server, independently of each other's knowledge, sends its write-acknowledgment response to the client, and the write-communication response uses independent security credentials that contain specific conditions different from the operational state at the time of the write operation. is sent by The routing of these link response messages does not necessarily use the reverse direction of the same routing path that was used to transfer the file. Such responses are likely to be used by cyber-attackers as tracebacks to find the owner of the file.

Instead, the link response uses the packet ID to identify to the client that the stored file is part of the same file and was stored as part of the same fragmented write-operation.

In operation, the Signaling Server sends routing for link-response messages to the file storage server, to the client file-owner, and to all intermediate SDNP nodes involved in routing the link-response messages. Signaling server 1715 uses data packets containing command and control payloads to coordinate link response message routing, as shown by the example of FIG. 89A, e.g. file storage server 1700H addresses Receives data packet 1721G containing C&C payload 1722G containing header data for “Link ₁ response” routing _from IP F _7,1 to address IP M 0,4. SDNP gateway node M _0,4 routes tag 1 data packets from address “SDNP M _0,4 ” to another node in the SDNP cloud (not shown), in this case at address “SDNP M _0,14 ”. Receives data packet 1712F containing C&C payload 1722F describing Similarly, signaling server 1715 stores data packet 1721M containing “Link 3 Reply” tagged 3 packet last mile routing instructions from addresses “IP F _9,1 ” to “IP M _0,8 ”. It is transmitted to the server 1700M. While the storage-side last mile routing for file data packets and their corresponding link response messages may be the same or similar, the routing of response messages through SDNP clouds is most likely different due to the dynamic nature of SDNP clouds.

The actual routing of link response messages from participating file storage server nodes is shown in FIG. 89B. As shown, file storage server 1700H responds with data packet 1720A identified by tag 1 and carrying payload “FS Link 1”. The packet is routed from address "IP F _7,1 " to the SDNP gateway located at "IP M _0,4 ", using zone (U7) security credentials. From the SDNP gateway, the tag 1 data packet is routed through the SDNP cloud to the client-side gateway located at address “SDNP M _0,0 ”, where the address is converted to last mile data packet 1720X and zone U1 Routed from address “IP M _0,0 ” to address “IP C _1,1 ” using a TCP transport using security credentials and carrying tag 1 data, i.e. preamble 1 and FS link 1.

In a similar manner, file storage server 1700L responds with data packet 1720B identified by tag 2 and carrying payload "FS link 2". The packet is routed from address "IP F _9,4 " to the SDNP gateway located at "IP M _0,8 " using zone (U9) security credentials. From the SDNP gateway, the tag 2 identified data packet is routed through the SDNP cloud (routing not shown) to the client-side gateway located at address “SDNP M _0,0 ”, where the address is the last mile data packet 1720X. from address "IP M _0,0 " to address "IP C _1,1 " routed to

A third piece of the parsed file identified by tag 3 and carrying payload “FS link 3” is transmitted from file storage server 1700M via data packet 1720C. This Tag 3 packet is routed from address “IP F _9,1 ” to the SDNP gateway located at “IP M _0,8 ” using zone (U9) security credentials. From the SDNP gateway, the tag 3 identified data packet is routed through the SDNP cloud to the client-side gateway located at address “SDNP M _0,0 ”, where the address is converted to a last mile data packet 1720X and zone ( U1) Routed from address “IP M _0,0 ” to address “IP C _1,1 ” using a TCP transport using security credentials and carrying tag 3 data, namely preamble 3 and FS link 3.

89C shows an example of the contents of FS Link Data Packet 1720A routed from File Storage Server 1700H back to the client and file owner. As shown, a data packet is sent from address "IP F _7,1 " using TCP in a packet with ID tag 1 generated in secure area U7 to the SDNP gateway located at address "IP M _0,4 ". Includes last-mile routing of The response preamble 1719A contains a description of the data payload 1741A and also includes optional security credentials used to enforce or enhance the security of the FS link data packet 1720A delivered to the client. However, in tri-channel communication, the response security credentials contained within the response preamble 1719A are generally not required and are not related to later use by the client to access and open the hypersecure storage file. Instead, the access credentials needed to create a link from the client to the file stored on file storage node F _7,1 are contained within data field 1741A containing:

* A specific network tag, SDNP address, or pseudo-address needed to identify the file storage server on which a portion of the fragmented file is stored.

* A description of the zone that specifies the security credentials used to encode files within the "storage-side" security zone (not the client's zone).

* Seed 1, which may contain a numeric seed or time or state (920) required during encoding of the file prior to storage.

* Seed 2, which may contain the numeric seed 929 used to perform file encoding as part of the save operation.

* Key 1 containing decryption key 1030 to decrypt zone (U7) "storage side" encryption. This key may be used with a shared secret maintained within a DMZ server operating as part of a file storage server, or , may represent a partial decryption key that can only be operated in conjunction with other security credentials, such as a numerical seed.

* Key 2, which is sent to the client and contains the encryption key 1022 used to send security instructions from the client to the file storage server using symmetric key encryption.

* A filename or other information used to help clients identify a stored file without revealing how it is stored.

The foregoing data packets are used for illustrative purposes and should not be construed as limiting the contents of the data packets to the precise elements or formats shown in the examples. FS link 1720X received by SDNP client node C _1,1 , once received from a file storage server participating in fragmented file storage, is processed to create a file link for the client's device. As shown in FIG. 89D, this operation combines FS links 1741A, 1741B, and 1741C using a blending operation 1753, thereby creating a FS link total “file store read link” 1754. . A file storage link 1754 is placed on the client's hypersecure text messenger or file management system for easy single-push-button recall of hypersecure files. Hypersecure operation is not visible to the user. The file owner need not be concerned that the file has actually been fragmented, encoded, and stored across distributed file storage systems. File recall is seen as a file staying local. As such, FS links are key elements for accessing any file stored across a distributed file storage system.

A simplified diagram of FS link communication is shown in FIG. 90A , where three file storage servers transmit their respective FS links to client node C _1,1 and corresponding client devices 1700A, specifically file storage Server 1700H transmits FS link 1, file storage server 1700M transmits FS link 2, and file storage server 1700L transmits FS link 3. Within client device 1700A, the SDNP App software within client node C _1,1 , combines the three receiving FS links 1, 2, and 3 to form a link to the stored file. These combined links appear within the SDNP messenger as file storage confirmations. In non-redundant file management, FS link information is only sent to the client device. For user file management, file links can be named when file storage is requested or when a confirmation message is received.

Because the file storage link is sent to the client directly from the file storage server and not through the signaling server, only the client with the link has access to the file. These FS links are needed to recall and read fragmented files. Without the FS link, the stored files and their contents will be lost forever and irreversibly become irretrievable. To reduce this risk that the FS link may be lost, an alternative approach is to transmit the FS link to two client devices - a client device and a secondary device. The secondary device may be a second device owned by the client or, in the case of a business, a second device owned by a company. Alternatively, the second device may include another server with its own login security and user identification.

Redundant link access for fragmented, distributedly stored files made in accordance with the present invention can be applied to both read redundant, RRF ≥ 1, and non-redundant file storage systems. The use of redundant links in a hypersecure distributed memory system with no read redundancy (RRF = 0) is illustrated in FIG. 90B. In such a system, the file mapping between parsed files 1706A, 1706B, and 1706C and corresponding file-storage servers 1700H, 1700M, and 1700L is non-redundant. As shown, FS links 1, 2, and 3 have two client devices: a client device 1700A hosting SDNP client node C _{1, 1} and a secondary client device hosting backup client node C _{2, 1} ( 1700B). If one of the FS links is lost or unavailable for any reason, the FS link on the backup client can be used to restore the files. In this regard, the SDNP Distributed Storage System describes a single link redundant, non-redundant read implementation with RRF = 0 and LRF = l.

An example of a hypersecure memory with both read and link redundancy is shown in FIG. 90C , where parsed files 1, 2 and 3 are mapped to two file storage servers respectively, with a read redundancy factor RRF = 1 accordingly. , and achieve a link redundancy factor LRF = 1 with each FS link sent to the two clients. The storage system's immunity to both read and link related failures means that the system can be considered a truly redundant hypersecure file management system with an overall storage redundancy factor SRF = 1. Herein we define storage redundancy factor (SRF) as the redundancy factor equal to the smallest of RRF and LRF. For example, if RRF = 0 and LRF = 1, then SRF = 0. Alternatively, if RRF = 3 and LRF = 2, the overall storage redundancy is SRF = 2. To implement a full system SRF = 3, each parsed file must be stored in 4 separate file storage servers (as shown earlier in Figure 85c), and the FS link must be sent to 4 separate clients .

Thus, the total storage redundancy factor (SRF) is a direct means of recovery from failure of a distributed storage system. This principle is summarized in the graph of FIG. 91, where the abscissa describes the # of file storage servers used in the file storage system and the ordinate describes the number of FS links sent to separate clients. As shown, a single file storage server has no redundancy, ie RRF = 0. Increasing the number of file storage devices improves read redundancy, but does not affect link redundancy. Conversely, sending the link to a single client provides no link redundancy, i.e. LRF = 0, regardless of the number of available file storage servers. In both cases, i.e. one storage server or one client link, the total storage redundancy factor (SRF) = 0, which means that the file storage system is not resilient, as diagrammatically illustrated by the L-shaped region. it means.

As shown, as previously shown, storing a three-part parsing file on three file storage servers results in a read redundancy factor (RRF)=1. Link redundancy of LRF ≥ 1 is achieved if at least two clients receive the FS link. The combination of LRF = 1 or RRF = 1 creates an L-shaped region 1724B, where SRF = 1, i.e. provides some degree of system resiliency. It should be noted that even if 6 servers are used, if the FS link is sent to only 2 clients, the system still exhibits only a limited degree of resiliency, ie SRF=1.

By sending FS links to 3 clients and storing data redundantly on 6 storage servers, area 1724C defines the condition that SRF = 2 provides a very strong degree of storage resiliency. Area 1724D shows additional resiliency improvements, where SRF = 3 uses 6 file storage servers and 4 clients receiving keys. Thus, the bottommost row and leftmost column have the lowest storage stability, and the top right corner has the highest storage stability.

Hypersecure distributed file storage built according to this disclosure achieves security that is sustainable over long periods of time by constructing, i.e., re-using, a number of inventive elements from SDNP communications. These elements according to the present invention include:

* parsing the file and distributing its fragmented content across a large number of unrelated networks connected to the file storage server;

* Transferring files between clients and file storage servers using SDNP dynamic scrambled, encrypted, and end-to-end hypersecure communications involving anonymous fragmented data transmission without a master key;

* "client-side" last-mile security credentials where the storage server does not have access to the client security credentials used to initially fragment and encode the stored data, i.e. the file storage server needs to decode, access or read the file storing fragmented files in a file storage server, in a proof-free manner;

* The "client-side" last mile, where the client (the owner of the file) does not have the necessary security credentials to decode the stored data, except over a secure link, is a "store" used to encode the file locally. selectively encoding fragmented files in the storage server in a manner that does not have "side" last mile security credentials;

* limiting the number of file storage links needed to locate and open a file, and limiting user access to such links on the file owner's client device, along with any redundant or backup devices;

* Requiring client multiple authentication and identity verification to execute file links and perform read or delete operations;

* Utilizes anonymous data packet routing and anonymous file names, whereby the use of file links for data recall does not reveal information about encoding and location of hypersecure file storage, and routing information, except for file links, is not stored on SDNP networks or hypersecure file storage systems;

* Fragmented files can be distributed to a large number of storage servers using undisclosed file server locations and using anonymous identities unknown to clients, SDNP networks, or other storage servers, except through file storage links. distributing it across

* Utilizing tri-channel communication, where the SDNP signaling server used to plan file routing for distributed storage does not have access to the content of the fragmented file or the security credentials used to encode the file, SDNP media nodes used to transmit content use single-hop SDNP data packets that do not have the identity or address of the client or file storage server;

* Using dynamic file renaming and data relocation at regular intervals and after repeated file access, replaying the encoding of security credentials at the time of a file rewriting operation, and

* Locally encrypting file storage server directories to prevent file parsing.

Using the foregoing, the lack of any recognizable file identity; use of fragmented files distributed across networks (possibly on a global scale); and the use of zone-specific security credentials, making access to and reconstruction of hypersecure stored files unthinkable without access to the file storage link. Those FS links of a limited number and only distributed over the SDNP communication system are further secured by identity verification.

Execution of the foregoing features for hypersecure file storage may be provided schematically in the same way as for hypersecure communications using functional symbols previously shown in FIG. 9A. For brevity, as shown in the upper diagram of FIG. Any combination may be provided as SDNP encoding function 1750. Similarly, decoding function 1751 includes decrypting 1032 using state or time 926B, mixing 1061 , removing junk data 1053B, and unscrambling 928 .

In use of the aforementioned security features, the top diagram of FIG. 93A illustrates the process of distributed file storage with client-side encoding. As shown, the file 1705 is parsed 1052 and split 1057 to create a parsed file 1706 within the client device 1700A used to realize the SDNP client C _1,1 . The resulting fragmented file is then encoded using the zone (U1) security credentials by SDNP encoding operation 1750B for last mile communication conducted in accordance with the methods disclosed herein. Then, the file fragment carried in the serial or multi-path last mile communication is received by the SDNP gateway M _0,0 and SDNP decoding operation 1751C according to zone (U1) security credentials restoring the parsed file 1706. ) is decoded using The parsed file 1706 is then re-encoded by the SDNP encoding operation 1750C according to the SDNP cloud zone (Z1) security credentials. During meshed transmission, after a series of zone (Z1) decoding and encoding operations within the SDNP cloud (not shown), the final data packet reaches each SDNP gateway including, for example, gateway M _0,8 , where SDNP decoding operation 1751D in , recovers the parsed file 1706 and re-encodes it using SDNP encoding operation 1750D according to zone U9 security credentials. In the illustrated example, the parsed file 1706 is then fragmented (split) into two files, and the fragmented files 2 and 3 of the parsed file 1706 are then restored using the SDNP decoding function 1751E, stored in file storage servers 1740B and 1740C, respectively. In this way, if a data file stored within the file storage server is fragmented, but not fragmented (except for local drive encryption), the file may be accessed by a cyber attack on the drive data. Thus, security is achieved by file fragmentation and distributed storage.

By using the process shown in the lower diagram of FIG. 93A, which depicts the process of distributed file storage with full client-side encoding, a large degree of file security is achieved. As shown, the file 1705 is processed by the SDNP encoding operation _1750A to be a scrambled, encrypted, parsed file ( 1706). Operation 1750A also includes splitting file 1706 into three fragmented files 1, 2 and 3. Fragmented files 1, 2, and 3 are then encoded using zone (U1) security credentials by the SDNP encoding operation 1750B for last mile communication conducted in accordance with the methods disclosed herein. The file fragments carried in the serial or multi-path last mile communication are then received by the SDNP gateway M _0,0 and reconstructed scrambled, encrypted, parsed file 1706 to zone U1 security credentials. is decoded using the SDNP decoding operation 1751C according to. The parsed file 1706 is then re-encoded by the SDNP encoding operation 1750C according to the SDNP cloud zone (Z1) security credentials.

During meshed transmission, after a series of zone (Z1) decoding and encoding operations in the SDNP cloud (not shown), the final data packet reaches each SDNP gateway including, for example, gateway M _{0, 8} , where SDNP decoding operation 1751D recovers the scrambled, encrypted, parsed file 1706 and re-encodes it using SDNP encoding operation 1750D according to zone U9 security credentials. Fragmented files 2 and 3 of scrambled, encrypted, and parsed file 1706 are then restored using SDNP decoding function 1751E and stored in file storage servers 1740B and 1740C, respectively. As such, files are secured not only by fragmented and distributed storage, but also by some combination of scrambling, junk data, and encryption known only to the client's security zone. In a similar manner, file 1 is transferred via the SDNP cloud to gateway M _0,4 where the file is stored in file storage 1700H in zone U7 as shown for packet 1712A in FIG. 88 . do.

In both examples described, a greater degree of security can be achieved by removing the final SDNP decoding operation 1751E shown in the diagram of FIG. 93B. In this way, files stored on the file storage server remain encoded by SDNP encoding operation 1750D using zone U9 security credentials. In the upper diagram, the file is fragmented by the client, but encoded according to the storage-side security credentials for zone U9. In the lower figure, the file is encoded according to the client-side security credentials (U1), then encoded a second time according to the storage-side security credentials for zone U9. Dual encoding of such files, in addition to being secured by fragmented and distributed file storage, represents nested hypersecure storage, in which files encoded by zone (U9) security credentials are encoded by U1 security credentials. Because it contains files. An advantage of nested security as disclosed is that neither the client nor the storage server has the necessary information to open the storage file.

The gist of an exemplary method for implementing hypersecure disaggregated file storage is illustrated in FIG. 94 . In the example shown, the encoding and decoding used for hypersecure communication and SDNP cloud routing have been removed to reveal only the net effect of file encoding. The upper left corner represents the case of client zone fragmentation, where the document is fragmented according to zone (U1) security credentials, but without any additional security provisions imposed by the storage side of the network. The lower left corner represents the case of client zone encoding, where the document is encoded by operation 1750B, i.e. scrambled, junked, fragmented, encrypted according to zone U1 security credentials, but the network No security provisions are introduced on the storage side.

The upper right corner shows the case of client zone U1 fragmentation, but here additional steps of SDNP encoding are introduced on the storage side according to zone U9: scrambling, junk insertion, fragmentation, and encryption. The lower right corner shows an example of fully nested hypersecure file storage, where the file is encoded and fragmented according to the SDNP encoding operation 1750B with zone (U1) client-side security credentials, then the file is stored-side last Second encoded according to Mile's Zone (U9) security credentials.

For recall and reading of files, data recall must use a secure operation that includes reverse-functions executed in the exact reverse order of encoding, as shown in FIG. 95 . In the upper left case, to recall client zone fragmented data, the recalled parsed file 1706 from different file storage servers is reassembled using merge operation 1061 to restore the original file 1705. In the lower left case recalling client zone encoded data, access original file 1705 using SDNP decoding operation 1751H, which is an exact inverse-function of segmentation operation 1750B, including mixing, decoding, and unscrambling. To do so, the recalled parsed file 1706 from different file storage servers is retrieved. In the upper right case for a storage zone encoded, client zone fragmented file, the reverse operation uses SDNP decoding operation 1751F to restore the parsed file 1706 by undoing the effects of zone U9 security operations. The first one, and then file merge operation 1061 to undo the effect of file splitting operation 1057 made according to zone (Z1) security credentials.

In the lower right example for reading a fully-nested hypersecure file, data stored in different file storage servers is decoded by SDNP decoding operation 1751D using zone U9 security credentials, resulting in zone Z1 Reconstructs file 1706, which is still a multi-part file that has been scrambled, junked, parsed, and encrypted upon viewing. Zone Z1 specific SDNP decoding operation 1751H then implements sequential inverse-functions of encoder 1750B, operations including mixing, decoding, and unscrambling to recall the original file 1705. . Operations that execute sequential inverse-functions to restore a file must be performed in the reverse order of the sequence used to create it. For example, if encoding involves division, then scrambling, and then encryption, then the reverse or inverse-function, i.e., decoding, must include a sequence of operations of decryption, then unscrambling, and then mixing. However, if encoding involves sequentially scrambling, then encryption, and then splitting of packets, then the opposite or inverse-function i.e., decoding must involve a sequence of mixing, then decryption, and finally unscrambling of data packets. .

To perform a file recall or "file read operation", the client clicks on the "file store read link" to initiate the steps necessary to recall and read the file stored on the system's hypersecure file storage system, thereby merging the file perform a link The reading process includes the following steps as shown in Fig. 96A:

* A file owner and client 1700A or an authenticated user clicks on a "file store read link" within an SDNP application such as SDNP-based hypersecure messenger 1196, file manager, or other SDNP-based interface.

*Using dialog interface 1765 or optionally command line instructions, client 1700A can read files, edit files (make copies of files with write privileges), remove files (delete), refresh links (with security credentials). certificate reissue), or redistribution of the file (moving file fragments to different file storage servers and issuing a new file storage read link to the file owner client or clients).

* In a “client authentication” operation 1762, the SDNP signaling server 1715 verifies the identity of the client or clients requesting the file (authentication). Using dialog box 1767, the client must verify its identity using a PIN, or optionally a second factor detecting a device or security token. Alternatively, the SMS text may be sent to another device owned by the same client. In a file requiring access authorization by multiple clients, the identity of all users must be proven (multi-authentication).

* At “verify privileges” operation 1763, signaling server 1715 verifies that requesting client 1700A has read or read/delete privileges (authentication) and is authorized to access the requesting file. Before checking whether the user still wants to download or read the file, the result is displayed in dial box 1768. If the identity is not verified, the requestor may be instructed to try again. After a specified number of failed attempts, the file manager 1700Z (if any) will recognize the failed attempts and lock the account. The dialog box can inform the user of the problem and bring them into contact with the file manager, or alternatively, if hacking is suspected, the box will be blank or even kick the user out of the SDNP application entirely.

* In the document request management operation 1764, the SDNP signaling server 1715 informs the file storage manager 1700Z regarding the file access request and the characteristics (management) of the request. These management steps (i) could be omitted entirely, (ii) file access requests could be logged into the file storage manager's account, and (iii) a message immediately notifying the attempted file access could be sent to the file storage manager. or (iv) require the approval of the file storage manager via dialog box 1769 before access is granted to the client requesting the file.

After this Authentication, Authentication, and Administration (AAA) step, upon approval, the client will use the steps shown in the flowchart shown in FIG. request access to These steps include:

* In read request operation 1770, requesting client 1700A sends a file read request to SDNP signaling server 1715.

* In the storage server name request operation 1771, the SDNP signaling server 1715 sends a file storage server name request to the SDNP name server 1714 to send the current SDNP of the relevant file storage server, e.g., the file storage server 1700M. ask for address According to the SDNP method, SDNP addresses for SDNP clients (including file servers) are changed at least once daily to prevent long-term client traceability.

* In storage name delivery operation 1772, SDNP name server 1714 forwards the requested file name “FS Address” to SDNP signaling server 1715, whereby SDNP signaling server maps file recall routing.

* At routing directive action 1773, the SDNP signaling server sends a file routing directive to client 1700A, to a node in the SDNP cloud, such as server 1700U, and to state or time 920, numeric seed 923, decode zone specific security credentials such as file storage server 1700M with zone U9 security credentials including key 1030, and optional encryption key 1022 (used in symmetric key encrypted communications). to the file storage server with

* In local file restore operation 1774, using applicable security credentials that include state or time information specific to the creation of the file, the DMZ server within every storage-side last mile decodes and restores the parsed file; In preparation for transport, data is arranged into one or more data packets.

* In file delivery operation 1775, each parsed file is delivered to the requesting client using independent delivery across the SDNP network according to the routing instructions of the SDNP signaling server, e.g., where the file storage server 1700M sends the file to the client 1700A.

* The incoming parsed data file is further decoded according to the client zone security credentials, and the parsed file is merged to recreate the original unparsed file ready for viewing or delivery.

Such steps are represented by the sequence in the figures below. In FIG. 97A, a client device at address “IP C _1,1 ” uses data packet 1810a, which includes a TCP transfer, header information related to files, and a C&C payload 1811A specifying two or more FS links. to make a file read request to Signaling Server 1715 at address “IP S”. FS links describe the location of anonymously stored file fragments using tags or pseudo-addresses that must be translated to SDNP addresses or IP addresses for routing purposes. However, Signaling Server 1715 does not know the current SDNP address for this named user ID, and must request current information from SDNP Name Server 1714. In FIG. 97B, signaling server 1715 sends data packet 1810B to naming server 1714 to obtain the IP or SDNP addresses of file storage server nodes F _7,1 , F _9,4 , and F _9,1 . request. In FIG. 97C, name server 1714 sends data packet 1810C containing the IP or SDNP addresses of file storage server nodes F _7,1 , F _9,4 , and F _9,1 to signaling server 1715. transmit The signaling server 1715 then calculates the last mile and meshed cloud delivery of the parsed file to the file storage server.

In FIG. 97D, signaling server 1715 transmits C&C data packets to last mile nodes located on the storage side, i.e. zones U7 and U9. As shown, data packet 1810G is forwarded from signaling server 1715 at address S to file storage server 1700H at address “IP F _7,1 ”, resulting in “instruction to read file 1” 1811G. It carries a C&C payload containing This packet instructs the file storage server to send the file with ID tag 1 from its address "IP F _7,1 " to the SDNP gateway at address "IP M _0,4 ", using the U7 security credentials.

At the same time, data packet 1810F is sent to SDNP gateway M _0,4 , the packet is routed from address “IP S” to “IP M _0,4-- ”, the packet is the data packet with tag 1 is sent to the gateway A C&C payload that communicates that it should be expected by node M _0,4 and, when received, should be forwarded to the address "SDNP M _0,31 ", for example, using the Z1 security credentials in the SDNP cloud ( 1811F).

A second data packet 1810I, containing a C&C payload 1811I containing "instruction to read file 3", is sent from the SDNP signaling server 1715 at address "IP S" to a file at address "IP F _9,1 ". It is transmitted to the storage server 1700M. This directive instructs file storage server 1700M to send the file with ID tag 3 to the SDNP gateway at address IP M _0,8 , using zone U90 security credentials. Other C&C packets (not shown) send nodes F _9,4 and M _0,8 as well as nodes in the SDNP cloud to other file storage servers and gateways, as well.

In FIG. 97E, signaling server 1715 sends data packet 1810D to client device 1700A, and the packet is routed from address “IP S” to “IP C _1,1 ” via router 1702G. Data packet 1810D tells the client to anticipate a number of received data packets with tag 1, tag 2, etc. from SDNP gateway 1701U at address “IP M _0,0 ” using zone U1 security credentials. It includes the C&C payload 1811D that informs. At the same time, signaling server 1715 also sends data packet 1810E to SDNP gateway 1701U, and the packet is routed from address “IP S” to “IP M _0,0 ”. This packet contains a C&C payload 1811E for last mile routing within zone U1 that can be applied for incoming data packets identified as tag 1, tag 2, and tag 3 transmitted from within the SDNP cloud.

Once command and control data packets are distributed over the network, file delivery can occur. The first stage of delivery is shown in FIG. 98 , where a data packet 1741R comprising FS link 3 has an exemplary state 920, a numeric seed 929, a decryption key 1030, and an encryption key Information including 1022 is provided to the SDNP decoding operation 1751R. packet decryption 1032R, where instead of SDNP decoding operation 1751R, this information is processed by the DMZ server 1762, all done in state 920, which is the state the parsed file was in last time it was encoded; Executes functions involving shared secrets such as mixing (1061R), de-junking (1053R), and unscrambling (928R). It should be noted that the encryption key 1022 is not specifically required for file decoding, but can be used in symmetric key encryption to transmit the parsed file back to the client and the file owner.

File routing and data transfer is shown in FIG. 99, which includes TCP data packet 1720A carrying file 1 from address “IP F _7,1 ” to “IP M _0,4 ” using U7 security credentials; TCP data packet 1720B carrying file 2 from address “IP F _9,4 ” to “IP M _0,8 ” using U9 security credentials, and address “IP F _9, ” using U9 security credentials. ₁ " to "IP M _0,8 " contains TCP data packet 1720C carrying file 3. After transmission through the SDNP cloud (not shown), a series of data packets 1720X are forwarded from the SDNP gateway at address “IP M _0,0 ” to the client address “IP C _1,1 ”.

In a read operation, the data is loaded into the SDNP App in its "read only" form. As long as the file remains sandboxed within the SDNP application, the file is protected by the features of the SDNP application and network, and is not dependent on the login process and weak security rules of the device's operating system. The need for read-only access to private documents is common in businesses. Files created by a company's finance, legal, manufacturing, engineering, and quality departments show examples of what often represent read-only content. In many cases, these corporate private files must be forwarded, i.e. distributed electronically, to corporate officers for review prior to their release.

Accidental or premature disclosure of communicated information can be catastrophic, with severe economic and even legal consequences for the company's and personal liability to the person in question. Unpublished financial reports of public companies, for example, are strictly confidential until they are disclosed. In the United States, regulation FD or “fair disclosure” means that information must be made publicly available to all at the same time without preferential treatment. If any external party has access to that information prior to its public disclosure, this would be a violation of Regulation FD. If a court determines that a violation of Rule FD occurred because the company neglected its duty to maintain and ensure the confidentiality of the documents, even in the absence of insider trading resulting from selective disclosure, the company would be guilty of the breach. and the person in charge may be held personally liable.

In the SDNP app, to prevent data transfer from one account identity to another, search files are classified (sandboxed), eg files cannot be swapped between business and personal accounts. Depending on the reader's authentication privileges, the user may or may not be able to download the retrieval file outside of the SDNP application and into unencoded storage within device memory.

Downloading a file outside of an SDNP-based application compromises the security of the file and the data it contains. To data within the SDNP application, access is controlled, user behavior is restricted, and both the device and the SDNP network must prove the user's identity. Such multi-layer multi-factor authentication is much more difficult to overcome than the simple destruction of a 4-digit pin needed to open a phone. In contrast, once a file is downloaded to a computer, tablet, or mobile phone, it is nearly impossible to prevent unauthorized access, to determine who has accessed it, or to determine who copied the file.

Thus, using SDNP communications, file owners can lock, or classify, sensitive documents and files so that others can read them but not download them to their phone. Screen shots or photography of the LCD display screen can be prevented using additional steps. In other cases where security and privacy are not required, the transfer of search files from the SDNP app to the phone's memory is possible and can be used without limitation.

In an edit operation, an editable form of the file can be downloaded into the device and passed to the application program needed to edit the file. There is no fundamental difference in SDNP network operation between a file read request and a file edit request, other than the operation of the client's SDNP application - in terms of data transfer in the SDNP network - to execute file requests and data exchanges, and those operations are functional equal to Accordingly, the difference between read and edit operations can be considered to exist mainly in the execution of layers 5 to 7 including application specific files.

To edit the retrieved file, the application can either (i) be a device-embedded application (e.g., Simpletext) native to the device's operating system, but operated outside of the SDNP application, or (ii) the device's operating system. on the SDNP application, but can be a third party application that runs outside of the SDNP application, eg Microsoft Word, Adobe Acrobat, etc., or (iii) can run inside the SDNP application and be accessed directly by the device or its operating system. It may be a security application that does not exist. For example, a company press release can be edited within the SDNP application sandbox, but cannot be downloaded into the phone's memory. As an added provision for maintaining business security, any files owned by the business, i.e., sandboxed within the SDNP business account compartment, will be stored in the user's personal SDNP account, even though the personal and business profiles are running within the same SDNP application. cannot be forwarded to

After editing, storage of the edited file on the SDNP file storage server does not overwrite the existing file unless specifically requested by the owner of the file.

Instead, the second version is stored in addition to the first version, and deletion of the previous version requires the user to execute a delete operation. Because hypersecure file storage always requires identity verification, the process of saving edited files may involve specific system features not available from file stores that do not have dedicated hypersecure network communications. One such specific feature is the signature verification function used to sign and date files (or stamp/chop and date in Asia). The signature function may include a registered receipt sent to the document holder and to the original document generator.

In a hypersecure data store made in accordance with the present invention, the erase operation is to overwrite all existing parsed files with random numbers and optionally do it again after 1 hour, resulting in a small but detectable charge or magnetic field in the stored bits. This includes making analog variations more obscure. The file records are also overwritten to confuse the file records of the data drive. After deleting the data and file records, the client's data link is destroyed within the client device using the message self-destruct feature of the SDNP system, and any remnants of the FS link are purged from the SDNP system. However, if a file system administrator tracks the activity of that user base with third-party software, even if the file itself has not been accessed, the administrator can determine who owns the file, when it was created, who accessed the file and when, and when the file was deleted. It can still retain metadata about the file's history, including when it was created.

The SDNP network and hypersecure last mile functionality may also support other features and behaviors for corporate accounts rather than personal account profiles. As discussed above, deletion operations in personal accounts involve rewriting junk data into files, purging the drive's index record for the existence of files, and using message self-destruction to remove files from previously fragmented storage locations. This includes the destruction of all FS links for However, in a corporate account, the file storage manager may require prior approval to permanently destroy the file, for example using an approval process similar to dialog box 1769 in FIG. 96A but sent to the administrator rather than the file owner. may need

If a company's file administrator chooses not to allow deletion of a file, several scenarios may arise, including: (i) the file will not be deleted and the file read link will appear in their SDNP application or SDNP Communicator message history. or (ii) the owner of the file is notified that the file will not be deleted, i.e. it will be retained for "archival purposes", but the private file reading link will not Using destroy rules, they will be removed from their SDNP application, meaning that only the file storage manager can recall them if the owner tried to delete the file, or (iii) the file owner's private file read link They will be removed from their SDNP application using the SDNP system's message self-destruct policy, but they will not be notified that the file is being maintained by the company.

Due to the last mile hypersecurity inherent in the operation of the disclosed anonymous fragmented and distributed file storage system, stored files are not retrievable without a "file store read link", even by a file store manager. In order for administrators to gain access to a file, they must be on the corresponding file save read link each time the file is saved and edited. While this level of monitoring is possible for corporate accounts, the sheer volume of data generated when tracking every change to every file will always overwhelm any file management system. The intelligent filter possible in the disclosed SDNP system as disclosed tracks only attempted file deletions. In this approach, administrators do not monitor the creation of files, but only track attempts to delete files. Whenever a file owner attempts to delete a file, and only then, the corresponding file store read link is passed to the administrator's database or console for approval or storage.

By identifying specific employees and contractors that require monitoring, database size can be further minimized. For example, if a company is involved in an audit or patent litigation, the parties are usually notified not to delete any relevant data or not to delete any files. Using the file management features enabled by the disclosed SDNP file storage system, any file deletion attempts by personnel involved in an investigation can be tracked by logging the attempted deletion, and in some cases "at that time" A copy of the file storage link may be sent to the file storage manager or to an independent investigator. Such a method is advantageous, as it limits the amount of data being monitored, and it alerts administrators to suspicious activity that will, of course, try to cover up the wrongdoing. In order to prevent accidental or malicious loss of the file storage name link by destruction of the device itself by the client and the file owner, the use of duplicate file storage links as described above is essential. In the case of a company, backup copies may be maintained on computers located in secure offices or on centralized company servers.

In extreme security cases, for example national security cases, deletion of a file may involve a multi-step method including: (i) overwriting the file with random data, (ii) storage copying all other files on the drive onto some other storage device, (iii) performing a bulk erase of the drive, (iv) reformatting the drive, (v) overwriting the drive's storage fields with a random number. writing, and optionally (vi) copying the preserved files back if necessary. Unlike conventional file overwriting of data, the bulk erase process affects the read-write storage medium itself, naturally randomizing its electrical, magnetic, or optical properties at the molecular level. Bulk erasing of magnetic drives can use large electromagnets, bulk erasing of flashes can heat ICs to high temperatures and possibly expose them to high operating voltage ionizing radiation. Magneto-optical drives can be bulk erased using large magnetic fields. A rewritable optical drive can be bulk erased using a bright scanning laser that is scanned across the disc format track. In any case, bulk deletion represents an extreme case where the storage medium loses data completely after erasing, even taking the risk that the storage medium is damaged and cannot be used again.

Another important factor in a hypersecure distributed file storage system is maintaining the integrity of file data and link access. To ensure against accidental loss of the link, it is sometimes advantageous to re-establish, i.e. re-verify, the file storage read link and re-issue the security credentials. This process, referred to herein as a "refresh link" command, may be initiated manually or automatically from the client, and also from the file storage server after some predefined interval. In the case of a request initiated by a client, the SDNP signaling server communicates command and control packets to the corresponding server. When a link refresh is initiated as shown in FIG. 100 , the file is SDNP in state 320X, in an “old” state at time t ₁ , where it was previously created using zone (U9) security credentials. It is read and decoded by decoding operation 1751F. The file is then re-encoded by SDNP encoding operation 1750D using the new state 920Y at time t ₂ and stored to the storage drive. The refreshed storage link, e.g., FS link 3, is then sent back to the file owner, client device 1700A, over the SDNP network. The resulting file contains the encoded data updated with zone U9 security credentials at time t ₂ . However, the client's security credentials in zone U1 used to create and parse the original file are not updated. To read the file, the read operation must first decode the file using zone U9 security credentials in a state corresponding to time t ₂ , and then, after transmission to client node C _1,1 , the file Decode the file using the zone (Z1) security credentials associated with the time it was first created.

As another provision for enhanced security, the redistribution file operation moves all parsed files for the selected file storage link to a new or different file storage server. Such an operation may send the parsed file to an entirely new server, or alternatively the file may be redistributed among existing storage nodes. In each case, the security credentials are updated and a new file FS link is issued and sent to the client or clients that have access to the file. This operation is shown by way of example in FIG. 101 , where the content of the file storage SDNP node F _7,1 in zone U7 is in state 920X, which is the state at time t ₁ when the file was created. It is decoded by the SDNP decoding operation 1751H using The file is then transferred over the SDNP network (not shown) to the file storage SDNP node F _9,4 , where the file is in state 920Y corresponding to time t ₂ using zone U9 security credentials. and encoded by the SDNP encoding operation 1750L. The file is then saved and the updated FS link 2 is sent to the file owner and other clients with access to the file.

Simultaneously with the aforementioned file delivery, the content of the file storage SDNP node F _9,4 in zone U9 is SDNP decoding operation 1751L using state 920X, which is the state at time t ₁ when the file was created. ) is decoded by The file is then transferred over the SDNP network (not shown) to the file storage SDNP node F _9,1 , where the file is in state 920Y corresponding to time t ₂ using zone U9 security credentials. and encoded by the SDNP encoding operation 1750M. The file is then saved and the updated FS link 3 is sent to the file owner and other clients with access to the file. In a similar manner, the content of file storage SDNP node F _9,1 in zone U9 is the state at time t ₁ when the file was created by SDNP decoding operation 1751M using state 920X. decoded The file is then transferred over the SDNP network (not shown) to the file storage SDNP node F _7,1 , where the file is in state 920Y corresponding to time t ₂ using zone U7 security credentials. and encoded by the SDNP encoding operation 1750H. The file is then saved and the updated FS link 1 is sent to the file owner and other clients with access to the file. In this way, all three files are relocated, new security credentials are issued, and clients with authenticated access are issued new file store read links based on updated FS links 1, 2, and 3.

Another essential maintenance function performed by the hypersecure file storage system is the operation used to check files that do not have any live links, i.e. "zombie files". This operation is similar to the refresh link operation, except that it is initiated by the file storage server instead of the client or the file owner. In operation, each file storage server tracks the time since a file was last accessed. If the last action on the file exceeds a specified interval without activity, for example one month, the file storage server contacts the client or clients to see if the link is still active. The file storage server may contact the client using the same method used to send the FS link to the client. At the time the file is stored, the file storage server holds the client's SDNP home or pseudo-address.

In case of no activity for a certain interval, the file storage server contacts the SDNP signaling server with a request to reconfirm that the link remains active. Then, the SDNP signaling server plans the delivery path of the FS link verification request for each participating file storage server. Each file storage server then sends the request to the client over the SDNP network. All participating SDNP client nodes respond with a confirmation that the file link still exists in the device. If the file link is confirmed, at that time the client has the option of performing a link refresh. However, if there is no device response, i.e. if an active file reading link is not maintained, the file storage server notifies the administrator that the file link has been interrupted or lost, and after a predetermined interval, such as 1 to 3 months, Permanently or irrecoverably delete unsolicited zombie files.

Registered Communications - Another feature of SDNP communications made in accordance with the present invention is the network's ability to forward or store "registered communications". Registered communications include hypersecure delivery of communiques as signed, time-stamped messages or hypersecure storage of files, including the ability to e-sign and e-chop communications to establish legal validity. includes Registered communications also include the ability to send a “certified message” handshaking method that confirms receipt of a document or file using a signed or chopped, time-stamped response. All registered communications are initiated by the SDNP application in the client device, but are verified through last mile communications, i.e., communications across the last mile of the SDNP network. Any attempt by the client to tamper with the stamp confirmation will result in a discrepancy between the message and the network record of the stamp confirmation, i.e. receipt notification.

Time stamping is a unique feature of SDNP communication by means of the use of "state" in SDNP communication, i.e. where time and other specific variables are used to construct message specific security credentials in communiques and in file storage. This point is illustrated in the SDNP Communicator application window 1800 shown in FIG. 102 , where each text message sent and received changes when a message is sent, when a message is received, and when a message is read. has a corresponding set of time stamps 1801A and 1801B representing Time information including the global time reference established by the SDNP signaling server is delivered to the client through the last mile network. The SDNP client app then incorporates the time stamp into the information display.

In registered communications, Communique creates an official stamp as part of the process. One example of a registered communication process is shown in FIG. 103 , where a hypersecure message is executed and begins with an optional file attachment step 1802 including a dialog box 1803 in which the message or The client sending the file, i.e. the sender, chooses whether or not to attach the file to the message and if so, uses a directory browser to find the file. Command dialog 1804 is then used to send the registered message, depending on dialog box 1805 choosing whether to use regular or registered delivery. Messages are then transmitted using hypersecure communications established in accordance with the present invention.

In the "message accepted" step 1806, the receiving party completes a series of steps necessary to verify their identity in order to access the message and to send an authenticated receipt confirming acceptance of the received message and file. This process begins with receipt authentication operation 1807, where receiving clients are asked to verify their identities. In the absence of their identity verification, the receiving party will not be able to access the message, the message will be destroyed and the sender will be notified of the authentication step failure. In this way, the sender can be alerted to the possibility that the receiving party may have their device stolen. Once identified, the receiving party is queried in an authentication of receipt operation 1808 as to whether they wish to accept or reject the received messages and attachments. In case a message is rejected, the sender is notified.

If the receiving party accepts the message by selecting 'yes', they may accept the message by selecting an electronic signature (e-sign) and/or by selecting a stamp/chop (e-chop). To do this, it is necessary to complete the receipt management step 1809 for signing. The sender may specify the options requested. In some countries, both chop and sign are required for legal binding purposes. A subsequent dialog box (not shown) instructs the user to place the sign or chop into the device's file directory. Alternatively, an audio/video recording may be used as confirmation. Recipients are instructed as to what to read during recording. Once the message is signed, the message can be viewed by the recipient and the attached file can be viewed or downloaded according to the sender's requirements.

Upon acceptance of the document, a signed time-stamped message receipt 1811 identifying the recipient of the message, the embedded text received and attached filename, the date and time the message was received, and an e-sign, e-chop A sign comprising either an audio recording, an audio-video recording, or some combination thereof is sent to the sender in an alert operation 1810. In the Archive Receipt option 1812, the sender will store a copy of the signed, time-stamped message receipt 1811 in the receiving system's hypersecure file storage system for the file read link 1813 the sender needs to recall the message. have a chance to Alternatively, the message receipt 1811 can be used for download into the sender's device.

Encryption-Based Security Issues - Government security agencies can trace callers to corporate crimes, IP theft, cybercrime, hacking, criminal gangs, drug cartels, mafia, yakuza, jihadists, and terrorists, such as Hyundai Corporation. Any communication system (metaphorically, payphone) that provides anonymous communication without data security, i.e. a system that uses encryption for data security and concealment of the identity of the caller, is an indiscreet and irresponsible business practice for network operators, application developers, and device manufacturers. It claims to provide

Unfortunately, it is true that communications that rely on encryption to achieve security similarly protect criminals and law-abiding citizens. As mentioned above, this subject focused on many new stories about the criminal activity of ISIS terrorists and their attacks in Paris and Belgium, using a phone application called Telegram. These apps help secure communications using end-to-end encryption, also known as end-user based encryption. End-to-end encryption is particularly problematic for security authorities because the decryption key is maintained only by the two communicating parties and not by the intervening network or its operator. Security authorities dealing with Telegram argue that the big-key end-to-end encryption presents a national and even international security risk that allows terrorists to operate covertly using open communications. Arguments in favor of Telegram support personal privacy, among other things.

California on December 2, 2015, killing 14 people and wounding 22 when a federal judge, in favor of the FBI, orders Apple to assist in "opening" a locked phone allegedly in the shooter's possession. The privacy controversy surrounding the San Bernardino shooting has re-emerged. On February 17, 2016, the Washington Post article was titled "Apple Vows to Deny FBI Request for iPhone Cracks Linked to San Bernardino Attack". Apple and its CEO cited several reasons for not following the court order. The article is available online 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-l le5-9823-02b905009f99_story.html). Most notably, Apple has steadfastly asserted that the new iPhones cannot be unlocked for law enforcement purposes, even when officials have a warrant, because they have been engineered in such a way that Apple does not have the decryption key - essentially end-to-end. Another example of the challenges of end-encryption is a panic about it. Apple claims that only the phone's user - or someone with the password - can unlock the phone. The government asserted that it was not necessary to unlock the encryption feature, only to disable the feature which erased the phone's memory after 10 unsuccessful login attempts. In an online statement, Apple CEO Tim Cook countered that such a step could dangerously weaken iPhone security. He said: "Once created", "such technology can be used over and over again in any number of devices. In the physical world, it will unlock hundreds of millions of locks - from restaurants and banks to stores and homes. It would be the same as the master key that could be used. A reasonable person would not allow that." He went on to say, "It is by no means frivolous to oppose these orders. We believe that we must speak out against the request of the US government to go too far."

Apple's final point that the U.S. judiciary has overstepped its powers is a legal argument, not a technical position, and those echoing the sentiments of constitutionalists and privacy advocates argue that the government can monitor communications for no apparent reason. or claim that they do not have the legal authority to invade the privacy of individuals. The controversial idea of creating a universal backdoor that could open any communication device would lead to abuse of power by the authorities, although in the case of San Bernardino in particular it clearly meets the criterion for good reason. In their February 23, 2016 article, The Atlantic concurred, saying "Apple is right: the FBI wants more phones infiltrated." On the same day, the Guardian reported that "Apple claims the FBI wants access to dozens of iPhones."

Oddly enough, the US Congress has taken the same privacy-related position. In a March 1 follow-up article in the Guardian titled "Congress Announces FBI Pressuring Apple to Unlock iPhone Is 'False'," US lawmakers accuse US lawmakers of invading and encroaching on privacy criticized As Microsoft legal counsel Brad Smith said at the RSA Conference in San Francisco, "The passage to hell begins with the backdoor." Smith challenged the computer security industry presented at a rally "to support Apple in this important event".

Amidst the fire, a number of security experts, including NSA whistleblower Edward Snowden, have published the view that unlocking phones is not as difficult as the FBI claims. In a discussion via video link to the Common Cause Blueprint from Moscow for the Great Democracy Conference (March 8 and 9), Snowden said: "The FBI says Apple has a 'proprietary technical means' to unlock phones. ’. To put it mildly, this is bullshit.” Before the case went to court, the FBI reported that it had already found a way to break through locked iPhones. On March 29, 2016, a Fortune Magazine article reported, "The FBI did not tell Apple how it cracked the iPhone."

The legal and geopolitical consequences of the Apple-FBI case were far-reaching. Following the FBI's lead, other countries are expected to assert backdoors on all communication devices connected to their networks - including phones carried by US citizens traveling the world. Also, now that the iPhone has been successfully hacked, criminals will one day discover or re-invent these methods to commit new forms of cybercrime and identity theft. In order not to fall prey to criminals, governments may try to use the same methods to extend surveillance and espionage, and even different departments within the same government may use these methods to spy on each other's activities. As a related story, several governments consider limiting the level of encryption used in end-to-end communications.

Collectively, these events clearly support the realization that the apparent combination of existing security methods currently available in the public domain does not guarantee both security and privacy, at least without helping criminals and terrorists. The problem stems from relying solely on encryption to achieve both network security and end-to-end security and its associated caller privacy. Increasing the security of a text, voice, or file by increasing the bit size of an encryption key makes any communique more secure and more difficult to crack. Enhanced security protects businesses and law-abiding citizens in maintaining security and privacy, and in combating identity theft. Unfortunately, the same enhanced security, without discrimination, protects criminals and terrorists from detection, allowing them to operate with impunity and without exposure.

This point is illustrated in FIG. 104A, where a caller 1825A is communicating via an unsecured network, such as the Internet 1821, which is subject to many cyber-attacks, i.e., a network with a large vulnerability "attack surface". Communicates to speaker 1825Q. To reduce the attack surface, encryption (1026) and decryption (1032) are used to form an encrypted pipe or tunnel (1820) with a smaller attack surface than the network (1821). The problem is to determine how large an encryption key should be used. As shown in table 1824, the larger the encryption key, the more combinations there are and the harder the password is to crack. Encryption is used for two purposes: (i) to provide network security to prevent man-in-the-middle attacks, and (ii) to ensure caller privacy through end-to-end security. As shown by line 1823, any improvement in network security results in an equivalent improvement in end-to-end security. While high network security is beneficial in preventing malicious external attacks, excessive end-to-end encryption is a double-edged sword. When a large key size is used, eg AES256 or AES512, the system delivers "top secret" network performance and, of course, provides the same level of security for the caller. However, if the caller is a suspected criminal or terrorist, the network operator or government cannot detect or monitor the caller's activities.

The key size trade-off is complex. If the encryption key is too small, criminals can attack the network and its users as targets. If the encryption key is too large, criminals can use the network to hide their illicit activity and to cripple investigators' efforts to detect fraud and misconduct in progress. In a corporate environment, the corporate security policy may disapprove of end-to-end encryption altogether, as it prevents monitoring employee activity or following corporate investigations and IP litigation.

Even determining what size keys are breakable and how secure is difficult, and will depend on advances in technology. Referring again to table 1824, the number of possible combinations that must be analyzed in a brute force attack is calculated as a function of the key size of the cipher. A 16-bit key has only 65k combinations, a 56-bit key has 10 ¹⁶ combinations, and a 128-bit key has more than 10 ³⁸ combinations. A 256-bit key has 39 more digit combinations than a 128-bit key. Ignoring the use of pattern recognition, brute force attacks try all combinations to crack the code. In an EETimes article titled "How to secure AES against brute force attacks?" We estimated the time required on a 2012 supercomputer capable of 10.5 petaflops. A petaflop is a thousand trillion or 10 ¹⁵ floating point operations per second, or one thousand teraflops. Thus, a 56-bit key takes only 399 seconds, a 128-bit key takes 1.02 x 10 ¹⁸ years, a 192-bit key takes 1.872 x 10 ³⁷ years, and a 256-bit key takes 3.31 x 10 takes ⁵⁶ years.

The time required to overcome a brute force attack also varies. Since the article was written, the world's fastest computer has already tripled in speed. As reported in a BBC News article of 30 July 2015 titled "Supercomputer: Obama Orders World's Fastest Computer", the investigators found that the target speed of the next supercomputer would be 20 times greater than the record-holding computer. They reported that it was fast, ie a machine capable of exoflops per second, or million-million floating point operations. This means that the time required to crack a password continues to decrease each year. Another novel approach to cracking cryptography is to use massively parallel processing, the same method as bitcoin mining. Instead of having one supercomputer, using thousands or even millions of parallel computers allows an attack to proceed simultaneously in proportionally less time. Today's fastest microprocessors have already broken 1.1 teraflops, so 3,000 top-of-the-line microprocessors working together equal the world's fastest computer today. Only one million microprocessors are required for the realization of an exoflop computer. While dedicated ASICs can further compromise security, quantum computing will change computing power by many orders of magnitude.

As a result, large key end-to-end encryption is not a good solution for achieving privacy and security in communications. An alternative approach enabled by SDNP networks and hypersecure last mile communications as disclosed herein separates end-to-end encryption from network security. As shown in FIG. 104B, communication between SDNP clients 1700A and 1700Q representing the caller and the called party, respectively, is performed by the SDNP network 1831. The network's small attack surface is realized by anonymous multi-path and meshed data transmission using routed, dynamic scrambling, fragmentation, junk insertion, and hop-by-hop encryption using tri-channel communications for control. do. Although the last mile communication and every hop in the SDNP cloud involves dynamically changing security credentials, the process is provided in a simplified form by SDNP encoding operation 1832 and SDNP decoding operation 1833.

As illustrated by table 1834 and illustrated by line segment 1830, these methods, in various combinations, achieve security equivalent to secret or top secret encryption standards without relying solely on encryption. Because line segment 1830 is flat, this means that there is no interdependency between end-to-end encryption, shown on the y-axis, and network security, shown on the x-axis. Instead, the network security level can be adjusted from Case A to Case D by applying various SDNP security methods. This security operation is implemented by the SDNP software in such a way that neither the caller nor the called party is aware of the security credentials used to transmit data packets over the SDNP network 1831 and its various secure zones. In particular, the interacting clients do not knowingly participate in the key exchange of any cryptographic last mile network. As a decentralized network, the use of encryption within the SDNP cloud is not related to last mile security, and there is no master key for such a system. Thus, SDNP network 1831 security does not rely on end-to-end encryption performed by encryption 1026 and decryption 1032 to create an encrypted pipe or tunnel 1820.

The encryption used by the SDNP network 1831 does not need to use the same size key as the end-to-end encrypted tunnel 1820. As shown in the graph, commercial and corporate security applications of end-to-end encryption are 128b (like AES128) shown by the dotted line 1835, even if the single-hop dynamic encryption within the SDNP cloud uses AES256. Key encryption can be used. In fact, end-to-end encryption can use RSA or other ciphers without compromising network security. SDNP network 1831, even if not end-to-end encrypted tunnel 1820, is still protected by AES encryption following FIPS 140-2 military grade security. As described, the SDNP network 1831 protects against all external cyber-attacks and man-in-the-middle attacks. The end-to-end encrypted tunnel 1820 protects the caller from network operator intervention and other "inside" hacker actions. In this regard, end-to-end encryption in this disclosure is used primarily to ensure caller privacy, not to achieve data packet transmission security.

Since the strength of end-to-end encryption can be increased or decreased or even removed without jeopardizing the security of the network, such a method can be adapted for a wide range of applications. For example, if the 128b key encryption shown by dotted line 1835 is too strict for small business or personal use, the number of bits can be reduced without giving up personal privacy. For military or governmental applications, the encryption key length can be increased to 192b, 256b or even 512b as needed. In this regard, the disclosed SDNP system overcomes a shortfall in today's cryptographic-based currencies, providing features not available by any alternative application, device, or network.

Security Management - Another key feature of SDNP communication is its specific approach to security management. Security management is required in many situations, including:

* Monitoring of employee communications conducted in accordance with HR policies or employee investigations;

* Monitoring and recording of employee communications in auditing, forensic accounting, or accounting reporting support;

* Documentation of intercompany communications as part of merger and acquisition transactions;

* Documentation of intercompany communications as part of an IP or corporate litigation;

* To comply with the demands of communiqués and documents under subpoenas and criminal investigations;

* To comply with legal mandates for monitoring account information, calls and messages, and file access related to national security.

With proper authentication, SDNP network administrators can facilitate access of SDNP network traffic to designated "SDNP Security Agents" for monitoring communications and monitoring data. The process of building and enabling the SDNP security agent includes a multi-layer authorization and authentication process that is necessarily performed prior to monitoring activities. To prevent abuse, no individual, not even SDNP network administrators, can initiate monitoring independently. Due to the dynamic nature of SDNP communications as a decentralized network with no central control, with no master network key and with dynamic SDNP encoding and decoding performed using zone-specific security credentials operating offline within the DMZ server. However, there is no mechanism for restoring data or recalling conversations after the fact. Data stays within the SDNP network for only a short duration, typically less than 100 milliseconds. As a decentralized system, the SDNP network is inherently designed to have no central control, and without such central control even metadata of previous calls is not available. Thus, SDNP networks support only a priori security monitoring, which means that monitoring by designated SDNP security agents must be established prior to hijacking a communique.

Also, due to the dynamic nature of fragmented meshed communications within the SDNP cloud, SDNP nodes within the cloud do not carry data packets of complete conversations, i.e. beyond the SDNP gateway. Most nodes carry less than 5% of the data and typically only for 10 ms in the time before a routing change. In accordance with SDNP communications, dynamic routing continuously redirects communications through different media servers. Therefore, cloud access is not available for restoration or monitoring of communiques. Data packets of the SDNP cloud may be captured, but they contain a useless mix of irrelevant sounds, data, conversations, and junk data. Instead, monitoring by a designated SDNP security agent can only productively occur within the last mile, where the complete set of relevant data packets essentially traverses within the client device or preferably within the SDNP gateway.

An example of data packet routing in security monitoring is schematically shown in FIG. 105A, where SDNP security agent 1840 monitors the conversation between SDNP client device 1600A and SDNP client device 1600H. Conversation takes place using data packets transmitted from the SDNP client device 1600A through the last mile router 1602G to the SDNP gateway 1701U and through the SDNP cloud, while the data packets transmitted from the client device 1600A are SDNP It is closed by gateway 1700U and safely routed to designated SDNP security agent 1840. Specifically, during UDP transmission, last mile data packet 1630A carries SDNP data 1 from the SDNP client at address “IP C _1,1 ” to the SDNP gateway at address “IP M _0,0 ”, It comes from the SDNP gateway at IP M _0,4 "and is forwarded to the SDNP client address "IP C _7,1 " via U7 last mile. During authenticated monitoring, the replicated SDNP data 1 is securely delivered to the SDNP security agent 1840 at the SDNP address “IP SA”. Duplicate monitoring data packet 1841 works in the same way as SDNP group-call, except duplicate data copies are visible to callers. As such, the caller is unaware that they are being monitored.

Security monitoring also works on incoming calls. In FIG. 105B, SDNP data 7 is transmitted from client device 1600H with address “IP C _{7, 1} ” to the SDNP gateway at address “IP M _0,4 ”. After SDNP cloud transfer, the data is forwarded from the SDNP gateway at address “IP M _0,0 ” to two destinations. The first destination, client 1600A at address “IP C _1,1 ”, receives response data packet 1640A containing SDNP data 7. The second destination, SDNP security agent 1840, receives, via data packet 1842, the same payload containing the replicated data "SDNP Data 7". The delivery of data packet 1842 is not visible to the callers, so they are unaware that they are being monitored.

The same method can be applied to the monitoring of fragmented distributed file storage. However, instead of capturing fragmented data files, the security agent only needs to receive a copy of the associated FS link. An example of such is shown in FIG. 106, where SDNP file storage device 1700H transfers data packet 1740H containing FS link 1 from address “IP F _1,1 ” to gateway address “IP M _0,4 ”. transmit, which is forwarded to client 1600A by data packet 1740A after being routed through the SDNP cloud. The replicated payload “FS Link 1” is also delivered to SDNP Security Agent 1840 at address “IP SA” by data packet 1843 sent from gateway address “IP M _0,0 ”. As in the case of real-time communication, the file owner, client 1600A, is unaware that it is being monitored by the SDNP security agent.

The same monitoring mechanism works for multi-path last mile communication, where data packets enter and exit the SDNP cloud through more than one SDNP gateway. This case is illustrated in FIG. 107, where the last mile communication from client device 1600A is split data packet 1630A containing payload SDNP data 1, and to the cloud via SDNP gateways 1701U and 1701V, respectively. The incoming payload includes data packet 1630B carrying SDNP data 2. After SDNP cloud routing, the data packets are reassembled and shown coming out of the cloud as a single data packet 1630L with a payload containing the combined data SDNP data 3. In operation _{, the} Signaling Server is directed to address "IP Indicates the SDNP gateway with M _0,0 " and "IP M _0,11 ". The replicated data is used for all SDNP data transfers, except that the security agent operates within its own specific security zone, i.e. within an zone (SA) that uses credentials that are not available on any other device. are transmitted within data packets 1841A and 1841B using the same hypersecure method as described above. Therefore, there is no record or evidence that a specific conversation was monitored by a designated security agent.

Because SDNP monitoring activity is the equivalent of a covert and essentially undetectable, undetectable conference call, SDNP systems must be used to authorize and verify the use of network monitoring and to designate and verify SDNP security agents authorized to perform monitoring. It is important to use independent checks. A SDNP security agent can be any SDNP client, except for network managers. As a protection against system corruption, any SDNP network operator or SDNP administrator cannot act as an SDNP security agent, i.e. anyone administering the network can destroy that capability for themselves, even when they are threatened or blackmailed. Can not.

SDNP security agents may constitute individuals, government agencies, government designated representatives, or law enforcement officers. The specific required qualifications of designated security agents vary by company or country depending on applicable regional laws. The SDNP security agent's monitoring hardware may include communication devices and computer servers with recording, data storage, and sophisticated decryption capabilities. All communications sent from the SDNP network to designated SDNP security agents are transmitted in the same hyper-secure communications as the client's communique itself, so that security monitoring, with the exception of monitoring conducted by authorized security agents, does not protect the confidentiality of calls or It does not compromise the privacy of the caller.

In addition, monitoring of authorized SDNP agents and implementation of permitted capabilities does not compromise network integrity and security by any means. No operational details or DMZ shared secrets are exposed to the network operator or to any security agent - the operation of the SDNP system is automatic and autonomous, without human operator intervention or involvement, while the DMZ server has online access Provides security by using zone-specific credentials that cannot be used through As such, security monitoring does not degrade the security of the system or make the SDNP network vulnerable to cyber attacks.

The data payload is delivered to the SDNP security agent in the same format as generated by the caller. As part of the delivery to the SDNP security agent, all network SDNP encodings are decoded so that there are no network security provisions within the data packets being delivered. However, if the client uses end-to-end encryption, the client agrees to pre-share the end-to-end decryption key with the network or to use an independent key server utility accessible by the SDNP network. If not, the SDNP security agent will have to break the client's end-to-end password. To reiterate, such end-to-end encryption and decryption keys are primarily included in the SDNP method for privacy purposes and are not related to any encryption used in the SDNP dynamic encoding function.

To minimize the risk of monitoring abuse, SDNP management is a multi-step process used to establish and authenticate designated SDNP security agents for monitoring a client or group of clients. Although the SDNP system contains provisions for implementing monitoring, the lawful application of these features is the responsibility of network operators, network administrators, and authentication agencies or agents. Together, these parties are personally responsible for ensuring that monitoring is conducted legally and in accordance with the laws of the country where monitoring is conducted.

Monitoring needs can arise from any number of circumstances. In a company, a whistleblower complaint or claim related to sexual harassment can trigger an HR investigation or result in forensics. Court subpoenas related to litigation matters (potentially including gag orders) may also require monitoring. In corporate matters, communications using corporate SDNP networks are generally limited to corporate communiques and do not cover private and personal communications. In most countries, private communications are protected unless criminal intent is suspected. In case of national security or law enforcement actions, both public and private SDNP accounts of callers may be monitored. In such a case, the corporate SDNP network operator for the company will implement the monitoring process for the company communications, while the independent telecommunications SDNP network operator will be the only provider in position to carry out monitoring of the caller's private communications. . In some countries, governments must present a court-approved subpoena to initiate monitoring of private citizens, while in other countries, governments may assert fact-based authority to monitor any and all private communications. In the case of international communications, it is more difficult to determine what laws may apply and where the network should be located to enable call monitoring.

One example of an AAA process used to enable monitoring is shown in FIG. 108 . The process for approving monitoring of a client includes a network manager 1850 used to set up monitoring operations, a security agent 1840 responsible for monitoring the client, preferably operating autonomously and independently of the network operator or network management. , and three authentication agents 1851A, 1851B, and 1851C used to authorize the monitoring process. The process begins with the network administrator 1850 wishing to make a monitor request 1862 in response to an investigation or court order. Using command dialog box 1862, the administrator identifies the phone number of the individual for whom monitoring is requested. If the request is to monitor a group of people, they can be entered one by one into the system in a file listing all parties, and their associated phone numbers uploaded into the system.

In authentication step 1863, network manager 1850 uses exemplary dialog box 1864 to identify recommended candidate security agents 1840 to implement the monitoring function. In the case of a company, an individual may be a HR supervisor, legal counsel, member of an audit committee, and independent accounting firm representative, or independent investigator. In legal cases, the security agent may be a solicitor, district attorney, FBI agent, or other duly appointed investigative committee member, such as a special prosecution committee investigative panel, for example in cases of government misconduct. The system then checks with the SDNP name server 1714 to ensure that the security agents have SDNP accounts and that they comply with the rules specified by the company or network operator. In some cases involving national security, a follow-up examination of the proposed security agent credentials and criminal record may be conducted prior to its approval.

If the security agent is approved, the request for monitoring is forwarded to authentication agents 1851A, 1851B, and 1851C in authentication step 1865, and the authentication agent determines the name of the description about the subject, the security with the task to perform the monitoring. Review the information present in dialog box 1866, including the name or location of the agent, the expected duration of the monitoring investigation, and the reason for the investigation. Each authentication agent can accept or reject the request. The network operator or corporate rules then determine whether the monitoring operation is approved based on unanimous approval of the authentication agents or simply approved by a majority. The identity of the authentication agents may be known, as in the case of a company, or in the case of a crime, their identity may remain anonymous and protected by the anonymous communication feature of the SDNP network.

If monitoring is approved, in a management step 1867, the database of clients 1868 is updated in the name server 1714 to tag the SDNP clients being monitored, SDNP clients authenticated as secure agents, in this example shaded data. identify the row of The SDNP addresses in this database are updated together daily, when SDNP addresses are mixed, in order to maintain the same relationship between monitored clients and designated security agents. When the survey date expires, the monitoring link is automatically disconnected. In management phase 1869, SDNP security agents 1840 are sent to the link, enabling them to receive all ongoing communications from the identified clients being monitored. Their use of this information is not a matter of SDNP network operation. Unauthorized leakage of personal information by a security agent may constitute a crime for which the security agent is fully responsible.

Through this monitoring method of the present invention, the SDNP network can thereby support criminal investigations regarding fraud and potential terrorist activity, while maintaining a secure communication medium for law-abiding citizens. The SDNP network can securely forward private client communications to authorized persons pursuant to a lawful court order without endangering the privacy of innocent citizens or compromising the security of the SDNP global communications network. Because no backdoor or master key was used in the delivery of the court order, subsequent communications across the SDNP network remain anonymous and hypersecure. In this way, secure dynamic communications networks and protocols and their hypersecure last mile communications can provide security features unavailable by any other means, and end up being used by OTT and virtually all messenger and communicator apps. - Aid to crime and terrorism caused by over-reliance on end-to-end encryption can be completely prevented.

Overcoming the SS7 Vulnerability - If the Apple-FBI debate wasn't a big deal in the telecom and security industry, the 60 Minutes episode (http://www.cbsnews.com/news/60-minutes-hacking-your-phone/) It has exposed a serious security vulnerability in Signaling System 7 or SS7, a signaling control channel for conventional wireless telephony. As evident from that show, SS7 vulnerabilities potentially expose all smartphones and connected devices to packet sniffing and cyberattacks, thereby eavesdropping on wireless conversations, by simply knowing a person's phone number, and SMS text, Allows viewing of attached files, and photos.

Signaling System 7 is a phone call signaling protocol developed in 1975 that is used in all forms of digital phone calls worldwide. This includes the message passing portion or “MTP” operations operated at PHY Layer 1, Data Link Layer 2, and Network Layer 3 to handle routing of calls. End-to-end routing is managed using the Signaling Connection Control Part or "SCCP" operation operating at transport layer 4. The protocol also includes a number of application layer 7 functions related to billing, roaming, and call authentication. The SS7 protocol, despite its inevitability, is extremely vulnerable to attack and presents a significant risk to the security of normal telephone calls.

In April 2016 (https://en.wikipedia.org/wiki/Signalling_System_No._7), the US Congressional Oversight Committee found that "applications with these vulnerabilities range from criminals monitoring individual targets to economic espionage against US corporations." There are thought to be no limits, from foreign businesses operating in the country to countries monitoring US government officials ...vulnerabilities have serious implications not only for individual privacy, but also for US innovation, competitiveness and national security. "Many innovations in digital security - such as using multifactor authentication - could become obsolete."

The SS7 cyberattack essentially results from the classification of packet sniffing, which intercepts both content and metadata by using the specific formatting of SS7 information as a guide. The SS7 protocol essentially provides an information template that allows packet information to be interpreted. As shown in Figure 109, the problem begins with the SIM card or "subscriber identity module", which contains various types of personal information about subscribers and their accounts. As shown, a carrier SIM card 1880, typically issued by a network provider, connects to the cellular network shown by antennas 25A, 25B, and 25C with corresponding radio links 28A, 28B, and 28C. It is used to identify the phone 32 for Each SIM card contains a unique identifier, an 18 or 19 digit ICCID or "Integrated Circuit Card ID" used to internationally identify the SIM card. The International Mobile Subscriber Identity or IMSI identifies the individual operator network, i.e. the home network in which the SIM card operates. The local network provider uses the IMSI number to communicate with the SIM card to establish a call.

The SIM card also includes a "mobile country code" or MCC, which is a three-digit number to identify the country in which the SIM card was issued. When placing an international cell phone call from a mobile phone, the MCC is required as part of the dialing sequence. Examples of MCCs include 310 to 316 for the US, 234 to 235 for the UK, 460 for China, 208 for France, 250 for Russia, 262 for Germany, 302 for Canada, 724 for Brazil. . The MCC is used in conjunction with the "mobile network code" or MNC to identify the network provider that issued the SIM card. A full list of codes is listed online at https://en.wikipedia.org/wiki/Mobile_country_code. The SIM card also contains a 15-digit "Mobile Station International Subscriber Directory Number" or MSISDN, which specifically defines the subscriber and type of network on which the SIM operates. The SFM card also maintains a user phone number and an SMS text directory, the SMS text directory includes a record of incoming and outgoing calls and sent texts with time and date information. In recent years, carriers have started using special SIM cards with so-called secure elements for storing credit card credentials to facilitate mobile payments.

Because the MCC, MNC, and MSISDN codes are sent as part of the linking process, the home country and carrier of any SIM card and subscriber's associated phone number can be easily identified by SS7 intrusion and packet sniffing. The transmitted data 1881 can be readily used to track the identity of the caller through phone directories, online information, or social media, i.e., through profiling. Once identified and correlated, the phone number and SIM can be used to monitor the subscriber's activity, regardless of where the subscriber moves around the world. Encryption does not hide underlying call information or metadata. Even with end-to-end encryption, data packets can be easily identified as coming from the same conversation, captured, and stored for subsequent decryption attempts.

In addition to metadata and content, the caller's location is also compromised by the SS7 vulnerability. In any cellular network, a phone sends a message to the local cell tower identifying if it is available for a particular call. These registration packets are transmitted at regular intervals. Monitoring these packets allows the location of a phone with a particular SIM card to be located, even when the phone is not busy and the GPS is turned off. In that way, the locations and movements of subscribers can be accumulated without their knowledge.

Despite the inherent vulnerabilities of SS7, hypersecure last mile communications built according to secure dynamic communications networks and protocols thwart SS7 attacks by obscuring meaningful call data within the last link. In particular, hypersecure last mile communications provide significant security superior to conventional phone calls or OTT Internet communications, including:

* Hypersecure last mile communication does not reveal the phone number or IP address of the calling party or receiving message, even if the party is not an SDNP client.

* Hypersecure last mile communication does not identify whether sequential data packets are part of the same call or represent unrelated data packets with different destinations.

* By hiding the call specificity of data packets, hypersecure last mile communication hides metadata about the duration of the call.

* Hypersecure last mile communications dynamically encode payloads, preventing unauthorized access to packet content and protecting the privacy of voice, video, and text communications, as well as photos, files, and other content.

Thus, as described, communications using the disclosed secure dynamic communications networks and protocols and hypersecure last mile communications are not affected by the SS7 vulnerability. Because SDNP communications are generated using its own protocol and carried by encoded payloads, even in packets carried over open, unencrypted channels such as 2G, 3G, and 4G/LTE telephony, call data or content can not be extracted from the SDNP data packet. As such, packet sniffing is ineffective in initiating cyber-attacks against SDNP coding and fragmented data transmission.

SDNP Concealment - In the foregoing, the SS7 vulnerability of only impact over SDNP communications is the disclosure of the location of the caller. Because the phone number in the carrier's SIM is associated with each user's identity, whenever the cell phone is turned on it essentially communicates with the nearest cell phone tower, even when no phone calls are taking place. Then, using this cell tower information, the user's location can be triangulated, and the subscriber's movement can be tracked even when the GPS is turned off. Because such unauthenticated tracking relies on SS7, devices using common carrier's SIM cards are vulnerable to location tracking, even if such devices act as SDNP clients.

As shown in Figure 110, a simplified network schematic diagram, the enhancement of last mile hypersecure communications, referred to herein as "SDNP concealment", avoids subscriber tracking entirely. To implement this feature, the generic carrier SIM card 1880 is replaced with the SDNP SIM card 1882. The SDNP SIM card is registered with the SDNP network operator, not the subscriber, so no personal subscriber information is included on the SDNP SIM card 1882. The SDNP SIM card 1882 is similar to a prepaid SIM card in that it has network access but no personal information. Instead, all of the account holder's personal information is securely contained within the SDNP network name servers and is not accessible to hackers or vulnerable to cyber-attacks.

In operation, SDNP concealment conceals the owner's true identity by using a SIM card 1882, known only to the SDNP network operator. Thus, the phone number contained in the SIM card is used to establish the PHY Layer 1 and Data Link Layer 2 connections 28B between cell phone 32 and cell tower 25B, but does not provide routing. Instead, data packet source and destination addresses for last mile routing are managed by SDNP App 1335A and SDNP Gateway 1601A according to instructions from SDNP Signaling Server 1603A.

Once routed through the SDNP gateway 1601A, calls from the SDNP app appear to have a different number than the SIM card number. This conversion from the physical SIM card number to the SDNP phone number is performed by the SDNP name server 1604A, while call routing according to the translation table 1885 converts the SDNP phone number to the SIM phone number, thereby changing any Conceal the physical SIM card number for the user. With SDNP concealment, the true identity of the phone owner is completely concealed. To make a call to an SDNP client, an external caller can make a call to SDNP #, even if they are not themselves SDNP clients. The SDNP network automatically routes calls to SDNP clients, never exposing the SIM card phone number. Similarly, the SDNP client places the call out to the non-SDNP called party, and the recipient of the call sees the incoming call from the SDNP #, not from the SIM card number. In this way, the SDNP implements a telephony function similar to that of a NAT gateway in Internet communications, except that the SDNP system is a real-time network and the Internet is not.

Since the true user identity of phone 32 is never exposed by call 28B, triangulating the phone's location is ineffective, since its user and all communications remain anonymous. Therefore, tracking the location of an unidentified mobile phone is not advantageous to hackers and avoids SS7 vulnerabilities. When an SDNP client travels internationally, the mobile can purchase a local prepaid SIM card and link it to its SDNP number. The SDNP subscriber will still receive calls located on that SDNP phone number, but the last link will be made using the local SIM card, thus avoiding roaming charges. In this way, a single SDNP phone number functions as an international phone number, with no long distance charges.

SDNP Subnet - Using its specific SoftSwitch software-based communication nodes, SDNP communication clouds can be deployed remotely across any network of interconnected computers, private or public hosted. Examples of server networks include privately owned, publicly leased networks, such as networks hosted by Microsoft, Google, and Amazon. Figure 111 shows two SDNP clouds deployed across two separate server networks. As shown, the SDNP cloud comprising servers 1901A, 1901B, 1901C, and 1901D hosts SDNP communication nodes M _0,0 , M _0,4 , M _0,7 , and M _{0, 8} , respectively. A second SDNP cloud comprising servers 1902A, 1902B, and 1902C hosts SDNP nodes M _10,0 , M _10,1 , and M _10,2 , respectively. Because they use separate security credentials for each of Zone (Z0) and Zone (Z10), the two SDNP clouds are completely separate and cannot directly share information. However, a single SDNP client, shown as a mobile phone 32 running the SDNP app 1335, has proper authenticated access to both clouds, even though they are hosted by different computer server rental providers. As shown by example, SDNP client C _{1, 1} can access _SDNP gateway node M 0, 7 in zone (Z0) cloud using hypersecure last mile communication through router 1910 and can communicate or It is possible to access the SDNP gateway node M _10,0 in the zone (Z10) cloud using hypersecure last mile communication through the same router 1910 without risk of mixing data packets.

Access to the two independent clouds is through a common communicator application (UI/UX 1920). Access to each cloud is partitioned within separate dialog sandboxes 1921A and 1921B. Although information can be downloaded into the phone from the personal account sandbox 1921A, data release from the business account sandbox 1921B depends on the business and corporate security management.

Connecting a device to the SDNP cloud requires installation of the SDNP app, either as software or firmware, into the device. Installation involves (i) downloading the application (ii) verifying device identity with an SDNP network-generated authorization code, (iii) establishing personally identifiable credentials, and (iv) obtaining authorization for specific SDNP cloud combinations. including receiving Once activated, the SDNP application creates a hypersecure last mile connection to the independent SDNP cloud. In many cases, identity validation and user authentication for business accounts is more sophisticated than required for personal account access, and may involve multiple authentication methods.

Because SDNP communication is software-based, there is no interaction between any installed SDNP communication networks, even when hosted by the same server, with distinct and separate security credentials for each communication cloud. With the zone-specific security credentials that uniquely form each custom SDNP cloud, no two SDNP clouds are alike and therefore cannot share data directly. Advantageously, multiple SDNP clouds can co-exist within the same server or network of servers, without risk of data leakage. Access to the business network is controlled as prescribed by the cloud owner's requirements. Thus, mixing of the two accounts and communication clouds is prohibited when sharing a common host server, operated with the same security, such as when two different phones are required to connect to two separate networks. The autonomy of zone-specific SDNP clouds or “subnets” is further illustrated in FIG. 112 , where servers 1901A, 1901B, 1901C, and 1901D have two cloud-Zone-Z0 SDNP communication nodes M _0,0 , M _{0 . _ _ _ _ _ _} Host 2 clouds simultaneously. Despite operating within the same server, hypersecure communication using the protocol built into SDNP prevents any direct data exchange. As such, access is governed by last mile communication, rather than through direct cloud-to-cloud data exchange.

SDNP communications are not limited to privately leased, publicly available servers, but can also be configured for different types of companies or government agencies. In fact, it is often desirable for a private enterprise to host its own network, especially for business-critical applications. Examples of private networks include FedEx, Walmart, IBM, etc. For confidentiality, networks used by research institutes, universities, and medical centers are also frequently self-hosted. The private server network also supports global business cloud applications such as SalesForce.com, Box.com, Dropbox, eTrade, SAP, etc.; electronic trading platforms and comparison-shopping networks such as eBay, Amazon.com, Priceline.com, e-Insurance; Media streaming services such as YouTube, Amazon Prime, Netflix, Hulu, Comcast Xfinity; and used to host social media such as Facebook, Twitter, and Snapchat.

In large enterprises, the IT department may choose to operate separate networks for the parent company and its subsidiaries. However, for many privately hosted businesses, infrastructure cost is considered a major factor in network design. Instead of supporting two entirely different hardware-based systems, SDNP systems provide companies with the ability to deploy their networks using a combination of separate and shared server resources. As shown in FIG. 113, two legal entities, eg, a parent company and its subsidiary, co-host a server network that includes both separate and shared servers. In particular, servers 1903, 1904B, 1904C, and 1904D host zone Z7 communication nodes M _7,0 , M _7,4 , M _7,7 , and M _7,8 , respectively, for parent companies, while servers ( 1901A, 1901B, 1901C, and 1903) host the corresponding zone (Z0) communication nodes M _0,0 , M _0,4 , M _0,7 , and M _0,8 for the company's regional subsidiaries. As shown, for example, server 1903 hosts two _SDNP communication nodes _, Node M _7,0 for the parent company and Node M 0,8 for the subsidiary. Due to their separate security credentials, although server 1903 and another server (not shown) are shared by both entities, data is not shared directly between the parent SDNP cloud and subsidiary SDNP cloud. Typically an employee is restricted to accessing only that employee's cloud, but in the case of a company administrator, access to both clouds may be required. Appropriate authenticated users as illustrated by the SDNP Communicator app (UI/UX 1920) includes separate dialog sandboxes 1921C and 1921D for the various entities. In this way, one cell phone or tablet can access multiple SDNP clouds of different entities without the risk of combining data, such as when a user carries multiple phones.

The SDNP App's multi-profile feature, which uses last mile hypersecure security credentials to enable or disable access to multiple SDNP clouds, supports an unlimited number of account profiles from a single SDNP App. In FIG. 114 , for example, SDNP client C _1,1 spans zone (Z99) global SDNP telcos including servers 1909A through 1909E hosting SDNP nodes M _99,1 through M _99,5 , respectively: It can make international calls without long-distance cost, and includes servers (1905A, 1905B, and 1905C) hosting other clouds, e.g., SDNP nodes M _9,0 , M _9,4 , and M _9,8 . Access to the zone Z9 company cloud can be obtained, and also through servers 1901A, 1901B, and 1901C hosting SDNP nodes M _0,0 , M _0,4 , and M _0,8 , respectively, of the zone Z0 cloud. You can call subscribers. Access privileges for any given cloud are enforced through last mile communication to the SDNP gateway, and are managed by the SDNP signaling server and SDNP name server in the system used to manage authenticated users.

SDNP communications are equally applicable in high security and restricted access networks required for government and security purposes. For example, in the United States, secure restricted communications, along with congressional and judicial server networks, are provided to a variety of organizations including local and state law enforcement, the FBI, the National Guard, the National Security Agency, the United States Army (separately or collectively), and the United States Department of State. required by the department. Similarly, other countries host separate networks for various government agencies.

To support access to specific clouds on a "need to know" basis, a nested subnet architecture can be implemented using SDNP communication methods and techniques. For example, in FIG. 115 , the nested SDNP cloud architecture has leased computer servers 1907A through 1907D hosting SDNP communication nodes M _0,0 , M _0,4 , M _0,5 , and M _0,9 , respectively. ), including a secure cloud. Communications within this external network "shell" include zone Z0 security credentials and are displayed within "secret" level dialog sandbox 1912E as displayed on SDNP Communicator 1920. The nested cloud also includes government-hosted servers (1906A, 1906B and 1906C) of enhanced security with zone Z8 security credentials that include corresponding SDNP server nodes M _8,0 , M _8,2 , and M _8,4 . contains the inner core. In order for clients C _1,1 to gain access to zone Z8 core, they must have a “top secret” security level and must communicate through the enhanced communications sandbox 1921F. One exemplary governmental application of this technology is at the US Department of State, where top secret communications within Zone Z8 are restricted to access by Ambassadors and Secretary of State, while other US embassy personnel across the world have Zone Z0 security credentials. limited to hyper-secure "secret" communications using

Claims (26)

In the SDNP last mile communication network,
Two or more devices each hosting SDNP software including an SDNP client, SDNP firmware or SDNP bridge, and each hosting SDNP software capable of digital packet communication containing datagrams constructed according to the SDNP protocol, wherein the SDNP software and the SDNP protocol comprise one or more two or more devices comprising applying an obscuration method to the datagram, wherein the at least one obscuration method comprises at least one of dynamic scrambling, encryption, junk data append, packet splitting and mixing, meshed packet forwarding, and packet routing. ; and
one or more datagrams in transit in the communication network, each containing state-based security credentials allowing dynamic application of one or more of the datagrams, routing information, SDNP payload, and the concealment methods to junk data, wherein The SDNP payload includes one or more of identification, routing, state, and security credentials along with data representing voice, image, video, database, presentation, document, spreadsheet, financial information, game, software, or other digital information. one or more datagrams;
Including,
SDNP last mile communications network, wherein only a device hosting SDNP software is capable of decoding and interpreting the contents of the datagram or executing instructions contained within the datagram. According to claim 1,
further contains one or more IP datagrams;
wherein each of the one or more IP datagrams includes, along with a SDNP payload, TCP/IP-based source and destination addresses for packet routing. According to claim 2,
wherein the TCP/IP based source and destination addresses are generated by Dynamic Host Configuration Protocol (DHCP) or issued by Network Address Translator (NAT). According to claim 1,
wherein each of the datagrams includes SDNP-based source and destination addresses. According to claim 4,
wherein the SDNP based source and destination addresses are generated by SDNP software. According to claim 5,
A gateway node in the SDNP cloud, an outgoing datagram leaving the gateway node, and a received datagram previously entering the gateway node, wherein the destination address of the outgoing datagram is in the SDNP payload of the received datagram. SDNP last mile communication network, identical to the embedded address. According to claim 1,
further contains IP datagrams,
wherein the SDNP payload of the IP datagram includes TCP/IP-based source and destination addresses for packet routing. According to claim 7,
further comprising a gateway node within the SDNP cloud;
An SDNP last mile communication network, wherein an SDNP client connects to the gateway node via Ethernet or a WiFi router that is not active as an SDNP node. According to claim 7,
A first SDNP client and a second SDNP client, wherein the first SDNP client is connected to the second SDNP client through an Ethernet or WiFi router, some of the Ethernet or WiFi routers are activated as SDNP nodes and the Ethernet Or some of the WiFi routers are not active as SDNP nodes, SDNP last mile communication networks. According to claim 7,
Further comprising a gateway node in the SDNP cloud, wherein an SDNP client is connected to the gateway node via a mobile wireless communication network, the mobile wireless communication network comprising a first group of devices activated as SDNP nodes, and a first group of devices that are not activated as SDNP nodes. SDNP last mile communication network, comprising a second device group. According to claim 7,
A first group of devices comprising a first SDNP client and a second SDNP client, wherein the first SDNP client is connected to the second SDNP client through a mobile wireless communication network, and the mobile wireless communication network is activated as an SDNP node. and a second device group that is not active as a SDNP node. According to claim 1,
further comprising a gateway node in the SDNP cloud, wherein an SDNP client is connected to the gateway node via a cable distribution network and a cable modem, wherein the cable distribution network and cable modem are activated as SDNP nodes; a first device group; and an SDNP node. SDNP last mile communication network, comprising a second device group that is not activated as . According to claim 1,
A first SDNP client and a second SDNP client, wherein the first SDNP client is connected to the second SDNP client through a cable distribution network and a cable modem, and wherein the cable distribution network and the cable modem are activated as SDNP nodes. An SDNP last mile communication network comprising a first device group and a second device group that is not active as an SDNP node. According to claim 1,
Further comprising a router and a gateway node in the SDNP cloud, wherein the router includes a first device group activated as an SDNP client and a second device group not activated as an SDNP client and the gateway via a wired or wireless connection including WiFi or Ethernet. The SDNP last mile communication network, which connects nodes. According to claim 14,
The second group of devices includes one or more of a personal computer, a home phone system, a notebook computer, a tablet, a WiFi-based mobile phone, and one or more Internet of Things (IoT) devices, wherein the one or more IoT devices include a wireless speaker. , printer-scanners, shared data-drives (repositories), security systems, cameras, lighting fixtures, motorized blinds, central HVAC thermostats, appliances, indoor HVAC, and garage doors. According to claim 1,
wherein the communication network comprises a bridge network, and wherein the two or more devices are included within the bridge network. According to claim 16,
wherein data packets transmitted between the devices of the bridge network include SDNP-based source and destination addresses. According to claim 16,
wherein the bridge network includes a SDNP bridge router, wherein the SDNP bridge router is also capable of functioning as a WiFi or Ethernet router using TCP/IP-based datagrams. According to claim 18,
wherein the SDNP bridge router is capable of accessing the contents of SDNP datagrams and converting commands, addresses and other packet contents made according to the TCP/IP protocol to the SDNP protocol and vice versa. According to claim 16,
The bridge network includes a physical medium, wherein the physical medium is wired communication including wire, cable and optical fiber modulated according to a communication standard including TCP/IP, Ethernet or DOCSIS III, or WiFi, 2.5G, 3G , SDNP last mile communications network, including wireless communications using modulated optical or radio waves according to communications standards including 4G, 5G, microwave communications, satellite communications, WiMax, or long range WiFi protocols. According to claim 16,
The bridge network is used for a variety of communications, including fixed-position ground communications, communications with trains, ships, aircraft, or other mobile vehicles, communications between terrestrial networks and satellite or mobile telephone communications networks, and terrestrial base station and mobile communications. SDNP last mile communications network, including vehicle-to-vehicle communications. According to claim 16,
wherein the communication content of the bridge network is divided into two or more datagrams, each of which is carried by different physical media, different carrier frequencies, different microwave bands, or different modulation schemes. According to claim 16,
wherein the bridge network comprises a high-bandwidth communication trunk between SDNP-based servers or SDNP gateways. According to claim 1,
SDNP last mile communication network comprising a peer-to-peer network, wherein the devices establish a direct communication link when one device detects the presence of another device. According to claim 24,
wherein within the peer-to-peer network, a vehicle can communicate with a cellular tower via intermediate vehicles when the vehicle cannot directly reach the cellular tower. According to claim 24,
wherein the contents of SDNP datagrams communicated between SDNP clients within the peer-to-peer network cannot be monitored, decrypted, or interpreted by any device that is not active as an SDNP client.

Images