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

Abstract

Various techniques are disclosed for concealing the content of communications between a client device, such as a mobile phone or laptop, and a network or cloud of media nodes. Among such techniques, route data packets in a communication to different gateway nodes in the cloud, transmit the packets over different physical media such as Ethernet cables or WiFi channels, and conceal the packets by providing different source addresses. Additionally, techniques for silencing specific participants within a conference call and a highly secure method for storing data files are disclosed.

Description

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

Cross-reference to related applications

This application claims priority to U.S. Provisional Application No. 62/480,696, filed April 3, 2017, and again claims priority to U.S. Provisional Application No. 62/107,650, filed January 26, 2015. This is a part-continuing application of U.S. application Ser. No. 14/803,869, entitled “Secure Dynamic Communication Network And Protocol,” filed on the same date.

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

Technology field

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

Improved means of communication have fueled the progress of civilization from humanity's earliest inception. From the use of couriers and messengers traveling on foot or horseback, through the delivery of mail by trains, trucks, and airplanes, through the telegraph and telegraph, telephones, radios, televisions, computers, cell phones, the Internet, email, and the World Wide Web. Until the advent, 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 communication in the Internet of Everything has always played a leading role in the development of the latest technologies of the times. With each new communication technology used, the number of people connected and the rate at which information is transmitted also increases.

The impact of this trend is that people are more connected than ever before in history, and people trust communication technologies to safely and reliably convey private, personal, family, and financial information only to those they intend to contact. It depends. Knowledge and information can now be distributed to millions of people in seconds, and friends and family can connect with each other across the world as routinely as pressing a button. It is often said that “the world has become a very small place.”

Although these advances are extremely beneficial to everyone, there are also negative consequences of our increased dependence on technology. When communication systems fail to perform, for example during an earthquake or severe weather, it is not surprising that people become confused or upset by being "unplugged," even if only temporarily. Therefore, 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 a communications network is its ability to guarantee privacy, safety, and security to the clients using it. As communications technology has evolved, so has the sophistication of criminals and "hackers" who intend to cause mischief, disrupt systems, steal money, or accidentally or maliciously cause harm to others. Credit card fraud, stolen passwords, identity theft, and unauthorized disclosure of confidential information, personal photos, files, emails, text messages, and personal tweets (embarrassing or intimidating theft) are just a few examples of modern cyber-crimes. It's just that.

To shed light on the prevalence of security issues in today's open communications networks, notable examples of privacy violations and cybercrimes at the time of this patent application are listed below (listed in chronological order):

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

* “Hacker created smart fridge and TV sent malicious email”. BGR (www.bgr.com), January 20, 2014

* “Nest Google Privacy Row Resumes with Hacked Thermostat,” Slash Gear (www.slashgear.com), January 24, 2014.

* "Account theft calls Question Line to protect Line's data. Line, a free calling and messaging application, has recently been hit with a data security breach. "We saw hundreds of user accounts that were illegally accessed by". Nikkei Asian Review, July 2, 2014

* “Ordinary Americans reported claims captured in NSA Data Sweep”. AP, July 6, 2014

* “Smart LED light bulbs leak WiFi passwords.” BBC News, 8 July 2014

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

* “Study shows ‘Internet of Things’ highly susceptible to hacking.” International Business Times (www.ibtimes.com), August 4, 2014

* “Russian hackers amass 1 billion Internet passwords”. New York Times August 5, 2014

* “New Leaker stands for U.S. Secrets, Government Concludes,” CNN, August 6, 2014

* “15 Second Hacker Roots Google’s Nest Thermostat,” The Enquirer (www,theinquirer.net), August 11, 2014.

* “Dairy Queen hacked by the same malware hitting its targets,” Christian Science Monitor, August 29, 2014

* “Celebrity Victim of Nude Photo Leak – Security Vulnerabilities in iCloud Accounts,” CBS News, September 1, 2014

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

* “Mysterious fake cell phone towers are intercepting calls across America.” Business Insider, September 3, 2014.

* “Hacking attacks from banking to retail, a sign of cyber warfare?” Yahoo Finance, September 3, 2014

* “Home Depot confirms payment systems were hacked at U.S. and Canadian stores”. Fox News, September 9, 2014

* “Yahoo is feuding with U.S. government over surveillance,” CBS/AP, September 11, 2014

* “Your medical records are more valuable to hackers than your credit cards.” Reuters, September 24, 2014

* "Red Alert: HTTP S has been hacked. Leveraging browsers for SSL/TLS (BEAST) attacks may be among the worst hacks, as they compromise the browser connections hundreds of millions of people rely on every day." InfoWorld, September 26, 2014

* “Sony cyberattack, first headache, quickly goes down in flames”. New York Times, December 30, 2014

As cybercrime, security breaches, identity theft, and privacy violations appear to be on the rise, the question arises: "How are all these cyber-attacks possible, and what can be done to stop them?" While society seeks greater privacy and security, consumers also want better connectivity, cheaper, higher-quality communications, and greater convenience when conducting financial transactions.

To understand the performance limitations and vulnerabilities of modern communications networks, data storage, 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 most important to understand how to store , , and save .

Circuit-switched telephone network operation

Electronic communications involves a variety of hardware components or devices connected within a network of wires, radio, microwave, or fiber optic links. Information is transferred from one device to another by transmitting electrical or electromagnetic energy through this network and by using various methods to embed or encode information “content” within the data stream. In theory, the laws of physics set the maximum data rate of these networks at the speed of light, but in most cases, data encoding, routing and traffic control, signal-to-noise quality, and electrical, magnetic and optical noise, unnecessary parasitics, A practical limitation to overcome is that it impedes or inhibits the flow of information, limiting the functioning of the communication network to a fraction of its ideal performance.

Historically, electronic data communications were first achieved using dedicated "hardwired" electrical connections that formed a communication "circuit" between or between two or more electrically connected devices. In the case of telegraphy, to manually make and break direct current (DC) electrical circuits, mechanical switches were used, which magnetized a solenoid and in turn moved a metal lever, causing the listening device or "relay" to follow the same pattern in which the caller pressed the switch. Make sure it is clicked at the same location. The sender then used an agreed upon language, Morse code, to encode the information into a pulse stream. The listener also needs to understand Morse code, a series of long and short pulses called dots and dashes, to interpret the message.

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 electrical connections. A telephone network consists of two magnetic transducers connected by an electrical circuit, each magnetic transducer consisting of a movable diaphragm and a coil or "voice coil" surrounded by a fixed permanent magnet enclosure. When the transducer speaks, changes in air pressure from the sound cause the voice coil to move back and forth within the surrounding magnetic field, which induces an AC current in the coil. On the listener's side, the time-varying current flowing in the voice coil induces an equal waveform and time-varying magnetic field opposing the waveform and surrounding magnetic field, moving the voice coil back and forth in the same way as the transducer that captures the sound. The resulting movement reproduces sound in a similar way 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. Additionally, since the conducted electrical signals are similar to audio waveforms carried in the air as elemental pressure waves, i.e. sound, these electrical signals are today referred to as analog signals or analog waveforms.

As mentioned above, because the transducer is used for both speaking and listening, both parties to the conversation must know when to speak and when to listen. In this system, similar to two tin cans connected by a string, the caller cannot speak and listen at the same time. This one-way operation, called "half-duplex" mode, may sound archaic, but it is used in modern walkie-talkies and under the name "push-to-talk" or PTT. It is still actually used for wireless communications in modern telephone technology.

Later, full-duplex (i.e., two-way or send-and-receive) calls with separate microphones and speakers became commonplace, allowing the parties to speak and listen at the same time. But even in modern times, feedback, a condition in which the receiver's sound is picked up by that microphone and fed back to the sender and back to the sender, resulting in confusing echoes and sometimes uncomfortable whistling sounds - a problem that especially plagues long-distance telephone communications - is avoided. To achieve this, caution is also required in operating full-duplex telephony.

Early telegraph and telephone systems suffered from one of the other problems: privacy. In these early incarnations of communication networks, everyone connected to the network heard everything communicated on the lines, even if they did not want to. In rural telephone networks, these shared lines were known as "party lines." After that, telephone systems rapidly evolved into multi-line networks where dedicated lines connected branch offices directly to individual clients' phones. Within the branch switching office, system operators manually connected callers to each other across the switchboard using jumper cables, and also had the ability to connect one branch to another to form the first "long distance" telephone call service. . Large banks of relays forming networks of telephone "switches" gradually replaced human operators, who in turn were replaced by electronic switches containing vacuum tubes.

After Bell Laboratories developed the transistor in the late 1950s, telephone switches and point switches replaced the fragile, hot vacuum tubes with cold, solid-state devices containing transistors and, ultimately, integrated circuits. As networks grew, phone numbers expanded from a seven-character prefix and private number to include an area code and eventually 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 remained constant, with calls exhibiting a direct electrical connection, or "circuit," between a caller with a voice carried by an analog signal and the routing of the call determined by a telephone switch. did. These telephone systems eventually became known as "circuit-switched telephone networks," or colloquially as the Plain Old Telephone System, or POTS. Circuit-switched telephony technology reached its peak in the 1980s, and has since been inexorably 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 one-way, transmitted from a radio station on a designated government-licensed frequency, and received by any of many radio receivers tuned to the designated broadcast frequency or radio station. Broadcast signals carried analog signals using amplitude modulation (AM) or later licensed frequency modulation (FM) methods, respectively, on dedicated portions of the radio spectrum. In the United States, the Federal Communications Commission, or FCC, has evolved to manage the allocation and regulation of these licensed bands. The broadcast concept was expanded to public television programming using wireless transmission, initially with black-and-white content and later with color. Later, television signals could also be carried to people's homes by microwave satellite dishes or via coaxial cable. Because any listener tuned to a given broadcast frequency can receive the broadcast, the term "multicast" is now used for this one-way multi-listener communication.

Simultaneously with the advent of radio broadcasting, the first two-way communications began aboard commercial and military maritime vessels, and also during World War II, radio was known as a walkie-talkie hand-held radio transceiver, a device that combined a transmitter and receiver into a single unit. It has developed. Like telephone technology, early two-way radio transmissions operated in a "simplex" mode, allowing only one radio to broadcast on a single radio channel while others only listened. By combining transmitters and receivers at different frequencies, simultaneous transmission and reception was possible 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 amplifies and repeats the signal and transmits it to the entire radio network. . The number of available frequencies carrying information for a broadcast area sets the total bandwidth of the system and the number of users who can communicate independently on the radio network at one time.

To expand the overall capacity of radio networks to handle large numbers of callers, the concept of cellular networks with large areas divided into smaller segments, or radio "cells," was demonstrated in the 1970s and became widespread within the next decade. The cellular concept was to limit the broadcasting range of radio towers to smaller areas, i.e. shorter distances, and thus to be able to reuse the same frequency band and simultaneously handle different senders present in different cells. To do so, software was created to manage the handoff of a caller passing from one cell to an adjacent cell without "dropping" and without suddenly disconnecting the call. Like radio and television broadcasting, POTS, and two-way radio, early cellular networks were analog in nature. To control call routing, a telephone number system has been adopted to determine the appropriate wireless electrical connection. This choice also had the advantage of seamlessly connecting the new wireless cellular network to the "wired" regular old telephone system, providing interconnection and interaction through both systems.

Beginning in the 1980s, telephony and radio communications, along with radio and television broadcasting, were developed to reduce power consumption and increase battery life, improve quality with better signal-to-noise ratios, and carry data and text along with voice. Beginning the inexorable transition from analog to digital communication methods and formats, driven by the need to begin addressing the need. Radio formats such as EDACS and TETRA have emerged that can use one-to-one, one-to-many, and many-to-many communication modes simultaneously. . Additionally, cellular communications quickly transitioned to digital formats such as GPRS, as did TV broadcasting.

By the 2010s, most countries had either discontinued or were in the process of discontinuing all analog TV broadcasting. Unlike broadcast television, cable TV carriers were not required to convert to a digital format, and maintained a hybrid composite of analog and digital signals until 2013. The ultimate move to digital will not be driven by government standards, but rather by expanding the network's allowable number of channels, being able to carry HD and UHD content, and allowing more pay-per-view (PPV) (also known as "unicast") was proposed and motivated by commercial reasons to enable high-speed digital connectivity services to its clients.

While it is common to equate the transition 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 also marked the beginning of the commercial acceptance of IP in telephony technology. It preceded, but did not facilitate, the universal move to IP and “packet-switched networks” (described in the next section).

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

Additionally, the PSTN is connected to a 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 standardized cellular radio frequencies in cellular links. In the case of 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 hand held radios and large in-dash and desktop radios via high-power radio towers and cellular links. Commonly used by police vehicles, ambulances, paramedics, fire departments, and even port authorities, these two-way radio networks, also referred to as professional communications networks and services, are aimed at governments, municipalities, and emergency responders rather than consumers. (Note: As used herein, the terms “desktop,” “tablet,” and “laptop” 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) phone numbers to establish a wireless link between the tower and the mobile device it serves. Uses RF radio channels. Professional wireless communications services thus exist as distinct, and uniquely different from consumer cellular telephone networks.

Therefore, the PSTN network flexibly interconnects subnetworks of various technologies. There are many variations that shape the interoperability between sub-networks, which is an inherent weakness of today's circuit-switched networks. Because the various sub-networks do not communicate with any common control protocols or languages, and because each technology handles the transmission of data and voice differently, calls cannot be made over the PSTN backbone or trunk lines. Aside from their limited capabilities, the various systems are fundamentally incompatible. For example, during the September 11 terrorist attacks on the World Trade Center in New York City, people from all over the United States converged on Manhattan just to learn the radio communication systems and walkie-talkies to help fight the disaster. Many of the state's emergency workers were incompatible with volunteers from other states and cities, making it impossible to administer central command and control over the relief effort. Because there was no standardization in the radios' communication protocols, the radios could not simply connect to each other.

Moreover, direct electrical and RF connections, especially in circuit-switched telephone networks using analog or non-secure digital protocols, could allow a hacker equipped with an RF scanner to locate active communication channels and sniff, sample, listen, and Or, blocking it is simple. Because the PSTN forms a “persistently connected” link or circuit between communicating parties, it may be used to conduct cyber surveillance, either lawfully by the government operating under federal court-ordered wiretapping, or illegal, prohibited, or unauthorized surveillance. Criminally or legally by the government, there is ample time for a hacker to identify and "wiretap" the connection. The definitions of legal and illegal espionage and surveillance, and the obligations of network operators to comply with cooperation, vary greatly from country to country, and the debate is heating up among global companies such as Google, Yahoo and Apple that operate across international borders. Although telecommunications networks and the Internet are global and have no borders or borders, the laws governing this electronic information are limited to the jurisdiction of the governments that control domestic and international communications and commerce at the time.

Electronic eavesdropping, regardless of its legality or ethics, ranges from the monitoring of ubiquitous security cameras on street corners and above every road or subway today to the sophisticated hacking and code cracking carried out by various countries' national security services and agencies. and surveillance are routine. All networks are vulnerable, but the PSTN's outdated and weak security regulations make them particularly easy to hack. Therefore, even a PSTN connected to a modern secure modem network represents a weakness in the overall system, creating a vulnerability to 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 privacy violations.

Packet-switched communications network operation

If two tin cans connected by a string represent a metaphor for the operation of a modern circuit-switched telephone, then 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 transmitted over a network. The delivery mechanism is based on electronic addresses that uniquely identify where the data packet is going and where it came from. Additionally, formats and communication protocols are designed to contain information according to the nature of the data contained in packets, including the content specified by the program or application for which it will be used, and the physical link carrying the packet and the hardware facilitating the electrical or radio connection. .

Born in the 1960s, the concept of packet-switched networks was created during the Sputnik Cold War editorial era. At that time, the US Department of Defense (DoD) feared that a space-based nuclear missile launch could destroy America's entire communications infrastructure, loosing its ability to respond to a USSR preemptive attack, and that its vulnerability to such an attack was actually one of the few. expressed concern that it could provoke. Accordingly, the DoD sponsored the development of redundant communications systems, or grid-like "networks," in which the network's ability to convey information between military installations could not be disrupted by destroying designated data links or even numerous links within the network. . This system, known as ARPANET, became the parent of the Internet and the famous forerunner of modern digital communications.

Despite the creation of packet-switched networks, the explosive growth of the Internet resulted in the first easy-to-use web browser, Mosaic, the emergence of hypertext-defined web pages, the rapid adoption of the World Wide Web, and the widespread use of email. This did not occur until the 1990s, when there was widespread global adoption of Internet platforms. Because no country or government can stop it (or even fully recognize its global connections), and because its user base includes consumers using the newly acquired personal computers, the basic view is; Either the lack of central control, or the need for a central mainframe, partly drove the Internet toward ubiquity.

Another significant impact of the growth of the Internet was the standardization of the Internet Protocol (IP), used to route data packets through networks. By the mid-1990s, Internet users realized 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 connection to freely communicate by voice over the Internet, but propagation delays, or latency, across the network made voice quality poor and often inconvenient. While latency has improved with the adoption of high-speed Ethernet links, high-speed WiFi connectivity, and 4G data to improve connection quality at the “last mile,” the Internet itself was created to ensure accurate delivery of data packets, and There are no guarantees about the time required for delivery, meaning the Internet was not created to operate as a real-time network.

Therefore, the dream of using the Internet to replace expensive long-distance telecommunications carriers or “telcos” has been overcome by “over-the-counter” services such as Skype, Line, Kakao Talk, Viper, etc. Despite the usefulness of “over-the-top” (OTT) providers, they fall far short. OTT telephony technology suffers from poor quality of service (QoS) resulting from uncontrolled network latency, poor voice quality, dropped calls, echo, reverberation, feedback, choppy sound, and sometimes inability to initiate calls. The poor performance of OTT communications is not inherently a weakness of VoIP-based protocols, but rather a weakness of the network itself, where OTT carriers have no control over the path data takes or the delays communications encounter. Essentially, OTT carriers cannot guarantee performance or QoS because OTT communications act as Internet hitchhikers. Paradoxically, the companies best able to leverage VoIP-based communications today are long-distance carriers with dedicated, low-latency hardware-based networks, and it is telcos that have the least incentive to do so.

Aside from its inherent network redundancy, one of the greatest strengths of packet-switched communications is that data is placed in packets consistent with the Internet Protocol and can be transmitted from any source as long as the communicating device is connected and linked to the Internet. It is the ability to transport information to any destination. The Internet Protocol manages the ability of a network to deliver payloads to their destination without concern or concern about what information is being carried or what applications will use it, eliminating the arbitrary 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.

Because versatile file formats avoid dependence on proprietary or company-specified software, the Internet is an "open" platform that can communicate with the widest range of devices ever connected, ranging from "computers" to cell phones, from cars to home appliances. It can be considered a “source” communication platform. The most recent phrase to describe this universal 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 optical fibers, among countless other servers (not shown) to form an Internet cloud. do. The cloud metaphor is appropriate because there are no well-defined boundaries defining which servers are considered part of the cloud and which are not. On a day-to-day and even minute-to-minute basis, servers are online while they can be taken offline for maintenance without affecting the functionality or performance of the Internet. This is the advantage of a truly redundant distributed system; there is no single point of control and therefore no single point of failure.

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

For short-range communication, the WiFi access point connects to a smartphone, tablet, laptop, desktop or connected device and can also be used for local wireless applications in homes, cafes, restaurants, and offices. WiFi involves communications operating according to IEEE defined standards for the single carrier frequency specifications 802.11a, 802.11b, 802.11g, 802.11n and most recently the dual frequency band 802.11ac format. WiFi security, based on simple static login keys, is primarily used to prevent unauthorized access to the connection, but is not intended to indefinitely protect data from sniffing or hacking.

Wired distribution units i.e. routers are floating to laptops, desktops, phones, and televisions by optical fiber, coaxial cable, or Ethernet, or to hotels, factories, offices, service centers, banks, and homes by twisted copper wire pair telephone lines. It can be connected to a point on a sales terminal operating 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 a twisted pair of copper wires. may include. In remote areas where fiber optics or cables are not available, digital subscriber line (DSL) connections are still used, but with significant compromises in data rates and connection reliability. Counting access via wireless, WiFi, and wired connections, the number of Internet-connected entities is expected to reach 20 billion worldwide by 2020.

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

In IP packet routing from a laptop to a desktop using packet-switched network communications, for example, a first data packet sent from a laptop to a local WiFi router via a wireless connection is directed toward an array of DNS servers, where the DNS is a domain name server. is an abbreviation 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 a 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 clearly identify the communication device, are used in the routing of data packets through the network.

After that, the laptop starts assembling the IP data packets and transmitting them sequentially to their destination, for example, first via a WiFi radio to a local WiFi router, and then to a network of routers and servers that act as intermediate routers. Send to the destination via work. Routers and computer servers together operate on a network as nodes on the Internet, or presence points, or POPs, gateways of limited connectivity that provide access to the Internet. Some routers or servers that operate as POPs connect to the Internet through a small number of adjacent devices, while other servers interconnect to large numbers of devices and are also sometimes referred to as "super POPs." For 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 in email applications.

Each router or server acting as a router contains in its memory file a routing table that identifies addressable IP addresses and possibly addresses that the router above it can address. These routing tables are automatically downloaded and installed on every router when it is first connected to the Internet, and they are typically 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 from New York to Tokyo 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 for each inter-router connection, vary by infrastructure and by network traffic and loading, there is no way to determine a priori which path is fastest or best.

Unlike circuit-switched telephony, which establishes and maintains direct connections between clients with packet-switched data, it monitors the Internet to route packets, determining which path is optimal, appropriate, or faster. There is no universal intelligence to determine the best path to route packets while doing so, and there is no guarantee that two consecutive packets will even take the same path. Thus, a packet "finds" its way through the Internet based on the priorities of the company operating the routers and servers it traverses. Each router essentially contains some routing tables and routing algorithms that define its preferred paths depending on network conditions. For example, a router's preferences may be to prioritize sending packets to other routers owned by the same company, equalizing traffic between connections with neighboring routers, finding the shortest delay to the next router, minimizing Create fast lanes for VIP clients by directing them to strategic business partners or by skipping intermediate routers whenever possible. When a packet enters a router, there is no way to know whether the routing choices made by a given POP are 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. As with the previous New York to Tokyo routing example, the routing and resulting QoS can vary substantially based on small perturbations in the path, the so-called "butterfly effect" in non-linear equations. Consider a case where a packet from New York passes through "Router A" in Chicago. Since there is temporarily high traffic in California, it is forwarded to Mexico City rather than California. The Mexico City router then forwards the IP packet back to Singapore, from where it is finally transmitted to Tokyo. The very next packet sent is routed through Chicago "Router B", which, due to low traffic at that point, directs the packet to San Francisco and then directly to Tokyo in just two hops. In this case, the second packet may arrive in Tokyo before the first packet is routed over a longer and more circumferential path. This example highlights the problem of using the Internet for real-time communications such as live video streaming or VoIP: the Internet is not designed to guarantee delivery times or control network delays when performing delivery. Latency can vary from 50 ms to over 1 second depending on whether the packet is routed through only two servers or 15.

The Internet's lack of routing control is problematic for real-time applications and also poses a problem of poor QoS, especially for carriers trying to provide Internet-based telephony by trapping free riders 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 steal data without being detected. If a pirate intercepts packets and identifies the source or destination IP address, they can intercept data from intervening routers and sniff or redirect traffic through their own pirate network, spying on conversations or even decrypting encrypted files. Various methods can be used.

The source and destination IP addresses and other sensitive information used to route packets (and may be used by pirates to intercept packets) are strings of digital data called IP packets, IP datagrams, or TCP/IP packets. It is designated as The IP packet contains digital information that defines the physical connection between devices, how the data is organized to link the devices together, the network routing of the packet, whether useful data (payload) is delivered accurately, and what type of data is included in the payload. and means to ensure that the payload data itself is subsequently used by various applications.

IP packets are a series of strings of digital bits that are sent and received sequentially and organized in a designated manner called the Internet Protocol established by various standards committees, including the Internet Engineering Task Force, among others. This standard ensures that any IP packet following a defined protocol can be communicated and understood by any connected device that complies with the same IP standard. Ensuring communication and interactivity for Internet-connected devices and applications is a hallmark of the Internet, and to prevent any company, government, or individual from controlling the Internet or limiting its accessibility or functionality, the Open Source Initiative ( It represents the guiding principles of the Open Source Initiative (OSI) or OSI.

The OSI model, an abstract concept containing seven layers of functionality, specifies exactly 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 as follows:

* Layer 1, the physical layer or PHY layer, contains hardware-specific information that represents the physical characteristics of the communication as electrical, RF, and optical signals, and how these signals can be converted to bits for use in the communication system. Converting a WiFi radio, Ethernet, serial port, optical fiber, 3G or 4G cellular radio, DSL on twisted pair copper wire, USB, Bluetooth, cable or satellite TV, or a digital broadcast of audio, video, or multimedia content into a bit stream. This is the operation of the PHY layer. The preamble in an IP packet 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 bit stream transmitted from PHY layer 1 is 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 wireless communications can be modulated using HSDPA or HSUPA, which are high-speed packet access methods; Electrical signals on optical or coaxial cables modulated in 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 leading "data link header" and a following "data link trailer", which ensures that the encapsulated payload is not lost in the transmission process. Start and stop as if One key element of Layer 2 data is a MAC or media access address that is used to direct data traffic to or from a designated Ethernet address, RF link, or hardware-specified transceiver link.

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

* Layer 4 , the transport layer, contains segments of data that define the characteristics of the connection between communicating devices, where UDP provides a minimal description of the payload for connectionless communication, i.e. how large the payload is, and what random bits are lost. It defines which application services (ports) use the delivered data. The UDP is considered non-connective because it does not confirm delivery of the payload and relies on checking for errors or lost data on the application. The UDP is typically used in time-sensitive communications such as broadcasting, multicasting, and streaming, where retransmitting packets is not an option. In contrast, TCP guarantees a virtual connection by checking packets, ensuring that the payload is delivered reliably before the next packet is sent, and retransmitting missing packets. Additionally, TCP uses checksums to check the data integrity of transmitted packets, and also includes a function to reassemble out-of-order packets into their original order. Both TCP and UDP define source and destination ports, a description of a higher layer service or application, such as a web server or email server, and the information contained within the layer 4 payload. For IP packets, layer 4 contains the TCP/UDP header and also encapsulates the data/payload containing content used by higher OSI layers 5, 6, and 7.

* Layers 5, 6, 7 , upper or application layers, describe 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 suite (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 typically includes the presentation of text, graphics and pictures, sound and video, and documents such as XML or PDF, along with security features such as encryption. Use 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 the corresponding IP packets encapsulate data about each other (one inside the other, in a manner similar to a babushka or Russian nesting doll). (a wooden doll with one doll within another, and this continues). The outer packet or layer 1 PHY defines the entire IP frame containing all higher level related information. Within this PHY data, the layer 2 data frame describes the data link layer and contains layer 3 network datagrams. This datagram again describes the Internet layer, with its payload having Layer 4 segment data describing the transport layer. The transport layer delivers upper layer data as payloads containing layer 5, 6, and 7 content. 7-layer encapsulation is sometimes referred to as "everyone seems to need data processing" that lists the seven OSI layers sequentially from top to bottom as application, presentation, session, transport, network, data link, and physical layers. It is referred to by a mnemonic symbol.

While the lower physical and link layers are hardware-specific, the middle OSI layer, encapsulated within IP packets that describe network and transport information, is typically completely agnostic to the hardware used to communicate and deliver IP packets. Moreover, the upper layers, encapsulated as the payload of the transport layer, are specific to applications that apply and operate completely independently of how packets are routed or delivered over the Internet. This partitioning 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 manner, the packet-switched network can route, transport, and convey a variety of application-related information over heterogeneous communication media in a consistent manner between any Internet-connected device or entity.

In conclusion, a switched circuit network is a network where packet-switched network communications split documents, sound, video, and text into multiple packets, using multiple network paths (on a best effort basis to provide delivery on time). It passes these packets through a post office (similar to a post office), then reassembles the original content, while ensuring that nothing is lost in the process, while two or more parties communicate (similar to common implementation telephone systems a century ago). ) requires a single direct connection between the A comparison between circuit-switched PSTN and packet-switched VoIP is summarized in the table below.

network PSTN Internet technology circuit switched packet switched connection dedicated electrical connection Each packet is routed through the Internet data transfer Real time (line) Best transmission (packet) signal analog or digital Digital, IP, VoIP contents voice Voice, text, data, video data transfer rate lowness height Error checking None, or minimal wide range Impact of broken lines Dropped or short calls Call rerouting Impact of power outage The network delivers power Battery backup required

While the PSTN operates using real-time electrical line connections, packet-switched networks ultimately deliver packets and payloads, unlike the post office, which uses different trucks and postal carriers to deliver mail, even if its arrival is late. To find a way, you need to recognize that you are using a “best effort” method to deliver your content. The operation and communications of packet-switched networks are described in more detail in the background section of the related patent application entitled “Secure Dynamic Communication Network and Protocol,” of which this disclosure is a part-continuation. Considering the performance of the network, below: Several factors are taken into consideration.

* Data rate, i.e. bandwidth

* Quality of service

* Network and data security

* User privacy

Among 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, voice quality, network reliability, intermittent operation or frequent service interruptions, synchronization or connection failures, low signal strength, delayed applications, and functional network redundancy during emergency conditions. do. Cybersecurity and cyberprivacy prevent attacks on the network, prevent cybercrime, cybersurveillance, IP packet sniffing, port interrogation and denial of service attacks, profiling, fraud, packet hijacking, cyber-infection, surveillance, pirate management and intrusion. Interferes with unauthorized access to data traffic and content, including:

service quality

Quality of service describes the network's performance in capacity, bandwidth, latency, data transfer rate, scalability, sound quality, data integrity, and data bit error rate. For program, file and security related verification, data accuracy is an important factor. Which factors are important depends on the nature of the payload carried over a packet-switched network. In contrast, for voice and video, which constitute real-time applications, factors affecting packet delivery time are important. Quality factors and how they affect various applications such as video, voice, data and text vary depending 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. Congested networks operating at lower effective data throughput rates due to short-period interruptions, as exemplified by IP packet waveforms, not only severely degrade video by jerky intermittent motion, fuzzy images, and inappropriate color and brightness. Rather, it degrades speech or voice communication by distortion, echo, and even entire sentences being dropped from the dialogue or sound track. However, in congested networks, data can still be delivered using TCP by repeated requests for rebroadcasts.

At the extreme, unstable networks exhibit low data throughput with many data outages at unpredictable intervals. Additionally, unstable networks contain corrupted IP packages, as represented by dark shaded packets in waveform 610D, which must be retransmitted in TCP based transmissions or simply discarded as corrupted or inappropriate data in UDP transmissions. At this level of network degradation, even email becomes intermittent and IMAP file synchronization fails. Because of its lightweight data format, most SMS and text messages will be delivered with little delivery delay even in severe network congestion, but attachments will not be downloaded. On an unstable network, all applications may fail, causing normal operation of the computer or mobile phone to stop and wait for the expected file to be delivered. In these cases, the video freezes, the sound becomes choppy and difficult to understand, the VoIP connection drops repeatedly more than a dozen times within a few minutes, and in some cases it doesn't connect completely. Likewise, emails freeze or lag with computer icons spinning endlessly. The progress bar all hangs. Even text messages bounce and “undeliverable”.

Although several factors can cause network instability, including power failure of key servers and super POPs, overloaded calling capacity, transmission of large data files or UHD movies during a severe denial of service attack 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 permanently “times out,” or when a router or server detects a checksum error in the IP packet header. For packets using UDP, packets are lost, and the Layer 7 application must be smart enough to know what has been corrupted. If TCP is used for layer 4 transport, packets will be requested to be retransmitted, potentially adding additional loading to an already overloaded network.

QoS, another factor that determines propagation delay, can be quantitatively measured in several ways, such as the delay of an IP packet from node to node, or the round trip delay from source to destination one way, or alternatively back from source to destination. You can. The effect of propagation delay on packet delivery is different using UDP and TCP transport protocols. As integrated network propagation delay increases, the time required to conduct round-trip communications such as VoIP conversations increases. For UDP transmission, the round-trip delay increases linearly with propagation delay. Because longer propagation delays are associated with higher bit error rates, the number of lost UDP packets increases, but because UDP requires retransmission of lost packets, the round-trip time remains linear with increased delay. TCP transmissions exhibit 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, TCP propagation delay increases linearly with the integrated propagation delay. However, as communication networks become unstable as propagation delays increase, the round-trip time due to TCP transmission increases exponentially due to the protocol's need for retransmission of missed 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 one-way latency of a network is by measuring the round-trip time of a large number of similarly sized IP packets, and This is done by dividing by 2 to estimate . Latency up to 100 ms is noticeable, up to 200 ms is considered quite good, and up to 300 ms is still considered acceptable. For a propagation delay of 500 ms easily encountered by OTT applications running on the Internet, this delay is inconvenient for the user and also interferes with normal conversation. In voice communication, especially, these long propagation delays can sound "bad" and can also appear as echoes, producing a "twangy" or metallic sound, making the other party wait until the last second to get your response. They may interrupt normal conversation while waiting for a response to their last comment, possibly resulting in distorted or unintelligible speech.

For clarity's sake, the one-way latency of communication is in part because ICMP packets are generally lightweight compared to actual IP packets, in part because the ping test does not use TCP's "resend request", and in part because it does not use TCP's "resend request" for public networks on the Internet. This 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 compensation, the root of the ping test matches the actual packing root. do. Essentially, when ping experiences long delays, 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 in itself will result in lower propagation delay of the actual packets. 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 interlocutor, causing additional delays, thereby increasing effective network latency and degrading QoS at the cost of improving security.

Cyber Security and Cyber Privacy

Two other key considerations in communications are cybersecurity and cyber privacy. Although related, the above two problems 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 a computer or communications network, 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 recordings. Network-connected devices may be connected to a point of sale (Point of Sale). Publicly shared devices used by individuals, such as point of sale (POS) terminals, gas pumps, ATMs, etc., as well as mobile phones, tablets, laptops, desktops, file servers, email servers, web servers, databases, and personal data This includes storage, cloud storage, internet-connected devices, and connected cars.

Clearly, crimes are committed by cybercriminals and computer hackers who attempt to gain unauthorized access to secure information. If the illegally obtained data contains personal information, the attack is a violation of the victim's personal privacy. But conversely, privacy violations can occur without the need for cybercrime and are virtually unstoppable. In today's networked world, unauthorized use of personal 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 another client who wants to use the data for another purpose. Even Microsoft-purchased Hotmail is well-known for selling mailing lists to advertisers interested in spamming potential clients. Whether such actions should be considered a cyber privacy violation remains a matter of opinion.

“Cyber privacy,” which includes Internet privacy, computer privacy, and private communications, includes the collection, storage, display, or sharing of information with others to control that private information and the rights of an individual. Contains rights or 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 other personal information useful to identify an individual without knowing his or her name. there is. In the future, even a personal DNA map may remain as a legal record. In addition to personally identifiable information, non-personally identifiable information may include things like the brands of clothing we buy, the websites we frequent, whether we smoke, drink alcohol, or own a gun, what type of car we drive, etc. This could include things like what illnesses we might contract in our lives, what illnesses or medical histories our family members have, or even what types of people we are attracted to.

This personal information is combined with public records related to personal income, taxes, property deeds, criminal records, traffic violations and any information posted on social media sites to form a powerful data set for interested parties. 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, has a strong interest in personal information stored as big data. Automotive and consumer goods companies likewise want access to these databases to manage their market strategies and advertising budgets. In recent elections, even politicians have begun to look to big data to better understand voters' opinions and which political issues to avoid.

The issue of cyberprivacy is not whether big data today is capturing personal information (which is already standard procedure), but rather whether said data set holds your name or enough personally identifiable information to identify you even without knowing it. It is whether or not it exists. For example, the U.S. government originally said personal information collected by the healthcare.gov website used to sign up for the Affordable Care Act would be destroyed once a personal health account was set up. Then, in a recent posting, a third-party company that facilitates data collection for the U.S. government had previously signed a government contract giving it the right to retain and use the data it collected, so personal information leaked to the U.S. government was revealed. The information was not actually private, he said.

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, cases of unauthorized government surveillance are more elusive, varying dramatically from country to country. For example, the U.S. National Security Agency has repeatedly pressured Apple, Google, Microsoft and others to provide access to cloud and databases. Even government officials eavesdropped and intercepted their conversations and presentations. When asked whether Skype, a division of Microsoft, monitors caller content, Skype's chief information officer suddenly responded, "No comment."

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

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

For example, for tablets that connect to a network through a cellular radio antenna and an LTE cellular base station, or through a short-range wireless antenna and a public WiFi base station, an unauthorized intruder could monitor the wireless link. Likewise, LTE calls over cellular links may be monitored or “sniffed” by a blocking radio receiver or sniffer. The same sniffer can monitor the WiFi link and coordinate on the receiving end of the cable between the cable CMTS and the cable modem.

In some cases, LTE calls can be blocked by pirate faux towers, resulting in switched communication paths 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 POTS lines from the PSTN gateway to the phone and calls on cooperative PBX lines 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 a tablet or desktop to phish for passwords. Worms can also attack your desktop, especially if your computer runs a Microsoft operating system with ActiveX features enabled. Finally, to launch a denial of service attack, a virus can attack any number of network-connected devices, including servers, desktops, and tablets.

Accordingly, malware may operate in different parts of communications networks and infrastructure, and cyber attacks may include viruses, man-in-the-middle attacks, government surveillance, and denial of service attacks. The last mile of communications networks presents an even broader opportunity for malware and cyber attacks, split into three zones: local telco/network, last link, and devices. The local telco/network as shown includes high-speed wired or fiber optic links, routers, cable CMTS, cable/fiber, cable modems, WiFi antennas, and LTE radio networks. In these parts of the network, radio sniffers, spyware, viruses, and man-in-the-middle attacks are all possible.

For the last link, from the local connection to the device, network connections include wired connections, WiFi links, and LTE/radio cellular links that are exposed to spyware, radio sniffers, wiretaps, and counterfeit towers. Devices themselves, including for example tablets, laptops, desktops, smartphones, smart TVs, POS terminals, etc., 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, can be readily used in commercial and online markets. Although sniffing of fiber optic cloud connections was not initially identified as a threat, non-intrusive data sniffers for fiber optics have recently emerged, that is, without the need to break the fiber or even temporarily corrupt its normal operation. Data sniffers now exist.

In addition to using hacking and surveillance methods, a variety of commercial spyware can be easily 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 features comes together in many surprisingly compelling ways to violate cyber privacy, including: phone calls, photos and videos, SMS/MMS text messaging, third-party instant messaging, email, GPS location tracking, Internet usage, address books, It is surprisingly comprehensive, including monitoring of calendar events, eavesdropping, control applications, and even remote control functions. In fact, cyberattacks are now so frequent that they are tracked every day. Launching a cyberattack typically requires a combination of several steps or techniques:

* IP packet sniffing

* Port interrogation

* Profiling

* fraud

* Packet theft

* Cyber infection

* watch

* Pirate Management

IP Packet Sniffing - Using radio monitoring devices, cybercriminals can obtain sensitive information about users, their transactions, and their accounts. In packet sniffing, the contents of an IP packet can be obtained or "sniffed" anywhere in the path between two users. For example, when a user sends a file, such as a photo or text, as an IP packet from his laptop to his friend's phone, a cyber pirate can intercept the sender's last link, thereby hijacking the sender's local network. , IP packets can be found in any number of places, by intercepting the cloud, by intercepting the recipient's local telco, or by intercepting the recipient's last link. Observable data contained in intercepted IP packets includes the layer 2 MAC address of the device used in the communication, the layer 3 address of the sender at the receiving end, i.e. the destination of the packet, including the transport protocol, e.g. UDP, TCP, etc. Includes. Additionally, the IP packet also contains the Layer 4 port numbers of the sending and receiving devices, potentially defining the type of service being requested, and the data file itself. If the file is not encrypted, the data it contains can be read directly by cyber pirates.

If the payload is not encrypted, text 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 operations are required to determine the Layer 6 application format the content uses, but once identified, the content can be publicly viewed or posted. It can be used to blackmail 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 noted, monitoring of the cloud is more difficult because IP packet routing in the cloud is unpredictable, since cyber pirates must capture sensitive information in IP packets when they first appear, so that subsequent packets may be identical. This is because it cannot follow the route and sniffed packets. Intercepting data in the last mile has a greater chance of observing a series of related packets containing the same conversation, which causes the local router to follow the specified routing path until the packet reaches a POP outside the client's own carrier. This is because the table is followed normally. For example, Comcast's clients will use entirely Comcast-owned networks to traverse IP packets up the routing chain until the packets travel geographically beyond Comcast's reach and client service area.

If a sequence of packets between the same two IP addresses occurs for a long enough time, the entire conversation can be recreated piecemeal. For example, if an SMS text message is traversed over the same network in the last mile, a cyber pirate can intercept the IP address and port number, allowing multiple IP packets carrying the text to intercept conversations between the same two devices, i.e. a mobile phone and a laptop. It is possible to identify what it represents. Therefore, even if the account number and password are texted in different messages or are incompletely disseminated over many packets, the consistency of packet identifiers still allows cyber pirates to reconstruct the conversation and steal account information. Once account information is stolen, they can take over account privileges by transferring money to an overseas bank or even changing account passwords and security questions, which temporarily identify the theft.

Even though 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, cyber pirates with access to sufficient computational power can systematically try all combinations by brutal shear force until they destroy the encryption password. Once the key is destroyed, the packet and all subsequent packets can be decrypted and used by cyber pirates. The odds of cracking a login password by "password guessing" are greatly improved when packet sniffing, described below, is combined with user and account "profiling." In a "man-in-the-middle attack" communication devices are usually not involved because cyber pirates do not have direct access to them.

Port Interrogation - Another way to break into a device is to interrogate many Layer 4 ports and use their IP addresses to determine whether any requests receive a response. Once a cyber pirate identifies the IP address of a target device from packet sniffing or other means, the cyber pirate can begin a series of interrogations of ports on the device to look for insecure or open ports, service and maintenance ports, or application backdoors. there is. While a hacker's interrogation program may systematically cycle through all port #s, attacks typically target 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.

During port interrogation, cyber pirates do not want to reveal their real identity, so they will use disguised pseudo-addresses to receive messages, which cannot be traced personally. Alternatively, cybercriminals can use stolen computers and accounts, making it look like someone else is trying to hack the target device, and if tracked, sets investigators back on an innocent person instead of them.

Profiling - User and account profiling allows cyber pirates to use publicly available information to decrypt passwords, identify accounts, and determine assets about a target, its accounts, and its personal records. It is a learning process. Once a hacker has obtained the target's IP address using sniffing or another method, a traceroute utility can be used to find the device's account's DNS servers. The account holder's name can then be found by using the "Who is" function on the Internet. 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 more. In many cases, websites from universities and professional societies include home addresses, email addresses, telephone numbers, and the individual's date of birth. By examining social media sites such as Facebook, LinkedIn, Twitter and others, cybercriminals can collect information about embarrassing incidents, family secrets, and personal enemies, including the names of family members, friends, pets, as well as photo and video files. You can collect important information such as previous home addresses, classmates, important events of others, and photos.

The cyber pirate's next step is to use this profile to "guess" the user's password based on that profile, hacking the target device and other accounts of the same individual. Once cybercriminals have cracked one device's 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 a person's identity, transfer money, make them the subject of a police investigation, steal all of their property, and essentially destroy another person's life. For example, as described at the outset of the invention by gathering long lists of passwords from stolen accounts, cybercriminals can use the same passwords and login information to illegally purchase millions of dollars in premium tickets to concerts and sporting events. I used a password.

Imposters - Cyber pirates act as "imposters" when they impersonate someone or use illegally obtained cybersecurity credentials to access communications and files by pretending to be an authorized person or device. In the scammer type of cyberattack, a cybercriminal has sufficient information or access to an individual's account to take over the victim's account, send messages on their behalf, and misrepresent them as the owner of the hacked 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 sent a message to her friend that included a misrepresentation that "she needed money for an emergency loan after a car accident" and instructions on where to send the money. Not knowing that her account had been hacked, and thinking her friend's request was real, she immediately offered financial help. For the avoidance of doubt, the request sent to each friend was $1,000 or less. Fortunately, just before transferring the money, one of her friends called her to double-check her wire information and the fraud was revealed. Without the phone, no one would have ever known that the request came from a scammer, and Line account holders would never have known that a wire transfer had been sent or requested.

Another form of misrepresentation occurs when a device is given security permissions and can exchange information with a server or other networked device, or somehow a cyber pirate device disguises itself as an authorized server and thereby, connects the victim's device. , unaware that the server is a scammer, willingly hands over their files and information to the pirate server. This method has been used to trick celebrities into backing up their personal photo files to iCloud, except that Backup Cloud is a scammer.

Another form of fraud occurs when someone with physical access to a person's phone or open browser performs fraudulent activities such as sending emails, answering phone calls, or sending text messages from another person's account or device. The receiving party assumes that they are connected to a known device or account and that the person operating that device or account is the owner. The scam may be a prank, such as a friend posting an embarrassing comment on Facebook, or of a more personal nature, such as someone's spouse answering a personal phone call or intercepting a private text message of a personal nature. The consequences of unauthorized access can include jealousy, divorce, and multiple legal proceedings. If your device goes unmonitored for a while in an office or cafe - for example, when you go to the bathroom - fraudsters can quickly access your personal or company information, or allow unauthorized access, as described in the next section titled "Infection". There are other risks when sending emails, transferring files, or downloading some form of malware onto your device.

Fraudster-based cyberattacks are also important when devices are stolen. In these cases, even if the device is logged out, the thief has plenty of time to destroy the login code. The "Find My Computer" feature, which locates stolen devices on your computer and erases your computer files when a cyber pirate first logs on to the device, because we know that tech-savvy criminals only activate devices that don't currently have a cellular or WiFi connection. It doesn't work anymore. This risk is especially great for cell phones where pass line security is a simple four-digit personal ID number or PIN. Since there are only 9999 possible combinations, it's only a matter of time before your PIN is cracked.

A major challenge in keeping devices safe is preventing access to fraudsters. Preventing fraudsters requires robust means of authenticating users' identities at regular intervals and ensuring they have access to only the information and permissions they need. Device security is often the weakest link in the chain. Once a device's security has been compromised, it's 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 cyberattack from a cyberpirate, the IP packets passing through the router may be rewritten into modified IP packets, and redirect the IP packets to different destination addresses and ports on the cyberpirate device. It can be converted to #. The cyber pirate device can then obtain all the information it needs from the payload of the IP packet and change the content of the payload of the IP packet. Deceptive payloads can be used to commit any number of fraudulent offenses, collect information, and download malware to mobile phones, which are discussed later in the “Infections” section.

The hijacked packet is then reconstructed to look like the source IP address of the original IP packet, except that the packet traverses 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 benefits of packet hijacking, cyber pirates need to conceal their identity in packet hijacking, and for that reason disguise the actual routing of IP packets and thus even the Layer 3 ICMP function "Trace Route" in communications. You will have difficulty identifying the actual path of . However, in cases where hijacking adds significant delays in packet routing, abnormal latency can be immediately investigated by the network operator.

Cyber-infections - One of the most insidious categories of cyberattacks is to collect information, commit fraud, redirect traffic, infect other devices, damage or block systems, or deny service failures. It is a “cyber infection” that thereby installs malware within the target device or devices to cause a malware infection. Cyber infections can spread through emails, files, websites, system extensions, applications or networks. “Spyware,” one common category of malware, 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 then passes that information on to cyber pirates. Other malware infections can take control of hardware, for example controlling routers to carry out the aforementioned packet hijacking. In these cases, cyber pirates seek to obtain information or control profits for their own purposes.

Another class of cyber-infections, including viruses, worms, and Trojan horses, are designed to prevent devices from performing normal operations, such as overwriting important files or repeatedly executing meaningless functions. Basically, it denies service, degrades performance, or kills the device completely. These malicious infections are destructive in nature and are used for malicious purposes, thereby preventing a competitor's business from functioning properly, or simply for fun reasons, to check if a hacker is possible.

Surveillance - Intrusion and surveillance go beyond cybercrime. In these cases, private investigators or acquaintances are hired or coerced to install devices or programs on the target's personal devices to monitor voice conversations, data exchange, and location. Because the detective must temporarily access the target device without the subject knowing, this poses a greater risk of getting caught. For example, SIM cards are available commercially that can copy a phone's network access privileges, but at the same time transmit information to cybercriminals who monitor a target's call and data traffic.

Other forms of surveillance, like those in casinos, involve using secret video cameras to monitor a person's every move and phone call. Through video monitoring, you can easily learn a device's password or PIN by observing the user's keystrokes during the login process. If there are enough cameras in place, the login process will eventually be recorded. To gain access to unsuspecting camera networks, cyber pirates can hack existing camera surveillance systems in buildings, stores or streets and access other people's networks to monitor the actions of unsuspecting victims. The combination of video surveillance and packet sniffing provides a more comprehensive data set from which to launch subsequent cyberattacks.

Pirate Administration(Infiltration) - Another means cyber pirates may use to obtain information is by hacking to gain access to system administration privileges on a device, server, or network. Thus, a user By hacking the system administrator's login, rather than gaining unauthorized access to the system administrator's account, a cyber pirate can gain significant access and privileges without the system user knowing. Since the system administrator acts as the system's police officer, he or she is essentially the system's police officer. There is no one to detect criminal activity, and there is no one to police a system or network with inherently corrupt managers.

Conclusion - The ubiquity and interoperability of the Internet, packet-switched networks, and the near-universal adoption of the 7-Layer Open Source Initiative network model have led to an unparalleled expansion of global communications over the past two decades, with global communications expanding from smartphones to tablets, computers, and smart TVs. , offered a diverse range of devices ranging from automobiles, home appliances, and light bulbs. The global adoption of the Internet Protocol, or IP, as the basis for Ethernet, cellular, WiFi, and cable TV connections has not only resulted in unified communications, but has also significantly simplified the challenge for hackers and cybercriminals to break into as many devices and systems as possible. Given the many software and hardware methods that can attack today's communications networks, no single security method as a single defense is sufficient. Instead, a systematic approach is needed to secure every device, end link, local telco/network and cloud network to ensure protection against sophisticated cyber attacks. The method utilized must provide intrinsic cybersecurity and cyber privacy without sacrificing QOS, network latency, video or sound quality. Cryptography must remain a critical component of these next-generation developments in secure communications and data storage, but the security of networks cannot rely solely on encryption methodologies.

In accordance with the present invention, data (broadly defined to include text, audio, video, graphics and all other types of digital information or files) is transmitted over a Secure Dynamic Network and Protocol (SDNP) network or “cloud”. . The "SDNP" Cloud consists of a number of "Nodes", also referred to as "Media Nodes", individually hosted on servers or other types of computers or digital devices (collectively referred to herein as "Servers") located anywhere in the world. Includes. 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 over 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 provides "last mile" links between the SDNP Cloud and client devices such as mobile phones, tablets, laptops and desktop computers, mobile consumer electronics devices, and Internet of Things devices and electronics, automobiles, and other vehicles. Additionally, it includes SDNP Cloud. Last mile communications also include cell phone towers, home 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 individual strings of digital bits that can be of fixed or variable length, and the data can also be processed using the following techniques: scrambling, encryption, or splitting. or reverse processing, unscrambling, deciphering and mixing thereof (Note: As used herein, unless the context indicates otherwise, the word “or” is used in a conjunctive (and/or) sense). It is disguised by using .

Scrambling involves rearranging data within a data packet; For example, data segments A, B, and C, which appear in that order in a packet, are rearranged into the sequence C, A, and B. The opposite of the scrambling operation is referred to as “unscrambling” and involves rearranging the data within the packet to the order in which A, B, and C first appeared in the example above. The combined operation of unscrambling and then scrambling a 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 data in the packet into a format called ciphertext, which is transparent to the sender and other authorized parties, and to those who must perform the reverse operation—“decryption”—to do so. It can only be understood through The combined operation of decrypting a ciphertext data packet and re-encrypting it, typically, but not necessarily using a method different from the method already used to encrypt it, is herein referred to as "re-encryption". It is referred to as

The third operation, "splitting", as the name suggests, means splitting the 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 separated and then mixed packets may be the same or different from the previous splitting operation. The order of operations is reversible, so that splitting may not be effected by mixing, and, conversely, mixing multiple inputs into one output may not be effected by splitting in order to recover the components by splitting. (Note : Since scrambling and unscrambling, encryption and decryption, and splitting and mixing are reverse processes, knowledge of the algorithm or method used to perform them is required to perform the opposite. Therefore, here we use special scrambling, encryption, or With respect to partitioning algorithms, it should be recognized that knowledge of the algorithm allows one to perform the reverse process.)

In accordance with the present invention, data packets passing through the SDNP cloud are scrambled, encrypted, or undergo one or both of these operations in combination with splitting. Additionally, “junk” (i.e. meaningless) data may be added to the packet to make the packet more difficult to decipher or to fit the packet to a required length. Moreover, packets can be parsed, i.e. separated into separate fragments. In computing languages, parsing means breaking a computer language statement, computer instruction, or data file into parts that can be used by the 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 packet is according to the Internet protocol, within the SDNP cloud, the addresses of media nodes are not standard Internet addresses, that is, they cannot be identified by any Internet DNS server. Therefore, although a media node is technically capable of receiving data packets over the Internet, the media node does not recognize the address or does not respond to queries. Moreover, even if Internet users contact the Media Node, they cannot access or inspect the data inside the Media Node, as they may perceive the Media Node as an impostor 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 an SDNP name server or an equivalently capable server, data packets transmitted from that node to another SDNP media node will be ignored and discarded. In a similar way, only clients registered with the SDNP name server can contact SDNP media nodes. As with unregistered servers, data packets received from sources other than registered SDNP clients will be ignored and discarded immediately.

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

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

In another embodiment, referred to as “multi-route” data transmission, packets are split at a gateway node, and the resulting multiple packets traverse the cloud in a series of “parallel” paths, with no path except the gateway node. Do not share media nodes with other paths. 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 have a portion of the entire message. The packet may be scrambled and re-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 only over a single path or series of parallel paths in the SDNP cloud, but rather packets may travel over multiple paths, many of which intersect each other. Because the picture of possible paths in this embodiment resembles a mesh, it is referred to as “meshed transport.” As in the embodiments described above, packets may be scrambled, encrypted, and split or mixed as they pass through individual media nodes in the SDNP cloud.

The path of packets through the SDNP network is determined by the signaling function, which is implemented by a segment of the media node itself, preferably "dual-channel" or "triple-channel", by a separate signaling node running on a dedicated signaling server. This can be done as an example. The signaling function determines the route of each packet as it leaves the sending client device (e.g. a mobile phone) based on the conditions of the network (e.g. propagation delay) and the priority and urgency of the call, It notifies each media node along the route that receives it, and also commands the node that will 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 a data field attached to each data sub-packet in the SDNP header or sub-header used to identify the sub-packet. Each sub-packet may contain data segments from one or multiple sources stored in data "slots" designated 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 is aligned with the splitting and mixing functions, because once a packet is split, the respective paths of each split sub-packet must be determined, and the node where the sub-packets are reassembled must be instructed to mix them. Because it does. Packets may be split and then mixed once, as in a multi-route embodiment, or they may be split and mixed multiple times as they exit the gateway node through the SDNP network. The decisions at which node the packet will be split, how many sub-packets will be split, each path of the sub-packet, and at which node the sub-packets will be mixed to recreate the original packet, require separate signaling. Regardless of whether it is performed by the server or not, it is all under the control of the signaling function. The segmentation algorithm may specify which data segments in the communication will 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 instructed by the signaling function, the node may also re-split the packet according to a different splitting algorithm corresponding to the time or state in which the splitting process occurs.

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

In a “dynamic” embodiment of the invention, individual media nodes in the SDNP cloud cannot use the same scrambling, encryption, or segmentation algorithm or method 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. It can be divided. “Dynamic” behavior greatly increases the difficulties a hacker may face, because they only have a short period of time (e.g. 100 msec) to understand the meaning of the packet, and even if they succeed, the The usefulness of the 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 a part of the node isolated from the data transmission ports, and which also allows the media node to apply data 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 to the media nodes and 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” that is used to indicate to the receiving node what algorithm will be used to unscramble the packet. The seed is a disguised number that is meaningless in itself but is based on constantly changing conditions, such as the time the packet was scrambled by a conventional media node. When the conventional node scrambled a packet, its associated DMZ server generated a seed based on the state. Of course, that state was used by its associated DMZ server in selecting the algorithm used to scramble the packet, which was then sent to the sending media node in the form of instructions on how to scramble the packet. Accordingly, the transmitting node received both an instruction on how to scramble the packet and a seed to be transmitted to the next media node. The seed generator operating within the DMZ server generated seeds using an algorithm based on the state when the process was executed. Even though the seed generator and its algorithm are part of the media node's shared secrets, the generated seed is not secret because it does not access the algorithm for which the numeric seed has no meaning.

Accordingly, the next media note on the route of the packet receives the scrambled packet and a seed derived from the state associated with the packet (eg, the time it was scrambled). The seed may be included in the packet itself, or may be sent to the receiving node prior to the packet, either along the same route as the packet or through some other path, such as through a signaling server.

Regardless of how it receives the sheet, the receiving node transmits the seed to the DMZ server. Since that DMZ server has a selector or table of scrambling algorithms that is part of its shared secret and therefore the same as 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; You 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 re-scrambled according to a different scrambling algorithm before being transmitted to another node. If so, the receiving node cooperates with the DMZ server to obtain the scrambling algorithm and seed, and the process repeats.

Therefore, 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 invention, actual state (e.g., time) may be transmitted between nodes (i.e., the transmitting node does not need to transmit a seed to the receiving node). The DMZ servers associated with both the sending and receiving media nodes contain hidden number generators (in other words, part of the shared secret) that contain the same algorithm at any given point in time. 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 the masking number and the masking number. The transmitting node transmits the status to the receiving node. Unlike seeds, cloaking numbers are never passed across the network, but exclusively private communication is maintained between a media node and its DMZ server. When the receiving media node receives the status of the incoming data packet, the Stealth Number Generator and its associated DMZ server use the state to generate the same Stealth Number, which is then used by the selector to identify the algorithm to be used for unscrambling the packet. Or used in tables. The state may be included in the packet or may be transmitted from the sending node to the receiving node before the packet or through some other path.

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. Shared secrets held by the DMZ server include selectors or tables of encryption and splitting algorithms and key generators. In the case of symmetric key encryption, the sending node transmits a key to the receiving media node, which is 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 information, i.e. the receiving node, first sends the encryption key to the node containing the data packet to be transmitted. Afterwards, the sending media node encrypts the data according to its encryption key. Only the receiving media node that generates the encryption key possesses 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 about how to decrypt the data packet.

In the case of splitting, the media node from which the packet was split sends a seed to the media node where the resulting sub-packets will be mixed, and 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 the seed to do this.

As described above, in a dual or triple channel embodiment, signaling functions are performed by signaling nodes operating on a separate group of servers 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. Accordingly, a transmitting media node can transmit a seed or key to a signaling server, and the signaling server can forward the seed or key to a receiving media node. As described above, the signaling server is responsible for designing the path of packets, so the signaling server knows the next media node to which each packet is directed.

To make it more difficult for a would-be hacker, a list or table of possible scrambling, splitting, or encryption methods in the selector may be organized periodically (e.g., hourly or daily) by changing the key or method corresponding to a particular seed. It can be “shuffled.” Accordingly, the encryption algorithm applied by a given media node to a packet generated at time t1 on the first day may be different from the encryption algorithm it applies to a packet generated at the same time t1 on the second day.

Each DMZ server is typically physically associated with one or more media nodes in the same "server farm". As described above, a media node can request instructions on what to do with packets it receives by providing a seed or key to its associated DMZ server (e.g., based on the time or state in which the packet was generated). However, Media Nodes cannot access shared secrets or any other data or code within the DMZ server. The DMZ server may respond to this request by using the seed or key to determine the method the media node should use when unscrambling, decrypting, or mixing packets. For example, if a packet is scrambled and the media node wants to know how to unscramble it, the DMZ server can look through the scrambling algorithm list (or selector) to find the specified algorithm that corresponds to the seed. Afterwards, the DMZ instructs the media node to unscramble the packet according to its algorithm. That is, the media node transmits queries made 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 though they do not have DNS recognized 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 are transmitted between the sending media node and the receiving media node as part of the data packet itself, or they can be transmitted in a separate packet as a data packet before 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 from 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 packets, and delivers to Media Node #2 a key reflecting the status corresponding to the encryption method. Media Node #2 performs encryption and transmits 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 examples above as a determining factor in the scrambling encryption or splitting method to be implemented on the seed or key is illustrative only. Any changing parameter, such as the number of nodes the packet has passed through, may be used as the "state" of the seed or key to select the specified scrambling, encryption, or splitting method to be used.

In a “dual channel” embodiment, seeds and keys may be transmitted between media nodes via a second “command and control” channel via a signaling server, rather than directly between media nodes. Signaling nodes also provide routing information to media nodes and may also inform media nodes along the packet route how the packet is split or mixed into other packets, and they may also ensure that the next media node(s) recognize the packet(s). An identifying “tag” is applied to each media node to enable it to be transmitted. The signaling server preferably supplies only the last and next media nodes of packets passing through 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 determining routes from and to other media nodes. Determine the route to the exit gateway node. In this way, no single signaling server is aware of the complete routing of the data packet.

In a “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 IPs or SDNP addresses. do. The name server also continuously monitors the media nodes of 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 locating 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. Additionally, a separate dedicated name server is used to act as the first contact whenever a device first connects, e.g. 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 bridge media nodes, which hold the shared secrets of both zones and also convert data formatted according to the rules of one zone to 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, a full-duplex (i.e. two-way) communication link is formed 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 an SDNP network there is no single point of control and no nodes or servers in the network have a complete picture of how a given communication occurs or how it can change dynamically.

For example, signaling nodes running on signaling servers know the route (or in some cases only part of the route) over which 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 Moreover, the signaling node does not have access to the shared secrets of the media node's DMZ server, so it does not know how the data packets in transit are encrypted, scrambled, split, or mixed.

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

SDNP media nodes that actually transmit media content do not know who the sender they are communicating with is, nor do they know the route that 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 only knows the data is encrypted, scrambled, etc. It doesn't know how to split, mix, or split files, nor does it know how to use states, numeric seeds, or keys to select algorithms or decrypt files. The know-how required to correctly process the data segments 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.

Other ingenious aspects of the disclosed invention include the ability to control the size of data packets by reducing network latency and minimizing propagation delay, thereby providing better quality of service (QoS) and eliminating echo or dropped calls; This means sending smaller data packets 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 may facilitate race routing and send redundant messages in fragmented form through the SDNP cloud, which selects only the fastest data to recover the original sound or data content. You can.

Among the many advantages of the SDNP system according to the present invention, in parallel and "meshed transport" embodiments, packets can be fragmented as they traverse the SDNP cloud, allowing a potential hacker to break into individual sub-packets or groups of sub-packets. This prevents the message from being understood even if the message can be decrypted, and in "dynamic" embodiments the scrambling, encryption, and segmentation methods applied to the packet are constantly changing, preventing a potential hacker from successfully decrypting the packet at any given point in time. 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 from review of the following description.

Similar security technologies can generally be applied in the "last mile" between the SDNP cloud and the client device, such as a mobile phone or tablet. Client devices are typically deployed within a secure enclave separate from the cloud, which can first become an authenticated SDNP client, and then download software packages specific to the device's secure enclave, typically through downloads from an SDNP management server. Includes installation on client devices. Client devices are linked to the SDNP cloud through a gateway media node (often referred to simply as a “gateway”) within the cloud. The gateway media node has access to the shared secret associated with both the cloud and the secure enclave 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 exchange seeds and keys with each other directly through the signaling server. Accordingly, the sending client device can transmit the seed and/or key directly to the receiving client device. In such embodiments, 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, thereby representing an added level of security, referred to as nested security.

Additionally, the client device or the gateway node through which the client device communicates may transmit data of the same type - for example, 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. Packets representing information - for example, one voice packet and one text file, one text packet, and one video or photo image - may be mixed, and an egress gateway node or destination client device may mix the packets. The original packet can be restored by splitting the packet. This is in addition to any scrambling, encryption or splitting that occurs in the SDNP network. In such cases, the sending client device may transmit a seed to the receiving client device that describes how to split the packets to reproduce the original mixed packets at the sending client device or gateway media node. Implementing successful mixing and splitting may involve a linear sequence of operations, or alternatively utilize a nested architecture, where the client executes its own security measures and the SDNP cloud accordingly.

To further confuse a possible hacker, the client device may transmit successive packets (or sub-packets) in a single communication to different gateway nodes, and/or the client device may transmit them over different physical media links (cellular , WiFi, Ethernet cables, etc.) - a process often referred to herein as "multi-PHY" transmission. To add to the 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 unique developments 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, a particular designated participant can be “silenced,” i.e., excluded from the call, by preventing a client device or other node from sending packets to the muted participant or participants. 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 to all users using encryption, where all participants have a copy of the decryption key. In private or silent mode, data packets broadcast to users use different encryption, where only selected users share the decryption key.

The security mechanisms inherent to communications using SDNP networks and protocols also make them perfectly suited for secure file and data storage. Since typical communication over an SDNP network typically involves anonymous, fragmented data transfer of scrambled, encrypted data from one client device to another, effectively breaking the communication at the transfer and the original client. File and data storage can be realized by storing them indefinitely in one or more buffers until the device wishes to retrieve them. This distributed file storage is often referred to herein as distributed data storage.

In the drawings listed below, generally similar components are given the same reference numerals. However, it should be recognized that any component to which a given reference number is assigned is not necessarily identical to other components with 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. Additionally, groups of components, such as servers in a network that are collectively identified by a single reference number, need not necessarily be identical.

1 is a schematic diagram showing a typical packet transmission over a network.
Figure 2A is a schematic diagram showing the packet scrambling process.
Figure 2b is a schematic diagram showing the packet unscrambling process.
Figure 2C is a schematic diagram showing various packet scrambling algorithms.
Figure 2d is a schematic diagram showing fixed parameter packet scrambling.
Figure 2e is a schematic diagram showing dynamic scrambling with hidden numbers.
Figure 3 is a schematic diagram showing the packet re-scrambling process.
Figure 4A is a schematic diagram showing the packet encryption process.
Figure 4b is a schematic diagram showing the packet decryption process.
Figure 5 is a schematic diagram showing the process of cryptographic scrambling and its inverse functions.
Figure 6 is a schematic diagram showing the process of DUSE re-packeting including re-scrambling and re-encryption.
Figure 7A is a schematic diagram showing the process of fixed-length packet segmentation.
Figure 7b is a schematic diagram showing the process of fixed-length packet mixing.
Figure 8 is a schematic diagram showing various packet-mixing methods.
Figure 9a is a table summarizing SDNP security functions and adverse functions.
FIG. 9B is a block diagram illustrating SDNP security operations implemented on incoming and outgoing data packets for single route last mile communication.
FIG. 9C is a block diagram illustrating SDNP security operations implemented on incoming and outgoing data packets for multi-route last mile communications.
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.
Figure 9E is a graphical representation of an SDNP data packet using the 7-layer OSI model to illustrate hierarchical data encapsulation.
Figure 9F is a graph and bar diagram of SDNP payload.
FIG. 9G is a block diagram illustrating inbound last mile data packet processing at an SDNP gateway using tri-channel communications.
FIG. 9H is a block diagram illustrating inbound last mile data packet processing in an SDNP gateway using single-channel communication.
FIG. 9I is a block diagram illustrating outbound last mile data packet processing in an SDNP gateway using tri-channel communications.
Figure 10 is a schematic diagram of SDNP cloud.
Figure 11 schematically shows an example of unsecured last mile communication without identity verification.
Figure 12 illustrates unsecure last mile communication over a generic legacy telephone system (POTS) without verification of the identity of the caller.
Figure 13 schematically shows an example of unsecured last mile communication with identity verification.
Figure 14 illustrates unsecured last mile communication over a similar Public Service Telephone Network (PSTN), with operator-based identity verification.
15 illustrates unsecured last mile communication over a wired digital network, with login- or token-based identity verification.
Figure 16 illustrates unsecured last mile communication over a wired analog network, with PEST- or credit card-based identity verification.
Figure 17 schematically illustrates an example of hypersecure last mile communication that can 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.
Figure 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.
Figure 22 illustrates identity-verifiable hypersecure last mile communication over a combined cabled wired and home WiFi wireless network.
Figure 23 schematically illustrates an example of last mile communication including an identity-verifiable hypersecure communication leg connected to an identity-pairing secure LAN last link.
Figure 24 illustrates last mile communication including an identity-verifiable hypersecure wired communication leg connected by wire to an identity-paired secure device and to an unidentified unsecure device.
25 illustrates last mile communications including an identity-enabled hypersecure wired communications leg connected by a WiFi LAN to identity-pairing WPA-secure computing and communications devices for home and work.
26 illustrates last mile communications including an identity-enabled hypersecure wired communication leg connected to an identity-paired WPA-secure home IoT device by WiFi LAN.
27 illustrates last mile communications including an identity-enabled hypersecure wired communications leg connected to a business identity-pairing WPA-secure device by Ethernet or by WiFi LAN.
Figure 28 schematically illustrates an example of last mile communication including an identity-verifiable hypersecure communication leg connected to an identity-paired secure wired or secure wireless LAN last link.
Figure 29a schematically shows a wired and wireless hypersecure bridge including Ethernet and WiFi applicable in last mile communications.
Figure 29b schematically shows a wired and wireless hypersecure bridge using satellite and automotive networks applicable in last mile communications.
Figure 29c schematically shows a wired and wireless hypersecure bridge using cable and cellular networks applicable in last mile communications.
30 includes identity-verifiable 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 communication network with satellite connectivity.
31B is an example of an aircraft satellite communications and antenna module.
32 is an example of last link hypersecure communication between devices within 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 on-board train communication network with radio and satellite connectivity.
34 illustrates hypersecure last mile communications for automotive telematics modules including cellular last link connectivity.
35 is an example of last link communication between a telematic module and an in-cabin WiFi connected device within an automotive communication network with cellular connectivity.
Figure 36 is an example of hypersecure inter-vehicle communication with cellular connectivity.
Figure 37 illustrates hypersecure trunk line communications over microwave, satellite, and fiber networks.
Figure 38 shows a comparison of security, identity verification, and caller anonymity features for hypersecure, secure, and unsecure communication networks.
Figure 39 is a schematic diagram of single-route last mile hypersecure communication with fixed IP address.
Figure 40A is a schematic IP stack diagram of single-route last mile hypersecure communication using fixed IP addresses.
Figure 40B is a simplified diagram of single-route last mile hypersecure communication using fixed IP addresses.
Figure 41 is a schematic diagram of single-route last mile hypersecure communication with dynamic client IP addresses.
Figure 42a is an IP stack diagram of single-route last mile hypersecure communication using dynamic client IP addresses.
Figure 42B is an alternative IP stack diagram for 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 fixed IP addresses.
Figure 44A is an IP stack diagram of multi-route last mile hypersecure communication with fixed IP addresses using a single PHY last link.
Figure 44b is an IP stack diagram of multi-route last mile hypersecure communication with fixed IP addresses using multiple PHY last links.
Figure 45 is a schematic diagram of multi-route last mile hypersecure communication with dynamic client IP addresses.
Figure 46A is an IP stack diagram of multi-route last mile hypersecure communication with dynamic client IP addresses 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.
Figure 47 is a schematic diagram of an alternative version of multi-route last mile hypersecure communication with dynamic client IP addresses.
Figure 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 representation of IPv4 and IPv6 datagrams for Ethernet communication carrying SDNP payload.
Figure 50a is a graphical diagram of IPv4 and IPv6 last link Ethernet packets used by the client for SDNP-cloud communication.
Figure 50b is a graphical representation of IPv4 and IPv6 gateway link Ethernet packets used by the client for SDNP-cloud communication.
Figure 50C is a graphical representation of IPv4 and IPv6 gateway link Ethernet packets used in SDNP-Cloud for client communication.
Figure 50D is a graphical representation of IPv4 and IPv6 last link Ethernet packets used in SDNP-Cloud for client communication.
Figure 51A shows continuous Ethernet data packets (abbreviated) used in single path last mile communications with fixed client addressing.
Figure 51B shows continuous Ethernet data packets (abbreviated) used in single path last mile communications with dynamic client addressing.
Figure 51C shows sequential Ethernet data packets (abbreviated) used in multi-path last mile communications with fixed client addressing.
Figure 51D shows sequential Ethernet data packets (abbreviated) used in multi-path last mile communications with dynamic client addressing.
Figure 52A is a table summarizing SDNP last mile routing over Ethernet.
Figure 52b is a topological illustration of single path last mile communication over Ethernet.
Figure 52C is a topological illustration of multi-path last mile communications over Ethernet.
Figure 52D is an additional topological illustration of multi-path last mile communications over Ethernet.
Figure 53 is a graphical representation of IPv4 and IPv6 datagrams for WiFi communication carrying SDNP payload.
Figure 54a is a graph of IPv4 and IPv6 last link WiFi packets used by the client for SDNP-cloud communication.
Figure 54b is a graphical diagram of IPv4 and IPv6 gateway link WiFi packets used by the client for SDNP-cloud communication.
Figure 54C is a graphical illustration of IPv4 and IPv6 gateway link WiFi packets used in SDNP-Cloud for client communication.
Figure 54D is a graphical representation of IPv4 and IPv6 last link WiFi packets used in SDNP-Cloud for client communication.
Figure 55 is a graphical representation of IPv4 and IPv6 datagrams for 4G cellular communications carrying SDNP payload.
Figure 56A is a graphical representation of IPv4 and IPv6 last link 4G cellular data packets used by clients for SDNP-to-cloud communication.
Figure 56b is a graphical illustration of IPv4 and IPv6 last link 4G cellular packets used in SDNP-Cloud for client communications.
Figure 57A is a graphical illustration of single-media multi-PHY last link communication.
Figure 57B is a graphical illustration of mixed-media multi-PHY last link communication.
Figure 57C is a graphical illustration of an alternative implementation of multi-PHY last link communication.
Figure 58 is a graphical illustration of a succession of clients for SDNP-Cloud last link communication using IPv6 datagrams carried over multi-PHY Ethernet.
Figure 59 is a graphical illustration of successive clients for SDNP-Cloud last link communication using IPv6 datagrams delivered over multi-PHY WiFi.
Figure 60 is a graphical illustration of a succession of clients for SDNP-Cloud last link communication using IPv6 datagrams carried over a multi-PHY 4G cellular network.
Figure 61 is a graphical representation of successive clients for SDNP-Cloud last link communication using IPv6 datagrams using multi-PHY delivery over Ethernet and WiFi. Figure 62 is a graphical illustration of a succession of clients for SDNP-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 illustrating layer 1 through layer 7 functionality.
Figure 64 is a graphical illustration of a DOCSIS3 based communication packet for a cable system carrying an SDNP payload.
Figure 65A is a graphical representation of spectrum allocation and carrier modulation methods for various DOCSIS3 protocols.
Figure 65b is a graphical representation of the DOCSIS3.1 communication sequence between CTMS and CM.
Figure 65C is a graph diagram of DOCSIS3.1 upstream communication. Figure 65d is a graph diagram of DOCSIS3.1 downstream communication.
Figure 66 is a schematic diagram of a triple-path SDNP network for last mile communications.
Figure 67 is a schematic diagram of a “call request” operation in tri-channel SDNP last mile communications.
Figure 68 is a schematic diagram of the “Address Request” operation in tri-channel SDNP last mile communication.
Figure 69 is a schematic diagram of “address passing” operation in tri-channel SDNP last mile communication.
Figure 70 is a flow chart showing SDNP command and control packet composition.
Figure 71 is a schematic diagram of “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.
Figure 73A is a schematic diagram of SDNP cloud and last mile triple-path communication to SDNP clients in SDNP calls. Figure 73B is a schematic diagram of SDNP cloud and last mile triple-path communication implemented as a “call out” to non-SDNP clients.
Figure 74 is a schematic diagram of “routing indication” operation in multi-path triple-channel SDNP last mile communication.
Figure 75A is a schematic diagram of “SDNP Call” operation in multi-path triple-channel SDNP last mile communication in the direction from SDNP client to SDNP cloud.
Figure 75B is a schematic diagram of “SDNP Call” operation in multi-path triple-channel SDNP last mile communication in the direction from SDNP Cloud to SDNP Client.
Figure 76 is a schematic diagram of group-call “direct routing” operation in single-path triple-channel SDNP last mile communications.
Figure 77A is a schematic diagram of a “SDNP Group Call” using SDNP multi-path cloud transport and SDNP last mile communications in the direction from Zone U1 clients to clients in other zones.
Figure 77B is a schematic diagram of an “SDNP Group Call” using SDNP multi-path cloud transport and SDNP last mile communications in the direction from Zone U7 clients to clients in other zones.
Figure 77C is a schematic diagram of a “SDNP Group Call” using SDNP multi-path cloud transport and SDNP last mile communications in the direction from a Zone U9 client to other clients on the same zone and within other zones.
Figure 78 is a schematic diagram of “SDNP Group Call” using SDNP multi-path cloud transport and last mile communications to both SDNP clients and unsecured PSTN devices.
Figure 79A is a bar diagram of regular and private call operations in SDNP group calls.
Figure 79B is a bar diagram of regular call and hyper-private call operation in SDNP group calls.
Figure 80A is a bar diagram of regular and private push-to-talk operation in an SDNP PTT group call.
Figure 80B is a bar diagram of regular and hyper-private push-to-talk operation in SDNP PTT group calls.
81 is a schematic diagram of data transfer for write-operation in hypersecure file storage of fragmented data.
Figure 82A is a schematic diagram of the data flow for write-operation in hypersecure file storage of fragmented data.
Figure 82b is a schematic diagram of the data flow for a read-operation in hypersecure file storage of fragmented data.
83 is a schematic diagram of data transfer for read-operation in hypersecure file storage of fragmented data.
Figure 84A shows various examples of SDNP cloud connected to file storage solutions.
Figure 84B is a schematic diagram of a distributed hypersecure file storage network including local and cloud-attached storage servers.
Figure 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.
Figure 85C is a file mapping for RRF = 2 read redundant hypersecure file storage.
Figure 86 is a network map for a distributed hypersecure file storage system using triple-channel network communication.
Figure 87A illustrates file write request operations within a distributed hypersecure file storage system.
Figure 87b illustrates file server name request operation within a distributed hypersecure file storage system.
Figure 87C illustrates signaling server planning operations within a distributed hypersecure file storage system.
Figure 87D illustrates signaling server client-side last mile and SDNP cloud record routing instructions within a distributed hypersecure file storage system.
Figure 87E illustrates signaling server storage side last mile and SDNP cloud record routing instructions in a distributed hypersecure file storage system.
Figure 88 illustrates file transfer within a distributed hypersecure file storage system.
Figure 89a shows link response confirmation file storage and recording operations in a distributed hypersecure file storage system.
Figure 89B illustrates file storage server link delivery within a distributed hypersecure file storage system. Figure 89C shows a file storage server record confirmation data packet containing a FS link.
Figure 89d shows composition of file storage read links within a client's SDNP Messenger.
Figure 90A is a file map for non-redundant RRF = 0 hypersecure file storage with LRF = 0 non-redundant FS links.
Figure 90b is a file map for non-redundant RRF = 0 hypersecure file storage with LRF = 1 redundant FS links.
Figure 90C is a file map for non-redundant RRF = 1 hypersecure file storage with LRF = 1 redundant FS links.
Figure 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.
Figure 93A is a schematic diagram of SDNP distributed file storage with client-side file security and hypersecure file transfer.
Figure 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 storage recording operations.
Figure 95 is a simplified schematic diagram of hypersecure decoding in SDNP distributed file storage read operations.
Figure 96a is a flowchart explaining AAA operation in a hypersecure file read operation.
Figure 96b is a flow chart illustrating file access and SDNP transmission in a hypersecure file read operation.
Figure 97A illustrates file read request operations within a distributed hypersecure file storage system.
Figure 97b illustrates a file storage server name request operation within a distributed hypersecure file storage system.
Figure 97C illustrates file storage server name forwarding and signaling server planning operations within a distributed hypersecure file storage system.
Figure 97D illustrates signaling server storage side last mile and SDNP cloud routing read instructions in a distributed hypersecure file storage system.
Figure 97E illustrates signaling server client-side last mile and SDNP cloud read routing instructions within a distributed hypersecure file storage system.
Figure 98 illustrates storage-side file decoding during a read operation within a distributed hypersecure file storage system.
Figure 99 illustrates file data transfer within a distributed hypersecure file storage system during a read operation.
Figure 100 illustrates file data transfer within a distributed hypersecure file storage system during link refresh.
Figure 101 illustrates file data transfer within a distributed hypersecure file storage system used to redistribute files.
Figure 102 shows timestamps within SDNP text messaging.
Figure 103 is a flowchart of SDNP registered communication.
Figure 104A illustrates end-to-end encryption in Internet OTT communications.
Figure 104B illustrates end-to-end encryption in hypersecure communication.
Figure 105A is a schematic diagram of the “SDNP Call” operation, where the SDNP security agent conducts invisible monitoring of outgoing calls.
Figure 105B is a schematic diagram of the “SDNP Call” operation, where the SDNP security agent performs invisible monitoring of incoming calls.
Figure 106 illustrates file storage server link forwarding in a distributed hypersecure file storage system, where SDNP security agents perform invisible monitoring of FS link routing.
Figure 107 is a schematic diagram of the “SDNP Call” operation, where the SDNP security agent conducts invisible monitoring of outgoing calls utilizing multi-path last mile communications.
Figure 108 is a flowchart of steps for specifying and authenticating an SDNP security agent.
Figure 109 shows a mobile phone to tower communication exposed to SS7 vulnerability.
Figure 110 illustrates SDNP communication using phone number hiding to repel SS7 attacks.
Figure 111 illustrates the connectivity of SDNP SoftSwitch-based clouds hosted on separate servers.
Figure 112 illustrates the connectivity of an SDNP SoftSwitch-based cloud hosted on shared servers.
Figure 113 illustrates the connectivity of an SDNP SoftSwitch-based cloud hosted on overlapping networks. Figure 114 illustrates the connectivity of an SDNP softswitch-based cloud accessing a global SDNP cloud telco.
Figure 115 is an example of a nested SDNP subnet.

After nearly a century and a half of circuit-switched telephone technology, today's communications systems and networks have moved from packet-switched to Ethernet, WiFi, 4G/LTE, and the Internet Protocol, which carries DOCSIS3 data over cable and fiber in just a decade. Everything was moved to communications. Using redundant paths to ensure reliable delivery of IP packets - voice, text, pictures, video, including the reason the Internet was created in the first place - along with an unrivaled level of system interoperability and connectivity across the globe. The benefits of providing and data are many. However, as with any innovation, the intensity of the challenges the new technology creates is often matched by the benefits it derives.

Disadvantages of existing telecommunication carriers

As described in detail throughout the Background of the Invention, today's communications have many shortcomings. Today, the highest performing communications systems, including custom digital hardware owned by the world's major long-distance carriers such as AT&T, Verizon, NTT, Vodaphone, etc., typically deliver superior sound quality. However, it includes expensive monthly fees, connection fees, long distance charges, complex data plans, long distance roaming charges, and various service charges. 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 landline and privacy breaches reported in the media today, the security of private carrier communications remains questionable, at least on last-mile connections, if not in their private clouds.

“Internet Service Providers” or ISPs form another link in the global communications chain. As described in the Background Art, voice delivered over the Internet using VoIP or “Voice over Internet Protocol” suffers from numerous quality of service or QoS problems, including:

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

* The routing of IP packets takes unpredictable paths, resulting in ever-changing delays, bursts of high data error rates, and unexpected call drops.

* IP packet routing is at the discretion of the Internet Service Provider, which controls the network through which packets are routed and may also load balance its own network or its VIPs at the expense of connection quality for normal traffic passing through that network. Routing can be adjusted 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 the network or factors that affect QoS.

* Use of heavy audio codecs that do not provide audio with 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 IP packet rebroadcast. Unassisted UDP transmission does not provide payload integrity.

In addition to QoS issues, the security of today's devices and networks is abysmal and completely unacceptable to support the future needs of global communications. As detailed in the Background section, entitled Secure Dynamic Communication Networks and Protocols, network security includes: spyware, Trojans, infections and phishing; Last Link, which includes spyware, IP packet sniffing, eavesdropping, and call blocking from cyber pirate “fake” cell phone towers; And on the local network or telco portion of last mile connectivity, they are vulnerable to an array of large-scale cyber attacks on communications devices, including spyware, IP packet sniffing, virus-like infections, and cyber pirate "man-in-the-middle attacks." The cloud itself can be accessed unauthorized by security breaches at any cloud gateway, by infections such as viruses, from man-in-the-middle attacks, denial-of-service attacks, and unauthorized 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 cyber privacy violations, including:

* Reveals the destination of the IP packet, including destination IP address, destination port #, and destination MAC address.

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

* Layer 4 transport type and port used # Requested service type 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 an IP packet, including personal and confidential information, login information, application passwords, financial records, videos, and photos.

* A dialog of communication that allows cyber parties repeated opportunities to destroy encrypted files.

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

The repetition of the key point, which is basically an inherent weakness of packet-switched communication networks using the Internet Protocol, allows any hostile party or cyber pirate to intercept IP packets and determine which devices are involved in generating the data contained in the IP packets. This means you can tell 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. You can find out whether it is included or not. In this regard, cyber pirates can determine the "context" of conversations, improving their chances of cracking passwords, destroying password security, and gaining unauthorized access to files, data, and payload content.

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

The encryption process, which converts an unprotected file into an encrypted file, uses a logical or mathematical algorithm, referred to as a cypher, to change the data into equivalent text elements without revealing any obvious patterns in the encryption process. Includes steps. The encrypted file is then transmitted over a communications network or medium until received by the destination device. Upon receiving the file, the receiving device, using a process called "decryption", then decodes the encoded message 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 surface ships used encrypted messages to communicate over open radio channels. Initially, encryption was single key based. By analyzing password patterns, Allied cryptographers were sometimes able to find password key words or patterns and then read encrypted files without detection. As encryption methods become more complex, manually breaking the code becomes more difficult.

The code evolved into machine-based cryptography, an early form of computing. At the time, the only way to break the code was to steal a cryptography machine and use the same tools to encrypt the files to decrypt the messages. The problem was how to steal a password machine without the theft being detected. If the code machine is known to be compromised, an adversary can simply change the code and update the code machine already in operation. 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, encryption became more complex, but the speed of the computers used to decipher encryption codes also improved. At each stage of the development of secure communications, the technology and know-how to encrypt information and the ability to decipher encryption codes have not advanced nearly as quickly. The next major evolutionary step in cryptography came with the innovation of dual-key encryption in the 1970s, which is still used today. One of the best-known dual-key cryptography methods is the RSA public key cryptosystem, named after its developers Rivest, Shamir, and Adleman. Despite being aware of the published RSA, contemporary developers have devised their own versions of the same principles. RSA uses two cryptographic keys based on two large prime numbers that are kept secret from the public. One algorithm is used to convert these two prime numbers into a cryptographic key, referred to herein as the E-key, and a different mathematical algorithm is used to transform the same two secret prime numbers into a secret cryptographic key, also referred to herein as the D-key. An RSA user who has chosen a small number of secrets, referred to herein as a "key publisher", distributes or "makes public" algorithmically generated E-keys, typically containing sizes between 1024b and 4096b, to anyone who wishes to encrypt their files. do. Because this key can be distributed to many parties in unencrypted form, the -E key is known as the "public key."

Parties wishing to communicate with the key publisher use this public electronic key in conjunction with publicly available algorithms, typically provided in the form of commercial software, to encrypt any files to be transmitted to the particular key publisher. Upon receipt of the encrypted file, the key publisher then uses the secret D-key to decrypt the file, returning it to plain text. A unique feature of the dual-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 owned by the key publisher has the ability to decrypt files.

The concept of dual keys, split keys or multiple key exchanges 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 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 generate two keys: an E-key for encryption and an E-key for decryption. Raises the D-key. The laptop then transmits the E-key to the mobile phone using public network communication involving IP packets. The IP packet in unencrypted form contains, as its payload, the destination IP address "CP" and the corresponding port of the mobile phone, the MAC address of the laptop, the IP address, as well as an encrypted copy of the transport protocol (TCP) and the E-key. Includes source address “NB” and port address.

Then, using the agreed-upon encryption algorithm or software package, the mobile phone uses the encryption algorithm and encryption E-key to create an encrypted file, or ciphertext, that is carried as the payload of the IP packet in secure communication from the phone to the laptop. Use to process plaintext files. Upon receipt of the IP packet, the algorithm decrypts the file using the secret decryption key, i.e. the D key. Because the D-key is made to match its corresponding E-key, the algorithm essentially uses knowledge of both keys to decrypt the ciphertext and return it to unencrypted plaintext. Although the payload of the IP packet is secured in the form of an encrypted file, i.e. ciphertext, 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 associated port. It can be sniffed and read by any cyber pirate. Therefore, 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 a VPN, a tunnel or secure pipe is formed in a network using encrypted IP packets. Rather than encrypting only the payload, in a VPN the entire IP packet is encrypted and then encapsulated within another unencrypted IP packet that acts as a mule or carrier to transmit the encapsulated packet from one VPN gateway to another. do. Essentially, VPNs used the same functionality to link disparate local area networks together over long distances, for example, allowing companies operating private networks in New York, Los Angeles, and Tokyo to share one global private network. It was used when one wanted to interconnect LANs.

The basic VPN concept is that a first server, as part of a LAN supporting a large number of devices, for example wirelessly over RF and over wired connections, creates a "virtual server" containing encrypted content across the VPN tunnel. A private network, or VPN, can be thought of as encrypted communication between two devices that are connected to a second server that has a wired connection to desktops, laptops, and other WiFi-based stations.

In addition to these relatively narrow bandwidth links, the first server may also be connected to the supercomputer via 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 external IP packet from server A, specifying source IP address and source port #, is sent to server B at destination IP address and destination port #. These external IP packets establish communication between the first and second servers to form an encrypted tunnel to each other for data transfer. The VPN payload carried by the external packet includes a last mile IP packet, sent to an end device, e.g. a desktop with source IP address "DT" and its corresponding ad hoc port #, and to another end device, e.g. source IP Provides direct communication between laptops with address "NB" and its corresponding ad hoc port #. Although any communication session may be initiated, in one example, a request for file transfer is conducted through a VPN tunnel.

To set up these transfers securely using a virtual private network, a VPN tunnel is created and a session is started before the actual communication is initiated. In enterprise applications, the VPN tunnel is not carried over the Internet, but is instead often carried by a dedicated ISP or carrier that owns its own fiber and hardware network. These carriers often sign annual or long-term contractual agreements with companies requiring their VPN services, guaranteeing a specified bandwidth for a given fee. Ideally, high-speed dedicated links connect directly, 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 the VPN, or to "log in" to the VPN, and a second step to pass data within a 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, the presentation layer, forms a VPN gateway-to-gateway pipe between the servers. It can be thought of as hierarchical, as an external IP packet executed by a 7-layer communications stack (used to accompany a VPN connection), which is 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. For example, application layer 7 data conveyed as device-to-device communication between communicating desktops is tunneled data that includes all seven OSI layers needed to establish communication as in the case where a VPN does not exist. It is transmitted as. In this way, a VPN can be thought of as a communications protocol operating within Layer-7 that is used to transport packets within the VPN.

In operation, an external IP packet, once passed from one communication stack to another, is opened to expose the encapsulated data, which is the actual message of the packet. In this way, end-to-end communication ignores the details used to create the VPN tunnel, except that the VPN tunnel must be formed before any communication attempt and must be closed after the conversation ends. And it comes true. Failure to open the VPN tunnel first will result in unencrypted transmission of IP packets, which is vulnerable to IP packet sniffing, theft, infection, etc. Failure to close the VPN after the conversation is complete may provide cybercriminals with an opportunity to hide their illegal activities in someone else's VPN tunnel, and could result in possible criminal charges being levied against innocent people if intercepted. .

Although VPNs are a common method 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 problems for the two parties to communicate. One problem with VPNs is that the VPN connection must be pre-established before use, and not on a packet-by-packet basis. For example, in a VoIP call over a packet-switched network, a VPN session must first be established before the mobile phone can contact the intended call recipient of the second mobile phone. To do this, the VPN connection application must first be loaded on the caller's mobile phone. The caller must then transmit the IP packet to the VPN host, typically the service provider. These packets are delivered via any available last mile routing, e.g. wirelessly from the cell phone to a nearby WiFi based base station, then by wired communication to the local router, and then by wired communication to the VPN host. Once a session is established between the caller's cell phone and the VPN host, the caller's cell phone must then instruct the VPN host to create a VPN tunnel from the caller's cell phone to the VPN host. This leg of the VPN tunnel is facilitated when layer 5 sessions within the tunnel are encrypted by layer 6.

Once the VPN connection is established, the caller's cell phone can route the call to any other phone through any VoIP phone app. In cases where the called phone is not connected to the same VPN, the application must establish a "call out" link over the last mile from the destination calling phone, i.e., the VPN host closest to the person being called. If the VoIP application is not available 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 to verify that the IP test packet can be properly decoded and understood.

In order for a call to be placed, the call must come from a Layer 7 application running on the caller's phone, i.e., a phone app using the carrier's data plan, and not from the phone's normal dialing function, which means that the phone carrier's SIM card in the phone This is because it is not compatible with VPN tunnels. When a call is initiated, the caller's mobile phone transmits a series of IP packets representing small snippets or "snippets" of sound depending on the communication application. These packets are transmitted from the application on the caller's phone over the network, for example 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 through the VPN tunnel to the end device of the VPN network, which is the destination VPN gateway. In this example, the VPN tunnel does not extend at all to the destination mobile phone, but instead is stopped before reaching the device being called. Beyond the VPN's destination gateway, data is no longer encrypted because the VPN carrier is no longer involved. As data packets leave the VPN tunnel, the VPN host continues to forward the data to a nearby router via the destination device's last mile connection, for example a wired connection, and then by wired connection to local cell phone systems and towers, such as 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 the "call out" feature.

The foregoing example highlights another problem with connections to VPNs across public networks - the last mile link from the VPN host to the person being called is not part of the VPN and therefore does not guarantee security, performance or call QoS. . Specifically, the caller's last mile, including the connection, is entirely open to sniffing and cyber-attacks. Once the call is complete and the caller's cell phone is disconnected, the VPN link must be terminated, whereby VPN Layer 5 coordinates closure of the VPN session and the caller's cell phone is disconnected from the VPN host.

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

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

* Last mile communication between the caller's mobile phone and the VPN gateway is secure only if the caller uses a data communication-based app. If a caller connects to a VPN gateway using a telephony link, i.e. a dial feature, the last mile communication from the caller's mobile phone to the nearest VPN gateway is not secure and is at risk of sniffing and surveillance.

* Calls can be secured end-to-end only if both parties use data communications and not telephony over their relevant last mile links, and only if both parties know to be joining the same VPN prior to initiating the call. It could be the end. This last bullet point highlights the paradox of secure VPN communications - in order for the person being called to join the network, they need to know they are being called before they are called. To let them know they are on a call, they must first be connected and instructed to log in to the VPN before the call begins. Essentially, in order to connect to a secure phone call, they must receive an unsecure phone call. Unsecured phone calls are easily hacked, sniffed, and monitored. Additionally, the metadata of an insecure call exposes who is calling, who is calling, and when the call occurred. Call metadata is very useful in tracking people's activities or profiling them as targets of crime.

Even ignoring security concerns, there is no guarantee that placing calls or sending documents through a VPN will not fail for any of the following reasons, including:

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

* VPN last mile connections from caller to VPN gateway or from VPN gateway to 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, i.e. the "last mile", may be very far away, possibly much further than the distance to the call receiver without a VPN, causing connections to suffer from excessive latency, network instability, It exposes you to numerous opportunities for uncontrolled routing through unknown networks, variable QOS, and man-in-the-middle attacks on unprotected parts of the connection.

* VPN last mile connections from the VPN gateway to the call receiver may not support “call out” connections and packet forwarding or support links to local telcos.

* Local carriers or government censors may block calls or connections into or out of known VPN gateways for national security or compliance reasons.

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

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

Network Comparison - Comparing a communications system that uses public networks to connect to an ad-hoc VPN versus communications provided by an "over-the-top" or OTT provider, most of the components and connections of both communications systems, other than the VPN link itself, are virtually identical. It can be easily seen that it has. Specifically, the caller's last mile, including cell phone WiFi wireless connections, WiFi base stations, wired connections, and routers, represents the same last mile connectivity in both implementations. Similarly, on the other party's last mile, the caller's cell phone, cellular connection, cell tower and tower, landline 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 on the public network is replaced by a server/router with unsecure communication throughout the cloud. The other difference lies in OTT communications, where calls can be made instantly, and 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 connections present unpredictable call QOS, exposure to packet sniffing, and cyberattack risks. Since the servers/routers are managed by different ISPs in different locales, the servers can be interpreted as existing different clouds. For example, the public open networks owned and operated by Google, Yahoo, Amazon, and Microsoft, although all of them are interlinked by the Internet, may be considered different clouds, e.g., the "Amazon Cloud". You can.

A competitive network or less popular topology, peer-to-peer network, or PPN, involves a network comprised of a large number of peers with packet routing managed by the PPN rather than 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 circumventing the controls, costs, and regulations of Internet service providers. When lawsuits were filed over U.S. government regulations over music piracy, Napster's pioneers broke out and invaded early OTT carrier Skype. At that time, Skype's network was converted from traditional OTT to PPN, similar to Napster.

In PPN operation, any 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 within 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 mobile phone uses its PPN connection to call another PPN connected device, such as a mobile phone, such call would follow a circuitous path through any device(s) physically located in the PPN between the two parties. . For example, a call originating from a caller's cell phone is transmitted by WiFi via a local WiFi tower to a nearby desktop, then to another person's laptop, to another desktop, to another desktop, and finally to a local cell phone tower and tower. connected to the destination mobile phone. In this way, all routing was controlled by the PPN, and the Internet was not included in the management of routing. Because it is used by both parties, the PPN software used to connect to the network acts as an application for VoIP-based voice communications.

If one cell phone wants to call a non-PPN device cell phone on the other side of the world, routing may necessarily involve the Internet on some link, especially to transmit packets across oceans or mountain ranges. The first part of the routing at the local geographic location proceeds in a similar way to the previous example, starting from the caller's cell phone and routing through the WiFi base station, desktop, laptop, 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 to the mobile phone through the local cell tower and local cell tower, before continuing to transmit it. return to

If a call crosses the Pacific Ocean, since computers and cell phones cannot carry traffic across oceans, the call must travel all the way to an Internet third-party server/router in a hosted cloud, and then to a third-party server/router within 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 within the destination geographic location through a desktop, which in turn connects to WiFi, to a laptop, and to a base station. Since WiFi does not run the PPN app, the actual packets entering WiFi must travel to the tablet or phone within the WiFi subnet and then return to WiFi before being transmitted over the wired connection onto the phone base station and tower. Finally, calls to the caller's cell phone are connected to the destination cell phone, not the PPN-enabled device. Thereby, the connection constitutes a “call out” for the PPN, since it exits the PPN network. When using this PPN approach, as with a VPN, locating a call involves first registering the calling device with the PPN network by completing a PPN login. Afterwards, the call can be located 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 all devices connected to the PPN regularly update the PPN operator regarding their status, loading and latency. This means that routing of packets can be determined to minimize delay.

The downside to this approach is that packets traverse a network containing many unknown nodes that present potential security threats and also have unpredictable impacts on call delay and call QoS. Therefore, with the exception of Skype, peer-to-peer networks operating at or above Layer 3 are not commonly used in packet-switched communications networks.

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

network Virtual Private VPN Internet OTT Peer-to-Peer PPN node Public/hosted servers public router/server PPN users Node Abilities known infrastructure known infrastructure Mixed, unknown cloud bandwidth Guaranteed unpredictable unpredictable last mile bandwidth Provider dependent Provider dependent PPN dependent waiting time unmanageable unmanageable optimal action network stability unmanageable Unmanageable, redundant optimal action call settings Complex login Not required log in user identity username phone number username VoIP QoS Variable up to good variable variable cloud security Encrypted payload only Unencrypted Unencrypted last mile security Unencrypted Unencrypted Unencrypted Sniffing possible Packet Header (Cloud)
Total packet (last mile) full packet full packet

As shown, the VPN and the Internet constitute a fixed infrastructure, but the nodes of a peer-to-peer network vary depending on who logs in and what device connects to the PPN. Cloud bandwidth, as defined in the context of this table as high-speed, long-distance connectivity of networks, e.g., networks crossing oceans and mountain ranges, is contractually guaranteed only in the case of VPNs and is otherwise unpredictable. While last-mile bandwidth is local to both Internet and VPN providers, PPN depends entirely on who is logged in. Latency, the propagation delay of successively sent IP packets, is unmanageable for OTTs and VPNs. This means that the provider does not control routing in the last mile, but instead relies on local telcos or network providers, while having a limited ability to use best effort to direct traffic between nodes that are online at a given time in a particular geographic location. Because it has. Likewise, for network stability, PPN can reroute traffic to maintain the network, but is entirely dependent on who is logged in. On the other hand, the Internet is inherently redundant and ensures delivery, but not necessarily timeliness. Network stability for an ad hoc VPN depends on the number of nodes authorized to connect to the VPN host. If these nodes go offline, the VPN becomes ineffective.

From a call setup perspective, the internet is always available, PPNs require the additional step of logging into the PPN before making a call, and VPNs can involve complex login procedures. Moreover, most users consider the use of OTT for phone numbers as the main advantage of OTT being ease of use rather than the separate login IDs used by VPNs and PPNs. All three networks listed suffer from variable VoIP QoS and generally lag far behind commercial telephony carriers.

From a security perspective, all three options are bad as the last mile is completely exposed to packet sniffing with readable addresses and payloads. A VPN provides encryption of your cloud connection, but exposes the IP address of the VPN host. Therefore, the network option shown is not considered secure. Therefore, encryption is used by various applications as a layer 6 protocol or as an embedded part of the layer 7 application itself to prevent hacking and cyber attacks.

Over-reliance on encryption - Whether used to encrypt IP packets or set up VPNs, today's network security relies almost entirely on encryption, which also represents a weakness in modern packet-switched-based communications networks. . For example, a lot of research has been done on how to attack RSA encryption. While limiting the prime numbers to large sizes greatly reduces the risk of breaking a decryption D-key code using brute force methods, the polynomial element method has been successfully demonstrated in cracking keys based on smaller prime numbers. It has been done. There are concerns that the evolution of "quantum computing" will ultimately lead to a practical way to destroy RSA-based and other encryption keys in reasonable cyberattack time.

To overcome the previously existing risks of code destruction, new algorithms and "bigger key" encryption methods have emerged, such as the "Advanced Encryption Standard" or AES cipher, adopted by US NIST in 2001. 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 has 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 files are 10, 12, and It's 14 cycles. As a practical matter, AES ciphers can run efficiently and quickly regardless of key size in software or hardware. In cryptography vernacular, AES-based encryption using 256b keys is referred to as AES256 encryption. AES512 encryption using 512b keys can also be used.

While new generations have improved cryptography, creating better encryption methods and breaking them quickly, profit-seeking cybercriminals often focus on targeting encrypted files rather than simply using computing to destroy them. As already described, using packet sniffing and port interrogation, cyber pirates can obtain sensitive information about your conversations, company servers, or even VPN gateways. With cyber profiling, it may be easier to launch a cyber attack against a company's CFO or CEO's personal computers, laptops, and cell phones rather than attacking the network itself. Sending emails to employers that automatically install malware and spyware when they open embedded links completely bypasses firewall security because they enter the network from the "inside" where they are essentially connected to operate.

If data moves across the network without modification, that is, statically, the likelihood of breaking the encryption increases. For example, in the network of Figure 1, the underlying data of packets 790, 792, 794, and 799 does not change as the packets move through the network. Each data packet shown contains a series of data or sounds arranged sequentially by time or page, unchanged from its original order when it was created. If the content of the data packet is text, reading the unencrypted plain text file in the 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, then converting, i.e. "playing", the unencrypted plain text file in the sequence 1A-1B-1C-1D-1E-1F via the corresponding audio codec, which is essentially a software-based D/A converter. Audio file number "1" will appear as the sound for you.

In any case, throughout the invention, each data slot, represented by a fixed size box, contains a defined number of bits, for example 2 bytes (2B) long. 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 is indicated by a number followed by text in the diagram. For example, as shown, the first slot of data packet 790 has content 1A where the number "1" represents designated communication #1 and the text "A" represents the first portion of data of communication #1. Includes. Likewise, the second slot of data packet 790 contains the text "1B" where the number "1" indicates that this is part of the same communication #1 and also the text "B" represents data in communication #1 that sequentially follows 1A. It includes content 1B representing the second part of.

For example, if the same data packet contains virtually contained content “2A”, then the data represents the first packet “A” in a different communication, specifically for communication #2, which is unrelated to communication #1. A data packet containing a homogeneous communication, for example all data for communication #1, is easier to analyze and read than mixing different communications. Data arranged sequentially in the appropriate order makes it easier for a cyber attacker to interpret the nature of the data, whether it is audio, text, graphics, photos, video, executable code, etc.

Moreover, in the illustrated example, since the source and destination IP addresses of the packet remain constant, that is, the packet remains unchanged during transmission over the network in the same form as the incoming or outgoing gateway servers 21A and 21F. Since the underlying data does not change, hackers have a better chance of intercepting data packets and analyzing and opening files or listening to conversations. Relying solely on simple transport and one-dimensional security, i.e., encryption for protection, increases the risk of cyberattacks because the likelihood of success is higher in oversimplified uses of the Internet, such as packet-switched networks.

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, new, innovative, systematic approaches to IP packet routing control are required, encompassing heterogeneous technologies. Manage a global network that supports end-to-end security at the same time. The goals of this unique packet-switched network include the following criteria:

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

2. Ensure security and QoS of “local network or telco” in the last mile of telecommunication network.

3. Ensure security and QoS of the “last link” of the communications 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 in online networks or cloud storage to prevent unauthorized access.

6. Provide security and privacy protection for all nonpublic personal information, including financial, personal, medical, and biometric data and records.

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

8. Provide security, privacy protection, and anonymity where necessary in processing and information exchange, including Machine-to-Machine (M2M), Vehicle-To-Vehicle (V2V), and Vehicle-to-Infrastructure (V2X) communications. .

Among the foregoing objectives, the inventive subject matter included in the present disclosure relates to the second topic listed in item #2, namely “Security and QoS of Local Networks or Telcos in the Last Mile of Telecommunications Networks”. This topic can be considered as secure last mile connectivity without sacrificing real-time communication performance.

Term Definition

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

Anonymous data packet: A data packet that lacks information about its original origin or final destination.

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

Stealth: An encoding process that renders the contents of an SDNP packet or portion thereof unrecognizable using any sequential combination of security operations such as scrambling, segmentation, junk data injection, and encryption. Recovery of concealed data requires execution of reverse order or decoding processes, such as decryption, junk data removal, mixing and unscrambling.

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

Disaggregated Data Storage: The process of fragmenting data files and concealing their 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 "air gapped" servers, i.e., computers that do not have a wired network connection or access.

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

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

Dynamic scrambling/unscrambling: Scrambling and unscrambling that rely on algorithms that change dynamically as a function of conditions, such as when the data packet was created or the region from 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: Mathematical operations used to convert data packets from plaintext to ciphertext.

Fragmented data transfer: Routing of fragmented and mixed data over SDNP networks.

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

Junk data injection (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 inputting a state, such as time, into a key generator that uses a secret algorithm to generate the key. The key is used to select an algorithm to encrypt or decrypt the data in the packet from the selector. Keys can be used to securely pass information about state across public or non-secure lines.

Key exchange server: To prevent any possibility of network operator espionage, public encryption keys are passed to the clients and, optionally, to the server using symmetric key encryption, especially client-managed key management, i.e. end-to-end encryption. A computer server, often third-party hosted and independent of the SDNP network operator, used to deploy to clients based on a computer server.

Last Link: A network connection between a client's device and a first device on the network with which it communicates, 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 WiFi connectivity (e.g. in a cafe), the last link includes a WiFi router connected to a DSL, cable, or fiber network. In cellular networks, the last link includes the radio link between the cellular tower and the mobile phone, which may include 3G or 4G/LTE, for example.

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

Mixing: Combining data packets from different sources, which may contain different data types, to create one longer data packet (or a 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 inserting and deleting and parsing junk data.

Multiple PHY or Multi-PHY: Communication involving alternating transmission of related sequential data packets across multiple physical media, such as 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 in the IP header. For packet routing outside the SDNP network, the IP address used may represent a valid Internet IP address (the address recognized by a DNS server), or may be a network address translator (NAT) operated by the local network provider. (e.g., Comcast assigns its own internal IP addresses for communications within the Comcast cable/fiber network).

Scrambling: The act of changing the order or sequence of data segments in a data packet from its natural order into 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 also include inserting and deleting junk data.

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

SDNP: Acronym for “Secure Dynamic Communications Network and Protocol,” meaning a hyper-secure communications network manufactured in accordance with the present invention.

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

SDNP Management Server: A computer server used to distribute executable code and shared secrets to SDNP servers around the world or in designated regions.

SDNP Bridge Node: An 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 connecting via the last mile, typically a mobile phone, tablet, laptop, desktop or IoT device.

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 through 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: A special identification tag upon command from a signaling server or other computer that performs signaling functions, including encryption/decryption, scrambling/unscrambling, mixing/splitting, tagging, and generating SDNP headers and subheads. Softswitch executable code that processes incoming data packets. The SDNP media node is responsible for identifying incoming data packets with specified tags and then transmitting the newly created data packets to their destination.

SDNP Media Server: A computer server that hosts softswitches that perform the functions of the SDNP Media Node in dual-channel and triple-channel communications and also the operations of the SDNP Signaling Node and SDNP Name Server Node in single-channel communications.

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

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

SDNP Network: A full hyper-secure communications network extending from client to client, including last link and last mile communications, as well as the SDNP Cloud.

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

SDNP Server: A computer server that includes an SDNP Media Server, SDNP Signaling Server, or SDNP Name Server and also hosts applicable softswitch functions to operate as an SDNP node.

SDNP Signaling Node: Initiates a call or communication between parties and instructs the SDNP media how to manage incoming and outgoing data packets, determining all or part of multiple routes to transmit fragmented data based on caller criteria. Executable code that softswitches.

SDNP Signaling or Signaling 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 concealment (or to recover the contents of a concealed packet) using state-dependent security credentials associated with the zone and state in which the packet originated.

Security Settings or Security Credentials: Seeds and keys that are generated by a seed generator or key generator using a secret algorithm with constantly changing input states such as network time, and can thus be transmitted securely 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 generates the seed using a secret algorithm. The seed is used by the selector to select an algorithm for scrambling, encrypting, or splitting the data within the packet. 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 are part of a shared secret and that are used with a seed or key to select a particular algorithm for scrambling, unscrambling, encrypting, decrypting, splitting, or mixing a packet or packets.

Shared Secret: Scrambling/unscrambling, encryption/decryption and mixing, as well as the algorithms used by the seed generator, key generator, zone information and algorithm shuffling processes stored locally on a DMZ server that is not accessible via the SDNP network or the Internet. /Confidential information about SDNP node operation, including tables or selectors for partitioning algorithms.

Single PHY: Communication of related data packets transmitted only over a single physical medium, for example, optical fiber, or Ethernet, or WiFi, or 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 the SDNP network.

Unscrambling: The process of restoring data segments of scrambled data packets to their original order or sequentially. Unscrambling is the inverse of scrambling.

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

Secure Dynamic Communications Network and Protocol (SDNP) Design

To prevent cyberattacks 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, the Open Secure Dynamic Communications Network and Protocol, or SDNP, is It was 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 must not provide information about the packet's origin, where it is traveling, or what is inside it.

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

* Even after they are decrypted, all data packet payloads still contain an unintelligible payload containing a dynamically scrambled mixture of multiple conversations and irrelevant data mixed with junk packet filler. Implementation of such instructions includes a variety of inventive and inventive methods, functions, features and practices, including some or all of the following in various embodiments.

* SDNP uses one or more dedicated clouds containing telco (telecommunication) systems, a soft-switch function realized using proprietary command and control software that is not accessible via the Internet.

* All intra-cloud communications occur using dedicated SDNP packet routing within the proprietary cloud based on SDNP addresses and dynamic ports (i.e. proprietary NAT addresses) rather than DNS-aware IP addresses. SDNP addresses cannot be used or routed on the Internet or outside the SDNP cloud.

* SDNP networks continuously identify and dynamically route all real-time communications over the lowest available latency path.

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

* Routing data included in the data packet 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, that is, the respective source and destination addresses of the client, are not present in the IP packet header, nor are they present in the encrypted payload.

* Command and control-related shared secrets reside in system software installed on a secure DMZ server that is not accessible via the Internet.

* SDNP packet communication consists of three independent channels: the “Name Server” used to identify elements within the SDNP cloud, the “Media Server” used for content and data routing, and the “Signaling” used for packet and call command and control. This can occur through a “server”.

* Routing information, along with key and numeric seeds (as required), are supplied to all participating media servers via independent signaling channels prior to the call or communiqué, but 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 that represents only part of a call, document, text or file, and are dynamically mixed and remixed with other packets containing fragmented data from other sources and different types.

* 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 transmissions are based on enhanced UDP, such as voice and real-time video or It is content-type dependent with streams.

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

* To ensure secure communication with low latency and high QoS, the described “Secure Dynamic Network and Protocol” or SDNP utilizes a unique “Dynamic Mesh” network comprising:

* Dynamic adaptive multipath and meshed routing with minimal latency

* Dynamic packet scrambling

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

* Dynamic intra-node payload encryption across the network or cloud.

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

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

* Dynamic adaptive real-time transmission protocol with data type-specified characteristics and context-specific routing.

* Support for client encrypted payloads with user key management.

* Lightweight audio codec for high QoS in congested networks.

As mentioned above, SDNP communications rely on multipath and meshed communications to dynamically route data packets. In SDNP communications according to the invention, unlike the contrasting 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 caller. but in a fragmented form that dynamically mixes and remixes content appearing from multiple sources and callers, wherein said data aggregates incomplete portions of files of data, content, voice, video and similar data types into junk data fillers. do. An advantage of the described implementation of data fragmentation and transmission is that unencrypted and unscrambled data packets are nearly impossible to interpret because they represent a combination of unrelated data and data types.

By combining fragmented packet mixing and packet scrambling with packet scrambling and dynamic encryption, these hybridized packets of dynamically encrypted, scrambled, and fragmented data generate a shared secret, key, numeric seed, data, packet, and Contains meaningless packets that are completely incomprehensible to any party or observer with no time and state variables used to dynamically repacketize them.

Additionally, the fragmented contents of each packet, and the secret used to create them, are valid for only a few seconds before the packet is reconstructed with new fragments and new security provisions such as modified seeds, keys, algorithms, and ciphers. The limited frequency at which cyber pirates can destroy and open state-dependent SDNP data packets further improves SDNP security, requiring 100,000 processing times per second, a challenge 12 times larger than the time it takes to destroy them. .

The combination of the foregoing methods promotes multidimensional security that far exceeds the security achievable from static encryption. Accordingly, the described secure dynamic communication networks and protocols 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 data segments out of order, rendering information unintelligible and useless. As shown in FIG. 2A, an unscrambled data packet processed through a scrambling operation 924, i.e., a data packet 923, appears as a scrambled data packet 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 numerical seeds based on "states", such as the time when scrambling occurred (920) and a numerical seed (929) generated by a seed generator (921); This can generate the seed 929 using an algorithm that depends on states such as time 920 during scrambling. For example, if each date is converted to a unique number in monotonically ascending order, then every seed 929 is 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 a scrambling algorithm 922. there is. In a data flow diagram, it is convenient to illustrate this packet-scrambling operation and sequence using schematic or symbolic representations, as shown here at symbol 926.

The unscrambling operation depicted in FIG. 2B illustrates the inverse function of the scrambling operation 924, particularly the unscrambling operation 927, where the state or time used to generate the scrambled data packet 925 920 and the corresponding Seed 929 is reused to return unscrambled data, particularly unscrambled data packet 923. Using the same state or time 920 that was used when packet scrambling first occurred, the same scrambling method must 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 reverse functions required to perform “unscrambling”, i.e. Scrambling Algorithm List 922 scrambles data packets and It also contains information needed to unscramble the data packet. List 922 can be renamed the “scrambling/unscrambling” algorithm list 922 because both functions involve the same steps performed in reverse order. However, for clarity, the above table is displayed by function only, not by semi-function.

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

In accordance with the disclosed invention, many algorithms perform a scrambling operation as long as a reversible process, meaning repeating the steps in the opposite order of the original process, returns each data segment to its original and proper location in a given data packet. It can be used to Mathematically, an admissible scrambling algorithm is a reversible algorithm, i.e. the function F(A) has an anti-function F ^{- 1} (A), or alternatively the transformation has a corresponding inverse function, so that F ^-1 [F(A)] = A, which means that a data file, sequence, text string, file, or vector (A) processed by a function (F) is subject to subsequent processing using the inverse function (F ^-1 ). This means restoring the original input (A) that is not damaged in the value or sequence.

An example of this reversible function is illustrated by the static scrambling algorithm shown in Figure 2C, which includes mirroring and phase shifting algorithms. In a mirroring algorithm, a data segment is swapped as a mirror image of another data segment around a line of symmetry defined by the module or “mod” of the mirroring process. In mode-2 mirroring as shown, every two data segments of the original input data packet 930 are swapped, i.e., 1A and 1B are centered between the first and second data segments, and the third and To generate a scrambled output data packet 935 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. The positions are exchanged, such as 1C and 1D, 1E and 1F, etc.

In mode-3 mirroring, the first and third data segments of every three data segments are swapped, while the intermediate packets of each three pair are kept in their original positions. Therefore, to produce a scrambled data packet output 936, data segments 1A, 1C are swapped, while 1B remains in the center of the three pairs, data segments 1D, 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 the 2 ^th , 5 ^th , 8 ^th , ..., (2 + 3n) ^th positions.

In mode-4 mirroring, to generate scrambled output data packets 937 from input data packets 931, first and fourth data segments and second and third data segments of every four data segments are It is swapped. Accordingly, the data segment 1A is swapped with 1D, and the data segment 1B is swapped with 1C. For mode-4 mirroring, the line of symmetry is centered between all four pairs of second and third data segments, for example 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 positions. In mode-m mirroring, the mth data segment of the input data packet 932 is swapped with the first, or ^0th, data segment; The 0 ^th data segment is swapped with the m ^th element, and likewise the n ^th element is swapped with the (mn) ^th data segment to generate a scrambled output data packet 938.

Another scrambling method, also shown in Figure 2C, is frame shifting in which all data segments are shifted left or right by one frame, two frames, or more. For example, in a single frame phase shift, all data segments are shifted by one frame to produce a scrambled output data packet 940, where the first data segment is shifted to a second position; The second data segment is shifted to the third frame. In the example shown, frame 1F, which is the last frame of input data packet 930, 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 to the position already occupied by the data segment 1C, and the fourth frame 1D is a 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 divided into two groups with 1E, 1B, and 1A replacing 1F, with the first frame 1A replacing 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 case of maximum phase shift, the first frame replaces the last, the second frame originally held by 1B becomes the first frame of the output data packet 943, and the second element is shifted to the first position, The third position is shifted to the second position. If one frame is phase shifted beyond the maximum phase shift, the output data appears unchanged from the input. The example shown includes a phase shift where the data is shifted to the right. This algorithm also applies to phase shifts that move to the left but have different results.

The above-described algorithms and similar methods as disclosed are referred to herein as static scrambling algorithms because the scrambling operation occurs at a single time to transform the input data set into a unique output. Moreover, the algorithm already shown does not rely on the value of the data packet to determine how scrambling occurs. As shown in Figure 2D, according to the described invention, parametric scrambling is a table of possible scrambling algorithms, e.g., classification #A, where the scrambling method is based on values derived from data contained within the data packet itself. This means that it is selected from category #B. For example, assume that each data segment can be converted to a number based on calculations of the data contained within the data segment. One way to determine the numeric value of a data segment is to use the same decimal or hexadecimal number as the bit data in the data segment. If a data segment contains multiple terms, you can find the number by adding up the numbers in the data segments. Data segment data is combined with a single number, or "parameter", which is then used to select which scrambling method is used.

In the example shown, the unscrambled data packet 930 is converted in step 950 into a data table 951 containing values for each data segment as parameters. As shown in data segment 1A, the data segment 1A, which is the 0th frame, has a numerical value of 23, and the data segment 1B, which is the first frame, has a numerical value of 125. A single data packet value is extracted at step 952 for the entire data packet 930. In the example shown, sum 953 represents the linear sum of all data segment values from table 951, which parametrically all equal 1002. In step 954, this parametric value, sum 953, is compared to sum 953 over a number of non-overlapping numeric ranges in table 955 to determine what kind of sorting routine should be used; It is compared against a state table, which is a set of predefined states in the software. In this example, the parameter value 1002 is in the range 1000 to 1499, which means that classification #C should be used. Once a sorting routine has been selected, no further parameter values are 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 example shown, 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 moving the 1D data segment three times, that is, moving it to the left by 3 shifts. The first frame contains a data segment 1B that has not changed from its original position, i.e. shifted to zero places. The second frame includes 1E, a data segment shifted to the left by moving it twice from its original position. The same applies to 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 to the right from its original position, i.e. a +2 shift. The fifth frame includes data segment 1A shifted 5 times, or +5, to the right from its original position.

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

Dynamic scrambling utilizes system states, e.g. time, to be able to identify the conditions under which a data packet has been scrambled, so that the same method can be selected to perform the unscrambling operation. In the system shown in Figure 2e, this state is used to generate a disguised numeric seed that is sent to the sender or recipient of the package, which then uses the seed to select a scrambling algorithm from the table. Alternatively, the state itself may be transmitted to the sender or receiver, and the state may be used by a concealed number generator located at the sender or receiver to generate concealed numbers that are used to select a scrambling/unscrambling algorithm. Accordingly, in Figure 2E, a state, e.g., time 920, is used to generate a hidden number 961 using a hidden number generator 960 and to select a scrambling method from a scrambling algorithm list 962. Hidden number generator 960 may also input a hidden number HN 961b directly into scrambling operation 963, where HN may serve as a variable in executing the scrambling operation. Afterwards, a scrambling operation 963 converts the unscrambling data packet 930 into a scrambled data packet 964. As shown in Figure 2F, state 920 can be passed directly to hidden number generator 960, or state 920 can be passed through seed generator 921 to hidden number generator.

The advantage of using a concealed number to select a scrambling algorithm instead of a numeric seed is that the possibility of a cybercriminal regenerating the scrambling table by analyzing the data stream, i.e. by statistically relating repeated sets of scrambled data to their corresponding numeric seeds, The point is to remove . Although the seed may be visible in the data stream and thus exposed to espionage, the Hidden Number Generator and Hidden Number (HN) are based on a shared secret. Hidden Numerals (HNs) therefore do not exist in the data stream or are susceptible to espionage or sniffing, meaning they are not transmitted over the network but are generated locally from a numeric seed. This mathematical operation of the stealth number generator adds an additional layer of security that frustrates hackers because 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 numerical seeds is a confusing analysis because the seeds do not directly select the algorithm, but act in conjunction with it. Determines the final sequence of the scrambled data segment. In a similar manner, to scramble a dynamically scrambled data packet, a seed 929 (or alternatively a state or time 920) is transmitted from the communication node, device or software that initially performs the scrambling to the node or It must be passed to the device.

In accordance with the disclosed invention, the seed generation algorithm 921, the stealth number generator 960, and the list of scrambling algorithms 962 are "shared secrets," stored on a DMZ server (as described below) and shared with the sender of the data packet or It represents information that is unknown to the recipient. The shared secret is pre-set 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 described below, shared secrets are restricted to "zones" so that a hacker who knows one set of stolen secrets cannot access the entire communications network or intercept real-time statements.

In dynamic scrambling, where the scrambling algorithm changes during data packet transmission, in addition to a random shared secret, a seed based on "state" is required to scramble or unscrambling the data. This state on which the seed is based can be time, as long as there is no ambiguity about the state used to generate the seed, and as long as there is some means of telling the next node which state was used to last scramble the data packet. It may contain arbitrary 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 therefore 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 a seed may include a random number generated by a counter and subsequently incremented by a certain number each time a data packet traverses a communication node, with each count corresponding to a particular scrambling algorithm. represents.

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

In another embodiment of the described counter-based method for selecting a scrambling algorithm, a random number is generated to select an initial scrambling algorithm, and this number is used by all communication nodes to transmit the designated data packet as a "shared secret". is passed on. For example, counts starting with 0 are also embedded in data packets in the header or parts of the data packet that are reserved for command and control and are 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 finally 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 back in the header of the data packet or any part of the data packet that is reserved for commands and control and not exposed to scrambling, overwriting the previous count. Random numbers that function 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 communicating node to scramble the incoming packet. In this method, 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, a stealth number can be used to communicate the status of the packet and what algorithm was used to scramble it. A stealth number is a confidential number, i.e. a shared secret that typically involves a numeric algorithm taken together to create a "stealth number" that is never communicated between communication nodes and is therefore unsniffable or undetectable by any man-in-the-middle attacker or cyber pirate. Combines time-varying states or seeds together. The hidden number is used to select the scrambling algorithm used. The state or seed is meaningless without knowing the algorithm used to calculate the hidden numbers, since the shared secret algorithm may be stored behind a firewall inaccessible over the network or the Internet, thus reducing the amount of monitoring of network traffic. This is because it does not expose the pattern. To complicate matters further, the location of the 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, includes a long number with only a portion of the number representing the seed. For example, if the 3rd to 8th numbers represent the seed, the actual seed is not the entire number but the bold number 27482567822552213, that is, the seed is 48256. This seed is combined with a shared secret algorithm to generate a cloaking number, which is used to select a scrambling algorithm that changes dynamically throughout the network.

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

As explained, data traversing a network, even if scrambled, may be referred to as “cleartext” because the actual data is present in the data packets, i.e., the packets are not encrypted with ciphertext. In contrast, in ciphertext, the text string containing the original data, whether scrambled or not, is translated into a series of meaningless 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 “Encryption” below.

To change the order of data packets during transmission over a network, packet "rescrambling" is required, as shown in Figure 3. The process of packet rescrambling returns a scrambled data packet to its unscrambled state with a new scrambling algorithm before scrambling it again. Accordingly, as used herein, the term “rescrambling” refers to 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 that can occur by scrambling previously scrambled packages and losing sequence tracks needed to restore the original data. As shown, once initially scrambled by the packet scrambling operation 926, the scrambled data packet 1008 is first subjected to an unscrambling operation 928 that uses the reverse operation of the scrambling algorithm used to scramble the data. Unscrambling, and then “re-scrambling” the data packets by scrambling them with a new scrambling operation 926 that uses a different scrambling algorithm than the one used in the previous scrambling operation 926. The resulting re-scrambled data packet 1009 is different from the previous scrambled data packet 1008. The rescrambling operation 1017 includes successive applications of unscrambling followed by scrambling, referred to herein as “US rescrambling.” 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 function 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 the interpretation of unscrambled data meaningless, realigning sound into unrecognizable noise, realigning video into video snow, realigning text, and recovering. Scramble unreadable code. On its own, 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, cyber attacks, cyber pirates, and man-in-the-middle attacks.

Packet Encryption - 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 encryption. As already noted, encryption, from the Greek meaning "concealment, concealment, obscurity", is the conversion of plain information or data, usually referred to as "plaintext", into "ciphertext" containing an incomprehensible format that cannot be read without secret knowledge. It represents means. In modern communications, this secret knowledge typically involves sharing one or more "keys" that are used to encrypt and decrypt data. The key typically contains pseudo-random numbers generated by an algorithm. Many articles and texts today include “Cryptography” by Neal Stephenson ⓒ 1999, “The Code Book: The Secret Science from Ancient Egypt to Quantum Cryptography” by Simon Singh ⓒ 1999, Niels It can be used to discuss the pros and cons of various encryption techniques, such as "Practical Encryption" by Ferguson) ⓒ 2013 and "Deciphering: The Study of Ciphers and Their Solutions", first published in 1939.

Although the concept of encryption or ciphers is old and well known to those skilled in the art, the application of encryption in the disclosed secure dynamic communications networks and protocols is unique, and is embedded end-to-end in the network architecture itself, independent of any client's own encryption. Facilitates both encryption and single-hop node-to-node dynamic encryption. SDNP communication consists of basic rules that, given enough time, any statically encrypted file or message regardless of the encrypted ciphertext can eventually be destroyed and its information stolen. Although this assumption may be incorrect in practice, there is no need to prove or disprove the proposition because the opposite case, i.e., waiting for the specified encryption method to fail, may result in unacceptable and irreversible consequential damage.

Instead, SDNP communications are based on the premise that all encrypted files have a limited “shelf life,” meaning that encrypted data is only secure for a limited period of time and secret data must be dynamically re-encrypted at regular intervals. It also metaphorically means that it would ideally occur much more frequently than the best estimate of the time required to crack the encryption with a state-of-the-art computer. For example, if it is estimated by cryptographers that the server farm facing the crypto engine can break a given cipher within a year, then in SDNP communication data packets will be re-encrypted every second or even every 100 ms, The power of the best technology is shorter than what can crack it. SDNP encryption is therefore necessarily dynamic, i.e. time-varying, and also spatially, i.e. depending on the location of the communicating nodes in a packet-switched network or geographical location. Accordingly, as used herein, the terms “re-encryption” or “re-encryption” refer to decrypting a data packet and then re-encrypting it, typically with a different encryption algorithm or method.

Therefore, SDNP encryption converts data from unencrypted plaintext to ciphertext repeatedly and frequently, making the information unintelligible 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 an entirely different encryption key or cipher, and also requires an entirely new effort to crack that encryption. By limiting the overall content of each uniquely encrypted data packet, the potential damage from unauthorized access is mitigated because the exposed data packets themselves are too small to contain data files that may not be meaningful or useful to cyber pirates. Because. Moreover, by combining dynamic encryption with the SDNP scrambling method described above, communication security is greatly improved. Even in its unencrypted form, intercepted data files contain only small snippets of data, voice or video scrambled into meaningless and incomprehensible sequences of data segments.

To avoid validity period security issues, SDNP encryption is dynamic and state-dependent. As shown in FIG. 4A, an unencrypted data packet containing plaintext 930 processed through encryption operation 1020 appears as an encrypted data packet containing ciphertext 1024 or 1025. In the case of ciphertext 1024, the entire data packet of plaintext 930 is encrypted, and data segments 1A to 1F are treated as a single data file. In the case of ciphertext 1025, each data segment 1A to 1F is encrypted individually and unambiguously and is not merged with other data segments. The first data segment 1A is encrypted with a corresponding first ciphertext data segment, shown for example purposes by a long text string, not shown, starting with 7 $ or a text string containing numbers. Likewise, the second plaintext data segment 1B is encrypted with a second ciphertext ciphertext data segment comprising a long text string shown for exemplary purposes beginning with *^. Text 7 $ and *^ are meant to indicate the beginning of a text string of meaningless symbols, numbers and alphanumeric characters, and do not limit or impose anything on the data specified in the plaintext source or in the length of the text string to be encrypted.

Encryption operation 1020 may use any available algorithm, encryption, or encryption method. While the algorithm may represent a static equation, in one embodiment the cryptographic operation is performed using a cryptographic generator 1021 to generate dynamic variables or "states" such as time 920 and an "E key" 1022 when encryption occurs. ) is used, 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 numeric seed to generate an encryption key that cannot be recreated even if an encryption algorithm is discovered. Time 920 or other “state” may be used to select a specified algorithm from an encryption algorithm list 1023, which is a list of available encryption algorithms. In the data flow diagram, it is convenient to illustrate this packet encryption operation and sequence using a diagrammatic or symbolic representation, as depicted by the symbol shown for encryption operation 1026. Throughout the present invention, a padlock 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, e.g. 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 the encryption operation 1020, specifically the decryption operation 1031, where a decryption key or “D-key” generated by the 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 to produce unencrypted data containing the original plaintext data packet 990, i.e. the file. It is reused for decryption. 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 packet encryption first occurred. Although the encryption algorithm list 1023 refers to the term “encryption,” the same algorithm table is used to identify and select the functions required to perform “decryption,” i.e., the encryption algorithm list 1023 is used to encrypt and decrypt data packets. Includes necessary information. Since both functions involve the same steps performed in reverse order, table 1023 may be renamed the “Encryption/Decryption” algorithm table 1023. However, for clarity, the table is labeled by function only and not by semi-function.

If the encryption algorithm selected to perform the decryption operation 1031 does not match the inverse of the original algorithm used in the packet encryption operation 1020, or the time or state 920 does not match the time at which the 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 will not recover the original unencrypted data 990, nor will the packet data will be lost. In data flow diagrams, it is convenient to illustrate this packet decryption operation and sequence using schematic or symbolic representations, as shown by the symbol shown for decryption operation 1032.

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

Therefore, even if a cyber pirate has enough computer power to break a strong encryption method, they lack any information embedded in the SDNP network as a private or shared secret needed to perform the decryption operation, and they can do so in a fraction of a second before the encryption changes. The encryption must be cracked. Additionally, 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 makes data theft meaningful from any given data packet both challenging and precluding cyber pirates.

The application of dynamic encryption and decryption of data packets within an SDNP network is described in the aforementioned US application Ser. No. 14/803,869, entitled “Secure Dynamic Communication Network and Protocol.” The application of data packet ciphertext in last mile communications will be described in more detail in this disclosure.

To intercept an entire document, video stream, or voice conversation and reconstruct a coherent data sequence, a cyberattack would have to crack and decrypt not just one, but thousands of consecutive SDNP packets in succession. The daunting challenge of sequential hacking of a series of SDNP packets is further exacerbated by combining the already described methods of scrambling the data packets with dynamic encryption. As shown in Figure 5, generation of the encrypted scrambled data packet 1024 involves first converting the unscrambled plaintext data packet 990 into a scrambled plaintext data packet 1008 and then converting the ciphertext of the scrambled data packet to To convert to 1024, it involves a sequential combination of a scrambling operation 926 and an encryption operation 1026. To return an encrypted scrambled package, first by a decryption operation 1032 to restore the scrambled plaintext data packet 1035 and then by an unscrambling operation 928 to restore the next unscrambled plaintext data packet 990. The inverse functions must be applied in reverse order.

As shown, scrambling and encryption represent complementary techniques in achieving secure communications. Unencrypted, scrambled data traversing a network is referred to as “cleartext” because the actual data is present in the data packets, i.e., the packets are not encrypted with ciphertext. An encrypted data packet or ciphertext contains a scrambled or unscrambled text string that has been converted into a series of meaningless nonsense text using an encryption key and cannot be restored to its original plaintext form without a corresponding decryption key. Depending on the algorithm used, the encryption and decryption keys may include identical keys or distinct keys that are mathematically related by predefined mathematical relationships. Scrambling and encryption therefore represent complementary techniques in achieving secure communications according to the invention described for SDNP communications.

The two methods, scrambling and encryption, operate independently even when used in combination, except that the sequence used to restore the original data packet from the encrypted scrambled data packet must occur in the reverse order used to generate it. can be considered. For example, if data packet 990 is first scrambled using scrambling operation 926 and then encrypted using encryption operation 1026, then to restore the original data packet, the encrypted scrambled data packet 1024 ) must first be decrypted using the decrypt operation 1032 and then unscrambled using the unscrambling operation 928. Mathematically, if a scrambling operation (F) scrambles a series of bit strings or text strings into an equivalent scrambled version and an unscrambling operation (F ^-1 ) cancels the scrambling, then F ^-1 [F(A)] = A Similarly, if the encryption operation (G) encrypts the plaintext string into the equivalent ciphertext and the decryption operation (G ^-1 ) cancels the encryption, then G ^-1 [G(A)] = A, and then , the sequential operations of scrambling and then encryption and decryption and unscrambling in combination restore the unscrambled plaintext data packet, which is the original argument (A). Therefore, F ^-1 {G ^-1 [G(F(A))]} = A, because the sequence occurs in reverse order, especially [G ^-1 ] encrypted scrambled packet [G(F(A) )] restores the scrambled plaintext data packet F(A). The subsequent unscrambling operation [F(A)] of the scrambled plaintext packet F(A) restores the original data packet A .

If the provided linear method is used, the sequence is reversible. For example, if a data packet is first encrypted and then scrambled, then to restore the original data packet, the scrambled ciphertext must first be unscrambled and 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 restore 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 has been 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 may be performed in any order, but during network transmission, encryption and decryption occur more frequently than scrambling, and thus are reversed as shown in Figure 5. Rather, encryption should occur only after scrambling and decryption occur before unscrambling. For convenience, we have defined the combination of an encryption operation 1026 followed by a packet scrambling operation 926 as a scrambled packet encryption operation 1041, and vice versa, a packet unscrambling operation 928 followed by a decryption operation ( The combination of 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 of improving security in any implementation that uses static scrambling encryption is to include changes in the state, seed, and/or key at the time each data packet enters the communication network (t ₁ ), thereby This is to ensure that each data packet is exposed to different scrambling and/or encryption methods.

However, dynamically changing the encryption or scrambling of data packets, or both, as packets traverse the network on time is a more powerful alternative. In order to implement a fully dynamic version of SDNP communication by facilitating the necessary data processing, each packet is "re-scrambled" (i.e., unscrambled and scrambled) as it passes through each communication node in a packet-switched communication network. There is a need to combine the previously defined processes to re-encrypt (i.e. decrypt and then encrypt). As used herein, the terms “re-packeting” or “re-encryption” sometimes refer to a combination of “re-scrambling” and “re-encryption,” depending on whether it is initially decrypted before being unscrambled or unscrambled before being decrypted. It will be used to In either 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, it must be performed at the current node. It must first be decrypted and then unscrambled. Typically, packets will be scrambled when leaving the current node and then encrypted.

A “repacket” operation at a communication node is depicted in Figure 6, where an incoming ciphertext data packet 1040 is first decrypted by a decryption operation 1032 and then into an unscrambled packet containing the contents of the original packet. The plaintext data packet 990 is unscrambled by an unscrambling operation 928 to recover it. If any information within a packet must be inspected, parsed, split, or redirected, an unscrambled plaintext file is the best format to perform these operations. Plaintext data packet 990 is then scrambled again using a scrambling operation 926 followed by new encryption performed by encryption operation 1026 to produce a new scrambled ciphertext data packet 1043. . Since the repacketing operation of an incoming scrambled ciphertext data packet 1040 occurs sequentially by decryption, unscrambling, scrambling and encryption, the abbreviation DUSE repacket operation 1045 is used herein to denote the technique described in accordance with the present invention. It is used here for. In a dynamic secure network, the state or time used to perform the decryption operation 1032 and the unscrambling operation 928, the decryption key, and any seed 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 re-packeting of data packets within an SDNP network is described in the aforementioned US application Ser. No. 14/803,869, entitled “Secure Dynamic Communication Network and Protocol.” The application of data packet repacketing in last mile communications will be described in more detail in this disclosure.

Packet Mixing and Splitting - Other key elements of the secure dynamic communications networks and protocols described herein include splitting data packets into sub-packets, directing these sub-packets into multiple paths, and It is its ability to mix and recombine to form complete data packets. The process of packet segmentation is depicted 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. It is split using the split operation 1051. Similar to junk DNA present in the human genome, junk data segments are inserted by a junk operation 1053 to extend or control the length of a data packet, or to remove them 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 inserted 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 comprised of completely meaningless data (bits). These junk bits can be introduced within the stream of data packets confusing the actual data in a sea of meaningless bits.

The purpose of the parsing operation 1052 is to split the data packet 1054 into smaller data packets, e.g., data sub-packets 1055, 1056, to process each component. Splitting the data packet 1054 into smaller fragments can be used to support multi-path transmission, i.e. transmitting data packets over multiple and different paths, and using different encryption methods to form unique components of the sub-packets. It offers unique advantages, such as facilitating advanced encryption.

The segmentation operation can use any algorithm, numeric method, or parsing method. The algorithm may represent a static equation, or a dynamic equation, such as the time when an incoming input data packet 1054 is first formed by many sub-packets 920 and a numeric seed 929 generated by a seed generator 921. It may contain a variable or numeric seed or "state", which may also depend on the state, such as the 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 every seed 929 would be unique. Time 920 and seed 929 may be used to identify a specified algorithm selected from the list of available methods, i.e., algorithm 1050. Packet splitting or unmixing involves the process of mixing, using the same algorithm executed in the exact reverse sequence used to generate the specified packet. Ultimately all actions used are undone, but not necessarily in one step. For example, a scrambled encrypted data packet may be decrypted but remain scrambled. When processed by the segmentation operation 1051, the unsegmented incoming data packet 1054 is converted into multiple data packets, e.g. Packets 1055 and 1056 are split. In the data flow diagram, these packet splitting operations include parsing 1052 and junking operations 1053 using schematic or symbolic representations, as shown here by the symbols shown for splitting operations 1057. It is convenient to explain (1051) as

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

The reverse function, packet-mixing operation 1060, shown in FIG. 7B, combines multiple packets 1055, 1056 together to form mixed packet 1054. Like packet splitting, the packet mixing operation can use any algorithm, numerical method, or mixing method. The algorithm may represent a static equation, or may include dynamic variables such as time 920 or numerical seeds or "states" used to specify the conditions under which incoming data packets 1055, 1056 will be mixed. . The mixing operation used to generate the data packet may utilize a numeric seed 929 generated by a seed generator 921 that may depend on a state such as time 920. Time 920 and seed 929 may be used to identify a specified mixing algorithm selected from a list of available mixing methods, i.e., mixing algorithm 1050. In data flow diagrams, 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 a number of possible mixing methods including concatenation, interleaving or algorithmic methods. Upon concatenation, a sequence of data segments from data packet 1056 is added to the end of data packet 1055, creating mixed packet 1054. In interleaving, the data segments of data packets 1055, 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 example shown, the algorithm involving interleaved reflection symmetry intersects data segments in the order 1A, 2A, 1B, 2B, 1C, 2C in the first half of the mixed packet 1066, and in the opposite order in the second half, That is, they intersect in the following order: 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 Ser. No. 14/803,869, entitled “Secure Dynamic Communication Network and Protocol.” Figure 9a schematically shows the SDNP functional elements including the functions and their corresponding inverse operations, i.e. the inverse functions as well as the dynamic components of the corresponding functions, i.e. the state or time of each function when executed on a data packet. SDNP functionality includes scrambling operations including packet scrambling (926) and its counterpart packet unscrambling (928); Fragmentation operations, including segmentation (1057) and their dysfunctional mixtures (1061), encryption operations, including encryption (1026) and decryption (1032), along with deception operations, including junk insertion (1053) and junk removal (1053B). Includes. All of these operations occur specifically depending on time or state variables 920.

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

SDNP last mile security operations are also symmetric and reversible across the last mile, which is implemented on outbound data packets within the client's device when using local security credentials such as keys, seeds, and shared secrets specific to a particular last mile. This means that an operation is undone in the SDNP gateway, usually by performing the inverse function, i.e. the mathematical inverse, or all the functional operations originally performed by the client's device but in the opposite sequence. Therefore, the SDNP gateway can restore the original content in preparation for routing through the SDNP cloud. Similarly, to inject data packets into the client's device using zone-specific security credentials for the last mile, the SDNP last mile security operation executing on the client device is processed by the SDNP gateway by executing the reverse sequence of functions. Undoes 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 is specific to a particular last mile; State-dependent conditions, such as location and time, are used. By being localized, data packet preparation conducted in different areas and on different last mile connections never have the same coding or use the same security credentials. Additionally, these last mile security credentials are always different from those used in the SDNP cloud. Additionally, dynamically, the states used to generate data packets are constantly changing, further confusing the actual security process performed on each data packet and making no two data packets similar.

The algorithmic application of dynamic scrambling, dynamic fragmentation, dynamic deception, and dynamic encryption made in the present invention by the unique combinatorial application of directional symmetric reversible dynamic localized security operations specific to each last mile communication: It ensures hypersecure communications that cannot be achieved through the use of simple static encryption methods. The comprehensive application of dynamic methods, effective for a duration of only tens of milliseconds, not only makes interpretation nearly impossible, but also does not give hackers time to decrypt or interpret data packets before they arrive. In practice, SDNP last mile security operations may be implemented using software, firmware, hardware, dedicated security ICs, or any combination thereof.

Although countless combinatorial sequences are possible, one example of SDNP last mile security operation, particularly for serial SDNP payloads used in single-path last mile communications, is shown in Figure 9b, where the client's device has a single Communicates with SDNP gateway. Such a process involves two directed sequences of operations, one for outgoing data packets and the other for incoming data packets. In the case of an outgoing data packet, shown in the upper half of the figure, the “data to be transmitted” is first scrambled using a packet-scrambling operation 926, followed by deception by insertion of junk data 1053A. In some cases, the entire packet may contain entirely junk data, further confusing data mining attempts by hackers.

These packets are then split into multiple fragments by a segmentation operation 1057 using a parsing operation 1052 and transmitted separately in an encryption operation 1026. Each fragment is then encrypted using a common or separate encryption key, and the resulting ciphertext is arranged into a serial SDNP payload, shown as data packet 1199A. Then, in preparation for communication on the last link and last mile, the packet is formatted as an IP data packet, i.e. “IP packet ready”. All actions performed are dynamic and occur at specific times or in specific states 920A during the execution of the security process.

In the case of the received data packet shown in the lower half of the figure, the received data from the last link containing the serial SDNP payload 1199B, i.e. from the “IP packet recognition”, is first decoded to recover the actual data stream. It is decoded piecemeal or entirely by operation 1032 and subsequent mixing operation 1061. The data packet is then dejunked, i.e., the junk data is removed from the data packet, using a dejunk operation 1053B and a subsequent packet unscrambling operation 928 to restore the “received data.” All operations performed on an incoming data packet utilize the state 920B, which contains information about a specific time or having a specific state 920B, that the SDNP gateway used when generating the data packet, i.e., at the time of the packet's birth. shall. This state information may be transmitted by the signaling server over a different communication or may be accompanied within the received data packet as plaintext or alternatively as static ciphertext, i.e. ciphertext with a decryption key already known by the SDNP last mile security operation. You can. However, the details regarding state 920B may not be decryptable using a key that requires state information contained within state 920B, or the code would otherwise be unable to open and use its own security credentials.

Another example of SDNP last mile security operation, particularly for parallel SDNP payloads used in multi-path last mile communications, is shown in Figure 9C, where a client's device communicates with multiple SDNP gateways. Like its single-path counterpart described above, such a process involves two directed sequences of operations, one for outgoing data packets and the other for incoming data packets. In the case of an outgoing data packet, shown in the upper half of the figure, the “data to be transmitted” is first scrambled using a packet-scrambling operation 926, followed by deception by insertion of junk data 1053C. In some cases, the entire packet may contain entirely junk data, further confusing data theft attempts by hackers.

These packets are then split into multiple sub-packets by a segmentation operation 1057 using a parsing operation 1052 and transmitted separately in an encryption operation 1026. Each fragment is then encrypted using a common or separate 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 on the last link and last mile, the packet is formatted as separate and delimited IP data packets, i.e. “IP packet preparation”. All actions performed are dynamic and occur at specific times or in specific states 920C during the execution of the security process.

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 the "IP packet recognition", is first transmitted to the actual data stream. is decrypted in a piecemeal manner by a decoding operation 1032 and a subsequent mixing operation 1061 to restore . The data packets are then dejunked, i.e., the junk data is removed from the data packets, using a dejunk operation 1053D and a subsequent packet unscrambling operation 928 to restore the “received data.” All operations performed on an incoming data packet use a state 920D that the SDNP gateway used when generating the data packet, i.e., containing information about a specific time or having a specific state 920D at the time of the packet's birth. shall. This state information may be transmitted by the signaling server over a different communication or may be accompanied within the received data packet as plaintext or alternatively as static ciphertext, i.e. ciphertext with a decryption key already known by the SDNP last mile security operation. You can.

SDNP last mile security operations do not require the use of the same algorithm or method on both incoming and outgoing data packets. As illustrated in Figure 9D, outgoing data packets utilize SDNP last mile security operation 1190A, while incoming data packets utilize 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, the sound 1198A converted into an electrical signal by the microphone 1180 and the 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 the file between the source and destination addresses.

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

In the reverse operation, shown in the lower half of the figure, the received data from the last link received by the client PHY 1192B is passed to the IP packet recognition operation 1191B, which either accepts the received data as a valid message or as an 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 the client device and to IP packet recognition operation 1191B.

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

IP packet recognition operation 1191B passes the valid data packet to SDNP last mile security operation 1190B, which in turn contains the actual content of the data packet - a serially arranged mix of video, audio, text, and data files. Perform all necessary operations to reconstruct data -. This is followed by a content demultiplexer 1193, a demultiplexer that undoes the mixing operation used in generating the data packets, e.g., sorting the serial data file generated by the mixer operation 1184 performed on another caller's phone. It is used to separate different file types. The output of content demultiplexing 1193 includes text shown displayed within messenger window 1196, data file 1179A, and real-time data sent to audio video codec 1182B. The audio video codec 1182B converts the digital presentation layer data into a live video image 1195 or into sound 1198B through the speaker 1194.

For last mile data transmission, the data must be embedded or wrapped in a multi-overlapping arrangement shown in Figure 9E, similar to the traditional Russian nesting 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 the MAC header 431 and MAC footer 433 results in a MAC “frame”, such as an electrical signal, light, radio waves, or microwaves. Equivalent to the physical layer 490, also known as PHY layer 1 content, which contains physical media.

In SDNP routing, MAC header 431 in layer 2 describes the MAC connection for the last link, i.e., the connection between the client device and the first device within the last mile link. By using the source and destination addresses of the client device and SDNP gateway, header 434 in layer 3 specifies the end point of routing over the last mile. However, because the last mile is not part of the SDNP cloud, the exact path taken by data packets over the last mile cannot be explicitly described or controlled. In SDNP last mile communications, the transport header 436 in layer 4 is used for the SDNP real-time payload, and also the ad hoc assigned SDNP port address used in each packet - dynamically changing to prevent port interrogation cyber-attack strategies. Specifies the address -.

The SDNP payload 438, which is the payload of a last mile IP packet, is an SDNP preamble 1198 containing zone information, a key, and a seed, and the SDNP data, which is a serial string of multiple segments of independently encrypted ciphertext. Includes field 1199A. The decrypted form of the ciphertext includes plaintext files 1197A, 1997B, and 1197C, each with 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 role of the SDNP preamble and header varies depending on the command and control method used. In 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. Accordingly, instructions are communicated to both devices using command and control data packets with TCP transport, prior to transmitting any media data packets. Therefore, the minimum data required for last mile communication between the client and the SDNP gateway is a tag or address used to identify the received packet. In some cases, for example if the signaling server cannot be reached, 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 illustrates one example format used to convey SDNP information within SDNP payload 438. The data packet includes 1 to 8 data field headers 1178X with an SDNP preamble 1198 and its corresponding data field “Data Each data field, such as "Data 1 field", "Data 2 field", etc., is preceded by its corresponding header (Hdr 1, Hdr 2, etc.), and contains a communique containing voice, text, video, photo, movie, file, etc. It involves 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. 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 include only the Hdr 1 and Data 1 fields. If the maximum of 8 fields is selected, i.e. field # = 1111 binary, 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, etc., 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). The 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 For practical reasons related to compatibility with Ethernet, the maximum data packet length for any one field is preferably limited to 1500B or 05DC hexadecimal, and the total length of all data fields is a jumbo packet size of 9000B or 2328 hexadecimal. It must not be exceeded. The specified length of each data field can be changed independently. For example, L Fld 8 = 0000 A field length of 0 in hexadecimal results in removal of the corresponding data 8 field, but does not remove the corresponding header (Hdr 8). Headers are removed only by the 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 and merged with junk data for deception purposes. The size of the data field can vary independently. Data fields 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 data field having its own specific header.

The SDNP packet format can be applied for end-to-end transmission across the entire SDNP network, including across multiple clouds and zones, such as in the 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. Because this format involves minimal data overhead, the SDNP data packet format can be equally applied for large payloads or for time-critical real-time communications. The packet format is for two-way data flow, i.e., from the last mile to the SDNP gateway and across the SDNP cloud, or conversely, out of the SDNP gateway for transmission across the last mile to the destination client device and into the cloud. It can be applied to transmit 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 Figure 9E. At the time a media node prepares a packet for transmission to the next media node on its path, each packet is loaded with its source and destination addresses and, in triple-channel communication, the SDNP or IP address of the packet's destination is the outgoing packet. Prior to preparation, it is delivered from the signaling server to the media node as a command and control (C&C) packet. In general, the signaling server may transmit C&C instructions to all nodes in the communication path, including both originating (caller) and destination (called party) devices. In cases where only single channel communication is available, for example on links with long propagation delays, the signaling server cannot forewarn the media nodes of the incoming packets or what to do with them. In such cases, 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 the incoming packet using data fields included within the incoming SDNP packet that include security credentials as well as routing and state information.

Payload 438 consists of two parts: a readable part containing a preamble 1198, and a non-readable part 1199a containing data in a “stealth form”. The contents of these packets may utilize any number of hiding techniques to hide the contents, such as encryption, scrambling, and possibly including junk data. The hiding method must be undone to extract useful content (1197a, 1997b and 1197c). These packets contain the destination address of future outgoing packets. The address only exists in uncloaked or decrypted form for only a brief moment before the next packet can be prepared and encrypted.

As explained, the SDNP preamble 1198 contains information related to the entire packet. In addition to the data field specifications, Figure 9F shows the SDNP preamble 1198, which also includes the SDNP zone from which the SDNP packet was generated, 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. Seeds and keys may be used as the exclusive means of conveying the security credentials necessary to open and read data fields, or may be used by a client's device from a network of signaling servers, command and control computers that are not included in the accompanying communiqué content within the media packet. and command and control packets sent to the SDNP gateway.

Seeds and keys can be transmitted securely publicly, i.e. in non-encrypted form, since the data does not contain the information necessary for its use - they only contain part of the security credentials. As other parts of the security credentials, lost fragments may have already been transmitted within other data packets, or may contain shared secrets, lookup tables, and code of the algorithm that are not carried over the network and are not part of the message. The encryption key may be a symmetric key, where both the sender and the recipient may hold the key, or they may hold a 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 restricted to a specific security zone, e.g. U1, are dynamic, and are limited to a specific time or state where they expire if not used within a specific time. For example, because the signaling server independently instructs the SDNP device regarding security operations, if the seed and key data fields are not used as security credentials, these fields may be filled with numeric values that falsely appear to be encryption keys, allowing cyber-attackers to This can mislead you into wasting time analyzing your security keys.

In last mile communications, intermediate routers between the client's device and the SDNP gateway do not process, interpret, or open transmitted data packets, as they are not part of the SDNP network and cannot query or interpret the SDNP packet data contained therein. Because it doesn't have the ability. Instead, all security operations are performed exclusively at two end points, the SDNP Client and the SDNP Gateway, since only these devices operate as SDNP communication nodes. Because each end point dynamically executes the SDNP protocol, last mile communications are hypersecure over the entire last mile. If the other calling party also runs SDNP software, the second party's last mile is also secured by the SDNP method described above, and hypersecure communication is "end-to-end" - from one caller to the other. Up to this point - guaranteed.

However, if the end device is not an SDNP client, the router closest to the caller, that is, the last link router, can be enabled with SDNP firmware, and the last link, even if it is not SDNP-based, is implemented by the SDNP-based router. Can be reasonably secured from special functions. These alternative last link security methods will be described in more detail in subsequent sections of this disclosure and will not be described in more detail in these sections. The methods described can be applied to last link communications security, but are not sufficient to protect other parts of the last mile.

Referring again to Figure 9F, each and every SDNP data field is accompanied by an SDNP data field header 1178X that contains information that is specifically applicable to the associated data field but is not useful for other data fields. Specifically, in the disclosed embodiment, each header includes: what type of data is contained in the associated data field, a destination address field used to identify the specific data field and its destination, and a forward section from one zone to another. Includes a data type field that describes the urgency and conveyed information, as well as the field sections 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 separated payloads, which may 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 element necessarily carried by last mile data packets is an "address field" or tag necessary to identify the data packet. The field referred to as the destination address of the SDNP payload (abbreviated as “Dest Addr” in the figures) may contain any unique identifier sufficient to distinguish the identity of one data field from another. The purpose is similar to the function of barcodes used to tag and track bags at the airport or boxes loaded by carriers. Address types can include, for example, numeric tags, SDNP addresses, IPv4 or IPv6 addresses, NAT addresses, or even POTS regular phone numbers, as long as the identifiers are specific enough to prevent collisions in the identification of data packets. there is. 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 an actual 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 examined for an identifying destination address. Before the data header can be inspected, the data packet must be decrypted or processed to undo the concealment method used in generating the packet. In the case of dual-channel or triple-channel communication, as shown in Figure 9g, signaling server 1603 notifies the SDNP gateway in advance of the planned arrival of data packets and their corresponding identification markings and security credentials. Accordingly, when the SDNP gateway receives a data packet 438A containing a last mile communication transmitted from an SDNP client, the gateway converts the SDNP payload from the ciphertext into a plaintext data packet 438B. Perform security operation 1190D. Security operations describe the processing of modifying outgoing data packets to conceal 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 insertions, and splitting to undo splitting. It is used to restore the content by undoing the concealment operation performed before the transmission, including mixing to restore the content. This process is carried out depending on the state and zone of the data packet at the time the data packet was created. For outgoing data packets, security operations include concealing the contents of the data packet before transmission by performing encryption, scrambling, junk insertion, and packet splitting depending on the state and zone when the data packet is generated. The unencrypted seed and key data fields in data packet 438A can be ignored or optionally used with signaling server information to decrypt the ciphertext. The resulting operation reveals Data Field 1 and its associated data field header 117D, denoted Hdr 1, containing the data field's destination address, data type, urgency and delivery information. In such cases, the destination address is not a routing address but just an SDNP home, i.e. the tag used to identify the packet is part of a specific conversation.

If a particular data field is determined to contain an identified destination address, e.g., an SDNP zip code, that matches an indication from signaling server 1603, the data field is extracted and optionally processed by blender 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 the destination. A new data packet destined for the cloud includes an SDNP header 434Z, which includes the destination and data content of the new packet, which is the SDNP payload 435Z. Destination supplied to the gateway media node by signaling server 1603 as an IP address or SDNP address may include other SDNP servers operating as SDNP cloud nodes, or may involve last mile communication to other SDNP clients. In the case of such triple-channel communication, the destination address is not an actual address but a means to identify the packet, where the next destination is already known by the SDNP gateway. If the destination of the packet is for SDNP cloud routing, the data packet is processed by the 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 Figure 9h, the signaling server cannot notify the SDNP gateway ahead of the imminent arrival of the data packet and its data fields because (i) there is no signaling server operating in the local network, or (ii) ) because the signaling server is temporarily offline, or (iii) because the signaling server is too busy and cannot route packets in a timely and preferential manner. In such case, the data packet 438A from the SDNP client is required to decrypt the data packet using the SDNP last mile security operation 1190D, which converts the ciphertext data packet 438A into a plaintext data packet 438B. It must be accompanied by a secure credential area (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 concealment process used to generate the data packet does not utilize the Key 2 field, then the data in that field is meaningless and is not used by the destination node. Nonetheless, the data packets retain the same number of bytes for used and unused fields, so all SDNP data packets are of a uniform 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 generates a new SDNP address for two reasons - firstly, to verify that the incoming packet is expected in triple-channel communication, and secondly, to generate a new SDNP address. Combine the data fields for the A type and destination address from the Hdr 1 field header 1178D. This new SDNP address is combined with the D type, urgency and delivery fields and processed by the SDNP packet preparation operation 1191Z to generate the SDNP header 434Z within the outgoing data packet. The content of the Data 1 field is also extracted from the received plain text data packet 438B, and its content is optionally mixed with other outgoing content (1184Z) to produce the outgoing SDNP payload 435Z. The packet is then processed by SDNP Cloud Security 1190Z in preparation for forwarding. In this way, the address field performs a number of functions: to identify incoming data packets and to provide a forwarding address when necessary.

If a 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 outgoing data packets. If the media node does not have any instructions on how to handle an unannounced received packet, the data packet will be discarded. If a media node is enabled with instructions on how to process an unidentified packet, the media node will first verify that the packet is a valid SDNP packet according to its 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 back to FIG. 9F, the packet fields labeled "Field Zone" describe the zone in which that particular field was created, i.e., whether past encryption or scrambling was performed, for example, with U1 or U2 zone settings. In the case of nested security protocols or other nested hiding methods, additional information such as key, seed, time or state is required to unscrambling, decrypt, or otherwise undo the hiding of the data packet, and in such cases " Packet fields marked “Field Other” may be used to carry field-specific information. Typically, these fields are not used, except, for example, in nested security protocols, where the encrypted data fields are subsequently scrambled or encrypted a second time. Care must be taken when using nested security methods to perform data restoration in exactly the opposite order of data packet preparation, otherwise the content will be lost forever.

The packet field marked "Data Type", when used, is used for context-specific routing, distinct data, pre-processing, and data packets that do not require real-time communication from data packets containing time-sensitive information such as voice and live video. Facilitates recorded video, text and computer files, i.e. distinguishes real-time routing from non-real-time data. Data types include voice, text, real-time video, data, software, etc.

Packet fields marked "Urgent" and "Delivery" are used together to determine how to optimally 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 invention, the binary sizes of the various data fields, as shown in table 1177, are selected to minimize the required communication bandwidth. For example, the data fields as shown can range from 0 to 200B, whereby eight 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 a client device transmits a data packet to a gateway node via the last mile in zone U1. The gateway node then uses the zone (U1) security credentials to process the incoming data packet to undo last mile security 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. You can.

A similar process is used when the SDNP gateway receives data packets from the cloud and transmits data packets to the client device, for example, from the SDNP cloud for the client's phone (called party). As shown in Figure 9I, the dual-channel or triple-channel communication signaling server 2603 has notified the SDNP gateway in advance of the planned arrival of data packets coming from the cloud and their corresponding identification markings 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 ciphertext to plain text data packet 2438B. . The unencrypted seed and key data fields within data packet 2438 A can be ignored or optionally used with signaling server information to decrypt the ciphertext. The use of the data field depends on the algorithm used to conceal 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. A subsequent operation partitions these data fields in a content-splitting operation 2184Z and uses a recognition operation 2191D to extract specific content including data field 1 and its associated data field header 2117D, denoted as Hdr 1. . The header (Hdr 1) contains the destination address, data type, urgency, and delivery information of the data field. The extracted data fields are then rewrapped into a new IP or SDNP datagram by SDNP packet preparation operation 1191Z for delivery to the next destination. A new data packet destined for the cloud includes an SDNP header 2434Z, which contains the data content and the destination of the new packet (an IP address corresponding to the person's phone number), which is the SDNP payload 2435Z. The outgoing packet is 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 incoming data packets using the previously communicated indication as a default indication. In such situations, incoming data packets are checked against criteria necessary to confirm that the sender is a valid SDNP client (such as an SDNP zip code or authentication code previously passed as a predetermined shared secret). If the packet is determined to be valid, the packet is processed according to default instructions. Otherwise, the packet is discarded.

The methods described above 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 communications is the network's ability to support both secure and private communications. Although privacy and security are often related, they are not the same. Security, as the term is used in communications, is considered "controls to prevent unauthorized access to communicate data in a recognizable form." However, security does not include instances where an individual or agency has the authority to access or monitor communications.

Privacy is defined as “the state or condition of being unobserved or undisturbed by others and free from public attention.” The legal term of privacy is defined as an individual's right to control access to his or her information.

In telecommunications, an individual's privacy rights in voice calls, video, text, email, private messaging, etc. vary greatly from country to country. Their role in complying with applicable government regulations to provide legally effective access to communications is explained in subsequent sections. Beyond that, an ideal network and communication system should be able to prevent communications from being hacked, i.e. be absolutely secure, and ensure that all communications are restricted to those who have the right to know, i.e. be private.

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

* Secure and private network. From an individual's perspective, this case represents ideal network performance, ensuring both security of information and privacy for the individual. At these extremes, a truly secure private network is one in which no meaningful communication can be stolen by any individual, government, agency or company, and that an individual's movements, actions, contacts and associates, his personal preferences and activities, etc. are private. This means that data cannot be obtained. Although privacy rights advocates regard the ideal of secure private networks as the gold standard for confidential communications, governments, security agencies, and companies view absolute autonomy in communications as problematic, and individuals can commit crimes with absolute security and impunity. It is seen as enabling participation in activities and terrorism.

* Unsecured networks lacking privacy. Networks that are unsecured and do not have privacy provisions (e.g., today's Internet OTT carriers) represent a significant risk to the individuals, groups, clubs, companies or governments that use the communication channels. Because cyber-hackers can easily access calls and data, any malicious party can use this information for any purpose they choose. In the case of real jokers and spammers, insecure communication channels can be commanded to cause confusion, flood networks with spam, cause early denial of service attacks, and create harmful adverse effects. In the case of ideologues, policy activists, and religious cults, unsecured communications can be used to leak sensitive information that can lead to policy changes, distrust of government officials, incite riots, or even overthrow of governments (e.g. between nations in solidarity). (see historical fiction film "The Fifth Estate" (DreamWorks ⓒ 2013), such as the WikiLeaks revelations of hundreds of thousands of sensitive government documents that caused repercussions). In the case of economically motivated cyber-crimes, such as those associated with organized crime and the mafia, attacks may involve financial crimes such as theft, fund diversion, fraud, identity theft, money laundering, extortion, blackmail, and other serious crimes. focus on In the case of people associated with fear and intimidation, such as drug cartels, gangs, and terrorists, to plan and carry out violent crimes such as attacks, kidnappings, murders, bombings, or acts of terrorism, their rivals, enemies, and targeted victims. Unsecured communications can be monitored to track location, movement, and behavior. Finally, in the case of a personal cyber-attack, unsecured communications may be used to steal an individual's private information, including Social Security numbers, passports, banking information, credit card information, medical records, and other personal confidential information. Databases can be hacked illegally.

* Secure network with no privacy. An example of a secure network that lacks privacy typically involves an information technology (IT) manager or security department having the right and authority to monitor all company communications to ensure that inappropriate or illegal communications do not occur across the company's network. Branches include company accounts. Although the network is secure from hackers and cyber-criminals, communications on such networks are not private, and may be subject to unauthorized personal use of company communications infrastructure, corporate espionage, violations of confidentiality agreements, unauthorized disclosure of intellectual property (IP leaks), etc. Detects wrongdoing, including sexual harassment, violations of fair disclosure regulations (registered FDs), insider trading, FCPA violations, bribery, bribery, fraud, financial reporting violations, security violations, and others. It can be monitored by an approved agent to do so. In company communications, individuals are informed upon joining that their company communications are not private and may be monitored, including company phone calls, emails, texts, private messaging and SMS, and other communications. In the case of court precedents, whether citizens or criminals, their communiqués may also be subpoenaed in court and introduced 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 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 to prevent inspection of their text chats, photos, and files. Because you can't claim it.

* Semi-private, unsecured network. A semi-private unsecured network is one in which private transactions can be conducted in secret despite the network carrying the data being hacked, for example, wire tapped, or lack of certain conditions provided for security being met. In this way, privacy is established by verifying the identity of the caller (or callers) by various means using shared secrets, which cannot be revealed even by a hacker intercepting the call. A common example of private, unsecured communication is voice banking transactions. The caller asks a series of ever-changing questions that may be difficult for the scammer to know the answers to, such as "We see that you had dinner last night and paid with our credit card. Can you tell us which city you had dinner in?" Verify their identity by answering the following questions: “Can you get it?” or “You receive 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 this method of identity verification for work, the bank has access to non-public information (such as credit card statements) or the bank and its clients share secrets when an account is first created, usually in person rather than electronically. A set must be constructed. In cases where the caller's identity is confirmed, the client can instruct the agency to take certain actions that may not be advantageous to cybercrime. For example, “Move $10,000 from my savings to my checking account.” However, when the money transfer is to another bank, more stringent authentication must be implemented to ensure the client's privacy. In any case, privacy depends on the fulfillment of the condition that the communication cannot reveal shared secrets electronically or audibly, otherwise all privacy may be lost and the account may be at risk. Accordingly, such authenticated communications on unsecured lines are referred to as semi-private, meaning conditional privacy. Other examples or semi-private communications over unsecured networks can be effected through the use of security tokens, which are bank-issued devices that are owned only by the client. Refers to 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, the chances of guessing the correct code the first time are very small. If an incorrect token number is recorded, the call will be terminated, the account frozen and the fraud department alerted to investigate. In any such case, the importance of ensuring privacy over an unsecured network relies on being able to make a call without verbally revealing any confidential details such as account number, PIN, credit card information, etc., i.e. Communication is only semi-private.

Identity Verification and AAA - The concepts of security and privacy rely on accurate and reliable verification of identity, that is, who the caller is talking to.

Verification of identity, also known as “authentication,” is important in validating the use of data and communications and preventing illegal or unauthorized access. Trustworthy identity verification is important for national security, law enforcement, IP ownership, business enterprises, and individual rights. Examples of the importance of verifying identity include:

* For the country's national security, caller identification is important in tracking down criminals, spies, terrorists, drug dealers, and anyone else who might reveal state secrets or threaten national security. It is equally important to be able to identify the individual authorized to access, read, or transmit confidential, confidential, or Top Secret communiqués, data, and files.

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

* In the case of IP owners such as movie studios, identification is important in identifying individuals, institutions, and organizations concerned with privacy and unauthorized distribution of copyrighted material such as music, movies, books, videos, etc. This is equally important in ensuring valid and legal distribution of IP and copyrighted material.

* For a business enterprise, verification of the identity of its employees may be used in tracking intentional or accidental disclosure of non-public sensitive information, in identifying persons involved in commercial espionage, in identifying individuals involved in unlawful 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 especially in authenticating the specific types of data they may have access to. 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 to ensure the caller's "privacy" by ensuring that the person or persons speaking is not an imposter.

Accordingly, the role of identity verification is to verify an individual's identity, that is, to verify that he or she is who he or she claims to be, and to identify, block, and ultimately apprehend 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 an individual's identity and authenticate that they have an account on the system.

Once authenticated, the effective 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 user's “authentication” as granted by the system, i.e., an authenticated user can only access communications, data, files and system features for which they are authorized. Accordingly, authentication is synonymous with “privilege” or “access.”

The third “A” in AAA stands for Management. Management is the bookkeeping practice of recording authorized access to networks and files, for example, to manage usage-based billing, 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 network's ability to conduct AAA processes takes precedence over ensuring privacy and preventing fraudulent use of the network from unauthorized users or network operators. Any network that cannot guarantee the user's identity can be misused for illegal purposes. Fraudulent use of the network by unauthenticated users is an inevitable problem in OTT communications because there is no means to verify the identity of the caller. Unauthenticated access and network communication by unidentified users, i.e. anonymous persons, is a significant risk in modern communications.

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

Some OTT carriers have chosen to operate VoIP phone services, such as Payphone, without verifying the subscriber's identity. For example, in an online report (http://money.cnn.com/2015/11/17/technology/isis-telegram/), CNN Money said, “An app called Telegram is the new favorite among jihadists.” announced. According to the study, the Telegram application was a tool of ISIS terrorists in secretly planning the Paris attacks. In one such article, “Telegram developers knew that Isis had used such apps to communicate 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 is more important than our fear of something bad like terrorism happening.'

Another example of privacy and anonymity being used in crimes reported in the media is that of BitTorrent - an application and data network often used to illegally download and share copyrighted material. In a news story from CNN Money Tech (http://money.cnn.com/201l/06/10/technology/bittorrent_lawsuits/) titled “50,000 BitTorrent users sued for illegal downloading,” users , has reportedly been sued under a new anti-privacy law for illegally downloading the movie "The Hurt Locker" and other copyrighted works. Network operator BitTorrent has taken PayPorn's position that it is not responsible for people who use the network for personal activities. Free speech advocates support this position, while law enforcement, government, national security, and IP rights advocates abhor this attitude as reckless and irresponsible. Regardless of the policy, unless the communications system is capable of implementing caller verification, discussion of stopping anonymous calls is purely academic.

Caller verification 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 This is especially important for companies and business enterprises in controlling access to confidential company data, including other trade secrets. When accessing company communications, the access privileges granted to any employee, contractor, or officer are dependent on his or her identity. On conference calls, including investor calls, identity verification is important in verifying who is participating in the call and ensuring that people who do not need to know are not listening.

Paradoxically, while caller authentication is used to prevent crime and deter corporate espionage, the same user authentication is beneficially 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, and the call is thus protected 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 or her true identity from the network with which he or she communicates. However, anonymous calling does not require the caller to be anonymous from the network, but only to confuse his or her true identity in call data packets during communication. Registered account holders on the SDNP network may, according to this disclosure, use anonymous data to place calls or transmit data, even if the network knows their identity and phone number. In this way, law-abiding citizens can communicate anonymously, without having to conceal their identity from SDNP network operators. When a caller engages in general private calling, entertainment, or business, their SDNP calls remain private and secure even though the network knows their identity as stored within the SDNP name server database.

Examples of the need for legally anonymous communications include global gaming where it is important to protect the identities of gamers, especially children. Another case where anonymity can be advantageous is vehicle-to-vehicle (V2V) communication to protect drivers who drive recklessly from harsh retaliation by identifying other drivers' personal data that makes their driving worse. In contrast, if the caller is involved in the communication with a crime or other heinous act, law officials may have access to the call and data transmission (subject to applicable law). In this way, network operators can satisfy the requirements of court orders and subpoenas without exposing the identity of law-abiding citizens or making their calls public.

In summary, using the disclosed SDNP communication method, only identifiable SDNP subscribers can place anonymous calls. Unidentified callers do not have access to the SDNP network or the 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 the law are considered. Every nation claims its sovereignty to control communications within its 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 traffic "through" server-to-server networks - data packets moving through the country without interruption. Because Internet traffic is routed dynamically, network operations are not concerned with which data packets the server's network carries. Of course, any country can intercept and decode such large amounts of data, but because of encryption, access without knowledge of the encryption key is difficult, especially for real-time monitoring. And because the caller may not reside within the country, certain countries do not have jurisdiction to subpoena or demand the encryption keys used to locate the currency. Such network transit-data is similar to radio wave traffic crossing the Earth's atmosphere. Even if radio waves pass through the stomach, there is no practical way to stop them. Similarly, other than completely isolating a country's infrastructure from the Internet, there is no practical way to stop data traffic passing through a network.

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

Unlike the legal and technical challenges associated with enforcing network transit-data regulations, the laws governing last mile communications and call termination are, as a whole, the prerogative of the country in which the last mile network operator resides. Depending on national privacy laws, state controls may impose the level of access required for last mile communications, including combinations of the following:

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

* The right to monitor the metadata of any call, without a court order.

* The right to monitor all calls and data communications, without a court order.

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

For example, various governments, such as the United States, have taken the position that they reserve the right to monitor currency "metadata" 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 at the time of the call, etc., 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 not only to header data, but also to the payload itself. In those cases where the payload may be encrypted, the government may insist that the network operator provide the master encryption key (if one exists). One issue raised by privacy advocates is government abuse of power. Specifically, in cases where a network relies on a set of master encryption keys, giving up those keys in response to a court order to enable government surveillance of specific individuals is prohibited, even though the court order is limited to individuals or groups. However, it allows the government to monitor all calls. This issue is often referred to as the question, “Who should be the police for the police?” Another consideration concerns the privacy rights of individuals placing international currency. In such cases, the caller should be aware that the applicable laws for government access vary depending on the location of both callers, i.e., where the two last mile networks originate. For calls from the United States to China, U.S. law will apply to the caller within the United States and Chinese law will apply to other callers within China. In such a situation, access to the currency by one government may be greater than another. Accordingly, callers in countries with greater privacy rights may consider their privacy violated by the government of another country, but cannot complain because they are speaking to a country without a legal basis.

For communications utilizing the previously disclosed secure dynamic call networks and protocols, it is virtually impossible to intercept transit-data in hypersecure cloud communications of fragmented, scrambled and dynamically encrypted data packets transmitted anonymously across the SDNP network. Therefore, the privacy and security of hypersecure calls are determined by the device and last mile communication. By adapting the disclosed SDNP method to last mile communications, hypersecure communications and high-integrity privacy capable last mile can be realized as disclosed herein.

Additionally, a mechanism is disclosed to adjust the security and privacy settings of the SDNP network to accommodate local 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 disposition. Accordingly, in the hypersecure last mile communications disclosed herein, the use of “back doors” vulnerable to cyber-attacks is not utilized.

Hypersecure last mile communication method and device

To ensure end-to-end hypersecurity, the application of the previously disclosed method for routing encrypted, scrambled, anonymous and fragmented data packets within the SDNP cloud should be similarly configured for communications within the last mile. Ensuring last-mile communications is particularly problematic, as data may be carried over networks that are not hosted by the SDNP operator, packet routing may include traditional IP packet routing, and the inherent complexity of the last-mile network may be problematic. 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 communications essentially involve 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 comprising a server 1201 (schematically represented by soft-switch based SDNP nodes M _0,0 to M _0,f ) transmits exemplary data packets 1222B, 1222C. VoIP, video, text, and data are transmitted using the SDNP datagram shown in , and 1222F). SDNP datagrams include SDNP Layer 3 source and destination addresses, but do not include 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 cannot be recognized by DNS name servers on the Internet.

As described in the aforementioned US application Ser. No. 14/803,869, SDNP packets dynamically change as they move through the network, with their routing addresses updated based on shared secrets and dynamic “states” (such as time). and continuous changes to the payload are implemented. 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 includes a layer 3 SDNP datagram (C) with a different SDNP address and a re-encrypted payload. A few tens of milliseconds later, the same payload arrives at node M _0,f , which processes the data and forwards the data packet 1223G containing the IP datagram (G) via the last mile.

Since the change is implemented according to the defined state, the original packet data can be restored by performing a series of counter-functional operations executed in the reverse order in which they were implemented. For example, an SDNP functional sequence comprising the scrambling, junk insertion (deception), and encryption steps can be implemented in the opposite sequence if the same state used for executing the function is implemented to implement the corresponding reverse function: decryption, junk removal, and It can be returned to its original state by unscrambling. State data for a packet may be embedded within the payload of the packet, accompanied by a time, seed, or key, or may be transmitted in advance with the packet. Data transmission and processing within the SDNP Cloud operates 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.” The area used for security credentials operating within the SDNP Cloud cannot be exposed to arbitrary user communications outside the SDNP Cloud. Therefore, all last mile communications must include an SDNP security zone that is different from the SDNP cloud.

In the illustrated example, servers 1201A and 1201F hosting the corresponding nodes M _0,0 to M _0,f operate as SDNP gateways, i.e. they connect devices outside the SDNP cloud as well as SDNP within other clouds. Communicate with nodes.

Communication from these gateways to communication devices outside the cloud represents “last mile” communication. Therefore, gateway nodes must understand the zone security credentials of both the SDNP cloud and the last mile network to which they are connected, and act as translators during packet routing. Semantically, the term last mile is an abstract concept referring to communications 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 and the SDNP cloud over any distance, regardless of whether the client device is acting as an SDNP client, i.e., running SDNP application software or firmware. Either it is or it is 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 mile - the distinction between first mile and last mile is arbitrary. Specifically, in any duplex conversion or any IP communication "session", the device receiving the call essentially responds to the call or session request by transmitting a response to the caller. In any two-way communication, the first mile connection therefore necessarily functions as the last mile in the response data path. Essentially, the first mile for the caller is simultaneously the last mile for the responder. 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 for any device other than the SDNP client is essentially accomplished using IP datagrams and is not accomplished using SDNP IP datagrams. For example, referring back to Figure 10, data packet 1223A includes an “IP datagram (A)” constructed using an SDNP payload with an IP address, rather than an SDNP address. Similarly, IP datagram (G) includes data packet 1223G containing an SDNP payload routed using an IP address. The IP source and destination addresses represent any IPv4 or IPv6 addresses that can be recognized by the network through which routing takes place. The IP address may include an Internet address that can be recognized by a DNS server on the Internet, or alternatively, it may include a NAT address used for routing across a local network established by a local network service provider.

Because the hardware and firmware utilized in last mile communications can vary significantly and can include phone lines, fiber communications, cable TV networks, 3G and 4G wireless networks, microwave communications towers, and satellites, an analysis of last mile communications includes: Consideration must be given to the various Layer 1 physical networks and their corresponding Layer 2 data link formats used. 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 regarding SDNP "call out" communications.

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

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 over the unsecured last mile. In the upper example, communication is made using analog signals to an analog device such as a telephone or Payphone 6A. In such cases, the SDNP gateway must include a digital-to-analog converter. Otherwise, a modem or conversion device can be added to the gateway. Information is carried by analog signals 1221, not by data packets. Analog telephone signals, while effective for voice transmission, are not suitable for high-speed data communications.

In the lower case, an SDNP call out is generated over a digital network to a digital device (e.g., mobile phone 32) that is not enabled as an SDNP client, i.e., not enabled with SDNP software or firmware. . In such cases, the data packet 1223 carries the call or data, typically using the Internet Protocol, i.e., an IP packet format according to the 7-layer OSI model. An IP datagram contains an IP or NAT address in its source and destination address fields and IP or VoIP data as its payload. Digital pathways can include digital data in various forms, such as Ethernet, WiFi, or 4G/LTE, depending on the last mile connection.

In one of the example schematics, because last mile communication data is carried outside of the SDNP network through an unsecured communication channel or network, calls are 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 twisted copper wire, coaxial cable, fiber, Ethernet, WiFi, cellular, or satellite, require special security methods such as encryption at the end- Unless inserted into a two-end data path, it is not inherently secure. The security of the most secure data cloud or VPN is therefore compromised by the weakest link - in this example, the last mile. Especially in a well-established electrical, microwave, or radio wave connection, even encryption does not guarantee security. In addition to the lack of security, the schematic example does not include any mechanism for identity verification. In the absence of authentication, the last mile does not guarantee privacy. Accordingly, the exemplary schematic represents an unsecure 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 communications connection 4 to a common conventional telephone system (POTS) switch 3. POTS switch 3 then places a normal telephone call via twisted copper wire 7 to the home phone 6, to the wireless phone system 5, or to Payphone 6A. The entire last mile is neither private nor secure. Although communication of data packets 1222A containing SDNP datagrams (A) utilizes SDNP addressing and SDNP payloads within the SDNP network, the benefits are lost once the data enters the last mile hypersecurity. For example, data packet 1223B containing an IP datagram B carried by an NSP network hosted wired or fiber link 24 may use conventional IP addressing recognizable by an Internet DNS server and Contains typical IP payloads that can be sniffed by cyber-pirates. Analog lines 4 and 7 are likewise vulnerable because they carry simple analog audio signals as analog call data 1221. Although the SDNP gateway can support insecure, non-private call outs, it is misdirected to connect SDNP secure calls to an insecure last mile network that lacks privacy support.

Using identity verification, some improvements over the previously described unsecured last mile implementations can be achieved. Figure 13 schematically shows an example of an SDNP callout routed over the last mile, which is unsecure but with two different types of authentication. The upper example shows a SDNP call out from SDNP gateway 1220A to business office desktop phone 9 via analog or POTS. As shown, operator 1225 passively performs authentication to verify the identity of the account holder and verify its account ID. Although authenticated, calls carried by analog sound 1221 are unsecure and private only if secret or account information is not revealed vocally in the conversation, i.e., information is private if secrets are not revealed, but information is private. Once exposed, communications are no longer private. Accordingly, the term semi-private is used herein to refer to authenticated calls over unsecured lines, i.e., conditionally private calls.

The lower schematic diagram shows the SDNP call out from SDNP gateway 1220A onto the unsecured digital last mile. Data conveyed by IP datagram 1223 to an electronic device, such as a desktop PC 36, is insecure but may be authenticated using an electronic identity verification method such as token 1226 to which a cyber-attacker does not have access. You can. Because the lines are unsecured and can be sniffed, you should exercise caution in digital dialogs to avoid exposing account numbers or confidential data.

Specific examples of semi-private unsecured calls are shown in several examples below. 14, an identified, unsecured last mile communication is shown between the SDNP network and an office desktop phone 9, for example a private banker's phone. The account holder's calls, for example when making international calls, may be routed internationally using hypersecure communications within the SDNP network and ultimately connected to the last mile as SDNP call outs through SDNP gateway 1201A. The long-distance portion of the call is generated using dynamically changing SDNP datagrams, such as data packet 1222A, which includes SDNP datagram A with an SDNP payload. Data packet 1222A is then converted by SDNP gateway 1201A from an SDNP datagram (A) to an IP datagram (B) shown by data packet 1223B. Unlike SDNP datagrams (A), IP datagrams (B) contain a sniffable IP payload. Data packet 1223B is transmitted to the public switched telephone network or PSTN gateway 1A by an operating wireline or fiber link 24 to a network service provider (NSP). Again, this gateway is connected to the corporate switchboard 8A via a POTS line 4 carrying an analog call 1221. Corporate switchboard 8A is connected to desktop phone 9 via an analog private branch exchange or to desktop phone 9 via PBX line 7A and also to personal authentication operator 1225. During the call, the account holder contacts the private banker at the desktop phone 9, but before being able to initiate any trading agreements, and a personal authentication operator 1225 joins the call to verify the caller's identity, and The caller later leaves the call, thereby maintaining the caller's privacy. However, because calls are not secure, both private bankers and account holders must be careful not to disclose confidential information such as account numbers, passwords, or PINs by voice. Therefore, the call is quasi-private, i.e. conditionally private.

15, unidentified, unsecured last mile communication is shown between the SDNP network and 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 the 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) operation wired or fiber link 24 transmits data packets 1223B containing IP datagrams B on the last leg of the last mile between network router 27 and SDNP gateway 1201A. transport Because IP datagrams are used, the last mile is not secure. Digital methods for identity verification, such as login windows 1227 and security tokens 1228, may be used for authentication to ensure communications remain quasi-private. These digital certificates should be limited to a single use to prevent their use by fraudsters. For example, if a token generates a number and this is used to gain access, the combination is no longer valid for that use, and if a hacker intercepts the token, it is useless because it expires. This is because it is no longer valid.

Another example of identity-verified unsecured last mile communication is shown in Figure 16, where SDNP gateway 1201A communicates with point of sale (POS) terminal 38 and gas pump POS terminal 38A as SDNP call outs. do. Last mile communications as shown are a mix of digital and analog connections including NSP wired or fiber links 24 carrying data packets 1223B containing IP datagrams B to network routers 27; A wired or fiber link 24A then carries the IP datagram (B) within data packet 1223C, and a POTS or analog line 30B is connected to a point of sale (POS) terminal 38 and a 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 smart card integrated circuits and may be by dynamic PIN 1228. Authentication involves identifying with a financial institution 1230 connected to the SDNP network through SDNP gateway 1201A or another last mile.

Hypersecure Last Mile Communication - By adapting the technology of secure dynamic communication networks and protocols, hypersecure communication can be achieved via the last mile. To promote hypersecurity, connected devices must run SDNP code as “SDNP clients.” The SDNP client contains operational instructions, shared secrets, and SDNP connectivity information, hosted on a connected communication device. The SDNP client 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 shows an example hypersecure communication over the last mile using an “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 different mobile device platforms using Android, iOS, and Windows Mobile. Similarly, separate OS-specific applications are required for laptops, desktop PCs, and servers, including Windows 10, MacOS, Unix, and Linux. Hardware hosting of SDNP clients within devices that do not have a higher level operating system, such as POS terminals, hotspots, IoT, etc., must be adapted to programmable devices that run the code. Programmable integrated circuits often require programming in chip-specific development environments that are specific to the IC's suppliers, such as Qualcomm, Broadcom, Intel, AMD, NVidia, Microchip, etc.

Because the SDNP gateway 1201A and the SDNP app 1335 communicate using the SDNP payload 1222, the caller identity and call payload cannot be understood from packet sniffing, and specifically the SDNP payload 1222 Contains source and destination SDNP pseudo-addresses that are not recognized by DNS servers, and the payload includes SDNP data that may be scrambled, fragmented, mixed with junk data injection, and dynamically encrypted. The SDNP payload 1222 is embedded within an IP datagram 1223, which uses the last mile IP address or NAT address of the network of the cellular, cable or ISP carrier used for last mile connectivity, instead of the SDNP address. Directs routing across the board.

Another aspect of SDNP-based hypersecure last-mile communication is that any SDNP client can essentially perform authentication and identity verification. Accordingly, the privacy feature is not based on the network's ability to achieve privacy to support AAA, but rather on whether the client software or firmware is designed to facilitate the authentication process. Because any hypersecure last mile can be identified, it should be understood that the hypersecure last mile examples below apply to both private and non-private secure communications. Accordingly, unlike unsecure last mile networks with semi-private characteristics, private communications over the hypersecure last mile are determined by the SDNP client, not by the network, and can be single-factor or multi-factor to whatever degree the client desires. Can support the factor authentication process.

Specific examples of hypersecure currencies are shown in several examples below. 18, hypersecure last mile communication is depicted between an SDNP network and various cellular mobile devices with WiFi last links. As shown, a data packet 1222A, which includes an SDNP datagram (A) and includes an SDNP payload, is sent by SDNP gateway 1201A for last mile communications to an IP datagram that also includes an SDNP payload. It is converted into a data packet 1223B containing (B). Because the hypersecure last mile uses a different shared secret, numeric seed, encryption key, and other zone-specific security credentials, instead of using the SDNP cloud, the SDNP payload within the IP datagram (B) is It is different from the SDNP payload in (A). In other words, SDNP gateway 1201A, by changing the payload from one secure zone to another and embedding 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 with an IP header containing a last mile network-specific IP address, either a NAT or Internet address, within an IP datagram packet, and thus the SDNP gateway 1201A and the communicating device. , that is, assists in packet routing between the tablet 33 and the mobile phone 32, which acts as an SDNP client. Because intermediate devices in the last mile routing are not SDNP clients, the composition of the SDNP payload within the IP datagram (B) remains fixed as it moves across the last mile. In other words, data packets 1223B, 1223C, and 1223D are identically structured 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 SDNP datagram (B). To simply summarize, only an SDNP network node or SDNP client can reconstruct the SDNP payload embedded within a level 3 datagram, whether it is an IP datagram or an SDNP datagram.

As shown, data packet 1223B containing an IP datagram B is carried by an NSP-operated wired or fiber link 24 to a network router 27, and then data packet 1223C is also transported by an ISP-operated wired or fiber link 24. Includes IP datagrams (B) carried by wired or fiber link 24A to WiFi router 26. WiFi router 26 then sends data packets ( 1223D) to promote last link communication. Accordingly, these devices are capable of processing an IP datagram (B), which includes decoding, de-junking, unscrambling, and mixing the contents of the payload with data fragments from other data packets to recreate the original message or sound. It functions as an SDNP client that can interpret data contained in the data packet 1223D containing.

19, hypersecure last mile communication is depicted between an SDNP network and various cellular mobile devices with cellular radio last links. As shown, data packet 1223B containing an 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 the cellular network. and an IP datagram (B) carried by a mobile network operator (MNO) wired or fiber link (24B) to a cellular base station (17) to generate (25). Subsequently, the cellular base station 17 transmits IP datagrams (B) over 3G, 4G/LTE 28 to mobile devices such as mobile phones 32 and tablets 33 on which the SDNP app 1335A is running. Facilitates last link communication using data packet 1223D.

As in the previous example, because the intermediate devices in the last mile routing are not SDNP clients, the composition of the SDNP payload within the IP datagram (B) remains fixed as it moves across the last mile. In other words, data packets 1223B, 1223C, and 1223D are identically structured 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 SDNP datagram (B).

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

In Figure 21, hypersecure last mile communication is depicted between an SDNP network and a cable service client. As shown, data packets 1223A containing IP datagrams B are carried by NSP wired or fiber links 24 to cable CMTS 101, i.e., the cable operator's command, communications and content distribution center. do. Such cable operators provide a variety of services such as cable TV, usage-based billing, telephone services, Internet connectivity, business services, and others. The CMTS 101 head unit is then connected to the client via cable 106 using DOCSIS3 and fiber or coaxial modulated according to 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 can maintain the datagram format or alternatively package the IP datagram into a proprietary datagram format. These data packets, referred to herein as CMTS datagrams (C), utilize cable-specific NAT addressing and store the SDNP payload as n nested payloads within data packet 1224C for delivery on cable 106. Encapsulate.

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

In Figure 22, hypersecure last mile communication is depicted 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 carried by NSP wired or fiber link 24A to cable CMTS 101, i.e., the cable operator's command, communications and content distribution center. do. The CMTS 101 head unit is then connected to a specific client's cable (WiFi) modem router 100B using a wired or fiber link 24A over coaxial or fiber to create a WiFi access point 26. Routing of data packet 1224C may include an IP datagram with an Internet address, or a proprietary CMTS datagram (C) with NAT addressing. 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 within the home network includes a WiFi link 29 that wirelessly connects the cable (WiFi) modem router 26 to various home devices by data packets 1223D containing IP datagrams (B). To facilitate end-to-end hypersecurity, the device must operate as an SDNP client using software or firmware loaded on the device. For example, the laptop 35 and desktop computer 36 operate as SDNP clients using the computer app 1335C, and the mobile phone 32 and tablet 33 operate as SDNP clients using the mobile app 1335A. It works. IoT devices, in this case registrars 34K, can operate as SDNP clients when SDNP firmware 1335E is loaded into their control system. However, in cases where such devices do not or cannot have the SDNP client's software embedded, end-to-end security can be achieved by other means.

Identity- Paired Last Link Security - If the connected device cannot act as an SDNP client, hypersecurity cannot be guaranteed end-to-end. In such cases, the use of SDNP remote gateways can extend hypersecure communications to cover the last mile of communications excluding the last link. The last link, that is, 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 through the local area network (LAN) used to facilitate last link communication. Figure 23 schematically illustrates the use of SDNP remote gateway 1350 in last mile communications. SDNP remote gateway 1350 includes any communications device enabled by SDNP firmware 1335H to function as a remote gateway. Accordingly, the SDNP connection between SDNP gateway 1201A and SDNP remote gateway 1350 includes an IP datagram 1223A that includes an IP or NAT source and destination address and an SDNP payload 1222. SDNP payload 1222 includes an SDNP address that cannot be recognized by a DNS server using last mile zone specific security credentials and a nested SDNP payload. These SDNP connections are hypersecure and can support 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), communications are conducted 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 identities of the two devices and prevents unauthorized access.

In Figure 24, an SDNP enabled router 1351, i.e. a router running SDNP firmware 1335H, functions as 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 the IP datagram (A), the connected devices are not SDNP clients. Instead, SDNP router 1351 converts the SDNP payload into a regular IP payload. Unless additional security measures are introduced into the device, this last link is insecure. In home use, these unsecured device connections are often not a concern because the last link occurs within the home. Unless a hacker physically enters your home to connect to a wiretap, such wireline connections cannot be sniffed. Examples of wired in-home last links for non-SDNP devices include Ethernet 106A, shown by example connected to modem 103C connected to desktop computer 36 and connected to TV 39, or HDMI-2. Includes.

Because SDNP connectivity and hypersecure communication extends only to the SDNP router 1351, the last link must rely on authentication and encryption to achieve security over the wireline connection. In Ethernet, such security can be achieved through any number of security methods, including iSCSI operating on Layer 1 to Layer 3, such as virtual local area network operation or VLANs using encryption between authenticated devices (http://www.computerweekly .com/feature/iSCSI-security-Networking-and-security-options-available). Alternatively, security may be achieved using “IP Security” or Layer 4 to Layer 6 methods utilizing the IPSec framework. Originally developed and promoted by Cisco as an industry standard for data storage, IPSec offers two security modes. In “authentication header” mode, the receiving device can authenticate the sender of the data. In this mode, the data fields are encrypted, but the header uses a recognizable IP address. In Encapsulating Secure Payload (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 is The correct network destination can be reached.

In either case, security relies on an authenticating device to be able to connect to the network. In home networks, for example, in private networks that connect computers, shared storage drives, IoT, and other device connections, network-connected hardware is not frequently exchanged. In such cases, authentication essentially involves a registration process for the device to gain access to the network or router. Instead of identifying the identity of a specific user, this type of authentication connects between devices, typically using some device tag, name, or ID number to identify and recognize devices authorized for connection. 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, and 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 the device to connect Bluetooth headphones to a cell phone or pair a Bluetooth cell phone to the vehicle's hands-free audio system. The protocols are 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). ) includes. Some methods, such as RADIUS, rely on encryption methods, which have been broken but are still used in combination with other technologies.

Ethernet communications may be connected to an identity-paired device, e.g., Ethernet modem 103C, a modem that includes an analog telephone signal transmitted via copper twisted pair conductor 7 to wireless telephone 5A and to desktop telephone 37. Although it protects the output, the last link is not secure. Additionally, the communication format of wireless phone 5A is not secure and is subject to interception and monitoring. For this reason, the use of home phones in secure communications is not recommended.

Distribution of video content is another concern in security. For example, in the communication of SDNP router 1351 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 involve a physical connection to an HDTV or display monitor. Originally, the security of these connections and their data was a concern for film studios and content providers, with a focus on preventing illegal copying and distribution of copyrighted works. One security protocol developed by Intel Corp. to maintain video link security is HDCP (High-bandwidth Digital Content Protection) (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 the TV receiver or display before transmitting content. Accordingly, DHCP uses authentication to prevent non-licensed parties from receiving data, it encrypts data to prevent information eavesdropping, and it revokes keys on compromised devices.

With HDCP, the flow of content from the modem to the TV can be secured by authentication, i.e. by the use of identification pairing. However, with the advent of smart TVs, the data flow is bidirectional. As a means to facilitate upstream data flow, that is, 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. Accordingly, secure communications can be facilitated across HDMI using the same security protocols and identity pairing available on Ethernet.

25, 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 (1335J) can interpret the SDNP payload contained in the IP datagram (A), the connected devices are not SDNP clients. Instead, the SDNP WiFi router 1352 converts the SDNP payload into a regular IP payload and communicates wirelessly with the connected device using the WiFi access point 26 to facilitate communication over the WiFi link 29. do. Unless additional security measures are introduced into the device, this last link is insecure. In the case of WiFi communication at home or in the office, security is a concern because data packets can be sniffed from 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, or SDNP WiFi router 1352, and connected devices includes WiFi Protected Access (WPA-II or WPA2) (IEEE 802.1 li-2004), which replaces the older WPA and its unsecure predecessor WPE. The same is achieved using any number of industry standard protocols. WPA2 communications are protected using Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP) based on AES processing with 128-bit keys and 1280-bit block sizes. CCMP provides data authenticity, requires authentication, and establishes access controls. Authentication involves pairing your identity in settings. 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 by SDNP clients.

26, as an example of an IoT connected device within 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 the IP datagram (A), connected IoT devices are not SDNP clients. Instead, SDNP WiFi router 1352 converts the SDNP payload to a normal IP payload and communicates wirelessly with the connected device using WiFi link 29 from WiFi access point 26. Unless additional security measures are implemented, these last links are insecure - especially WiFi data packets can be sniffed from afar. Examples of WiFi-connected IoT devices in the home include central heating and air conditioning (34D), lighting (34G), blinds (34F), large appliances (34K), and portable and indoor heating, ventilation, and air conditioning (34E). , garage door (34L), home monitoring (34J), and home central security system (34H).

Security between the SDNP gateway, i.e. SDNP WiFi router 1352, and connected devices is achieved using any number of industry standards, such as the previously described WiFi Protected Access protocol (WPA2) using CCMP to promote data confidentiality, Require authentication and set up access controls. WPA2 achieves security using identity pairing, device authentication implemented as a layer 2 protocol. These methods are cumbersome and involve passive authentication methods.

An alternative protocol used for recently introduced local area networks for IoT communications - local area networks, referred to as the AllJoyn framework. Such frameworks help discover devices, create sessions, and facilitate secure communications. The framework is designed to support IoT device connectivity using a number of Layer 2 transport layers, including WiFi, Ethernet, serial bus communication, and power line PLC. Applications run on a number of 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 run at application layer 7. Transport Layer 2, also referred to as the router layer, transports security-related messages between application endpoints but does not perform any security logic itself. Additionally, the reverse call feature, also known as "Auth Listener", implemented at application layer 7, assists with authentication using a PIN, password, or authentication certificate. Security is achieved using AES128 peer-to-peer encryption. Like WPA, AllJoyn uses identity pairing in the authentication process prior to execution of command and control sequences. Supported authentication methods include pre-shared key or PSK, secure remote password (SRP) key exchange, or login using username and password. The protocol also supports transient (elliptic curve Diffe-Hellman) key exchange: (i) without authentication, (ii) authenticated with pre-exchanged keys, and (iii) authenticated with X.509 ECDSA certificates.

The same techniques can be applied to business enterprises. 27, as an example of an IoT connected device within a home network, the use of an 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 the IP datagram (A), connected IoT devices are not SDNP clients. Instead, SDNP and Ethernet WiFi router 1352 converts the SDNP payload to a normal IP payload and communicates with the connected device using both WiFi link 29 and Ethernet 106A.

Unless additional security measures are implemented, these last links are unsecure - especially WiFi data packets that can be sniffed from a distance. Examples of WiFi connected IoT business devices include WiFi hotspot connected devices such as central heating and air conditioning (34D), lighting (34G), surveillance systems (34J), security systems (34H), POS terminals (38), and tablets (33). Includes. Business enterprise Wireline connected devices vary depending on the characteristics of the business. In banking, devices include Ethernet connected ATM machines 38D. In a gas filling station, the device comprises, for example, an Ethernet-connected gas pump 38A.

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

SDNP SDNP Bridge Communication - As previously discussed, last mile data transmission outside the SDNP cloud involves IP datagrams, i.e. data packets, using Internet source and destination addresses, or alternatively using the network operator's NAT address. It is essential to use. For example, in the case of a private network operating within an office building or collaborating with a local network service provider to host SDNP soft-switches on their servers, SDNP datagrams can be used to achieve hypersecure communications over the last mile. You can.

As mentioned above, hypersecure communications rely 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, and these SDNP Soft-switch based servers are referred to as SDNP nodes, as indicated by 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 SDNP bridge concept can be similarly configured for the last mile communications segment. To create an SDNP sub-network or mini-cloud within the last mile, two or more servers must be enabled by SDNP bridge software or firmware. Unlike SDNP client software or firmware that runs on the end device, i.e. on the calling device, SDNP bridge operation does not operate as a final connection, but is used to route data. Accordingly, 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 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 or from outside the SDNP bridge network uses IP datagrams with an SDNP payload.

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

Within the SDNP-bridge connection, between the SDNP bridge router 1350 and the WiFi-based SDNP bridge router 1352Z, hypersecure communication occurs using SDNP datagrams 1222B. SDNP routing information is extracted from SDNP addressing included within SDNP payload 1222A. Together, SDNP-Bridge and SDNP connections include a hypersecure wireline leg of last mile communications that can support identity and account verification and support privacy.

The connection from SDNP-bridge router 1352Z to a non-SDNP client device, i.e. laptop 35, utilizes 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 previously mentioned Ethernet and WiFi security protocols such as iSCSI, IPSec, WPA, AllJoyn, and others.

Implementations of SDNP bridging can occur between any two SDNP-based devices accompanied by any number of physical media, with SDNP bridging operating layer agnostic from the Layer 1 PHY and Layer 2 transport layer implementations. 3 means it is a protocol. For example, in the top schematic diagram shown in Figure 29A, two SDNP bridge 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 a WiFi (wireless) bridge using SDNP datagrams 1222. . In the bottom schematic, an SDNP-bridge Ethernet router 1351A running SDNP firmware 1335H is configured to display SDNP datagrams ( 1222) to communicate over an Ethernet (wireline) bridge. In this way, an SDNP bridge comprising two or more SDNP-based routers, although operating outside the SDNP cloud within the last mile, can route or distribute SDNP datagrams throughout a building or across a private network.

SDNP-Bridge can be extended to systems using proprietary hardware, such as cable TV systems. For example, in the top view shown in FIG. 29B, two Cable CMTS "head" servers have been modified to run SDNP firmware or software 1335L and thereby act as Cable CMTS SDNP bridges 101 and transmit SDNP datagrams. (1222) to communicate over a cable or fiber (wireline) bridge. The SDNP-bridge can extend from the CMTS head to the subscriber's home. As shown in the central schematic, a cable CMTS SDNP bridge 101 running SDNP firmware or software 1335L uses SDNP datagrams 1222 across the cable (coaxial) bridge to run 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 of Figure 29B, two cellular base stations and radio towers running SDNP firmware or software 1335N function as cellular base stations SDNP bridges 17X and 17Y, resulting in cellular bridge 25X utilizing SDNP datagrams 1222. and 25Y). In the upper schematic 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 firmware as a microwave satellite bridge using SDNP datagrams 1222. or to an orbital satellite on which the software 1335P operates, i.e. to the satellite SDNP bridge 93. The satellite then communicates again with the subscriber or with other satellites.

SDNP bridge communication can be adapted to automotive applications using automobiles as a peer-to-peer ad hoc communication network. In the lower schematic of Figure 29C, the telematics module inside car 1390A with SDNP firmware 1335F running, via the car radio bridge, using SDNP datagrams 1222, also running SDNP firmware 1335F. Communicates with a nearby vehicle (1390B). Each vehicle enabled with SDNP firmware forms another communication node within the dynamic telematics SDNP bridge network. These communications do not indicate information being transmitted to a specific vehicle or driver, but instead form a communications network that can convey information along highways, even where cell towers are not present locally.

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

Distributing hypersecure communication data packets from SDNP-based satellite 93 to various clients includes SDNP data packet-A and data packet 1222C containing an SDNP payload. Satellite communications are bidirectional, and the downlink from satellite 93 to a terrestrial client allows for stronger signal strength and faster data rates than the uplink connection. In other words, the satellite can transmit to a client on Earth at a faster data rate and with a stronger signal strength than the client's response. Examples of satellite 93 links to subscribers include: to a Dish Internet subscriber 92G running SDNP firmware 1335T, to a satellite phone 92F running SDNP firmware 1335S, and to a satellite phone 92F running SDNP firmware 1335S. for a satellite antenna array 92H positioned atop an operational high-speed rail 1360C, for a satellite antenna array 92E positioned atop an operational ocean vessel 1360B with SDNP firmware 1335R, and with SDNP firmware ( 1335Q) includes a satellite link 95B to a satellite antenna array 92H located on top of the operational aircraft 1360A.

In the case of large vehicles such as ships, aircraft, and trains, each system connects these hypersecure satellite communications links to its own internal communications system or local area network. For example, Figure 31A depicts a commercial aircraft, where a satellite antenna module 92D running SDNP firmware 1335X mounted on the top of the fuselage of aircraft 1360A is connected to a communications central server running SDNP software 1335Z. Linked to (1361). The communications central server 1361 includes an instrument 1367, a data logger 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 connected to an array of WiFi antennas 1361 located throughout the aircraft to support WiFi hotspot communication. All communications except radio-based flight control occur over a common satellite communications link, for example using antenna module 92D shown in Figure 31B. The antenna module includes a satellite transmit antenna 1360A, a satellite receive antenna 1368A, an antenna control unit 1369, and a 40W voltage regulator 1370. The satellite receiving antenna 1368A is smaller than the satellite transmitting antenna 1360A because the satellite broadcast power and signal strength are greater than the antenna's broadcast strength and uplink capability.

Maritime satellite ship communications utilize multiple bands of satellite communications, including high-altitude and near-Earth orbit satellites. For example, Figure 32 illustrates the use of multiple band communications including Ku band satellite antenna 1383A and low-Earth-orbit satellite antennas 1383B and 1383C. High-altitude satellites provide limited or no uplink capabilities, but can cover large areas from high altitudes, including geostationary orbit. Because of its high altitude, the area coverage of each satellite is significant, 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 orbit satellites may be intermittent depending on the satellite's orbital position.

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

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

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

Communications functions in the automotive and professional trucking industry are multifaceted, including:

* Voice communication

* Navigation, maps, road information, warnings

* Entertainment, hotspot service, infotainment

* Wireless payment, toll

* Emergency services, roadside assistance

* Collision avoidance

* Flight scheduling (professional, shared ride)

Additional functions for autonomous vehicles, i.e. self-driving vehicles, are also required. Existing automotive systems, mainly 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 expenditure, meaning that installing a new network is not a financial option. Instead, a security infrastructure, such as security methods deployed at Layer 3 to Layer 7, must be deployed on top of the hardware network. This strategy is compatible with the SDNP last mile implementation disclosed herein.

34 illustrates an example hypersecure last mile connection between a carrier and an SDNP cloud. As with previous last mile connections, the specific data carriers involved in transporting packets across the last mile can vary greatly depending on location. Accordingly, an example is shown to present hypersecure communication regardless of the data carrier involved. As shown, SDNP gateway 1201A is coupled to network router 67A via a network service provider (NSP) managed wired or fiber link 24 to generate data packets 1222A containing SDNP datagrams A. Convert to a data packet 1223A containing an IP datagram (B) containing an SDNP payload. Network router 67A then sends the IP datagram B as data packets 1223B over wired or fiber links 24A owned or operated by a mobile network operator (MNO) to cellular base station 17. route to The IP data packet B is then transferred over the cellular network 25 as a data packet 1223C containing an SDNP datagram B containing an SDNP payload using the cellular link 28, i.e., area Communicates wirelessly to a telematics module within vehicle 1390A using 2.5G, 3G, 3.5G, or 4G/LTE, depending on the mobile network operator within. Next, SDNP firmware 1335F operating within the telematics module interprets the SDNP payload embedded within the received data packet 1223C, completing the hypersecure communication link. Therefore, automotive cellular last link functions as part of hypersecure last mile communications.

As shown in FIG. 35, the telematics module within automobile 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. The IP datagram (B) includes 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 datagrams (C) that use only a conventional IP payload are less secure, but work devices do not act 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 automotive communication is that of vehicle-to-vehicle communication, also referred to as V2V communication. The purpose of V2V communication is mainly to prevent collisions. 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 depicted in Figure 36, where vehicles 1390A, 1390B, and 1390C running SDNP firmware 1335F peer-to-peer with each other and with cellular base station 17 connected to SDNP gateway 1201A. Forms a two-peer network. Communication between vehicles may be conducted 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) with an SDNP payload into a data packet 1223A containing an IP datagram (B) with the SDNP payload embedded. As shown, cellular base station 17 connects car 1390A over 2.5G or 3G cellular link 28A using data packet 1223B containing an IP datagram (B) with an embedded SDNP payload. 1390C over a 3.5G or 4G/LTE cellular link 28B using data packets 1223C that also include 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 packet.

Cars enabled with SDNP firmware (1335F) can also form an ad hoc peer-to-peer SDNP bridge or bridge network. For example, car 1390A communicates with car 1390B over V2V radio link 1391A using data packets 1222B containing 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 remains hypersecure using the SDNP payload.

Another feature of the SDNP ad hoc V2V network is its ability to implement a tunneling function, i.e. to pass data from one vehicle to another without the intervening vehicle being able to monitor or interpret the passing data. In the event that cellular link 28B fails due to car 1390C being out of range, such as on another route, cellular base station 17 may connect cellular link 28A, V2V radio link 1391A, and finally cellular link 28A, in the example shown. Through the V2V radio link 1391B, the SDNP bridge network can be used to reach the same caller. During data transfer, data packets 1223B, 1222B, and 1222C are transformed from an IP datagram (B) to an SDNP datagram (C) and finally to an SDNP datagram (D). Because the SDNP payload intended for car 1390C is generated specifically for the destination car, car 1390B and its occupants rely on SDNP datagrams ( C) Content cannot be hacked or monitored.

In addition to typical last mile communication, the same SDNP bridge technology can be used to transmit large amounts of data over long distances through hypersecure, i.e. 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 connect microwave towers 96A and 96B running SDNP firmware 1335W. Alternatively, servers 21A and 21B may communicate directly over fiber trunk 98, which also utilizes data packets 1222 containing SDNP datagrams. there is. In global communications, for example, in a trans-Pacific data link, servers 21A and 21B use earth-based satellite antennas 92A and 92B, both running SDNP firmware 1335U, to host microwave satellite trunks ( 95A and 95B) can communicate with the satellite 93 on which the SDNP firmware (1335V) is operated. As in the fiber and microwave tower examples, satellite trunk communications utilize data packets 1222 containing SDNP datagrams.

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

In the bottom example, SDNP gateway 1395 communicates openly with a non-SDNP client without any security provisions using data packets 1223C containing an IP datagram with a sniffable IP address and an IP payload. Therefore, the last mile connection is neither secure nor private. In the second example from the bottom, SDNP gateway 1395 communicates with a non-SDNP client providing device authentication and identity pairing features. The communication is conducted 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 decrypt. Although the communication is neither private nor anonymous, it provides improved security, at least for a limited period of time.

The example following the top is hypersecure, as long as the SDNP gateway 1395 routes communications through any bridge or router 1397 and the data packet 1223A contains an SDNP payload within an IP datagram. It shows that it can still be achieved. The level of security achieved depends only on the end device and not on the router. In the above example, using a data packet 1222 containing an SDNP datagram with SDNP addressing, i.e., using source and destination addresses that are not recognized by Internet DNS name servers, and using an SDNP security payload, the SDNP Communication between gateway 1395 and SDNP client 1396 is hypersecure and provides excellent security, 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 utilized, routing of packets between an SDNP client or SDNP-bridge and an SDNP gateway carries and routes data packets over the last mile. To do this, it relies on IP datagrams. Unlike data routing within the SDNP cloud that is directed by the SDNP signaling server, neither the SDNP cloud nor its signaling server controls IP datagrams traversing the last mile. Therefore, some variability in last mile propagation delay is expected. Fortunately, because the distance and number of possible paths for last mile communications are limited, this uncertainty is small compared to the overall end-to-end propagation delay of global communications. The variation in total propagation delay due to last mile variability is estimated to be less than 10% of the total delay.

Figure 39 shows 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 (SDNP gateway), and the IP address of the source of the data packet (C _1,1 ), which is an SDNP client. Last link communication occurs over a 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 a last mile network connection shows each communication device as a PHY, data link, and IP stack representing network connections as OSI layers, 1, 2, and 3. For example, Figure 40A is a schematic IP stack diagram of single-route last mile hypersecure communication using fixed IP addresses. Accordingly, 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 to router 1402A via last link 1404, where the PHY layer 1 physical connection and corresponding data link layer 2 in client IP stack 1411 are connected to router 1402A. Connected to layer 1 and layer 2.

Again, router 1402A is connected to router 1402B using Ethernet, where the PHY layer 1 physical connection and corresponding data link layer 2 of WiFi router's IP stack 1412A are connected to router 1402B. Connected to corresponding layer 1 and layer 2. Finally, router 1402B is connected to SDNP gateway server 1401 using Ethernet, where the PHY layer 1 physical connection and corresponding data link layer 2 of the Ethernet router's IP stack 1412B 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, thereby transporting network layer 3 IP datagrams from one IP stack to another, specifically from layer 3 in IP stack 1411 to IP stacks 1412A and 1412B. And finally, it flows transparently to the IP stack 1422. In this way, the network carries IP datagrams across the virtual last mile connection 1409 as single path data, even when the data physically passes through multiple devices.

In other words, Layer 3 network data flows over the last mile independent of the physical connection used to carry the IP datagram, i.e., Layer 3 last mile communications are the basic Layer 1 and Layer 2 implementations used for data delivery. It operates agnostically. By removing intermediate nodes from the schematic diagram as shown in Figure 40b, this principle can be presented in a simplified form, where a client device 1400 comprising communication IP stacks 1411 and 1422 and an SDNP gateway server ( 1401 transfers data to and from corresponding computing and data storage functions 1410 and 1421. IP datagrams 1405 flow across last mile connections 1409, regardless of the media or number of routers used in the data packet delivery process. Accordingly, the last mile can be thought of as a “data organization” and can be viewed abstractly as meaning any and all physical means of transporting IP datagrams between devices. However, the last link has a more physical meaning, since the caller's connected device 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 that only has a WiFi connection and is sitting in a cafe with WiFi, but the caller does not have a WPA password for the WiFi network, the last link cannot be established and the caller cannot access the last mile. , cannot connect to the SDNP cloud, or cannot place calls.

Another consideration in last mile communications is that the payload of the IP datagram 1405 contains all of the information for the upper OSI layers, including transport layer 4 data, session layer 5 data, presentation layer 6 data, and application layer 7 data. It contains information. In addition to the Layer 4 data required to select the UDP or TCP transport protocol, the remaining data in the payload of the IP datagram is specific to the open SDNP communication and operates along the last mile, unless you are running the SDNP software or firmware yourself. It cannot be interpreted by the router. Therefore, although the last mile network itself may include a mix of different devices, carriers, and network operators, only the end devices, i.e. the caller or SDNP client and SDNP gateway, can interpret the last mile communication. .

Although SDNP payloads are secured by numerous secrets, including scrambling, fragmentation, junk data insertion and deletion, state-dependent formatting, and dynamic encryption, the IP address of IP datagrams traversing the last mile network is essential. The source and destination addresses of the client device 1400 and SDNP gateway server 1401 are exposed. To provide a degree of anonymity over the last mile, address spoofing is advantageous, that is, dynamically changing the source and destination addresses within an IP datagram to mislead a cyber-attacker. IP spoofing is achieved by dynamically changing the IP address of the caller's connection 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 ). Accordingly, although packets entering router 1402A all originate from SDNP client 1400, the client source address (C _1,n ) may change dynamically, confusing the true IP address and causing more than one communicating device to be present. Make it look like it is. To complete the charade, the MAC address of the communication device must also be changed correspondingly along with the dynamic source address.

This method is depicted using an IP stack in Figure 42A, where devices 1400, 1402A, 1402B, and 1401 communicate via corresponding IP stacks 1411N, 1412A, 1412B, and 1422 using WiFi and Ethernet. One, 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, as shown in the schematic diagram of the last link shown in Figure 42B, sequential data packets entering router 1402A appear to be transmitted from three different client devices, rather than one. The shared PHY layer contains WiFi standard frequencies, and the data link layer connecting devices follows defined standards such as 802.11ac or 802.11n.

IP datagram 1405N transmitted to router device 1402 along network connection 1408 has sequential source addresses IP C 1, expressed in mathematical notation as fixed destination IP addresses IP M _0,0 and IP C _{1,n . 1} , IP C _1,2 , IP C _1,3 , etc., where n = 1, 2, 3, ... uniquely identifies each sequential packet. Each sequential IP packet also includes a corresponding payload (SDNP 1, SDNP 2, SDNP 3, and others). Although this description cites individual IP addresses using the mathematical abbreviation IP C _1,n , it is important to note that IP addresses include actual IP addresses created according to the international standards of IPv4 or IPv6 and exclude any conserved IP addresses. It is important to note that you must understand that you do this.

Another option to improve security is to use multipath packet transmission in the last mile. In a similar manner to data transmission within the SDNP cloud, in multipath last mile communications, 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 a static IP address is shown in Figure 43, where SDNP client 1400 communicates with multiple gateways 1401A, 1401B, and 1401C. As shown, the first data packet 1405A includes 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 a payload SDNP 2 with 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. The 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 via last link 1404C through routers 1402D and 1402E to SDNP gateway 1401C.

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

For example, Figure 44A shows an IP stack diagram of the above-described multi-route last mile hypersecure communication over a common PHY last link 1404 using a fixed IP address. In operation, SDNP client C _1,1 communicates with routers 1401A, 1402B, and 1402C as a single device connection using common PHY, data link, and network layers. Address spoofing uses successive IP datagrams containing fixed client addresses IP C _{1, 1} , but with varying SDNP gateway addresses IP M _0,0 , IP M _0,1 , and IP M _{0, 3} . It is carried out. Packet misdirection can occur algorithmically or randomly. For example, when every 10th datagram among 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 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, such as WiFi. Although the last link connection is shown as a single line splitting into three, it should be understood that the physical connections are all made point-to-point rather than electrical Y connections used to create parallel wires. Instead, the diagram shows the effect of a connection, i.e., the PHY layer of client IP stack 1411 extending one PHY connection to three, i.e., the PHY layer of IP stacks 1412A, 1412C, and 1412D. It means connected. Functionally, this last link operates as a single input to a three input expander, wherein one The clients of are connected to three router functions. As shown, it should be noted that last link 1404 constitutes a single type of communication media - cable, fiber, WiFi, Ethernet, or cellular.

However, the remainder of the last mile may include any media that is not necessarily the same as the last link. An alternative last link includes multiple different PHY layers connected to independent routers. One such implementation, an IP stack implementing multi-path last mile hypersecure communications using fixed 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. Connected to (1402A). Similarly, IP stack 1404B is connected to router 1402C over last link 1404B directing IP datagrams with source address IP C _1,1 and destination address IP M _0,1 . IP stack 1411C is connected to router 1402D over last link 1404C directing an IP datagram with source address IP C _1,1 and destination address IP M _0,3 traversing router 1402E. connected.

The combination of dynamic source addressing and multipath data transfer is shown in Figure 45, where SDNP client 1400 uses dynamic source addresses to communicate with multiple gateways 1401A, 1401B, and 1401C. In this method, the first data packet 1405A includes a payload SDNP(1) with a dynamic 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 a payload SDNP 2 with a dynamic IP source address (C _1,2 ) and a destination address (M _0,1 ). Data packet 1405B is then routed to SDNP gateway 1401B via router 1402C via last link 1404B. The third data packet 1405C includes payload SDNP 3 with a dynamic IP source address (C _1,3 ) and a destination address (M _0,3 ). Data packet 1405C is then routed via last link 1404C through routers 1402D and 1402E to SDNP gateway 1401C.

Accordingly, each successive data packet contains a changing SDNP payload, uses a dynamically changing source address, and is routed to a specific SDNP gateway over a different last link. Via multiple last links, namely Last Links 1404A, 1404B, and 1404C, a single router with multiple IP inputs, such as a DOCSIS3 cable modem with trellis encoding, or through multiple forms of media, e.g. For example, a combination of radio and WiFi or other combinations of wireline and wireless communications are used to transmit data across multiple WiFi bands. In one example, Figure 46A shows the 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 that includes 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 the IP stack 1411C generates a client address (C _1,3 ) directed to SDNP gateway M _0,3 .

As shown in the IP stack diagram of Figure 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 the SDNP gateway with IP addresses IP M _0,0 , IP M _0,1 , and IP M _0,3 .

In many cases, the last link involves a single path, where multipath data transmission beyond the first router is utilized. In Figure 47, SDNP client 1400 communicates with a single router 1402A over last link 1404. 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 a payload SDNP(1) with a dynamic IP source address (C _1,1 ) and a destination address (M _0,0 ). Data packet 1405A is routed via last link 1404 and through 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 through routers 1402A and 1402C to SDNP gateway 1401B. The third data packet 1405C includes payload SDNP 3 with a dynamic IP source address (C _1,3 ) and a destination address (M _0,3 ). Data packet 1405C is subsequently routed via last link 1401 and through routers 1402A, 1402D, and 1402E to SDNP Gateway 1401C. Accordingly, each successive data packet contains a changing SDNP payload, uses a dynamically changing source address, and is routed to a specific SDNP gateway over a common last link.

This last mile connection is depicted using the IP stack in Figure 48, where the IP stack 1411 in the SDNP client device 1400 with the last link 1404 having only the router 1402A is connected to the network layer 3. transmits the data packet to stack 1412A, which includes three different network addresses, specifically IP C _1,1 , IP C _1,2 , and IP C _1,3 . Accordingly, client device 1400 appears to router 1402A as three separate clients, although it actually contains a single client. When the IP datagram reaches router 1402A, the IP datagram is split and takes different paths to different destination gateways. For example, a packet with source address IP C _{1, 1} may be routed through router 1402B to destination IP M _{0, 0} , and a packet with source address IP C 1, ₂ may be routed through router 1402C. 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 specific SDNP gateway is not pre-fixed and may vary dynamically. IP addresses can be assigned on a per-packet basis, further confusing the fact that apparently unrelated data packets are all part of a single, fragmented communication between two callers.

Physical Realization of Last Mile Routing - The physical realization of the last mile may involve 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:

* Media Access Control (MAC) address of the communication device,

* Source IP address of IP datagram,

* Destination IP address of IP datagram.

Therefore, the MAC address controls the physical media used to carry information at each hop in the last mile communication, i.e. layer 1 and layer 2, while the IP address controls the physical media used to carry information to the client device and the SDNP gateway i.e. the two ends of the last mile. Identifies the device located in . Although the payloads used in hypersecure communications follow protocols prescribed by Secure Dynamic Communications Networks and Protocols, intermediate devices within the last mile, i.e. routers and other devices on the path of packets between client devices and gateways, typically use SDNPs. It is not enabled to execute the function because there is no SDNP executable code in such device. Accordingly, the SDNP payload is not relevant to the routing of last mile hypersecure data packets.

One example is the use of Ethernet for last mile communications. In an adaptation of the Ethernet data packets described above in FIG. 9E for SDNP last mile communications, FIG. 49 is a schematic diagram of IPv4 and IPv6 datagrams for Ethernet communications carrying SDNP payload. As shown, layer 1 Ethernet packet 188 includes a data frame header, namely a preamble 180, a start frame delimiter (SFD) 181, and a layer 2 Ethernet packet 189. 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 used to specify the type of data link used (Ethernet II or length specifications according to IEEE802.3), and a frame check 186 containing a 32-bit CRC checksum of the entire data link packet. The Ethernet packet 189 also includes a variable length MAC payload 187 that is used to encapsulate the SDNP content 1430 of the IP datagram.

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

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

Last mile routing of Ethernet packets depends on both the IP address and the MAC address, indicated by an exemplary name of the device to which the IP or MAC address refers, for example MAC C _1,1 or IP M _0,0 . For brevity, a symbolic name representing a numeric address generated 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 a different number of bytes for IPv4 and IPv6 names. Additionally, the format for the MAC address varies depending on the layer 2 data link protocol used. Therefore, the MAC address MAC C _{1, 1} for a cellular radio is not the same as the MAC address for the same device communicating using WiFi or Ethernet. MAC addresses are not related to IP addresses, that is, IP addresses and MAC addresses for the same client are not related.

Sequential last mile routing of Ethernet packets is shown in examples in Figures 50A-50D. Each diagram 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, the 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 includes an SDNP payload (G) that is moved from SDNP gateway 1401 to router 1402A over gateway link 1414 and then to client 1400 over last link 1404. Includes. The SDNP client 1400 has a numeric MAC and IP address MAC C _1,1 and IP C _{1, 1} , the router 1402A has a numeric MAC address MAC R, and the SDNP gateway has a numeric MAC and IP address MAC It has M _0,0 and IP _{M 0,0} . Router 1402A's IP address is not used in data packets.

Unlike in the SDNP cloud, where SDNP datagram packet routing is completely controlled by the SDNP network, in last mile communications using IP datagrams, SDNP payloads cannot be interpreted or affect routing across the last mile. This means that each communication carried contains fixed source and destination IP addresses. The physical media or channel used to direct Ethernet packets is controlled by the MAC address connecting each communication node within the last mile. For example, Figure 50A shows router 1402A including source MAC address MAC C _1,1 , destination MAC address MAC R, source IP address IP C _1,1 , destination address IP M _0,0 , and SDNP payload. Shows IPv4 and IPv6 last link Ethernet packets used for a single PHY routing to . Figure 50B shows the corresponding Ethernet packet carrying SDNP payload (A) over gateway link 1414. As explained, the source and destination IP addresses remain unchanged in 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 . changes.

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

One convenient means for representing last mile communication from an SDNP client is to use a "short" data packet that contains data fields including source and destination MAC addresses, source and destination IP addresses, and SDNP payload. The abbreviated form is convenient for describing the data flow in any communication "session", consisting of successive data packets and their responses delivered across the last mile to the SDNP gateway. For example, a series of Ethernet packets (shown in abbreviated form) sent from an SDNP client to an SDNP gateway are shown in the upper portion of Figure 51A. Each row represents consecutive data packets containing the SDNP payload (A, B, and C). The leftmost column shows the data packets within the last link, while the right column carries the same payload across the gateway link. shows a data packet. As shown, every packet specifies IP C _{1, 1} as the source IP address and IP M _{0, 0} as the destination IP address. Because only one pair of IP addresses is used, the last mile is referred to herein as SDNP single path last mile communication. Additionally, 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.”

To facilitate layer 2 interconnection between each communication node to its neighbor, MAC addresses within different segments of the last mile are necessarily varied. As shown, every successive packet traveling across the last link from the client to the router uses the source and destination MAC addresses MAC C _1,1 and MAC R. Because a single MAC address is used for clients in successive data packets, the last link contains a single physical media, i.e. a single PHY last link. Transport over the gateway link uses source and destination MAC addresses MAC R and MAC M _0,0 respectively.

Accordingly, although the data packets shown contain SDNP payloads, routing over the last mile essentially utilizes sniffable MAC and IP addresses - addresses that can be interpreted by monitoring by an unauthenticated listener. By tracking packets with the same source and destination IP addresses, unauthenticated listeners can determine that the data packets are likely to be part of the same conversation or session, and that although they cannot open the SDNP payload, they can still It can be assumed that metadata such as file size, data rate, etc. can be collected to create a profile of the caller. Additionally, by following MAC and IP addresses, metaphorically analogous to tracing a trace, 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 use MAC and IP addresses in last mile and last link communications. is to change it to The deception method of this invention is:

* Data packet transmission across changing communication media by dynamically changing the last link MAC address, referred to herein as “multi-PHY last link” communication,

* Hiding the caller by dynamically changing the identity of the client device's IP address, referred to as "dynamic client addressing";

* Varying 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” communication. To do something.

The combination of multi-PHY, dynamic client addressing, and multi-path last mile communications makes tracking and detecting last mile and last link communications extremely difficult, as only the SDNP caller and SDNP gateway can determine which packets are connected to the same call or session. This is because we know that it is a part of . These methods can be used separately or in combination.

For example, the bottom half of Figure 51A illustrates 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 the last link data packet, and the right side represents the 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 A third consecutive data packet containing (C) is described. In single path last mile communication with fixed client addressing, every successive data packet uses a fixed client address IP C _1,1 and a fixed destination address IP M _0,0 .

To utilize multi-PHY last link communications, i.e., to route data within the last link across multiple physical media, the SDNP client's MAC address must dynamically change within sequential data packets. Each MAC address corresponds to a specific PHY layer, for example, Ethernet 100BASE-T and 1000BASE-T connections. In the case of three physical media, the client's MAC address is a packet that dynamically changes sequentially from MAC C _1,1 to MAC C _1,2 and then to MAC C _1,3 . In cases where only two media are available, 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, It can be changed to a random pattern, such as ₁ , MAC C _1,2 , MAC C _{1, 1} , ..., preventing pattern recognition. While the source MAC address changes, the MAC destination for the last link may remain constant, i.e. as MAC R. Because all of the last link's multi-PHY paths terminate within the same router, the data path through the remainder of the last mile remains fixed as single path communication. In other words, while the last link utilizes multi-PHY connections, 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, packet sniffing data packets from a specific call can still be identified because they share a common client IP address. This detection method is avoided by using dynamic client addressing - the action of a client changing its IP address with each packet it transmits. As an example, Figure 51B illustrates the use of client dynamic IP addressing in single path last mile communications. The top set of data packets represent a single PHY last link connection, while the bottom set of data packets describe a multi-PHY implementation. In SDNP single path last mile communications, the SDNP gateway's destination IP address 442 is fixed to the numeric value IP M _0,0 within every data packet, regardless of whether a single PHY or multi-PHY method is 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 dynamic client addressing data packet carrying the SDNP payload (B) Data packets use dynamically selected source IP addresses including IP C _1, 3, etc., and data packets carrying SDNP payload (C) use dynamically selected source IP addresses including IP C _{1, 3} . . The number of dynamically selected addresses is virtually unlimited, especially in IPv6. Additionally, an IP address can be reused as long as a certain amount of time, for example 1 second, elapses before the address is recycled. In the case of dynamic client addresses 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 dynamic client addresses with multi-PHY last links, the value of the source MAC address 183 changes sequentially, from MAC C _{1, 1} to MAC C _{1, 2} and then to MAC C _{1, 3} . . There is no special numerical correspondence between the client's changing MAC address and its dynamic IP address.

Although dynamic client addressing appears to include 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 way 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 clients 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 multiple gateways, the SDNP cloud directs the packet to its destination. It can be routed. Figure 51C illustrates the use of multi-path last mile communications with fixed client addressing. In every data packet shown within the last link, the client's source IP address 441 remains fixed with the numeric value IP C _1,1 , while successive data containing the SDNP payload (A, B and C) The packet dynamically changes its destination IP address 442 from IP M _{0, 0} to IP M 0, ₁ 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 the gateway that is temporally close 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 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 show a different media , for example, describes 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 changing MAC address of the client and the destination IP address of the SDNP gateway.

The most effective level of deception combines dynamic client addressing with multi-path last mile communications. A new combination of these security features is shown in Figure 51D for a single-PHY last link implementation (shown in the top half of the figure) and for a 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 and 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 selected by the SDNP signaling server to minimize propagation delay while dynamic client addresses change in unrelated ways. 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 changing client and the IP address of the changing client or SDNP gateway. However, in multi-path last mile communications, the multi-PHY last link would advantageously be connected to three separate routers (R ₁ , R ₂ , and R ₃ ) instead of centralizing all data within a single router (R). You can.

Last mile deception as described above is located in the top row #1 from the minimum security implementation (shown at the bottom of the table as row #10), which includes a single path last mile with a fixed client address and a single-PHY last link. Ten different cases are shown, as summarized in the table of FIG. 52A, ranging from dynamic source addressing to better deception provided by multi-PHY last links with multi-path last mile communications. The intermediate combinations are ranked in order of security. The notations of (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 communication, using a single gateway (M _0,0 ), while rows 1 through 6 describe multi-path last mile communication with multiple gateways. Except for shaded rows 1 and 4, last link communications are connected to a single router with MAC address (R). In contrast, in multi-path communication, shaded rows 1 and 4 illustrate multi-PHY last link communication for multiple routers with dynamic MAC addresses (R _n ).

The operation of single-path last mile communications is a combination of four - static client addressing with a single-PHY last link, fixed-client addressing with a multi-PHY last link, dynamic client addressing with a single-PHY last link, and multi-PHY. Dynamic-Client Addressing with Last Link - is shown topographically in Figure 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 shows possible unused paths. Shaded circles represent communication nodes used in last mile communications, while empty circles represent unused communication nodes. As shown, all examples terminate last mile data routing over a single connection between the router (R) and the SDNP gateway (M _0,0 ).

In the case of fixed client addressing over the single-PHY last link shown in the upper left corner, each successive packet takes the same path over the entire last mile using an IP address that does not change. 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 involves a single route as specified by the IP address, which does not change. Despite single-path transport, the changing physical media of the last link makes caller tracking more difficult. In the case of dynamic client addressing across a single-PHY last link, shown in the upper right corner, each successive packet is identical over the entire last mile with a constant client MAC address and an unchanged destination IP address for the last link. take the passage Instead, deception is achieved by changing the client's identity by dynamically changing the source IP address. In the case of single-path communication with dynamic client addressing and multi-PHY last links, shown in the lower right corner, all packets are routed to a single SDNP gateway, but the client's MAC address and source IP address are dynamically and randomly change

Dynamic client addressing is the process of having a client device use one or more temporary, ad-hoc IP addresses. The process includes two stages. In the first stage, when a device first logs onto the network, 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, 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 as the assigned IP address is updated by the local DHCP server, each time the client device communicates it uses this IP address, either by starting a new session or requesting a new address. Because the address is generated dynamically within a specific subnet, the client device's IP address is not an Internet address.

In the second stage, when a client device places a call or log on the SDNP network, the device automatically contacts the SDNP signaling server based on the SDNP server's static IP address. When the SDNP server receives an incoming message, it uploads the ad hoc IP address or addresses to the SDNP name server. The SDNP name server then assigns an SDNP address as a pseudo-code for each of the temporary IP addresses. In operation, immediately before routing, a 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 transmitting packets with changing source addresses. In this way, dynamic deception hides the true identity of the client device.

When the SDNP gateway arrives, the source address for the outgoing packet discards the client IP address and substitutes the gateway server's SDNP address instead. Each outgoing SDNP packet then exchanges the device's local IP address with its local ad hoc IP address immediately before transmission. Unlike Internet packet transmission where the 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 client device's source address is not included in the data packet. Instead, the signaling server notifies the destination device regarding a return path for a response.

The operation of “multi-path” last mile communications is topographically depicted in Figure 52C, with four combinations of single-PHY and multi-PHY last links, as well as fixed and dynamic client addressing. In each multi-path communication, the destination IP address, i.e. SDNP gateway, changes continuously, meaning that the last mile path connects to different inputs to the SDNP cloud. In the left column, the client address remains static, meaning that the caller's identity does not change. The upper left corner example uses a single-PHY connection for the last link, which means that the MAC address for the client also remains static. Although the communication occurs to a different destination gateway, the unchanged last link physical media and the unchanged client IP address make the last mile call traceable. This vulnerability can be remedied by changing the last link media 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, which means that the MAC address for the client changes dynamically. Such an approach compensates for the fact that the client's identity maintains a static IP address. As part of end-to-end multi-path last mile communications, each specific last link is connected to separate routers on the journey of successive packets to separate SDNP gateways. Therefore, 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} . is 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 fixed client IP address C _1,1 is routed via the specific PHY media to the router with media address MAC R ₃ , where it is subsequently routed to SDNP gateway M _0,3 do. Despite using a client with a single source IP address, the use of multiple routers opportunistically utilizes multiple PHY last links to forward last mile packets in entirely separate trajectories.

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

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

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

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

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, one or two for wired network connections, and specifically uses Ethernet data packets. Figure 53 shows the same WiFi packet format configured for SDNP last mile and last link communications. As an access point applicable to last link communications, only three 6B-length MAC addresses are required, specifically the MAC Address 1 field 235 for the receiving radio base station or "receiver", and the transmitting radio base station or "Xmeter". A MAC Address 2 field 236 is required, and a MAC Address 3 field 237 contains the MAC address of the wired network connection to the WiFi router, i.e. Ethernet or "Net". In operation, the numeric value of the MAC address loaded into the Receiver and Exmeter data fields determines whether (i) data packets received on the radio and forwarded to Ethernet or (ii) received data on Ethernet converted to radio communication. It depends on the directivity setting to/from DS. The MAC Address 4 data field 239 is optional and is only used when the WiFi device is used as a radio bridge in “wireless 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 the SDNP last mile is generally limited to SDNP clients. The focus is on last link connections. Accordingly, the following description will focus on the access point mode for WiFi routers, with the understanding that the SDNP technology herein can be equally applied in wireless distributed mode routing.

Similar to Ethernet data packets, the preamble 230 and start frame delimiter (SFD) 232 contain layer 1 data to synchronize the data and device. Physical Layer Convergence Process (PLCP) 232 includes mixing Layer 1 and Layer 2 information (related packet length, data rate, error checking in header, etc.). According to the IEEE 802.11 standard, the remaining data fields are Layer 2 containing the frame control 233, which specifies the WiFi version packet type, such as management, control, preservation, or "data", the type used in SDNP payload delivery. Contains data link information.

Duration and ID 234 contains the NAV duration, if the WiFi device is not in a power saving mode, in which case the field contains the station ID. NAV, or Network Allocation Vector, is a virtual carrier-sensing mechanism used to save power in wireless communication systems. The NAV duration can be viewed as a counter that subtracts towards zero at a uniform rate while it senses the media to determine whether the radio is idling or still communicating. In idle mode, the counter repeatedly counts the NAV duration and checks to determine whether any radio communication activity request interest has been detected. The sequential 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 in length used to carry the WiFi payload. In SDNP last mile communications, these fields contain the IP datagram used in the last mile communications, including IP header 434, transport-header 436, and SDNP payload 435.

The IP header 434 varies depending on whether the IP datagram follows 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 include transport header flags 470 that are used to determine the layer 4 transport method used, e.g. TCP, UDP or maintenance functions ICMP and IGMP. Specifically, TCP transport is used for software and data files, while UDP is used for real-time data such as VoIP and video, according to secure dynamic communication networks and protocols. The length and format of the transport header 436 vary depending on the transport header flag 470. 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 WiFi packets depends on both the IP address and MAC address, which are 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 examples in Figures 54A-54D. Each diagram contains 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 by wireline to the BS link 1415. ) and moves onto the router 1402X. Router 1402X then forwards the data packet to SDNP gateway 1401 via gateway link 1414. The response from the SDNP gateway to the client is transmitted by wireline from SDNP gateway 1401 to router 1402X over gateway link 1414, across BL link 1415 to WiFi router 1402W, and through the communication media. It includes an SDNP payload (G) that is moved to the client 1400 across the last link 1404 using a WiFi radio. The SDNP client has numeric MAC and IP addresses MAC C _{1, 1} and IP C _{1, 1} , the WiFi router 1402W has a numeric MAC address MAC W, and the router 1402A has a 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 for the last mile communication shown.

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

For example, Figure 54A shows the example used for a single-PHY radio routing to WiFi router 1402W via last link 1404, including the exmeter MAC address MAC C _1,1 and the receiver MAC address MAC W. IPv4 and IPv6 last link WiFi packets are shown. 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 the 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. Accordingly, a WiFi data packet specifies two media: WiFi radio last link 1404, and Ethernet wireline BS link 1415. Figure 54B shows corresponding Ethernet packets carrying SDNP payload over 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 . changes.

Response communication involves swapping destination and source IP addresses, and adjusting MAC addresses accordingly. Figure 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 is the address of the client, the value IP C _1,1 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).

Figure 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 depending on the radio mode. In the transmission mode shown here, this field contains the Ethernet MAC address of the wireline source of the radio's received data, i.e., the numeric value MAC R of the router 1402X transmitting the data packet to the WiFi access point.

In the receiver mode previously shown in Figure 54A, this field specifies the Ethernet destination of data received as radio packets and converted to Ethernet packets. In the example shown, the “net” field 237 contains the same MAC address, i.e. MAC R, of router 1402X for both transmit and receive modes, which allows the WiFi access point to use a single This means using an Ethernet router.

Optionally, in multipath communications over the last mile, a wireline router used to route, in receive mode, data packets received by a WiFi access point may, in transmit mode, route data packets transmitted by the WiFi access point. It may be different from what is used for routing. For example, the network MAC address 237 for a radio packet in receiver mode may have the numeric MAC address MAC R ₁ , while in transmit mode the data may be converted to a different router connection MAC R ₂ , which This means that the BS link can optionally include multi-PHY implementations that vary directionally. In transmit mode, the last link WiFi packet used for the single-PHY radio 1404 last link routing from the WiFi router 1402W to the SDNP client 1400 has an Exmeter MAC address 236 with a numeric value MAC W. and a receiver MAC address 235 containing the numeric value MAC C _1,1 . In this direction of data transfer, wireline router 1402A acts as a source of data transmitted by the WiFi router device. Accordingly, a 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 communications. The cellular network re-partitions incoming Ethernet packets into radio-specific Media Access Control (MAC) packets. Data may be transmitted and received by time division (TDMA), by code division (CDMA), or by spreading of content over 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 within layer 2; Specifically, the lowest level is a PHY PDU 299 containing a MAC header 303 and a single frame MAC SDU 304 with padding 305 spread over 20 time slots 300 containing PHY layer 1 data. Includes. The MAC SDU 304 in turn contains 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: known mode, unknown mode, and transparent mode, as well as error detection, error correction, copy detection, and specified It provides packetization of data according to 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 perform radio overhead functions, a single frame RLC SDU 308 is inevitably limited in duration and data file size available to carry the payload. Accordingly, the single frame RLC SDU 308 must be divided into segments and mapped to different RLC layer 2 formats - multi-frame RLC SDU 319.

As shown in Figure 55, mapping the single-frame RLC SDU 308 to the various K, K+l, K+2 segments 313, 314, 315, etc. of the multi-frame RLC SDU 319 involves -It does not occur on a one-to-one basis. For example, as shown, the mapping of a 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 processed within a new single-frame RLC SDU 312, but only after allowing for the necessary padding time 310 for radio clock synchronization and only after RLC header 311 processing. , is transmitted. In this way, transmission of the data encapsulated within the K+2 slots resumes exactly where it is left as if the data flow had never been interrupted. Alternatively, 4G is similar to stopping playback of a DVD encoded movie in the middle of a DVD chapter, waiting a few moments to perform some other function, and then resuming playback exactly where it was stopped. Thus, the RF data 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 no data-rate degradation resulting from clock synchronization padding time 310. is minimized.

A multi-frame RLC SDU 319 encapsulates a PDCP PDU 320 in 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 PDCP header 321C and data 325, and so on. The term PDCP is an acronym for Packet Data Convergence Protocol, as specified in 3G and 4G/LTE communication protocols, and performs functions such as compression, encryption, integrity assurance, as well as user and control data delivery. The PDCP header varies depending on the type of data being transmitted, e.g. user data, control data, etc.

Because data transmission within 4G data packets carries a continuously concatenated stream of data, the payload size is not quantized into defined length blocks as is the case in 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 may be supported incrementally, including IP header 434 and IP payload 435 including SDNP payload 1430. Additionally, in OFDM-based communications, each time slot carries data simultaneously on multiple frequency subcarriers, which means that the total data throughput is not simply determined by the duration over 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. It varies depending on. Both preambles 440 and 444 include transport header flags 470 that are used to determine the layer 4 transport method used, e.g. TCP, UDP or maintenance functions ICMP and IGMP. Specifically, TCP transport is used for software and data files, while UDP is used for real-time data such as VoIP and video, according to secure dynamic communication networks and protocols. The length and format of the transport header 436 vary depending on the transport header bits 470. 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 communications using IPv6 datagrams, Figure 56A shows 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 the cellular source media address, such as MAC C _{1, 1} , of the client's device. Likewise, the MAC destination field 300B specifies the cellular receiver media address as a MAC BS that describes the cell tower and base station. Layer 3 network routing involves only last mile 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 ,} shown in the Source Data field. do. As mentioned above, data fields 323, 324, and 325 do not necessarily correspond to specific sections of the IPv6 datagram data payload, and data field 323 may include an IP source address 445, an IP destination address ( 446), and a portion of the SDNP payload (A) 435, including the transport header 436. Data fields 324 and 325 carry the remaining untransmitted portion of SDNP payload 435.

56B shows a data packet for the response message SDNP payload (G) over cellular last link 1404 from a cell tower and base station 1402Q to a mobile client device 1400, thereby and the destination address has been swapped, that is, the media address MAC BS is loaded in the cellular source media address (300A), the cellular destination media address (300B) is set to MAC C _1,1 , which is the MAC address of the client, and the 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 over BS link 1415 uses Ethernet data packets consistent with the previous example.

Multi-PHY communication over the last link may include any of the foregoing media used in various combinations. Multi-PHY implementations include multiple wireline connections carrying data at the same or different data rates and utilizing common or separate Layer 2 protocols such as USB, Ethernet 10BASE-T, 100BASE-T, 1000BASE-T, or DOCSIS3. may include. Wireline physical media may include Ethernet or USB-compatible network cables, coaxial cables, fiber optics, or even twisted-pair copper connections for DSL, albeit at reduced performance levels.

Wireless multi-PHY communications may include WiFi, cellular, satellite, or a combination of proprietary radio formats operating in radio frequencies and microwave bands. Wireless last link communications 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 general radio. May include cellular formats for 2G, 2.5G, 3G, and 4G/LTE, including proprietary formats for links. Because the Layer 2 protocol varies depending on the Layer 1 physical media, the term multi-PHY communication as used in the context of this disclosure refers to a combination of the OSI physical and data link layers, i.e., both Layer 1 and Layer 2. and should not be construed to limit the scope of the claims as referring only to Tier 1 physical media.

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

In a 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 5GHz channel using 802.11ac. In order to operate in multi-PHY mode, notebook 35 must be capable of simultaneously transmitting and receiving signals at multiple frequencies using a multi-band antenna 26B within the notebook. Similarly, a WiFi router must be able to transmit and receive signals simultaneously at multiple frequencies using a multi-band antenna 26. To facilitate hypersecure communications over the last mile, a laptop 35 is shown running SDNP software 1335C.

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

Such multi-PHY communication using a common Layer 2 protocol confuses cyberattacks because hackers must gain physical access to two different Layer 2 data links, each of which may have its own security. Additionally, when the SDNP software (1335C), SDNP app (1335A), or SDNP firmware (1335B) (not shown) is running on the client, routing of SDNP payloads across multi-PHY connections provides real-time security for real-time hacking. SDNP uses unique dynamic security credentials that make packet interception and interpretation very difficult.

An example of multi-PHY communication using mixed layer 1 media and layer 2 protocols is shown in Figure 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, 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). To ensure hypersecure communication over the last mile, a desktop 36 is shown running SDNP software 1335C. Such examples represent 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 containing secure desktop computers within a building or campus communicating to locked private servers within restricted access server rooms.

In the intermediate view of mixed-medium multi-PHY communication shown in FIG. 57B, mobile phone 32 with internal multi-band antenna 18C communicates using two different wireless technologies. One PHY connection, WiFi link 29C, communicates to WiFi router 100 and antenna 26 using the 802.11n protocol, for example at 5 GHz. The second PHY connection, cellular link 28C, utilizes a 1.8 GHz carrier operating with the 4G/LTE protocol to facilitate last link connectivity to cellular tower 25 and base station 17. Because the cell 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 be done. To ensure hypersecure communication over the last mile, a mobile phone 32 is shown running the SDNP app 1335A.

A similar method to achieve multi-PHY last link communication combining cellular and satellite is shown in the bottom diagram of Figure 57B, where satellite/mobile phone 32Z running SDNP app 1335A is connected to two long range radios. Communicates across a network - a cellular link 28D to a cell cellular tower 25 and base station 17 at 18 GHz, and a satellite link 95W to a communications satellite 92, for example at 1.9 GHz. Satellite 92 communicates with a terrestrial satellite antenna and base station 92B via wide bandwidth link 95X, again not necessarily at the same frequency as the client communications.

Figure 57C illustrates various other 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, i.e. performance is reduced as more users occupy the media's bandwidth and throughput capacity. Only three such media can readily exploit such large bandwidths: (i) DOCSIS3 cable systems using coaxial cable, (ii) DOCSIS3 cable systems using optical fiber, and (iii) multi-GHz satellite communications systems in low Earth orbit. You can. Specifically, the top view of the multi-PHY cable system shows SDNP firmware 1335M communicating with the cable CMTS 101 using multiple bands via coax or fiber 105 running the DOCSIS3 protocol. It shows the set-top box or cable modem 102B in operation.

The bottom diagram shows a multi-PHY satellite network, in which a satellite-based mobile phone 32Z running an SDNP app 1335A connects to a communications satellite 92 using multiple carrier bands 95Z formatted with a proprietary communications protocol. communicate with Communications between satellite 92 and the ground satellite antenna and base station 92B utilize trunk line protocol 95X to mix thousands of calls, using multi-PHY communications across multiple bands within client link 95Z. This ensures hypersecure communications for clients, making it difficult for hackers to identify and interpret specific calls.

Another example of data packets used in multi-PHY last link routing is shown in Figure 58, where the SDNP client 1400 is configured to connect, for example, an Ethernet wired or fiber link running protocols 100BASE-T and 1000BASE-T, respectively. It communicates with router 1402A through two separate PHY connections including (24A and 24B). The router 1402A is again connected to the SDNP gateway 1401 through a gateway link 1414. Both Ethernet packets specify the source IP address 445, the client device as IP C _1,1 and the destination IP address 446 of the SDNP gateway 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} . Includes. An Ethernet packet (B) routed across a PHY realized by wired or fiber link 24B has a MAC destination address 182 containing MAC R and MAC C _1,2 forming an alternative PHY connection. Includes another MAC source address (183).

A change in the source media address from MAC C _1,1 to MAC C _1,2 redirects the Ethernet communication from the 2.6GHz 100BASE-T connection to the 1000BASE-T connection. In operation, data packets from SDNP client device 1400 are fragmented and then assigned to SDNP payload (A) and SDNP payload (B) according to the SDNP algorithm and shared secret. Fragmented data transport across multi-PHY last links is a SDNP payload (A) carried by an Ethernet packet (A) over a wired or fiber link (24A) and an Ethernet packet (B) over a wired 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 Figure 59, where the SDNP client 1400 uses WiFi protocols, for example, 802.11n at 2.4 GHz and 802.11ac at 5 GHz, respectively. It communicates with the WiFi router 1402W through two separate PHY connections including links 29A and 29B. Router 1402W is again 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 destination IP address 446 of the SDNP gateway as IP M _0,0 . A WiFi packet (A) routed across the PHY realized by WiFi link 29A has an Exmeter MAC radio source address 236 containing MAC C _{1, 1} , a MAC radio receiver destination address containing MAC W ( 235), and a MAC network destination 237 including MAC R. WiFi packets (B) routed across the PHY realized by WiFi link 29B have an Exmeter MAC radio source address 236 containing MAC C _{1, 2} , a MAC radio receiver destination address containing MAC W ( 235), and a 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.6GHz WiFi radio to the 5GHz transceiver. In operation, data packets from SDNP client device 1400 are fragmented and then assigned to SDNP payload (A) and SDNP payload (B) according to the SDNP algorithm and shared secret. Fragmented data transport across multi-PHY last links is achieved with SDNP payloads (A) carried by WiFi packets (A) over WiFi link 29A and WiFi packets (B) on WiFi link 29B. It consists of SDNP payload (B).

Another example of data packets used in multi-PHY last link routing is shown in FIG. 60, where SDNP client 1400 supports, for example, 4G/LTE at 1.8 GHz and 4G/LTE protocols at 900 MHz, respectively. communicates with cell tower 1402Q through two separate PHY connections including cellular links 28A and 28B. Router 1402Q is again 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, the client device as IP C _1,1 and the destination IP address 446 of the SDNP gateway as IP M _0,0 . Cellular packets (A) routed across the PHY realized by cellular link 28A have an Exmeter MAC radio source address 300A containing MAC C _1,1 and a MAC cell tower destination 300B containing MAC BS. ) includes. Cellular packets (B) routed across the PHY realized by cellular link 28B have an Exmeter MAC radio source address 300A containing MAC C _{1 and 2} and a MAC cell tower destination 300B containing MAC BS. ) includes.

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

As mentioned above, multi-PHY communication may also include different media. In such cases, the data packet for each connection must be formatted according to the layer 2 protocol for the corresponding physical media. For example, Figure 61 shows hybrid last link communication including Ethernet and WiFi, where SDNP client 1400 uses Ethernet wired or fiber, for example, using 100BASE-T and 802.11ac at 5 GHz, respectively. It communicates with WiFi router 1402W through two separate PHY connections including link 24A and WiFi link 29B. Router 1402W is again 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 destination IP address 446 of the SDNP gateway 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. WiFi packets (B) routed across the PHY realized by WiFi link 29B have an Exmeter MAC radio source address 236 containing MAC C _{1, 2} , a MAC radio receiver destination address containing MAC W ( 235), and a 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 SDNP client device 1400 are fragmented and then assigned to SDNP payload (A) and SDNP payload (B) according to the SDNP algorithm and shared secret. Fragmented data transport over multi-PHY last links is carried by SDNP payloads (A) carried by Innernet 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 communications including WiFi and cellular communications, where SDNP client 1400 spans two separate PHY connections to two different wireless base stations, specifically 802.11n operation at 2.4 GHz. over a WiFi link 29A to a WiFi router 1402W, and a cellular link 28B to a cellular base station 1402Q operating 4G/LTE 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 destination IP address 446 of the SDNP gateway as IP M _{0, 0} . A WiFi packet (A) routed at the PHY layer over a connection containing WiFi link 29A has an Exmeter MAC radio source address 236 containing MAC C _1,1 and a MAC radio receiver destination containing MAC W. Address 235, and MAC Network Destination 237, including MAC R. The cellular routed B as a PHY layer connection realized by WiFi link 29B includes a MAC source address 300B containing MAC C _{1, 2} and a MAC 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 WiFi LAN to the cellular network. In operation, data packets from SDNP client device 1400 are fragmented and then assigned to SDNP payload (A) and SDNP payload (B) according to the SDNP algorithm and shared secret. Fragmented data transport over multi-PHY last links is achieved by SDNP payloads (A) carried by WiFi packets (A) over WiFi link 29A and cellular packets (B) on cellular link 28B. It consists of SDNP payload (B).

Another form of multi-PHY communication involves a physical medium that can support many channels of different frequencies and uses separate protocols for different data packets. Such an implementation may be facilitated using a DOCSIS3-based cable distribution system running SDNP software. The OSI communications stack for an SDNP-based DOCSIS3 cable distribution system is shown in Figure 63, which includes layer 1 PHY connectivity, layer 2 data links, and cable modem end device CMTS 101, as well as examples of cabled devices, e.g. For example, it includes an overlapping layer 3 network for both a cable modem CM (103) or a 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). Includes an associated layer 1 PHY network interface 361. 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 forwarding function 370, specifically into link level control (LLC) 369. 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, providing rudimentary packet security and primarily preventing unauthorized viewing of content such as pay-per-use unicast broadcasts.

The layer 1 PHY cable interface 362 then transmits the data frame to a cable modem (CM) 103 or set-top box (STB) via a distribution network 102, including coaxial cable 104 or optical fiber 91. Transmit to the corresponding layer 1 PHY cable interface 363 in 102. Cable interface 363 represents the PHY layer of a cable network interface, shown as the OSI communications stack 379 of a cable modem (CM) 103 or set-top box (STB) 102. Upon receiving the data packet, cable MAC interface 371 then interprets the cable MAC address, passes the payload to link security 372 for decryption, and finally to the hardware independent link layer control 802.2 LLC (802.2 LLC) for interpretation. 373). Input data to the CM or STB cable network communication stack is then transmitted to the CM or STB device interface communication stack via transparent bridging (374), specifically to the device independent link layer control 802.2 LLC (375) according to the specifications for IEEE 802.2. is delivered to The packet is then passed to the HSD & IPTV MAC block 376 or the WiFi 802.11 MAC block 377 to update the packet's MAC address. For WiFi communications, 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 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 the connection from the CMTS to any number of cable modems (CMs). Within the CMTS communications stack 378 and within the CM communications stack 379, data packets are sent to the OSI Layer 3 layers (360A and 360B) using IP addresses recognized by the cable network or by DNS name servers on 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 not commonly used, as connected devices that are not enabled by SDNP software or firmware must use the SDNP datagram routing address. This is 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 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. . In this respect, cable communications 102 is closer to an SDNP real-time network than is the case with the Internet. Because the cable modem has interoperability with both the Internet and cable networks as a client, or end-communications device, the Layer 4 transport layer 1420B within the OSI communications stack 379 of CM 103 or STB 102 provides real-time It uses UDP for operation and TCP for Internet data. Such use is problematic for OTT carriers that use 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 be done. This problem does not occur with SDNP-based cable modems - when the CM or STB is running SDNP firmware or software, the SDNP software is, in context, guaranteed to use TCP (for software and files) and, For real-time data, decide when not to.

The application layer, i.e. OSI layers 5 through 7, lies on top of the transport layer 1420A in CMTS 101 and on top of the transport layer 1420B in CM 103 or STB 102. In CMTS 101, these applications typically include communications tasks such as SNMP 1431A, an Internet-standard protocol for collecting and configuring information connected devices over IP networks. Other features 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 dynamically generated (non-static) IP addresses, default gateways, and subnet masks. . Although Internet generation specific, i.e. the function of dynamic IP address generation for IPv4 or IPv6, similar to NAT gateway or SNMP, is generic and DOCSIS3 cable system for both CMTS (101) and CM (103) or STB (102) The same can be applied to .

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

* Act as a pass-through without interpreting the SDNP payload 1430, in which case the CM 103 must be enabled to open and read the SDNP payload, i.e. the CM 103 must be an SDNP client.

* Acting as a last mile remote SDNP gateway, i.e. interpreting the content of the SDNP payload and converting the content into DOCSIS3 specific messages (including link security) for forwarding to the CM 103. In such cases, CM 103 does not require the SDNP client software or firmware to be operational.

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

As shown, the OSI communication stack 379 for CM 103 and STB 102 is OSI layer 5 including the communication-related apps SNMP 1431B, DHCPv4 1432B, and DHCPv6 1433B described above. It includes numerous applications classified as Tier 7. Another function, the utility TFTP (1434B) or "Small File Transfer Protocol", is mainly used in DOCSIS3 as a means to download software from the CMTS over the cable network 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 on smart TVs. Other applications (shortened to "Otr" (1436B)) include gaming apps, diagnostics, IPTV apps, video recording functions, and others. SDNP firmware 1430B running on CM 103 or STB 102 extends all of the hypersecure secure last mile communications to users and last links, regardless of whether the CMTS 101 is running SDNP software. I order it.

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

Short codeword 394 includes payload 395A including data (A) and error correction 396A including FEC A. In the case of a long codeword 397, the payload is divided into multiple payload blocks 395A, 395B, and 395C, carrying data A, data B, and data C, respectively, The payload of includes its own error checking blocks 396A, 396B, and 396C, which contain corresponding data (FEC A, FEC B, and FEC C). After error checking, the data delivered from DOCSIS3 includes data blocks 395A, 395B and 395C for long codewords and only data block 395A for 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 ( Adjacent IP datagrams containing data fields 435 containing 436), in this example, are merged into an IPv6 datagram. In this way, DOCSIS3 uses a packet-switched data protocol to flexibly deliver data over cable networks.

As shown in Figure 65A, data packets are carried within multiple channels, i.e., at different frequencies, across a hybrid cable-fiber network. In DOCSIS 3.0, data channels range from 5 MHz to 1,002 MHz, including analog TV signals 1440 (triangles), QAM data 1441, and a “diplexer” control channel 1443. In Phase 1 of DOCSIS 3.1, the frequency range is extended to 1,218 MHz, and in frequency bands beyond the existing channels primarily allocated to QAM, a DOCSIS3.1 data channel 1442 is added to assist OFDM modulation.

OFDM is preferred over the QAM modulation method because channels can be more tightly spaced. Comparing the modulation schemes, the QAM frequency distribution (1445A) exhibits a wider tail of 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 drops by -50 dB, is 4.3 normalized frequency units 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, increasing 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 the available channels. Although the CMTS can allocate downstream communications and dynamic channel selection as needed, upstream communications require contention management to assist in cases where multiple CMs attempt to send data simultaneously. Therefore, each modem must request an uplink channel from the CMTS before transmitting data. This process is depicted in Figure 65B, which includes a sequence of communication operations between a CMTS 101 running SDNP app 1335L and a CM 103 running SDNP firmware 1335M. Routing of IP datagrams in multi-PHY communication uses IP addresses “IP CMTS” and “IP CM1” and multiple MAC addresses, e.g. “MAC CM1” for CM 103 and “MAC CM1” for CMTS 101. Use “CMTS1”, “MAC CMTS2”, “MAC CMTS3”, and “MAC CMTS4”. In the top figure showing a graph of frequency versus time, CM 103 transmits a request to transmit RQST 1445A on the designated channel.

If there is no response, a second RQST 1445B is sent, resulting in a response from CMTS 101 on a different channel in the form of a MAP data packet 1446. The contents of the MAP data packet 1446 indicate to the CM 103 which channels to use for transmission and for its upstream communications. 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 splitting of data transmitted simultaneously over two channels, shown in the central figure, is referred to as channel bonding. Channel bonding is a means to increase communication bandwidth and data transfer rate between CMTS and CM. This is also a dynamic way to ensure that unavailable bandwidth is not used. In the bottom figure, CMTS 101 responds by channel bonding four channels, 1448A, 1448B, 1448C, and 1448D, and transmitting data simultaneously but with different durations.

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

In last link communications, upstream data packet 1450A specifies "MAC CMl" as the source MAC address of the cable modem and the channel of frequency f ₁ as the PHY media, in this case MAC destination "MAC CMTS1". . Data packet 1450A containing the SDNP payload (A) occupies a total of three minislots, minislots 1, 2, and 3, although it carries a single data packet and payload together. 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 SDNP gateway nodes M _{0 and 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 a MAC destination address of "MAC CMTS2". Using these addresses, data packets 1450B and 1450C must be accompanied by a different frequency than data packet 1450A - in this case, frequency f ₂ and not frequency f ₁ . The actual value of the frequency is dynamically mapped by the CMTS 101 and is not specifically identified. Thereby, DOCSIS3 based systems represent a multi-PHY solution, whereby a single CMTS unit can communicate simultaneously over multiple frequencies and using multiple protocols such as 256 QAM or OFDM to a cable modem or set-top box.

Instead of allowing the CM and CMTS to decide which data packets will utilize a common carrier channel or frequency, as is typical in DOCSIS3 systems, according to the disclosed secure dynamic communication network and protocol for last mile communications, the 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 operations over the last link. Alternatively, the use of MAC addresses to perform multi-PHY communications may be replaced by other means, for example, if the CMTS facilitates other means of requesting specific channel assignments using command and control requests. You can.

Figure 65D depicts downstream data from CMTS 101 to CM 103, demonstrating 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 specifications of the MAC source address of the CMTS 101. As shown, data packet 1450G containing the SDNP payload (G) has a MAC source address “MAC CMTS6” corresponding to communication at frequency (f ₆ ) carrying data within minislots 15 and 16. Be specific. Data packet 1450H includes an SDNP payload (H) and specifies a MAC source address “MAC CMTS7” corresponding to communication at frequency f ₇ carrying data within minislots 17 and 20. Data packet 1450I containing SDNP payload (I) specifies MAC source address “MAC CMTS8” corresponding to communication at frequency f ₈ carrying data in minislots 21, 22 and 23 . Finally, the data packet 1450J containing the SDNP payload (J) specifies the MAC source address “MAC CMTS9” corresponding to communication at frequency (f ₉ ) carrying data within 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 approach, without channel contention or data collisions with concurrent upstream data.

HyperSecure Call Routing - HyperSecure Call Routing created in accordance with the disclosed secure dynamic communications network and protocol may be implemented using one of the following three methods for command and control.

* Triple-channel communication, where routing of calls or communiqués involves three sets of servers: SDNP Media Server for carrying audio, video or data files; controlled using an SDNP signaling server to select routing of calls, and an SDNP name server to store a dynamic mapping of phone numbers to their corresponding SDNP addresses;

* As a dual-channel communication, routing control of a call or communique is controlled by two sets of servers: SDNP Media Server to carry audio, video or data files; and using the SDNP Signaling Server to perform the functions of the SDNP Name Server for routing calls and mapping telephone numbers to their corresponding SDNP addresses;

* As a single-channel communication, data carrying, route planning and SDNP address maps are all run by a single set of servers.

In general, triple-channel communication provides greater immunity against cyber-attacks because one set of servers does not contain all the information about the call. However, in all cases, the SDNP network uses distributed processing to limit the information contained within any given server. Additionally, during data transport in single-, dual- or triple-channel communication, the SDNP media server is connected to a fourth type of server - a DMZ server. The DMZ server is used to house the SDNP shared secrets needed to process the SDNP data payload, 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 were modified or what logic or algorithms were used to process the data. Executable code and tables stored on the DMZ server are encrypted to prevent analysis of the code. Additionally, the DMZ server operates offline without being connected to a network or the Internet.

The figure below shows one example implementation of triple-channel SDNP communications and sequences used in initiating a call or sending a file across a network. The operation of dual-channel communication can be considered as a minor modification to triple-channel communication, where the SDNP name server functionality is merged into the signaling server. Single-channel communication involves integrating all three operations into a network of multi-function servers operating as SDNP communication nodes.

Although fragmented data transmission within the SDNP cloud is typically implemented using dynamically meshed routing, last mile communications are specifically designed to allow continuous data packets to (i) be routed to a single SDNP gateway, i.e. as single-path last mile communications; routed, or alternatively (ii) routed to multiple SDNP gateways, i.e. as multi-path last mile communications. Other last mile routing choices include dynamic source addressing and multi-PHY last link connectivity. These delivery options are specified within the IP data packet 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 takes within the last mile is not known. Instead, the middle path is determined by the actions of routers, devices owned by local network operators, mobile network operators, and network service providers serving the last mile, and not by the SDNP signaling server. Last mile communications are thus similar to a jump rope, where the two ends are fixed but a maze of specially shaped passages connect them.

To reiterate briefly, the terms single-path, multi-path, and meshed-path communication refer to the passage of media packets, i.e., the passage "content", across the callers, while triple-channel, dual-channel , and the term single-channel communication refers to a command and control system used to control transmission across a network of SDNP nodes. From the foregoing, the following set of figures illustrate the sequence of steps, or "process", used to make a call or initiate a communique in accordance with the disclosed secure dynamic communications network and protocol.

Figure 66 shows a single-channel communication configuration including SDNP client 1600, IP routers 1602A, 1602B, and 1602C signaling server 1603A, SDNP name server 1604A, and SDNP gateway 1601. This is a schematic diagram of the 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 SDNP communication nodes that are used to facilitate network communication with names and IP addresses. Network connection 1610 facilitates the 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 the router's IP address is not used as the source or destination address in IP datagrams, 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 unique identity, but this aspect is not relevant to the description of IP network layer 3 call routing. SDNP signaling server 1603A (node S) is connected to SDNP name server 1604A (node NS) via network connection 1613 and to SDNP cloud node M _0,n via a number of network connections 1614. . Signaling server 1603A is also connected to other signaling servers (not shown) via network connection 1615.

Using an SDNP network, placing a call, i.e. establishing a “session”, involves the following sequence of steps, initiated from the SDNP client making the call, i.e. the “caller”:

1. Request an SDNP call (or call out)

2. SDNP address request

3. SDNP address delivery

4. SDNP routing instructions

5. Initiate SDNP call (or call out)

The first step, “Call Request”, is schematically depicted in Figure 67, where the caller, client 1600 with address “IP C _{1, 1} ,” sends a conduit 1610 with an IP datagram 1620. , 1616, and 1612) contact signaling server 1603A at address “IP S”. The datagram's command and control payload 621 includes Layer 4 data transfer using TCP to ensure data accuracy, delivery, urgency, security credentials, and contact information of the "called party" being called. Specifies a number of requested call parameters, including: For calls to other SDNP clients, or “SDNP calls,” this contact information includes the called client's credit identification (CID), data that resides in the client's SDNP phone directory. In the case of a “call out,” which is a call to a party other than the SDNP client, the contact information includes a telephone number. While the SDNP client's CID is inherently anonymous and known only to the SDNP name server, the phone number is not hidden. 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 the IP datagram 1620 cannot be encrypted, and if so, routers 1602A and 1602C cannot route the datagram.

The second step, “SDNP Address Request”, is shown in Figure 68, where the SDNP signaling server with address “IP S” sends the address “IP NS” via conduit 1613 with IP datagram 1622. Contacts the SDNP name server. The datagram's command and control payload specifies Layer 4 data transmission as TCP and includes the CID or encrypted phone number of the called party. For SDNP calls, name server 1604A translates the CID to the SDNP address of the client being called. In the case of a call out, name server 1604A decodes the telephone number of the called party and translates it into 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" to signaling server 1603A at source address "IP NS". .

Signaling server 1603A then uses the SDNP addresses of the caller and the called party to route the call between them, either as a hypersecure connection if the called party is an SDNP client, or as a hypersecure connection if the called party is not an SDNP client. Route to SDNP gateway. The process used to prepare routing instructions and distribute them to all media nodes necessary to complete the caller's connection is shown in Figure 70. As shown, the caller's delivery request included in the delivery and urgency fields of the C&C payload 1621A, once verified against the account information, can determine how to deliver the datagram, as shown by operation 1650. It is used to select . The delivery method, including normal, VIP, guaranteed, or special delivery, affects the routing of the packet or sub-packet (if the packet is split or fragmented). In VIP forwarding, for example, the fastest path is used for data transfer 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 fastest packets and ignoring late arrivals. Operation 1651 then, combined with the SDNP address data from C&C payload 1623A, maps the optimal path from the caller to the called party's SDNP address, or to the nearest gateway if the called party is not an SDNP client. do. Urgency request data contained within the C&C payload 1621A is used to reduce propagation delay in that order - package urgent operations 1652, including snail delivery (no rush), regular delivery, priority delivery, and urgent delivery. ).

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 to synthesize a routing command and control packet through operation 1660. These C&C data packets are delivered to the last mile participating communication nodes using TCP specified layer 4 transport, but contain routing information that uses UDP as its layer 4 transport protocol when used in real-time data delivery. For example, last mile routing created based on 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 created as an IP datagram (1625). The IP datagram 1625 is delivered to the SDNP client using a TCP data transmission, but the C&C payload 1626, referred to as “last mile routing U1,” contains data used to route packets in real time. Requires the use of UDP as a layer 4 transport mechanism. SDNP C&C packet composition operation 1660 also generates many other C&C messages that are delivered to nodes within the SDNP cloud as TCP data packets. One example of a cloud-directed data packet is IP datagram 1627A that includes a C&C payload 1628A that is used to route data from SDNP M _0,0 to SDNP M _0,1 . As shown in Figure 71, these SDNP routing instruction packets are sent to media nodes including client nodes 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 beginning of a call is shown in Figure 72, where a media SDNP datagram 1630 containing SDNP data, e.g., sound, video, text, etc., is transmitted on an IP header containing a C&C data packet 1626. Attached, from IP C _1,1 to IP M _0,0 from SDNP client 1600 over last link network connection 1601 to routers 1602A and 1602B and finally across gateway link 1611 to SDNP gateway It is routed to (1601). The identification tag, security zone, preamble, and SDNP data fields together make up the payload of the SDNP media packet contained within the media SDNP datagram 1630.

Routing of the above-described SDNP calls involving mobile phones 32 running SDNP app 1335A, i.e., hypersecure calls from SDNP gateway M _0,0 to SDNP client C _7,1 , is shown in the simplified network diagram of FIG. 73A. It is shown as SDNP datagram 1631A containing 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 - IP address "IP M _0,0 " for last mile communication, and 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 thus the content contained within the SDNP media payloads (A, B, and C) - sound, video, and text are distinctly different, 20 May contain content from several different conversations or communiqués. Mechanisms for data routing and packet security within the SDNP Cloud are disclosed in U.S. Application No. 14/803,869, entitled “Secure Dynamic Communication Network and Protocol,” which provides for the encryption and content of data packets moving anonymously through the SDNP Cloud. describes how to change dynamically and continuously and only converge within the client's device.

Accordingly, SDNP datagram 1631B containing media SDNP payload (B) and header 1628B is routed between media nodes with IP addresses IP M _0,4 and M _0,f . Data exiting the SDNP cloud through 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, the zone containing the last mile. IP datagram 1632 is then routed via the last mile via wired or fiber link 24 to network router 27 and then via cellular network 25 and cellular link 28 to mobile phone 32. ) is routed to. Because the mobile phone 32 is an SDNP client, communication over the last mile remains 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 “call out” is shown in Figure 73B . Although routing through the SDNP cloud uses the same SDNP datagrams (1631A and 1631B) as calls to SDNP clients, SDNP gateway 1601B is the last server running SDNP software. Accordingly, last mile communication in call out uses IP datagrams with non-SDNP payload, i.e. IP datagram 1635 is transmitted from gateway IP M _0,0 to PSTN at IP address IP C _7,9 . It is routed to and carries sound in VoIP format. The PSTN then converts the VoIP call format to a traditional phone number using the phone # and analog sounds in sound packets 1636. 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 to client 1600 via data links 1612 and 1610. , a C&C data packet 1627X sent to SDNP gateway 1601X via data link 1614X, and a C&C data packet 1627Y sent to SDNP gateway 1601Y via data link 1614Y. Other C&C data packets (not shown) are transmitted via data link 1614X to other servers hosting media nodes. From address “IP S”, a C&C data packet 1625X is sent to address “IP C _{1, 1} ” containing a C&C payload including last mile routing (U1). Last mile routing (U1) has two different routing instructions - a routing instruction from “IP C _1,1 ” with tag 1 and preamble 1 to “IP M _{0, 0} ” and “IP C with tag 2 and preamble 2”. Contains different routing instructions from " _1,1 " to "IP M _0,1 ". Shown as an example, a C&C data packet sent to a communication node in the SDNP cloud is sent from "IP S" containing the instructions SDNP Cloud Routing 1 to "IP M _{0, 0} ", and includes SDNP Cloud Routing 2. Includes those transmitted as “IP M _0,1 ”.

SDNP Group Call - Last mile media packet routing from an SDNP client 1600 to multiple SDNP gateways , shown in FIG. 75A, includes each header 1626X and 1626Y and an SDNP media payload SDNP data ( It contains two data packets (1630X and 1630Y) containing SDNP data (X) and 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 from address “IP Routed from C _1,1 "to "IP M _0,1 ".

As shown in Figure 75b, data flowing backward 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 a data packet 1630U containing the destination address "IP C _0,0 ". At the same time, the data is also a data packet (1630V) containing a 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 reproduce the message text or voice (sound).

C&C data packet delivery of routing instructions can be expanded to initiate three-way or group calls, group messaging, and other multi-client communications. In such group communiqués or “conference calls,” client messages are sent simultaneously to multiple recipients. This group function is initiated by the caller, and the caller's request for a group call first defines the group of clients it wishes to contact, and then determines, by the signaling server, how to handle the routing of data packets associated with a particular group call. , instructs the requested media node. An example of a group call routing instruction is shown in Figure 76, where signaling server 1603P sends routing instructions to SDNP client 1600A over data link 1614A and to many media within the SDNP cloud over data link 1614Z. Communicates with 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. The C&C data packet provided by the example TCP data packet 1627Z is transmitted via 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. It is distributed simultaneously throughout the whole, where y represents an integer variable. Collectively, the SDNP cloud routing instructions establish packets that are routed from the caller's gateway through the 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 within different geographic areas and may be within separate security zones, such as zones U7 and U9. In some cases, these clients may be far enough 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. The C&C data packet 1625M communicates a last mile routing indication (U9), for example, from the signaling server located at “IP S4” to the 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 via data link 1614H from signaling server 1603Q located at "IP S4" to the client located at address "IP C _7,1 ". It is transmitted to (1600H).

Signaling servers 1603P and 1603Q located at nodes S1 and S4 also exchange information as C&C data packets via data link 1613z. This information configures which portions of the routing will be performed by signaling server 1603P and which portions will be performed by signaling servers 1603Q, essentially splitting the routing task across multiple signaling servers. It is used. In the example shown, signaling server node S1 manages 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 communiqué is shown in Figure 77A, where the voice accompanied by SDNP data 1 in data packet 1630A is connected to the caller with IP address "IP C _{1, 1} " by header 1626A. It is routed to the nearest SDNP gateway media node M _0,0 . Data packets are re-packetized and sent to gateway media nodes M _0,4 and M _0,8 for SDNP cloud transmission. The path packet routing taken in the SDNP cloud is unknown to any of the conference call participants, has no central control, and changes dynamically according to network conditions. In this example, all SDNP data packets within the SDNP cloud utilize fragmented meshed data transmission with anonymous addressing and dynamic encryption, as well as dynamic scrambling, mixing, separation, and junk data insertion and removal. In the example shown, the cloud transport directs incoming communication at SDNP gateway node M _0,0 to another gateway, in this case SDNP gateway nodes M _0,4 and M _0,8 .

The data packet 1630H accompanying the caller's voice, i.e., SDNP data 1, exits gateway node M _0,4 and uses header 1626H to access the "IP M _0, " using zone (U7) security credentials. It is routed from the media node at _"4 " to the client (1600H) at "IP C _7,1 ". Header 1626H was supplied to client 1600A in C&C data packet 1627A prior to preparing the media data packet, as illustrated in FIG. 76. In this way, all media packets carrying real-time data can be prepared without delay when the content is ready for data transmission. In real-time networks, great 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 transmitted from gateway media node M _0,8 to client IP addresses “IP C _9,1 ” and “IP C _9,4 ” to zone (U9) conference call participants. , that is, to SDNP-clients (1600M and 1600L). These last mile data packets (1630M and 1630L) include identification packet tags, tag 8 and tag 9, used to recognize content associated with the same conversation, preamble 9 information used to carry SDNP embedded instructions, and a key. , seed, etc., and headers 1626M and 1626L that specify an “L4” data field used to specify layer 4 transmission as UDP. Although the data routing instructions delivered by the signaling server utilize the TCP transport protocol to ensure accuracy, the media packet content represents real-time data and therefore advantageously utilizes the UDP layer 4 protocol instead of TCP.

Figure 77B shows the same conversation in which content from zone U7 client 1600H is generated - that is, when client C _7,1 begins speaking. To match 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 users, 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 data packets from SDNP client node C _1,1 are transmitted to other call participants, including client node C _7,1 , with client node C responding to client node C _1,1 It should be understood that _{7 and 1} can occur simultaneously.

At network level 3 of last mile communication, data collisions in opposite direction traffic do not occur. However, at physical and data link layers 1 and 2, last mile communications may include time sharing to prevent contention for the same communications link. However, this coordination occurs quickly, so that the communication is likely to appear in a completely synchronous manner, with no delays within the voice packets. It should be noted that in both Figures 77A and 77B, the direction of data flow shown for the zone U9 client remains unchanged, i.e. data flows from the cloud to the client. However, in Figure 77C, zone (U9) client node C _9,1 starts speaking. In this case, client nodes C _9,4 , C _1,1 , and _C7,1 all become recipients of the voice, i.e. SDNP voice data 6.

In an alternative embodiment shown in FIG. 78, group calls 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 Figure 77A, the voice accompanied by SDNP data 1 in data packet 1630A is transmitted by header 1626A from the caller with IP address "IP C _{1, 1} " to media node M. Routed to the nearest SDNP gateway containing _0,0 . Data packets are re-packetized and sent to gateway media nodes M _0,4 and M _0,8 for SDNP cloud transmission.

In the example shown, the cloud transport directs _incoming communication at SDNP gateway node M _0,0 to another gateway, in this case SDNP gateway nodes M _0,4 and M _0,8 . The data packet 1630H accompanying the caller's voice, i.e. SDNP data 1, exits the gateway node M _0,4 and, using the header 1626H, uses zone (U7) security credentials to "IP M _0, " It is routed from the media node at _"4 " to the client (1600H) at "IP C _7,1 ". SDNP Data 1 payload is also delivered to conference call participants through gateway media node M _0,8 . Last-mile communication from these SDNP gateways can be achieved through two different types of connections, specifically hypersecure connections to SDNP-clients (1600M) and PSTN 1, which includes traditional phone systems that do not utilize VoIP or packet protocols. Includes a secure “call out” connection. The last mile data packet (1630M) delivered to a zone (U9) SDNP client at address "IP C _9,1 " carries an identification packet identifier tag 9, SDNP embedded indication, which is used to recognize content associated with the same conversation. It includes preamble 9 information used to do this, key, seed, etc., and a header 1626M that specifies the "L4" data field used to specify layer 4 transmission 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 can be intercepted by packet sniffing. The telephone switch system, PSTN 1, then transmits these unsecured IP packets to the telephone, as shown by POTS data 1636, containing the called telephone number followed by a continuous analog circuit connection between telephone 37 and PSTN 1. Converts to analog POTS phone connection for 37. Because these and any other call out connections are not hypersecure, content carried by call out last links is at risk of hacking, wiretaps, and other surveillance techniques. Unless some hierarchical structure is implemented that dictates the clients' access privileges, 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 Figure 79A, where a group call is made to SDNP network client nodes C _1,1 , with callout participants at phone numbers “Ph #1” and “Ph #2”. Includes hypersecurity participants on C _7,1 , C _9,1 , and C _9,4 . As shown, SDNP client C _{1, 1} is the group host, SDNP clients C _7,1 and C _9,1 are participants, meaning they listen and talk, and SDNP client C _9,4 is the “listener.” This means that they can listen to the call but cannot speak or the participant can listen in. The participant at the call out phone number "Ph #1" is also the participant who can listen and speak, while at "Ph #2" the participant can listen. Participants in the callout are only authenticated as "listeners" and cannot speak in the group call. The group host, when setting up the call, stipulates these listening-speaking 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, that is, any caller approved by the host, can listen to the call. A caller who wishes to hack a call but is not authorized by the host has no means of connecting to or breaking into the call, or even the ability to determine whether the call originates. The same method can be applied to group chats, where participants can read and write messages, but observation-only members can only read comments and cannot insert their text into the chat.

When using authentication and identity verification to control network access made in accordance with this disclosure, the SDNP system provides privacy features that are not available in traditional group chats and group calls. This feature is created by selecting private mode, for example by clicking on the lock symbol or other privacy icon, before writing or speaking text. In such cases, communications are sent only to authenticated SDNP clients, not to SDNP clients whose identities have not yet been verified through authentication, and not to any callout listeners or participants on unsecured devices. This point is set forth in the foregoing table, wherein in private calls 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 marked ", all SDNP clients can listen, 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 can hear and speak in private mode. In this way, a group call with a mix of SDNP clients with positive identities, and call-out connections to unknown parties can inter-join in the public portion of the call, but without exposing confidential information to the call-out device. A “call out” caller can be removed from the private discussion simply by clicking on any SDNP participant's private icon before speaking or composing text. At the end of the private discussion, the private button is released and they reconnect. During times when a callout caller is not connected, i.e. essentially placed on “call waiting,” the SDNP system can 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 callout 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 not forwarded to the chat group. If the participant clicks the lock or privacy icon before sending the message, the message will be sent only to the SDNP client and not to all callout clients. At the SDNP client receiving the private message, if they have authenticated its identity, the message will be visible for reading. If they have not authenticated their identity, the message will be hidden, covered, hidden, or displayed with an icon, for example a padlock, until an observer authenticates to confirm its identity.

By combining identity verification with privacy privileges regulated by SDNP network system authentication, hacking of the device is insufficient to open private texts or listen to private calls, even in group chats and group calls. These features cannot be guaranteed by relying solely on device security parameters - information that can be hacked locally. System parameters are much more difficult to spoof, because 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 implementation of group calls and group chats. This specific embodiment of hypersecure last mile described in the table shown in FIG. 79B is referred to herein as hyper-private calling or hyper-private chat. Hyper-privacy requires caller or message verification against the following four criteria:

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

* The call or text, whether call, text, video, etc., must be selected a priori as a hyper-private communiqué.

* The recipient of a communiqué on a group call or chat must have an authenticated connection to ensure its identity.

* The recipients of any hyper-private communiqué must be pre-selected as either “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 above, the fourth criterion, that 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 limits 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 the group call. In contrast, SDNP client C _{9, 1} is designated only as a participant, but not as a private participant. By definition, call participants or listeners cannot be registered as private parties.

As in the previous example, during a regular call all participants, namely 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. In addition, you can speak and write text at any time, while "listeners", which include clients C _9,3 and Ph #2, can listen to all conversations and see text, but cannot speak or send messages in group calls or chats. I can't. However, in a hyper-private call, selecting the switch or icon to designate a hyper-private communique not only automatically blocks all unauthenticated parties in the group call or chat, it also blocks all parties other than the "private" party. Disable it. This also disables all call out connections and all unauthenticated users. Therefore, in operation, when any private participant selects the privacy icon, only the private participant (including the private group host) can see, read, speak, or write text to the group. All other parties' microphones and speakers are muted, and likewise no text or attachments to the group can be received or sent. Specifically, in hyper- _private mode, once authenticated, both clients C _1,1 and C _7,1 can hear and speak as well as read and send text, while private client C _9,4 cannot listen to the conversation. Or you can only read group text.

With the last mile routing control capabilities described above, group calls and group chats can be managed in any number of ways. For example, a group call host can determine who can join the call or group, who can speak or write 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 communiqué 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 is eligible for parts of a hyper-private communiqué, i.e., who is identified as a private participant or listener, and who is not, can be structured 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-mandated" hyper-private group communications, the SDNP network operator predetermines who is a private caller and who is not. In rule-based hyper-private group communication, the SDNP network specifies rules for determining who is eligible to be a private caller and who is not. These rules could be based on a company employment list, for example, only vice presidents and above can participate in hyper-private calls. In government and security agencies, criteria may be set by national security clearance, passport number, police badge number, etc. The SDNP-based last mile communication method defined herein may support any of these example scenarios, or may utilize any other criteria to divide the population into two groups, thereby providing hyper-private communiqué access. Branches constitute groups and non-branches.

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

One challenge for group calls is when everyone wants to talk at the same time. Overlapping speech can be confusing, difficult to hear, and also cause unwanted noise. This problem can be solved by using the push-to-talk feature, a feature that mimics a walkie-talkie or CB radio. In 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 in listen-only mode. As shown in the table in Figure 80A, in regular PTT conversations, when the host presses the PTT button, they have priority over group calls, as shown in the column marked Host PTT, even when other talkers press their talk buttons. Takes priority over all other callers. All other callers' microphones are automatically muted, including those on the call out line, and you become the only listener. If the host does not press his PPT button, the PTT capabilities are passed on 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, such as C _9,4 and Ph #1, can hear the PTT conversation during the whole group call, but their microphones are muted.

When utilizing SDNP last mile capabilities to identify authenticated callers to the network, PTT features can be extended to private push-to-talk capabilities. Whenever the privacy feature or icon is selected, all unauthorized parties are removed from the group call and their speakers and microphones are silenced. Regulatory call out connections cannot be authenticated and are therefore also muted. Silencing is two-way and prevents the excluded party from hearing the conversation, but it also disconnects the excluded participant's microphone. In the case of an authenticated party, the operation proceeds identically to a regular PTT, where the host has priority to speak, otherwise any authenticated participant can take the PTT talk feature in order of execution.

The table in FIG. 80B shows that hyper-private group calling can be extended with PTT functionality. In regular operation, PTT functionality is the same as previously described. However, in hyper-private mode, only authenticated parties previously designated as private participants or private listeners can participate in the hyper-private conversation. 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 silenced while operating in hyper-private mode. In this way, access to multiple parties within a PTT group call can be clearly controlled. Silencing is the process of excluding some participants (e.g., call-out listeners) from receiving data packets carrying the sounds of the conversation, while continuing to supply data packets for non-silenced participants. In this disclosed method, data packets are sent individually to all participants in a normal conversation and only to a subset of the list when silencing 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 to all users using encryption, where all participants have a copy of the decryption key. In private or silent mode, data packets broadcast to users use different encryption, where only selected users share the decryption key. Anyone who has the key can participate in the call, and anyone without it is excluded. The advantage of using broadcast packets is that last mile communications require narrower bandwidth than sending separate packet requests. In another embodiment, a single packet is sent to the gateway, and the signaling server replicates the packet for distribution to all participants in normal call mode and to select callers in private or silent mode.

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

This simplified explanation, in which storage is a communication that stops mid-packet delivery, is more technically accurate than one might initially think. In the aforementioned US application Ser. No. 14/803,869, temporary buffering of data packets until the arrival of other packets was specifically disclosed and operationally described. Although buffering within the nodes of the SDNP cloud occurs on the scale of milliseconds rather than months, the SDNP system has the ability to hold or hold data without losing the information being restored to restore the original content. Of course, such a simplified implementation does not have certain features necessary for long-term file management, such as directories, menus, file recycling, refreshing security credentials, and other such features.

An example of data transfer from a client to a fragmented data storage network is shown in Figure 81. As shown, the SDNP client 1700A with IP addresses IP C _{1, 1} sends a series of data packets through the SDNP cloud to the corresponding IP addresses IP F _7,1 , IP F _9,1 , and IP F _9, Send to SDNP file storage servers (1700H, 1700M and 1700L) with ₄ . 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 transmission uses TCP instead of UDP. The packet includes tag 1, tag 2, and tag 3, in the case of data packets (1730H, 1730L, and 1730M), and tag The payload portion of each packet carries specific data, for example within three partial fragmentation files SDNP File 1, SDNP File 2, and SDNP File 3. Security credentials within the last mile use zone (U1) information with corresponding preamble 1.

When data packets enter the SDNP cloud, they are routed to different destinations depending on their identity and instructions from a signaling server (not shown). Data packet 1730H with header 1626H and tag 1 carrying 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, a 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} and is in the same mesh as data packet 1730L with the ID of tag 2. It is not necessary to use a routing channel. SDNP gateway node M _{0, 8} then routes packet 1730M with tag 3 to file storage node F 9, ₁ , also using the security credentials for zone U9.

In this way, SDNP file 1 is passed to file storage node F _7,1 with the security credentials for zone (U7), while SDNP file 2 and SDNP file 3 both use the security credentials for zone (U9). It is delivered to the file storage nodes F _{9, 4,} F _{9 , and 1,} respectively. 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 owning the data does not have access to the security credentials used to store the data, it is difficult for a hacker to steal the contents of the file, which is ) they are fragmented into incoherent and unusable pieces, (ii) all files use different security credentials for scrambling and encryption of data, and (iii) they are stored in different locations and on different last mile networks. and (iv) it is impossible to know that various stored data come from the same SDNP source file. The area containing the file storage servers is also referred to as the “storage side” area to distinguish it from the area where the file owner is located, i.e. the area 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 “storage” zones.

Applying the SDNP network communication protocol to file storage is further illustrated in the flow diagram of Figure 82A, which illustrates the "write operation", which is a general step in which an SDNP client and file owner stores, i.e., writes, the data to a hypersecure file storage server. It is shown. As shown, SDNP client 1700A performs an SDNP split operation to create a multi-part file or document, which in the example shown is a three-part file containing parsed files 1706A, 1706B, and 1706C. Using 1057 and the parsing function 1052, the unparsed file 1705 is split. Optionally, the contents of the file may be scrambled before splitting. These three files are then transmitted across the SDNP network as unrelated data or communiqués. The steps involved in routing to the final destination across the SDNP network utilize the same methods described herein for hypersecure last mile communications and previously described for meshed routing in the SDNP cloud. Specifically, last mile hypersecure transport 1707 utilizes security credentials per zone (U1). Hypersecure meshed transport 1708 within the SDNP cloud utilizes zone (Z1) security credentials. Although these hypersecure data transfer operations are represented in large blocks, packet transfers are actually performed using a decentralized system with no master key, no central control, and no access to the packet contents, as described in this disclosure. Occurs across networks of routers, servers, and soft-switches.

Although zone (U1) last mile routing may involve transmitting data packets across an infrastructure with a limited number of routing choices, multi-PHY last link routing, routing of sequential packets to multiple SDNP gateways, and The methods described for hypersecure last mile communications, including the use of dynamic source addressing, i.e., renaming of the client's IP address, can be equally applied to hypersecure file storage operations. Once data packets reach the SDNP cloud, their transmission uses anonymous mesh-like routing with dynamically scrambled encrypted data, preventing monitoring of file content or even metadata associated with the communication. Finally, all three data packets are sent 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 within 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 in SDNP file storage nodes F _9,1 and F _9,4 . This way, no single file contains all the data, and a single security credential does not require unlocking all the component files to recreate the original.

In the “read operation” of a hypersecure stored file shown in Figure 82B, the sequence of data transfer between the file storage server and the SDNP client, i.e. the file owner, is reversed. Reading a hypersecure file involves undoing the process in which the file was originally stored in the reverse order, which process includes (i) identifying the parsed file within each storage server; (ii) each parsed file; (iii) removing local storage security provisions from the files; (iii) transferring each restored parsed file back to the SDNP client, across the SDNP cloud and hypersecure last mile; (iv) transferring the parsed files to various including collecting from communiqués, and (v) merging (de-splitting) parsed files using the client's local security credentials to restore the original files, and, if applicable, scrambling. do.

To further explain the described hypersecure file "reading operation", in order to restore parsed file 1, the relevant content of the file storage server 1700H stored within the file storage node F _7,1 is stored in the section U7 file security operation ( 1709A). Independently of parsed file 2 or 3, parsed file 1 is processed by a hypersecure transfer operation 1708 using zone (Z1) security credentials, followed by a zone (U1) last mile hypersecure transfer operation (1707). is communicated back to SDNP client node C _1,1 using the example cloud shown in simplified form. At the same time, to restore parsed file 2, the relevant content of file storage server 1700M stored within 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 processed by a hypersecure transfer operation 1708 using zone (Z1) security credentials, followed by a zone (U1) last mile hypersecure transfer operation 1707. is communicated back to SDNP client node C _1,1 using the SDNP cloud, shown in simplified form. Meanwhile, to restore parsed file 3, the relevant content of file storage server 1700L stored within file storage node F _9,4 is processed using zone U9 file security operation 1709C. Independently of parsed file 1 or 2, parsed file 3 is processed by a hypersecure transfer operation 1708 using zone (Z1) security credentials, followed by a zone (U1) last mile hypersecure transfer operation 1707. is communicated back to SDNP client node C _1,1 using the SDNP cloud, shown in simplified form.

Independent packet routing of the three component parsed files during a read operation is illustrated in Figure 83, where server node 1700H carries SDNP file 1 and receives data packet 1731H with ID "Tag 7". , using TCP transmission, the file is sent from the storage address IP F _7,1 to the SDNP gateway server at the address IP M _0,4 . Packet 1731H includes a header 1727H containing preamble 7 and other information previously provided in command and control packets conveyed by the signaling server in tri-channel communication.

Meanwhile, server node 1700L, using TCP transmission, transfers data packet 1731L carrying SDNP file 2 and having ID “tag 9” from file storage address IP F _9,4 to address IP M _0,8 . It is transmitted to the SDNP gateway server. Packet 1731L includes a header 1727L containing a preamble 9 and other information previously provided in command and control packets conveyed by the signaling server in tri-channel communication. Independently and simultaneously, server node 1700M, using TCP transport, transfers data packet 1731M carrying SDNP file 3 and with ID “tag 8” from file storage address IP F _9,1 to address IP M _{0 ,8} also transmits to the SDNP gateway server.

Packet 1731M includes a header 1727M containing a preamble 9 and other information previously provided using command and control packets delivered by the signaling server in tri-channel communication. Three data packets (1731H, 1731L, and 1731M) access the SDNP cloud using zone (Z1) security credentials until they finally exit the SDNP gateway M _{0, 0} hosted by the SDNP cloud server 1701U. Traversing, the data packet from the SDNP cloud server _1701U is sent to the client device ( 1700A) and are transmitted sequentially.

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

Rather than adding additional file server operations to secure stored data, the security operations 1709A, 1709B, and 1709C actually include last-mile hypersecure communication between the SDNP cloud and the 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 hypersecure in nature, including junk data injection and the use of data deception methods such as junk files, stored across distributed, non-volatile data drivers. Includes scrambling, fragmentation, and encrypted data. In addition to the data security methods described above, hypersecure storage as disclosed herein has no meaningful metadata, no traceability to file owners, no routing to deliver files, or no loss of components from the original source file. It uses anonymous file names, without the identity of any other file storage servers that maintain them.

Despite the physical implementation of the storage server, i.e., its Layer 1 PHY implementation and Layer 2 transport, interoperability over SDNP networks, the protocol can be changed very significantly without affecting storage functionality, access times, or global accessibility. You can. FIG. 84A shows a physical implementation of an SDNP file storage server, including a top view showing SDNP gateway 1701B connected to SDNP file storage server 1740A via router 27, as an example. For greater network performance and additional resilience to attacks, the middle diagram shows a direct connection between the SDNP gateway 1701B and the SDNP file storage server 1740A using optical fiber 91 without an intervening router. As shown in the lower limit example, a file storage server may include a server controller 1740B and a large memory array with storage drives 1740C and 1740D. The drive may include any media including non-volatile memory based on a hard disk drive or flash drive. To further limit access, the SDNP Gateway and SDNP File Storage Server may be physically located in the same location and facility with only fiber links connecting them. They may even share a common space and may be physically locked, for example within a vaulted ceiling, with strict access controls and surveillance monitoring of anyone entering the facility.

Figure 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 saver's desktop 36 includes (i) a local file storage server 1740A accessed across a WiFi router 1352 connected to SDNP gateway node M _0,0 on server 1701A, (ii) ) can store distributed files across several devices, including (iii) a file storage server 1740B connected to SDNP gateway node M _0,4 , and (iii) a 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, laptop 35 , tablets 33 , and 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 depicted in Figure 85A. As shown, client device 1700A, including SDNP client nodes C _{1, 1} , stores parsed files 1, 2, and 2 with storage nodes F _7,1 , F _9,1 , and F _9,4 , respectively. Corresponding to the one-to-one file mapping between 3, parsed file 1706A only on file storage server 1700H, parsed file 1706B only on file storage server 1700M, and file storage server 1700L ) and save the parsed file (1706C) only. File delivery uses hypersecure last mile communication to secure not only the delivery of data but also its storage. One disadvantage of non-redundant file mapping is that the loss of either file storage server, either temporarily or permanently, jeopardizes file access and restoration. In the context of this application, the terms “resiliency” and “restorative” are used to define guaranteed and timely access to stored data, i.e. that stored data will not be lost or access to it will not be compromised for a significant period of time. It is used to define certainty. By this token, the non-redundant hypersecure file mapping shown exhibits poor resilience because a single point of failure prevents file access. Poor resiliency can be overcome by redundant systems, 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 read redundancy factor (RRF), defined herein as a term that defines the number of backup systems that provide data access in case primary data storage is unavailable. It is a standard measurement standard. In the example shown, there is one location for each unique piece of data. This results in a read redundancy factor of 0, 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 Figure 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 file storage server node F _9,1 is damaged or unavailable, parsed file 3 can still be accessed from file storage server node F 9,4, and parsed file 2 can be accessed from file storage server node F _9,4 . It can still be accessed from server node F _7,1 . Therefore, failure of any one storage node will not prevent read access to the hypersecure files. Figure 85C shows hypersecure file mapping with RRF = 2. The file mapping maintains _the file storage servers ( _1700L , _1700M , and _1700H ), but uses a second set of file storage servers ( 1700J, 1700E, and 1700F) are added. Accordingly, file storage server 1700J acts as a backup for file storage server 1700L, file storage server 1700E acts as a backup for file storage server 1700M, and file storage server 1700F acts as a backup for file storage server 1700M. It acts as a backup for the storage server 1700H. Although the example shown includes a file parsed into three sections, it will be appreciated that the 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 enabling storage and retrieval of duplicate files using hypersecure file storage, it is advantageous to describe the transactional sequence of communiqués and file transfer functions overlying the SDNP network that are used to facilitate the storage process. The network shown in FIG. 86 includes, for example, client device 1700A implementing client node C _{1, 1} , router 1702G, signaling server 1715 implementing SDNP node S, and 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) that respectively implement , ₁ .

In Figure 87A, client device 1700A at address "IP C _1,1 " sends a data packet ( 1710A), a file record request is made to the signaling server 1715 at the address “IP S”. In Figure 87B, signaling server 1715 sends data packet 1710B to name 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 a file address server node to use may be selected randomly from a list of storage nodes, or may be selected based on one available node 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. 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. Send. Signaling server 1715 then calculates the last mile and meshed cloud delivery of the parsed file to file storage servers 1700H, 1700L, and 1700M.

In Figure 87D, signaling server 1715 transmits data packet 1710D to client device 1700A, and the packet is routed from address "IP S" to "IP C _1,1 " through router 1702G. Data packet 1711D is configured for last-mile routing for imminent file delivery within zone U1, the client zone, specifically tag 1, tag 2, and tag 3 of each packet (indicated as "tag X" for brevity). and a C&C payload 1711D containing 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 ), and includes a C&C payload (1711E) showing SDNP cloud routing to the next node in the cloud. According to the secure dynamic communication network and protocol, the routing of data packets throughout the SDNP cloud using meshed, anonymous, fragmented transport is dynamically selected based on the current conditions of the real-time network. Specifically, 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 Figure 87E, signaling server 1715 transmits C&C data packets to the 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. Includes a C&C payload 1711F that communicates that the packet should be expected by gateway node M _0,4 and, when received, forwarded on the last mile address “IP F _7,1 ”. The 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 specifies an incoming 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 empty. , i.e. filled with invalid values. Once command and control data packets are distributed over the network, file transfer may occur.

88 illustrates a 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. It is transmitted from address "IP C _{1, 1} " to the SDNP gateway located at address "IP M _0,0 ". Each data packet has a unique identifier ID: tag 1, tag 2, and tag 3. These files are then transferred via the SDNP cloud to other gateways, i.e. to SDNP gateway nodes M _0,4 and M _0,8 . A _packet containing SDNP data 1 arriving at gateway node M _0,4 is sent to the data packet ₍ 1712A), while the Data 2 and Data 3 packets arriving at gateway node M _0,8 are sent from address "IP M _0,8 " along with zone (U9) security credentials in data packets 1712B and 1712C. Sent to 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 is not related to SDNP security provisions. The contents of the data packets SDNP Data 1, SDNP Data 2, and SDNP 3 contain the actual fragmented files being stored.

The preamble within each data packet, for example Preamble 1 within data packet 1712A, may also include an encryption key supplied by the client as part of a symmetric key encryption operation. Using symmetric key encryption, 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 file storage server node F _7,1 , conveyed by data packet 1712A in this example. In the future, whenever a client requests to read or access the contents of a stored file, the file storage server node F _{7, 1} uses this encryption key to encrypt the requested file before transmitting the file back to the client. Because only the client has the associated decryption key, only the client can open the file for reading. Although this method provides an extra layer of protection, only a single client can access the file as a read operation, and multiple It has the disadvantage of preventing the use of the client file "owner".

Approximately in time for the data transfer and file storage processes, signaling server 1715 also sends instructions to file storage servers 1700H, 1700L, and 1700M regarding routing “link response” messages. The link response is a data packet and C&C payload that confirms to the client that the write operation was successful and storage of each parsed file is complete. These messages are sent to the client file-owner independently of the respective file storage server involved in storing the delivered parsed file. The file server sends its write-confirmation response to the client, independently and without knowledge of each other, and the write-communication response uses independent security credentials that contain a specific state that is different from the operating state at the time of the write operation. and is transmitted. Routing of these link response messages does not necessarily need to use the reverse direction of the same routing path that was used to deliver the file. Such a response could potentially be used by a cyber-attacker as a traceback 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 the link-response message to the file storage server, to the client file-owner, and to all intermediate SDNP nodes involved in routing the link-reply message. Signaling server 1715 uses data packets containing command and control payloads to coordinate link response message routing, as shown by the example in Figure 89A, e.g., file storage server 1700H may use data packets containing command and control payloads to Receives a data packet 1721G including a C&C payload 1722G including header data for “Link 1 Reply” routing from IP F _7,1 to address IP M _{0, 4} . The SDNP gateway node M _0,4 is responsible for routing 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 ”. Receive a data packet 1712F that includes a C&C payload 1722F describing . Similarly, signaling server 1715 files data packet 1721M containing the "Link 3 Reply" tag 3 packet last mile routing instructions from addresses "IP F _9,1 " to "IP M _0,8 ". Send to 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 the SDNP cloud is most likely different due to the dynamic nature of the SDNP cloud.

The actual routing of link response messages from participating file storage server nodes is shown in Figure 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 translated into a last mile data packet (1720X) and zone (U1) Using the security credentials and using a TCP transport carrying Tag 1 data, i.e. Preamble 1 and FS Link 1, it is routed from address "IP M _0,0 " to address "IP C _1,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). converted, from address "IP M _0,0 " to address "IP C _1,1 " using a TCP transport using zone (U1) security credentials and carrying tag 2 data, i.e. preamble 2 and FS link 2. 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 translated into a last mile data packet (1720X) and zone ( U1) is routed from address “IP M _0,0 ” to address “IP C _1,1 ” using the security credentials and using a TCP transport carrying tag 3 data, i.e. preamble 3 and FS link 3.

Figure 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, the data packet is from address "IP F _7,1 " using TCP in the 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. The response preamble 1719A includes 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 triple-channel communication, the response security credentials included within the response preamble 1719A are generally not required and are not relevant for 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, which includes:

* A specific network tag, SDNP address, or pseudo-address needed to identify the file storage server where part of the fragmented file is stored.

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

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

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

* Key containing the decryption key 1030 to decrypt the zone (U7) "storage side" password 1. These keys 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 operate in conjunction with other security credentials, such as a numeric seed.

* Key 2, including an encryption key 1022 sent to the client and used to transmit secure instructions from the client to the file storage server using symmetric key encryption.

* A file name or other information used to help a client identify a saved file without revealing how it was saved.

The foregoing data packets are used for illustrative purposes and should not be construed as limiting the contents of the data packets to the exact elements or formats shown in the examples. The FS link 1720X received by SDNP client node C _1,1 , once received from the file storage server participating in fragmented file storage, is processed to create a file link for the client's device. As shown in Figure 89D, this operation combines FS links 1741A, 1741B, and 1741C using a mixing operation 1753, thereby creating the FS link total "File Store Read Link" 1754. . A file save 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 operations are not visible to users. The file owner need not be concerned that the file has actually been fragmented, encoded, and stored across a distributed file storage system. File recall appears to cause files to reside locally. Accordingly, FS links are the key element for accessing arbitrary files stored across distributed file storage systems.

A simplified diagram of FS link communication is shown in Figure 90A, where three file storage servers transmit their respective FS links to client node C _1,1 and corresponding client device 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 devices 1700A, the SDNP app software in client node C _1,1 combines the three receiving FS links 1, 2, and 3 to form a link to the stored file. This combined link appears within SDNP Messenger as a file save confirmation. In non-redundant file management, FS link information is sent only 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 a signaling server, only the client that has the link has access to the file. These FS links are needed to recall and read fragmented files. Without FS Link, stored files and their contents will be lost forever and cannot be recovered. To reduce this risk that the FS link may be lost, an alternative approach sends the FS link to two client devices - a client device and a secondary device. The auxiliary device may be a second device owned by the client or, in the case of a business, a second device owned by the company. Alternatively, the second device may include another server with its own login security and user identity verification.

Redundant link access to fragmented, distributedly stored files created in accordance with the present invention can be applied to both read redundant, i.e. RRF ≥ 1, and non-redundant file storage systems. The use of redundant links in a hypersecure distributed memory system without read redundancy (RRF = 0) is shown in FIG. 90B. In such a system, the file mappings between parsed files 1706A, 1706B, and 1706C and corresponding file-storage servers 1700H, 1700M, and 1700L are non-redundant. As shown, FS links 1, 2, and 3 have two client devices: a client device 1700A hosting SDNP client nodes C _{1, 1} and a secondary client device 1700A hosting backup client nodes C _{2, 1} . 1700B). In case one of the FS links is lost or becomes unavailable for any reason, the files can be restored using the FS link on the backup client. 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 Figure 90c, where parsed files 1, 2, and 3 are mapped to two file storage servers, respectively, with a read redundancy factor RRF = 1. Realize, and achieve link redundancy factor LRF = 1 with each FS link transmitted to two clients. The storage system's immunity to both read and link related failures means that the system can be considered as a truly redundant hypersecure file management system with an overall storage redundancy factor SRF = 1. Herein, storage redundancy factor (SRF) is defined as the redundancy factor equal to the smallest of RRF and LRF. For example, if RRF = 0 and LRF = 1, then SRF = 0. Instead, 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 four separate file storage servers (as shown previously in Figure 85C), and FS links must be sent to four separate clients. .

Therefore, overall storage redundancy factor (SRF) is a direct means of recovery from failure of distributed storage systems. This principle is summarized in the graph of Figure 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, i.e. RRF = 0. Increasing the number of file storage devices improves read redundancy, but does not affect link redundancy. Conversely, sending a link to a single client does not provide link redundancy, i.e. LRF = 0, regardless of the number of file storage servers available. In both cases, i.e. one storage server or one client link, overall storage redundancy factor (SRF) = 0, which means that the file storage system is not resilient, as schematically shown by the L-shaped region. it means.

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

By sending FS links to three clients and storing data redundantly on six storage servers, area 1724C specifies the condition that SRF = 2 provides a very strong degree of storage resilience. Region 1724D shows further resiliency improvement, where SRF = 3 uses 6 file storage servers and 4 clients receiving keys. Accordingly, the bottommost row and leftmost column have the lowest storage resilience, and the upper right corner has the highest storage resilience.

The hypersecure distributed file storage created in accordance with this disclosure achieves long-term, sustainable security by constructing, or re-using, numerous inventive elements from SDNP communications. These elements according to the invention include:

* Parsing files and distributing their fragmented content across a large number of unrelated networks connected to file storage servers;

* Transfer files between clients and file storage servers using end-to-end hypersecure communication, including SDNP dynamically scrambled, encrypted, 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 within a file storage server in a proof-free manner;

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

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

* Requiring client multi-factor 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 the location and encoding of hypersecure file storage, and, except for file links, routing information not stored on SDNP networks or hypersecure file storage systems;

* Store fragmented files on a large number of storage servers, using undisclosed file server locations, and using anonymous identities unknown to the client, the SDNP network, or other storage servers, except through file storage links. dispersing across,

* Utilizing triple-channel communication, where the SDNP signaling server used to plan file routing for distributed storage does not have access to the contents 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;

* Utilizing dynamic file renaming and data relocation at regular intervals and after repeated file accesses, replaying the encoding of security credentials upon file rewrite operations, and

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

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

Implementation of the above-described features for hypersecure file storage can be schematically presented in the same way as for hypersecure communication using the functional symbols previously shown in FIG. 9A. For brevity, as shown in the upper diagram of FIG. 92, scrambling (926), junk data insertion (1053), parsing (1052) and splitting (1057) and encryption (1026) using state or time (926C). Any combination may be provided as SDNP encoding function 1750. Similarly, the decoding function 1751 includes decoding 1032 using state or time 926B, mixing 1061, junk data removal 1053B, and unscrambling 928.

Using the security features described above, the top diagram of Figure 93A illustrates the process of distributed file storage with client-side encoding. As shown, file 1705 is parsed (1052) and split (1057) to produce parsed file 1706 within client device 1700A used to implement SDNP client C _1,1 . The resulting fragmented file is then encoded using zone (U1) security credentials by an SDNP encoding operation 1750B for last mile communications implemented in accordance with the methods disclosed herein. Then, the file fragment carried in the serial or multi-path last mile communication is received by SDNP gateway M _0,0 and performs an SDNP decoding operation 1751C according to zone (U1) security credentials to restore the parsed file 1706. ) is decoded using. The parsed file 1706 is then re-encoded by an 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 arrives at each SDNP gateway, including, for example, gateway M _0,8 , where The SDNP decoding operation 1751D restores the parsed file 1706 and re-encodes it using the SDNP encoding operation 1750D according to the zone U9 security credentials. In the example shown, parsed file 1706 is then fragmented (split) into two files, and fragmented files 2 and 3 of parsed file 1706 are then restored using SDNP decoding function 1751E. They are stored in file storage servers 1740B and 1740C, respectively. In this way, if the data files stored within the file storage server are fragmented, but not fragmented (except for local drive encryption), the files can be accessed by a cyberattack on the drive data. Therefore, security is achieved by file fragmentation and distributed storage.

A great degree of file security is achieved by using the process shown in the bottom diagram of Figure 93A, which illustrates the process of distributed file storage with full client-side encoding. As shown, file 1705 is processed by SDNP encoding operation _1750A to produce a scrambled, encrypted, parsed file ( 1706) is created. 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 an SDNP encoding operation 1750B for last mile communications performed in accordance with the methods disclosed herein. The file fragments, carried in serial or multi-path last mile communication, are then received by SDNP gateway M _0,0 and accessed with zone (U1) security credentials to restore the scrambled, encrypted, parsed file 1706. Accordingly, it is decoded using the SDNP decoding operation 1751C. The parsed file 1706 is then re-encoded by an 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 arrives at each SDNP gateway, including, for example, gateways M _{0, 8} , where The SDNP decoding operation 1751D restores the scrambled, encrypted, parsed file 1706 and re-encodes it using the SDNP encoding operation 1750D according to zone (U9) security credentials. Fragmented files 2 and 3 of the scrambled, encrypted, parsed file 1706 are then restored using the SDNP decoding function 1751E and stored within file storage servers 1740B and 1740C, respectively. Accordingly, 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 secure enclave. 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 Figure 88. do.

In both examples described, a greater degree of security can be achieved by eliminating the final SDNP decoding operation 1751E shown in the diagram of FIG. 93B. In this manner, files stored on the file storage server remain encoded by SDNP encoding operation 1750D using zone (U9) security credentials. In the top 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 first according to the client-side security credentials (U1) and then secondly according to the storage-side security credentials for zone (U9). The 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. This is because it contains files. The advantage of nested security as disclosed is that neither the client nor the storage server has the necessary information to open the storage file.

An overview of an example method for implementing hypersecure decomposed file storage is shown in FIG. 94. In the example shown, the encoding and decoding used for hypersecure communication and SDNP cloud routing are removed, showing only the net effect of file encoding. The upper left corner shows the case of client zone fragmentation, where the document is fragmented according to zone (U1) security credentials, but does not have 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, and encrypted according to zone (U1) security credentials, but the document is encoded by operation 1750B. No security regulations 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, namely scrambling, junk insertion, fragmentation, and encryption, are introduced on the storage side according to zone U9. The lower right corner shows an example of a fully nested hypersecure file store, where the file is encoded and fragmented according to the SDNP encoding operation 1750B with zone (U1) client-side security credentials, and then the file is stored in the storage-side last. Second encoded according to Miles' zone (U9) security credentials.

For recall and reading of a file, data recall must utilize a secure operation that includes a reverse function that executes in the exact reverse order of the encoding, as shown in Figure 95. In the top left case, to retrieve client area fragmented data, parsed files 1706 recalled from different file storage servers are reassembled using a merge operation 1061 to restore the original file 1705. In the lower left case, recalling client area encoded data, accesses the original file 1705 using the SDNP decode operation 1751H, which is the exact inverse of the split operation 1750B, including mixing, decoding, and unscrambling. Thus, parsed files 1706 recalled from different file storage servers are recovered. In the upper right case regarding a storage area encoded, client area fragmented file, the reverse operation performs an SDNP decoding operation 1751F to undo the effects of the area U9 security operation and restore the parsed file 1706. It performs first and includes a file merge operation 1061 to undo the effect of the file split operation 1057 made according to the subsequent zone Z1 security credentials.

In the lower right example for reading a fully-nested hypersecure file, data stored on different file storage servers is decoded by an SDNP decoding operation 1751D using zone (U9) security credentials, resulting in zone (Z1) Reconstruct file 1706, which is still a scrambled, junked, parsed, and encrypted multi-part file. Zone Z1 specific SDNP decoding operation 1751H then performs a sequential de-function of encoder 1750B, an operation that includes mixing, decoding, and unscrambling to recall the original file 1705. . To restore a file, the operations that execute the sequential reverse function must be done in the reverse order of the sequence used to create it. For example, if encoding involves splitting, then scrambling, and then encryption, then the opposite or reverse-function, i.e., decoding, should involve a sequence of operations: decryption, then unscrambling, and then mixing. However, if encoding sequentially involves scrambling of packets, then encryption, and then splitting, then the opposite or reverse-function, i.e. decoding, must involve a sequence of mixing of data packets, followed by decryption, and finally unscrambling. .

To perform a file recall or “file read operation”, the client must retrieve the combined files by clicking on the “file store read link” to initiate the steps necessary to recall and read files stored in the system's hypersecure file storage system. Execute the link. The read process includes the following steps as shown in Figure 96A:

* The file owner and client 1700A or an authenticated user clicks the “file storage read link” within an SDNP application, such as SDNP-based Hypersecure Messenger 1196, a file manager, or another SDNP-based interface.

* Using the dialog interface 1765 or optionally command line instructions, the client 1700A can read a file, edit a file (make a copy of the file with write privileges), remove a file (delete), and refresh a link (with security credentials). specifies the file request 1761, including reissuing a certificate), or redistributing a 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 the “client authentication” operation 1762, the SDNP signaling server 1715 verifies (authenticates) the identity of the client or clients requesting the file. Using dialog box 1767, the client must verify its identity using a PIN, or optionally a second factor that detects a device or security token. Alternatively, the SMS text can be sent to another device owned by the same client. In files that require access authorization by multiple clients, the identity of all users must be proven (multiple-authentication).

* In a “verify privilege” operation 1763, the signaling server 1715 verifies that the requesting client 1700A is authorized to access the requested file with read or read/delete privileges (authentication). Before checking whether the user still wants to download or read the file, the results are displayed in dial box 1768. If the identity cannot be verified, the requester may be instructed to try again. After a specified number of failed attempts, file manager 1700Z (if present) will recognize the failed attempts and lock the account. The dialog box can notify the user of the problem and cause them to contact the file manager, or alternatively, if hacking is suspected, the box may be blank or even eject the user from the SDNP application entirely.

* In document request management operation 1764, SDNP signaling server 1715 informs file storage manager 1700Z regarding the file access request and the nature (management) of the request. These administrative steps can (i) be omitted entirely, (ii) log file access requests to the file storage manager's account, and (iii) send a message to the file storage manager immediately notifying him of the attempted file access. or (iv) the file storage manager's approval may be required through a dialog box 1769 before access is granted to the client requesting the file.

After these authentication, authentication, and administration (AAA) steps, upon authorization, the client may retrieve the file using the steps depicted in the flowchart shown in FIG. 96B, shown here as being used as a read request for the purposes illustrated. 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 storage server name request operation 1771, SDNP signaling server 1715 sends a file storage server name request to SDNP name server 1714 to determine the current SDNP of the associated file storage server, e.g., file storage server 1700M. Request an address. According to the SDNP methodology, SDNP addresses for SDNP clients (including file servers) are changed at least once daily to prevent the possibility of long-term client traceability.

* In a store name forwarding operation 1772, the SDNP name server 1714 forwards the requested file name “FS address” to the SDNP signaling server 1715, whereby the SDNP signaling server maps the file recall routing.

* In a routing instruction operation 1773, the SDNP signaling server sends a file routing instruction to a client 1700A, to a node within the SDNP cloud, such as server 1700U, and to a state or time 920, numeric seed 923, and decryption. Zone-specific security credentials, such as a file storage server 1700M with zone U9 security credentials containing a key 1030, and an optional encryption key 1022 (used in symmetric key encrypted communications). The file is sent to the storage server.

* In a local file restore operation 1774, the DMZ server within the last mile of all storage decodes and restores the parsed file when using applicable security credentials that include state or time information specific to the creation of the file; In preparation for transport, data is arranged into one or more data packets.

* In a file delivery operation 1775, each parsed file is delivered to the requesting client using independent delivery across the SDNP network according to routing instructions of the SDNP signaling server, for example here the file storage server 1700M transmits the file to the client 1700A.

* The incoming parsed data file is further decoded according to the client zone security credentials, and the parsed files are merged to recreate the original unparsed file ready for viewing or delivery.

Those steps are represented in the sequence of figures below. In Figure 97A, a client device at address “IP C _1,1 ” uses data packet 1810a, which includes a TCP transport, file-related header information, and a C&C payload 1811A that specifies two or more FS links. thus making a file read request to the 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 converted to SDNP addresses or IP addresses for routing. 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. 97B, signaling server 1715 sends data packet 1,810B to name server 1714 with the IP or SDNP addresses of file storage server nodes F _7,1 , F _9,4 , and F _9,1 . request. 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. Send. Signaling server 1715 then calculates last mile and meshed cloud delivery of the parsed file to the file storage server.

In Figure 97D, signaling server 1715 transmits C&C data packets to the 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 “file 1 read instruction” 1811G. It carries a C&C payload containing. This packet instructs the file storage server to send a file with ID tag 1 from its address “IP F _7,1 ” to the SDNP gateway at address “IP M _0,4 ” using 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 with tag 1 is sent to gateway A C&C payload (communicating that it should be expected by node M _0,4 and, when received, should be forwarded to address "SDNP M _0,31 ", for example, using Z1 security credentials in the SDNP cloud) 1811F).

A second data packet 1810I, containing a C&C payload 1811I containing a “file 3 read instruction”, is sent from the SDNP signaling server ₁₇₁₅ at address “IP S” to file at address “IP It is transmitted to the storage server (1700M). This instruction instructs file storage server 1700M to send a 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) are similarly sent to other file storage servers and gateways, such as nodes F _9,4 and M _0,8 as well as nodes within the SDNP cloud.

In Figure 97E, signaling server 1715 transmits data packet 1810D to client device 1700A, and the packet is routed from address "IP S" to "IP C _1,1 " through router 1702G. Data packet 1810D sends the client a prediction of a number of incoming data packets with tag 1, tag 2, etc. from SDNP gateway 1701U at address “IP M _0,0 ” using zone (U1) security credentials. Contains a C&C payload (1811D) that informs you. At the same time, signaling server 1715 also sends a data packet 1810E to SDNP gateway 1701U, and the packet is routed from address “IP S” to “IP M _0,0 ”. This packet includes 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 transfer may occur. The first stage of transfer is shown in Figure 98, where data packet 1741R containing FS link 3 is configured with an example state 920, numeric seed 929, decryption key 1030, and encryption key. Information including 1022 is provided to the SDNP decoding operation 1751R. Instead of the SDNP decoding operation 1751R, this information is processed by the DMZ server 1762 to perform packet decoding 1032R, all performed in state 920, which is the state it was in when the parsed file was last encoded. Performs 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 needed 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 depicted in Figure 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 Contains TCP data packets 1720C carrying file 3 from ₁ "to "IP M _0,8 ". After transmission through the SDNP cloud (not shown), a series of data packets 1720X are delivered from the SDNP gateway at address "IP M _0,0 " to client address "IP C _1,1 ".

In a read operation, data is loaded into the SDNP app in its “read-only” form. As long as the files remain sandboxed within the SDNP application, they are protected by the characteristics of the SDNP application and network and are not dependent on the login process and weak security provisions of the device's operating system. The need for read-only access to private documents is common in business. Files created by a company's finance, legal, manufacturing, engineering, and quality departments illustrate examples of what often represents read-only content. In many cases, these company private files must be forwarded to company officials for review prior to their release, i.e., distributed electronically.

Accidental or premature disclosure of communicated information can be fatal, carrying serious economic and even legal consequences for the company's and personal liability for the responsible person. For example, a public company's unpublished financial reports are strictly confidential until their disclosure. In the United States, Regulation FD, or "fair disclosure," means that information must be made publicly available to everyone at the same time without any special privileges. If any outside party accesses the information prior to its public disclosure, it is a violation of Regulation FD. If a court determines that a violation of Regulation FD occurred because the company neglected its duty to maintain and ensure the confidentiality of documents, the company may be guilty of that violation even if there was no insider trading resulting from selective disclosure. and the person in charge may be held personally liable.

In the SDNP app, search files are classified (sandboxed) to prevent data passing from one account identity to another and, for example, 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 search file out of the SDNP application and into unencoded storage within the device memory.

Downloading files outside of an SDNP-based application compromises the security of the file and the data it contains. For data within SDNP applications, access is controlled, user actions are restricted, and both the device and the SDNP network must verify user identity. Such multi-layered multi-factor authentication is much more difficult to overcome than breaking the simple four-digit pin required to open the phone. In contrast, once a file is downloaded to a computer, tablet, or phone, it is nearly impossible to prevent unauthorized access, determine who had access, or determine who copied the file.

Therefore, using SDNP communications, file owners can lock, or categorize, sensitive documents and files so that others can read them but not download them to the phone. Additional steps can be taken to prevent screenshots or filming of the LCD display screen. In other cases where security and privacy are not required, transfer of search files from the SDNP app to the phone's memory is possible and can be used without restrictions.

In an editing operation, an editable form of a file may be downloaded into the device and passed to an application program required for editing of the file. Other than the operation of the SDNP application on the client - in terms of data transfer in the SDNP network - to execute file requests and data exchange, there is no fundamental difference in the operation of the SDNP network between a file read request and a file edit request, and such operations are functional. is equivalent to The difference between read and edit operations can therefore be considered to exist primarily in the execution of layers 5 to 7, including application specific files.

To edit retrieved files, the application may be (i) a device-embedded application (e.g., Simpletext) native to the device's operating system, but running outside of the SDNP application, or (ii) the device's operating system. (iii) may be a third-party application that operates externally to the SDNP application, such as Microsoft Word, Adobe Acrobat, etc., or (iii) may operate within the SDNP application and be directly accessed 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 to maintain business security, any files owned by the business, i.e. sandboxed within the SDNP business account field, may be stored in the user's personal SDNP account, even though the personal and business profiles run within the same SDNP application. cannot be passed on.

After editing, saving the edited file on the SDNP file storage server will not overwrite existing files unless specifically requested by the file owner.

Instead, a second version is stored in addition to the first version, and deletion of the previous version requires the user to perform a delete operation. Because hypersecure file storage always requires identity verification, the process of saving edited files may involve specific system features that cannot be obtained from file storage that does not have dedicated hypersecure network communications. One such unique 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 hypersecure data storage created in accordance with the present invention, the delete operation involves overwriting a random number over all existing parsed files and optionally re-doing this after one hour, thereby removing the small but detectable electrical or magnetic field of the stored bits. Includes making analog variations more unclear. File history is also overwritten to confuse the data drive's file history. 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 remainder of the FS link is purged from the SDNP system. However, if a file system administrator tracks the activity of its user base with third-party software, even if the files themselves have not been accessed, the administrator can determine who owns the file, when it was created, who accessed it and when it was deleted, and when the file was deleted. You can still retain metadata about the file's history, including when it was deleted.

SDNP network and hypersecure last mile capabilities may also support other features and operations for corporate accounts but not for personal account profiles. As mentioned above, a deletion operation in a personal account involves rewriting junk data to a file, purging the drive's index record of the file's existence, and using message self-destruction to restore the file's previous fragmented storage location. Includes destruction of all FS links. However, in corporate accounts, the file storage administrator may require prior approval to permanently destroy a file, for example using an approval process similar to dialog box 1769 in Figure 96A but sent to the administrator rather than the file owner. You may need it.

If your company's file manager chooses not to allow file deletion, several scenarios can occur, including the following: (i) the file will not be deleted and the file read link will be in their SDNP application or SDNP communicator message history; (ii) the file owner is notified that the file will not be deleted, for example, that it will be retained for "archival purposes", but the personal file read link will be Using the destruction provisions, they will be removed from their SDNP applications, meaning that only the file storage administrator can retrieve them if the owner has attempted to delete them, or (iii) the file owner's personal file access link will be removed from the SDNP application. They will be removed from their SDNP applications using the SDNP system's message self-destruct provisions, but they will not be notified that the files are 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 storage read link", even by a file storage manager. In order for administrators to gain access to a file, they must be on the corresponding file save read link whenever the file is saved and edited. Although 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. Intelligent filters possible in the disclosed SDNP system as disclosed only track attempted file deletions. In this approach, the administrator does not monitor the creation of files, but only tracks attempts to delete files. Whenever the file owner attempts to delete a file, only then the corresponding file storage read link is passed to the administrator's database or console for approval or storage.

By identifying specific employees and contractors that need to be monitored, the database size can be further minimized. For example, if a company is involved in an audit or patent litigation, the parties are typically notified not to delete any relevant data or 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, as the case may be, "at the time." A copy of the file storage link may be sent to the file storage administrator or an independent investigator. Such a method is advantageous because it limits the amount of data monitored, which naturally alerts administrators to suspicious activity to try to cover up mistakes. In order to prevent accidental or malicious loss of file storage name links due to destruction of the client and file owner's device itself, the use of duplicate file storage links as previously disclosed is essential. In the case of a company, backup copies may be maintained on a computer located within a secure office or on a centralized company server.

In extreme security cases, for example national security cases, deletion of files may involve a multi-step method including: (i) overwriting the file with random data, (ii) storing it. (iii) performing a bulk erase of the drive, (iv) reformatting the drive, (v) overwriting the drive's storage fields with random numbers; writing, and optionally (vi) backcopying the preserved files if necessary. Unlike traditional file data overwriting, the bulk erasure process affects the read-write storage medium itself, naturally randomizing its electrical, magnetic, or optical properties at the molecular level. Bulk erase of magnetic drives can utilize large electromagnets, and bulk erase of flash can heat the ICs to high temperatures and possibly expose them to ionizing radiation at high operating voltages. Magneto-optical drives can be bulk erased using large magnetic fields. Re-writable optical drives can be bulk erased using a bright scanning laser that scans across the disk format tracks. In any case, bulk deletion represents an extreme case where the storage media loses data completely after deletion, even at the risk of the storage media becoming damaged and unusable again.

Another important factor in a hypersecure distributed file storage system is maintaining the integrity of file data and link access. To ensure prevention of accidental loss of the link, it is sometimes advantageous to re-establish the file storage read link, i.e. re-verify 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 may also be initiated from the file storage server after some predefined interval. In case of a request initiated from a client, the SDNP signaling server communicates command and control packets to the corresponding server. When a link refresh is initiated as shown in Figure 100, the file is entered into the SDNP at state 320X, being in the "old" state at time t ₁ when 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 an SDNP encoding operation 1750D using the new state 920Y at time t ₂ and stored on the storage drive. The refreshed storage link, e.g. FS Link 3, is then sent back to the file owner, client device 1700A, via the SDNP network. The resulting file contains encoded data updated with zone (U9) security credentials at time (t ₂ ). However, the client's security credentials in the zone (U1) used to create and parse the original file are not updated. To read a file, the read operation must first decode the file using zone (U9) security credentials in a state corresponding to time (t ₂ ), and then, after transfer to client node C _1,1 , the file is Decode the file using zone (Z1) security credentials associated with the time it was first created.

As another provision for improved security, the redistribute 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 with access to the file. This operation is shown by way of example in FIG. 101 , where the contents of file storage SDNP node F _7,1 in region U7 have state 920X, which is the state at time t ₁ when the file was created. It is decoded using the SDNP decoding operation (1751H). The file is then transferred via the SDNP network (not shown) to the file storage SDNP node F _9,4 , where the file is stored using zone (U9) security credentials as state (920Y) corresponding to time (t ₂ ). It is then 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 above-described file transfer, the contents of the file storage SDNP node F _9,4 in zone U9 are subjected to an SDNP decoding operation 1751L using state 920X, which is the state at time t ₁ when the file was created. ) is decoded. The file is then transferred via the SDNP network (not shown) to the file storage SDNP node F _9,1 , where the file uses zone (U9) security credentials as a state (920Y) corresponding to time (t ₂ ). It is encoded by 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 contents of file storage SDNP node F _9,1 in region U9 are decoded by SDNP decoding operation 1751M using state 920X, which is the state at time t ₁ when the file was created. It is 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 stored using zone (U7) security credentials as state (920Y) corresponding to time (t ₂ ). It is then 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 file access. In this way, all three files are relocated, new security credentials are issued, and clients with authenticated access are issued new file storage read links based on updated FS links 1, 2, and 3.

Another essential maintenance function performed by hypersecure file storage systems is the operation used to check for 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 file owner. In operation, each file storage server tracks the time since a file was last accessed. If the last operation on a file exceeds a specified interval of inactivity, for example one month, the file storage server contacts the client or clients to check whether 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 inactivity for a certain interval, the file storage server contacts the SDNP signaling server with a request to reconfirm that the link remains active. Next, the SDNP signaling server plans the delivery path of the FS link verification request for each participating file storage server. Then, each file storage server transmits the request to the client through the SDNP network. All participating SDNP client nodes respond with confirmation that the file link still exists within the device. If a file link is confirmed, at that time the client has the option to perform a link refresh. However, in case 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, Deletes unclaimed zombie files permanently or irretrievably.

Registered Communications - Another feature of SDNP communications created in accordance with the present invention is the network's ability to forward or store "registered communications." Registered communications include the ability to e-sign and e-chop communications to establish legal validity, hypersecure delivery of communiques as signed, time-stamped messages, or hypersecure storage of files. 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 within the client device, but are authenticated 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 an inherent feature of SDNP communications, as is the use of "state" in SDNP communications, i.e., where time and other specific variables are used to establish 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 is divided into three categories: when the message was sent, when the message was received, and when the message was read. There is a corresponding set of time stamps 1801A and 1801B representing . Time information including the global time standard established by the SDNP signaling server is delivered to the client through the last mile network. The SDNP client app then integrates the time stamp into the information display.

In registered communications, communiques produce an official stamp as part of the process. One example of a registered communication process is shown in Figure 103, where a hypersecure message is executed, beginning with an optional file attachment step 1802, which includes a dialog box 1803, where the message or The client sending the file, that is, the sender, chooses whether 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 transmit the registered message, with dialog box 1805 selecting whether to use regular or registered delivery. The message is then transmitted using hypersecure communications created 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 send a certified receipt confirming acceptance of the received message and file. This process begins with a receipt authentication operation 1807, where the receiving client is asked to verify their identity. If their identity is not authenticated, 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 the identity is confirmed, the receiving party is questioned in a receipt authentication operation 1808 as to whether they wish to accept or reject the received message and attachment. If a message is rejected, the sender is notified.

If the receiving party accepts the message by selecting 'Yes', they may choose to accept the message by selecting Electronic Signature (e-Sign) and/or Stamp/Chop (e-Chop). In order to sign, you must complete the receipt management step (1809). The sender can specify the required options. In some countries, both the chop and the sign are required for legal binding. A subsequent dialog box (not shown) instructs the user to place the sign or chop within the device's file directory. Alternatively, audio/video recordings may be used as confirmation. The recipient is given instructions on what to read during the recording. Once the message is signed, the message can be viewed by the recipient, and the attached files can be viewed or downloaded depending on the sender's requirements.

When accepting a document, a signed, time-stamped message receipt (1811) identifying the recipient of the message, the embedded text received and the attached file name, the date and time the message was received, and an e-sign, e-chop, etc. A signature, including either an audio recording, an audio-video recording, or some combination thereof, is transmitted to the sender in notification operation 1810. In the Archive Receipt option 1812, the sender may store a copy of the signed, time-stamped message receipt 1811 in the hypersecure file storage system of the receiving system with a file read link 1813 necessary for the sender to recall the message. have the opportunity to Alternatively, message receipt 1811 can be used for download into the sender's device.

Encryption-based security concerns - Government security agencies can trace callers to corporate criminals, IP theft, cybercrime, hacking, criminal organizations, drug cartels, mafia, Yakuza, jihadists, and terrorists. Any communication system (metaphorically, Payphone) that provides anonymous communication, i.e., a system that uses encryption to secure data and conceal the identity of the caller, is a reckless and irresponsible business practice for network operators, application developers, and device manufacturers. It claims to provide.

Unfortunately, the truth is that communications that rely on encryption to achieve security protect criminals and law-abiding citizens alike. As mentioned above, this subject has focused on many new stories about the criminal activities of ISIS terrorists and their attacks in Paris and Belgium using a phone application program 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 operators. Security officials responding to Telegram argue that big-key end-to-end encryption presents a national and even international security risk that could allow terrorists to operate secretly using open communications. The argument in favor of Telegram supports personal privacy above all else.

The Dec. 2, 2015, California shooting that killed 14 people and wounded 22 others came as a federal judge ruled in favor of the FBI and ordered Apple to help "unlock" a locked phone allegedly in the possession of the gunman. The privacy debate surrounding the San Bernardino shooting has arisen again. On February 17, 2016, the headline of a Washington Post article was "Apple vows to deny FBI demands for iPhone cracks linked to San Bernardino attacks." Apple and its CEO cited several reasons for not complying with the court order. The article can be found 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 insisted that law enforcement cannot unlock new iPhones, even when officials have a warrant, because they are engineered in a way that Apple does not have decryption keys - essentially end-to-end. Another example of the challenges of end-encryption is raising fears. Apple claimed that only the phone's user - or someone who knows the password - could unlock the phone. The government argued that there was no need to unlock the encryption feature, only to disable a feature that erases 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 on any number of devices. In the physical world, this could unlock hundreds of millions of locks – from restaurants and banks to stores and homes.” "It would be identical to a master key that could be accessed. No reasonable person would tolerate such a thing." He continued, "Opposition to these orders is not frivolous. We believe we must speak out against the overreach of the U.S. government."

Apple's final point, that the U.S. judiciary has exceeded its authority, is a legal argument, not a technical one, and one that echoes the sentiments of constitutionalists and privacy advocates would argue that the government can monitor communications without a clear reason. Or, it claims that it does not have the legal authority to invade an individual's privacy. Although the standard of probable cause is clearly met, especially in the case of San Bernardino, the disputed idea of creating a universal backdoor that could open any communications device would result in an abuse of power by the authorities. In their February 23, 2016 article, The Atlantic agreed: "Apple is right: The FBI wants to infiltrate many phones." The same day, the Guardian reported that "FBI seeks access to dozens of iPhones, Apple claims."

Strangely enough, the US Congress has taken the same privacy-related position. A March 1 follow-up article in the Guardian titled “Congress says FBI pressure on Apple to unlock iPhone is ‘futile’” states that US lawmakers are violating and invading privacy in the US judiciary. criticized. “The road to hell begins with a backdoor,” Microsoft general counsel Brad Smith said at the RSA conference in San Francisco. Smith challenged the computer security industry's presentation at the rally "to support Apple in this important case."

Amid the fire, many security experts, including NSA whistleblower Edward Snowden, have publicized the view that unlocking a phone is not as difficult as the FBI claims. In a discussion via video link from Moscow to the Common Cause Blueprint for the Great Democracy conference (March 8 and 9), Snowden said: "The FBI says Apple has 'proprietary technical means' to unlock phones. 'Even if I put it politely, this is nonsense." Before the case came to court, the FBI reported that it had already discovered a way to break into locked iPhones. On March 29, 2016, a Fortune Magazine article reported, "The FBI didn't tell Apple how it breached the iPhone."

The legal and geopolitical consequences of the Apple-FBI case have had major implications. Following the FBI's lead, other countries are expected to claim backdoors for all communications devices connected to their networks - including phones carried by US citizens traveling the world. Additionally, now that the iPhone has been successfully hacked, criminals will eventually discover or re-invent these methods to commit new forms of cybercrime and identity theft. To avoid being fooled by criminals, governments may try to use the same methods to expand surveillance and espionage, and even multiple departments within the same government may use these methods to spy on each other's activities. As a related story, several governments are considering limiting the level of encryption used in end-to-end communications.

Collectively, these events clearly support the realization that the obvious combination of existing security methods currently available in the public domain does not guarantee both security and privacy, at least without aiding criminals and terrorists. The problem stems from relying solely on encryption to achieve both network security and end-to-end security and their associated caller privacy. Increasing the security of text, voice, or files by increasing the bit size of the encryption key makes arbitrary communiques more secure and more difficult to crack. Enhanced security protects businesses and law-abiding citizens in maintaining security and privacy, and combating identity theft. Unfortunately, the same improved 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 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 “attack surface” of vulnerability. Communicate 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 determining how large the encryption key should be used. As shown in table 1824, the larger the encryption key, the more combinations there are and the more difficult it is to crack the password. 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. Although high network security is advantageous in preventing malicious external attacks, excessive end-to-end encryption is a double-edged sword. When large key sizes, such as AES256 or AES512, are used, the system delivers "top secret" network performance and naturally 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.

Key size trade-offs are complex. If the encryption key is too small, criminals can target the network and its users. If the encryption key is too large, criminals can use the network to hide their illegal activities and thwart investigators' efforts to detect ongoing fraud and malfeasance. In a corporate environment, the company's security policy may reject full end-to-end encryption because it prevents monitoring of employee activities or following company investigations and IP litigation.

Even determining what size key is breakable and how secure it is is difficult and depends on technological advancements. 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, while a 56-bit key has 10 ¹⁶ combinations, and a 128-bit key has more than 10 ³⁸ combinations. A 256-bit key has a larger combination of 39 digits than a 128-bit key. Ignoring the use of pattern recognition, brute force attacks will try every combination to hack your code. In an EETimes article titled "How to secure AES against brute force attacks?" (http://www.eetimes.com/document.asp?doc_id=1279619), the author states that, in order to conduct a brute force attack, We estimated the time required on a 2012 supercomputer capable of 10.5 petaflops. A petaflop is a quadrillion, or 10 ¹⁵ , floating point operations per second, or a thousand teraflops. ^Therefore , a 56-bit key ^requires only 399 seconds, a 128-bit key requires 1.02 It takes x 10 ⁵⁶ 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 July 30, 2015 BBC News article titled "Supercomputer: Obama orders world's fastest computer," researchers said the target speed of the next supercomputer would be 20 times faster than the record-holding computer. It was reported that the machine was fast, capable of operating at exoflops per second, or million to million floating points. This means that the time needed to crack a password continues to get shorter every year. Another new approach to cracking cryptography is using massively parallel processing, the same method used in Bitcoin mining. Instead of having a single supercomputer, using thousands or even a million parallel computers allows attacks to run simultaneously while proportionally reducing the time. Today's fastest microprocessor has already surpassed 1.1 teraflops, so 3,000 top-end microprocessors working together are equivalent to the fastest computer in the world today. Only one million microprocessors are required to realize an exoflop computer. While dedicated ASICs could further compromise security, quantum computing will change computational 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 Figure 104B, communication between SDNP clients 1700A and 1700Q, representing the caller and called party, respectively, is performed by 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 injection, and hop-by-hop encryption using triple-channel communication for control. do. Although last mile communication and every hop within the SDNP cloud involves dynamically changing security credentials, the process is presented in a simplified form by SDNP encoding operation 1832 and SDNP decoding operation 1833.

As illustrated by table 1834 and shown by line segment 1830, these methods, in various combinations, achieve security equivalent to secret or top secret encryption standards, without relying on encryption alone. Since line segment 1830 is flat, this means that there is no interdependence between the end-to-end encryption shown on the y-axis and the 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. These security operations are implemented by the SDNP software in such a way that the caller and called party are unaware of the security credentials used to transmit data packets through the SDNP network 1831 and its various security zones. In particular, the conversing clients do not knowingly participate in the key exchange of any encrypted 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. Accordingly, SDNP network 1831 security does not rely on end-to-end encryption implemented 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 when single-hop dynamic encryption within the SDNP cloud utilizes AES256. Key encryption can be used. In fact, end-to-end encryption can utilize RSA or other ciphers without compromising network security. The SDNP network 1831, even though it is not an end-to-end encrypted tunnel 1820, is still protected by AES encryption conforming to FIPS 140-2 military grade security. As explained, the SDNP network 1831 protects against all external cyber-attacks and man-in-the-middle attacks. The end-to-end encrypted tunnel 1820 protects callers 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, decreased, or even eliminated 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 the dotted line 1835 is too stringent for small companies or personal use, the number of bits can be reduced without giving up individual privacy. In military or government applications, the encryption key length can be increased to 192b, 256b, or even 512b as needed. In this regard, the disclosed SDNP system overcomes deficiencies in today's encryption-based currencies, providing features that are not available by any alternative application, device, or network.

Security Management - Another key feature of SDNP communications is its specific approach to security management. Security management is required in numerous situations, including:

* Monitoring of employee communications conducted in accordance with HR policy or employee investigations;

* Monitoring and recording 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 IP or corporate litigation;

* Complying with communiques and document requests pursuant to subpoenas and criminal investigations;

* Comply with legal orders for monitoring account information, calls, messages, and accessing files related to national security.

With proper authentication, SDNP network administrators can facilitate access of SDNP network traffic to designated “SDNP security agents” for communications monitoring and data surveillance. The process of deploying and enabling SDNP security agents includes a multi-layer authorization and authentication process that is mandatory prior to monitoring activities. To prevent abuse, no individual, not even the SDNP network administrator, can independently initiate monitoring. Due to the dynamic nature of SDNP communications as a decentralized network with no central control, with no master network key and dynamic SDNP encoding and decoding running using zone-specific security credentials operating offline within a DMZ server. , there is no mechanism to restore data or recall 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 designed to have essentially no central control, without which even the metadata of previous calls would not be available. Therefore, the SDNP network supports only a priori security monitoring, which means that monitoring by a designated SDNP security agent must be established before intercepting the communiqué.

Additionally, due to the dynamic nature of fragmented meshed communications within the SDNP cloud, SDNP nodes within the cloud do not carry data packets of a complete conversation, i.e., beyond the SDNP gateway. Most nodes carry less than 5% of their data and typically only for 10 ms before a routing change. Depending on SDNP communications, dynamic routing continuously redirects communications through different media servers. Therefore, cloud access is not available for restoration or monitoring of communiqués. Although data packets from the SDNP cloud may be captured, 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 necessarily traverse within the client device or preferably within the SDNP gateway.

An example of data packet routing in security monitoring is schematically depicted in Figure 105A, where SDNP security agent 1840 monitors the conversation between SDNP client device 1600A and SDNP client device 1600H. A conversation takes place using data packets transmitted from SDNP client device 1600A through last mile router 1602G to SDNP gateway 1701U and through the SDNP cloud, while data packets transmitted from client device 1600A are transmitted through SDNP gateway 1701U. It is closed by the gateway 1700U and securely routed to the designated SDNP security agent 1840. Specifically, during UDP transmission, the 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 ”, and It comes from the SDNP gateway at IP M _0,4 "and is delivered 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 SDNP address “IP SA”. Duplicate monitoring data packets 1841 operate in the same way as SDNP group-calls, except that duplicate data copies are visible to callers. Accordingly, the caller is unaware that they are being monitored.

Security monitoring also works on incoming calls. In Figure 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 transmission, data is delivered to two destinations from the SDNP gateway at address "IP M _0,0 ". 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 the same payload, via data packet 1842, containing the duplicated data “SDNP Data 7”. The delivery of data packets 1842 is not visible to the callers, and thus they are unaware that they are being monitored.

The same method can be applied to monitoring 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. One such example is shown in Figure 106, where SDNP file storage device 1700H forwards data packet 1740H containing FS Link 1 from address “IP F _1,1 ” to gateway address “IP M _0,4 ”. It is transmitted, which is routed through the SDNP cloud and then forwarded to the client 1600A by the data packet 1740A. The duplicate payload “FS Link 1” is also delivered to the SDNP security agent 1840 at address “IP SA” by a data packet 1843 sent from gateway address “IP M _0,0 ”. As in the case of real-time communication, the file owner, the client 1600A, is unaware that it is being monitored by the SDNP security agent.

The same monitoring mechanism operates for multi-path last mile communications, where data packets enter and exit the SDNP cloud through more than one SDNP gateway. This case is shown in Figure 107, where last mile communication from client device 1600A is to the cloud via segmented data packet 1630A containing payload SDNP data 1 and 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 are shown emerging from the cloud as a single data packet 1630L with a payload comprising the combined data SDNP data 3. In operation, the signaling server generates duplicates of the incoming SDNP data 1 and SDNP data 2 from client nodes C _{1, 1} and directs them to the SDNP security agent 1840 at address “IP SA”. Instructs the SDNP gateway with "M _0,0 " and "IP M _0,11 ". Replicated data is used for all SDNP data transfers, except that the security agent operates within its own specific secure zone, i.e. within a zone (SA) using credentials that cannot be used on any other device. is transmitted within data packets 1841A and 1841B using the same hypersecure method. Therefore, there is no record or evidence that a given security agent monitored a specific conversation.

Because SDNP monitoring activities are covert and essentially undetectable, equivalent to non-exposed conference calls, the SDNP system is required to authorize and verify the use of network monitoring and to designate and identify authorized SDNP security agents to perform monitoring. It is important to use independent checks. The SDNP security agent can be any SDNP client, except a network manager. As a protection against system corruption, any SDNP network operator or SDNP administrator cannot act as an SDNP security agent, meaning that anyone managing the network can destroy that ability for their own sake, even when they are threatened or blackmailed. Can not.

SDNP security agents may consist of individuals, government agencies, government-appointed representatives, or judicial officers. The specific required qualifications of a designated security agent vary by company or country depending on applicable local 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 a designated SDNP security agent are transmitted in the same hypersecure communication as the client's communiqué itself, and security monitoring therefore ensures the confidentiality of the call, or Does not compromise caller privacy.

Additionally, monitoring of authenticated SDNP agents and implementation of permitted capabilities does not compromise network integrity and security by any means. The operation of the SDNP system occurs automatically and autonomously, without the intervention or involvement of a human operator - without exposing operational details or DMZ shared secrets to network operators or arbitrary security agents, while the DMZ server provides online access. Provides security using zone-specific credentials that cannot be used through . Accordingly, security monitoring does not reduce 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 to ensure that no network security specifications are present within the data packet 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 use an independent key server utility that can be accessed by the SDNP network. Otherwise, the SDNP security agent will have to destroy the client's end-to-end password. To reiterate, such end-to-end encryption and decryption keys are included in the SDNP method primarily for privacy purposes and are not associated with 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 deploy and authenticate designated SDNP security agents for monitoring clients or groups of clients. Although the SDNP system includes provisions for conducting monitoring, lawful application of these features is the responsibility of the network operator, network administrator, and certification agency or agent. These parties, together, are individually responsible for ensuring that monitoring is conducted legally and in accordance with the laws of the country in which it is conducted.

Monitoring needs can arise from any number of situations. In a company, a whistleblower complaint or claim related to sexual harassment can trigger an HR investigation or result in a forensic investigation. Court subpoenas related to litigation matters (potentially including gag orders) may also require monitoring. In corporate matters, communications using the corporate SDNP network are generally limited to company 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 the caller's public and private SDNP accounts may be monitored. In such cases, the corporate SDNP network operator for the company will conduct a monitoring process for corporate communications, whereas the independent telecommunications SDNP network operator will be the only provider in a position to perform monitoring of the caller's private communications. . In some countries, the government must produce a court-approved subpoena to begin monitoring private citizens, while in other countries the government can assert the authority to monitor any and all private communications on a fact-based basis. 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 authorizing monitoring of clients includes a network manager 1850 used to set up monitoring operations, preferably operating autonomously and independently of the network operator or network management, and a security agent 1840 responsible for monitoring the clients. , and three authentication agents (1851A, 1851B, and 1851C) used to authorize the monitoring process. The process begins with a 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 telephone 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 the authentication step 1863, the network manager 1850 uses exemplary dialog box 1864 to identify recommended candidate security agents 1840 to perform the monitoring function. In the case of a corporation, the individual may be the HR director, general counsel, member of the audit committee, and representative of an independent accounting firm, or independent investigator. In legal cases, a security agent may be a judicial officer, district attorney, FBI agent, or other duly appointed investigative committee member, such as a special prosecution 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, follow-up checks on proposed security agent credentials and criminal records may be conducted prior to approval.

Once the security agent is authorized, in the authentication phase 1865, the request for monitoring is forwarded to authentication agents 1851A, 1851B, and 1851C, which provide a security message with a descriptive name for the subject and a task for performing monitoring. Review the information present in the dialog box 1866, including the agent's name or location, the expected duration of the monitoring survey, and the reason for the survey. Each authentication agent can accept or reject the request. The network operator's or company's rules then determine whether the monitoring operation is approved based on unanimous approval of the authentication agents or simply by majority. The identity of the authentication agent 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 features of the SDNP network.

Once monitoring is approved, in the management step 1867, the client's database 1868 is updated in the name server 1714 to tag the monitored SDNP client, the SDNP client authenticated as a security agent, data shaded in this example. Identify the row of . SDNP addresses in this database are updated together daily when SDNP addresses are mixed to maintain the same relationship between monitored clients and designated security agents. When the survey date expires, the monitoring link is automatically disconnected. In the management phase 1869, SDNP security agents 1840 are sent to the link, allowing them to receive all ongoing communications of the identified clients being monitored. Their use of this information is not a problem for SDNP network operation. An unauthorized disclosure of an individual's private information by a security agent may constitute a crime for which the security agent is fully responsible.

Through this inventive monitoring method, the SDNP network can thereby support criminal investigations of misconduct and potential terrorist activities, while maintaining a secure communications media for law-abiding citizens. The SDNP network can securely deliver private client communications to authorized parties pursuant to lawful court orders without jeopardizing the privacy of innocent citizens or compromising the security of the SDNP global communications network. Because no backdoors or master keys were used in the delivery of court orders, subsequent communications across the SDNP network remain anonymous and hypersecure. In this way, secure dynamic communication networks and protocols and their hypersecure last mile communications can provide security features that are not available by any other means, and are used by OTT and virtually all messenger and communicator apps. -Completely prevents aiding crime and terrorism caused by over-reliance on two-end encryption.

Overcoming SS7 Vulnerabilities - If the Apple-FBI controversy wasn't a big deal for the communications and security industry, a 60 Minutes episode (http://www.cbsnews.com/news/60-minutes-hacking-your-phone/) would have been, They exposed serious security vulnerabilities in Signaling System 7, or SS7, the signal control channel for conventional wireless telephony. As made clear in those shows, the SS7 vulnerability potentially exposes all smartphones and connected devices to packet sniffing and cyberattacks, thereby eavesdropping on wireless conversations and SMS texts, simply by knowing an individual's phone number. Enables observation of attached files and photos.

Signaling System 7 is a telephone call signaling protocol developed in 1975 that is used in all forms of digital phone calls worldwide. This includes a message passing portion or “MTP” operation that operates 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, which operates 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 necessity, is extremely vulnerable to attacks and poses a significant risk to the security of ordinary phone calls.

In April 2016 (https://en.wikipedia.org/wiki/Signalling_System_No._7), the U.S. Congressional Oversight Committee stated that "applications with these vulnerabilities range from criminals monitoring individual targets to economic espionage against U.S. companies." It is believed that there are no restrictions, ranging from foreign entities operating in the United States to countries monitoring U.S. government officials. “Many innovations in digital security – such as using multi-factor authentication – could become obsolete,” the report said.

SS7 cyber attacks essentially result from a class of packet sniffing, intercepting 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 the subscriber and their account. As shown, a carrier SIM card 1880, typically issued by a network provider, is connected 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 telephone 32. Each SIM card contains a unique identifier, an 18 or 19 number ICCID or “Integrated Circuit Card ID” used to identify the SIM card internationally. The International Mobile Subscriber Identity, or IMSI, identifies the individual operator network, i.e. the home network on 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 that identifies the country in which the SIM card was issued. When placing an international cellular call from a mobile phone, MCC is required as part of the dialing sequence. Examples of MCCs include 310 to 316 for the United States, 234 to 235 for the United Kingdom, 460 for China, 208 for France, 250 for Russia, 262 for Germany, 302 for Canada, and 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 includes a 15-digit “Mobile Station International Subscriber Directory Number” or MSISDN, which specifically identifies the subscriber and type of network on which the SIM operates. The SFM card also maintains a user phone number and SMS text directory, which contains a record of incoming and outgoing calls and sent texts along with time and date information. In recent years, carriers have begun using special SIM cards with a so-called secure element for storing credit card credentials to facilitate mobile payments.

Because the MCC, MNC and MSISDN codes are transmitted as part of the connection process, the home country and carrier of any SIM card and the subscriber's associated phone number can be easily identified by SS7 intrusion and packet sniffing. The transmitted data 1881 can easily be used to trace the caller's identity through phone directories, online information, or social media, such as through profiling. Once identified and correlated, the phone number and SIM can be used to monitor the subscriber's activities, regardless of where the subscriber moves in the world. Encryption does not conceal underlying currency 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 transmits a message to the local cell tower identifying its availability for a particular call. These registration packets are sent 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 on a call and even when GPS is turned off. In that way, a subscriber's location and movements can be accumulated without them knowing.

Despite SS7's inherent vulnerabilities, hypersecure last-mile communications built on secure dynamic communication networks and protocols prevent SS7 attacks by obscuring meaningful call data within the last link. In particular, hypersecure last mile communications offer significant security advantages over traditional phone calls or OTT Internet communications, including:

* Hypersecure last-mile communications do not reveal the phone number or IP address of the calling or message-receiving party, even if the party is not an SDNP client.

* Hypersecure last mile communications do not distinguish 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 communications hides metadata about call duration.

* 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.

Accordingly, as described, communications utilizing the disclosed secure dynamic communications networks and protocols and hypersecure last mile communications are not affected by the SS7 vulnerabilities. Because SDNP communications originate using its own protocol and are carried by encoded payloads, call data or content, even in packets carried over open, unencrypted channels such as 2G, 3G, and 4G/LTE phone calls. cannot be extracted from SDNP data packets. Accordingly, packet sniffing is ineffective in initiating cyber-attacks against SDNP coding and fragmented data transmission.

SDNP Concealment - As discussed above, the only impact SS7 vulnerability has over SDNP communications is the disclosure of the caller's location. Because the phone number within the carrier's SIM is associated with each user's identity, each time the cell phone is turned on, it essentially communicates with the nearest cell phone tower, even when no phone call is occurring. This cell tower information can then be used to triangulate the user's location and track the subscriber's movements even when GPS is turned off. Because such unauthorized tracking relies on SS7, devices using SIM cards from common carriers are vulnerable to location tracking, even if such devices operate as SDNP clients.

As shown in Figure 110, a simplified network schematic, the enhancement of last mile hypersecure communications, referred to herein as “SDNP Stealth,” completely prevents subscriber tracking. To implement this feature, the regular carrier SIM card 1880 is replaced with an SDNP SIM card 1882. The SDNP SIM card is registered with the SDNP network operator, not the subscriber, and therefore no personal subscriber information is included in 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 cloaking hides the owner's true identity by utilizing the SIM card 1882, known only to the SDNP network operator. Accordingly, the phone number contained on the SIM card is used to establish a PHY Layer 1 and data link layer 2 connection 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.

When routed through SDNP gateway 1601A, calls from the SDNP app appear to have a different number than the SIM card number. This translation from a physical SIM card number to an 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 a SIM phone number, thereby Conceals the physical SIM card number to the user. With SDNP concealment, the true identity of the phone owner is completely concealed. To call an SDNP client, external callers, even if they are not SDNP clients themselves, can dial SDNP #. The SDNP network automatically routes calls to SDNP clients without ever revealing the SIM card phone number. Similarly, the SDNP client places a call out to a non-SDNP called party, and the call recipient confirms the incoming call from the SDNP #, not from the SIM card number. In this way, 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 revealed by call 28B, triangulating the phone's location is ineffective, as the user and all communications remain anonymous. Therefore, tracking the location of an unidentified mobile phone is not advantageous to hackers and avoids the SS7 vulnerability. If an SDNP client moves internationally, the mover can purchase a local prepaid SIM card and link it to its SDNP number. SDNP subscribers will still receive calls placed on their SDNP phone number, but the last link will be made using a local SIM card, thereby avoiding roaming charges. In this way, a single SDNP phone number functions as an international phone number, without long distance costs.

SDNP Subnet - Utilizing specific soft-switch software-based communication nodes, the SDNP communication cloud can be deployed remotely across any network of interconnected computers, private or publicly hosted. Examples of server networks include privately owned and 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 including servers 1901A, 1901B, 1901C, and 1901D host SDNP communication nodes M _0,0 , M _0,4 , M _0,7 , and M _{0,8 ,} respectively. A second SDNP cloud containing 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 Zone (Z0) and Zone (Z10) respectively, the two SDNP clouds are completely separate and cannot share information directly. 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} within the zone (Z0) cloud using hypersecure last mile communication through router 1910 and chat or SDNP gateway node M _10,0 within the zone (Z10) cloud can be accessed using hypersecure last mile communication through the same router 1910, without risk of mixing of data packets.

Access to the two independent clouds is via a common communicator application (UI/UX 1920). Access to each cloud is partitioned within separate dialog sandboxes 1921A and 1921B. Although information may be downloaded into the phone from the personal account sandbox 1921A, the release of data from the business account sandbox 1921B is dependent on the business and company's security controls.

A device's connection to the SDNP cloud requires installation of the SDNP app, as software or firmware, into the device. Installation involves (i) downloading the application, (ii) verifying device identity with an SDNP network-generated authentication code, (iii) establishing personally identifiable credentials, and (iv) authorizing a specific SDNP cloud association. Includes receiving. Once activated, the SDNP application creates a hypersecure last-mile connection to an independent SDNP cloud. In many cases, identity validation and user authentication for business accounts are more sophisticated than those required for personal account access and may involve multiple authentication methods.

Because SDNP communications are software-based, there is no interaction between any installed SDNP communications networks, even when hosted by the same server, with separate and separate security credentials for each communications cloud. In terms of the zone-specific security credentials that uniquely shape each custom SDNP cloud, no two SDNP clouds are similar and therefore cannot share data directly. Advantageously, multiple SDNP clouds can coexist within the same server or server network, without risk of data leakage. Access to the business network is controlled as defined by the cloud owner's requirements. Therefore, mixing of two accounts and communication clouds is prohibited when sharing a common host server, operating with the same security, such as when two different phones are required to be connected to two separate networks. The autonomy of zone-specific SDNP clouds or “subnets” is further illustrated in Figure 112, where servers (1901A, 1901B, 1901C, and 1901D) are connected to two clouds - Zone-Z0 SDNP communication nodes M _0,0 , M _{0 ,4} , one cloud each containing M _0,7 , M _0,8 , and a second cloud containing Zone-Z7 SDNP communication nodes M _7,0 , M _7,4 , M _7,7 , M _7,8 . Host 2 clouds simultaneously. Despite operating within the same server, hypersecure communication using the SDNP-built protocol prevents any direct data exchange. Accordingly, access is managed by last mile communication rather than through direct inter-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 private companies to host their own networks, especially for business critical applications. Examples of private networks include FedEx, Walmart, IBM, etc. For confidentiality reasons, networks utilized 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, and e-Insurance; Media streaming services such as YouTube, Amazon Prime, Netflix, Hulu, and Comcast Xfinity; And it is used to host social media such as Facebook, Twitter, and Snapchat.

In large corporations, the IT department may choose to operate separate networks for the parent company and its subsidiaries. However, for many privately hosted businesses, infrastructure costs are considered a significant factor in network design. Instead of supporting two completely 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 Figure 113, two legal entities, e.g., 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 the parent company, while servers ( 1901A, 1901B, 1901C, and 1903) host 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 nodes M _0,8 for the subsidiary. Because of their separate security credentials, data is not shared directly between the parent SDNP Cloud and the subsidiary SDNP Cloud, although server 1903 and other servers (not shown) are shared by both entities. Typically, employees are restricted to accessing only their employer's cloud, but in the case of company administrators, access to both clouds may be required. Appropriate authenticated users as shown by the SDNP Communicator app (UI/UX 1920) include separate dialog sandboxes 1921C and 1921D for the various corporate entities. In this way, one phone or tablet can access multiple SDNP clouds of different entities without risk of collating data, as would be the case if a user carried multiple phones.

The multi-profile feature of the SDNP app, 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 Figure 114, for example, SDNP client C _1,1 spans zone Z99 global SDNP telco containing servers 1909A through 1909E hosting SDNP nodes M _99,1 through M _99,5 , respectively: It is possible to make international calls without long distance costs, and includes servers (1905A, 1905B, and 1905C) hosting SDNP nodes M _9,0 , M _9,4 , and M _9,8 , for example. Access to the Zone Z9 corporate cloud can be obtained and the Zone Z0 cloud through servers 1901A, 1901B, and 1901C that also host SDNP nodes M _0,0 , M _0,4 , and M _0,8 , respectively. You can call the subscriber. 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 of the system used to manage authenticated users.

SDNP communications can equally be applied in high security and limited access networks required for government and security purposes. For example, in the United States, secure restricted communications include a variety of organizations, including local and state law enforcement, the FBI, the National Guard, the National Security Agency, the United States Armed Forces (separately or combined), the U.S. Department of State, along with congressional and judicial server networks. Required by 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 may be implemented using SDNP communication methods and technologies. For example, in Figure 115, a nested SDNP cloud structure includes leased computer servers 1907A through 1907D hosting SDNP communication nodes M _0,0 , M _0,4 , M _0,5 , and M _0,9 , respectively. ) includes a secure cloud that includes Communications within this external network "shell" include zone Z0 security credentials and are displayed within the "secret" level dialog sandbox 1912E as displayed in the SDNP communicator 1920. The nested cloud also has enhanced security credentials with zone Z8 security credentials, including government-hosted servers (1906A, 1906B, and 1906C) corresponding SDNP server nodes M _8,0 , M _8,2 , and M _8,4 . Contains an inner core. In order for Client C _1,1 to gain access to the Zone Z8 core, they must have a "Top Secret" security level and communicate through an enhanced communications sandbox (1921F). One exemplary government application of these technologies is at the U.S. Department of State, where top secret communications within Area Z8 are restricted to access by ambassadors and secretaries of state, while other U.S. embassy personnel throughout the world have Area Z0 security credentials. Limited to hypersecure "secret" communications using .

Claims (26)

In the SDNP last mile communication network,
Two or more devices hosting SDNP software, each comprising an SDNP client, SDNP firmware, or SDNP bridge, and capable of communicating digital packets containing datagrams created in accordance with the SDNP protocol, wherein the SDNP software and the SDNP protocol are one or more Two or more devices comprising applying a concealment method to a datagram, wherein the one or more concealment methods include at least one of dynamic scrambling, encryption, junk data addition, packet splitting and mixing, meshed packet transmission, and packet routing. ; and
One or more datagrams in transit in the communication network, each comprising the datagram, routing information, SDNP payload, and state-based security credentials allowing dynamic application of one or more of the cloaking method for junk data, wherein The SDNP payload includes one or more of identification, routing, status, and security credentials along with data representing voice, images, video, databases, presentations, documents, spreadsheets, financial information, games, software, or other digital information. one or more datagrams;
Includes,
An SDNP last mile communications network, wherein only a device hosting SDNP software can decode and interpret the contents of the datagram or execute instructions contained within the datagram. According to paragraph 1,
further comprising one or more IP datagrams,
An SDNP last mile communications network, wherein each of the one or more IP datagrams includes a TCP/IP based source and destination address for packet routing, along with an SDNP payload. According to paragraph 2,
The SDNP last mile communications network, wherein the TCP/IP based source and destination addresses are generated by Dynamic Host Configuration Protocol (DHCP) or issued by a Network Address Translator (NAT). According to paragraph 1,
An SDNP last mile communications network, wherein each datagram includes SDNP based source and destination addresses. According to paragraph 4,
SDNP last mile communications network, wherein the SDNP based source and destination addresses are generated by SDNP software. According to clause 5,
It further includes a gateway node of the SDNP cloud, an outgoing datagram leaving the gateway node, and an incoming datagram previously entering the gateway node, wherein the destination address of the outgoing datagram is included in the SDNP payload of the incoming datagram. SDNP last mile communication network, identical to the built-in address. According to paragraph 1,
further includes IP datagrams,
SDNP last mile communications network, wherein the SDNP payload of the IP datagram includes TCP/IP-based source and destination addresses for packet routing. In clause 7,
Further comprising a gateway node within the SDNP cloud,
SDNP last mile communication network, where SDNP clients connect to the gateway node via Ethernet or a WiFi router that is not activated as an SDNP node. In clause 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, and some of the Ethernet or WiFi routers are activated as SDNP nodes and the Ethernet or WiFi router is connected to the second SDNP client. Or, some of the WiFi routers are not activated as SDNP nodes, SDNP last mile communication network. In clause 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 group of devices not activated as SDNP nodes. SDNP last mile communications network, including a second device group. In clause 7,
A first device group 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, an SDNP last mile communications network, including a second group of devices that are not activated as SDNP nodes. According to paragraph 1,
It further comprises 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, the cable distribution network and cable modem comprising a first device group activated as an SDNP node, and an SDNP node. An SDNP last mile communications network comprising a second group of devices that are not activated. According to paragraph 1,
a first SDNP client and a second SDNP client, wherein the first SDNP client is connected to the second SDNP client via a cable distribution network and a cable modem, and the cable distribution network and cable modem are activated as an SDNP node. An SDNP last mile communications network comprising a first device group and a second device group that is not activated as an SDNP node. According to paragraph 1,
It further comprises a router and a gateway node in the SDNP cloud, wherein the router is configured to include 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. SDNP last mile communication network connected to nodes. According to clause 14,
The second device group includes one or more of a personal computer, a home phone system, a laptop 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. , SDNP last mile communications network, including printer-scanners, shared data-drives (storage), security systems, cameras, light fixtures, motorized blinds, central HVAC thermostats, appliances, indoor HVAC, and garage doors. According to paragraph 1,
wherein the communication network includes a bridge network, and the two or more devices are included within the bridge network. According to clause 16,
An SDNP last mile communications network, wherein data packets transmitted between the devices in the bridge network include SDNP based source and destination addresses. According to clause 16,
An SDNP last mile communications network, wherein the bridge network includes an SDNP bridge router, wherein the SDNP bridge router can also function as a WiFi or Ethernet router using TCP/IP based datagrams. According to clause 18,
The SDNP last mile communications network, wherein the SDNP bridge router is capable of accessing the content of SDNP datagrams and converting commands, addresses and other packet content made according to the TCP/IP protocol to the SDNP protocol and vice versa. According to clause 16,
The bridge network includes a physical medium, where the physical medium includes wired communications including wires, cables, and optical fibers modulated according to communications standards including TCP/IP, Ethernet, or DOCSIS III, or WiFi, 2.5G, 3G. , SDNP last mile communications network, comprising wireless communications using optical or radio waves modulated according to communications standards including 4G, 5G, microwave communications, satellite communications, WiMax, or long-range WiFi protocols. According to clause 16,
The bridge networks are used for a variety of communications, including fixed-location terrestrial communications, communications with trains, ships, aircraft, or other mobile vehicles, communications between terrestrial networks and satellite or mobile telephony networks, and communications with terrestrial base stations and mobile communications. SDNP last mile communications network, including communications between vehicles. According to clause 16,
SDNP last mile communication network, wherein the communication content of the bridge network is divided into two or more datagrams, each of which is carried by a different physical medium, a different carrier frequency, a different microwave band, or a different modulation scheme. According to clause 16,
An SDNP last mile communications network, wherein the bridge network includes high-bandwidth communications trunks between SDNP-based servers or SDNP gateways. According to paragraph 1,
An 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 clause 24,
Within the peer-to-peer network, the vehicle can communicate with the cellular tower through intermediate vehicles when the vehicle cannot reach the cellular tower directly. According to clause 24,
An SDNP last mile communications network, wherein the content 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 activated as an SDNP client.