JP2023011781A - Method and apparatus for hyper-secure last-mile communication - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method and an apparatus that facilitate hyper-secure "last-mile" communication between a device and gateway and a network or cloud.

SOLUTION: In a packet scrambling process, each of two or more devices contains datagrams created according to the secure dynamic communication network and protocol (SDNP). SDNP includes applying one or more concealment methods to the datagrams. The one or more concealment methods include at least one of dynamic scrambling, encryption, junk data addition, packet splitting and mixing, mesh packet transport, and packet routing.

SELECTED DRAWING: Figure 2A

COPYRIGHT: (C)2023,JPO&INPIT

Description

(Cross reference to related application)
This application claims priority from U.S. Provisional Application No. 62/480,696, filed April 3, 2017, and from U.S. Provisional Application No. 62/107,650, filed January 26, 2015. This is a continuation-in-part of US Application Serial No. 14/803,869, entitled "Secure Dynamic Communication Networks and Protocols," filed July 20, 2015, claiming priority. Each of the aforementioned applications is incorporated herein by reference in its entirety.

(Technical field)
The present invention relates to methods and apparatus for facilitating hyper-secure "last mile" communications between devices and gateways and networks or clouds.

Improved means of communication have advanced civilizations since the earliest beginnings of mankind. From the use of couriers and couriers traveling on foot or on horseback, through mail delivery by train, truck and plane, through telegraph, telephone, radio, television, computers, mobile phones, and the Internet, e-mail, and the emergence of the World Wide Web (WWW), and more recently through social media, voice-over-Internet, machine-to-machine (M2M) connectivity, Internet of Thing (IoT), and Internet of Everything (IoE). , telecommunications have always been at the forefront of the use of modern technology. With each new era of telecommunications technology being adopted, the number of people connected and the speed at which information is conveyed between them also increases.

The impact of this trend is that humanity is more connected than at any time in history, and communication technologies are meant to connect private, personal, family, and financial information. People trust and rely on safe and reliable delivery only to authorized audiences. Knowledge and information will be delivered to millions of people in seconds, allowing friends and family to reach people on the other side of the globe at the touch of a button. It is often said that the world has become a very small place.

While such advances are highly beneficial to everyone, there are also pitfalls of our heavy reliance on technology. For example, if a communication system fails to perform during an earthquake or stormy weather, even temporarily, the "no connection" causes people to become confused or even panic. The quality of service (QoS) of a communication system, or medium, is an important measure of the performance of a communication network. People's peace of mind, financial wealth, identity, and even their very lives depend on reliable and secure communications.

Another consideration of communication networks is their ability to guarantee privacy, safety, and security to their clients. As communication technology has evolved, so has the sophistication of criminals and "hackers" who intend to play tricks, disrupt systems, steal money, and harm others, either accidentally or maliciously. . Credit card fraud, password theft, identity theft, and unauthorized release of confidential information, private photos, files, emails, text messages, private tweets (stolen to embarrass or victim of extortion) are the modern These are just a few examples of cybercrime.

Notable examples of privacy violations and cyber crimes at the time of this patent filing are listed below to provide a chronological timeline of the prevalence of security problems in modern open communications networks.
"Target: Stolen Information Involving At Least 70 Million People", CNBC, Jan. 10, 2014 "Hackers Send Malicious Emails on High-end Refrigerators and TVs," BGR, Jan. 2014 March 20 ・“Thermostat hacked, secret dispute between Nest and Google reopened”, Slash Gear, June 24, 2014 ・“Account hijacking raises questions about LINE data security. The calling and messaging application LINE has been shaken by a recent spate of data security breaches, in which hundreds of user accounts were found to have been compromised by someone other than the account's user.” Nikkei Asia Review, July 2, 2014 “NSA Data Sweep Engulfs Ordinary Americans, Reported Complaints,” AP, July 6, 2014, “Smart LED Bulbs Exfiltrate WiFi Passwords,” BBC News , July 8, 2014 “Six people were scammed to buy Prime tickets on StubHub. Targeted by hackers selling 1,000 tickets, New York State officials say.”, Bloomberg, July 24, 2014 “Study Shows IoT Highly Vulnerable to Hacking,” International Business Times ( www.ibtimes.com )
“Russian Hacker Collects Over 1 Billion Internet Passwords,” New York Times, August 5, 2014 “New Leaker Reveals America's Secrets, Government Conclusions,” CNN, 8, 2014 Mon 6 “Hackers Root Nest Thermostat Bought by Google in 15 Seconds”, The Enquirer (www.theinquirer.net), Aug 11, 2014 “Same Malware Targets Dairy Queen Company Hacked by”, Christian Science Monitor, August 29, 2014 ・“Celebrity Victims of Nude Photo Leaks – Security Vulnerability in iCloud Accounts”, CBS News, September 1, 2014 “ Home Depot could be the latest target of a credit card breach, which could be much larger (40 million cards stolen over 3 weeks). Fortune, Sept. 2, 2014 “Mysterious Counterfeit Cell Phone Towers Are Intercepting Calls Across America,” Business Insider, Sept. 3, 2014, “Hacking Attack: Banks to Retail Hey, what are the signs of cyberwarfare?”, Yahoo Finance, Sept. 3, 2014 ・“Home Depot admits payment systems were hacked at US and Canadian stores,” Fox News, Sept. 2014 9th “Yahoo hits court battle with U.S. government over surveillance,” CBS/AP, Sept. 11, 2014 “Your medical records are more valuable to hackers than credit cards,” Reuters, 2014 September 24, 2009 Red Alert: HTTP Hacked. Browser Crasher for SSL/TLS (BEAST) Attacks Ranks Worst Hacks, as it Involves Browser Connections Hundreds of Millions Rely on Every Day InfoWorld, Sept. 26, 2014 "Sony Cyberattack, Initial Sabotage Swiftly Flared", New York Times, Dec. 30, 2014

At a time when the pace of cybercrime, security breaches, identity theft, and invasion of privacy seems to be picking up, the question is, "How are all these cyberattacks possible and what can be done to stop them?" Is it?” While society demands more privacy and security, consumers also demand greater connectivity, cheaper and higher quality communications, and greater convenience in conducting financial transactions.

To understand the performance and vulnerabilities of modern communication networks, data storage, and connected devices, modern electronic, wireless, and optical communications are used to analyze files, email, text, audio, and video. It is first important to understand how data, including images, are manipulated, transferred and stored.

Circuit-switched telephone network operation

Electronic communication includes various hardware components or devices connected in networks of wire, radio, microwave, or fiber optic lines. Information is passed from one device to another by transmitting electrical or electromagnetic energy through this network, using various methods to embed or encode the "content" of the information in the data stream. be Theoretically, the maximum data rate of these networks is set by the laws of physics at the speed of light, but in most cases data encoding, routing and traffic control, signal-to-noise quality, and electrical noise, electromagnetic noise, Practical limitations in overcoming optical noise and unwanted electronic parasitics disrupt or impede information flow, limiting the capacity of communication networks to a fraction of ideal performance.

Historically, electronic data communication was first accomplished using dedicated "hardwired" electrical connections that formed a communication "circuit" between two or more electrically connected devices. . In the case of the telegraph, a direct current (DC) electrical circuit is manually created using a mechanical switch to break the current, magnetize a solenoid that rotates and moves a metal lever, and activates the switch pressed by the sender. Click on Listening Devices, or Repeaters, in a pattern similar to Patterns. The sender then encodes the information into a pulse train using an established language, Morse code. The recipient similarly needs to understand Morse code, a series of long and short pulses called dots and dashes, to understand the message.

Later, Alexander Graham Bell developed the first telephone using the concept of "wave current", now called alternating current (AC), to transmit sound through electrical connections. The telephone network included two electromagnetic transducers connected by an electrical circuit, each including a movable diaphragm surrounded by a fixed permanent magnet enclosure and a coil, or "voice coil." When speaking into the transducer, 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. At the listener's end, the time-varying current flowing in the voice coil induces an identical waveform facing the surrounding magnetic field and a time-varying magnetic field, pushing the voice coil back and forth in the same manner as a transducer that captures sound. move. The resulting motion reproduces the sound in the same way as the device that captures the sound. In modern parlance, when the transducer converts sound into electrical current, it operates as a microphone; when the transducer converts electrical current into sound, it operates as a speaker. In modern times, such electrical signals are also called analog signals, or analog waveforms, because the propagated electrical signals resemble natural pressure waves in the air, ie audio waveforms carried as sound.

As explained, transducers are used for both speaking and listening, so conversation requires both parties to know when to speak and when to listen. In such a system, like two empty cans connected by a string, i.e. a string telephone, the caller cannot speak and hear at the same time. Such one-way operation, called a "half-duplex" scheme, may sound classical, but in modern radio communications in transceivers and in the modern telephony termed "push-to-talk" or PTT, is still in common use today.

Later full-duplex (ie, two-way or transmit-receive) telephones were equipped with separate microphones and speakers, and it became commonplace to be able to speak and listen simultaneously. However, even today, when operating full-duplex telephony, feedback, that is, the recipient's voice is picked up by a microphone and fed back to the caller, produces confusing echoes and sometimes annoying noises. Care must be taken to prevent problems such as erroneous transmission, a problem that particularly plagues long distance telephony.

Early telegraph and telephone systems were plagued by another problem, the issue of privacy. In these early communication networks, everyone connected to the network hears all information communicated over the circuit, even if they don't want to. In non-urban telephone networks, these shared circuits were known as "party lines." The telephone system then rapidly evolved into a multi-line network, with leased lines connecting directly to individual customer telephones at the telephone office's branches. Within branch exchanges, system operators manually connect callers to each other through switches using jumper cables, and also connect one branch to another for initial "long distance" telephone service. It had the function of forming Large arrays of repeaters forming telephone "switch" networks gradually replaced human operators and subsequently electronic switches containing vacuum tubes.

After Bell Laboratories developed the transistor in the late 1950s, fragile and hot vacuum tubes were replaced in telephone and branch exchanges by cold-running solid-state devices containing transistors and eventually integrated circuits. As networks grew, phone numbers expanded from seven digit prefix numbers and private numbers to include area codes and eventually country codes to handle international calls. Copper cables carrying voice calls soon covered the world and crossed the oceans. Regardless of the size of the network, the principle of operation remains the same, and calls are made directly and electronically between the caller with voice carried by analog signals and the routing of the call determined by telephone switches. It represented a connection, or "circuit". Such telephone systems eventually came to be known as "circuit-switched telephone networks" or as the basic telephone system, or POTS. Adoption of circuit-switched telephony peaked in the 1980s and has since been replaced by "packet-switched telephony," which is described in the next section.

Evolving almost in parallel with the telephone network, regular radio communication began in the 1920s with radio broadcasts. The broadcast was unidirectional, originating from a radio station on a particular government-licensed frequency and received by any number of radio receivers tuned to that particular broadcast frequency, or radio station. The broadcast signals carried analog signals using either the amplitude modulation (AM) scheme, or the later frequency modulation (FM) scheme, respectively, in a dedicated portion of the licensed radio spectrum. In the United States, the Federal Communications Commission, or FCC, has evolved to manage the allocation of such licensed bands and regulations. The concept of broadcasting has been extended to the broadcasting of television programs using radio transmission. Television programs initially contained black and white content, but later aired in color. Television signals could then also be carried to people's homes either by microwave satellite television reception antennas or via coaxial cables. The term "multicast" is now used for such unidirectional multi-listener communication, since any viewer tuned to a particular broadcast frequency can receive the broadcast.

With the advent of radio broadcasting, the first two-way communications began on commercial and military sea vessels. By the time of World War II, radio had evolved into portable radio transceivers that combined transmitters and receivers into a single unit. Similar to telephony, early two-way radio transmissions operated in a "simplex" manner, allowing only one radio to broadcast on a radio channel while other radio channels could not. By combining different frequency transmitters and receivers, it was possible to transmit and receive simultaneously at both ends of the radio link, allowing full-duplex communication between the two parties.

However, to prevent duplicate transmissions from multiple parties, a protocol called half-duplex, or push-to-talk, is commonly used for channel management, allowing anyone to monopolize a particular channel on a first-come, first-served basis. can be sent directly. 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 transceiver communications. In these two-way radio networks, radios transmit data over specific frequency "channels" to a central radio tower, which amplifies and repeats the signal and transmits it across the radio network. The number of available frequencies carrying information in a broadcast area sets the total bandwidth of the system and the number of users that can independently communicate over the wireless network at one time.

In the 1970s, the concept of cellular networks was demonstrated in the 1970s and decades afterward, dividing a large area into smaller portions, or wireless "cells," to expand the total capacity of the wireless network and handle more callers. popularized within. The cellular concept is to limit the coverage area of radio towers to a smaller range, i.e. a shorter distance, thus reusing the same frequency band to simultaneously handle different callers residing in different cells. can be done. To that end, software has been created to manage the handoff of a person calling from one cell to an adjacent cell without "cutting off" and abruptly disconnecting the communication. Like POTS, two-way radio, radio and television broadcasting, the first cellular networks were analog in nature. To control call routing, a telephone number system was employed to determine appropriate wireless electrical connections. This choice also had the advantage of seamlessly connecting the new wireless cellular network to the "wired" traditional telephone system, providing interconnection and interoperability between the two systems.

In the 1980s, telephony and radio communications, in addition to radio and television broadcasts, carried data and text with voice to reduce power consumption and improve battery life and to improve signal-to-noise quality. To begin to address the problem of need, we began the inevitable transition of communication methods and formats from analog to digital. With the advent of wireless formats such as EDACS and TETRA, one-to-one, one-to-many and many-to-many communication schemes became possible. Cellular communications, like television broadcasts, have rapidly migrated to digital formats such as GPRS.

By 2010, most countries had canceled or were in the process of canceling all analog television broadcasts. Unlike broadcast television, cable operators did not have to switch to digital formats, maintaining a hybrid mix of analog and digital signals until 2013. Cable TV's eventual move to digital was for commercial reasons rather than government standards, expanding the number of available channels on the network, enabling delivery of HD and UHD content, and increasing pay-per-view. (PPV, (also known as "Unicast")) to enable programming and to provide customers with high-speed digital connectivity services.

Although it is common to equate the migration of global communications networks from analog to digital formats with the advent of the Internet, and more specifically with the spread of the Internet Protocol (IP), if not promoted, the digital format The conversion to IP precedes the commercial acceptance of IP over telephony and enables a worldwide migration of communications to IP and "packet-switched networks" (described in the next section).

The resulting evolution of circuit-switched telephony is the "Public Switched Telephone Network," or PSTN, which includes amalgamations and sub-networks of wireless, cellular, PBX, and POTS connections, each containing a different technology. For example, the networks include POTS gateways, circuit-switched cellular networks, PBXs, and PSTN gateways connected via wired connections to two-way wireless networks, connected by high-bandwidth trunk lines. Each sub-network can operate independently and drive similar devices.

The PSTN also connects to a circuit-switched cellular network 17 running AMPS, CDMA, and GSM analog and digital protocols. Via cellular radio towers, circuit-switched cellular networks use standardized cellular radio to connect mobile devices, such as cell phones. In the case of the GPRS network, an extension of GSM, the circuit-switched cellular network can also connect to tablets, carrying low-speed data and voice at the same time. Two-way wireless networks such as TETRA and EDACS connect the PSTN to handheld radios and desktop radios in larger dashboards via high-power radio towers and RF connections. Commonly used by police officers, ambulances, paramedics, fire departments, and even Gulf authorities, such two-way wireless networks, also called professional communication networks and services, are used by government rather than consumers. , local governments, and emergency responders (Note: As used herein, the terms “desktop,” “tablet,” and “notebook” are abbreviations for computers with their names.) used.).

Unlike POTS gateways, circuit-switched cellular networks, and PBXs, which use traditional telephone numbers to complete call routing, two-way wireless networks use dedicated RF wireless channels (rather than telephone numbers) to Establish a wireless connection between the tower and any mobile device. Professional wireless communication services are thus distinct and unique in nature from consumer cellular networks.

In other words, the PSTN network flexibly interconnects sub-networks of diverse technologies. It is precisely this diversity that defines the essential weakness of current circuit-switched networks: interoperability between subnetworks. Because various sub-networks do not communicate with any common control protocol and language, and because each technology handles data and voice transmission differently, various systems are not capable of making phone calls over the PSTN backbone or trunk lines. Inherently incompatible, except to a limited extent. For example, during the September 11 terrorist attacks on the World Trade Center in New York City, many emergency responders from across the United States converged in Manhattan to try to help fight the catastrophe, but radio communication systems and We simply learned that the transceivers were not compatible with volunteers from other states and cities, and it was impossible to manage the centralized command and control of relief efforts. Due to the lack of standardization in radio communication protocols, radios simply could not connect to each other.

Furthermore, when using direct electrical and RF connections in circuit-switched telephone networks, especially analog or insecure digital protocols, hackers with RF scanners can find active communication channels and It is easy to notice, sample, listen to and intercept conversations. Because the PSTN creates a "continuous" connection, or circuit, between communicating parties, there is plenty of time for hackers to scrutinize and "tap" the connection, and the government operating under federal courts. is lawfully ordered to be wiretapped by, or is illegally wiretapped by a cybercriminal or government conducting unlawful, prohibited or unauthorized surveillance. Definitions of legal and illegal espionage and surveillance, and the obligations of cooperation and compliance by network operators, vary widely from country to country, and among global companies such as Google, Yahoo, and Apple, which operate across numerous borders. has become a hotly contested point. Although communications networks and the Internet are global and do not recognize national borders or boundaries, the laws governing electronic information and the like are local and specific to the governmental regulatory agencies governing national and international communications and commerce at the time. Target.

Regardless of its legality or ethics, today's electronic snooping and surveillance is commonplace, from surveillance on every road and subway turn, to the ubiquitous security cameras installed overhead, in various countries. It extends to sophisticated hacking and code cracking performed by national security departments and organizations. All networks are vulnerable, but the PSTN's antiquity and inadequate security measures make it particularly easy to hack. Thus, even a PSTN connected to a secure modern network becomes a weak link in the overall system, creating vulnerability to security breaches and cybercrime. Nevertheless, it will still take years, if not decades, to decommission the global PSTN network and completely replace it with IP-based packet-switched communications. Packet-based networks (described below) are more modern than PSTN networks, but are still insecure and subject to security breaches, hacking, denial-of-service attacks, and invasion of privacy.

Packet-switched communication network operation

If two cans connected by a string, a string telephone, represents a metaphor for the operation of modern circuit-switched telephones, the post office represents a similar metaphor for packet-switched communications networks. Text, data, voice, and video are converted into files and streams of digital data, which are then parsed into quantized "packets" of data that are delivered over networks. The delivery mechanism is based on electronic addresses that uniquely identify the destination and source of data packets. The format and communication protocol are also designed to contain information about the nature of the data contained in the packet, which contains content specific to the program or application in which it is used and the physical and electrical connections that carry the packet. and hardware that facilitates connectivity or wireless connectivity.

Born in the 1960s, the concept of packet-switched networks was created during the post-Sputnik post-Cold War paranoia. At the time, the U.S. Department of Defense (DoD) was concerned that spaced nuclear missile strikes could obliterate the entire U.S. telecommunications infrastructure and disable the Soviet Union's ability to respond to a preemptive strike; Expressed concern that vulnerabilities to attacks and the like could actually lead to attacks. As such, the Department of Defense advocates the creation of redundant communication systems, or gridded "networks," whose ability to distribute information between installations is not hampered by the disruption of specific data links and numerous links within the network. supported. That system, known as ARPANET, became the parent of the Internet and the Eve of modern digital communications.

Despite the creation of the packet-switched network, Mosaic, the first accessible web browser, the emergence of web pages defined by hypertext, the rapid spread of the WWW, and the spread of electronic mail, gave Internet platforms a worldwide reach. The explosive growth of the Internet did not occur until the 1990s, when it gained strong support. One of its basic ideas, the lack of central control, i.e. the need for a central mainframe, has propelled the Internet to some extent universally, but this has been unstoppable by nations and governments (or the global and the user base contained consumers with newly purchased personal computers.

Another major impact of the growth of the Internet has been the standardization of the Internet Protocol (IP) used to route data packets through networks. By the mid-1990s, Internet users realized that the same packet-switched networks that carried data could also be used to carry voice, and the "Voice over Internet Protocol" or VoIP was born shortly thereafter. Although this concept theoretically allowed anyone with access to the Internet to communicate via VoIP for free, it is expensive to propagate across networks. This results in latency, poor voice quality and often obscurity. The adoption of fast Ethernet links, fast WiFi connections, and 4G data to improve connection quality in the “last mile” has improved latency, but the Internet itself is not the answer to accurate delivery of data packets. It is not intended to guarantee the time required to deliver packets, i.e. it is not intended to operate as a real-time network.

So the dream of using the Internet instead of expensive long distance carriers, or “telephone companies,” has come to fruition despite the availability of “expected” (OTT) providers such as Skype, Line, KakaoTalk, Viber, etc. was almost unfulfilled. OTT telephony suffers from poor quality of service (QoS) due to uncontrolled latency, poor sound quality, stalled calls, echoes, reverberation, feedback, erratic tones, and often the inability to even initiate calls. annoyed. The poor performance of OTT communications is not inherently a shortcoming of VoIP-based protocols, but rather of the network itself, where OTT carriers cannot control the path data travels or the delays faced by communications. OTT carriers are unable to guarantee performance or QoS as, in essence, OTT communications act as Internet hitchhikers. The companies that can take full advantage of today's VoIP-based communications are long distance operators with dedicated low-latency hardware-based networks and, ironically, the least motivated to do so. It's the phone company.

Aside from the inherent network redundancy, one of the greatest strengths of packet-switched communications is that data is arranged in packets consistent with the Internet Protocol and any transmission is possible as long as an Internet connection and linked communication device is provided. It is the ability to transmit information from the source to any destination. The Internet Protocol governs the ability of networks to deliver payloads to their destinations without any care or concern as to what information is being conveyed or which applications use that information; Completely avoid the need for expensive dedicated hardware. In many cases, even payloads associated with applications have established predefined formats. For example, to read emails, open web pages on a browser, view photos and videos, view Flash files, or read PDF documents.

Because its versatile file format does not rely on proprietary or company-specific software, the Internet can be considered an "open source" communications platform, connecting everything from computers to mobile phones, cars to consumer electronics. It is possible to communicate with the widest range of devices. The latest phrase to describe this universal connectivity is the “Internet of Everything” or IoE.

A large array of computers, including high-speed cloud servers, cloud data storage, interconnected by high-bandwidth connections, typically fiber optics, between a myriad of other servers (not shown) that form the cloud of the Internet be done. The cloud metaphor is appropriate because there are no clear boundaries defining which servers are considered part of the cloud and which are not. Every day, and even minutes, servers come online and can be taken offline for maintenance without any impact on the functionality or performance of the Internet. This is the benefit of a properly duplicated distributed system. That is, there is no single point of control and therefore no single point of failure.

The cloud may be connected to users or devices via various wired, WiFi, or wireless links. Wireless packet switched telephony includes cellular protocols 3G including HSUPA and HSDPA as well as 4G/LTE. LTE, or Long Term Evolution, is a network that ensures interoperability of various cellular protocols, including the ability to seamlessly hand off calls from one cell to another, even when the cells are operating with different protocols. refers to standards. (Note: As a matter of definition, "last mile" as used herein refers to the link between any type of client device, such as a tablet, desktop, or mobile phone, and the cloud server.) Directionality As such, the term "first mile" is sometimes used to identify the link between the data originating device and the cloud server. In such cases, the "last mile" link is also the "first mile".

For shorter-range communication, WiFi access points connect to smartphones, tablets, notebooks, desktops, or consumer electronics and can be used in localized wireless applications within homes, cafes, restaurants, and offices. WiFi includes communications that operate according to the IEEE defined standards for the single-carrier frequency specifications 802.11a, 802.11b, 802.11g, 802.11n, and most recently the dual-band 802.11ac format. WiFi security based on simple static login keys is primarily used to prevent unauthorized access to connections, but is not intended to protect data from eavesdropping or hacking indefinitely.

Routers connect to notebooks, desktops, phones, and televisions by fiber, coaxial cable, or Ethernet, or connect to hotels, factories, offices, service centers, banks, and It is connected to point-of-sale terminals that serve the stationary, or fixed, wired market, including homes. Digital Subscriber Line (DSL) connections are still used in remote areas where fiber or cable is not available, but data speeds and connection reliability suffer dramatically. Overall, the number of Internet-connected objects worldwide is projected to reach 20 billion by 2020, aggregating access via wireless, WiFi, and wired connections.

In contrast to circuit-switched networks, which establish and maintain direct connections between devices, pallet-switched communications use addresses to "route" packets through the Internet to their destinations. Thus, in packet-switched communication networks, there is no single dedicated circuit that maintains connections between communication devices, nor does data traveling over the Internet follow a single consistent path. Each packet must travel through a maze of interconnected computers to reach its destination.

When routing IP packets from a notebook to a desktop using packet-switched network communication, the first data packet sent from the notebook to the WiFi router over the wireless connection is directed to an array of DNS servers. DNS is an acronym for Domain Name Server. The purpose of the array of DNS servers is to translate the text name or phone number of the destination device, in this case the desktop, into an IP address. Once translated, the IP address is returned from an array of DNS servers back to the source address, the notebook. This address, which unambiguously identifies the communication terminal, is used for routing data packets through the network.

The notebook then assembles the IP data packets and starts sending the assembled IP data packets sequentially to the destination, first through the WiFi radio's wireless connection to the local WiFi router, and then acting as an intermediate router to the destination. Traversing a network of routers and servers. Routers and computer server networks function as nodes or points of presence (POPs) in the Internet. Together they form a router network that acts as a gateway with limited connectivity to the Internet. Some routers or servers operating as POPs connect to the Internet through only a few neighboring devices, but the servers are interconnected to many devices and are sometimes called "superPOPs." For the sake of clarity, the term POP in network terminology should not be confused with the application name POP used in email applications, or plain old Post Office.

Each router, or server acting as a router, contains a routing table in a memory file that identifies IP addresses to which it can be addressed, and possibly addresses to which higher routers can be addressed. These routing tables are automatically downloaded and installed in all routers when they are first connected to the Internet. It is not normally downloaded when routing packets through the network. When an IP packet enters a router, POP, or superPOP, the router reads the IP address sufficiently to determine, typically the most significant digits of the address, where to direct the packet to its destination. Understand. For example, a packet destined for Tokyo from New York may first pass through Chicago and then through servers in San Francisco, Los Angeles, or Seattle before arriving in Tokyo. Since the number of data packets passing between routers and the data rate between routers depend on infrastructure equipment and network traffic and load, it is impossible to decide in advance which route is the fastest.

Unlike circuit-switched telephony, which uses packet-switched data to establish and maintain direct connections between clients, there is no universal Internet bird's-eye view of which path is the best and most suitable for routing packets. , or the fastest path, and there is not even a guarantee that two consecutive packets will take the same path. Thus, a packet "discovers" its route through the Internet based on the priorities of the companies operating the routers and servers that the packet traverses. Essentially, each router contains specific routing tables and routing algorithms that define preferred routes based on network conditions. For example, router selection may involve sending packets to other routers owned by the same company, balancing traffic between connections to neighboring routers, looking for the shortest delay to the next router, trading strategies. Priority may be given to directing the VIP client to a common business partner, or to creating a fast path for the VIP client by hopping over as many intermediate routers as possible. Once a packet enters a router, there is no way of knowing whether the routing choices made by a particular POP were made in the best interests of the sender or network server operator.

So, in a sense, the path a packet takes is a matter of timing and luck. In the New York to Tokyo routing example above, the routing and resulting QoS change substantially even for small perturbations in the route, i. be able to. Consider the case where packets from New York pass through "Router A" in Chicago and are forwarded to Mexico City instead of California due to temporary heavy traffic in California. The Mexico City router then forwards the IP packet to Singapore and finally to Tokyo. The very next packet sent will be routed through "Router B" in Chicago, which has low traffic at the time, so it will send the packet to San Francisco and only make two trips thereafter. This is for direct transmission to Tokyo. In such a case, the second packet may arrive in Tokyo before the first route takes the longer detour. This example highlights the problem of using the Internet for live video streaming, or real-time communications such as VoIP. That is, the Internet was not designed to guarantee transmission times or control network transmission delays. Latency can vary from 50 milliseconds to 1 second or more, depending on whether the packet traverses only 2 servers or 15 servers.

Poor internet routing control is a problem for real-time applications, especially poor QoS for OTT operators. Thus, OTT operators are attempting to offer Internet-based telephony by piggybacking on the infrastructure of the Internet. Since OTT operators do not control routing, they cannot control delay or network latency. Another problem with packet-switched communications is that it is easy to hijack data without detection. If a predator intercepts a packet and identifies its source or destination IP address, it can use a variety of methods to intercept data from routers in between, allowing the traffic to flow through its own illegal network. It can intercept or redirect, spy on conversations, and even destroy encrypted files.

The source and destination IP addresses and other important information used to route packets (and also used by looters to hijack packets) can be either IP packets, IP datagrams or TCP /IP packets are specified as digital data. IP packets describe the physical connections between devices, the way data is organized to tie devices together, the network routing of packets, the means to ensure that useful data (payload) is correctly delivered, and the payload. Containing digital information defining the type of data contained, the payload data itself is used by various application programs.

IP packets are sent and received in order as a series of serial digital bits, organized in a specific way called the Internet Protocol, established by various standards committees, including the Internet Engineering Task Force, or IETF. This standard ensures that any IP packet conforming to a predefined protocol will be communicated and understood by any connected device conforming to the same IP standard. Ensuring the communication and interoperability of Internet-connected devices and applications is the hallmark of the Internet and represents the guiding principle of the Open Source Initiative, OSI, which allows any company, government, or individual to control the Internet. or limit its accessibility or functionality.

The OSI model is an abstraction containing seven functional layers that precisely define the format of an IP packet and what each segment of the packet is used for. Each portion of an IP packet, or "segment," corresponds to data that applies to a particular OSI layer function. The seven OSI roles are:

Layer 1 : Physical Layer, or PHY Layer, Layer 1 contains hardware-specific information that defines the physical nature of the communication as electrical, RF, and optical signals, and how these signals are connected to the communication system. and how to convert it to bits for use. WiFi radio, Ethernet, serial port, fiber optic, 3G or 4G cellular radio, DSL over twisted-pair copper, USB, Bluetooth, cable or satellite TV, or for audio, video, or multimedia content Converting certain communication media, such as digital broadcasting, into bitstreams is the task of the PHY layer. In an IP packet, the preamble represents the Layer 1 data and is used to synchronize the data packet, or the entire frame, to the hardware sending and receiving Layer 1 data.

Layer 2 : Layer 2, the data link layer, contains bits arranged as frames and defines the rules and means for converting the bitstream delivered from PHY Layer 1 into interpretable data. For example, WiFi radio-based bitstreams can conform to any number of IEEE defined standards, including 802.11a, 802.11b, 802.11g, 802.11n, and 802.11ac. 3G radio communications may be modulated using the high speed packet access methods HSDPA or HSUPA. Modulated light in optical fibers, or electrical signals on coaxial cables, can be decoded into data, such as according to the DOCSIS 3 standard. In an IP packet, Layer 2 data encapsulates its payload into datagrams with a leading "data link header" and a trailing "data link trailer" that define when delivery of that payload begins and ends. and ensure that nothing is lost in the transmission process. A key element of Layer 2 data is the MAC, or Media Access Address, used to direct data traffic to and from a specific Ethernet address, RF link, or hardware-specific transceiver link. .

Layer 3 : Layer 3, the network or Internet layer, contains packets called "datagrams" that contain IP information used to route IP packets, which relate to the nature of the payload contained within the packet. Like information, it contains IPv4 or IPv6 data and corresponding source and destination IP addresses. That is, the type of transport protocol used includes Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or some other. Layer 3 also includes functions to prevent loops. That is, IP packets are never forwarded, but neither are they lost. A particular type of Layer 3 packet, ICMP, is used to diagnose network conditions and includes the well-known "ping" function. In an IP packet, Layer 3 includes an "IP" header, encapsulating a payload that includes transport segment headers, and higher layer segments.

Layer 4 : Layer 4, the transport layer, contains segments of data that define the nature of the connection between the communicating devices and is the minimal descriptive element of the payload for connectionless communication by UDP, i.e. the size of the payload, The amount of lost bits and which application service (port) uses the delivered data is defined. UDP is considered connectionless because it does not check for payload delivery, but instead checks for errors or lost data at the application. UDP is typically used for time-sensitive communications such as broadcast, multicast, streaming, etc., where retransmission of packets is not an option. In contrast, TCP guarantees virtual connectivity by acknowledging packets, ensuring that payloads are delivered before the next packet is sent, and discarded packets are retransmitted. TCP also uses checksums to verify the data integrity of delivered packets, and includes provisions for reconstructing out-of-order packets into their original order. Both TCP and UDP define source and destination ports, descriptive elements of higher layer services or applications, such as web servers or email servers related to information contained within the Layer 4 payload. In an IP packet, layer 4 contains a TCP/UDP header and encapsulates the data/payload containing the content used by upper OSI layers 5, 6 and 7.

Layers 5 , 6, 7: The upper layers or application layers, Layers 5, 6, 7, describe the content delivered by the Internet as data/payload. Layer 7, the "application" layer, represents the highest level in the OSI model and relies on the six underlying OSI layers to support both open source and proprietary application software. Commonly used Level 7 applications include email using SMTP, POP, or IMAP, HTTP (Chrome, Safari, Explorer, Firefox), file transfer using FTP, and terminal emulation using Telnet. included. Unique applications include Microsoft Office products (Word, Excel, PowerPoint), Adobe Illustrator and Photoshop, Oracle and SAP database applications, Quicken, Microsoft Money and QuickBooks financial software, plus audio and video players (iTunes, QuickTime, Real Media Player, Window Media Player, Flash, etc.), and document readers such as Adobe Acrobat Reader, Apple Preview. Level 7 applications were generally defined syntactically by the Level 6 "Presentation" layer, which includes text, graphics & pictures, sound & video, document presentation such as XML or PDF, and security features such as encryption. It also uses embedded objects. The level 5 "session" layer establishes connections between applications, such as importing one object into another program file, and controls the initiation and termination of sessions.

As previously mentioned, the OSI seven-layer model defines the functionality of each layer, and the corresponding IP packets encapsulate the data associated with each layer. In one layer, in a manner similar to a babushka, or Russian nesting doll, in which a wooden doll contains another doll, which in turn contains yet another doll. contains other layers. The outer packet, ie Layer 1, the PHY layer, defines the entire IP frame containing information about all higher levels. Within this PHY data, layer 2 data frames describe the data link layer and include layer 3 data frames. Similarly, this data frame describes the Internet layer as payload and the layer 4 data frame describes the transport layer. The transport layer carries upper layer data, including the contents of layers 5, 6 and 7, as payload.

While the lower physical and data link layers are hardware specific, the intermediate OSI layer encapsulated within IP packets that describe network and transport information is specific to the hardware used to communicate and deliver IP packets. is completely irrelevant. Moreover, the upper layers encapsulated as transport layer payloads are application specific only, applying and operating completely independently of the manner in which packets are routed or delivered over the Internet. This division allows each layer to be managed essentially independently, allowing a myriad of technologies and user Combinations are supported. Incomplete or improper IP packets are simply discarded. In this manner, packet-switched networks are capable of routing, transferring, and delivering a wide variety of application-related information over different communication media in a consistent manner between any Internet-connected device or object. .

In conclusion, circuit-switched networks require a single, direct connection between two or more communicating parties (similar to the conventional telephone system of a century ago). Packet-switched network communications break down documents, voice, video, and text into multiple packets, which the post office makes best efforts to deliver in an accurate and timely manner. ), then reconstruct the initial content, making sure nothing was lost along the way. The table below summarizes the comparison between public switched telephone network (PSTN) and packet-switched VoIP.

While the PSTN operates using real-time electrical circuit connections, the packet-switched network content is the post office, which uses various trucks and mail carriers to ultimately deliver letters even if they arrive late. Unlike , it uses a "best effort" method to deliver content, finding paths to deliver packets and payloads. Packet-switched networks and communications are described in greater detail in the background section of the patent entitled "Secure Dynamic Communications Networks and Protocols."

Several factors are considered when considering network performance, namely:
data rate, i.e. bandwidth,
・Quality of service,
・Network and data security,
- User privacy is considered.

Of the above considerations, data rates are easily quantified in millions of bytes per second, or Mbps. Quality of Service or QoS, on the other hand, includes latency, audio quality, network stability, intermittent operation or frequent service interruptions, sync or connection failures, low signal strength, application outages, and emergency capabilities. Several factors are involved, including network redundancy and others. Cybersecurity and cyberprivacy deals with cybercrime, cyber surveillance, IP packet sniffing, DoS attacks, profiling, fraudsters, packet hijacking, cyber infections, surveillance, cybercriminal control and intrusion, etc., and attacks on networks. and guard against unauthorized access to data traffic and content.

QoS (Quality of Service)

QoS is performance on a network and is expressed using network capacity, bandwidth, latency, data rate, scalability, sound quality, data integrity, data bit error rate, and other performance-based parameters. Accuracy of data is an important factor in program, file, and security-related verification. Which factors are important depends on the nature of the payload being carried over the packet-switched network. In contrast, for voice and video, including real-time applications, the factors affecting packet delivery time are significant. Quality factors and how they affect different applications such as video, voice, data, and text are application dependent. Good network conditions, typified by consistent high data rate IP packet waveforms, are those with minimal time delays, clearly strong signal strength, no signal distortion, stable operation, and no packet transmission loss.

Intermittent networks with lower data rate packet waveforms with short interruptions have the greatest impact on video performance, causing uncomfortably slow video downloads and making video streaming unacceptable. A congested network that causes lower effective data throughput rates with regular short interruptions, exemplified by the IP packet waveform, results in video images with choppy motion, fuzzy images, and inappropriate coloration and brightness. as well as causing echoes and even total removal from dialogue and soundtracks. However, in a congested network, data can be supplied using TCP by repeating rebroadcast requests. Unstable networks exhibit low data throughput rates with numerous data outages of unpredictable duration. An unstable network also includes corrupted IP packages represented by the dark-shaded packets in waveform 610D, which require retransmission for TCP-based transport, and simply corrupted data for UDP transport. or discarded as inappropriate data. Email is also intermittent at some level of the network and IMAP synchronization fails. Due to the lightweight data format, most SMS and text messages are forwarded with delivery delays even under severe network congestion, but attachments are not downloaded. An unstable network can cause all applications to fail and even freeze the normal operation of a computer or cell phone waiting for a file that is expected to be delivered. In such cases, the video freezes, the audio is choppy and inaudible, the VoIP connection drops repeatedly 10 or more times within minutes, and sometimes the connection fails completely. Similarly, email stalls or freezes in the form of a computer icon spinning indefinitely. The progress bar completely stops. Text messages also bounce and become "undeliverable".

Many factors can lead to network instability, such as power outages on critical servers and super POPs, overloaded call volumes, transmission of huge data files and UHD movies, and severe denial-of-service attacks against some servers and networks. A potentially important factor in tracking a network's QoS is its packet drop rate and packet latency. A discarded packet occurs when an IP packet is not delivered and has "timed out" permanently, or when a router or server detects a checksum error in the IP packet's header. For packets using UDP, packets are lost and layer 7 applications must be smart enough to know that something is lost. When TCP is used for Layer 4 transport, packets are required for retransmission, adding further load to a potentially already overloaded network.

QoS, another factor that determines propagation delay, as the delay of IP packets between nodes, or in one direction from source to destination, or as round trip delay from source to destination and destination to source, It can be quantitatively measured in several ways. Effect of propagation delay on packet delivery using UDP and TCP transport protocols. As intermodal network propagation delay increases, the time required to conduct a round-trip communication, such as a VoIP conversation, increases. For UDP transport, round trip delay increases linearly with propagation delay. Longer propagation delays correlate with higher bit error rates, so the number of lost UDP packets increases, but because UDP requires retransmission of dropped packets, the round trip time is linear with increasing delay. remain. TCP transport exhibits substantially longer round-trip times for each packet sent than UDP because of the handshake required to confirm packet delivery. TCP propagation delay increases linearly with intermodal propagation delay if the bit error rate remains low and most packets do not require retransmissions, but at a higher rate, i.e., TCP's line slope do. However, as communication networks become less stable as propagation delay increases, the round-trip time resulting from TCP transfers increases exponentially because of the protocol's need for retransmission of dropped packets. VoIP is therefore contraindicated for time-sensitive applications such as VoIP and video streaming.

Since all packet communication is statistical and no two packets have the same propagation time, the best way to estimate the unidirectional latency of a network is the round trip time of many IP packets of similar size. A method by measuring and dividing to estimate the one-way latency. Latency below 100ms is considered very good, up to 200ms is considered very good, and up to 300ms is considered acceptable. For propagation delays of 500 ms, easily encountered by OTT applications running on the Internet, the delay is annoying to users and interferes with normal conversation. In voice communications, in particular, such long propagation delays appear "bad" and can lead to reverberations, creating a "plucked string" or metallic sounding voice, where one party While waiting for the last comment to be answered, it may interrupt normal conversation and output broken, incomprehensible audio.

For clarity, the one-way latency of the communication is different from a ping test performed by a layer 3 ICMP utility (such as the free network speed test at http://www.speedtest.net). , these differences are partly because ICMP packets are generally lighter weight than real IP packets; This is because there is no guarantee that the ping test route above matches the actual packet route. In short, if your ping experiences long delays, there is something wrong with your network or with some link between your device and your network (e.g. WiFi router or last mile), even if you get good ping results. , by itself, cannot guarantee small propagation delays for actual packets.

To improve network security, encryption and verification methods are often employed to prevent hacking, sniffing, or espionage. However, heavy encryption and multiple-key encryption protocols constantly reconfirm the identity of conversation partners, creating additional delays, increasing effective network latency, and reducing QoS at the cost of increased security.

Cybersecurity and cyberprivacy

Two other major considerations in communications are cybersecurity and cyberprivacy. Although related, the two issues are somewhat different. “Cybersecurity,” which includes network security, computer security, and secure communications, refers to unauthorized access, misuse, modification, or protection of data contained in a computer or communications network, network-accessible resources, or network-connected devices. or methods for monitoring, intercepting, and preventing denials. Such data may include personal information, biometric data, financial records, health records, private communications and records, and private photographic images and video recordings. Network-connected devices include desktops, file servers, email servers, web servers, databases, personal data storage, cloud storage, internet-connected appliances, internet-connected cars, and public shared devices for personal use (POS). terminals, gas pumps, ATMs, etc.).

Clearly, cybercriminals and computer hackers who attempt to gain unauthorized access to confidential information are committing crimes. If the illegally obtained data contains private personal information, the attack also compromises the victim's personal information. Conversely, however, privacy breaches may occur without the need for cybercrime and may actually be 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 choose to sell the database to other clients interested in using the data for another purpose. Even when Microsoft purchased Hotmail®, it was well known that it sold mailing lists to advertisers interested in spamming potential customers. Whether such behavior should be considered a violation of cyberprivacy remains a matter of opinion.

"Cyberprivacy," which includes Internet privacy, computer privacy, and private communications, refers to an individual's ability to control an individual's nonpublic and personal information and its uses, including the collection, storage, display, or sharing of information with others. Including personal rights or obligations. Nonpublic personal information includes personal information such as height, weight, age, fingerprints, blood type, driver's license number, passport number, social security number, or other personal information that helps identify an individual without knowing their name. ID information is included. In the future, even an individual's DNA map may become a matter of legal record. Non-public, so-called non-personal information, apart from personal ID information, includes the brands of clothing we buy, the websites we visit frequently, whether we smoke or drink alcohol, whether we own a gun or not. what type of car you drive, previous medical history, whether you have certain illnesses or a history of illness in your family, and even what kind of people you are attracted to.

This personal information is combined with public records related to personal income, taxes, real estate lawsuits, criminal records, traffic violations, and any information posted on social media sites to create a powerful dataset for our stakeholders. to form The intentional collection of large data sets that capture demographic, personal, financial, biomedical and behavioral information and capture data on patterns, trends and statistical correlations today. big data”. The medical industry, including insurance companies, healthcare, pharmaceutical companies, and malpractice attorneys, all have a deep interest in personal information stored as big data. Automotive and consumer goods manufacturers alike desire access to such databases to direct their marketing strategies and advertising budgets. In recent elections, even politicians are turning to big data to better understand what voters think and what political debates they should avoid.

The question of cyber privacy is not whether today's big data captures personal information, but whether the dataset holds your name or identifies you without knowing your name. It is not whether or not we hold sufficient personal information to For example, initially, when a private healthcare account was opened, the U.S. government used healthcare. It said personal information collected by the gov website would be destroyed. And recently, it was revealed that a third-party entity that facilitates data collection for the U.S. government had signed a contract with the government under which it had the right to retain and use the data it collected. , it turns out that the private personal information entrusted to the US government is not actually private.

Finally, it must be mentioned that surveillance is carried out by governments and criminal gangs using similar technical methods. Criminals clearly have no legal right to collect such data, but cases of unauthorized government surveillance vary significantly from country to country. The U.S. NSA, for example, has repeatedly pressured Apple, Google, Microsoft and others to provide access to their clouds and databases. Even government officials have their conversations and communiqués eavesdropped and intercepted. When asked whether Skype(R), a division of Microsoft, monitors callers' content, Skype(R)'s CIO abruptly replied "no comment."

Cyber Crime and Cyber Surveillance Methods

Focusing on cybersecurity implications, there are numerous means of gaining unauthorized access to devices, networks and computer data. There are various malware and hacker techniques used to carry out cyber crimes and gain unauthorized entry into secured networks.

For example, an individual using an Internet-connected tablet can call a business office phone, send a message to a television, or call a friend in a country using a circuit-switched POTS network on the phone. or download files from web storage or send e-mails through e-mail servers. Although all applications represent normal applications with Internet and global interconnectivity, there are many opportunities for surveillance, cybercrime, fraud, and identity theft throughout the network.

For example, in the case of tablets that connect to networks via cellular radio antennas and LTE base stations, or via short-range radio antennas and public WiFi base stations, an intruder can monitor the radio link. Similarly, LTE calls can be monitored or "tapped" by an eavesdropping radio receiver or sniffer. The same sniffer can be tuned to monitor WiFi communications and the receiving end on the cable between the cable CMTS and the cable modem.

In some instances, the LTE call can also be intercepted by a cyber pirate fake tower and establish an alternate communication path between the tablet and the cellular tower. Communications involving transmissions over packet-switched networks to routers, servers, and cloud storage are subject to attack by others, even in man-in-the-middle attacks. The wiretap can intercept calls on POTS lines from PSTN gateways to phones and calls on corporate PBX lines from PBX servers to office phones.

By performing a series of security breaches, spyware can be installed on tablets, routers, PSTN bridges, cloud storage, cable CMTS, or desktops. Trojan software can be installed on tablets or desktops to phish passwords. Worms can also be used to attack the desktop, especially if the computer is running Microsoft's operating system with the ActiveX feature enabled. Finally, viruses can attack any number of network-connected devices, including servers, desktops, and tablets, to launch denial-of-service attacks.

Various forms of malware can operate against different parts of communication networks and infrastructure, and these cyber-attacks can include viruses, man-in-the-middle attacks, government surveillance, and denial-of-service attacks. The last mile of a communications network, more broadly, presents an opportunity for malware and cyberattacks and is divided into three sections: local carrier/network, lastlink, and device. Local telephony/networks include high speed fiber, routers, cable CMTS, cable/fiber, cable modems, WiFi antennas, and LTE radio towers. Spyware, viruses, and man-in-the-middle attacks are all possible in this part of the network wireless sniffer.

For local connections to lastlink devices, network connections include wired links, WiFi links, and LTE/wireless links that are subject to spyware, wireless sniffers, eavesdropping, and fake towers. Device bodies, which can also include, for example, tablets, notebooks, desktops, smart phones, smart TVs, point-of-sale terminals, etc., are subject to a variety of attacks including spyware, Trojan horses, viruses, and worms. Such monitoring methods and devices are commercially available and readily available in online markets with terminals for monitoring Ethernet local area networks, WiFi data and cellular communications. Until recently, sniffing of fiber optic cloud connections was not identified as a threat, but non-invasive data sniffers for optical communications, i.e., without the need to cut the fiber, even temporarily, to ensure normal operation, even temporarily. It turned out that a sniffer currently exists that can be used intact.

Besides the use of hacking and surveillance methods, a wide variety of commercial spyware are readily available for monitoring cell phone conversations and Internet communications. Commercially available spyware programs advertise the ability to spy on employee, child, and spouse information for profit. The feature set is surprisingly comprehensive, including phone calls, photos, videos, SMS/MMS texts, 3rd party instant messaging, email, GPS location tracking, internet usage, address book, calendar events, bugs and controls. It contains a surprisingly convincing number of cyberprivacy breach methods, such as apps and even remote control capabilities. In fact, cyberattacks are becoming more frequent and tracked daily.

Launching a cyberattack generally requires several steps or combinations of techniques, including: IP packet sniffing,
・Port scan,
・Profiling,
·scam,
・packet hijacking,
・Cyber infection,
・Monitoring,
・Cyber pirate site management is necessary.

IP packet sniffing

Cybercriminals can use wireless surveillance devices to gain important information about users, their transactions, and their accounts. The contents of IP packets can be obtained or "sniffed" anywhere along the path between two users. For example, when a user sends a file (e.g. a picture or text) in IP packets from his notebook to his mobile phone, the cyberpirate intercepts the sender's last link and intercepts the sender's local network. , by monitoring the cloud and either intercepting the receiver's local telco, or intercepting the receiver's last link, IP packets can be found at any number of locations. The 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 of the receiving side, i.e. the destination of the packet, and the transport protocol such as UDP, TCP etc. is used. The IP packet also contains the Layer 4 port number of the sending and receiving device, which potentially defines the type of service requested, and the data file itself, which, if the file is unencrypted, is encrypted. It is also possible for cyber pirates to directly read the data contained in .

If the payload is unencrypted, text information such as account numbers, login sequences and passwords can be read and, if valuable, can be stolen and misused for criminal purposes. If the payload contains video or emoji information, some additional work is required to determine which layer 6 application format the content adopts, but once identified, the content can be , viewed, published, or possibly used to intimidate one or both of the communicating parties. Such cyberattacks are called "man-in-the-middle attackers" because cyberpirates do not personally know who they are communicating with.

As mentioned earlier, IP packet routing in the cloud is unpredictable, making it more difficult to monitor the cloud, i.e. the reason it is difficult to monitor is that cyber pirates were the first to encounter important information in IP packets. Because sometimes it has to supplement, and subsequent packets may not follow the same route and sniffed packet. Eavesdropping on last-mile data has a high probability of observing a series of related packets that make up the same conversation, because local routers typically have at least one packet reaching a POP outside the customer's own carrier. This is because it follows a predetermined routing table until it does. For example, Comcast's clients may continue up the routing chain using a network entirely owned by Comcast until the packet travels geographically beyond Comcast's control and customer service territory. Likely to pass IP packets.

If consecutive packets between the same two IP addresses occur long enough, the entire conversation can be reproduced in detail. For example, if an SMS text message traverses the same network in the last mile, cyberpirates can determine by IP address and port# that multiple IP packets carrying text can be sent between the same two devices, namely a mobile phone and a notebook. It can be specified to represent a conversation. Therefore, even if account numbers and passwords are texted in different messages or sent incompletely in many packets, the consistency of packet identifiers allows cyberpirates to reconstruct conversations and steal account information. be able to. Stealing account information can allow you to transfer money to an offshore bank, or even temporarily deprive an account using identity theft by changing the account's password and security questions.

Even if the payload is encrypted, the rest of the IP packet including IP address and port number is not encrypted. Cyber pirates with access to sufficient computing power repeatedly sniff a large number of IP packets and then systematically try all combinations until they break the cryptographic password. Once the key is broken, the packet and all subsequent packets can be decrypted and used by cyber pirates. The probability of cracking a login password by "password guessing" is greatly improved when packet sniffing is combined with user and account "profiling" as described below. Note that in a "man-in-the-middle attacker", communication devices are usually not involved as cyber pirates do not have direct access to them.

port scan

Another way to break into a device is to probe a number of Layer 4 ports using its IP address and see if all requests receive responses. Once the cyberpirate identifies a cell phone with an IP address as a target device from packet sniffing or other means, the cyberpirate initiates a series of queries to ports on the cell phone and unsecured ports. look for open ports, service and maintenance ports, or application backdoors. A hacker's interrogator can systematically cycle through all port numbers, but attacks usually use port #7 for ping, port #21 for FTP, port #23 for telnet terminal emulation, It focuses on notorious vulnerable ports such as port #25 for simple mail. Cyber pirates learn more about the target device's operating system each time they send a packet and a response is sent.

In the port scanning process, cyber pirates do not want their real identities exposed, so they use fake addresses to receive messages that cannot be traced to individuals. Also, cybercriminals may use stolen computers and accounts, so if someone else appears to be trying to hack the target device and is tracked, the investigator will be an innocent person, not them. put it back in.

profiling

User and account profiling is the process by which cyber pirates use publicly available information to examine targets, accounts, and personal histories to crack passwords, identify accounts, and determine assets. Once a hacker has obtained the target's IP address using means such as sniffing, a traceroute utility can be used to locate the DNS server for the device's account. The name of the account holder can then be found by using the "Who is" function on the Internet. Profiling involves cybercriminals searching the Internet and gathering all available information about account holders. Sources of information include public records such as real estate transactions, vehicle registrations, marriages and divorces, tax liens, parking tickets, traffic violations, and criminal records. College and professional websites often contain home addresses, e-mail addresses, phone numbers, and dates of birth of individuals. By examining social media sites such as Facebook, LinkedIn, and Twitter, cybercriminals can glean important details, such as family and friends, pet names, previous home address, etc. Includes photo and video files containing addresses, classmates, personal milestones, embarrassing events, family secrets, and personal enemies.

The cyber pirate's next step is to use this profile to "guess" the user's password based on the profile and hack other accounts of the same individual as the target device. Once a cybercriminal has cracked passwords on one device, it is very likely that they will break into other accounts because people tend to reuse passwords to make them easier to remember. expensive. At that point, it may be possible to steal a person's identity, move money, subject him to police investigation, steal all his assets, and essentially destroy his life. For example, as discussed at the beginning of this document, cybercriminals who collect long password lists from stolen accounts can use the same passwords and logins to redeem millions of premium tickets to concerts and sporting events. Buy dollars illegally.

con man

Cyber-pirates are acting as "impostors" when they impersonate someone and use fraudulent cybersecurity credentials to access communications and files. Fraudster-type cyberattacks allow cybercriminals to possess sufficient information or access to a personal account to take over a victim's account and fraudulently send messages to individuals on behalf of the victim. and they can mislead the owner of the account they hacked into doing it. Recently, for example, a personal friend of one of the inventors had her "LINE" personal messenger account hacked. The cybercriminal who took over the account sent a false message to a friend saying, "I had a car accident and need funds for an emergency loan." Not knowing that her account had been hacked, her friend found the request genuine and rushed her to fund it. To avoid suspicion, the requests sent to each friend were less than US$1,000. Luckily, just before sending the money, one of her friends called her to double check the money transfer information and the scam was revealed. If this phone call doesn't go through, no one will know that this was a request from a scammer and the account owner on the line didn't even know the money was sent or requested to be sent in their name. I don't think so.

Another form of misrepresentation is a server where the device has been given security privileges and is capable of exchanging information with a server or other networked device, and where the cyberpirate device has authenticated itself by some means. , and the victim's device entrusts files and information to a cyber pirate server without knowing it is a rogue server. This method was allegedly used to get celebrities to back up their private image files using iCloud as they normally would, except the backup cloud belonged to a crook.

Another form of fraud is when a person with physical access to a person's phone or an open browser can send emails, answer phone calls, and from there access other people's accounts or devices. Occurs when you engage in fraudulent activity, such as sending a text message from Recipients are connected to a known device or account and therefore assume that the person operating the device or account is the owner. Scams can be mischievous, such as posting embarrassing comments to a friend on Facebook, or asking someone's spouse to answer a personal phone call or intercept a private text message of a nature that should be private. may be of a more personally identifiable nature. The consequences of this unauthorized access can lead to jealousy, divorce, and retaliatory lawsuits. Temporarily leaving the device unsupervised while going to the bathroom in an office, cafe, etc. can allow fraudsters to quickly access personal and corporate information, as explained in the "Infection" section below. , send malicious emails, transfer files, or download malware onto your device.

Fraud-based cyberattacks are also important when devices are stolen. In such cases, even if the device is logged out, the thief has plenty of time to crack the login code. The "find my computer" function, ie, the ability to locate the stolen device on the network and erase the computer's files, when the cyber pirate logs on to the device for the first time, is no longer effective. Tech-savvy criminals now know that they only need to activate devices when there is no cell phone or WiFi connection. This risk is particularly high for mobile phones where passline security is a simple four-digit personal identification number (PIN) or personal identification number. With only 9999 possible combinations, it's only a matter of time before the PIN is broken.

A key issue for securing devices is preventing access by fraudsters. Fraud prevention requires a robust means of authenticating a user's identity at regular intervals and ensuring that they are authorized to access the required information and privileges. Device security is often the weakest link in the chain. If device security is compromised, the need for robust network security becomes questionable.

packet hijack

Packet hijacking involves a cyberattack that diverts the normal flow of packets through a network through a malicious device.

For example, if the integrity of a router is compromised by a cyber-attack from a cyber-pirate, IP packets passing through the router are rewritten with revised IP packets to route the IP package to the cyber-pirate's device's destination address and port number. change. The cyber pirate's device then obtains the necessary information from the IP packet's payload and possibly modifies the contents of the IP packet's payload. Malicious payloads are used to commit any number of types of malicious crimes, gather information, or download malware onto mobile phones, as explained later in the topic "Infection". there is a possibility.

The hijacked packet is modified to have the source IP address and port# of the original IP packet, but the packet actually traverses the new child route. Alternatively, the hijacked IP packets are returned to the compromised router and then sent to the cloud. Cyber pirates need to hide their identity during packet hijacking to maximize the effectiveness of packet hijacking crimes, making it difficult to determine the true path of communication even with the layer 3 ICMP function "traceroute". hides the true routing of IP packets so that However, if the hijacking adds significant delays to packet routing, the unusual delays may prompt investigation by network operators.

cyber infection

One of the most insidious categories of cyberattacks involves installing malware on a target device or network that gathers information, defrauds, redirects traffic, infects, aggravates, or shuts down other devices. It is to cause a "cyber infection", a condition that prevents denial of service. Cyber infections spread through email, files, websites, system extensions, application programs, or networks. One common class of malware, "spyware," collects all kinds of transaction information and passes it on to cyber pirates. In the case of "phishing," a web page or application shell that looks like a familiar login page prompts for account login or personal information and forwards the information to cyber pirates. Still other malware infections can control hardware, such as controlling routers to perform the aforementioned packet hijacking. In such cases, cyber pirates seek useful information and control for their own purposes.

Another class of cyber infections such as viruses, worms, and Trojan horses are designed to overwrite important files or repeatedly perform useless functions, preventing your device from performing its normal tasks. ing. Basically, it denies service, degrades performance, or even kills the device completely. These malicious infections are destructive in nature and are intended to do harm, to disrupt normal operations in a competitor's business, or simply to entertain hackers who want to see if it is possible. used as motivation.

monitoring

There are threats and surveillance beyond cybercrime. In such cases, a private investigator or acquaintance is hired or coerced to install a device or program on the target's personal device in order to monitor voice conversations, data exchanges, and location. Detectives are more likely to be caught because they have to temporarily access the target's device without the subject's knowledge. For example, SIM cards are on the market that can copy a phone's network access privileges, but at the same time transmit information to cybercriminals who monitor the target's call and data traffic.

Other forms of surveillance include the use of covert video cameras that monitor people's behavior and phone calls, similar to those found in casinos. With video surveillance, the device password or PIN can be learned simply by observing the user's keystrokes during the login process. With enough cameras, the login process will eventually be recorded. To gain access to camera networks without arousing suspicion, cyber pirates hack existing camera surveillance systems in buildings, stores, or streets to arouse suspicion through access to other people's network monitors. Victim's behavior can be monitored. Combining video surveillance with packet sniffing provides an even more comprehensive data set to launch subsequent cyberattacks.

Control by cyber pirates (intrusion)

Another means by which cyber pirates can obtain information is by hacking and gaining access to system administration privileges on devices, servers, or networks. Thus, rather than gaining unauthorized access to a user's account by hacking a system administrator's login, critical access and privileges are available to cyber pirates without the knowledge of the user using the system. become. System administrators act as the system's police force, so no one can keep track of their criminal activity. In essence, corrupt management systems and networks leave no one to police.

Conclusion

Universality and interoperability through the ubiquitous adoption of the Internet, packet-switched networks, and the seven-layer open-source initiative network model have led, over the past two decades, to the unparalleled expansion of global communications, from smartphones to tablets, It has enabled a wide range of uses in computers, smart TVs, cars, and even home appliances and light bulbs. The worldwide adoption of the Internet Protocol, or IP, that underlies Ethernet, cellular, WiFi, and cable TV connections has not only resulted in a unified communication, but has also made it available to as many devices and systems as possible. It greatly simplifies the challenge for hackers and cybercriminals trying to break in. Given the large number of software and hardware methods available for attacking today's communication networks, using a single security method as the sole defense is not sufficient. Instead, a systematic approach to securing all devices, lastlinks, local phones/networks, and cloud networks is needed to ensure protection from advanced cyber-attacks. The methods utilized should provide intrinsic cybersecurity and cyberprivacy without compromising QoS, network latency, video or sound quality. Encryption should be a key factor in developing this next generation of secure communications and data storage, but network security should not rely solely on cryptographic methodologies.

According to the present invention, data (broadly, text, audio, video, graphics, and all other types of digital information or files) can be transferred through a secure dynamic communication network and protocol (SDNP) network or "cloud". transmitted. An SDNP cloud consists of multiple "nodes" ("media nodes") hosted on servers located anywhere in the world or on other types of computers or digital devices (collectively referred to herein as "servers"). ”). It is also possible to place more than one node on a single server. Generally, data is transmitted between media nodes by light transmitted through fiber optic cables, by radio waves in the radio or microwave spectrum, by electrical signals transmitted by copper wire or coaxial cables, or by satellite communications. , the invention broadly includes any means by which digital data can be transmitted from one point to another. An SDNP network according to the present invention includes an SDNP cloud and a "last mile" link between the SDNP cloud and client devices. Such client devices include, for example, cell phones (smartphones), tablets, notebook computers, desktops (desktop computers), mobile electronic devices, Internet-of-Things (IoT) devices or applications, automobiles or other vehicles. be done. Last-mile communications also include cell phone towers, cable or fiber connections to homes, and public WiFi routers. In the last mile, the link between the client's device and the nearest cell phone tower or other retransmitter is called the "last link."

When communicating between media nodes in an SDNP cloud, data is transmitted in the form of "packets", which are strings of digital bits of fixed or variable length, and are scrambled, encrypted, fragmented, or vice versa. It is camouflaged using some unscrambling, decoding, mixing, etc. technique. (Note: "or" is used herein in its conjunctive sense (and/or (and/or)) unless the context dictates otherwise.)

Scrambling changes the order of data within a data packet. For example, data segments A, B, and C arranged in that order in the data packet are rearranged in the order of data segments C, A, and B. The reverse operation of the scrambling operation is called "unscrambling". Unscrambling returns the arrangement order of the data in the packet to the original arrangement order (the order of A, B, and C in the above example). The combination of a data packet unscrambling operation followed by a scrambling operation is called "rescrambling". When rescrambling a scrambled packet, the packet is scrambled in the same or different manner as in the previous scrambling operation.

The second operation, "encryption," converts the data in the packet into ciphertext that is understandable only to the sender and other authorized parties, and to those who perform the reverse operation of encryption, "decryption." is to be encoded in a form called The combination of a ciphertext data packet decryption operation followed by a re-encryption operation is referred to herein as "re-encryption." The encryption operation in this re-encryption typically, but not necessarily, uses a different method than in the previous encryption.

The third operation, "splitting", as its name suggests, involves splitting a packet into two or more smaller packets. The inverse operation of splitting, "blending", is defined as recombining two or more split packets back into the original single packet. The fragmentation of a previously fragmented and mixed packet is done in the same or different way as during the previous fragmentation operation. The order of splitting and mixing operations is reversible and splitting can be reversed by mixing. And vice versa, an output that is a mixture of multiple inputs can be split back into its components (multiple inputs). (Note: Scrambling and unscrambling, encryption and decryption, and splitting and mixing are inverse processes of each other, so any information on algorithms or methods used to implement a process is the inverse process. Therefore, when a particular scrambling, encryption, or segmentation algorithm is mentioned, it should be understood that information about that algorithm enables the inverse process to be performed. )

According to the present invention, data packets traversing the SDNP cloud are scrambled, encrypted, or a combination of scrambled and/or encrypted and fragmented. In addition, "junk" data is added to packets to make them more complicated for the decryptor or to make them a given length. Further, the packet is parsed, ie divided into individual parts (fragments). In computer terminology, parse means dividing a computer language statement, computer instruction, or data file into parts that are useful to a computer. Parsing is also used to obfuscate the purpose of instructions or data packets, or to split data into data packets having specific data lengths.

The format of the data packets follows the internet protocol, but in the cloud within the SDNP, the addresses of the media nodes are not standard internet addresses. That is, the media node's address cannot be identified by an Internet DSN server. Thus, media nodes can technically receive data packets over the Internet, but cannot respond to address recognition or queries. Furthermore, even if a user of the Internet is able to contact a media node, the media node recognizes the user as an imposter who does not have the identification and authentication information required to access the node. Data cannot be accessed and analyzed. Specifically, unless the media node is registered as a valid SDNP node running on an SDNP name server or a designated server in a device with equivalent functionality, the node sends to other SDNP media nodes data packets that have been overwritten will be ignored and discarded. Similarly, only clients registered with the SDNP name server can contact the SDNP media node. Data packets received from sources other than registered SDNP clients, as well as unregistered servers, are ignored and immediately discarded.

In relatively simple embodiments, called "single route", data packets are transmitted through a single route through a series of media nodes in the SDNP cloud, scrambled at the media nodes through which they enter the cloud, It is unscrambled at the media node through which it exits the cloud (the two nodes are called the "gateway node" or "gateway media node"). In a slightly more complex embodiment, the packets are rescrambled at each media node using a different scrambling method than the one used at the previous media node. In another embodiment, packets are encrypted at the gateway node through which they enter the cloud and decrypted at the gateway node through which they exit the cloud. Additionally, packets may also be re-encrypted at each media node that passes through the cloud. Because a given node uses the same algorithm each time it scrambles or encrypts a packet, this embodiment is called "static" scrambling or encryption.

When performing more than one operation on a packet (eg, scrambling and encryption), the inverse operations are preferably performed in the reverse order of the original operations. For example, if a packet is scrambled and then encrypted and sent from a media node, the packet arriving at the next media node will be decrypted and then unscrambled. A packet is regenerated in its original form only when it resides in the media node. Packets may be scrambled, fragmented/mixed, or encrypted when transmitted between media nodes.

In another embodiment, referred to as a "multi-route" data transmission, packets are split at a gateway node such that the resulting multiple packets follow a series of "parallel" paths that share no media nodes other than the gateway node. Pass through and traverse the cloud. Multiple packets are then mixed (typically at the egress gateway node) to recreate the original packet. Therefore, even if a hacker were able to make sense of a single packet, he would only get a portion of the entire message. Packets may also be scrambled and encrypted at the gateway node before or after fragmentation. Also, packets may be re-scrambled or re-encrypted at each media node through which they pass.

In yet another embodiment, packets are transmitted not only through a single route or a series of parallel paths within the SDNP cloud, but through multiple paths that include many intersecting portions. This embodiment is called "mesh transmission" because the image of possible paths resembles a mesh. Similar to the embodiments described above, packets are scrambled, encrypted, and fragmented/mixed as they pass through each media node in the SDNP cloud.

A packet's route through the SDNP network is determined by signaling functions performed by the media node segment itself, or preferably by a separate signaling node running on a dedicated signaling server in "dual-channel" or "tri-channel" embodiments. be done. This signaling function determines the route of each packet as it is transmitted from the sending client device (e.g. cell phone) based on network conditions (e.g. propagation delay) and the priority and urgency of the communication. . It then notifies each media node along the route that it is to receive packets, and indicates the destination of packets received by that node. Each packet is identified by a tag, and a signaling function instructs each media node which tag to attach to each packet transmitted from that node. In one embodiment, the data tag is included in an SDNP header or subheader, which is a data field attached to each subpacket of data and used to identify the subpacket, each subpacket identifying a specific data "slot" within the packet. contains data segments from one or more sources, stored in the . During data transmission between any two media nodes, multiple sub-packets may exist within one larger data packet.

The routing function is performed in conjunction with the split and mix functions. This is because when a packet is split, it is necessary to determine the route of each subpacket and to instruct the node where the subpacket is to be recombined (mixed) to mix the subpacket. In multi-route embodiments, packets are split and mixed one or more times before they traverse the SDNP network and reach the egress gateway node. Determination of the node to divide the packet and the number of subpackets to be generated by dividing the packet, and determination of the transmission route of the subpacket and the node to regenerate the original packet by mixing the subpacket are all Whether or not the signaling function is implemented by a separate signaling server is controlled by the signaling function. The segmentation algorithm specifies, for the data segments of the data packet being segmented, which data segments to include within each subpacket, and the order and position of each data segment within the subpacket. The mixing algorithm regenerates the original packet by reversing the splitting process at the node that mixes the subpackets. Of course, when instructed to re-segment by the signaling function, the node re-segments the packet according to a separate segmentation algorithm from the previous segmentation, corresponding to the time and state when performing the segmentation process. .

Signaling functions allow a media node to send multiple packets to specific destinations on the "next hop" through the network, whether they are fragmented packets (subpackets) or relate to different messages. When a media node is instructed to send, in particular if multiple subpackets share a common destination media node for the next hop, the media node combines the multiple packets and Create a single large packet (similar to putting letters with the same address in a box at the post office and sending the box to that address).

In a "dynamic" embodiment of the invention, each media node in the SDNP cloud does not use the same scrambling, encryption, or fragmentation algorithm or method for a series of packets passing through it. For example, at a given media node, one packet is scrambled, encrypted, or fragmented using a particular scrambling, encryption, or fragmentation algorithm, and the next packet is , scramble, encrypt, or split using a separate scrambling, encryption, or split algorithm from the previous one. This "dynamic" operation leaves the hacker with a very short amount of time (e.g. 100 ms) to decrypt the packet, and even if the packet is successfully decrypted, the information is quickly unavailable. It can significantly increase the difficulty faced by hackers.

In dynamic embodiments, each media node is connected to a so-called "DMZ server". The DMZ server can also be viewed as a separate part from the data transmission part in the node, with a list or table of scrambling, encryption and fragmentation algorithms that the media node may apply to packets output from it. has a database (a "selector") containing The selector is a piece of a lot of information called a "shared secret" because even the medianodes don't know and all DMZ servers have the same selector at a given time.

When a media node receives a scrambled packet, in dynamic embodiments it also receives a "seed" that is used to tell it the algorithm to use to unscramble the packet. The seed is a disguised number that has no meaning by itself, but is based on a frequently changing state (eg, the time when the packet was scrambled at the previous media node). When the previous node scrambled the packet, the DMZ server connected to that node generates the seed based on the current state. Of course, the state is also used to select the algorithm that a DMZ server connected to the node uses to scramble packets. The selected algorithm is communicated to the sending node in the form of instructions on how to scramble the packet. Thus, the sending node receives both instructions on how to scramble the packets and a seed that is transmitted to the next media node. A seed generator running within the DMZ server generates seeds using an algorithm based on the state at the time the process is performed. The seed generator and its algorithm are part of the media node's shared secret, but the generated seed is not secret information. This is because the numeric seed has no meaning unless you access the algorithm.

Thus, the next media node on the packet route receives the scrambled packet and a seed derived from the state associated with the packet (eg, the time the packet was scrambled). The seed may be included in the packet itself, or may be sent via the same route as the packet or another route (eg, a signaling server) before the packet is sent to the receiving node.

Regardless of how the seeds are received, the receiving node sends the received seeds to the DMZ server connected to it. Since the DMZ server has a selector or table of scrambling algorithms that are part of the shared secret, the seed is used to scramble the packet, similar to the DMZ server's selector at the sending node. It identifies the algorithm used and instructs the receiving node how to unscramble the packet. Therefore, the receiving node can regenerate the packet in unscrambled form and recover the original data. Generally, the packet will be rescrambled according to another scrambling algorithm before being sent to the next node. In this case, the receiving node obtains the scrambling algorithm and seed from its DMZ server and repeats the above process.

Thus, packets are scrambled according to separate scrambling algorithms at each node as they are transmitted through the SDNP network. Along with it, a new seed is also generated at each node that allows the next node to unscramble the packet.

In another embodiment of the invention, the actual state (eg, time) is transmitted between nodes (ie, the sending node need not send the seed to the receiving node). A DMZ server connected to both the sending media node and the receiving media node contains a hidden number generator (also part of the shared secret) containing an identification algorithm at any given time. A DMZ server connected to the sending node uses the state to generate a hidden number for determining a scrambling algorithm from a selector or table of possible scrambling algorithms. The sending node sends the state to the receiving node. Unlike seeds, hidden digits are not sent over the network, but through private communications between media nodes and their DMZ servers. When a receiving media node receives state for an incoming data packet, a hidden number generator within a DMZ server connected to that node uses that state to generate the same hidden number. The generated number is used by the selector or table to determine the algorithm to use to unscramble the packet. The state may be transmitted in the packet, or may be transmitted from the transmitting node to the receiving node prior to transmission of the packet through the same or a different route than the transmission route of the packet.

The techniques used for dynamic encryption and splitting are similar to those used for dynamic scrambling, but in dynamic encryption a "key" is used in addition to the seed. The shared secret held by the DMZ server contains a selector or table of encryption and splitting algorithms and a key generator. In the case of symmetric key encryption, the sending node tells the receiving node, at the node's DMZ server, to identify the algorithm used to encrypt the packet and thereby the key used to decrypt the file. Send. For asymmetric key encryption, the media node requests information. That is, first, the receiving node transmits an encryption key to the transmitting node containing the data packet to be transmitted. The sending media node then encrypts the data according to the received encryption key. Only the receiving media node that generates the encryption key has the decryption key corresponding to that encryption key, and can use that encryption key to decrypt the generated ciphertext. Importantly, with asymmetric encryption, access to the encryption key used for encryption does not provide information about how the data packet was decrypted.

In the case of splitting, the seed is sent from the media node that split the packet to generate the subpackets to the media node that mixes the subpackets. A DMZ server connected to this mixing node uses the received seed to determine the segmentation algorithm, ie, the algorithm to use for subpacket mixing.

As noted above, in dual or tri-channel embodiments, signaling functions are performed by signaling nodes running on separate servers called signaling servers. In such embodiments, the seeds and keys are not sent directly from the sending media node to the receiving media node, but via a signaling server. Therefore, the sending media node sends a seed or key to the signaling server. As mentioned above, the signaling server is responsible for determining the routing of packets, so it knows the next media node to which each packet is to be sent.

To make hacking more difficult for hackers, the list or table of possible scrambling, splitting, and encryption methods in the selector is periodically updated so that the method corresponding to a particular seed or key is changed. (eg hourly or daily). Thus, at a given media node, the encryption algorithm used for packets generated at time t1 on day 1 is the encryption algorithm used for packets generated at the same time t1 on day 2. can differ from

Each DMZ server is typically physically connected to one or more media nodes within the same "server farm." As described above, a media node performs on packets it receives by providing a seed or key (e.g., based on the time or state in which the packet was generated) to a DMZ server connected to it. While requesting instructions (instructions) for operations, the medianodes do not have access to shared secrets or any other data or code in the DMZ server. The DMZ server responds to requests from media nodes and uses seeds or keys to determine which method the media node should use to unscramble, decode, or mix packets. For example, if a packet is scrambled and a media node wants to know how to unscramble it, the DMZ server searches a list (or selector) of scrambling algorithms to find the particular algorithm corresponding to the seed. find. The DMZ server then instructs the media node to unscramble the packet according to the found algorithm. In short, the media node sends a query embodied in a seed or key to the DMZ server, and the DMZ server sends instructions to the media node in response to the query.

Media nodes (despite not having IP addresses recognized by DNS) are accessible via the Internet, but DMZ servers are wired or optical to the networks connected to the media servers. It is completely separate from the Internet with only local network connections via 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 prior to the transmission of the data packet. Sent in a separate packet using the same route as the route. For example, when encrypting a packet, media node #1 includes in the packet an encryption key based on the time when the encryption was performed. Then, when the packet containing the encryption key arrives at media node #2, media node #2 transmits the encryption key to the DMZ server connected to the node. The DMZ server then uses the received key to select a decryption method from the selector to decrypt the packet. Media node #2 then asks the DMZ server how to re-encrypt the packet before sending the packet to media node #3. Again, the DMZ server informs media node #2 of the encryption method selected by the selector and sends the key reflecting the state corresponding to the selected encryption method to media node #2. Media node #2 performs encryption and sends the encrypted packet and key (individually or as part of a packet) to media node #3. The key is then used in a similar fashion by media node #3 to decrypt the packet. As a result, there is no single static decryption method that hackers can use to decrypt packets.

In the above examples, the use of time, a dynamic "state" state, as a determinant of the scrambling, encryption, or splitting method embodied in the seed or key is but one example. Any variable parameter, such as the number of nodes the packet has passed through, can also be used as a "state" for the seed or key to select the particular scrambling, encryption, or fragmentation method used.

In a "dual-channel" embodiment, seeds and keys are not sent directly between media nodes, but via a second "command and control" channel consisting of a signaling server. transmitted in Signaling nodes also provide routing information to media nodes and inform media nodes along the route of a packet how to split the packet and mix it with other packets. The signaling node also instructs each media node to attach an identifying "tag" to each packet transmitted from that node so that the media node next to it can recognize the packet. Command. Preferably, the signaling server only informs a given media node which media nodes have sent packets to it and which media nodes will receive packets sent from it. Hence, no media node knows the entire packet transmission route within the SDNP cloud. In some embodiments, routing functions may be split between two or more signaling servers. For example, a first signaling server determines the route to a particular media node, a second signaling server determines the route from that particular media node to another media node, and exits such processing. Continue up to the gateway node. Thus, no signaling server knows the entire routing of data packets.

In a "tri-channel" embodiment, a third set of servers, called "nameservers", are used to identify components within the SDNP cloud and provide identifiers for devices connected to the SDNP cloud and their corresponding IP or Stores information about the SDNP address. In addition, the name server frequently monitors media nodes in the SDNP cloud, maintaining, for example, a current list of active media nodes and a table of propagation delays for all combinations of media nodes in the cloud. In the first step when communication is initiated, the client device (eg, tablet) sends an IP packet to the name server requesting the address or other information of the data destination or called party. Additionally, a separate dedicated name server is used to act as the first point of contact when a device first connects, or registers, to the cloud.

For additional useful security, separate security "zones" with different selectors, seed and key generators, and other shared secrets are provided within a single SDNP cloud. Adjacent zones are connected by a bridge media node that holds the shared secret of both zones and has the ability to convert the rule-compliant data format of one zone to the rule-compliant data format of the other zone.

Similarly, in communication between different SDNP clouds, eg hosted by different service providers, a full-duplex (ie bi-directional) communication link is formed between the interface bridge servers of each cloud. Each interface bridge server has access to relevant shared secrets and other security information for each cloud.

An important advantage of the present invention is that there is no single point of control within the SDNP network and any node or server within the network has no control over how certain communications take place and how they change dynamically. not having complete information about

For example, a signaling node running on a signaling server knows the route (or, in some cases, only part of the route) over which communication takes place, but has no access to the data content communicated or the true The caller or client cannot be known. Furthermore, the signaling node cannot access the shared secret in the media node's DMZ server. As such, the signaling node cannot know how the data packets being transmitted were encrypted, scrambled, split or mixed.

An SDNP nameserver knows the real phone number or IP address of the caller, but does not have access to the data in flight or the routing of various packets and subpackets. Like signaling nodes, nameservers do not have access to shared secrets. Therefore, the nameserver cannot know how the data packets were encrypted, scrambled, split, or mixed in transit.

The SDNP media node that actually transmits the media content has no idea who the caller is, nor can it know the route that the various fragmented subpackets are traveling through the SDNP cloud. In fact, each media node only knows the data packet that is expected to arrive at it (identified by its tag or header) and where to send that data packet next (i.e., the "next hop"). . That is, each media node knows how the data was encrypted, scrambled, mixed, or split, or how the state, numeric seed, or key was used to decompress the file. I don't know what to choose. Only the DMZ server knows the information necessary to correctly process the data segments of the incoming data packet. That is, only the DMZ server can do the right thing using its shared secret, an algorithm that is not accessible through the network or by the media node itself.

Another inventive aspect of the present invention is to provide superior quality of service (QoS) by reducing network delays and minimizing propagation delays, as well as controlling the size of data packets. ie by sending smaller data packets in parallel through the cloud rather than relying on a single high-bandwidth connection to eliminate echo and dropped calls. Dynamic routing in SDNP networks uses knowledge of the network's node-to-node propagation delays to dynamically select the best current route for a given communication. In another embodiment, for high-priority clients, the network facilitates race-routing, sending duplicate messages in fragmented form through the SDNP cloud, selecting only the earliest data to restore the original voice. Or it can be restored to the data content.

Among the various advantages of the SDNP system according to the present invention, in parallel and "mesh transmission" embodiments, packets are fragmented as they are transmitted within the SDNP cloud so that even if a hacker can Prevent hackers from understanding the message even if they can decrypt the packets. And in "dynamic" embodiments, the scrambling, encryption, and fragmentation methods applied to packets change frequently, so that a hacker cannot continuously decrypt packets at one point in time. . Various other advantages of embodiments of the invention will become readily apparent to those skilled in the art upon reading the following description.

In general, similar security techniques can be applied in the "last mile" between the SDNP cloud and client devices (eg cell phones, tablets). Since the client device is usually located in a security zone away from the cloud, it first needs to be an authenticated SDNP client. This step involves installing, on the client device, a software package specific to that device's security zone, typically by downloading it from an SDNP management server. Client devices are linked to the SDNP cloud via a gateway media node (sometimes called a gateway) within the cloud. This gateway media node has access to shared secrets for both the cloud and the client device's security zone. However, client devices cannot access the shared secret for the SDNP cloud. Seeds and keys are sent directly between client servers via a signaling server to increase the level of security. Thus, the sending client device sends the seed and/or key directly to the receiving client device. In such embodiments, packets received by the receiving client device have the same scrambled or encrypted form as packets sent from the sending client device. As such, the receiving client device can use the seed and key received from the sending client device to unscramble or decrypt the packet. The direct transmission of seeds and keys between client devices is done in addition to the dynamic scrambling and encryption of the SDNP network itself, which can provide a higher level of security called nested security. .

In addition, a client device or a gateway node communicating with it can process packets of the same data type (e.g., voice packets, text message files, documents, pieces of software) or packets of different data types (e.g., voice packets and text files, text packets and video or photo images) are mixed before the packets reach the SDNP network, and the egress gateway node or destination client splits the mixed packets and restores the original packets. This is in addition to any scrambling, encryption, or fragmentation implemented in SDNP networks. In such cases, the sending client device instructs the receiving client device how to divide packets mixed at the sending client device or gateway media node to regenerate the original packets. Submit your seed. Sequential mixing and splitting implementations involve linear order operations or use nested structures where the client implements its own security measures and SDNP also implements its own security measures.

To further confuse hackers, a client device may send multiple packets (or sub-packets) in succession to different gateway nodes in a single communication, and send them over different physical media links (cellular, WiFi, etc.). , Ethernet cable). This process is sometimes called "multi-PHY". To further confuse, successively sent packets may contain different source addresses to prevent hackers from discovering that packets are being sent from the same client device.

The invention also makes progress with respect to teleconferencing. In a normal conference call, packets are sent to all participants, but according to the invention, some participants can be muted and the participants to be muted can be muted from the client device or other node. is removed from the conference call by preventing packets from being sent. In another embodiment of the invention, data packets are broadcast to all participants, but implemented using a different encryption method. In a normal conference call, data packets are encrypted and sent to all participants, which sends a copy of the decryption key to all participants. In private or mute mode, data packets are sent to multiple users using different encryption methods, and decryption keys can be sent only to selected users.

The security mechanisms used in communication using the SDNP network and protocol are also compatible with file and data storage security. Communication over an SDNP network typically involves the transmission of scrambled and encrypted data, as well as anonymous fragmented data, from one client device to another client device; Storage can also be stopped prematurely, storing files and data in one or more buffers until the client device wishes to receive them. This decentralized data storage is sometimes referred to herein as decentralized data storage.

In the drawings listed below, similar components generally have similar reference numerals. Note, however, that each component bearing a reference number is not necessarily identical to another component bearing the same reference number. For example, a cryptographic operation with a particular reference is not necessarily identical to another cryptographic operation with the same reference. Also, groups of components, such as servers, within a network that are collectively identified by a single reference numeral are not necessarily identical to each other.
Schematic diagram showing packet forwarding over a conventional network Schematic diagram showing the packet scrambling process Schematic diagram showing the packet unscrambling process Schematic showing various packet scrambling algorithms Schematic showing static parametric packet scrambling Schematic showing dynamic scrambling with hidden digits Schematic diagram showing the packet rescrambling process Schematic diagram showing the packet encryption process Schematic diagram showing the packet decoding process Schematic diagram showing the cryptographic scrambling process and its inverse Schematic diagram showing the process of DUSE re-packetization including re-scrambling and re-encryption Schematic diagram showing the process of fragmenting a fixed-length packet Schematic diagram showing the mixing process for fixed-length packets Schematic showing various packet mixing methods Schematic diagram showing SDNP security functions and inverse functions Block diagram illustrating SDNP security operations for incoming and outgoing data packets for single route last mile communication. Block diagram illustrating SDNP security operations for incoming and outgoing data packets for multi-route last-mile communication. FIG. 2 is a block diagram illustrating audio, video, text, and file content creation, data packet preparation, data packet recognition, and content playback in an SDNP client device; An illustration of an SDNP data packet illustrating hierarchical data encapsulation using the 7-layer OSI model. Descriptive diagram of the SDNP payload Block diagram showing inbound last-mile data packet processing in an SDNP gateway using tri-channel communication Block diagram showing inbound last-mile data packet processing in an SDNP gateway using single-channel communication Block diagram showing outbound last mile data packet processing in an SDNP gateway using tri-channel communication Schematic diagram of the SDNP cloud Example of insecure last-mile communication without identity verification Insecure last mile communication over the traditional telephone system (POTS) without caller identity verification Example of insecure last mile communication with identity verification Insecure last-mile communication over the analog Public Service Telephone Network (PSTN) with operator-based identity verification Insecure last-mile communication over wired digital networks with login-based or token-based identity verification Insecure last-mile communication over wired analog networks with PIN or credit card-based identity verification Schematic diagram of an example hyper-secure last-mile communication that can support identity verification Identity verifiable hyper-secure last-mile communication over WiFi wireless networks Identity verifiable hyper-secure last-mile communication over cellular wireless networks Identity verifiable hyper-secure last-mile communication over Ethernet wired network Identity verifiable hyper-secure last-mile communication over cable networks Identity verifiable hyper-secure last-mile communication that combines wired and home WiFi wireless networks Schematic diagram of an example last-mile communication including an identity-verifiable hyper-secure communication segment connected to the final link of an identity-paired secure LAN Last mile communication including ID verifiable hyper-secure wired communication section connected to secure device with wired ID pairing and unsecured device with unknown ID Last-mile communications including identity-verifiable hyper-secure wireline connections connected to WPA-protected computing and communication devices that are ID-paired by WiFi LAN for home and work Last-mile communication including identity-verifiable hyper-secure wired links connected to WPA-protected home IoT devices ID-paired by WiFi LAN Last-mile communications including identity-verifiable hyper-secure wireline connections connected to corporate identity-paired, WPA-protected devices over Ethernet or WiFi LAN Schematic diagram of an example last mile communication including an identity verifiable hyper-secure communication segment connected to an identity paired secure wired or secure wireless LAN last link Schematic diagram of wired and wireless hyper-secure bridges including Ethernet and WiFi applicable for stream communication Schematic diagram of wired and wireless hyper-secure bridges using satellite and automotive networks applicable for last-mile communications Schematic diagram of wired and wireless hyper-secure bridges utilizing cable and cellular networks applicable for last-mile communications Last-mile communications including identity verifiable hyper-secure wireless communications via satellite uplinks and downlinks to various devices including satellite phones, planes, trains, ships, and home satellite receivers (set-top boxes) Example of last link hyper-secure communication between devices in an on-board aircraft communication network with satellite connectivity Examples of aircraft satellite communications and antenna modules Example of last-link hyper-secure communication between devices in an onboard ocean cruise ship communication network with multiple satellite connection channels An example of last-mile hyper-secure communication between devices in an on-board train communication network with wireless and satellite connectivity Hyper-secure last-mile communication to automotive telematics modules, including cellular last-link connectivity Example of last link communication between telematics modules of an automotive communication network with cellular connection and in-vehicle WiFi connected device Example of hyper-secure vehicle-to-vehicle communication using cellular connectivity Hyper-secure trunk line communication over microwave, satellite, and fiber networks Feature Comparison of Security, Identity Verification, and Caller Anonymity for Hyper-Secure, Secure, and Non-Secure Communication Networks Schematic diagram of single-route last-mile hyper-secure communication using static IP addresses Schematic diagram of IP stack for single-route last-mile hyper-secure communication using static IP address Simplified diagram of single-route last-mile hyper-secure communication using static IP addresses Schematic diagram of single-route last-mile hyper-secure communication with dynamic client IP address IP stack for single-route last-mile hyper-secure communication with dynamic client IP address Alternate IP stack for single-route last-mile hyper-secure communication using dynamic client IP addresses Schematic diagram of Multi-Route Last Mile Hyper-Secure with Static IP Address IP Stack Diagram for Multi-Route Last Mile Hyper-Secure Communication with Static IP Address Using Single PHY Last Link IP stack diagram for multi-route last-mile hyper-secure communication with static IP addresses using multi-PHY lastlink Schematic diagram of multi-route last-mile hyper-secure communication with dynamic client IP address IP Stack Diagram for Multi-Route Last Mile Hyper-Secure Communication with Dynamic Client IP Address Using Single PHY Last Link IP stack diagram for multi-route last-mile hyper-secure communication with dynamic client IP address using multi-PHY lastlink Schematic of an alternative version of multi-route last-mile hyper-secure communication using dynamic client IP addresses IP stack diagram for alternative version of multi-route last-mile hyper-secure communication with dynamic client IP address Illustration of IPv4 and IPv6 datagrams for Ethernet communication carrying SDNP payloads An illustration of IPv4 and IPv6 Last Link Ethernet packets used in communication from the client to the SDNP cloud Illustration of IPv4 and IPv6 Gateway Link Ethernet packets used in communication from client to SDNP cloud Illustration of IPv4 and IPv6 Gateway Link Ethernet packets used in SDNP cloud-to-client communications Illustration of IPv4 and IPv6 Last Link Ethernet packets used in SDNP cloud-to-client communications Continuous Ethernet data packets used in single-route last-mile communication with static client addressing (abstract) Continuous Ethernet data packets used in single-route last-mile communication with dynamic client addressing (abstract) Continuous Ethernet data packets used in multi-route last-mile communication with static client addressing (abstract) Continuous Ethernet data packets used in multi-route last-mile communication with dynamic client addressing (abstract) Summary Table of SDNP Last Mile Routing over Ethernet Topology for single-route last-mile communication over Ethernet Topology of multi-route last-mile communication over Ethernet Topology of multi-route last-mile communication over Ethernet Explanatory diagram of IPv4 and IPv6 of WiFi communication that transmits SDNP payload Illustration of IPv4 and IPv6 last link WiFi packets used in communication from client to SDNP cloud Illustration of IPv4 and IPv6 gateway link WiFi packets used in communication from client to SDNP cloud Illustration of IPv4 and IPv6 gateway link WiFi packets used in SDNP cloud to client communication Illustration of IPv4 and IPv6 last link WiFi packets used in SDNP cloud to client communication Illustration of IPv4 and IPv6 datagrams for 4G cellular communication carrying SDNP payload Illustration of IPv4 and IPv6 last link 4G cellular data packets used in communication from client to SDNP cloud Illustration of IPv4 and IPv6 last link 4G cellular packets used in SDNP cloud to client communication Explanatory diagram of single-media multi-PHY last link communication Explanatory diagram of mixed media multi-PHY last link communication Explanatory diagram of alternative implementation of multi-PHY last link communication Illustration of continuous last-link communication from client to SDNP cloud using IPv6 datagrams delivered over multi-PHY Ethernet Illustration of continuous last link communication from client to SDNP cloud using IPv6 datagrams delivered over multi-PHY WiFi Illustration of continuous last link communication from a client to the SDNP cloud using IPv6 datagrams delivered over a multi-PHY 4G cellular network Illustration of sequential last-link communication from client to SDNP cloud using IPv6 datagrams using multi-PHY delivery over Ethernet and WiFi Illustration of continuous last-link communication from client to SDNP cloud using IPv6 datagrams with multi-PHY delivery over WiFi and 4G cellular networks Schematic diagram of the OSI layer stack configuration of a DOCSIS cable modem communication network showing layer 1 to layer 7 functionality An illustration of a DOCSIS3-based communication packet created for a cable system carrying an SDNP payload. Explanatory diagram of spectrum allocation and carrier modulation scheme for various DOCSIS3 protocols Explanatory diagram of DOCSIS3.1 communication sequence between CTMS and CM Explanatory diagram of DOCSIS3.1 upstream communication Explanatory diagram of DOCSIS3.1 downstream communication Schematic diagram of a three-route SDNP network for last-mile communication Schematic diagram of "call request" operation in tri-channel SDNP last mile communication Schematic diagram of "address request" operation in tri-channel SDNP last mile communication Schematic diagram of "address delivery" operation in tri-channel SDNP last mile communication Flowchart showing an SDNP command and control packet synthesis method Schematic diagram of "routing instruction" operation in single route tri-channel SDNP last mile communication Schematic diagram of "SDNP call" operation in single route tri-channel SDNP last mile communication from SDNP client to SDNP cloud Schematic diagram of last mile 3 route communication to SDNP cloud and SDNP client in an SDNP call Schematic diagram of 3-route communication between the SDNP cloud and the last mile implemented as "callouts" to non-SDNP clients Schematic diagram of "routing instruction" operation in multi-route tri-channel SDNP last mile communication Schematic diagram of the "SDNP call" operation in a multi-route 3-channel SDNP last-mile communication from the SDNP client to the SDNP cloud Schematic diagram of "SDNP call" operation in multi-route tri-channel SDNP last mile communication in direction from SDNP cloud to SDNP client Schematic diagram of group call "routing instruction" operation in single-route tri-channel SDNP last-mile communication Schematic diagram of an "SDNP group call" using SDNP multi-route cloud transport and SDNP last mile communication from zone U1 clients to clients in other zones Schematic of an "SDNP Group Call" using SDNP Multi-Route Cloud Transport and SDNP Last Mile Communication from Zone U7 Clients to Clients in Other Zones Schematic of an "SDNP Group Call" using SDNP multi-route cloud transport and SDNP last mile communication from a zone U9 client towards clients in the same and other zones. Schematic diagram of an "SDNP Group Call" using SDNP multi-route cloud transport and last mile communication for both SDNP clients and non-secure PSTN devices. Operation list of normal call and private call in SDNP group call Operation list of normal call and hyper private call in SDNP group call Normal and Private Push-to-Talk Operation Chart in SDNP PTT Group Call Normal and Hyperprivate Push-to-Talk Operation Table in SDNP PTT Group Call Schematic diagram of data transmission during write operations in hyper-secure file storage of fragmented data Schematic diagram of data flow during write operations in hyper-secure file storage for fragmented data Schematic diagram of data flow for read operations in hyper-secure file storage for fragmented data Schematic diagram of data transmission during read operations in hyper-secure file storage of fragmented data Examples of SDNP cloud-connected file storage solutions Schematic diagram of a distributed hyper-secure file storage network with local and cloud-connected storage servers File mapping for non-redundant hyper-secure file storage (RRF=0) File Mapping for Hyper-Secure File Storage with Read Redundancy Factor RRF=1 File Mapping for Hyper-Secure File Storage with Read Redundancy Factor RRF=2 Network map of a distributed hyper-secure file storage system using tri-channel network communication File Write Request Operations in a Distributed Hyper-Secure File Storage System File Server Name Request Operation in Distributed Hyper-Secure File Storage System Planning Operation of Signaling Server in Distributed Hyper-Secure File Storage System Client-Side Last Mile of Signaling Server and Write Routing Direction of SDNP Cloud in Distributed Hyper-Secure File Storage System Storage Side Last Mile of Signaling Server and Write Routing Direction of SDNP Cloud in Distributed Hyper-Secure File Storage System File transfer in a distributed hyper-secure file storage system Link response confirming file storage and write operations in a distributed hyper-secure file storage system File Storage Server Link Transfer in Distributed Hyper-Secure File Storage System File Storage Server Write Confirmation Data Packet Containing FS Link Synthetic file storage read link in client's SDNP messenger Hyper-secure file storage with non-redundant RRF=0 and file map of non-redundant FS link with LRF=0 File Map of Hyper-Secure File Storage with Non-Redundant RRF=0 and Redundant FS Link with LRF=1 File Map of Hyper-Secure File Storage with Non-Redundant RRF=1 and Redundant FS Link with LRF=1 Graph showing storage resilience as a function of number of file storage server and client FS links Schematic diagram of SDNP encoding and SDNP decoding functions Schematic diagram of SDNP distributed file storage with client-side file security and hyper-secure file transmission functions Schematic diagram of SDNP distributed file storage with nested file security and hyper-secure file transmission Schematic diagram of hyper-secure encoding in SDNP distributed file storage write operations Schematic diagram of hyper-secure decoding in SDNP distributed file storage read operations Flowchart of AAA operation in hyper-secure file read operation Flowchart of file access and SDNP transmission in hyper-secure file read operation File Read Request Operations in a Distributed Hyper-Secure File Storage System File Storage Server Name Request Operation in Distributed Hyper-secure File Storage System Planning operation of storage server name distribution and signaling server in distributed hyper-secure file storage system Reading instructions for storage-side last mile and SDNP cloud routing of signaling servers in a distributed hyper-secure file storage system Client-Side Last Mile of Signaling Servers and Read Routing Directions for SDNP Clouds in Distributed Hyper-Secure File Storage Systems Storage-Side File Decoding During Read Operations in Distributed Hyper-Secure File Storage Systems File data transfer during read operations in a distributed hyper-secure file storage system File data transfer during link update in a distributed hyper-secure file storage system File data transfer in a distributed hyper-secure file storage system used for file redistribution Timestamp for SDNP text messaging Flowchart of SDNP registration communication End-to-end encryption in Internet OTT communication End-to-end encryption of hyper-secure communications Schematic diagram of the "SDNP call" operation by an SDNP security agent performing invisible monitoring of outgoing calls. Schematic diagram of the "SDNP call" operation by an SDNP security agent performing invisible monitoring of incoming calls. Forwarding File Storage Server Links in a Distributed Hyper-Secure File Storage System with an SDNP Security Agent Covertly Observing FS Link Routing Schematic diagram of "SDNP call" operation by an SDNP security agent covertly monitoring calls using multi-route last-mile communication. Flowchart of SDNP security agent designation/approval procedure Communication from mobile phone to base station affected by SS7 vulnerability SDNP communication that repels SS7 attacks by spoofing phone numbers SDNP Softwitch-based cloud connectivity hosted on separate servers SDNP softswitch-based cloud connectivity hosted on shared servers Connectivity for SDNP softswitch-based clouds hosted on overlapping networks SDNP Softswitch-based cloud connectivity to access global SDNP cloud carriers Nested SDNP subnet example

After nearly a century and a half of circuit-switched telephony, today's communication systems and networks will carry Ethernet, WiFi, 4G/LTE, and DOCSIS3 data over cable and fiber, all within the next decade. Moved to packet-switched communications using the Internet protocol. The benefits of bundling voice, text, images, video and data, along with the use of redundant paths to ensure reliable IP packet delivery (hence why the Internet was originally created), is an unparalleled level of System interoperability, global connectivity, and much more. However, as with any innovation, the challenges posed by the new technology are often as great as the benefits gained.

Disadvantages of existing telecom providers

As detailed throughout the Background section of this disclosure, today's communications have many drawbacks. Today's highest performance mobile phones built with custom digital hardware owned by the world's leading long distance carriers including AT&T(R), Verizon(R), NTT(R) and Vodaphone(R). Communication systems typically provide excellent voice quality but are costly, such costs include expensive monthly fees, connection fees, long distance charges, complex data rate plans, long distance roaming charges, and a number of service charges. Because these networks are private, the actual data security is not generally known and security breaches, hacks and intrusions are usually not reported to the public. Given the number of wiretapping and privacy breaches reported in the press today, private carrier communication security remains questionable, at least in last-mile connections, if not private clouds.

"Internet Service Providers" or ISPs form another link in the global communications chain. As described in the Background of the Invention, voice carried over the Internet using VoIP or "Voice over Internet Protocol" suffers from quality of service or QoS problems. Such problems include the following.
- The Internet, a packet-switched network, was not designed to deliver IP packets in a timely manner and was not designed to support low-latency, high-QoS real-time applications.
• Unexpected paths in the routing of IP packets result in constantly changing delays, bursts with high data error rates, and unexpected call disconnects.
IP packet routing is at the discretion of the Internet Service Provider (IPS), which controls the network over which the packet is routed and uses its own It may coordinate routing to distribute network load or provide appropriate service to VIP clients.
Over-the-top or OTT providers such as LINE®, KakaoTalk®, Viber®, etc., free ride on the Internet and act as hitchhikers on the Internet, impacting the network and QoS Uncontrollable factors.
• Heavyweight audio CODECs are used that cannot provide speech with uncompromised speech quality even at modest data rates.
• VoIP, which is based on the TCP transport protocol, suffers from high latency due to delays caused during handshaking and rebroadcasting of IP packets, causing voice degradation problems. Unassisted UDP transport does not guarantee payload integrity.

Aside from QoS issues, the security of current devices and networks is simply unacceptable to support the future needs of global communications. As detailed in the Background section of the United States patent application entitled Secure Dynamic Communication Networks and Protocols, network security protects against cyber attacks (spyware, Trojan horses, infections, phishing, etc.) against communicating devices. , cyber-attacks against the Last Link (including spyware, IP packet sniffing, eavesdropping, call interception of “fake” cell phone towers by cyber pirates), and cyber-attacks on the local network or telco portion of the last mile connection (spyware, It is susceptible to large-scale attacks such as IP packet sniffing, infections such as viruses, and cyber pirates'"man-in-the-middleattacks"). The cloud itself is vulnerable to unauthorized access by breaching security at any cloud gateway through attacks such as viruses, attacks from cyber pirates launching man-in-the-middle attacks, denial-of-service attacks, and attacks from unauthorized government surveillance. may receive. In summary, today's communications security is compromised by a number of vulnerabilities that are easily exploited by cybercriminals and useful for cybercrime and cyberprivacy violations, including:
- Disclosure of the IP packet's destination, including the destination IP address, destination port number, and destination MAC address.
- Disclosure of the source of the IP packet, including source IP address, source port number, and source MAC address.
• Disclosure of the type of Layer 4 transport employed, the type of service requested by port number, and the application data encapsulated in the payload of the IP packet.
• IP packet payloads, including personal and confidential information, login information, application passwords, financial records, videos, photos, etc., in unencrypted files.
• Communication dialogs that allow cyber hackers to repeat the opportunity to destroy encrypted files.
• Numerous opportunities to install malware, including spyware, phishing programs and Trojan horses, on communication devices and routers using FTP, email, and web page-based infections.

To reiterate the basic and inherent weakness of packet-switched communication networks that use the Internet Protocol, intercepted IP packets by any adversary, i. involved, where the IP packet came from, where the IP packet is being sent, how the data is being transferred (i.e. either UDP or TCP), what kind of service is requested (i.e. what kind of application data is contained within the payload). In this regard, cyber pirates can determine the "context context" of conversations, increasing the chances of breaking encryption, breaking password security, and gaining unauthorized access to files, data, and payload content.

encryption

To defend against various cyber-attacks as described above, today's network administrators, IT professionals, and application programs rely primarily on a single line of defense: encryption. Encryption is the process by which recognizable content (readable text, executable programs, visible video and images, or intelligible speech), also called “plaintext,” is transformed into “ciphertext,” which is represented as a string of nonsensical characters. is a means of converting to an alternative file type known as .

The encryption process, which transforms an unprotected file into an encrypted file, uses a logical algorithm called a cryptographic algorithm to change the data into equivalent text elements without revealing the apparent pattern of the transformation process of encryption. is used. The encrypted file is transmitted over a communication network or medium until received by the destination device. Upon receiving the file, the receiving device then decodes the encoded message to reveal the original content using a process known as "decoding". The study of encryption and decryption, commonly referred to as "cryptography", fuses elements of mathematics such as mathematical theory, set theory, and algorithm design with computer science and electrical engineering.

Simple "single-key" or "symmetric-key" encryption techniques allow the use of a single keyword or phrase known in advance by both parties for unlocking during the file encryption and decryption process. For example, in World War II, submarines and seagoing ships that communicated on open radio channels used encrypted messages. Originally, encryption was single-key based. Allied cryptographers were able to read encrypted files without their knowledge after revealing encryption keywords or patterns by analyzing code patterns. As encryption methods became more complex, it became harder to break the code manually.

Code evolved into mechanical, machine-based cryptography. At the time, the only way to break the code was to steal the encryption machine and use the same tools that encrypted the files to decrypt the messages. The problem was how to steal the encryption machine without being detected. If the code machine turns out to be stolen, the adversary can simply change the code and update the already working encryption machine. This principle is still valid today, and the most effective cyberattacks are those that go undetected.

Computerization and the advent of the Cold War made encryption more complex, but also increased the speed of the computers used to crack the encryption code. At each step in the development of secure communications, the technology and know-how for encrypting information and the ability to crack the encryption code have been developed almost in tandem. The next major evolutionary step in cryptography was the innovation in the 1970s of dual-key cryptography, which is still in use today. One of the best-known dual-key cryptosystems is the RSA public-key cryptosystem, named after its developers Rivest, Shamir, and Adleman. Despite RSA's public certification, some contemporary developers independently devised the same principles. RSA uses two cryptographic keys based on two large undisclosed prime numbers. One algorithm is used to convert these two primes into an encryption key (here called E-key), and a different algorithm is used to convert two different secret primes into a secret decryption key (here called D-key). A mathematical algorithm is used. An RSA user (referred to herein as a "key issuer") who chooses a secret prime distributes E-keys generated with algorithms typically between 1024b and 4096b to those who wish to encrypt files, i.e. " Publish. The E-key is known as the "public key" because this key may be distributed in unencrypted form to many parties.

A party wishing to communicate with a key issuer uses this public E-key together with a publicly available algorithm generally provided in the form of commercial software to encrypt files sent to a particular key issuer. do. Upon receiving the encrypted file, the key issuer uses the private D-key to decrypt the file back to plaintext. A unique feature of common dual-key schemes and the RSA algorithm is that the public E-key used to encrypt the file cannot be used for decryption. Only private D-keys owned by the key issuer are capable of file decryption.

The concept of dual-key, split-key, or multi-key exchange in file encryption and decryption is not specifically limited to RSA or any algorithmic method, but rather methodologically identifies the communication method as a series of steps. Let us use dual key exchange in implementing communication over a switched packet communication network. For example, a notebook wishing to receive a secure file from a mobile phone first generates two keys, an E key for encryption and a D key for decryption using some algorithm. The notebook then sends the E-key to the mobile phone using public network communications carrying IP packets. The IP packet, in unencrypted form, contains the mobile phone's destination IP address, port #, and transport protocol TCP, along with the notebook's MAC address, IP source and port addresses, and the E-key as its payload. Contains an encrypted copy.

The mobile phone then uses the agreed encryption algorithm or software package to process the plaintext file using the encryption algorithm and the encryption E-key to extract the payload of the IP packet in a secure communication. An encrypted file or ciphertext carried as . When the algorithm receives the IP packet, it uses the private decryption key, the D-key, to decrypt the file. Since the D key corresponds to the E key, essentially the algorithm recognizes both keys and uses them to decrypt the ciphertext back into unencrypted plaintext 697B. The payload of IP packet 696 is protected in the form of an encrypted file, i.e. ciphertext, while the rest of the IP packet is unencrypted, sniffable, readable by cyber pirates, and partly contains the source IP address "CP" and port #, the destination IP address "NB" and the associated port #. Thus, communications can be monitored even if the payload itself cannot be opened.

Virtual Private Network (VPN)

Another security method that relies on encryption is that of "virtual private networks" or VPNs. A VPN uses encrypted IP packets to form a tunnel or secure pipe within the network. Instead of encrypting only the payload, the entire IP packet is encrypted and another unencrypted IP packet that acts as a mule or carrier that sends the encapsulated packet from one VPN gateway to another VPN gateway. encapsulated in Originally, VPNs were used to connect remotely distributed local area networks; for example, companies operating private networks in New York, Los Angeles, and Tokyo interconnected LANs to form one It was used when one wanted to have the same functionality as if they were sharing a private network.

The basic VPN concept can be thought of as encrypted communication between two devices. For example, a first server may serve a "virtual private network" containing content as part of a single LAN supporting multiple devices via wireless RF and wired connections, i.e., a second server via VPN tunnels. A second server has wired connections to desktops, notebooks, and WiFi base stations. In addition to these relatively low bandwidth links, the first server also connects to the supercomputer via a high bandwidth connection. The resulting communication is a sequence of multiple data packets including a VPN packet within an outer IP packet. In operation, an external IP packet from Server A specifying a source IP address and port # is sent to server B with a destination IP address and port #. This outer IP packet causes communication to be set up between the first server and the second server, forming an encrypted tunnel for the data to pass through. The VPN payload of the external packet contains a last-mile IP packet, and connects a desktop with source IP address "DT" and a corresponding ad-hoc port # and a notebook with source IP address "NB" and a corresponding ad-hoc port #. It provides direct communication between and requests for file transfers.

To establish this transfer securely using a virtual private network, a VPN tunnel is created and a session is started before the actual communication is sent. For enterprise applications, VPN tunnels are generally owned and operated by dedicated ISPs or carriers with their own fiber and hardware networks, rather than being carried ad-hoc over the Internet. The carriers often have annual or long-term contracts with companies that require VPN services to guarantee a certain amount of bandwidth for a certain cost. Ideally, communication between servers should be performed using high-speed dedicated links, with no intermediate or "last mile" connections that impede VPN performance, QoS, or security.

In operation, a conventional VPN requires a two-step process, the first step of creating or "logging in" to the VPN, and the second step of transferring data within a secured pipe or tunnel. The tunneling concept is shown hierarchically, with external IP packets carried by the communication stack forming a VPN connection from layer 1 to layer 4, utilizing layer 5 to create a virtual VP session 723, and layer 6 presentation layers are utilized to facilitate encryption and provide VPN gateway to gateway pipes between servers. A VPN connection uses the Internet Protocol to transmit IP packets, but the VPN's physical layer 1 and VPN data link layer 2 are generally supported by dedicated carriers and do not use unpredictable routing over the Internet. For example, application layer 7 data transferred as device-to-desktop communication is supplied as tunneling data containing all seven OSI layers necessary to establish communication as if a VPN did not exist. Thus, a VPN can be considered a communication protocol that operates within Layer 7, carrying its internal packets.

In operation, when an external IP packet transitions from one communication stack to another, the packet's true message, the encapsulated data, is opened to reveal. In this way, end-to-end communication takes place independently of the details used to create the VPN tunnel, except that the VPN tunnel must be formed prior to any communication attempt and closed after the conversation is finished. . Failure to open a VPN tunnel first results in the transmission of unencrypted IP packets that are susceptible to IP packet eavesdropping, hijacking, infection, and the like. Failure to close the VPN after the conversation is complete gives cybercriminals the opportunity to hide their illegal activities within someone else's VPN tunnel, and if intercepted, criminal penalties will be imposed on the innocent. could become

VPNs are a common way for multiple private local area networks to connect to each other using private connections with dedicated capacity and bandwidth, but the use of VPNs over public networks and the Internet limits communication between the two. have a problem. One problem with VPNs is that VPN connections must be pre-established before use, rather than on a packet-by-packet basis. For example, a VoIP call connected over a packet-switched network must establish a VPN session before one cell phone can contact the intended call recipient on a second cell phone. For this purpose, a VPN connection application must first be installed on the mobile phone of the caller. The caller then sends IP packets to a VPN host, which is typically a service provider. These packets are carried in the last mile traversable through routing. For example, it is carried from the wireless communication of the mobile phone to a nearby WiFi base station, then by wire communication to the local router, and finally to the VPN host. Once a session is established between the caller's mobile phone and the VPN host, the caller's mobile phone instructs the VPN host to establish a VPN tunnel. Portions of this VPN tunnel are facilitated at layer 5 and encrypted at layer 6.

Once the VPN connection is set up, the caller's mobile phone will place the call via any VoIP phone app. If the destination phone is not connected to the same VPN, the application needs to establish a last-mile "call-out" link from the nearest VPN host to the destination mobile phone. If the VoIP application cannot or is not allowed to do so, the call fails and ends quickly. Otherwise, the inner side IP packet establishes an application layer 5 session between the calling and destination mobile phones and verifies that the IP test packets are properly decrypted and understandable.

To make a call (make a call), the phone carrier's SIM card in the phone is not compatible with the VPN tunnel, so the call is not from the phone's normal dial-up feature, but through the layers running on the phone. 7 application. When a call is initiated, the mobile phone sends a series of IP packets representing small pieces or "snippets" of audio according to its communication application. These packets are sent from the application in the caller's mobile phone over the WiFi link to the WiFi base station, then over the wired connection to the router, and finally over the wired connection to the VPN host. The data is then sent to the destination device of the VPN network, the VPN gateway, secured by connection to the VPN host through the VPN tunnel. In this example, the VPN tunnel is not connected to the destination mobile phone and stops short of the device being called. After the VPN gateway, the data is unencrypted since there is no VPN carrier intermediary. Once leaving the VPN tunnel, the VPN host forwards the data to the destination device's last mile connection. That is, the data is sent over a wired connection to the router, and then sent over the wired connection to the local cellular system and the tower, which makes the call as a normal 2G, 3G or 4G phone call. The process of making a call from a mobile phone app to a phone not running the same app is called callout functionality.

The examples below highlight another problem in connecting to a VPN over a public network. The last mile link from the VPN host to the caller is not covered by VPN and therefore does not guarantee security, performance or call QoS. Specifically, every caller's last mile connection is subject to eavesdropping and cyberattacks. When the call is completed and the caller hangs up, the VPN link must be terminated, VPN Layer 5 terminates the VPN session, and the caller's mobile disconnects from the VPN host.

The application of VPN networks designed for transferring data between computers raises a number of problems.
• Last-mile communication from the destination VPN network to the destination mobile phone is unsafe and at risk of being sniffed and monitored.
• Communication between the caller's mobile phone and the VPN gateway can only be secured if the caller is using a data communication application. If the caller uses a phone line to connect to the VPN gateway, i.e. using the dial-in feature, the last mile connection between the caller's mobile phone and the nearest VPN gateway is not secure and subject to sniffing and surveillance. there is a risk of being
- The final call between terminals can be secured only when both terminals use data communication, and cannot be secured when telephone lines are used. It also requires that both terminals are pre-connected to the same VPN before initiating the call.

This last point is a paradox of VPN communication. The party receiving the call must know that it will be called and connect to the network in advance. They must be notified in advance to receive the call and instructed to connect to the VPN before the call is placed. This means that you must first receive an unsecured call before you can make a secure call. Insecure calls are easily hacked, sniffed, and monitored. Metadata also reveals who is calling whom and what time the call was made. Call metadata is very useful for hackers to learn the activity and profile of the person being hacked.

However, even excluding security concerns, there is no guarantee that making phone calls or sending documents over a VPN will not fail for any reason, including the following.
• VPNs may not operate with low enough latency to support real-time applications, VoIP, or video.
• The VPN last-mile connection from the caller to the VPN gateway or from the VPN gateway to the call recipient may not operate with low enough latency to support real-time applications, VoIP or video.
The distance to the nearest VPN gateway, or "last mile", to the caller or intended recipient is likely to be very far, possibly farther than the distance to the call recipient without a VPN This can provide numerous opportunities for network instability, uncontrolled routing through unknown networks, variable QoS, and man-in-the-middle attacks on unprotected portions of the connection.
• The VPN last-mile connection from the VPN gateway to the call recipient may not support "call-out" connections and packet forwarding or supporting links to local carriers.
• Local carriers or government censors may block calls or connections to or from known VPN gateways for national security or regulatory compliance reasons.
Using a corporate VPN limits VoIP calls to company employees and designated authorized users only, blocks financial transactions and video streaming, and prevents private emails to public mail servers such as Yahoo, Google, etc. may be blocked, or YouTube®, chat programs, or Twitter may be blocked according to company policy.
• In the case of unstable networks, the VPN may keep a permanent session open and connected to the caller's device until manually reset by the VPN operator. This can result in loss of bandwidth for subsequent connections or high connection charges.

Network comparison

Comparing communication provided by an "overtop" or OTT provider to a communication system that uses a public network to connect to an ad-hoc VPN, other than the VPN link itself, both communication systems have largely the same components and connections. have. Specifically, the caller's last mile, which includes cell phones, WiFi wireless connections, WiFi base stations, wireline connections, and routers, represents the same last mile connection in both implementations. Similarly, at the other party's last mile, the caller's cell phone, cell connection, cell towers and towers, wireline connection, and router are the same in both the Internet and VPN versions. The main difference is that in public networks, VPN tunnels, which constitute secure communication between VPN hosts, are replaced by servers and routers, which constitute unsecured communication connections. Another difference is that in OTT communication, the call is immediately available and a VPN addition step needs to be used to set up the VPN and terminate the VPN session before and after the call.

In both examples, last-mile connections pose unanticipated call QoS, exposure to packet sniffing, and risk of cyber-attacks. Since the servers and routers are likely to be managed by different ISPs in different locations, we can interpret them as different existing clouds. Although public networks owned and operated by, for example, Google, Yahoo, Amazon, and Microsoft are linked together by the Internet, for example, the "Amazon cloud" can be considered a different cloud from each other.

A relatively unpopular competing network topology, peer-to-peer networks (PPNs), include networks composed of many peers with packet routing managed by the PPN rather than a router or ISP. Peer-to-peer networks have existed in hardware for decades, but it was Napster who popularized the concept as a way to circumvent the controls, costs, and regulations of Internet service providers. When sued by US government regulators for music piracy, the Napster founder quit and went into early OTT carrier Skype. At that time, Skype's network was transformed from traditional OTT to PPN like Napster.

In PPN operation, all devices with login connections to the PPN become one node participating in the PPN. For example, when a mobile phone with PPN software installed logs into a peer-to-peer network in a region, it becomes part of the network like all other connected devices in that region. A call invoked by any device hops from one device to another to reach its destination, another PPN-connected device. For example, if a mobile phone uses its PPN connection to call another PPN-connected device (e.g., a destination mobile phone), the call is routed through any device physically located in the PPN between the two parties. Connect along the route. For example, a call originating from a mobile phone will be routed by WiFi through a WiFi base station to a nearby desktop, then to another person's notebook, then from one desktop to another desktop, and finally to a mobile phone base station and Connect to the destination mobile phone through the tower. In this way all routing was controlled by the PPN and the Internet was not involved in managing routing. Used by both parties, the PPN software used to connect to the network also serves as an application for VoIP-based voice communications.

When one cell phone tries to call a cell phone on a non-PPN device on the other side of the world, the routing must involve the Internet on some link, especially to send packets across oceans or mountains. There is The first part of routing in a region begins with the caller's cell phone and is routed through WiFi basestations, desktops, notebooks, and multiple desktops, as in the previous example. At this point, if the nearest notebook is connected to the network, the call will be routed through it, otherwise the call will be routed through cell towers and towers to the destination cell phone, and then are returned to the cell phone base stations and towers at 10:00 a.m. before being sent onwards.

If the call is transpacific, the call is routed to a third-party server/router in the cloud and then to a separate third-party server in the cloud, as computers and mobile phones cannot carry traffic over the sea. / will necessarily be routed to the Internet through the connection to the router. For example, on approaching the destination, the call leaves the Internet and first enters the PPN in the destination area through the desktop and connects to WiFi, notebooks and base stations. WiFi does not run PPN apps, so the actual packets going into WiFi travel to either a tablet or cell phone in the WiFi subnet, back to WiFi and then sent over a wired connection to cell towers and towers. It must be. Finally, the caller's mobile phone call connects to a destination mobile phone that is not a PPN enabled device. The connection thereby constitutes a "callout" of the PPN as it exits the PPN network. When using such a PPN scheme, the calling party's registration with the PPN network is done by first completing a PPN login, like a VPN. The PPN app can then be used to make calls. The advantage of the PPN scheme is that little or no hardware is required to make long distance calls, and all devices connected to the PPN regularly update the PPN operator regarding its status, load and latency. Therefore, the PPN operator can determine the routing of packets to minimize delay.

The drawback of this scheme is that the packet traverses a network containing many unknown nodes, which poses a potential security threat and has unpredictable impact on call latency and call QoS. As a result, peer-to-peer networks operating at layer 3 and above are generally not employed in packet-switched communication networks, with the exception of Skype.

A summary comparison of ad-hoc VPN providers, Internet OTT providers, and PPN peer networks side-by-side is shown in the table below.

As mentioned above, VPNs and the Internet constitute a fixed infrastructure, but the nodes of a peer-to-peer network vary depending on the user logged in and the device connected to the PPN. From the contents of this table, high-speed long-distance connections of networks (eg, networks across oceans and mountains) are contractually guaranteed only for VPNs and otherwise unpredictable. Last mile bandwidth is dependent on the local provider for both Internet and VPN providers, but for PPN it's completely different depending on who is logged in.

Latency, the propagation delay of IP packets sent in succession, cannot be managed by OTT and VPN because it depends on the local carrier or network provider rather than the provider controlling the routing in the last mile PPNs, on the other hand, are limited in their ability to use best effort to forward traffic between nodes that are online in a particular region at that time of day. Similarly, for network stability, PPN has the ability to reroute traffic to maintain the network, but it is dependent on who is logged in. The Internet, on the other hand, is inherently redundant, and although delivery is almost certain to be guaranteed, it is not always delivered in a timely manner. The network stability of ad-hoc VPN depends on the number of nodes allowed to connect to the VPN host. When these nodes go offline, the VPN is disabled.

From a call setup perspective, the Internet is always available, PPNs require an extra step of logging into the PPN before making a call, and VPNs can involve complicated login procedures. Also, most users find the ability to use an OTT phone number beneficial from an ease-of-use standpoint, rather than the separate login IDs used in VPNs and PPNs. All three listed networks suffer from variable VoIP QoS, which generally lags far behind those available with commercial carriers.

From a security point of view, all three options are bad and the last mile is completely exposed to packet sniffing with readable addresses and payloads. VPNs provide cloud connection encryption, but still expose the IP address of the VPN host. Therefore, none of the network options shown are considered secure. Cryptography is therefore used in a variety of applications to prevent hacking and cyber-attacks, either as a Layer 6 protocol or as an embedded part of Layer 7 applications themselves.

Over-reliance on encryption

Whether encrypting IP packets or establishing a VPN, current network security relies solely on encryption, which is one of the weaknesses of modern packet-switched communication networks. For example, much research has been done on how to attack RSA encryption. Restricting the prime numbers to a large size greatly reduces the risk of breaking the cracked D-key code using the brute force method, but the polynomial factorization method solves the key based on smaller prime number-based keys. It has been demonstrated that this can be done successfully. There are concerns that advances in "quantum computing" will lead to practical ways to conduct cyberattacks and destroy RSA-based cryptographic keys and other cryptographic keys in a reasonable amount of time.

In order to counter the risk of code corruption that has existed so far, new algorithms and encryption methods using "larger keys" such as the "Advanced Encryption Standard" (AES encryption) adopted by the US NIST in 2001 appeared. Based on the Rijndael cipher, a design principle known as a substitution permutation network combines both substitution and permutation using different keys and block sizes. In its current form, the algorithm employs a fixed block length of 128 bits and variable key lengths of 128, 192, and 56 bits, corresponding to 10 rounds used in the input file conversion. , 12, and 14 times. As a practical matter, AES encryption can be efficiently and quickly performed in software or hardware for keys of any length. In cryptography, AES-based encryption using 256-bit keys is referred to as AES256 encryption. AES512 encryption using a 512-bit key is also available.

While each new generation creates better encryption methods and raises the bar on cryptography to break them more quickly, cybercriminals who want to make a profit simply use computing power to break encrypted files. They often focus on goals rather than using . As mentioned above, cyber pirates can use packet sniffing and port scanning to gain valuable information about conversations, corporate servers, or VPN gateways. With cyber profiling, it may be easier to launch cyber attacks on the personal computers, notebooks, and mobile phones of corporate CFOs and CEOs, rather than attacking the networks themselves. Sending an email to an employee that automatically installs malware or spyware when the embedded link is opened is entering the network from the "inside," where the employee must connect and work, thus ensuring full firewall security. be bypassed.

If the data does not change, ie statically traverses the network, it also increases the chances of breaking the encryption. For example, in the network of FIG. 1, the underlying data in packets 790, 792, 794, and 799 remain unchanged as the packets travel through the network. Each illustrated data packet contains a sequence of data or audio sequentially ordered in time, unaltered from its original order when created. If the content of the data packet is in text form, reading the unencrypted plaintext file of the sequence 1A-1B-1C-1D-1E-1F yields the "readable" text of the communique number "1". If the content of the data packet is voice, then the unencrypted plaintext files in the sequence 1A-1B-1C-1D-1E-1F are processed by the corresponding voice codec (essentially a software-based D/A converter). When converted, or "played", by the audio file number "1".

In any case, throughout this disclosure, each data slot represented by a fixed size box has a predetermined number of bits, eg, two bytes (2B) long. The exact number of bits per slot is flexible as long as each communication node in the network knows the size of each data slot. Each data slot contains audio, video, or text data, identified in the drawings by a number followed by a letter. For example, as shown, the first slot of data packet 790 contains content 1A, where the number "1" indicates a particular communication #1, and the letter "A" indicates the first data of communication #1. represent a part. Similarly, the second slot of data packet 790 contains content 1B, where the number "1" indicates a particular communication #1, the letter "B" represents the second portion of data for communication #1, It is after 1A in order.

For example, if the same data packet contained content "2A" hypothetically, the data represents a different communication unrelated to communication #1, specifically the first packet "A" in communication #2. A group of data packets containing the same kind of communication, for example all data for communication #1, is easier to analyze and read than a data packet that mixes different communication. By sequencing the data in a proper order, cyber attackers can easily interpret the nature of the data, such as voice, text, graphics, pictures, video, and executable code.

Furthermore, in the illustrated example, the source and destination IP addresses of the packets are constant, i.e., the packets remain unchanged during transfer over the network in the same format as the data entering and exiting gateway servers 21A and 21F. Because it is there, and because it does not change the underlying data, hackers have more opportunities to intercept data packets, analyze and open files, or listen to conversations. Mere transmission and simple security, that is, security that uses only encryption to protect, increases the opportunities for cyberattacks. This is because the extremely simplified use of the Internet as a packet-switched network increases the likelihood of successful cyberattacks.

Securing real-time networks and connected devices

A new and innovative way to control IP packet routing to improve quality of service (QoS) for telephony, video, and data communications while addressing the plethora of security vulnerabilities that plague today's packet-switched networks. A systemic approach is needed, one that manages a global network of discrete technologies while simultaneously promoting end-to-end security. Goals for such packet-switched networks of the present invention include the following criteria.
1. Ensuring global network or long distance carrier security and QoS, including dynamically managing real-time voice, video and data traffic routing throughout the network.
2. Guaranteeing "Local Network or Telco" security and QoS in the last mile of the communication network.
3. Ensuring the security and QoS of the "last link" of communication networks, including providing secure communications over unsecured lines.
4. Ensuring the security of communication devices and authenticating users to prevent unauthorized or unauthorized access or use.
5. Facilitate the implementation of secure means of storing data on a device or online network or cloud storage to prevent unauthorized access.
6. Provide security and privacy protection for non-public personal information, including all financial, personal, medical and biometric data and records.
7. Provide security and privacy protection for all financial transactions including online banking, shopping, credit cards and electronic payments.
8. Provide security, privacy, and optionally anonymity for transactions and information exchanges, including M2M (machine-to-machine), V2V (vehicle-to-vehicle) and V2X (vehicle-to-infrastructure) communications thing.

Of the above goals, the subject matter contained in this disclosure addresses the second topic listed in Item #2, namely, "Ensuring local network or telco security and QoS in the last mile of a telecommunications network. "About. This topic can be thought of as achieving security for last-mile connections without sacrificing real-time communication performance.

Explanation of terms

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

Anonymous Data Packet: A data packet that lacks information about its original source or ultimate destination.

Client or Client Device: A terminal that connects to the SDNP cloud over the last mile. Typically mobile phones, tablets, notebooks, desktops, or IoT devices.

Concealment: The process of encoding, using a combination of security operations such as scrambling, fragmentation, junk data insertion, encryption, etc., to render the contents of an SDNP packet, or parts thereof, unrecognizable.

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

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

MZ Server: A computer server not directly accessible from the SDNP network or the Internet used to store selectors, seed generators, key generators and other shared secrets. A DMZ, also called an "air-gapped" server, refers to a computer with no wired network connection or access.

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

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

Dynamic Scrambling/Unscrambling: Scrambling and unscrambling that relies on algorithms that change dynamically depending on conditions, such as the time the data packet was created or the zone in which it was created.

Dynamic Fragmentation: A fragmentation process in which the fragmentation algorithm dynamically changes as a function of the seed, based on conditions such as time, state, zone, etc., when a data packet is split into multiple subpackets.

Encryption: A mathematical operation used to transform a data packet from plaintext to ciphertext.

Fragmented Data Transfer: Routing over an SDNP network of fragmented and mixed data.

Junk Data Removal (or "Dejunking"): The removal of junk data from a data packet for the purpose of restoring the original data or to recover the original length of the data packet.

Junk Data Insertion (or "Junking"): The intentional introduction of meaningless data into a data packet to obfuscate the actual data content or to control the length of the data packet.

Key: A disguised digital value generated by inputting a state, such as time, into a key generator that uses a secret algorithm to generate the key. A key is used to select an algorithm to encrypt or decrypt data in a packet from a selector. Keys can be used to securely pass state information over public or unsecured lines.

Key Exchange Server: To prevent possible network operator espionage, a public cryptographic key is sent to the client (particularly for client-managed key management, i.e., client-based end-to-end encryption), optionally A computer server hosted by a third party independent of an SDNP network operator, used to distribute servers using symmetric key encryption accordingly.

Last Link: The network connection between the client's device and the first device in the network with which it communicates (usually a wireless tower, WiFi router, cable modem, set-top box, or Ethernet connection). In the case of Ethernet communications, the last link refers to what is physically cabled to a cable modem or fiber optic modem. In the case of WiFi connections (eg coffee shop connections), Last Link indicates that the WiFi router is connected to a DSL, cable or fiber optic network. In the case of wireless cellular networks, the last link refers to the wireless link (eg 3G or 4G/LTE connection) between the cellular tower and the mobile phone.

Last Mile: A network connection between an SDNP gateway (or other type of network or cloud) and a client, including the last link. The last mile typically refers to communications over networks owned and controlled by local telephone companies and cable television companies (eg, Comcast Cable, Verizon Mobile, Korea Telecom, British Telecom, etc.).

Mixing: Combining data from different sources and data types to produce one long data packet (or series of shorter subpackets) with unrecognizable content. In some cases, previously split data packets are mixed to recover the original data content. Mixing operations may also include junk data insertion, deletion, and parsing.

Multi-PHY or Multi-PHY: Refers to communication that alternately transfers related sequential data packets over multiple physical media (optical fiber and 4G, different WiFi channels and wavenumbers, 4G and WiFi, Ethernet and WiFi, etc.) .

Parsing: A mathematical operation that divides data packets into shorter subpackets for storage or transmission.

Router: A device that routes datagrams to the destination address specified in the IP header. For data routing outside the SDNP network, the IP addresses used are either valid Internet IP addresses (i.e., addresses recognized by a DNS server) or local network providers (e.g. Comcast, owned cable/ Communications within the fiber optic network are assigned IP addresses within Comcast.).

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

Fragmentation: An operation in which a data packet (or series of serial data packets) is split into multiple subpackets and routed to multiple destinations. A splitting operation may also include the insertion or deletion of junk data.

Softswitch: Software containing executable code that performs the functions of communications switches and routers.

SDNP: An acronym for "Secure Dynamic Network and Protocol" which means a high security communication network made in accordance with the present invention.

SDNP Address: Address used to route SDNP packets through the SDNP cloud or last mile. This address is the ad-hoc IP address of the next destination device, ie it contains the information necessary only to perform a single hop.

SDNP Management Server: A computer server used to distribute executable code and shared secrets globally or to specific zones.

SDNP Bridge Node: An SDNP node that connects one SDNP cloud (or zone) to another SDNP cloud (or zone) with different security credential information.

SDNP Client or Client Device: A network-connected device (typically a mobile phone, tablet, notebook, desktop, or IoT device running an SDNP application to connect to an SDNP cloud that typically connects over the last mile of the network). ).

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

SDNP gateway node: An SDNP node that connects the SDNP cloud to client devices over the last mile. An SDNP gateway node needs access to at least two zones: the SDNP cloud and the last mile.

SDNP Media Node: Following instructions from a signaling server or another computer that performs signaling functions (including encryption/decryption, scrambling/unscrambling, mixing/splitting, tagging, and generation of SDNP headers and subheaders); Softswitch executable code that processes incoming data packets with specific identification tags. The SDNP media node is responsible for identifying incoming data packets with specific tags and forwarding newly generated data packets to their next destination.

SDNP Media Server: A computer server that hosts a softswitch that performs the functions of an SDNP media node with dual-channel and tri-channel communication, and performs the tasks of an SDNP signaling node and an SDNP name server node with single-channel communication.

SDNP nameserver: A computer server that hosts a softswitch that performs the functions of an SDNP nameserver node in tri-channel communications.

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

SDNP Network: The entire client-to-client high-security communication network, including last-link and last-mile communication, as well as the SDNP cloud.

SDNP Node: An SDNP communication node, including a software-based "softswitch" running on a computer server, or hardware connected to an SDNP network and acting as an SDNP node, either a media node, a signaling node, or a name server node. device.

SDNP Server: A computer server comprising either an SDNP Media Server, an SDNP Signaling Server, or an SDNP Name Server, and hosting appropriate softswitch functionality to act as an SDNP node.

SDNP Signaling Node: initiates a call or communication between parties and all or part of multiple routes for fragmented data transfer based on caller (caller) criteria and dynamic tables of inter-node propagation delays. and how to manage incoming and outgoing data packets for SDNP media.

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 tri-channel SDNP communications and the duties of an SDNP nameserver node in dual-channel communications.

SDNP tag: A source address, SDNP zip code, or code used to identify an incoming data packet or its subpackets.

Security Operation: A process that modifies a data packet in order to conceal it (or recover the contents of a concealed packet) using state-dependent security credential information associated with the zone or state in which the packet was created.

Security settings or security credential information: Generated by a seed generator or key generator using a secret algorithm with constantly changing input state such as network time, and thus securely transmitted over public or insecure lines A digital value, such as a seed or key, that can be

Seed: A spoofed digital value generated by inputting a state, such as time, into a seed generator that uses a secret algorithm to generate the seed. The seed is used to select an algorithm for scrambling or splitting the data in the packet from the selector. Seeds can be used to securely pass state information over public or insecure lines.

Selector: part of the shared secret and along with the seed or key to select a particular algorithm for scrambling, unscrambling, encrypting, decrypting, splitting, or mixing one or more packets A list or table of scrambling, encryption or fragmentation algorithms that may be used.

Shared Secrets (Information): Seed generators, key generators, zone information and algorithms used in the shuffling process as well as scrambling/unscrambling, stored locally on a DMZ server that is not accessible over the SDNP network or the Internet Sensitive information about SDNP node operations, including tables or selectors for , encryption/decryption, and mixing/splitting algorithms.

Single PHY: Communication that transports related data packets over a single physical medium such as fiber optics, Ethernet, WiFi or cellular networks.

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

Time: Universal network time used to synchronize communications over an SDNP network.

Unscrambling: A process used to restore data segments within a scrambled data packet to their original order or sequence. Unscrambling is the inverse function of scrambling.

Zone: A specific interconnected network of servers that share common security credentials and shared secrets. The last mile connection includes zones separate from the SDNP cloud.

Secure Dynamic Network And Protocol (SDNP) Design

To minimize packet delays in real-time, ensure stable call connections, and transmit highly reliable voice and video streaming, and to prevent cyber attacks and hacks on packet-switched communications, the present disclosure A secure (hereafter also referred to as "secure") dynamic network and protocol, or SDNP, was designed based on several processing principles:
• Real-time communications should always use the path with the shortest latency.
• Unauthorized inspection or sniffing of data packets should not reveal the source, destination, and contents of the packet.
Data packet payloads should be dynamically re-encrypted (i.e. decrypted and then re-encrypted) using a separate encryption algorithm without risking being hacked in a reasonable period of time. be.
・Even after being decrypted, the payload of every data packet is still an unintelligible payload by dynamically scrambling a combination of multiple conversations, irrelevant data, and junk packet fillers. be.

Implementation of the above guidelines includes various unique methods, functions, features, and implementations that are included in some or all of the various embodiments described below.

SDNP uses one or more private clouds, including soft-switching functions of telecommunications companies (ie, communication systems) implemented using proprietary command and control software that is not accessible over the Internet.
• All intra-cloud communication is done using dedicated SDNP packet routing within the proprietary cloud based on SDNP addresses and dynamic ports (i.e. proprietary NAT addresses) rather than DNS-recognized IP addresses. SDNP addresses cannot be used or routed through the Internet or outside the SDNP cloud.
• The SDNP network dynamically routes all real-time communications using the frequently identified and lowest latency path.
- With the exception of cloud-to-cloud and last-mile communications, secure or real-time communications are not routed outside the SDNP cloud or over the Internet, generally using single-hop routing with invisible addresses.
• The routing data contained within the data packet identifies the routing for a single hop between two devices adjacent to each other, identifying only the SDNP or IP addresses of the previous and next servers.
• The phone number or IP address of the caller or callee, ie the client's respective source and destination addresses, are not present in the header of the IP packet nor in the encrypted payload.
- Shared secrets associated with command and control reside in system software installed in a secure DMZ server that is not accessible over the Internet.
- SDNP packet communication is carried out on three different channels: a "name server" used to identify elements in the SDNP cloud, a "media server" used to route content and data, and packets and calls through a "signaling server" used for command and control of
• Routing information, along with keys and numeric seeds (if required), is supplied to all participating media servers through independent signaling channels prior to call origination or communication and separate from content. The signaling server only provides the media server with the previous and next destinations of packets that traverse the network.
A media packet represents only a portion of a speech, document, text, or file dynamically mixed and remixed with other packets containing different fragmented data types from other sources Contains fragmented data.
• Special security measures are used to protect first and last mile communications, including separating signaling server related communications from media and content related packets.
Packet transmission is content-type dependent, audio and real-time video or streaming is based on modified UDP, but is susceptible to packet loss or delay Signaling packets, command and control packets, data files, application files, systems files, and other files, use TCP transmission.
Use specific security and authentication methods to verify that the device is the real client and not a clone, and to authenticate that the person communicating is the true owner of the device and not an impostor. be done.

To ensure secure communication with low latency and high QoS in VoIP and real-time applications, the disclosed "Secure Dynamic Network And Protocol" or SDNP includes the following components: A "dynamic mesh" network according to the invention is used.
Dynamically adaptive multipath and latency-minimized mesh routing Dynamic packet scrambling Dynamic fragmentation using packet splitting, mixing, parsing, and junk bit packet fillers Signaling, commanding and controlling dynamic network protocol media and content with dynamic intra-node payload encrypted address disguise and need-to-know routing information across networks or clouds Multi-channel communication separated from network addresses Dynamically adaptable real-time communication protocol with data type-specific features and contextual routing Support for client encrypted payloads with user key management For high QoS in congested networks lightweight audio CODEC

As mentioned above, SDNP communication relies on multi-route or mesh transmission to dynamically route data packets. In SDNP communication according to the present invention, in contrast to the single-path packet communication used for Internet OTT and VoIP, the contents of data packets are distributed from a common source or caller by coherent packets containing information. It is not delivered serially, but in fragmented form. Dynamically mixing and remixing content sent from multiple sources and callers to create imperfections that combine different types of data, content, audio, video, and files with junk data fillers. Fragments are generated. An advantage of data fragmentation and communication according to the present disclosure is that even unencrypted and unscrambled data packets are nearly impossible to decipher because they are a combination of unrelated data of different data types. It is impossible.

By combining the mixing and splitting of fragmented packets with packet scrambling and dynamic encryption, hybrid packets of dynamically encrypted, scrambled and fragmented data can be generated by generating that data. , packetization, and dynamic re-packetization, meaningless packets that are completely unreadable and undecipherable to any person or observer without the shared secret, key, numeric seed, time, and state variables used becomes.

In addition, the fragmented content of each packet and the secret information used to generate it are used to reassemble the packet with new fragments and new security elements (e.g., changed seeds, keys, algorithms, and secret information). It is only valid for less than a second until In this way, the security of SDNP is further enhanced by limiting the time it takes for cyber pirates to decrypt state-dependent SDNP data packets. This is because cyber pirates have to perform calculations for tens of thousands of years (the 12th power of the time required to decipher) in one tenth of a second.

The combination of methods described above allows a much higher level of multidimensional security than that provided by static encryption. Accordingly, secure dynamic networks and protocols according to the present disclosure are also referred to herein as "hyper-secure" networks.

Device packet scrambling

In accordance with the present invention, secure communication over packet-switched networks relies on several elements of anti-hacking and security, one of which includes the scrambling of SDNP packets. . Scrambling an SDNP packet involves rearranging the order of data segments to render the information unreadable and useless. As shown in FIG. 2A, unscrambled data packet 923 is processed by a scrambling operation 924 to produce scrambled data packet 925 . This scrambling operation 924 can use any algorithm, numerical technique, or sequencing technique. Algorithms can be static equations, dynamic variables or numerical seeds based on a "state", such as the time 920 when scrambling is performed, or a Seed Generator 921 may include a numeric seed 929 generated using a state-based algorithm, such as the time 920 at which scrambling was performed by . For example, if each datum is converted to a monotonically increasing unique number, then all seeds 929 will be unique. The time 920 and seed 929 are used to select and identify a particular algorithm and to select a particular scrambling operation 924 from the available scrambling methods, namely the Scrambling Algorithms list 922. Also used for In the data flow diagrams, for convenience of illustration, this packet scrambling operation and sequence is indicated schematically or symbolically as packet scrambling operation 926 (Packet Scrambling).

FIG. 2B shows an unscrambling operation 927 (Unscrambling Process), which is the inverse operation of scrambling operation 924 . This unscrambling operation 927 reuses the state (time) 920 and its corresponding seed 929 used to generate the scrambled data packet 925 to unscramble the descrambled data. , produces an unscrambled data packet 923 . Using the same state (time) 920 that was used for packet scrambling, an unscrambling operation 927 selects from the scrambling method list 922 the same scrambling that was used for scrambling. method must be used again. Although the term "scrambling" is used in the scrambling algorithm list 922, this algorithm table identifies and selects the inverse operation of scrambling required to perform "unscrambling." used for That is, the scrambling algorithm list 922 contains information necessary for both scrambling and unscrambling data packets. The scrambling algorithm list 922 may also be referred to as a “scrambling/unscrambling” algorithm list 922, as the two operations involve identical steps performed in reverse order from each other. However, for the sake of clarity, this table (list) refers only to the function of scrambling and not the inverse function (unscrambling).

If the scrambling algorithm selected for performing the unscrambling operation 927 does not match the algorithm used for packet scrambling, or the seed 929 or state (time) 920 is the time the scrambling was performed. , the unscrambling operation fails to decode 923 the original unscrambled data packet and the packet data is lost. In the data flow diagram, for convenience of illustration, this packet unscrambling operation and sequence is indicated schematically or symbolically as packet unscrambling operation 928 (Packet Unscrambling).

According to the present invention, each data segment within a data packet is returned to its original proper position as long as the scrambling operation is reversible, i.e. by repeating the steps in the reverse order of the original process. Numerical algorithms are used to perform the scrambling operation as long as they can be returned. Mathematically, acceptable scrambling algorithms are reversible. That is, function F(A) has or can be transformed into its inverse function F−1(A), for example as follows.
F−1[F(A)]=A

This means that the data file, array, string, file or vector A processed by function F is then processed using the inverse function F-1 to restore the original input It means that it can be decrypted to A.

Examples of such reversible operations are the static scrambling algorithms shown in FIG. 2C, including mirroring and phase shifting algorithms. In the mirroring algorithm, one data segment is swapped with another data segment so that it is a mirror image about the line of symmetry defined by the mirroring process factor or "Mod". In the illustrated Mod-2 Mirroring, every two consecutive data segments of the original input data packet 930 are swapped. That is, the positions between the 1st and 2nd data segments, between the 3rd and 4th data segments, between the 5th and 6th data segments (and so on), that is, mathematically, 1.5th, 3 The positions of data segments 1A and 1B are exchanged, and the positions of data segments 1C and 1D are exchanged about the line of symmetry located at the 5th, 5.5th, ..., (1.5+2n) positions. , the positions of data segments 1E and 1F are swapped (and so on), thereby producing a scrambled output data packet 935 .

In Mod-3 Mirroring, for every three consecutive data segments, the positions of the first and third data segments are exchanged, and the second packet in between is shifted from its original position. Not changed. Thus, the positions of data segments 1A and 1C are swapped, but data segment 1B remains unchanged from its original position (the middle position in three consecutive data segments). Similarly, the positions of data segments 1D and 1F are swapped, but data segment 1E remains unchanged from its original position (the middle position of three consecutive data segments). Thus, a scrambled data packet output 936 is produced. In Mod-3 mirroring, the lines of symmetry of mirroring are located at the 2nd, 5th, 8th, . . . (2+3n)th positions.

In Mod-4 Mirroring, the positions of the first and fourth data segments are exchanged and the positions of the second and third data segments are exchanged for every four data segments that are continuous with each other. , thereby generating a scrambled output data packet 937 from the input data packet 931 . Thus, data segment 1A is swapped with data segment 1D and data segment 1B is swapped with data segment 1C. In Mod-4 mirroring, the line of symmetry of mirroring is between the second and third data segments of four consecutive data segments (e.g., between the second and third data segments). between the 6th data segment and the 7th data segment), i.e., at the 2.5th, 6.5th, . . . , (2.5+4n)th positions do. In Mod-m Mirroring, the mth data segment of the input data packet 932 is swapped in position with the first or 0th data segment and the nth data segment is (mn) th data segment and positions are swapped, thereby producing a scrambled output data packet 938 .

Another scrambling method called frame-shifting is further illustrated in FIG. 2C. In this frame shift, each data segment is shifted in position by one, two, or more frames to the left or right. For example, in 1-Frame Phase Shift, each data segment is shifted in position by one frame. Specifically, the first data segment is position-shifted to the position of the second data segment, the second data segment is position-shifted to the position of the third data segment, and so on; produces a scrambled output data packet 940 . Note that the last frame of the input data packet 930 (frame 1F in the illustrated example) is shifted to the position of the first data segment 1A.

In the 2-Frame Phase Shift, the first data segment 1A of the input data packet 930 is shifted two frames to the position of the third data segment 1C, and the fourth data segment 1D is shifted to the position of the third data segment 1C. , to the position of the last (sixth) data segment of the scrambled output data packet 941 . The penultimate (fifth) data segment 1E is shifted in position to the position of the first data segment, and the last (sixth) data segment 1F is shifted to the position of the second data segment. shifted. Similarly, in a 4-Frame Phase Shift, each data segment of input data packet 930 is shifted in position by 4 frames, the first frame 1A is swapped in position with frame 1E, and frame 1B is Frame 1F is swapped with frame 1F, frame 1C is swapped with frame 1A, and so on to produce scrambled output data packet 942 . For Maximum Frame Phase Shift, the first frame A is swapped in position with the last frame, and the second frame 1B is shifted in position to the position of the first frame (i.e., the output data packet 943), the position of the third frame is shifted to the position of the second frame, and so on. If one frame is phase shifted beyond the maximum phase, the output data will not change from the input data. In the illustrated example, the shift direction of the phase shift is to the right. In this algorithm, the shift direction of the phase shift could be to the left, but in that case the results would be different.

The above-described algorithms and similar methods of the present disclosure are referred to herein as static scrambling algorithms. This is because the scrambling operation is performed only once, thereby transforming the input data set into a unique output. Furthermore, in the algorithm described above, the decision on how to perform scrambling does not depend on the value of the data packet. As shown in FIG. 2D, according to the present invention, parametric scrambling is a possible scrambling algorithm ( For example, Sort#A, Sort#B, etc.). For example, assume that each data segment can be converted to a number based on a calculation of the data contained in that data segment. One possible approach to determining the numerical value of the data segment is to use the decimal or hexadecimal equivalent of the bit data within the data segment. If the data segment contains multiple terms, the numerical equivalent is determined by summing the digits in the data segment. The data in the data segments are then combined into a single number or "parameter" which is then used to select the scrambling method to use.

In the illustrated example, the unscrambled data packet 930 is parametrically converted in step 950 into a data table 951 containing numerical values for each data segment. As shown, the 0th frame, data segment 1A, has the value "23", the 1st frame, data segment 1B has the value "125", and so on. A single data packet value for the entire data packet 930 is then extracted at step 952 . In the illustrated example, the "1002" in the sum value 953 (Sum) indicates the linear sum of all data segment values from table 951, ie sum of the parameter values. In step 954, this parameter value (i.e., total value 953) is compared to a set of condition tables (i.e., if-then-else statements predefined in software), i.e., total value 953 is compared with a number of non-overlapping numeric ranges in table 955 to determine the sort routine to use. In this example, the parameter value "1200" falls in the range 1000 to 1499, so it is determined that Sort #C should be used. Once the sort routine is selected, the parameter values are no longer needed. Unscrambled input data 930 is then scrambled in a selected manner at step 956 to produce scrambled data packet output 959 . In the illustrated example, Sort #C, summarized in table 957, contains a set of relative movements for each data segment. In this set, the first data segment of scrambled data packet 959, the 0th frame, is defined to be shifted three frames to the left (shifted by three). The first frame contains data segment 1B that is unchanged (ie, does not move) from its original position. The second frame contains data segment 1E shifted two to the left from its original position. The same is true for the third frame, which contains data segment 1F shifted two to the left from its original position. The fourth frame of scrambled data packet output 959 contains data segment 1C shifted two to the right from its original position (ie moved +2). The fifth frame contains data segment 1A shifted five positions to the right from its original position (ie moved +5).

Thus, sort #C, summarized in table 957, causes each data segment to uniquely move to a new position, thereby producing a parametrically determined scrambled data packet 959. When unscrambling a scrambled data packet, the same sorting method (Sort #C) is used and the above process is performed in reverse order. To ensure that the same algorithm is selected to perform the unscrambling operation, the parameter values 953 of the data packets are not changed by the scrambling operation. For example, using a linear summation of the parameter values for each data segment produces the same number regardless of the order of the numbers.

Dynamic scrambling methods use the state of the system (e.g., time) to identify the conditions under which the data packets were scrambled so that when performing the unscrambling operation, the It becomes possible to select the same method as when. In the system shown in FIG. 2E, states are used to generate impersonation numerical seeds. The spoofed numeric seed is sent to the package sending or receiving device and used to select a scrambling algorithm from a table. Alternatively, the state itself is transmitted to the sending or receiving device and a hidden number generator located in the sending or receiving device generates the hidden number used to select the scrambling/unscrambling algorithm. used for In such a configuration, shown in FIG. 2E, state (eg, time) 920 generates a Hidden Number (HN) 961 by Hidden Number Generator 960 and scrambles it using Hidden Number 861. Used to select a scrambling method from algorithm list 962 . An algorithm selected from scrambling algorithm table 962 using hidden number 961 is used to transform unscrambled data packet 930 into scrambled data packet 964 by scrambling operation 963 (Scrambling). State 920 may be sent directly to hidden number generator 960 or via seed generator 921, as shown in FIG. 2F.

The advantage of using hidden numbers, rather than using only numeric seeds, to select the scrambling algorithm is that analysis of the data stream, i.e., combining repeated sets of scrambled data with their corresponding numeric seeds and statistics By physically correlating, the possibility of cybercriminally reconfiguring the scrambling table can be eliminated. The seed is visible in the data stream and can therefore be spied on, but the hidden number generator can generate the hidden number "HN" based on the shared secret. As such, the hidden number HN is not present in the data stream and cannot be spied on or sniffed. That is, the hidden number is not sent over the network, but is generated locally based on the numeric seed. Since the purpose of the numeric seed is camouflage, this mathematical manipulation in the hidden number generator provides an additional layer of security to thwart hackers.

Once the algorithm is selected, the numeric seed is also used as an input variable in the algorithm of scrambling operation 963. Using the numeric seed twice in this way can further confuse analysis by hackers. This is because the seed does not directly select the algorithm, but cooperates with the algorithm to determine the final alignment of the scrambled data segment. Similarly, when unscrambling a dynamically scrambled data packet, the seed 929 (or state (time) 920) is transferred from the communication node, device, or software that performed the unscrambling to the node performing the unscrambling. Or must be sent to the device.

According to the present invention, the seed generator 921 algorithm, the hidden number generator 960, and the scrambling algorithm list 962 represent "shared secret" information stored on the DMZ server (described below) and used to transmit data packets. unknown to either the sender or the recipient. The shared secret is preconfigured and is not associated with the transmitted communication data packet, e.g., set during code installation where various authentication procedures are performed to ensure that the shared secret is not leaked. . As will be described below, shared secrets are limited to "zones" so that a single set of stolen shared secrets cannot allow a hacker to access an entire communication network or sabotage real-time communications.

In addition to any shared secret, in dynamic scrambling, where the scrambling algorithm changes between passes of data packets, a "state" based seed is required to scramble or unscramble the data. If there is no ambiguity about the state used to generate the seed, and if there is some means of telling the next node which state was used during the previous scrambling of the data packet, then this state based on the seed is , time, communication node number, network identifier, or even any physical parameter such as GPS location. The algorithm used to generate the seed in the seed generator is part of the shared secret, so a hacker cannot tell from the seed's information what state the seed is based on. The seed is transmitted from one communication node to the next, such as by embedding itself in a data packet, by transmitting over another channel or path, or a combination thereof. For example, the state used to generate the seed may initially be a random number and then include a counter that increments by a fixed number each time a data packet passes through a communication node. Each count represents a specific scrambling algorithm.

In one dynamic scrambling embodiment, in the first step of scrambling, a random number is generated to select the scrambling method to be used. This random number is embedded in the header of the data packet or in a portion of the data packet that is not subject to scrambling reserved for command and control. When the data packet arrives at the next node, the digits embedded in the data packet are read by the communicating node and used in software to select the appropriate algorithm to unscramble the incoming data packet. The number or "count" is then incremented by one or a predetermined integer and the packets are scrambled according to the algorithm associated with this new number. A new count is then stored in the output data packet, overwriting the previous count. This process is repeated at the next communication node.

In another embodiment of the disclosed counter-based method for selecting a scrambling algorithm, a random number is generated to select the initial scrambling algorithm, and this random number is referred to as a "shared secret" to a specific It is sent to all communication nodes used to send data packets. A count (eg, starting at 0) is embedded in the header of the data packet, or in a portion not affected by scrambling reserved for command and control in the data packet. The data packet is then sent to the next communication node. When the packet arrives at the next communication node, that server reads the numerical value of the count, adds an initial random number to the count, identifies the scrambling algorithm used to previously scramble the data packet, and scrambles the packet accordingly. to unscramble the The count is then incremented by one or a predetermined integer thereafter, and the count is again placed in the header of the data packet, or the portion of the data packet that is not affected by scrambling, reserved for instructions and controls. Padded and overwrites the previous count. The random number, which serves as a shared secret, is not sent embedded in communication data packets. When the data packet arrives at the next communication node, the server adds a random number (shared secret) to the updated count value extracted from the data packet. This new number uniquely identifies the scrambling algorithm used to scramble the incoming packet at the previous communication node. In this way, only non-meaningful counts can be intercepted from the unscrambled portion of the data packet by cyber pirates, who do not know what the data means.

Alternatively, a hidden number is used to signal the state of the packet and the algorithm used to scramble the packet. A hidden number combines a time-varying state or seed with a shared secret, typically comprising a numerical algorithm, a secret that is not transmitted between communicating nodes and therefore cannot be sniffed or found by man-in-the-middle attacks or cyber pirates. is used to generate digits, or "hidden digits". This hidden number is then used to select the scrambling algorithm used for scrambling. The state or seed is meaningless without knowledge of the algorithm used to calculate the hidden number, and the shared secret algorithm is stored behind a firewall inaccessible over the network or Internet, thus reducing network traffic. monitoring does not reveal patterns. Further complicating matters, the position of the seed can represent a shared secret. In one embodiment, the data-sniffable digits, eg, 27482567822552213, transmitted by the unscrambled portion of the data packet contain long digits, only a portion of which indicates the seed. For example, if the 3rd through 8th numbers indicate the seed, the actual seed is not the whole number 27482567822552213, but a partial number, namely 48256. This seed is then combined with a shared secret algorithm to generate a hidden number. The hidden number is then used to select a dynamically changing scrambling algorithm throughout the network.

Scrambling of data packets in an SDNP network is described in "Secure Dynamic Network And Protocol," filed Jul. 20, 2015, U.S. Application No. 14/803,869. Further details regarding scrambling data packets in last-mile communications are provided in this disclosure.

As mentioned above, the data traversing the network can be called "plaintext" even though it is scrambled. This is because the real data is present in the data packet, ie the data packet is not encrypted in ciphertext. In contrast, in ciphertext, a string containing the original data, whether scrambled or not, is turned into a meaningless string using an encryption key, and unless a decryption key is used, the It is not restored to its original plaintext form. The role of encryption in SDNP-based communications according to this disclosure is further described in the "Packet Encryption" section below.

As shown in FIG. 3, changing the data segment arrangement of a data packet during transmission over a network requires "rescrambling" of the packet. This process of packet re-scrambling returns the scrambled data to its unscrambled state before re-scrambling it with the new scrambling algorithm. Thus, the term "rescramble" as used herein means to unscramble a data packet and then re-scramble it, typically by another scrambling algorithm or method. This approach avoids the risk of data corruption that can arise from re-scrambling an already scrambled package and not knowing the data segment sequence needed to recover the original data. As shown, scrambled data packet 1008 is “rescrambled” after being initially scrambled by packet scrambling operation 926 . That is, scrambled data packet 1008 is first unscrambled by unscramble operation 928 using the inverse of the scrambling algorithm used to scramble the data, and then scrambled operation 926 unscrambles the previous is scrambled again using a different scrambling algorithm than that used in the scrambling operation 926 of . The resulting rescrambled data packet 1009 is different from the previous scrambled data packet 1008 . The rescrambling operation 1017 includes successive performances of unscrambling followed by scrambling, which is referred to herein as "US Rescrambling" (US stands for unscrambling • An abbreviation for unscrambling-scrambling). To recover the original data packet 930, a final packet unscrambling operation 928 requires performing the inverse of the algorithm used for the final rescrambling of the data packet.

According to the present invention, static and dynamic scrambling of data transforms unscrambled data into unintelligible nonsense (meaningless), reorders speech into unrecognizable noise, Text can be rearranged into nonsense, images can be converted to video snow, and code can be irreversibly scrambled. Scrambling alone can provide high security. And, in the SDNP law of the present disclosure, scrambling is one factor that can provide and ensure secure communications that escape hacking, cyber-attacks, cyber-piracy, and man-in-the-middle attacks. It's nothing more than

packet encryption

According to the present invention, secure communication over packet-switched networks relies on several factors for hacking prevention and segment reservation, one of which includes SDNP encryption. Derived from the Greek word meaning "hide," "secret," or "make invisible," as mentioned above, cryptography converts ordinary information or data, commonly called "plaintext," into secret information. Represents a means of converting to "ciphertext" in an unreadable format that is not readable unless using a . In modern communications, this secret information typically involves sharing one or more "keys" that are used to encrypt and decrypt data. This key typically contains an algorithmically generated pseudo-random number. Various literatures or texts discussing the advantages and disadvantages of various cryptographic techniques such as "Cryptonomicon" currently exist, for example, "Neal Stephenson (C) 1999", "The Code Book: The Science of Secrecy from Ancient Egypt". to Quantum Cryptography, by Simon Singh (C) 1999," Practical Cryptography, by Niels Ferguson (C) 2013," and "Cryptanalysis: A Study of Ciphers and Their Solution, first published in 1939."

Although the concept of encryption or cryptography is ancient and known to those skilled in the art, the application of cryptography in the secure dynamic networks and protocols of this disclosure is unique and independent of the client's own encryption. , facilitating both end-to-end encryption and single-hop node-to-node dynamic encryption for the network architecture itself. SDNP communication is designed around the fundamental precept that any statically encrypted file or message, no matter how complicated the encryption, will eventually be broken and its information stolen, given enough time. It is Although this assumption is actually incorrect, there is no need to prove or disprove this assumption. This is because waiting until a particular cryptographic method fails can result in unacceptable and irreversible consequential damage.

Instead, SDNP communication is based on the premise that all encrypted files have a limited "shelf life". This is because encrypted data is only kept secure for a finite period of time, and secret data is kept secure at predetermined intervals, ideally the shortest amount of time required to break the encryption on a state-of-the-art computer. Metaphorically, it must be dynamically re-encrypted much more frequently than an accurate estimate. For example, if a cryptographer speculates that a large server farm of cryptographic processors can break a given cipher in a year, then in SDNP communication, data packets are sent every second or every 100 milliseconds, i.e., breaking the cipher. Re-encrypt at intervals that are orders of magnitude shorter than the best techniques for breaking. Therefore, SDNP encryption is necessarily dynamic or time-varying and may also vary spatially, ie depending on the position of the communication node on the packet-switched network or map. Thus, the term "re-encryption" or "re-encryption method" refers to recovering a data packet and then encrypting it again using another encryption algorithm or method.

Thus, SDNP encryption involves the repeated and frequent conversion of data from unencrypted plaintext to ciphertext, altering the information to be unreadable and meaningless. Even if the data encryption of a given packet is miraculously broken, by using the SDNP dynamic encryption method, the next data packet will use a completely different encryption key or cipher, so that cipher To break it requires an entirely new effort. By limiting the content contained in each individually encrypted data packet, the potential for unauthorized access damage can be reduced. This is because the size of the data files contained in the broken data packets can be made too small to be meaningful or useful to cyber pirates. Furthermore, combining dynamic encryption with the SDNP scrambling method described above can greatly increase the security of communications. Even in unencrypted form, intercepted data files contain only small fragments of data, audio, or video scrambled such that the order of the data segments is meaningless and unreadable.

To avoid security concerns related to shelf life, SDNP encryption is dynamic and state dependent. As shown in FIG. 4A, an unencrypted data packet containing plaintext 930 (Plaintext) is processed by an encryption operation 1020 (Encryption Process), which converts an encrypted data packet containing ciphertext 1024 and 1025 (Ciphertext). A customized data packet is generated. For ciphertext 1024, plaintext 930 data packets are encrypted as a whole and data segments 1A-1F are treated as a single data file. On the other hand, for ciphertext 1025, data segments 1A-1F of plaintext 930 are encrypted separately and not mixed with other data segments. The first data segment 1A of plaintext is its corresponding first cipher text segment (a long string of characters beginning with "7$" shown for illustrative purposes, including long strings or numbers not shown) encrypted to Similarly, the plaintext second data segment 1B is encrypted into a second ciphertext segment (a long string beginning with "*^" shown for illustration purposes). The characters "7$" and "*^" denote the beginning of meaningless strings of symbols, numbers, alphabets, etc., and are used to indicate the length of certain data in plaintext sources or encrypted strings. neither limited nor implied.

The encryption operation 1020 (Encryption Process) can use any available algorithm, encryption scheme, or encryption method. Although the encryption algorithm presents a static equation, in one embodiment the encryption operation uses dynamic variables or "states", such as time 920, when performing encryption. An encryption key generator 1021 is also used to generate an encryption key (E-key) 1022 that depends on the state, such as the time 920 when encryption was performed. For example, the date and time of encryption is used as a numerical seed to generate an E-key that cannot be regenerated even if a hacker or the like discovers the encryption algorithm. Time 920 or other "state" is also used to select a particular algorithm from Encryption Algorithm List 1023 (Encryption Algorithms), which is a list of available encryption algorithms. In the data flow diagram, for convenience of illustration, this packet encryption operation and sequence is represented schematically or symbolically as encryption operation 1026 (Encryption). Throughout this disclosure, secure and encrypted data are also symbolically represented by padlocks. In particular, the padlock with the clock face on the top is a secure transmission mechanism, e.g., if not received within a certain time interval or by a certain time, the encrypted file will self-destruct and be lost forever. indicates that

FIG. 4B shows decryption operation 1031, which is the inverse operation of encryption operation 1020. FIG. This decryption operation 1031 reuses the state (time or other state) 920 that was used to generate the ciphertext 1024 (Ciphertext) and cooperates with the decryption key (D-key) 1030 generated by the decryption key generator 1021 . function to decrypt, ie, decrypt the file, producing unencrypted data including the original plaintext data packet 990 (Plaintext). The decryption operation 1031 (Decryption Process) uses the same state (time) 920 that was used when encrypting the packet, and uses the same state (time) 920 that was selected from the encryption algorithm list 1023 when encrypting. select and use the encryption algorithm again. Although the term "encryption" is used in encryption algorithm list 1023, this algorithm table is used to identify and select the inverse operation of encryption required to perform "decryption." be done. That is, encryption algorithm list 1023 contains information necessary for both encryption and decryption of data packets. This table 1023 can also be referred to as the "encryption/decryption" algorithm table 1023, as the two operations involve the same steps performed in reverse order. However, for the sake of clarity, this table refers only to the function of encryption and not its opposite function (decryption).

If the encryption algorithm selected for performing decryption operation 1031 does not match the inverse of the algorithm used for packet encryption operation 1020, state (time) 920 matches the time at encryption. If not, or if the D-key 1030 does not have a predetermined numerical relationship to the E-key 1022 used during encryption, then the decryption operation 1031 uses the original unencrypted data 990 will fail to restore and the packet data will be lost. In data flow diagrams, this packet decoding operation and sequence is represented schematically or symbolically as decoding operation 1032 for convenience of illustration.

As mentioned above, knowledge of encryption and the use of encryption and decryption keys in common encryption algorithms, such as symmetric public key encryption, RSA encryption, AES256 encryption among others, is common to those skilled in the art. Yes and publicly known. However, applying such known encryption methods to the SDNP communication system of the present disclosure, the hidden information, shared secrets, and time-dependent dynamic variables and State makes hacking or decryption difficult.

Thus, even in the unlikely event that a cyber-pirate possesses the computational power to ultimately break a robust encryption method, the cyber-pirate cannot obtain the private or private information necessary to perform the decryption operation. It lacks some information embedded in the SDNP network as a shared secret, and the cipher must be broken in less than a second before it can be changed. Further, all data packets traversing the SDNP network according to the present disclosure use different encryption methods determined based on unique keys and dynamic state. The combination of missing information, dynamic state, and the limited information content contained in any packet makes semantic data stolen from any data packet difficult and rewarding for cyber pirates. .

The encryption and decryption of data packets in an SDNP network is described in the aforementioned "Secure Dynamic Network And Protocol", U.S. Application No. 14/803,869, filed July 20, 2015. is described. Further details regarding cryptography of data packets in last mile communications are provided in this disclosure.

To intercept an entire text, video stream, or voice conversation and reconstruct a coherent data sequence, a cyber attacker must continuously break and decrypt not just one, but a series of thousands of SDNP packets. Must. Combining dynamic encryption with the methods for data packet scrambling described above makes the difficult task of serially hacking a series of SDNP packets even more difficult. As shown in FIG. 5, Ciphertext of Scrambled Data Packet 1024 is produced by a sequential combination of scrambling operation 926 and encryption operation 1026 . First, a scrambling operation 926 converts an un-scrambled plaintext data packet 990 into a scrambled plaintext data packet 1008 (Scrambled Plaintext), and then an encryption operation 1026 converts the scrambled data. Convert to cipher text 1024 of the packet. To repeat the encryption of the scrambled package, the above operations are performed in reverse order. First, a decoding operation 1032 decodes into a scrambled plaintext data packet 1035 (Scrambled Plaintext), and then an unscramble operation 928 recovers an unscrambled plaintext data packet 990 (Unscrambled Plaintext).

As shown, scrambling and encryption represent complementary techniques for achieving secure communication. The unencrypted scrambled data that traverses the network is called "plaintext" because there is real data in the data packets, ie the packets are not encrypted into ciphertext. An encrypted data packet, or ciphertext, is scrambled, converted into a nonsensical string using an encryption key, and cannot be restored to its original plaintext unless the corresponding decryption key is used. or containing unscrambled strings. Depending on the algorithm used, the encryption and decryption keys can be the same key or separate keys that are mathematically related by a predetermined mathematical relationship. Scrambling and encryption thus represent complementary techniques for achieving secure communication according to the present invention for SDNP communication.

The two methods of scrambling and encryption are combined with each other, except that the order in which the original data packets are recovered from the encrypted scrambled data packets is reversed from that in encryption. Even when used, they can be considered separate. For example, if data packet 990 is scrambled by scramble operation 926 and then encrypted by encryption operation 1026, the encrypted and scrambled data packet 1024 must be decrypted to recover the original data packet. After decoding by 1032 it is unscrambled by an unscrambling operation 928 . Mathematically, scrambling a string of bits or characters into its corresponding scrambled version by scrambling operation F and unscrambling by unscrambling operation F−1 is as follows: expressed.
F−1[F(A)]=A

Similarly, encrypting a sequence of plaintext into its corresponding ciphertext by encryption operation G and decrypting by decryption operation G-1 can be expressed as follows.

G−1[G(A)]=A
therefore,
F−1 {G−1 [G(F(A))]}=A
It can be expressed as. The order of each operation is reversed. Specifically, the encrypted and scrambled packet [G (F (A))] is decrypted [G−1] to obtain the scrambled plane This is because the text data packet F(A) is recovered and then the original data packet A is recovered by the unscrambling operation F-1 of the scrambled plaintext packet F(A).

Assuming a linear method is used, the order of each operation is reversible. For example, if a data packet is encrypted and then scrambled, the scrambled ciphertext is unscrambled and then decrypted to recover the original data packet. That is, it is represented as follows.
G−1 {F−1 [F(G(A))]}=A

Changing the order of operations makes it impossible to recover the original data packet. That is, if an encrypted and then scrambled data packet is decrypted before being unscrambled, the original data packet cannot be recovered. That is, it is represented as follows.
F−1{G−1[F(G(A))]}≠A

Similarly, if a scrambled and then encrypted packet is unscrambled before decryption, the original data packet cannot be recovered. That is, it is represented as follows.
G−1{F−1[G(F(A))]}≠A

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

Scrambling and encryption may occur in any order, but in one embodiment of the SDNP method according to the invention, encryption and decryption occur more frequently than scrambling during network transfer. Thus, encryption should be performed after scrambling and decryption should be performed after unscrambling, as shown in FIG. For convenience, the combination of packet scrambling operation 926 followed by encrypting operation 1026 is defined as scrambling and encrypting operation 1041 (Scramble & Encrypt). Also, the reverse combination of the decoding operation 1032 followed by the packet unscrambling operation 928 is defined as a decoding/unscrambling operation 1042 (Decrypt & Unscramble). These combined operations are used for static and dynamic SDNP communication according to the present invention.

One way static scrambling encryption is used to increase security in any implementation is to encrypt each data packet with a separate scrambling and/or encryption method (e.g., when each data packet enters a communication network). (including changing the state, seed, and/or key at time t1 of ).

However, another more robust method involves dynamically changing the encryption and/or scrambling of data packets as they traverse the network. To facilitate the data processing required to implement a fully dynamic version of SDNP, each packet passing through each communication node of a packet-switched communication network is "rescrambled" (i.e., unscrambled and subsequently scrambled). In order to "encrypt" and "re-encrypt (i.e. decryption followed by encryption)", the processes defined above need to be combined. As used herein, the terms "repacket" or "repacketization" are used regardless of whether the packet is decoded before unscrambled or unscrambled after being decoded. used to refer to the combination of "rescramble" and "re-encrypt". In any case, the unscrambling and decryption operations at one node must be performed in the reverse order in which the packet was scrambled and encrypted at the previous node. That is, if the previous node scrambled and then encrypted the packet, the current node must unscramble the packet after decrypting it. Generally, packets are scrambled and then encrypted when they leave the current node.

The "re-packetize" operation at the communication node is illustrated in FIG. A ciphertext data packet 1040 input to a communication node is first decoded by decoding operation 1032 and then unscrambled by unscrambling operation 928 . This restores an unscrambled plaintext data packet 990 (Unscrambled Plaintext (content)) containing the content of the original packet. If any information in a packet needs to be inspected, parsed, split or redirected, an unscrambled plaintext file is the perfect format for doing such operations. Plaintext data packet 990 is then re-scrambled by scrambling operation 926 and then re-encrypted by encryption operation 1026 to produce a new scrambled ciphertext data packet 1043 . In the repacketization operation of the ciphertext data packet 1040 input to the communication node, decryption, unscrambling, scrambling, and encryption are sequentially performed. This is referred to as the re-packetization operation 1045 (DUSE Re-Packet). In a dynamic secure network, the state (time), decryption key, and seed used to perform decryption operation 1032 and unscrambling operation 928 are used to perform scrambling operation 926 and encryption operation 1026. Preferably, the state (time), encryption key, and seed used are different.

Repacketization of data packets in an SDNP network is described in the aforementioned "Secure Dynamic Network And Protocol", U.S. Application No. 14/803,869, filed July 20, 2015. ing. Further details regarding repacketization of data packets in last mile communications are provided in this disclosure.

Mixing and splitting packets

Another key element of the dynamic secure communication network and protocol of the present disclosure is to split data packets into sub-packets and send them over multiple routes, combine and reassemble the sub-packets, and re-assemble complete data packets. It is a function to configure. The process of splitting data packet 1054 by splitting operation 1051 (Splitting (Un-mixing) Process) is shown in FIG. 7A. The split operation 1051 combines an algorithmic parse operation 1052 (Parse) with a junk operation 1053 (Junk) and has the ability to insert or remove non-data "junk" data segments. Like the junk DNA present in the human genome, junk data segments are inserted, and removed as necessary, by junk operations 1053 to extend or adjust the length of data packets. Junk operation 1053 is particularly important when the amount of data to fill a packet is insufficient. Also, the presence of junk data segments inserted into 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 that consists only of data (bits) that have no meaning. By introducing such junk bits into the stream of data packets, real data can be buried in a large number of meaningless bits.

The purpose of parse operation 1052 is to divide data packet 1054 into smaller data packets (eg, subpackets 1055 and 1056) for processing each component. Dividing the data packet 1054 into smaller portions may, for example, support multipath transmission, i.e., transmit the data packet over multiple separate paths, and separate subpackets using separate encryption methods. can provide unique advantages, such as facilitating encryption of

The splitting operation can use any algorithm, numerical method, or parsing method. The algorithm may be expressed in terms of static equations or may be represented by dynamic variables or numerical seeds or "states", e.g. A generated numeric seed 929 (this seed also depends on the state, such as the time 920 at the time of generation of the data packet) can be included. For example, if each datum is converted to a monotonically increasing unique number, then each seed 929 will be unique. Time 920 and seed 929 are used to identify the particular algorithm selected from the list of available methods, ie, Mixing Algorithms 1050 . The packet splitting operation involves the inverse of the mixing operation, using algorithms that are executed in exactly the opposite order as the algorithms used in the mixing operation to generate a particular packet. That is, all performed operations can be undone, but not all must be done in one step. For example, a scrambled and encrypted data packet may be decrypted but kept scrambled. By processing with splitting operation 1051 , unsplit data packet 1054 is converted into multiple data packets, eg, fixed length packets 1055 and 1056 . A parse operation 1052 is used to perform this operation algorithmically. In the dataflow diagram, this packet splitting operation 1051, which includes parse operation 1052 and junk operation 1053, is represented schematically or symbolically as splitting operation 1057 for convenience of illustration.

Thus, the term "splitting" as used herein includes parsing, which splits a packet into two or more packets or subpackets. Also, the term "splitting" refers to inserting junk packets or subpackets into or removing junk packets or subpackets from a "parsed" packet or subpacket. including.

FIG. 7B shows a packet mixing operation 1060 (Mixing Process) that is the inverse of the splitting operation and mixes a plurality of packets 1055 and 1056 to generate a mixed packet 1054 . As with the packet splitting operation, this packet mixing operation can use any algorithm, numerical method, or mixing method. The algorithm may be expressed in static equations or include dynamic variables or numerical seeds or "states" such as times 920 used to specify the conditions under which the input data packets 1055 and 1056 were generated. can be done. The blending operation used to generate the data packets can use a numeric seed 929 generated by seed generator 921 (this seed also depends on state such as time 920). Time 920 and seed 929 are used to identify the particular blending algorithm selected from the list of available blending methods, ie, blending algorithm 1050 . In the data flow diagram, this packet mixing operation 1060 is schematically or symbolically indicated as mixing operation 1061 for convenience of illustration.

According to the invention, packet mixing and packet splitting can be performed using any of a variety of possible algorithms. FIG. 8 shows three possible mixing techniques: Concatenation, Interleaved and Algorithmic. The concatenation method appends the data segment sequence of data packet 1056 to the end of data packet 1055 to produce mixed packet 1054 . In the interleaving method, the data segments of data packets 1055 and 1056 are mixed alternately, ie, staggered in the order 1A, 2A, 1B, 2B, to produce mixed packet 1056 . Another method used for packet mixing is an algorithmic method. In the illustrated example, the algorithm includes alternating mirror symmetry (interleaved mirror symmetry), placing the data segments in the order 1A, 2A, 1B, 2B, 1C, 2C in the first half of the mixed packet 1066. However, in the second half of the mixed packet 1066, they are arranged in the reverse order of the first half, that is, in the order of 2D, 1D, 2E, 1E, 2F, and 1F.

The application of data packet mixing and splitting in SDNP networks is described in US application Ser. No. 14/803,869, entitled "Secure Dynamic Communication Networks and Protocols," referenced above. FIG. 9A summarizes the SDNP functional elements including the function and its corresponding inverse process, i.e. the inverse function, and the dynamic components of the corresponding function, i.e. the state or time of each function when executed on a data packet. is. SDNP functions include scrambling operations including packet scrambling operation 926 and its inverse packet unscrambling operation 928; fragmentation operations including splitting operation 1057 and its inverse mixing operation 1061; junk insertion 1053A and junk removal. Impersonation operations including 1053B and encryption operations including encryption operation 1026 and decryption operation 1032 are included. All of these functions occur uniquely according to time or state variables 920 .

The application of data packet mixing and splitting, together with scrambling, unscrambling, encryption, decryption, and disguise in last-mile communications, collectively constitutes the SDNP last-mile security operation. This SDNP last-mile security operation is "directional". That is, the operations performed on all outgoing data packets are different than the operations performed on incoming data packets.

The SDNP last mile security operation is also symmetric and reversible to the last mile. That is, local security credential information such as keys, seeds, shared secrets, etc., unique to a particular last mile are used, and operations performed on the client device's transmitted data packets can be reversed at the SDNP gateway. This is generally performed by performing the inverse function, ie the mathematical inverse or all functional operations originally performed by the client device in reverse order. As such, the SDNP gateway is enabled to recover the original content in preparation for routing via the SDNP cloud. Similarly, for data packets arriving at the client device through last-mile zone-specific security credential information, the SDNP last-mile security operations performed on the client device cause the SDNP gateway to perform the reverse functions in reverse order. You can undo each security operation performed on In this way, it is possible to recover the original data of all incoming data packets at the client device.

The SDNP last mile security operation is dynamic. This, in turn, uses state-dependent conditions such as location and time to determine the parameters used at the time the data packet was prepared and the region, geography, or locale specific to a particular last mile. Localized, i.e. specific to a zone. Localization ensures that the same coding or the same security credential information are not used in the preparation of data packets executed on different last-mile connections in different regions. Also, these last mile security credentials will always be different than the credentials used in the SDNP cloud. Additionally, because it is dynamic, the state used to create the data packets is constantly changing, further obfuscating the actual security process performed on each data packet, rendering two data packets identical. disappears.

Dynamic scrambling, dynamic fragmentation, dynamic disguise, and and the application of dynamic encryption algorithms guarantee hyper-secure communications that cannot be achieved using simple static encryption schemes. The pervasive application of dynamic methods that are effective for just a few tens of milliseconds in duration not only make interpretation nearly impossible, but also allow hackers to decipher or interpret a data packet before another packet arrives. I don't have time to do it. In practice, SDNP last-mile security operations can be performed using software, firmware, hardware, dedicated security ICs, or any combination thereof.

Although a myriad of sequence combinations are possible, an example of SDNP last-mile security operations specifically for serial SDNP payloads used in single-route last-mile communications is shown in FIG. 9B. That is, in this figure, communication is made from client devices to a single SDNP gateway. This process involves a two-way sequence of operations for outgoing and incoming data packets. As shown in the top half of the figure, for outgoing data packets, the "data to be sent" is first scrambled by packet scrambling operation 926 and then disguised by inserting junk data 1053A. In some cases, the entire packet can consist entirely of junk data, further confusing data mining attempts by hackers.

These packets are then split into multiple fragments by split operation 1057 where parse operation 1052 is used and sent individually to encryption operation 1026 . Each fragment is then encrypted using a common or individual encryption key and the resulting ciphertext is placed in a serial SDNP payload shown as data packet 1199A. The packet is then formatted into an IP data packet or "IP packet ready" in preparation for communication to the last link and last mile. All operations performed are dynamic and occur at a particular state 920A at a particular time or during execution of the security process.

As shown in the bottom half of the figure, for incoming data packets, the incoming data from the last link containing the serial SDNP payload 1199B, i.e. the incoming data from "IP Packet Recognition", is first decrypted in pieces or as a whole. It is decrypted by operation 1032 and then recovered to the actual data stream by mixing operation 1061 . Junk is then removed from the data packet, i.e., junk data is removed from the data packet by the remove junk operation 1053B, after which the "received data" is recovered by the packet unscrambling operation 928. FIG. All operations performed on incoming data packets should use the state 920B that was used when the data packet was created at the SDNP gateway. That is, it contains information about a particular state 920B at a particular time or packet generation. This state information is either sent via a separate communication by the signaling server, or in incoming data packets as plaintext or static ciphertext, i.e. with the decryption key already known in the SDNP last-mile security operation. . However, the details of state 920B cannot be encrypted using a key that requires the state information contained in state 920B. This is because you will not be able to open the code and use your own security credentials.

FIG. 9C shows an example of SDNP last-mile security operations for parallel SDNP payloads specifically used in multi-route last-mile communications. That is, in this figure, a client device communicates to multiple SDNP gateways. Similar to the single route described above, this process involves a two-way sequence of operations for outgoing and incoming data packets. As shown at the top of the figure, for outgoing data packets, the "data to be sent" is first scrambled by packet scramble operation 926 and then disguised by inserting junk data 1053C. In some cases, the entire packet can consist entirely of junk data, further confusing data mining attempts by hackers.

These packets are then split into multiple sub-packets by splitting operation 1057 where parsing operation 1052 is used and sent individually to encryption operation 1026 . Each fragment is then encrypted using a common or individual encryption key, and the resulting ciphertext is placed into multiple SDNP payloads shown as data packets 1199C, 1199D, 1199E. The packets are then formatted into separate, distinguishable IP data packets, or "IP packet ready", in preparation for communication to the last link and last mile. All operations performed are dynamic and occur at a particular state 920C at a particular time or during execution of the security process.

As shown in the lower part of the figure, for incoming data packets, the incoming data from the last link containing the parallel SDNP payloads 1199F, 1199G, 1199H, i.e. the incoming data from "IP Packet Recognition", is first processed by decryption operation 1032. It is piecewise decoded and then recovered to the actual data stream by a blending operation 1061 . Junk is then removed from the data packet, ie, the junk data is removed from the data packet using the remove junk operation 1053D, after which the "received data" is recovered by the packet unscrambling operation 928. All operations performed on an incoming data packet should use the state 920D that was used when the data packet was created at the SDNP gateway. That is, it contains information about a particular state 920D at a particular time or packet generation. This state information is sent either via a separate communication by the signaling server or as plaintext or static ciphertext in incoming data packets, i.e. with the decryption key already known in the SDNP last mile security operation. .

SDNP last-mile security operations do not require the use of the same algorithms or methods for both incoming and outgoing data packets. As shown in FIG. 9D, outgoing data packets use the SDNP last mile security operation 1190A and incoming data packets use the SDNP last mile security operation 1190B. As shown in the upper half of the diagram, outgoing data packets contain data representing any combination of real-time data sources from transducers or sensors, or contain files created prior to communication. For example, sound 1198A converted to electrical signals by microphone 1180 and video signals from camera 1181 are converted to equivalent digital formats by audio-video CODEC 1182A. The formats created generally involve standard formats such as png, pic, mpeg, mov, etc. that are interpretable and interoperable by standard devices according to the presentation layer, OSI Layer 6. Using a standard audio-video format eliminates the need to send a unique code between the source and destination addresses to open the file.

The digital output of audio-video CODEC 1182A is then mixed using content mixer 1184 with text data from virtual keyboard 1183 (a keypad implemented with a touch screen) and data file 1179A. From this mixer the data file is then sent to the SDNP Last Mile Security operation 1190A and the SDNP header information is provided to the IP packet preparation operation 1191A to identify and label the real-time data packets from the static file. SDNP last-mile security operation 1190A then passes the secure data packet to IP packet preparation operation 1191A, which in turn embeds the SDNP payload into the IP data packet according to the routing instructions received at SDNP signaling server 1603. . The data packets are delivered in multiple IP packets for multi-route last-mile communication, or concatenated into serial data strings and embedded into one or more serial data packets for single-route last-mile communication. . These packets are then passed to client PHY operation 1192A to complete the IP data packets with added layer 1 and layer 2 data.

In the reverse operation, shown in the lower half of the diagram, incoming data from the last link received at client PHY 1192B is passed to IP packet recognition operation 1191B, which converts the incoming data into a valid message or an unknown malicious message. Identified as a 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 IP packet recognition operation 1191B. Anthropomorphically, IP packet recognition operation 1191B expects and even predicts valid incoming data packets. Unexpected data packets without proper identification are discarded and not further opened or processed. In this way, a hacker cannot impersonate himself and send valid data to any SDNP node without registering his identity in the SDNP cloud.

IP packet recognition operation 1191B passes valid data packets to SDNP last mile security operation 1190B. This performs all the operations necessary to reconstruct the actual content of the data packet, i.e. the data that contains the continuously adjusted combination of video, audio, text and data files. Content de-mux 1193, which is a demultiplexer that undoes the blending operations used in creating data packets (e.g. splitting serial data files created by blending operations 1184 performed on other callers' phones). is used to separate different file types. The output of content de-mux 1193 includes text displayed in messenger window 1196, data file 1179A, and real-time data sent to audio-video CODEC 1182B. Audio-Video CODEC 1182B converts the digital presentation layer data into live video images 1195 or sounds 1198B through speakers 1194 .

For last-mile data transfer, the data needs to be embedded or wrapped in multiple layers in a manner similar to a babushka, a Russian nesting doll, as shown in FIG. 9E. Thus, SDNP payload 438 represents transport payload 437 . This constitutes IP payload 435 along with transport header 436 . The combination of IP payload 435 and IP header 434 represents the IP datagram corresponding to MAC payload 432 . Wrapping MAC payload 432 within MAC header 431 and MAC footer 433 produces a MAC "frame" that corresponds to physical layer 490 and is also called PHY layer 1 content. It consists of physical media such as electrical signals, light, radio waves and microwaves.

In SDNP routing, the Layer 2 MAC header 431 describes the last link MAC connection, ie the connection between the client device and the first device of the last mile link. Layer 3 headers 434 specify endpoints for routing via the last mile using the source and destination addresses of the client device and the SDNP gateway. However, since the last mile is not part of the SDNP cloud, the exact route data packets that take over the last mile cannot be explicitly specified or controlled. For SDNP last-mile communications, Layer 4 transport header 436 specifies that UDP is used for the SDNP real-time payload and the ad-hoc assigned SDNP port address to be used in each packet. This address changes dynamically to thwart port scanning (port inquiry) cyberattack strategies.

The last-mile IP packet payload, the SDNP payload 438, includes an SDNP preamble 1198 containing zone information, keys, and seeds, and an SDNP data field 1199A, which is a serial string of multiple segments of independently encrypted ciphertext. is included. The decrypted format of the ciphertext includes plaintext files 1197A, 1997B, and 1197C, each with its own unique SDNP header and corresponding data files data 91, data 92, and data 93. Each subheader contains information including tag, zip, address, urgency, and QoS data as appropriate.

The role of the SDNP preamble and header depends on the commands and control methods used. In three-way last-mile communication, the signaling server instructs the client device and the SDNP gateway how to communicate with each other to make a call, send a file, or open a session. Therefore, instructions are communicated to both devices using command and control data packets in a TCP transfer before the media data packets are sent. Therefore, the minimal data required for last-mile communication between the client and the SDNP gateway is the tag or address used to identify incoming packets. In some cases, for example, if the signaling server is unreachable, another embodiment is that the SDNP data packet carries additional data in its preamble and packet header.

The data packet and accompanying table 1177 shown in FIG. 9F illustrate one exemplary format used to carry SDNP information within SDNP payload 438. FIG. A data packet includes an SDNP preamble 1198 and 1-8 data field headers 1178X with a corresponding data field "data X field". In each data field such as "data 1 field", "data 2 field", the corresponding header Hdr 1, Hdr 2, etc. is preceded, and communique contents such as voice, text, video, photo, movie, file, etc. are transmitted. . The numeric value of the data field varies from 1 to 8, ie binary 0001 to binary 1111, as determined by the long field # of 4b. The length of the SDNP Preamble 1198 and SDNP Payload 438 are affected by the Field # specification. If only one field is selected, ie field #=0001 binary, then SDNP preamble 1198 contains only L Fld 1 (L Fld 2 through L Fld 8 are excluded) and SDNP payload 438 contains Only the Hdr 1 and Data 1 fields are included. If a maximum of 8 fields is selected, i.e., Field #=1111 Binary, the SDNP preamble 1198 contains 8 length-specific L fields 1 through L fields 8, and the SDNP payload 438 contains 8 data fields and 8 data fields. The headers are included in order as Hdr 1, Data 1 field, Hdr 2, Data 2 field...Hdr 8, Data 8 field. As shown, the SDNP preamble 1198 includes field length specifications L Fld 1, L Fld 2, L Fld 8. The small gap between L Fld 2 and L Fld 8 represents a sequence continuation and not a data gap.

Each data field length, designated by L Fld X, varies from zero or 0B (null data field) to FFFF or a maximum of 65,535B hexadecimal. For practical reasons in Ethernet compatibility, it is preferable to limit the maximum data packet length of any one field to 1500B or 05DC hex, and the total length of all data fields to 9000B or 2328 hex. must not exceed the jumbo packet size of The length specified for each data field may vary individually. For a field length of zero, eg, L Fld 8=0000 hex, the corresponding data 8 field is deleted, but the corresponding header Hdr 8 is not deleted. Headers are removed only by specifying the field #.

According to this SDNP protocol, the distribution of content across various data fields is very flexible. Data destined for a single destination may be contained in a single data field, or may be split into multiple data fields and merged with junk data for disguise purposes. Each data field may have a different size. It is also possible to include a data field containing pure junk data, or generate an entire data packet containing only junk data. However, for efficient packet routing, data targeting different destinations must be split into separate data fields, each with its own header.

The SDNP packet format is applicable for end-to-end transport between multiple clouds and zones, such as SDNP clouds, or across SDNP networks, including last-mile communications. The content of the SDNP data packet changes as it passes through the network, but the format of the SDNP packet does not change. Since this format contains minimal data overhead, the SDNP data packet format is equally applicable to large payload or time-critical real-time communications. The packet format originates from the cloud for bi-directional data flow, i.e. data flow from the last mile to the SDNP gateway and data flow to the SDNP cloud or transfer across the last mile to the destination client device. It can be applied to the delivery of data packets leaving an SDNP gateway through

In operation, the direction of SDNP data routing is determined by the network layer 3 source and destination addresses described within the IP header 434 of FIG. 9E. Each packet is loaded with a source and destination address when the packet is prepared by a media node for transmission to the next media node on the route. In tri-channel communication, the SDNP or IP address of the packet's destination is delivered from the signaling server to the media node as a command and control (C&C) packet prior to preparation of the outgoing packet. In general, a signaling server can send C&C indications to all nodes in the communication path, including both the sending (sender) device and the destination (receiver) device. If only single-channel communication is available, eg on links with long propagation delays, the signaling server cannot give advance warning to the media nodes of incoming packets or their handling. In this case, the routing address is carried within the incoming data packet in the SDNP payload 438 . In such cases, the media server follows default instructions regarding how to process incoming packets using the data fields contained in incoming SDNP packets, such as routing, state information, and security credential information.

The payload 438 consists of two parts, a readable part containing the preamble 1198 and an unreadable part 1199a containing the data in "concealed format". Any number of concealment techniques, such as encryption, scrambling, and possibly junk data insertion, are used for the contents of this packet to hide its contents. To extract usable content 1197a, 1997b, and 1197c, the concealment method must be undone. These packets contain the destination address of future outgoing packets. The address can exist in unconcealed or decrypted format only for a short time until the next packet is prepared and encrypted.

As described, the SDNP preamble 1198 contains information related to the entire packet. Aside from the data field specification, Figure 9F shows an SDNP preamble 1198 that also includes the SDNP zone in which the SDNP packet is created (eg, zone U1, two numeric seeds, and two keys, etc.). These keys and seeds can be used as zone-specific security credentials in the scrambling/unscrambling, junk insertion/removal, mixing/splitting, encryption/decryption processes. Seeds and keys are used either as the exclusive means of delivering the security credential information needed to open and read data fields, or as command and control packets sent from signaling servers to client devices and SDNP gateways, i.e. communique content. can be used in conjunction with a network of computers that do not participate in the transmission of media in media packets.

Because seeds and keys consist only of part of the security credential information, and the data lacks the information necessary to use them, seeds and keys are made public, i.e., in an unencrypted format. can be safely delivered. Other pieces of missing security credential information, if pre-sent in separate data packets, or algorithmic shared secrets, lookup tables, code that is not delivered over the network and is not part of the message may be included. A cryptographic key can be a symmetric key, where both the sender and receiver hold the key, or the public, including the sender, can access the cryptographic key but only the receiver, i.e., the party who generated the cryptographic key. May be the public key holding the decryption key. Further, all security credential information is restricted to a specific security zone, such as U1, and is restricted to a state that is dynamic and expires if not used for a specific period or specified time. If the Seed and Key data fields are not used as security credential information, for example when the signaling server specifically instructs the SDNP device about security operations, then these fields contain bogus numeric values that appear as cryptographic keys. is entered. This leaves cyber attackers wasting time analyzing decoy security keys.

In last-mile communication, intermediate routers between the client device and the SDNP gateway do not process, interpret, or open forwarded data packets. This is because they are not part of the SDNP network and do not have the ability to query or interpret the SDNP packet data contained within. Instead, all security operations are performed exclusively at two endpoints: the SDNP client and the SDNP gateway. This is because only these devices act as SDNP communication nodes. The last mile communication is hyper-secure over the last mile because the SDNP protocol is dynamically executed at each endpoint. If the other caller is also running SDNP software, that caller's last mile is also protected by the aforementioned SDNP method, ensuring hyper-secure communication between callers "end-to-end".

However, if the end device is not an SDNP client, enable the router closest to the caller, the last link router, with SDNP firmware. In this case, SDNP is not enabled, but the last link can be reasonably protected by special functions performed in routers that are SDNP enabled. This alternative last link security method is described in more detail in subsequent sections of this disclosure and will not be detailed in this section. The methods described are applicable to protecting last link communications, but are insufficient to protect other parts of the last mile.

As shown in Figure 9F, each SDNP data field is accompanied by an SDNP data field header 1178X. It contains information that is uniquely applicable to the data field with which it is associated, but is useless to other data fields. Specifically, in the disclosed embodiment, each header includes a data type field that describes the type of data contained within the associated data field, a data type field that is used to identify a particular data field and its destination. a destination address field used to transfer zone information from one zone to another zone, urgency, and delivery information. As shown, each SDNP data payload 438 includes one SDNP preamble 1198 and one or more SDNP data field headers 1178x and corresponding datax fields. x indicates the number of individual payloads. This ranges from 5 to 50 depending on payload size and urgency.

Although most of the information described is provided from signaling servers to SDNP clients and SDNP gateways, there is one basic component that is always transmitted in last-mile data packets. This is the "address field" or tag required to identify the data packet. A field called the Destination Address (abbreviated as "Dest Addr" in the figure) in the SDNP payload may contain a unique identifier sufficient to distinguish the ID of one data field from another. Its purpose is similar to the functionality of barcodes used for tagging and tracking packages at airports and boxes delivered by courier services. Address types include, for example, numeric tags, SDNP zip, IPv4 or IPv6 addresses, NAT addresses, and even POTS plain phone numbers, so that identifiers are unique to prevent conflicts in identifying data packets. good too. The size of the destination address field depends on the type of address type selected.

To maintain packet anonymity during routing, it is recommended to use a confidential code such as the SDNP Zip Code as the SDNP destination address instead of using the actual phone number or IP address. In operation, each time a data packet arrives at the SDNP gateway from an SDNP client, the SDNP payload is decoded and then an examination of each data field header is performed for identification of the destination address. The data header cannot be inspected until the data packet is decrypted or processed to undo the concealment method used when the packet was created. For dual-channel or tri-channel communication, the signaling server 1603 informs the SDNP gateway in advance of the expected arrival of data packets and their corresponding identification markings and security credential information, as shown in FIG. 9G. Therefore, when a data packet 438A containing a last-mile communication sent from an SDNP client is received at the SDNP gateway, an SDNP last-mile security operation 1190D is performed at the gateway to convert the SDNP payload from ciphertext to plaintext data packet 438B. executed. Security operations are the process of modifying outgoing data packets to conceal their contents, and the process of modifying incoming data packets to reveal their contents. Specifically, the security operations performed on incoming data packets are decryption to remove encryption, unscrambling to undo scrambling, de-junk removal to remove inserted junk, mixing to undo disassembly, etc. , is used to recover the content by undoing the concealment operations performed before the transfer. These processes are executed according to the state and zone at which the data packet was created. For outgoing data packets, security operations include concealing the contents of data packets by performing encryption, scrambling, junk insertion, and packet fragmentation according to the state and zone in which the data packet was created prior to transmission. included. The unencrypted seed and key data fields of data packet 438A can optionally be ignored or used along with signaling server information to decrypt the ciphertext. The resulting manipulation displays data field 1 and an associated data field header 117D labeled Hdr 1 that contains the data field's destination address, data type, urgency, and delivery information. In such a case, the destination address is not the routing address, but simply the SDNP Zip, a tag used to identify the packet, which is part of a particular conversation.

Once a particular data field containing an identified destination field is found, such as an SDNP Zip Code that matches instructions from Signaling Server 1603, the data field is extracted and optionally mixed with other relevant content by mixer 1184Z to form an SDNP packet Prepare operation 1191Z rewraps it into a new IP or SDNP datagram and delivers it to the next destination. A new data packet destined for the cloud includes an SDNP header 434Z containing the destination and data content of the new packet, the SDNP payload 435Z. Destinations supplied from the signaling server 1603 to the gateway media node as IP addresses or SDNP addresses can include another SDNP server acting as an SDNP cloud node or include last mile communication to another SDNP client. . For such tri-channel communications, the destination address is not really an address, but a means of identifying the packet, the next destination of which is already known by the SDNP gateway. If the packet's destination is SDNP cloud routing, then the data packet is processed by SDNP cloud security operation 1190Z according to the cloud's Z1 security credential information rather than the U1 authentication information used in the last mile.

For single-channel communication, as shown in FIG. 9H, (i) there is no signaling server working in the local network, (ii) the signaling server is temporarily offline, or (iii) the signaling server is busy. , there is no notification from the signaling server to the SDNP gateway prior to the impending arrival of the data packet and its data fields, either because the packet cannot be preemptively routed in time. In such a case, the data packet 438A from the SDNP client conveys the required security credential information zone U1, Seed1, Seed2, Key1, Key2, and the SDNP last-mile security operation 1190D converts the ciphertext data packet 438A into plain text. It must be converted to text data packet 438B. The standard SDNP data packet format reserves these data fields even if the contents of the fields are not required by a particular media node. For example, if the Key 2 field is not used in the particular concealment process used to create the data packet, the data in that field is meaningless and will not be used by the destination node. Nevertheless, the format of all SDNP data packets is homogeneous, as data packets reserve the same number of bytes for used or unused fields. Once the ciphertext of data packet 438A is decrypted, the SDNP gateway extracts the contents of the data packet data 1 field and associated Hdr 1 field header 1178D from plaintext data packet 438B. For two reasons, firstly to confirm that the incoming packet is expected in tri-channel communication, and secondly to generate a new SDNP address, this data packet is sent to Hdr 1 by IP packet recognition process 1191D. The A type and destination address data fields from field header 1178D are combined. This new SDNP address is combined with the D-type, urgency, and delivery fields and processed by prepare SDNP packet operation 1191Z to create an SDNP header 434Z in the outgoing data packet. The content of the Data 1 field is also extracted from the incoming plaintext data packet 438B, and that content is optionally mixed with 1184Z and other outgoing content to create outgoing SDNP payload 435Z. The packet is then processed by SDNP Cloud Security 1190Z in preparation for transfer. Thus, multiple functions are performed in the address field to identify incoming data packets and, if necessary, provide a forwarding address.

If a data packet is received at a media node without first receiving instructions from the signaling server, the media node will revert to its default instructions on how to process incoming data packets and prepare outgoing data packets. . If the media node has no instructions on how to handle unacknowledged incoming packets, the data packet is discarded. If the media node has not enabled instructions on how to handle unidentified packets, then the media node first verifies that the packet is a valid SDNP packet according to the security credential information and acts accordingly. be done. However, if the sender cannot be determined, for example because the encryption code, seed, or source address is invalid, the packet is discarded as fraudulent.

In FIG. 9F, the packet fields labeled "Field Zone" indicate the zone in which the particular field was created. That is, whether past encryption or scrambling has been performed, for example in the U1 or U2 zone settings. For nested security protocols or other nested concealment methods, unscrambling, decrypting, or recovering concealment of data packets requires additional information such as key, seed, time, or state. necessary. In this case, packet fields labeled "fields other" can be used to carry field-specific information. Generally, these fields are not used except for nested security protocols where the encrypted data field is then scrambled or re-encrypted. Care must be taken when using nested security methods to perform data recovery in the exact reverse order of data packet preparation. Otherwise, your content will be lost forever.

Context-specific routing is facilitated when packet fields labeled "data type" are used to request real-time communication from data packets containing time-sensitive information such as video or live video. However, it is possible to distinguish between data, recordings, texts and computer files, namely between real-time and non-real-time routing. Data types include voice, text, real-time video, data, software, and more.

Together, the packet fields labeled "Urgency" and "Delivery" are used to determine how best to route data for a particular data field. Urgency includes snail, normal, priority, and urgent categories. The delivery usually includes QoS markers that indicate redundant, special, and VIP categories. In one embodiment of the invention, the binary sizes of the various data fields are selected to minimize the bandwidth required for communication, as shown in table 1177. For example, as shown, data packets can range from 0 to 200B, and the data field can contain 8 packets of 200B, so an SDNP packet can carry 1,600B of data.

Both Figures 9G and 9H show the case where a data packet in zone U1 is sent from the client device to the gateway node via the last mile. The incoming data packet is then processed by the gateway node and the zone U1 security credential information is used to undo the last mile security and concealment methods that have been performed. The gateway node then mixes the contents of the packet with the contents of other packets in a mixing process 1184Z to create a new packet that uses the security credential information of zone Z1 and is bound for transfer over the SDNP cloud.

When a data packet is received from a cloud (including another gateway) at an SDNP gateway, for example when it is sent from the SDNP cloud to a client's phone (recipient), and the data packet is sent to the client device. process is used. As shown in FIG. 9I, for dual-channel or tri-channel communication, the signaling server 2603 informs the SDNP gateway in advance of the expected arrival of data packets from the cloud and corresponding identification markings and security credential information. Therefore, when a data packet 2438A from the SDNP cloud is received at the SDNP gateway, an SDNP cloud security operation 2190D is performed at the gateway to convert the SDNP payload from ciphertext to plaintext data packet 2438B. The unencrypted seed and key data fields of data packet 2438A can optionally be ignored or used along with signaling server information to decrypt the ciphertext. The use of the data field depends on the algorithm used in concealing the payload of the packet. For example, if encryption is not used, fields containing encryption keys are ignored.

Manipulation of the results extracts a number of data fields. In subsequent operations, these data fields are split by split content operation 2184Z, and specific content is extracted by recognize operation 2191D, including data field 1 and associated data field header 2117D labeled Hdr 1. 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 new IP or SDNP datagrams 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 containing the new packet's destination (IP address corresponding to the personal phone number) and data content, SDNP payload 2435Z. Outgoing packets are processed by the SDNP last mile security operation 2190Z according to the last mile U1 security credential information, not the Z1 authentication information used in the cloud.

If the signaling server is not available, i.e. for single-channel communication, the incoming data packets should be processed at the media node according to the instructions previously delivered as default instructions. In such cases, the incoming data packet is tagged with the criteria necessary to verify that the sender is a valid SDNP client (such as an authentication code previously delivered as an SDNP Zip code or a pre-determined shared secret). is used. 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 exemplary and are not intended to limit the processing and routing of data packets to any 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 associated, they are not the same thing. The term security, as used in communications, can be viewed as "discipline to prevent unauthorized access to communicated data in a recognizable format". However, security does not apply where individuals or institutions have the right to access or monitor communications. Privacy is defined as "the state or condition of not being observed or disturbed by others and out of the public eye". In legal terms, privacy is defined as an individual's right to control access to his or her personal information.

In communications, individual privacy rights in voice calls, video, text, email, personal messaging, etc. vary widely from country to country. Their role in complying with applicable government regulations in providing access to communications in a legally valid manner is described in subsequent sections. That aside, an ideal network and communication system would ensure that communications are hack-proof, i.e., completely secure, and that all communications are restricted to those with a right to know, i.e., private. There is a need.

The last mile of the network and the connected devices should be carefully considered when evaluating the privacy and security capabilities of the network. Security credentials used to establish information access rights often dictate network security and privacy in the last mile and connected devices. In other words, the last mile is the most vulnerable part. Four possible combinations in the communication network should be considered.
・Secure and private network. From an individual's point of view, this represents ideal network performance and ensures both information security and individual privacy. At the extreme, a truly secure private network is one in which no individual, government, agency, or enterprise intercepts meaningful communications, and is concerned with personal behavior, conduct, contacts and associates, personal preferences, activities, etc. It means that private data cannot be retrieved. While advocates of the right to privacy view the ideal secure private network as the gold standard for confidential communications, governments, security organizations, and corporations question the absolute autonomy of communications, which allows individuals to will be able to engage in criminal and terrorism completely covertly and safely.
• Non-secure networks that lack privacy. Insecure networks without privacy provisions (such as today's Internet OTT operators) pose significant risks to individuals, groups, clubs, businesses, or governments using the communication channel. Cyber hackers have easy access to your calls and data, so bad actors can use this information for any purpose. By hijacking non-secure communication channels, pranksters and spammers can wreak havoc, flood networks with spam, launch denial-of-service attacks, or deploy harmful mischief. Ideologues, political activists, and religious cults can use unsecured communication channels to leak classified information (hundreds of thousands of The famous fictional film "The Fifth Estate" (DreamWorks(c ) 2013)). Economically motivated organized crime and mafia cybercriminals focus their attacks on financial crimes such as theft, money diversion, fraud, identity theft, money laundering, extortion, extortion, and other felonies. Monitoring non-secure communications can help those involved in extortion and intimidation, such as drug cartels, gangsters, and terrorists, plan and carry out violent crimes such as assaults, kidnappings, murders, bombings, or acts of terrorism. The purpose is to track the location, movement and behavior of competitors, adversaries and targeted victims. Finally, in the case of personal cyberattacks, unsecured communications can be used to compromise databases containing personal information such as social security numbers, passports, banking information, credit card information, medical records, and other sensitive personal information. can be hacked into
• A secure network that lacks privacy. An example of a secure network that lacks privacy is an IT (Information Technology) manager or security department monitoring all corporate communications to ensure that inappropriate or illegal communications do not occur on the corporate network. Includes corporate accounts with rights and privileges. Although networks are protected from hackers and cybercriminals, communications on these networks are not private and include unauthorized personal use of corporate communications infrastructure, corporate espionage, breach of non-disclosure agreements, and unauthorized disclosure of intellectual property (such as unauthorized disclosure of intellectual property). IP leaks), sexual harassment, Regulation FD (reg. FD) violations, insider trading, FCPA violations, corruption, bribery, fraud, financial reporting violations, securities violations, and other fraud may be monitored by authorized entities. In the case of corporate communications, the company informs individuals who join the company that their communications are not private and that the company's phone calls, emails, texts, personal messaging, SMS, and other communications, etc. may be monitored. do. Such communiqués may be presented as evidence in court in the event of legal proceedings, whether civil or criminal, even if personal information is mixed with company information. Essentially, when corporate employees use corporate communications, devices, and networks for personal use, all information (except in the case of attorney-client privilege) becomes an open target for attack, It is no longer considered private. For this and other reasons, the mixed use of personal messengers such as Line and KakaoTalk for business and personal use does not allow employees to exercise their privacy rights to prevent inspection of text chats, photos, and files. especially problematic.
• Semi-private, non-secure network. A semi-private, insecure network is one in which the network that transmits data can be hacked, such as by eavesdropping, but still allows private transactions, regardless of lack of security, if certain conditions are met. Refers to a network that can run secretly. In this case, privacy is established by verifying the identity of the caller by various means using a shared secret that a hacker cannot discover by intercepting the call. A common example of private, non-secure communication is voice banking. For example, "Your credit card paid for the restaurant you ate at last night. In which city did you dine?" Verify the caller's identity by asking the caller constantly changing questions that the fraudster has a low probability of knowing the answer, such as. Another example question is, "What is the last name of your favorite teacher in elementary school?" In order for these identity verification methods to work well, either the bank has access to non-public information (such as credit card statements) or the bank and its clients have access to electronic information at the time the client opens an account. Shared secrets should be established face-to-face rather than face-to-face. Once the caller's identity is verified, the client can instruct the agency to perform certain operations, which will not bring any profit to cybercriminals. For example, a caller may issue instructions such as "Move $10,000 from a savings account to a checking account." However, if the transfer is going to another bank, even stricter verification needs to be done to ensure the client's privacy. In any event, ensuring privacy, whether electronic or aural, depends on meeting the condition that the communication does not reveal shared secrets. If this condition is not met, all privacy is lost and the account can be compromised. Therefore, authenticated communication on a non-secure line refers to semi-private, which means conditional privacy. Another example or semi-private communication over a non-secure network is performed using a security token, a device issued by a bank and owned only by the client. A pseudo-random number generated by the device is communicated to a bank representative who verifies that the number matches the bank's approved number. Since the numbers are eight or more digits, the chances of guessing the correct code on the first attempt are very low. If an incorrect token number is provided, the call will be terminated, the account frozen, and an alert sent to the Fraud Response Department to investigate. In this case, the importance of ensuring privacy in an insecure network depends on being able to communicate confidential information such as account numbers, PINs, credit card information without verbally revealing it. That is, the communication becomes semi-private.

Identity verification and AAA

The concepts of security and privacy rely on accurate and reliable identity verification, ie, that the originator is who he claims to be. Identity verification, also called "authentication," is critical to effective use of data and communications and to prevent illegal or unauthorized access. Reliable identity verification is important in national security, law enforcement, intellectual property ownership, corporate and personal rights. Examples of the importance of ID verification include the following.
・In national security, it is important to perform identity verification of callers to track the identities of criminals, spies, terrorists, drug traffickers, and those who seek to leak national secrets or threaten national security. becomes. This is equally important in identifying individuals who are authorized to access, read, or transmit confidential, confidential, or top-secret communiqués, data, or files.
For law enforcement, caller identity verification to identify individuals or organizations involved in criminal acts such as robbery, arson, drug trafficking, smuggling, prostitution and human trafficking, robbery, blackmail, and other felonies. important to do. This also helps identify individuals authorized by law enforcement agencies, such as police officers, firefighters, paramedics, park rangers, air force officers, TSA and airport security personnel, port officials, customs officers, coast guard personnel, etc. is equally important.
For intellectual property owners such as movie studios, to identify individuals, organizations and entities involved in piracy and unauthorized distribution of copyrighted material such as music, films, books and videos; Secondly, it is important to verify the identity of the caller. This is equally important in ensuring valid and lawful distribution of intellectual property and copyrighted material.
For businesses, tracking the intentional or accidental disclosure of material non-public information, individuals engaged in commercial espionage or unlawful disclosure of intellectual property, and other crimes such as fraud or personal use of corporate communications; It is important to conduct employee identity verification to identify individuals who commit crimes. This is equally important in ascertaining the identities of those who have access to confidential company information, and the specific types of data they have access to. For example, no system should allow a company's engineering department to access the marketing department's personnel records in order to view the salaries of marketing staff.
• It is important for individuals to perform identity verification to ensure the 'privacy' of the caller by confirming that the person they are communicating with is not a fraudster.

Therefore, the role of identity verification is to verify a person's identity, ie, to authenticate that they are who they claim to be, and to identify, block, and ultimately catch those who falsify their identities. The first "A" in the "triple A security model" or "AAA" which stands for "Authentication, Authorization, Administration" refers to Authentication. Numerous methods such as PIN codes, passwords, fingerprints, tokens, query-response schemes, etc., can be used to confirm an individual's identity and verify the existence of an account in the system.

Once authenticated, a valid user's identity is used to determine access rights and privileges to communiques, data, files, systems, and the like. These privileges and access rights are collectively referred to as the user's "Authorization" granted by the system. That is, only authorized users can access authorized communications, data, files, and system functions. Authorization is therefore synonymous with "privilege" or "access right".

The third "A" in AAA stands for "Administration". Management is the recording of authorized access to networks and files, and the monitoring and reporting of unauthorized access attempts to networks, files, and systems, for purposes such as pay-per-use management. Management is also important in tracking changes to security credentials, PINs, passwords, etc. required for authentication operations.

A network's ability to perform AAA verification is paramount in ensuring privacy and preventing unauthorized use of the network by unauthorized users and network operators. Any network that cannot verify a user's identity can be exploited for illegal operations. Since there is no means of verifying caller ID in OTT communications, network abuse by unauthorized users is an inevitable problem. Unauthorized access by unidentified users and network communication, ie anonymity, are significant risks in modern communications.

Anonymity

The principle of anonymity in communication is the intentional concealment of the identity of the caller with the goal of communicating without traceability. Public telephones are an almost symbolic example of anonymous communication. Payphone payments are untraceable cash, payphone numbers are public, and anyone can use the phone. In other words, the identity of the caller is unknown on public telephones, and there is no means of verifying that the caller is who he or she claims to be. There is no way to identify the caller's ID (except through the use of sophisticated voice recognition software) because the phone number is not in a phone book or owned by an individual. For registered devices such as mobile phones, the phone number can trace the identity of the device owner, but still hide the identity of the caller. For example, using a stolen phone or a pay-as-you-go SIM card can hide the real identity of the caller. Alternatively, connecting your notebook, tablet, or cell phone to WiFi in a public cafe will give you the same anonymity as a payphone or phone booth.

Some OTT operators operate their VoIP phone service as a pay phone without subscriber identity verification. For example, CNN Money's recent online report (http://money.cnn.com/2015/11/17/technology/isis-telegram/) states, "An app called 'Telegram' has become a new favorite among jihadists. It is noted that it is popular with According to the investigation, the Islamic State (ISIS) terrorists who secretly planned the Paris attacks used the Telegram app as a means of communication. "Telegram founder knew Isis was using the app to communicate before Paris attacks" (http://www. independent.co.uk/life-style/gadgets-and-tech/news/telegram-knew-isis-communicate-paris-pavel-durov-a6742126.html) reported that Telegram founder Pavel Durov (Pavel Durov) said, "The right to privacy is more important than the fear of bad things happening like terrorism."

Another news story where privacy and anonymity have been exploited for criminal activity is BitTorrent. It is an application and data network commonly used to illegally download or share copyrighted material. CNN Money article "50,000 BitTorrent users sued for alleged illegal downloads" (http://money.cnn.com/2011/06/10/technology/bittorrent_lawsuits) /) said users of the app have been charged with illegally downloading copyrighted material, including "The Hurt Locker," under new anti-piracy laws. Network operator BitTorrent has taken the public telephone position that it is not responsible for actions taken by network users for their personal activities. While free speech advocates support the stance, law enforcement, government, national security agencies, and intellectual property advocates vehemently detest it as reckless and irresponsible. there is Irrespective of the political side of the issue, unless the communication system is capable of performing caller verification, the discussion of terminating anonymous calls is purely academic.

For companies and entities, intellectual property, development technology, product evaluation, manufacturing know-how, confidential financial reports and forecasts, business conditions, sales forecasts, inventory and work-in-progress, quality audits, transaction and intellectual property contracts, customer lists, Originator verification and authentication is especially important in controlling access to sensitive company data such as employee records and other trade secrets. In accessing corporate communications, the access rights granted to employees, contractors, or officers rely on identity verification. In conference calls involving calls with investors, identity verification is important to confirm the identities of the participants in the call and ensure that no one is listening without a need to know.

Ironically, while caller verification can be used to deter criminals and corporate espionage, the same identity verification can also be beneficial in ensuring caller privacy. If both parties to a call or text chat confirm each other's identities through some prescribed authentication procedure, the call can be protected from attacks, as fraudsters will not be able to access the call or its data.

Finally, in order to distinguish between anonymous callers in anonymous calls, a distinction needs to be made. Anonymous callers are individuals who disguise their true identity on the network they are communicating with. However, in an anonymous call, the identity of the caller is not anonymous on the network, only the identity of the caller during the call is obfuscated in the call data packet. Registered account holders of the SDNP network can follow this disclosure to place calls or send data using anonymous data transfer even though their identity and phone number are known to the network. In this way, law-abiding citizens can communicate anonymously without hiding their identity from the SDNP network operator. SDNP calls are private and secure, even if the network knows the identity stored in the SDNP name server database if the caller is engaging in a normal private call, entertainment, or business.

An example of the need for legal anonymous calling is global gaming where it is important to protect gamer identities, especially children's identities. Another example where anonymity can benefit is vehicle-to-vehicle (V2V) communication. Retaining anonymity eliminates the risk that identifying the personal data of a driver who has made traffic worse could make him the target of retaliation from other irate drivers. In contrast, law enforcement (subject to applicable law) has access to calls and data transmissions if the originator is involved in a crime or other malicious communication. In this way, network operators can satisfy the requirements of court orders and subpoenas without exposing the identities of law-abiding citizens or the content of their calls.

In summary, using the disclosed SDNP communication method, only identifiable SDNP subscribers can make anonymous calls. Unidentified callers cannot access the SDNP network or make anonymous calls.

National security and privacy

The nature of secure and private communications is even more confusing when considering government roles and laws. Every country claims sovereignty to control domestic communications. However, with the advent of the Internet and dynamically routed packet-switched data networks, network monitoring presents a host of technical and legal issues. One concern is the problem of monitoring traffic "flowing" through the network between servers. This means that data packets pass between countries without stopping. Because Internet traffic is dynamically routed, network operators have no idea what data packets are being transmitted by their network of servers. Of course, any country can intercept and attempt to decode this mass of bulk data, but since it's encrypted, especially for real-time surveillance, it can be accessed without knowing the encryption key. is difficult. Also, certain countries may not have jurisdiction to request a subpoena or request the encryption key used to place the call, as the caller may not reside within the country. The data flowing through the network in this way is analogous to radio traffic passing through the Earth's atmosphere. Even if radio waves pass overhead, there is no practical way to stop them. Similarly, there is no practical way to stop data traffic flowing through networks other than completely isolating a country's infrastructure from the Internet.

A more practical solution to managing communications is to focus surveillance on last-mile communications. That is, intercept and monitor calls and call data whose source and destination are within the country. Compared to interception of large amounts of data traffic, this approach requires that (i) the data is small in scale, i.e. easier to analyze, (iii) able to summon a last-mile carrier or network operator for submission of encryption keys; (v) use network addresses, GPS data, or triangulation of radio signals to learn the location of network-connected devices; There are several advantages.

Unlike the legal and technical challenges of enforcing regulations on data flowing through networks, it is entirely in the jurisdiction of the country in which the last-mile network operator is located to enforce laws on last-mile communications and call termination. Depending on national privacy laws, national governments may insist on the required level of access in last-mile communications. This includes any combination of:
• No right to monitor any data or calls unless subpoenaed by a court on probable grounds. The right to surreptitiously monitor calls or data communications 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 and monitor communications, and block any or all communications if necessary;

For example, various governments, such as the United States, have taken the position that they reserve the right to monitor call "metadata" without a court order. Metadata includes data packet information about the caller and destination, the duration of the call, where the caller was located at the time of the call, etc., and can be viewed without access to the actual call data itself can be obtained. Essentially, metadata consists of the data header of an IP packet, but not the payload. In contrast, monitoring call and data communications requires access to the payload itself, not just the header data. If the payload may be encrypted, the government may require the network operator to provide the master encryption key, if one exists. One issue raised by privacy advocates is government abuse of power. In particular, if a network relies on a single set of master encryption keys, the fact that those keys are provided to the government in response to a court order so that the government can actually monitor specific individuals is Even if the court order is limited to certain individuals or groups, in practice the government will be able to monitor everyone's calls. In this issue, it is sometimes pointed out that we are caught in a dilemma: "Then who will crack down on the police?"

Another consideration concerns the privacy rights of individuals making international calls. In such cases, callers should be aware that government access laws are dependent on the location of both callers, ie where the two last mile networks occur. US-to-China calls are subject to US law for US callers and Chinese law for Chinese callers. In these situations, call access by one government may be greater than the other. So a caller in a country with full privacy rights may believe that their privacy has been violated by the government of the other country, but the legal basis for filing a complaint is that they are calling into that country. does not exist.

In the case of communication using the previously disclosed dynamic communication network and protocol, fragmented, scrambled and dynamically encrypted data packets transferred anonymously through the SDNP network flow in hyper-secure cloud communication. Data interception is virtually impossible. As such, the privacy and security of hyper-secure calls are determined by the device and the last-mile communication. Adapting the above-described SDNP method to last-mile communications has the potential to enable hyper-secure communications and a last-mile capable of high integrity privacy, as disclosed herein.

In addition, it discloses mechanisms for adjusting the security and privacy settings of SDNP networks to comply with local laws applicable to last-mile communications in each country. These methods include safeguards that allow licensed security authorities to monitor communications in accordance with law and court action without exposing call data to hackers and cybercriminals. As such, the hyper-secure last-mile communications disclosed herein do not employ the use of "backdoors" that are vulnerable to cyber-attacks.

Method and apparatus for hyper-secure last-mile communication

To ensure end-to-end hyper-security, the application of the aforementioned methods for routing fragmented, scrambled and encrypted anonymous data packets within the SDNP cloud is similarly adapted to communications within the last mile. There is a need. Since data may be carried on networks not hosted by the SDNP operator, packet routing may include conventional IP packet routing, and the inherent security of the last mile network is the responsibility of the last mile network operator. Securing last-mile communications is particularly problematic as they can be unknowingly compromised by cybercriminals who may be colluding with

In the present invention, last-mile communication entails the transfer of IP datagrams outside the data cloud network using different packet formats than data packets within the SDNP cloud. As shown in FIG. 10, exemplary data packets 1222B, 1222C, and 1222F are generated by an SDNP cloud composed of servers 1201 (shown schematically as softswitch-enabled SDNP nodes M _0,0 through M _0,f ). SDNP datagrams denoted as are used to transfer VoIP, video, text and data. SDNP datagrams contain SDNP Layer 3 source and destination addresses rather than Internet IP addresses. An SDNP address differs from an IP address in that it is not recognized by the Internet's DNS name servers, but only by an SDNP name server or other server performing the functions of an SDNP name server.

As described in the above-referenced US application Ser. No. 14/803,869, SDNP packets dynamically change as they traverse networks, providing updated routing addresses and shared secrets and dynamic "states" (time). etc.) is executed. For example, data packet 1222B sent by node M _0,0 consists of a Layer 3 SDNP datagram B containing a unique SDNP address and a uniquely encrypted payload. Data packet 1222C output from downstream node M _0,1 consists of Layer 3 SDNP datagram C with different SDNP address and re-encrypted payload. A few tens of milliseconds later, the same payload arrives at node M _0,f . This processes the data and forwards data packet 1223G containing IP datagram G to the last mile.

Modifications are performed according to defined states so that the original packet data can be restored by performing a series of inverse functional operations performed in the reverse order in which they were performed. For example, if an SDNP function sequence consisting of the scrambling, junk insertion (disguise), and encryption steps invokes the same state used to perform the function to perform the corresponding inverse function: It can be reversed by decoding, removing junk, and unscrambling in reverse order. Packet state data is transmitted as a time, seed, or key, either embedded in the payload of the packet or sent before the packet. Data transfer and processing within the SDNP cloud is done using a shared secret and security credential information unique to the SDNP cloud. Media nodes that share a shared secret and a common set of security credential information may be referred to as a security "zone." Zones used for security credential information operating within the SDNP cloud cannot be exposed to user communications outside the SDNP cloud. Therefore, all last mile communications should include an SDNP security zone that is separate from the SDNP cloud.

In the example shown, server 1201A and server 1201F hosting corresponding nodes _0,0 and M _0,f act as SDNP gateways. That is, it communicates with devices outside the SDNP cloud and with other SDNP nodes in the cloud. Communications from these gateways to communication devices outside the cloud represent "last mile" communications. Therefore, the gateway node needs to understand the zone security credential information of both the SDNP cloud and the last mile network to which it connects, and act as a translator during packet routing. Semantically, the term last mile is an abstraction that refers to communications outside the SDNP cloud and does not specifically refer to a mile distance. Instead, the term last mile includes the distance between the client device and the SDNP cloud, regardless of whether the client device is acting as an SDNP client, i.e., running SDNP application software or firmware, and regardless of the distance. including communication between

Also, the term last mile applies to both the client device from which the call is initiated and the client device to which the call is made. The distinction between "first mile" and "last mile" is arbitrary because, literally, the caller's data represents the "first mile" rather than the "last mile" of the call. Specifically, in a double translation or IP communication "session", the device receiving the call responds to the call or session request by necessarily sending a response to the caller. Therefore, in two-way communication, the first mile connection always serves as the last mile of the reply data path. In essence, the caller's first mile simultaneously becomes the response's last mile. As such, the term "last mile" as defined throughout this application shall mean both the first mile and the last mile, regardless of from which device the call or call session was initiated.

Communication from outside the SDNP cloud to any device other than an SDNP client is necessarily performed using IP datagrams, not SDNP datagrams. By way of example, as shown in FIG. 10, data packet 1223A consists of "IP datagram A" constructed using an SDNP payload with an IP address rather than an SDNP address. Similarly, IP datagram G consists of data packet 1223G containing the SDNP payload routed using the IP address. The source IP address and destination IP address represent IPv4 or IPv6 addresses that can be recognized by the routing destination network. An IP address may include an Internet address as recognized by the Internet's DNS servers, or it may include a NAT address used for routing across a local network defined by a local network service provider.

The hardware and firmware used in last-mile communications can vary widely and can include telephone lines, fiber communications, cable television networks, 3G and 4G wireless networks, microwave towers, and satellites. Therefore, the analysis of last mile communications needs to consider the various layer 1 physical networks and the corresponding layer 2 data link formats employed. For example, formats include analog (POTS), Ethernet, WiFi, 3G, 4G/LTE, and DOCSIS3. The security and privacy features corresponding to each last-mile implementation are considered on a case-by-case basis in the section below on SDNP "call-out" communications.

SDNP callouts over non-secure lines

As a term of nomenclature, any call that leaves a defined network and is transferred through another (and generally different) network is commonly referred to as a "callout". This term means that data or voice leaves one network and is transferred over another network. For example, communications between clients running the Skype application are commonly referred to as Skype calls, whereas calls made from a Skype client to a plain or mobile phone number are referred to as Skype call-out features or "Skype-out" calls. Called. Call-outs to regular phones generally incur additional costs, either as a subscription fee or as a pay-as-you-go charge.

In the context of this document, communication from an SDNP client to any device other than an SDNP client over a non-secure last-mile connection is referred to herein by the defined term "SDNP callout." FIG. 11 is a schematic representation of two examples of SDNP callout routing to non-secure last mile. In the upper example, communication takes place using analog signals to an analog device such as a telephone or public telephone 6A. In such cases, the SDNP gateway must include a digital-to-analog converter. Otherwise, a modem or conversion device may be added to the gateway. Information is transmitted by analog signals 1221 rather than data packets. Analog telephone signals are efficient for transmitting voice, but are not well suited for high speed data communications.

In the case of the bottom example, an SDNP callout is made over a digital network to a digital device (such as a mobile phone 32) that is not enabled as an SDNP client, i.e. not enabled with SDNP software or firmware. . In such cases, an IP packet format, generally according to the Internet Protocol, ie, consistent with the 7-layer OSI model, is used to carry the call or data via data packets 1223 . IP datagrams contain IP or NAT addresses in their source and destination address fields, and IP data or VoIP data as payload. A digital path may contain digital data in various formats such as Ethernet, WiFi, 4G/LTE, etc., depending on the last mile connection.

In both exemplary schematics, the last-mile communication data is carried outside the SDNP network over an unsecured communication channel or network, making the call insecure and subject to hacking, spying, eavesdropping, and other cyber-attacks. . As explained in the background of this application, no matter what kind, such as copper twisted pair, coaxial cable, fiber, Ethernet, WiFi, cellular, satellite, etc., special security schemes such as encryption are required at the end. Last-mile non-secure circuits and connections are inherently insecure unless they are inserted into the two-end data path. Therefore, the security of the most secure data cloud or VPN is compromised due to the weakest link (the last mile in this example). Even encryption does not guarantee security, especially over a single, well-defined electrical, microwave, or radio connection. In addition to the lack of security, the illustrative schematic does not include any mechanisms for identity verification. Since authentication is not possible, Last Mile has no privacy guarantees. Thus, the exemplary schematic represents a non-secure last-mile network in which caller privacy is not guaranteed.

In FIG. 12, an SDNP call without privacy guarantees connects to the public switched telephone network or PSTN gateway 1A via a wire or fiber link 24 hosted by a digital network service provider NSP to a non-secure last mile SDNP gateway 1201A. Out is executed. The PSTN gateway 1A is then routed to a conventional telephone system POTS switch 3 via an analog communication connection 4 . A conventional telephone call is then placed from POTS switch 3 over twisted pair wire 7 to home telephone 6, cordless telephone system 5, or public telephone 6A. The entire last mile is non-private and non-secure. The communication of data packet 1222A containing SDNP datagram A uses SDNP addressing and SDNP payload within the SDNP network, but loses the hyper-security benefits once the data enters the last mile. For example, data packet 1223B containing IP datagram B transmitted over wire or fiber link 24 hosted on the NSP network uses conventional IP addressing recognized by Internet DNS servers, including cyber pirates. Includes conventional IP payloads that can be sniffed by Analog lines 4 and 7 are similarly vulnerable because they carry simple analog voice signals as analog call data 1221 . Although SDNP gateways can support non-secure, non-private callouts, it is not recommended to connect SDNP-protected calls to non-secure last-mile networks without privacy provisions.

The non-secure last-mile implementation described above can be slightly improved by using identity verification. FIG. 13 schematically illustrates an example of SDNP call routing to non-secure last mile but using two different types of authentication. The top example shows an SDNP call out from the SDNP gateway 1220A to the office desktop phone 9 via an analog or POTS line. As shown, the operator 1225 manually performs authentication to verify the identity of the account owner and the account ID. Although authenticated, calls made with analog voice 1221 are not secure and are private only if the conversation does not audibly reveal secret or account information. That is, information is private if the secret is not revealed, but once the information is revealed, the communication is no longer private. As such, the term semi-private as used herein refers to authenticated, or conditionally private, communication over a non-secure line.

The bottom example shows an SDNP callout from the SDNP gateway 1220A to the non-secure digital last mile. The data transmitted by IP datagram 1223 to an electronic device such as desktop PC 36 is insecure, but can be authenticated using electronic identity verification methods such as token 1226, which is inaccessible to cyber attackers. Because the lines are insecure and can be sniffed, care must be taken not to reveal account numbers or sensitive data in digital interactions.

Some examples of semi-private, non-secure calls are given below. FIG. 14 illustrates identity verified non-secure last mile communication between an SDNP network and an office desktop phone 9 (such as a private banker's phone). For example, when performed internationally, account holder/account holder calls are routed worldwide using hyper-secure communications over the SDNP network and are ultimately routed through SDNP gateway 1201A as SDNP calls. Connected to Miles. The long-distance portion of the call is carried out using dynamically changing SDNP datagrams, such as data packet 1222A containing SDNP datagram A with an SDNP payload. Next, at SDNP gateway 1201A, data packet 1222A is converted from SDNP datagram A to IP datagram B indicated by data packet 1223B. Unlike SDNP datagram A, IP datagram B contains a sniffable IP payload. Data packet 1223B is forwarded to public switched telephone network or PSTN gateway 1A by wire or fiber link 24 operated by a network service provider (NSP). This gateway is then connected to the company's exchange 8A via a POTS line 4 carrying an analog call 1221. FIG. Corporate switch 8A is connected to desktop telephone 9 via analog private branch exchange or PBX line 7A and is also connected to personal authentication operator 1225 . During the call, the account holder will contact the private banker at desktop phone 9 . In doing so, prior to engaging in any transaction, the Personal Authentication Operator 1225 joins the call to verify the identity of the caller before terminating the call, thereby preserving the caller's privacy thereafter. . However, because the call is non-secure, both private bankers and account holders need to be careful not to verbally reveal confidential information such as account numbers, passwords and PINs. The call is therefore semi-private, or conditionally private.

FIG. 15 illustrates identity verified non-secure last mile communication between the SDNP network and the desktop computer 36 . The digital communication session uses IP datagrams B carried on some digital medium to communicate from desktop computer 36 to SDNP gateway 1201A. In the first leg, Ethernet 106A carries data packet 1223D containing IP datagram B from desktop computer 36 to Ethernet-based local router 27B. Data packet 1223C containing IP datagram B is then used to communicate from the Ethernet local router to network router 27 via Internet Service Provider (ISP) wired or fiber link 24A. In the final leg of the last mile between network router 27 and SDNP gateway 1201A, data packet 1223B containing IP datagram B is transmitted by the network service provider line of wire or fiber link 24 operated by the NSP. The last mile is non-secure because IP datagrams are used. Digital identity verification such as login window 1227 and security token 1228 can be used for authentication to keep communications semi-private. To prevent exploitation by fraudsters, these digital certificates should be restricted to one-time use. For example, once a number is generated from a token and used for access, the combination can no longer be used, so even if a hacker were to intercept the token, it would expire and become invalid. does not stand in

Another example of identity verified non-secure last mile communication is shown in FIG. In this example, as an SDNP callout, communication is made from the SDNP gateway 1201A to the POS terminal 38 and the gas pump POS terminal 38A. The last mile communication shown is NSP wire or fiber link 24 carrying data packet 1223B containing IP datagram B to network router 27, and then IP datagram B in data packet 1223C to PSTN bridge 3A. A mixed digital and analog connection followed by a wire or fiber link 24A and a POTS or analog line 30B carrying digital PCM (Pulse Code Modulation) data as an analog call 1221A connected to POS terminal 38 and gas pump POS terminal 38A. be. Authentication in financial transactions is based on bank card data 1229 including smart card integrated circuits and dynamic PINs 1228 based on electronic verification. Authentication includes confirmation by a financial institution 1230 connected to the SDNP network via SDNP gateway 1201A or another last mile.

Hyper-secure last-mile communication

Hyper-secure communication can be achieved in the last mile by employing the technology of secure dynamic communication networks and protocols. To facilitate hyper-security, the connected device needs to run the SDNP code as an "SDNP client". An SDNP client consists of operating instructions, a shared secret, and SDNP connection information hosted on the connected communication device. An SDNP client may include software running on an operating system, firmware running on a microcontroller or programmable IC, or dedicated hardware or integrated circuits. Figure 17 is a schematic representation of an example of hyper-secure communication in the last mile, where an "SDNP connection" is used. As shown, the SDNP gateway 1201A is connected to an SDNP app 1335 running on a device running an SDNP client, desktop computer 36 in this example. SDNP clients are hardware and operating system specific. For mobile devices, separate apps are required for each mobile device platform using Android, iOS, and Windows Mobile. Similarly, notebooks, desktop PCs and servers, including Windows 10, MacOS, Unix, Linux, etc., require separate OS-specific applications. Hardware hosting of the SDNP client on devices that do not have a high level operating system, such as POS terminals, hotspots, IoT, etc., needs to be adapted to the programmable device executing the code. Programmable integrated circuits often require programming in chip-specific development environments specific to IC vendors such as Qualcomm, Broadcom, Intel, AMD, NVidia, Microchip, and the like.

Since the SDNP gateway 1201A and the SDNP application 1335 communicate using the SDNP payload 1222, packet sniffing cannot understand the caller's ID and the call payload. Specifically, the SDNP payload 1222 contains source and destination SDNP pseudo-addresses that are not recognized by DNS servers, and the payload can be scrambled, fragmented, mixed with junk data insertion, and dynamically encrypted. It consists of various SDNP data. SDNP payload 1222 is embedded in IP datagram 1223 . This directs routing over the last mile using the IP or NAT address of the cellular, cable, or ISP operator's network used for the last mile connection, rather than the SDNP address.

Another aspect of SDNP-based hyper-secure last communication is that all SDNP clients are inherently capable of authentication and identity verification. Thus, privacy features are based not on the ability of the network to implement privacy to support AAA, but on whether the client software or firmware is designed to facilitate the verification process. Since all hyper-secure last mile support identity verification, it should be understood that the hyper-secure last mile examples below apply to both private and non-private secure communications. Thus, unlike insecure last-mile networks with semi-privacy features, private communication over hyper-secure last-mile is determined by the SDNP client, not the network, where any level of single-factor authentication the client desires. Or can support multi-factor authentication procedures.

Specific examples of hyper-secure calls are shown below in some examples. FIG. 18 illustrates hyper-secure last-mile communication between various cellular mobile devices with SDNP network and WiFi lastlink. As shown, data packet 1222A containing SDNP datagram A and SDNP payload is converted by last mile communication's SDNP gateway 1201A into data packet 1223B comprised of IP datagram B also containing SDNP payload. Because hyper-secure last mile utilizes different shared secrets, numerical seeds, encryption keys, and other zone-specific security credential information than those used in the SDNP cloud, the SDNP payload of IP datagram B is It is different from the SDNP payload of SDNP datagram A. In other words, by changing the payload from one security zone to another, and by embedding the SDNP routing information as source and destination SDNP addresses that are not recognized by the DNS server, SDNP gateway 1201A can process the SDNP data. gram is converted to an IP datagram.

Then, in order to facilitate packet routing between the SDNP gateway 1201A and the communication devices, i.e. tablets 33 and mobile phones 32 acting as SDNP clients, this zone-specific SDNP payload is transferred to the last-mile network-specific IP address ( wrapped in an IP datagram packet with an IP header containing a NAT or Internet address). Since the intermediate device in the last mile routing is not an SDNP client, the structure of the SDNP payload within IP datagram B remains fixed as it travels the last mile. In other words, data packets 1223B, 1223C, and 1223D are identically constructed datagrams, all SDNP data with the same SDNP payload (a payload that does not change as the packet hops from device to device along the last mile). Gram B. In brief summary, only an SDNP network node or an SDNP client will be able to reconstruct the SDNP payload embedded in a level 3 datagram, regardless of whether it is an IP datagram or an SDNP datagram.

As shown, data packet 1223B containing IP datagram B is transmitted over wire or fiber link 24 operated by the NSP to network router 27, followed by data packet 1223C, also containing IP datagram B, transmitted by the ISP. is transmitted to WiFi router 26 by wired or fiber link 24A. The data packet 1223D containing IP datagram B is then used over the WiFi link 29 of the mobile devices, such as the mobile phone 32 and the tablet 33, both running the SDNP application 1335A, and the last link communication is facilitated by the WiFi router 26. be. As such, these devices act as SDNP clients capable of interpreting the data contained in data packet 1223D containing IP datagram B. FIG. This includes decoding, removing junk, unscrambling, and mixing the contents of the payload with data fragments from other data packets to recreate the original message or sound.

FIG. 19 illustrates hyper-secure last-mile communication between various cellular mobile devices with an SDNP network and a cellular radio last link. As shown, data packet 1223B containing IP datagram B is transmitted to network router 27 by wire or fiber link 24 operated by the NSP, followed by data packet 1223C, also containing IP datagram B, to the mobile network operator. 24B to the cell phone base station 17, creating a cellular network 25. The data packet 1223D containing IP datagram B is then used over the 3G or 4G/LTE cellular link 28 of mobile devices such as mobile phone 32 and tablet 33, both running Last link communication is facilitated.

As in the previous example, the last-mile routing intermediate device is not an SDNP client, so the structure of the SDNP payload in IP datagram B remains fixed as it travels the last mile. In other words, data packets 1223B, 1223C, and 1223D are identically constructed datagrams, all SDNP data with the same SDNP payload (a payload that does not change as the packet hops from device to device along the last mile). Gram B.

FIG. 20 illustrates Ethernet last mile communication between various tethered (non-mobile) devices with an SDNP network and Ethernet last link. As shown, data packet 1223B containing IP datagram B is transmitted over wire or fiber link 24 operated by the NSP to network router 27, followed by data packet 1223C, also containing IP datagram B, transmitted to the Internet service provider. (ISP) wired or fiber link 24A to Ethernet router 103A. Data packet 1223D containing IP datagram B is then used over Ethernet 106A of a tethered device such as desktop computer 36 running SDNP app 1335C and desktop phone 37 running SDNP firmware 1335B to transfer Ethernet Last-link communications are facilitated by the Trademark router 103A. If there is no SDNP network node or SDNP client in the last mile, data packets 1223B, 1223C, and 1223D are identically constructed datagrams, all with the same SDNP payload (the packets hop from device to device along the last mile). consists of an SDNP datagram B with a payload that does not change between

FIG. 21 illustrates hyper-secure last-mile communication between SDNP networks and cable service clients. As shown, data packet 1223A containing IP datagram B is transmitted over NSP wire or fiber link 24 to cable CMTS 101, the cable operator's command, communication, and content distribution center. Such cable operators offer a wide range of services such as cable television, pay-per-view, telephone services, Internet access and business services. Fiber or coax modulated according to DOCSIS3 and trellis formats (discussed in the background of this disclosure) are then used, and the CMTS 101 head unit to the client via cable 106 so that bandwidth and real-time services are optimized. Connected. Cable operators can maintain datagram formats or package IP datagrams into proprietary datagram formats transparently to their clients. These data packets, referred to herein as CMTS datagrams C, use cable-specific NAT addressing and encapsulate SDNP payloads as nested payloads within data packets 1224C for delivery over cable 106. become.

As shown, cable CMTS 101 routes CMTS datagram C to cable modem 103 . This then extracts a payload data packet 1223B consisting of IP datagram B with the unmodified SDNP payload for last link delivery. The last link to an SDNP client enabled device is via Ethernet 106A to desktop computer 36 running SDNP client app 1335C, or via twisted copper wire 7 to cordless phone 5A running SDNP client firmware 1335B. Can occur in some formats. Cable CMTS 101 also routes CMTS datagram C to cable modem 103 , which then extracts the original IP datagram, eg, IP datagram B, and sends it and other video content over cable 106 . transmitted to the cable TV set-top box. From the cable set-top box, the IP datagram B and content are then transferred via HDMI-2 107 to the UHD interactive television 39 running the SDNP application 1335D. Alternatively, the cable TV set-top box 102 can host the SDNP firmware.

Figure 22 illustrates hyper-secure last-mile communication between a WiFi home network connected via an SDNP network and a cable service provider. As shown, data packet 1223B containing IP datagram B is transmitted over NSP wire or fiber link 24A to cable CMTS 101, the cable operator's command, communication, and content distribution center. A wired or fiber link 24A is then used to connect, via coax or fiber, the CMTS 101 head unit to a particular client's cable (WiFi) modem router 100B, creating a WiFi access point 26 . Routing of data packet 1224C may include an IP datagram with Internet address or a unique CMTS datagram C with NAT addressing. The routing between the SDNP gateway 1201A and the cable (WiFi) modem router 26 represents the hyper-secure last mile wireline section.

The last leg of the home network includes a WiFi link 29 that wirelessly connects a cable (WiFi) modem router 26 to various home devices by means of data packets 1223D containing IP datagram B's. To facilitate end-to-end hyper-security, such devices must act as SDNP clients using software or firmware loaded on the device. For example, notebook 35 and desktop computer 36 operate as SDNP clients using computer app 1335C, and mobile phone 32 and tablet 33 operate as SDNP clients using mobile app 1335A. An IoT device (refrigerator 34K in this example) can act as an SDNP client if the control system is loaded with SDNP firmware 1335E. However, if these devices do not or cannot include software for an SDNP client, other methods must be used to provide end-to-end security.

Last link security for ID pairs

End-to-end hyper-security cannot be guaranteed if the connected device cannot act as an SDNP client. In this case, an SDNP remote gateway can be used to extend the hyper-security communication to cover the last mile of communication excluding the last link. The part of the last mile that is directly connected to a communication device, the last link, is not enabled as an SDNP host, and the last link is via a local area network (LAN) used to facilitate last link communication. Link security must be guaranteed. FIG. 23 is a schematic representation of the use of the SDNP remote gateway 1350 in last mile communications. SDNP remote gateway 1350 includes any communication device enabled by SDNP firmware 1335H to function as a remote gateway. Thus, the SDNP connection between SDNP gateway 1201A and SDNP remote gateway 1350 consists of IP datagram 1223A containing IP or NAT source and destination addresses and SDNP payload 1222 . SDNP payload 1222 contains nested SDNP payloads using an SDNP address that is not recognized by the DNS server and security credential information specific to the last mile zone. This SDNP connection is hyper-secure capable of supporting identity verification and caller privacy.

Communication between the SDNP remote gateway 1350 and any connected device other than the SDNP client (such as the desktop computer 36) may be performed over a local area network or LAN connection such as Ethernet, WiFi, or other protocol. . Security is facilitated by LAN security protocols and device pairing between communication devices and SDNP remote gateways. Device pairing is a process in which an authentication sequence between two communicating devices establishes the identities of the two devices to prevent unauthorized access.

FIG. 24 illustrates an example in which the functions of a remote SDNP gateway are performed through the use of an SDNP-enabled router 1351, a router running SDNP firmware 1335H. The gateway converts data packet 1223A containing IP datagram A into data packet 1223B containing IP datagram B. FIG. The SDNP firmware 1335H interprets the SDNP payload contained in IP datagram A, but the connected device is not an SDNP client. Instead, the SDNP router 1351 converts the SDNP payload to a conventional IP payload. This last link is not secure unless additional security measures are implemented in the device. For home use, this insecure device connection is often not a problem as the last link occurs within the home. Hackers can't sniff those wired connections unless they physically break into your home and eavesdrop. Examples of wired last links to non-SDNP devices in the home include modem 103C or HDMI-2 connected to desktop computer 36 and connected to television 39 as shown in the example. Ethernet 106A is included.

Because SDNP connections and hyper-secure communications only extend to the SDNP router 1351, Last Link relies on authentication and encryption to provide wired connection security. In the case of Ethernet, such security can include any number of security features, such as VLANs or virtual local area network operations that utilize encryption between authentication devices, such as iSCSI operating at layers 1 to 3. A method (http://www.computerweekly.com/feature/iSCSI-security-Networking-and-security-options-available) is available. Alternatively, the "IP Security" or IPSec framework can be used to implement security using Layer 4 to Layer 6 methods. Originally developed for data storage and promoted by Cisco as an industry standard, IPSec has two security modes. The "Authentication Header" mode allows the receiving device to authenticate the sender of the data. In this mode, the data fields are encrypted, but the header uses a recognizable IP address. In Encapsulating Security Payload (ESP), also known as Tunnel Mode, the entire IP packet, including the IP header, is encrypted and nested in a new unencrypted IP packet so that routing works properly and packets reach the correct network destination. is transmitted to

In either case, security relies on authentication devices that allow devices to connect to the network. For example, in home networks such as personal networks connected to computers, shared storage drives, IoT, and other devices, the hardware connected to the network does not change frequently. In such cases, authentication essentially involves a registration process for devices accessing a network or router. Rather than identifying a particular user's identity, this type of authentication is device-to-device, or device-to-device, typically through the use of device tags, names, or ID numbers to authorize connections. The identified device is identified and recognized. Establishing a network connection includes a setup phase after the devices are first introduced to each other and the user is authorized to connect. An automatic authentication sequence is then performed each time a wired device is physically connected to another device, or in the case of WiFi, each time the two devices come within range of each other. This setup phase, referred to herein as ID pairing, may also be referred to as device registration, device bonding, device pairing, pairing, or pair bonding. A similar process is used in devices that connect Bluetooth® headphones to a mobile phone, or pair a Bluetooth® mobile phone to a car's hands-free audio system. Protocols include Challenge Handshake Authentication Protocol or CHAP, Kerberos V5, Simple Public Key Generic Security Service Application Programming Interface (GSSAPI), Secure Remote Password (SRP), and Remote Authentication Dial-In User Service (RADIUS). included. Methods such as RADIUS rely on broken encryption methods, but are still used in combination with other techniques.

Ethernet communication protects an ID pair device, such as Ethernet modem 103C, but consists of analog telephone signals transmitted to cordless telephone 5A and desktop telephone 37 via twisted pair copper wire conductors 7. The last link is not secure if the modem output is Furthermore, the communication format of cordless telephone 5A is not secure and subject to eavesdropping and monitoring. For this reason, using a home phone for secure communication is not recommended.

Delivery of video content is also of interest in security. For example, for communication to the HDTV 39 of the SDNP router 1351, the high-definition multimedia interface (HDMI), DisplayPort (DP), Digital Visual Interface (DVI) and, less popularly, the Gigabit Video Interface (GVIF). video communication formats such as HDTV, or Unified Digital Interface (UDI), typically consist of a physical connection to an HDTV or display monitor. Originally, the security of this connection and its data has been a concern of movie studios and content providers, with a focus on preventing illegal duplication and distribution of copyrighted material. To maintain the security of the video link, Intel Corp. One security protocol developed by High-Bandwidth Digital Content Protection (HDCP) (https://en.wikipedia.org/wiki/High-bandwidth_Digital_Content_Protection). Originally, the system was intended to prevent HDCP-encrypted content from being played on unauthorized devices. The system verifies the authenticity of the television receiver or display before content is transmitted. Thus, in DHCP, authentication prevents data receipt by unlicensed devices, data encryption prevents information eavesdropping, and compromised device keys are revoked.

HDCP can protect the flow of content from the modem to the TV through authentication, ie using ID pairing. However, with the advent of smart TVs, the data flow has become bi-directional. Since revision 1.4, a high-speed bi-directional data channel known as the HEC or HDMI Ethernet channel has been introduced as a means of facilitating upstream data flow from a TV to a modem or set-top box. registered trademark). This data channel allows data to be sent and received from HDMI-connected devices via 100 MC/sec Ethernet, thus supporting IP-based applications such as IP-TV. HDMI Ethernet Channel allows Internet-enabled HDMI devices to connect to the Internet over an HDMI link without the need for a separate Ethernet cable can be shared. Therefore, the same security protocol and ID pairing available on Ethernet can be used to facilitate secure communication over HDMI.

FIG. 25 shows an example of the use of an SDNP-capable WiFi router 1352, a WiFi router running SDNP firmware 1335J, to perform the functions of a remote SDNP gateway. The gateway converts data packet 1223A containing IP datagram A into data packet 1223B containing IP datagram B. FIG. The SDNP firmware 1335J interprets the SDNP payload contained in IP datagram A, but the connected device is not an SDNP client. Instead, the SDNP WiFi router 1352 converts the SDNP payload to a conventional IP payload and the WiFi access point 26 is used to communicate wirelessly with connected devices to facilitate communication over the WiFi link 29. become. This last link is not secure unless additional security measures are implemented in the device. Security is a concern for WiFi communication in homes and offices, as data packets can be sniffed from a distance. Examples of WiFi-connected home and office devices include desktop computers 36, notebooks 35, tablets 33, cell phones 32, speakers 34B, printers/scanners 34A, and shared data drives 34C.

Security between the connected device and the SDNP gateway (i.e., the SDNP WiFi router 1352) is WiFi Protected Access WPA-II or WPA2 (IEEE 802.11i-2004), an alternative to the old WPA and its insecure predecessor WPE. etc., using any number of industry standard protocols. WPA2 communications are protected using CCMP. CCMP is an acronym for "Counter Mode Cipher Block Chaining Message Authentication Code Protocol", which is based on AES processing with 128-bit keys and 128-bit block sizes. CCMP provides data confidentiality, requires authentication, and sets access controls. Authentication includes ID pairing during setup. Re-pairing must be done manually. While CCMP security is good, it is not hyper-secure and lacks the anonymous data packets afforded by SDNP clients and the dynamic nature of SDNP communications.

FIG. 26 is an example of IoT connected devices in a home network. In this example, the use of an SDNP-enabled WiFi router 1352, a WiFi router running SDNP firmware 1335J, performs the functions of a remote SDNP gateway. The gateway converts data packet 1223A containing IP datagram A into data packet 1223B containing IP datagram B. FIG. Although the SDNP firmware 1335J interprets the SDNP payload contained in IP datagram A, the IoT connected device is not an SDNP client. Instead, the SDNP WiFi router 1352 converts the SDNP payload to a conventional IP payload, and the WiFi link 29 from the WiFi access point 26 is used to wirelessly communicate with the connected device. Unless additional security measures are implemented, this last link is not secure, especially since WiFi data packets can be sniffed from a distance. Examples of WiFi-connected IoT devices in the home include central heating and air conditioning 34D, lighting 34G, blinds 34F, large appliances 34K, portable and indoor HVAC 34E, garage doors 34L, home monitoring 34J, and home central security systems. 34H is included.

Security between the connected device and the SDNP gateway (i.e., the SDNP WiFi router 1352) uses any number of industry standard protocols, such as the aforementioned WiFi Protected Access protocol WPA2 with CCMP, to ensure data confidentiality. Accomplished by securing, requiring authentication, and setting access controls. In WPA2, security is achieved using identity pairing, device verification implemented as a Layer 2 protocol. This method is cumbersome because it involves a manual authentication method.

For IoT communication, a proximity network called “AllJoyn Framework” was recently introduced, an alternative protocol used in local area networks. In this framework, devices are detected, sessions are created, and secure communications are facilitated. The framework is designed to support connectivity of IoT devices using multiple Layer 2 transport layers, such as WiFi, Ethernet, serial bus communication, and powerline PLC. The applications are C, C++, Obj. C, and Java.

AllJoyn-compliant applications authenticate each other and exchange encrypted data to provide end-to-end application-level security. Authentication and data encryption are performed at application layer 7. Transport Layer 2, also called the router layer, transmits security-related messages between application endpoints, but does not implement the security logic itself. Application Layer 7 also implements a callback function called "Authentication Listener", which facilitates authentication using a PIN, password or authentication certificate. Security is achieved using AES128 peer-to-peer encryption. Similar to WPA, AllJoyn uses identity pairing in the authentication process prior to execution of command and control sequences. Supported authentication methods include pre-shared key (PSK), secure remote password (SRP) key exchange, or logon using username and password. This protocol allows (i) no authentication, (ii) authentication with pre-exchanged keys, and (iii) X. Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange with authentication via H.509 ECDSA certificates is also supported.

The same technology can be applied to enterprises. FIG. 27 is an example of IoT connected devices in a home network. In this example, the use of an SDNP-enabled WiFi and Ethernet router 1352Z, an Ethernet and WiFi router running SDNP firmware 1335J, performs the function of a remote SDNP gateway. The gateway converts data packet 1223A containing IP datagram A into data packet 1223B containing IP datagram B. FIG. Although the SDNP firmware 1335J interprets the SDNP payload contained in IP datagram A, the IoT connected device is not an SDNP client. Instead, the SDNP and Ethernet WiFi router 1352Z converts the SDNP payload to a conventional IP payload, and both WiFi link 29 and Ethernet 106A are used to communicate with connected devices. is done.

Unless additional security measures are implemented, this last link is not secure, especially since WiFi data packets can be sniffed from a distance. Examples of WiFi connected IoT business devices include devices connected to WiFi hotspots such as central heating and air conditioning 34D, lighting 34G, monitoring system 34J, security system 34H, POS terminals 38, tablets 33, etc. . Enterprise wired devices depend on the nature of the business. In the banking industry, devices include Ethernet-connected ATM machines 38D. At a petrol station, devices include, by way of example, an Ethernet-connected gas pump 38A.

In summary, last link can be protected with non-SDNP clients communicating with SDNP remote gateways. Thus, most of the last mile is hyper-secure, and the last link uses ID pair encryption security.

SDNP bridge communication

As mentioned above, last-mile data transfers outside the SDNP cloud always use IP datagrams, ie data packets that use Internet source and destination addresses, or use network operator's NAT addresses. For private networks, for example, when operating within an office building or in cooperation with a local network service provider that hosts an SDNP softswitch on a server, SDNP datagrams are used to It is also possible to realize hyper-secure communication with part of the miles.

As mentioned above, hyper-secure communication relies on a server to host the SDNP softswitch software or firmware, and communicates using SDNP datagrams and anonymous addresses rather than IP datagrams in the SDNP cloud. These SDNP softswitch-enabled servers are called SDNP nodes, designated by the SDNP node notation M _0,0 , M _0,1 , M _1,0 , M _1,1 , and so on. The above-referenced US application Ser. No. 14/803,869 also discloses communication between multiple independent SDNP clouds connected by SDNP bridges, which are SDNP gateways through which IP datagrams are routed to other SDNP clouds.

The concept of SDNP bridging can be similarly adapted to some of the last mile communications. Creating an SDNP sub-network or mini-cloud within the last mile requires enabling two or more servers with SDNP bridge software or firmware. Unlike the SDNP client software or firmware running on the end or originating device, the SDNP bridging operation is used to route data rather than acting as a final connection. As such, two or more adjacent SDNP bridges can operate as a standalone SDNP bridge network, an SDNP mini-cloud, or an SDNP ad-hoc network. As disclosed, the SDNP bridging function represents a layer 3 description similar in structure to the layer 2 description of a WiFi router's bridge mode operation. Within an SDNP bridge or SDNP bridge network, communication takes place using SDNP datagrams. Communication from an SDNP bridge or outside an SDNP bridge network to an SDNP bridge uses IP datagrams with an SDNP payload.

The exemplary schematic diagram of FIG. 28 illustrates the operation of an SDNP bridge within a last mile communication. This includes an SDNP network with an SDNP gateway 1201A, an SDNP bridge consisting of SDNP bridge routers 1350 and 1352Z running SDNP firmware 1335H and 1335J, respectively, and a connected client device that is not an SDNP client (shown as notebook 35 in this example). ). As shown, communication between SDNP gateway 1201A and SDNP bridge 1350 consists of a secure connection using IP datagrams 1223A containing IP addresses and SDNP payloads. SDNP payload 1222A contains SDNP routing information and a secure SDNP payload encoded using zone-specific security credential information. So even if IP address routing is used, the SDNP payload is used to achieve hyper-security.

Within the SDNP bridge connection, ie, between SDNP bridge router 1350 and WiFi-enabled SDNP bridge router 1352Z, hyper-secure communication is performed using SDNP datagrams 1222B. SDNP routing information is extracted from the SDNP addressing contained in SDNP payload 1222A. SDNP bridges and SDNP connections include hyper-secure wireline last-mile communications, where identity and account verification can be supported, and privacy is supported.

The connection from the SDNP bridge router 1352Z to a non-SDNP client device, i.e. notebook 35, utilizes an IP datagram 1223B with an IP address and an IP payload on either a WiFi or Ethernet local area network. . Although not hyper-secure, this last link can be secured by any of the Ethernet and WiFi security protocols mentioned above, such as iSCSI, IPSec, WPA, AllJoyn.

An SDNP bridge can be implemented between any two SDNP compliant devices transported over any number of physical media. Thus, SDNP bridging is a Layer 3 protocol that operates agnostic from the Layer 1 PHY and Layer 2 transport layer implementations. For example, the top schematic shown in FIG. 29A shows two SDNP bridged Ethernet bridges, each running SDNP firmware 1335H, using SDNP datagram 1222 via an Ethernet (wired) bridge. ) shows the communication that takes place from router 1351A. The central schematic shows two SDNP bridge routers 1352Z, each capable of Ethernet and WiFi communication, running SDNP firmware 1335J. Communicate from this SDNP bridge router using SDNP datagrams 1222 via a WiFi (wireless) bridge. The schematic diagram at the bottom shows that an SDNP datagram 1222 is used via an Ethernet (wired) bridge, from an SDNP bridged Ethernet router 1351A running SDNP firmware 1335H, to an Ethernet (wired) bridge. ) and an SDNP bridge router 1352Z capable of WiFi communication and running SDNP firmware 1335J. In this way, SDNP datagrams can be routed or distributed across buildings or private networks from an SDNP bridge consisting of two or more SDNP-enabled routers, even when operating outside the last-mile SDNP cloud.

The SDNP bridge can be extended into systems with proprietary hardware such as cable television systems. For example, in the top schematic diagram shown in FIG. 29B, two Cable CMTS “head” servers have been modified to run SDNP firmware or software 1335L and operate as Cable CMTS SDNP Bridge 101 . Communication is carried out from this server using SDNP datagrams 1222 via cable or fiber (wired) bridges. An SDNP bridge can extend from the CMTS head to the subscriber's home. As shown in the middle schematic, via a cable (coax) bridge, an SDNP datagram 1222 is used, from a cable CMTS SDNP bridge 101 running SDNP firmware or software 1335L to a cable television set running SDNP firmware 1335M. Communication is made to the top box or cable modem 102 . In this way, an SDNP bridge extends hyper-secure communication to your home or office.

The disclosed SDNP bridging method can also be used for data transfer over wireless networks. The schematic diagram at the bottom of FIG. 29B shows two cell towers and a radio tower running SDNP firmware or software 1335N and functioning as cell tower SDNP bridges 17X and 17Y. These cell base stations and radio towers communicate wirelessly using SDNP datagrams 1222 via the cellular network, including cellular bridges 25X and 25Y. The top schematic shown in FIG. 29C shows a terrestrial microwave base station running SDNP firmware or software 1335O and functioning as a terrestrial inter-satellite link SDNP bridge 92C. SDNP datagrams 1222 are used to communicate from this terrestrial microwave base station as a microwave satellite bridge to orbiting satellites running SDNP firmware or software 1335P, namely satellite SDNP bridge 93 . Communications are then made from the satellite to subscribers or other satellites.

SDNP bridge communication can be adapted for automotive applications using cars as peer-to-peer ad-hoc communication networks. In the lower schematic diagram of FIG. 29C, an SDNP datagram 1222 is used, via the vehicle's wireless bridge, from the telematics module of vehicle 1390A running SDNP firmware 1335F to a nearby vehicle 1390B running SDNP firmware 1335F. Communication is shown to. Each car with SDNP firmware enabled forms another communication node of the dynamic telematics SDNP bridge network. This communication creates a communication network that can pass information along highways, even if there is no local cellular tower, rather than information being sent to a particular vehicle or driver.

The concept of an SDNP bridge network is particularly useful in large area communications and transport and shipping involving cars, trucks, emergency vehicles, trains, planes, boats and ocean vessels. In particular, satellite networks are required to achieve wide area coverage. A system typically includes a network connection with a satellite operator, called a satellite bridge or backhaul, and a satellite link to its clients and subscribers, also called satellite distribution. Figure 30 is a schematic representation of various satellite connections adapted for SDNP hyper-secure communication. As shown, wired connection 94A is used to transmit data packets 1222A containing SDNP datagram A and SDNP payloads, communicating from SDNP gateway 1201A to terrestrial satellite dish 92C running SDNP firmware or software 1335O. . From there, the same SDNP datagram A is relayed as data packet 1222B via satellite bridge 95A to satellite 93 running SDNP firmware or software 1335P.

Due to the delivery of hyper-secure communication data packets from SDNP to various clients, satellite 93 includes data packet 1222C containing the SDNP payload and SDNP data packet A. Satellite communications are two-way, and the downlink from satellite 93 to terrestrial clients allows for higher signal strengths and faster data rates than the uplink connection. In other words, satellite-to-ground client transmissions are possible at a higher data rate and stronger signal strength than the client's response. Examples of satellite 93 to subscriber links include satellite link 95B to Dish Internet subscriber 92G running SDNP firmware 1335T, satellite phone 92F running SDNP firmware 1335S, and high speed train 1360C running SDNP firmware 1335G. Included are a deployed satellite antenna array 92H, a satellite antenna array 92E located on a marine vessel 1360B running SDNP firmware 1335R, and a satellite antenna array 92D located on aircraft 1360A running SDNP firmware 1335Q.

For large vehicles such as ships, aircraft and trains, each system connects this hyper-secure satellite communication link to its own internal communication system or local area network. For example, FIG. 31A shows an example of a commercial aircraft connected to a communications central server 1361 running SDNP software 1335Z from a satellite antenna module 92D located in the fuselage of aircraft 1360A and running SDNP firmware 1335X. . Communications central server 1361 links to various systems including appliances 1367, data recorders and black boxes 1368, media storage module 1363, and optionally WiFi router module 1362 running SDNP firmware 1335L. To support WiFi hotspot communications, the WiFi router module 1362 connects to an array of WiFi antennas 1361 located throughout the aircraft. As shown in the example of FIG. 31B, all communications except radio-based flight control are conducted over a common satellite communications link using antenna module 92D. 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. Satellite receive antenna 1368A is smaller than satellite transmit antenna 1360A because satellite broadcast power and signal strength are greater than antenna broadcast strength and uplink capability.

Marine vessel satellite communications utilize multiple bands of satellite communications, including high altitude satellites and low altitude orbit satellites. For example, FIG. 32 illustrates the use of multiple band communications including Ku-band satellite antenna 1383A and low altitude orbit satellite antennas 1383B and 1383C. High-altitude satellites do not provide or have limited uplink capabilities, but they can cover large areas from very high altitudes, including geostationary orbits. As shown in map 1384, due to the high altitude, the area covered by each satellite is fairly large. As shown in map 1385, the low altitude orbit satellites require more satellites due to the smaller area they can cover. Therefore, the cost for covering the broadcast area is high. Depending on the course of the vessel, access to the low altitude orbit satellites may be intermittent, depending on the satellite's orbital position.

Since the Ku-band satellite antenna 1383A is primarily used for the distribution of TV and movie content, SDNP security is usually not required. Tracking and positioning are performed by antenna control 1383 . Multi-channel data from satellite antenna 1383A is fed to L-band multi-switch 1381 to separate fixed video broadcast data and digital video broadcast DVB data from which the signals are routed to television receivers and tuners 1382 . Video content is provided to central communication server 1380 . However, if secure communication is desired, the Ku-band satellite antenna 1383A can be adapted to run SDNP software.

For data from low altitude orbit satellite antennas 1383B and 1383C running corresponding SDNP firmware 1335U and 1335V, information from the satellite antennas is relayed to central communication server 1380 running SDNP software 1335Z. The communication system also enables communication within land area using a 4G/LTE cellular network 25 hosted by a mobile phone base station 17 running SDNP firmware 1335N. Communications via server 1380 are distributed throughout the vessel by SDNP WiFi routers 1362 running SDNP firmware 1335L. WiFi hotspot communications of WiFi access points 26 are distributed throughout the vessel by WiFi antennas 1361 . Communication with an SDNP client, such as a mobile phone 32 running an SDNP app 1335, facilitates end-to-end hyper-secure communication. Devices not enabled as SDNP clients will have to rely on identity pairing using WAP, AllJoyn, or other security protocols.

FIG. 33 shows an application of multi-band communication applied to high-speed trains. As shown, from a train data center server 1380 running SDNP software 1335Z connected to an SDNP gateway 1201A, via multiple PHY connections including satellite microwave 95B, 400 MHz radio 1372, and 60 Ghz microwave 1373, Communication is made to 1360C. During SDNP communications, data is relayed from SDNP data center 1380 to satellite 93 running SDNP firmware 1335P via satellite antenna 92C running SDNP firmware 1335D. Communications are made from the satellite to a train antenna array 1383V connected to a server 1361 running SDNP software 1335Y. Alternate communications are provided from the SDNP data center 1380 via 400 MHz antennas 1381 or 60 GHz antennas 1382 spaced along the train tracks. These satellites also communicate to an antenna array 1383B connected to a train communications SDNP server 1361 running SDNP software 1335Y. Communications received at the SDNP server 1361 are then distributed throughout the train by WiFi bridge 1335Z and delivered to clients as WiFi hotspots.

Communication functions in motor vehicles and commercial trucking are multifaceted and include:
・Voice Communication ・Navigation, Maps, Road Information, Alerts ・Entertainment, Hotspot Service, Infotainment ・Wireless Payment, Toll/Emergency Service, Tow Vehicle Service

Self-driving cars, or driverless cars, require additional capabilities. Based on legacy cellular networks such as CDMA (2.5G) control central units, mainly called "telematics" modules, existing automotive systems have been found to be susceptible to hacking, cyber-attacks, and privacy attacks. there is To eliminate this vulnerability, you need to protect your entire network without spending a lot of money. That is, there is no financial option to install a new network. Instead, the security infrastructure must be layered over the hardware network, as security methods are deployed from Layer 3 to Layer 7. This strategy is compatible with the SDNP last mile implementation disclosed herein.

Figure 34 shows a typical hyper-secure last-mile connection between a vehicle and the SDNP cloud. As with previous last mile connections, the specific data carriers involved in transporting packets across the last mile may vary significantly from location to location. The figure therefore shows an example representing a hyper-secure communication, regardless of the data carrier involved. As shown, at an SDNP gateway 1201A connected to a network router 67A via a wired or fiber link 24 managed by a network service provider (NSP), a data packet 1222A containing SDNP datagram A contains an SDNP payload. It is converted into a data packet 1223A composed of IP datagram B. From network router 67A, IP networkgram B is then routed as data packet 1223B to cellular base station 17 via wire or fiber link 24A owned or operated by a mobile network operator (MNO). Then, via the cellular network 25, a cellular link 28, either 2.5G, 3G, 3.5G or 4G/LTE, depending on the local mobile network operator, is used and consists of an SDNP datagram B containing an SDNP payload. Communication is made from IP data packet B to the telematics module of vehicle 1390A as data packet 1223C, which is sent as data packet 1223C. The SDNP payload embedded in the incoming data packet 1223C is then interpreted by the SDNP firmware 1335F running within the telematics module to complete the hyper-secure communication link. As such, the car's cellular last link acts as part of a hyper-secure last mile communication.

Secure information is utilized for various functions controlled by infotainment interface 1377 in the telematics module of vehicle 1390A, as shown in FIG. The built-in WiFi hotspot 1362D also delivers data packets 1223B and 1223C containing IP datagram B and IP datagram C, respectively. IP datagram B contains an SDNP payload that facilitates end-to-end hyper-secure communication to any SDNP client, such as mobile phone 32B running SDNP app 1335 . IP datagram C, which uses only a conventional IP payload, is less secure, but works on devices that do not act as SDNP clients, such as mobile phones 32A and tablets 33A. Identity pairing can be used to improve last link security for non-SDNP devices over WPA, AllJoyn, or other protocols.

Another important function in automotive communication is that of vehicle-to-vehicle communication, also called V2V communication. The purpose of V2V communication is mainly collision avoidance. However, according to the SDNP method disclosed herein, V2V communication can also function as a hyper-secure ad-hoc peer-to-peer network. FIG. 36 shows inter-vehicle SDNP communication. In this figure, cars 1390A, 1390B, and 1390C running SDNP firmware 1335F form a peer-to-peer network with each other and with cell tower 17 connected to SDNP gateway 1201A. Vehicle-to-vehicle communication can be performed using either IP datagrams or SDNP datagrams.

When communication is made from a SNP client or gateway to a non-SDNP device, the communication is done using IP datagrams. For example, at SDNP gateway 1201A, an SDNP datagram A containing an SDNP payload is converted into a data packet 1223A consisting of an IP datagram B containing an embedded SDNP payload. As shown, a data packet 1223B consisting of IP datagram B with an embedded SDNP payload is used to communicate from cell tower 17 to vehicle 1390A over 2.5G or 3G cellular link 28A. However, if a data packet 1223C composed of IP datagram B, also containing an embedded SDNP payload, is used to communicate to vehicle 1390C over 3.5G or 4G/LTE cellular link 28B. There is also Thus, the SDNP payload is delivered independently of the network used to transmit the data packets.

Ad-hoc peer-to-peer SDNP bridges or bridge networks may be formed in vehicles with SDNP firmware 1335F enabled. For example, data packets 1222B containing SDNP datagrams C, rather than IP datagrams, are used to communicate from vehicle 1390A to vehicle 1390B over V2V wireless link 1391A. Similarly, data packet 1222C containing SDNP datagram D is used to communicate from vehicle 1390B to vehicle 1390C via V2V wireless link 1391B. It does not rely on IP datagrams. Regardless of the datagram type used, the embedded content remains hyper-secure using the SDNP payload.

Another feature of the SDNP ad-hoc V2V network is its ability to perform tunneling functions. That is, data can be passed such that data passing between vehicles is not monitored or interpreted. If cellular link 28B fails due to vehicle 1390C being out of range, the alternative path is to utilize the SDNP bridge network at cellular base station 17, followed by cellular link 28A, V2V radio link 1391A and finally V2V radio link 1391A. Connected to the same caller via link 1391B. During data transfer, data packets 1223B, 1222B, and 1222C are changed from IP datagram B to SDNP datagram C and finally to SDNP datagram D. FIG. Since the SDNP payload intended for vehicle 1390C is uniquely crafted for the destination vehicle, vehicle 1390B and its driver can hack the content of SDNP datagram C even though data packet 1222B is relayed over an ad-hoc network. or cannot be monitored.

Apart from traditional last-mile communications, the same SDNP bridge technology can be used to send large amounts of data over long distances, ie digital trunk communications, with hyper-security. Three such examples are shown in FIG. a microwave trunk 98, a fiber trunk 90, and satellite trunks 95A and 95B. This feature can be considered part of the SDNP cloud, but since the single data route resembles that of last-mile communications, it employs similar methods to ensure hyper-security. For example, communication from servers 21A and 21B running SDNP software 1335Z using data packets 1222 containing SDNP datagrams via microwave trunk 98 via microwave towers 96A and 96B running SDNP firmware 1335W. It can be carried out. It is also possible to communicate directly from servers 21A and 21B via fiber trunk 98 using data packets 1222 containing SDNP datagrams. For global communications (e.g., data links across the Pacific Ocean), using earth-based satellite antennas 92A and 92B, both running SDNP firmware 1335U, via microwave satellite trunks 95A and 95B, from servers 21A and 21B to: Communications can be made to satellite 93 running SDNP firmware 1335V. As in the fiber and microwave tower example, satellite trunk communications utilize data packets 1222 containing SDNP datagrams.

The bottom line is that the security and privacy features provided in last mile communication are dependent on two communication devices. FIG. 38 contrasts four different combinations. Security and privacy increase from bottom to top. For each: (i) security: the ability to prevent unauthorized access to the communiqué; (ii) identity verification: the ability to authenticate users and regulate access and privileges based on identity; and (iii) anonymity: from surveillance. Three factors are considered: the ability to hide the caller's identity.

In the bottom example, a data packet 1223C containing an IP datagram with a sniffable IP address and IP payload is used to communicate openly from the SDNP gateway 1395 to a non-SDNP client that lacks any security measures. As such, last-mile connections are neither secure nor private. In the second-to-bottom example, communication is made from the SDNP gateway 1395 to a non-SDNP client that provides device authentication and identity pairing functionality. This communication uses data packets 1223B containing IP datagrams with sniffable IP addresses, but with encrypted payloads containing ciphertext that can only be decrypted by the device of the ID pair. Communications are not private and anonymous, but they do provide increased security, at least for a limited time.

In the second example from the top, if data packet 1223A contains an SDNP payload within an IP datagram, hypersecurity is achieved by routing the communication from SDNP gateway 1395 through any bridge or router 1397. realizable. The level of security achieved depends only on the end device, not the router. For the top example, a data packet 1222 containing an SDNP datagram with SDNP addressing, i.e., source and destination addresses not recognized by Internet DNS name servers, and an SDNP gateway 1395 performed using an SDNP secure payload. Communications between SDNP clients 1396 are hyper-secure communications with superior security, complete privacy terms, and anonymous packet routing.

Hyper-secure last-mile packet routing

Regardless of the layer 1 physical hardware and layer 2 data link algorithms and schemes used, packet routing between an SDNP client or an SDNP bridge and an SDNP gateway relies on IP datagrams to ensure data packets travel the entire last mile. transmitted and routed. Unlike data routing within the SDNP cloud as dictated by the SDNP signaling server, the IP datagram traversing the last mile is not controlled by the SDNP cloud or its signaling server. Therefore, some variation in propagation delay in the last mile is expected. Fortunately, due to the limited distance and number of possible routes for last-mile communications, this uncertainty is not very high compared to the total end-to-end propagation delay for global communications. The total propagation delay fluctuation due to last-mile variability is estimated to be less than 10% of the total delay.

FIG. 39 shows single route last mile communication between SDNP client 1400 and SDNP gateway 1401 where fixed IP addresses are used. IP datagram 1405 contains the destination IP address of M _0,0 (the SDNP gateway) and the source IP address of C _1,1 of the data packet, the SDNP client. Last link communication is performed as a single route 1404 to router 1402A. Data is routed through any number of routers R (eg, from router 1402B to SDNP gateway M _0,0 ).

As an alternative representation of last-mile network connectivity, each communication device can be represented as an IP stack representing the PHY, data links, and network connectivity as OSI layers 1, 2, and 3. For example, FIG. 40A is an IP stack diagram for single-route last-mile hyper-secure communication where static IP addresses are used. Thus, from the client device including the SDNP client C _1,1 to the SDNP gateway 1401 including the SDNP gateway M _0,0 , a single signal is sent via router 1402A, which is a WiFi router, and 1402B, which is an Ethernet router. A route last mile connection 1409 is established. Client device 1400 is connected to router 1402A via last link 1404 . Here, the PHY layer 1 physical connections and corresponding data link layer 2 of client IP stack 1411 are connected to corresponding layers 1 and 2 of router IP stack 1412A.

Router 1402A is then connected to router 1402B via Ethernet. Here, the PHY layer 1 physical connections and corresponding data link layer 2 of the WiFi router's IP stack 1412A are connected to the corresponding layers 1 and 2 of the Ethernet router IP stack 1412B. Finally, router 1402B is connected to SDNP gateway server 1401 via Ethernet. Here, the PHY layer 1 physical connections and corresponding data link layer 2 of the IP stack 1412B of the Ethernet router are connected to the corresponding layers 1 and 2 of the IP stack 1422 of the gateway. In operation, network layer 3 IP datagrams are passed transparently from one IP stack to another, specifically from layer 3 of IP stack 1411, so that data is transmitted from the router unhindered. It flows to 1412A, then to 1412B, and finally to 1422. Thus, IP datagrams are transported over virtual last-mile connections 1409 as single-route data in the network, even though the data physically traverses multiple devices.

In other words, Layer 3 network data flows the last mile independent of the physical connection used to transmit IP datagrams. That is, layer 3 last mile communication operates agnostic to the underlying layer 1 and layer 2 implementations used for data transfer. This principle can be expressed in simplified form with intermediate nodes removed, as in the schematic diagram of FIG. 40B. This includes the communication of data transfers between IP stack 1411 and corresponding computing and data storage functions 1410 and between IP stack 1422 and corresponding computing and data storage functions 1421, respectively. An SDNP gateway server 1401 is included. IP datagrams 1405 flow over last mile connections 1409 regardless of the number of mediums or routers used in the data packet delivery process. The last mile can therefore be viewed as a "data structure", an abstraction meaning any physical means by which IP datagrams are transferred between devices. However, Last Link has physical significance as the originator's connecting device must have the ability to connect to an upstream router for a communication link that cannot be established. For example, if a caller using a tablet computer with only WiFi connectivity is in a WiFi-enabled cafe, and the caller does not have the WPA password to the WiFi network, the last link cannot be established and the caller cannot Unable to connect to the SDNP cloud which is miles. Or you cannot make calls.

Another consideration in last-mile communication is that the payload of IP datagram 1405 contains all higher OSI layer information, such as transport layer 4 data, session layer 5 data, presentation layer 6 data, application layer 7 data. It can be mentioned that Except for the layer 4 data required to select the UDP or TCP transport protocol, the rest of the data contained in the IP datagram payload is specific to the disclosed SDNP communication and is not itself running SDNP software or firmware. Not interpreted by routers operating along the last mile. Therefore, only the end devices, i.e. the originator or the SDNP client and the SDNP gateway, interpret the last mile communication, even though the last mile network itself consists of a combination of various devices, carriers and network operators.

Although the SDNP payload is protected by a number of secrets, including scrambling, fragmentation, junk data insertion and removal, state-dependent formatting, and dynamic encryption, the IP address of IP datagrams traversing the last-mile network , necessarily reveals the source and destination addresses of the client device 1400 and the SDNP gateway server 1401 . Address spoofing is useful to provide some degree of anonymity in the last mile. That is, dynamically changing the source and destination addresses of IP datagrams can mislead cyber attackers. IP spoofing involves dynamically changing the IP address of the originator's connected device (referred to herein as "dynamic client addressing") or communicating with multiple SDNP gateways, i.e. multi-route last-mile It can be realized by communication.

The first method of IP address spoofing described involves dynamically changing the source address of sequential data packets. As shown in FIG. 41, successively transmitted IP datagrams A, B, and C are configured with three different source addresses. Specifically, IP datagram A 1405A has source IP address C _1,1 , IP datagram B 1405B has source IP address C _1,2 , and IP datagram C 1405C has source IP address C ₁ . _{, 3} are included. Thus, all packets entering router 1402A originate from SDNP client 1400, but the client's source address C _1,n changes dynamically, obfuscating the actual IP address and making it look like multiple communication devices. appear. To complete this "fake", the MAC address of the communication device also needs to be changed to correspond to the dynamic source address.

This method is illustrated in Figure 42A using the IP stack. In this illustration, WiFi and Ethernet are used, with communication from devices 1400, 1402A, 1402B, 1401 through corresponding IP stacks 1411N, 1412A, 1412B, 1422, but the network layer of the SDNP client 3 ID includes multiple IP addresses: C _1,1 , C _1,2 , C _1,3 . As a result, as shown in the last link schematic of FIG. 42B, the sequential data packets entering router 1402A appear to have been sent from three different client devices rather than one device. The shared PHY layer consists of WiFi standard frequencies and the data link layer connecting the devices follows established standards such as 802.11ac or 802.11n.

IP datagrams 1405N sent along network connection 1408 to router device 1402A have fixed destination IP address IP M _0,0 and sequential source addresses IP C _1,1 , IP C _1,2 , IP C _1,3 . etc. This is expressed in mathematical notation IP C _1,n , where n=1,2,3, which uniquely identifies each sequential packet. Each sequential IP packet also includes a corresponding payload SDNP 1, SDNP 2, SDNP 3, and so on. Although this description uses the mathematical shorthand notation “IP C _1,n ” to refer to each IP address, the IP address consists of an actual IP address created according to the international standards of IPv4 or IPv6. , that reserved IP addresses are excluded.

Another option to enhance security is to use multi-route packet forwarding in the last mile. In a similar manner to data transfer within the SDNP cloud, in multi-route last-mile communication audio and sequential data are parsed and fragmented before being split into individual packets and addressed to different SDNP gateways. FIG. 43 shows an example of multi-route data transfer where static IP addresses are used. In this figure, an SDNP client 1400 communicates to multiple gateways 1401A, 1401B, and 1401C. As shown, the first data packet 1405A consists of payload SDNP1 with source IP address C _1,1 and destination address M _0,0 . Data packet 1405A is routed through routers 1402A and 1402B to SDNP gateway 1401A via last link 1404A. Similarly, a second data packet 1405B consists of a payload SDNP 2 with source IP address C _1,1 and destination address M _0,1 . Data packet 1405B is routed through router 1402C to SDNP gateway 1401B via last link 1404B. The third data packet 1405C consists of payload SDNP3 with source IP address C _1,1 and destination address M _0,3 . Data packet 1405C is routed through routers 1402D and 1402E to SDNP gateway 1401C via last link 1404C.

On the path between the client device 1400 and any of the three gateways 1401A, 1401B, 1401C shown, IP datagrams are routed over multiple last links 1404A, 1404B, 1404C to multiple routers 1402A, 1402B, 1402C. be done. These routers include (i) completely independent routers using the same physical medium, such as WiFi or Ethernet, and (ii) common hardware devices, such as multiple trellis channels in a DOCSIS3 cable modem. or (iii) different physical media used for communication, eg one via WiFi and another via 3G.

For example, FIG. 44A is an IP stack diagram for multi-route last-mile hyper-secure communication over a common PHY last link 1404 and static IP addresses are used. In operation, common PHY, data link and network layers are used to communicate from SDNP client _C1,1 to routers 1401A, 1402B and 1402C as a single device connection. Address spoofing is performed using successive IP datagrams containing the static client address IP C _1,1 , but the SDNP gateway addresses IP M _0,0 , IP M _0,1 and IP M _0,3 is changed. Packet misdirection can be done algorithmically or randomly. For example, every tenth datagram sent from client device 1400 is sent to SDNP server 1401C, and the tenth datagram sent from client device 1400 has destination address IP M _0,3 and source IP address IP C _1,1 can be included. The reply from the SDNP gateway server 1401C is returned to the client device 1400 on the reverse path, ie 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, 1402C consist of a single medium, eg, WiFi. Although the last link connection is represented as a single line that splits into three, it should be understood that all physical connections are made point-to-point rather than the electrical Y-connectors used to create parallel wiring. There is a need to. Instead, the connections in the figures are meant to show the effect of the connections. That is, one PHY connection is extended to three from the PHY layer of the client IP stack 1411 . That is, it is connected to the PHY layer of IP stacks 1412A, 1412C, and 1412D. Functionally, this last link acts as a single output to three input expanders. Here, one client is connected to three router functions, regardless of whether the router functions are contained in one common electronic device or split into separate routers. Note that last link 1404, as shown, consists of a single type of communication medium, either cable, fiber, WiFi, Ethernet, or cellular.

However, the rest of the Last Mile is not necessarily the same as the Last Link and is made up of arbitrary media. An alternative last link includes multiple different PHY layers connected to independent routers. Such an implementation is shown in FIG. 44B. The figure shows an IP stack that performs multi-route last-mile hyper-secure communication using static IP addresses over multiple PHY last-links. Specifically, client device 1400 operates using a common network layer 3 interface with a static client address IP C _1,1 , but separate layer 1 and layer 3 interfaces represented as IP stacks 1411A, 1411B, and 1411C. 2 interfaces are used. In operation, IP stack 1411A is connected to router 1402A via last link 1404A and an IP datagram containing source address IP C _1,1 and destination address IP M _0,0 is transmitted to router 1402B. Similarly, IP stack 1411B is connected to router 1402C via last link 1404B and transmits an IP datagram containing source address IP C _1,1 and destination address IP M _0,1 . IP stack 1411C is connected to router 1402D via last link 1404C, and an IP datagram containing source address IP C _1,1 and destination address IP M _0,3 is transmitted to router 1402E.

A combination of dynamic source addressing and multi-route data transfers is shown in FIG. In this illustration, dynamic source addresses are used to communicate from an SDNP client 1400 to multiple gateways 1401A, 1401B, and 1401C. Thus, the first data packet 1405A consists of payload SDNP1 with dynamic source IP address C _1,1 and destination address M _0,0 . Data packet 1405A is routed through routers 1402A and 1402B to SDNP gateway 1401A via last link 1404A. Similarly, a second data packet 1405B consists of payload SDNP 2 with dynamic source IP address C _1,2 and destination address M _0,1 . Data packet 1405B is routed through router 1402C to SDNP gateway 1401B via last link 1404B. The third data packet 1405C consists of payload SDNP3 with dynamic source IP address C _1,3 and destination address M _0,3 . Data packet 1405C is routed through routers 1402D and 1402E to SDNP gateway 1401C via last link 1404C.

As such, each successive data packet contains a changing SDNP payload and dynamically changing destination addresses are used to route each data packet to a unique SDNP gateway over a different last link. To transfer data over 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 multiple band WiFi , or use multiple forms of media, such as a combination of wireless and WiFi, or other combinations of wired and wireless communications. As an example, FIG. 46A shows an IP stack for multi-route last-mile hyper-secure communication over a single PHY last link 1404 and dynamic client IP addresses are used. Client device 1400 exhibits a shared physical interface that includes layer 1 and layer 2 communications as shown in IP stack 1411A. For network layer 3, client address C _1,1 destined for SDMP gateway M _0,0 at IP stack 1411A, client address C _1,2 destined for SDMP gateway M _0,1 at IP stack 1411B, IP stack At 1411C a client address C _1,3 destined for SDMP gateway M _0,3 is generated.

The same multi-route approach can be combined with dynamic client addressing and a final layer of multiple PHYs, as shown in the IP stack diagram of FIG. 46B. As shown, the client device 1400 has, via corresponding last links 1404A, 1404B, 1404C, to the SDNP gateways with IP addresses IP M _0,0 , IP M _0,1 , IP M _0,3 , Three IP stacks 1411A, 1411B, 1411C are included that transmit IP datagrams with corresponding IP addresses IP C _1,1 , IP C _1,2 , IP C _1,3 .

Often the last link consists of a single route with multi-route data forwarding used after the first router. In FIG. 47, communication occurs from SDNP client 1400 to single router 1402A via last link 1404. In FIG. After router 1402A, dynamic source addresses are used to transmit data packets to multiple gateways 1401A, 1401B, and 1401C. In this implementation, the first data packet 1405A consists of payload SDNP1 with dynamic source IP address C _1,1 and destination address M _0,0 . Data packet 1405A is routed to SDNP gateway 1401A via last link 1404 via routers 1402A and 1402B.

Similarly, a second data packet 1405B consists of payload SDNP 2 with dynamic source IP address C _1,2 and destination address M _0,1 . Data packet 1405B is routed to SDNP gateway 1401B via last link 1404 via routers 1402A and 1402C. The third data packet 1405C consists of payload SDNP3 with dynamic source IP address C _1,3 and destination address M _0,3 . Data packet 1405C is routed serially via last link 1401 to SDNP gateway 1401C via routers 1402A, 1402D, and 1402E. As such, each successive data packet contains a changing SDNP payload, and dynamically changing destination addresses are used to route each data packet to a unique SDNP gateway over a common last link.

This last mile connection is illustrated in FIG. 48 using the IP stack. In this figure, from the IP stack 1411 of the SDNP client device 1400 with the last link 1404 leading only to the router 1402A, network layer 3 data packets are sent to three different network addresses, namely IP C _1,1 , IP C _1,2 and IP C _1,3 are sent to stack 1412A. Thus, although client device 1400 actually consists of a single client, it appears to router 1402A as three separate clients. When the IP datagram reaches router 1402A, the IP datagram is split and transmitted via different routes to different destination gateways. For example, a packet with source address IP C _1,1 goes through router 1402B to destination IP M _0,0 and a packet with source address IP C _1,2 goes through router _1402C to destination IP M 0,0. ₁ , a packet with source address IP C _1,3 is routed to destination IP M _0,3 via routers 1402D and 1402E. A routing table that forwards data packets with a particular dynamic client address C1 _,n to a particular SDNP gateway can be changed dynamically without being fixed in advance. The ability to assign IP addresses to each packet further obfuscates the fact that apparently unrelated data packets are actually all part of a single fragmented communication between two originators.

Physical Realization of Last Mile Routing

The physical realization of the last mile includes communication over various media such as Ethernet, WiFi, cellular, or DOCSIS3 compliant cable and fiber links. Regardless of the medium used, the routing of data packets in the last mile is primarily controlled by three variables:
・Media access control (MAC) address of the communication device ・Destination IP address of the IP datagram ・Destination IP address of the IP datagram

Thus, the physical medium used to carry out each hop in last-mile communication, ie layer 1 and layer 2 information, is controlled by the MAC address, and the client device and the SDNP gateway, ie the last mile, are identified by IP addresses. Payloads used in hyper-secure communications follow protocols defined in accordance with Secure Dynamic Communications Networks and Protocols, but do not affect last-mile intermediate devices, i.e. routers and other devices on the route of packets between client devices and gateways. Without SDNP executable code, such devices cannot perform SDNP functions. Therefore, the SDNP payload does not affect the routing of last-mile hyper-secure data packets.

One example is the use of Ethernet in last-mile communications. FIG. 49 graphically illustrates IPv4 and IPv6 datagrams for Ethernet communications carrying SDNP payloads, adapted from the Ethernet data packet of FIG. 9E previously described for SDNP last-mile communications. . As shown, Layer 1 Ethernet packet 188 includes data frame header or preamble 180 , start frame delimiter SFD 181 , and Layer 2 Ethernet packet 189 . Ethernet packet 189 includes destination MAC address 182 and destination MAC address 183, an optional 802.1Q tag 184 for VLAN implementation, and an Ethertype field used to specify the type of data link used. 185 (a length designation based on Ethernet II or IEEE 802.3), and a frame check 186 which contains a 32-bit CRC checksum of the entire data link packet. Ethernet packet 189 also contains variable length MAC payload 187 used to encapsulate the SDNP content 1430 of the IP datagram. Specifically, the MAC payload 187 includes an IP payload 435 consisting of an IP header 434 and a transport header 436 and an SDNP payload 1430 .

IP header 434 differs depending on whether the IP datagram follows the IPv4 or IPv6 protocol as determined by protocol field 447 containing binary 4 or protocol field 448 containing binary 6. FIG. Both preambles 440 and 444 contain transport header flags 470 that are used to determine the layer 4 transport method used, such as TCP, UDP, or maintenance functions ICMP and IGMP. Specifically, TCP transport is used for software and data files, and 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 transport header 436 varies according to transport header 470 . The IP header 434 includes a source address 441 and a destination address 442 of IPv4, or a source address 445 and a destination address 446 of IPv6.

Last-mile routing of Ethernet packets relies on both IP and MAC addresses. In the figure, the device is represented by an exemplary designation, such as MAC C _1,1 or IP M _0,0 , to which the IP or MAC address points. Here, for clarity purposes, symbolic names are used in place of numeric addresses to represent numeric addresses created according to the Internet protocol in Ethernet format. Note that the IP address IP C _1,1 follows a different format and different numbers of bytes are used for IPv4 and IPv6 names. Furthermore, the MAC address format varies depending on the layer 2 data link protocol used. Therefore, the cellular radio MAC address MAC C _1,1 is different from the MAC address of the same device communicating via WiFi or Ethernet. MAC addresses are not related to IP addresses. That is, there is no relationship between the IP address and MAC address of the same client.

Sequential last-mile routing of Ethernet packets is illustrated in FIGS. 50A-50D. Each figure contains two Ethernet packets. The upper packet consists of IPv4 datagrams and the lower packet consists of IPv6 datagrams. Since IPv4 and IPv6 use different formats with different field lengths, no two Ethernet packets displayed will usually have the same length, even if the same payload is carried. In the first step of the communication sequence, SDNP payload A travels from SDNP client 1400 to router 1402 A via last link 1404 and to SDNP gateway 1401 via gateway link 1414 . In the response from the SDNP gateway to the client, the SDNP payload G travels from SDNP gateway 1401 to router 1402 A via gateway link 1414 and to client 1400 via last link 1404 . SDNP client 1400 has numeric MAC address MAC C _1,1 and numeric IP address IP C _1,1 , router 1402A has numeric MAC address MAC R, and SDNP gateway has numeric MAC address MAC M _0,0 and numeric IP address IP C 1,1. It has the IP address IP M _0,0 . The IP address of router 1402A is not used in data packets.

Unlike the SDNP cloud, where the packet routing of SDNP datagrams is completely controlled by the SDNP network, in last-mile communication where IP datagrams are used, the SDNP payload is not interpreted or impacted on routing. . That is, each communication forwarded in the last mile includes a fixed source IP address and a fixed destination IP address. The physical medium or channel used to transmit Ethernet packets is governed by MAC addresses connecting each communication node in the last mile. For example, FIG. 50A shows a message to router 1402A containing 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 an SDNP payload. IPv4 and IPv6 Last Link Ethernet packets used for single PHY routing are shown. FIG. 50B shows the transfer of SDNP payload A over packet gateway link 1414 by corresponding Ethernet. As shown, the source and destination IP addresses are unchanged from IP C _1,1 and IP M _0,0 , but the source and destination MAC addresses are changed from their original values to MAC R and MAC M _0, changed to ₀ .

In the reply communication from the SDNP gateway 1401 to the client 1400, the SDNP payload G traverses the same network in reverse order, ie where the source and destination addresses are swapped. As shown in FIG. 50C, the source IP address and destination IP address consist of IP M _0,0 and IP C _1,1 respectively, and the MAC address includes source address MAC M _0,0 and destination address MAC R is included. In the last link communication shown in FIG. 50D, the MAC address is changed to source address MAC R and destination address MAC C _1,1 , but the source and destination IP addresses are IP M _0,0 and IP C ₁ . _{, 1} is unchanged.

One convenient way to represent last-mile communications from an SDNP client is a "simplified ” using data packets. The simplified form is useful in showing the data flow in any communication "session", ie the construction of successive data packets sent over the last mile to the SDNP gateway and the response. For example, at the top of Figure 51A is shown a series of Ethernet packets sent from an SDNP client to an SDNP gateway (shown in shortened form). Each row represents a series of data packets containing the SDNP payload, A, B, C. The leftmost column shows data packets for the last link, and the right column shows data packets carrying the same payload over the gateway link. As shown, all packets have IP C _1,1 as the source IP address and IP M _0,0 as the destination IP address. This last mile is referred to herein as SDNP single route last mile communication because only one IP address pair is used. Furthermore, the last link uses “static client addressing” because the source IP address used by the SDNP client 1400 to transmit successive data packets does not change.

The MAC addresses of different segments of the last mile are necessarily changed to facilitate Layer 2 interconnection between each communicating node and its neighbors. As shown, all successive packets traversing the last link from the client to the router use the source MAC address MAC C _1,1 and the destination MAC address MAC R. Since a single MAC address is used for the client in consecutive data packets, the last link consists of a single physical medium, ie a single PHY last link. Forwarding over the gateway link uses source MAC address MAC R and destination MAC address MAC M _0,0 .

So, although the data packets shown contain SDNP payloads, last-mile routing necessarily uses sniffable MAC and IP addresses, ie addresses that can be interpreted by unauthorized listener monitoring. By tracking packets with the same source and destination IP addresses, an unauthorized listener can infer that the data packets are likely part of the same conversation or session, even without opening the SDNP payload. , call duration, file size, data rate, and other metadata to create a caller profile. Furthermore, metaphorically like a breadcrumb, a hacker may be able to trace the origin of a call to the end device, i.e. the client device, by tracing the MAC address and IP address, thus making the caller an individual. can be specifically identified.

As disclosed herein, a superior method for preventing tracking to client devices, obfuscating associated call packets, and suppressing metadata collection is the use of MAC in last mile and last link communications. One is to dynamically change addresses and IP addresses. These ingenious camouflage methods include:
• Send data packets over changing communication media by dynamically changing the last link MAC address. This is referred to herein as "multi-PHY last link" communication.
- Impersonate the caller by dynamically changing the identity of the IP address of the client device. This is called "dynamic client addressing".
- Changing the communication path of successive data packets in the last mile by dynamically changing the IP address of the communication to and from different SDNP gateway IP addresses. This is called "multi-route last mile" communication.

The combination of multi-PHY, dynamic client addressing, and multi-route last-mile communication means that only the SDNP caller and the SDNP gateway can understand which packets are part of the same call or session, so It becomes very difficult to track and trace mile and last link communications. These methods can be used individually or in combination.

For example, the bottom half of FIG. 51A illustrates the use of multi-PHY last-link communication in single-route last-mile communication with static client addressing. As shown, each row consists of 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. Three rows represent three consecutive messages. The top row represents the first data set "SDNP Payload A", the middle row contains SDNP Payload B, and the bottom row represents the third in a series of data packets containing SDNP Payload C. . In single-route last-mile communication with static client addressing, all successive data packets use static client address IP C _1,1 and fixed destination IP address IP M _0,0 .

To implement multi-PHY last link communication, i.e. to route last link data to multiple physical media, it is necessary to dynamically change the MAC address of the SDNP client in sequential data packets. Each MAC address corresponds to a specific PHY layer, such as Ethernet 100BASE-T and 1000BASE-T connections. In the case of three physical media, the MAC address of the client is dynamically changed in packets from MAC C _1,1 to MAC C _1,2 to MAC C _1,3 . If there are only two media, to avoid pattern recognition, MAC C _1,1 , MAC C _1,2 , MAC C _1,2 , MAC C _1,1 , MAC C _1,2 , MAC C _{1, 1} , MAC C _1,2 , MAC C _1,1 , etc., the MAC addresses can be changed in random patterns. Although the source MAC address changes, the destination MAC address of the last link can be kept constant as MAC R. Since all multi-PHY paths of the last link terminate at the same router, the data path through the remainder of the last mile remains fixed as a single route communication. In other words, the last link uses multiple PHY connections, but the last mile enters the SDNP cloud through a single gateway, and the last mile consists of single route communication.

Although the multi-PHY approach provides some degree of impersonation, packet sniffing of data packets from a particular call is still possible because a common client IP address is shared. This detection method can be thwarted using dynamic client addressing (a client changing its IP address with each packet it sends). As an example, FIG. 51B illustrates the use of client dynamic IP addressing in single-route last-mile communication. The top set of data packets shows a single PHY last link connection and the bottom set of data packets shows a multi-PHY implementation. For SDNP single-route last-mile communication, the destination IP address 442 of the SDNP gateway was fixed to the numerical value IP M _0,0 for all data packets, regardless of whether the single-PHY or multi-PHY method was used. remain.

As shown, for dynamic client addressing, data packets carrying SDNP payload A have a dynamically selected source IP address 441 (including IP C _1,1 ), data carrying SDNP payload B Dynamically selected source IP address (including IP C _1,2 ) for packets and dynamically selected source IP address (including IP C _1,3 ) for data packets carrying SDNP payload C and so on. The number of dynamically selected addresses is almost unlimited, especially in IPv6. Additionally, IP addresses are reused for a period of time (eg, 1 second), so it may occur before the address is recycled. In the case of a dynamic client address with a single PHY last link, even if the source IP address changes, the value of the source MAC address 183, MAC C _1,1 in this example, remains constant. In the case of a dynamic client address in a multi-PHY last link, the value of the source MAC address 183 changes continuously from MAC C _1,1 to MAC C _1,2 to MAC C _1,3 . There is no particular mathematical correspondence between a client's changing MAC address and its dynamic IP address.

Although dynamic client addressing appears to consist of messages sent by different users, data packets still traverse most of the last mile in a single route (except the last link in multi-PHY implementations). A more sophisticated way to disrupt packet sniffing of last-mile communications is to employ "multi-route" communications. In multi-route communication, multiple SDNP gateway IP addresses are used to connect clients to the SDNP cloud. SDNP network routing is defined by the signaling server and uses the identification of each packet's SDNP tag, so whether data enters the SDNP cloud through a single gateway or through multiple gateways. Regardless, packets will be able to be routed from the SDNP cloud to their destination. FIG. 51C illustrates the use of multi-route last-mile communication with static client addressing. For all data packets indicated on the last link, the client's source IP address 441 remains static at the numerical value IP C _1,1 , but IP M ₀ for successive data packets containing the SDNP payloads A, B, C. _{, 0} to IP M _0,1 to IP M _0,3 . The IP address of the SDNP gateway is not chosen randomly, but rather is "chosen" by the SDNP signaling server to temporarily identify the gateway closest to the originator, i.e., the minimum statistical propagation delay between the SDNP client and a particular SDNP gateway. Represents a gateway. In this example, the dynamic destination address changes regardless of the PHY connection. For example, the upper set of data packets is a single PHY last link connection with client source MAC address 183 with last link numeric value MAC C _1,1 , the lower set of data packets is between different mediums _, MAC C 1,1 ₁ , MAC C _1,2 , MAC C _1,3 , etc., illustrate multi-PHY implementations where the source MAC address is changed. There is no corresponding pattern or mathematical relationship between the client's changing MAC address and the destination IP address of the SDNP gateway.

Combine dynamic client addressing with multi-route last-mile communication to achieve the most effective level of impersonation. FIG. 51D shows this new combination of security features in both a single-PHY last-link implementation (top of diagram) and a multi-PHY last-link version (bottom of diagram). In the fully dynamic version shown at the bottom, the source IP address 441 dynamically and randomly changes from IP C _1,1 to IP C _1,2 to IP C _1,3 and the destination of the SDNP gateway The IP address 442 varies independently from IP M _0,0 to IP M _0,1 to IP M _0,3 . The SDNP gateway address is chosen by the SDNP signaling server and the dynamic client address is changed in an unrelated manner so that propagation delays are minimized. As in the previous example, the upper set of data packets is a single PHY last link connection with the client source MAC address 183 with the last link numeric value MAC C _1,1 , the lower set of data packets is between different media, MAC Multi-PHY implementations are shown where the source MAC address is changed, such as C _1,1 , MAC C _1,2 , MAC C _1,3 . There is no corresponding pattern or mathematical relationship between the client's changing MAC address and the client's or the SDNP gateway's changing IP address. However, in multi-route last-mile communication, rather than all data being aggregated in a single router R, multi-PHY last-links can advantageously connect to three different routers R ₁ , R ₂ , R ₃ .

The table in FIG. 52A shows the dynamic destination address from the least secure implementation consisting of a single route last mile with a static client address and a single PHY last link (shown in the last row 10 of the table). The 10 types of last mile impersonation mentioned above are summarized, all the way to the superior impersonation provided by multi-PHY last-link with designation and multi-route last-mile communication (shown in the first row at the top of the table). The table is ordered by security strength. The notations C _1,n , M _0,n , R _n refer to the dynamically changing addresses of the SDNP client, the SDNP gateway and the last link router. Dynamic addresses are uncorrelated. Lines 7-10 show single-route last-mile communication, ie communication in which a single gateway M _0,0 is used, and lines 1-6 show multi-route last-mile communication with multiple gateways. It is shown. Except for shaded lines 1 and 4, the last link communication is connected to a single router with MAC address R. In contrast, for multi-routed communications, the shaded first and fourth rows represent multi-PHY last-link communications connected to multiple routers with dynamic MAC addresses _Rn .

FIG. 52B shows a single PHY last link static client addressing, a multiple PHY last link static client addressing, a single PHY last link dynamic client addressing, and a multiple PHY last link dynamic client addressing. Four combinations topologically illustrate the operation of single-route last-mile communication. Each box shows three consecutive data packet communications indicating the data path used. Solid lines represent data packet flows and dotted lines represent unused but possible paths. Shaded circles represent communication nodes used in last-mile communications, and empty circles represent unused communication nodes. As shown, in all examples the last mile data is routed through a single connection between router R and SDNP gateway M _0,0 to reach the termination.

In the case of static client addressing via a single PHY last link shown in the top left, each successive packet follows the same path over the last mile with a constant IP address. In the case of static client addressing over multi-PHY lastlinks shown at bottom left, each successive packet takes a different path on the lastlink according to the dynamically changing MAC address specification. The rest of the last mile consists of a single route pointed to by a constant IP address. Although a single route transfer, changing the physical medium of the last link makes it more difficult to trace the originator. In the case of dynamic client addressing over a single PHY last link, shown in the top right, each successive packet follows the same path over the last mile, with a constant destination IP address and a constant client MAC address on the last link. Instead, impersonation is achieved by changing the client ID by changing the dynamic source IP address. In the case of single-route communication where both dynamic client addressing and multi-PHY last link on the bottom right are used, even if all packets are routed to a single SDNP gateway, the client's MAC address and destination IP address are It changes dynamically and randomly.

Dynamic client addressing is a process in which one or more temporary ad-hoc IP addresses are used on a client device. This process has two stages. In the first stage, when a device first logs on to the network, it connects to the nearest router and registers its presence on the local subnet. The router then redirects the connection to the closest 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. The registration process downloads one or more IP addresses to the client device and saves the addresses in a communication data register. Client devices communicate using these IP addresses until the assigned IP addresses are updated by the local DHCP server by initiating a new session or requesting new addresses. A client device's IP address is not an Internet address because addresses are dynamically issued within a particular subnet.

In the second phase, when a client device makes a call or logs on to the SDNP network, the device automatically connects to the SDNP signaling server based on the static IP address of the SDNP server. When an incoming message is received at the SDNP server, the ad-hoc IP address or addresses are uploaded to the SDNP name server. The SDNP name server then assigns an SDNP address as pseudocode for each temporary IP address. In operation, just prior to routing, the packet's SDNP source address is replaced with the local ad-hoc IP address. In the case of SDNP dynamic addressing, the identity of the client device is spoofed by repeatedly sending packets with varying source addresses. Thus, dynamic impersonation can hide the real identity of the client device.

Upon reaching the SDNP gateway, the client IP address is discarded from the source address of the outgoing packet and replaced with the gateway server's SDNP address. Then, on each outgoing SDNP packet, the device's local IP address is swapped with a local ad-hoc IP address just prior to forwarding. Unlike Internet packet forwarding, which requires constant source and destination IP addresses and a response, SDNP forwarding uses a new IP address at each hop. Therefore, when the SDNP message finally reaches its destination, the source address of the client device is not included in the data packet. Instead, the signaling server informs the destination device about the return path of the response.

FIG. 52C illustrates topologically the operation of "multi-route" last-mile communication with four combinations of static and dynamic client addressing and single-PHY last-link and multi-PHY last-link. ing. In each multi-route communication, the destination IP address, i.e. the SDNP gateway, always changes. That is, the last mile route is connected to the SDNP cloud with different inputs. In the left column, client addresses remain static. That is, the caller's ID is not changed. In the top left example, a single PHY connection is used on the last link. In other words, the client's MAC address remains static in this case as well. The last mile is susceptible to call tracing because the last link physical medium and client IP address do not change when communicating with different destination gateways. Changing the last link medium used to transfer data packets or hiding the true identity of the originator's IP address can compensate for this weakness.

In the lower left example, multiple PHY connections are used for the last link. That is, the client's MAC address changes dynamically. Such an approach compensates for the fact that the client's identity is maintained at a static IP address. As part of end-to-end multi-route last-mile communication, each unique last link is connected to a separate router so that successive packets can reach separate SDNP gateways. So the first packet is routed over a unique PHY medium from the client with static address IP C _1,1 to the router with MAC address MAC R ₁ and then finally the SDNP with IP address IP M _0,0 routed to the gateway. A second packet with the same client address IP C _1,1 is routed via a unique PHY medium to another router with media address MAC R ₂ and then finally to SDNP with IP address IP M _0,1 routed to the gateway. Similarly, the third packet with static client IP address C _1,1 is routed over the unique PHY medium to the router with media address MAC R ₃ and then to SDNP gateway M _0,3 . With multiple routers, the opportunistic use of multiple PHY last links allows last-mile packets to travel on completely separate trajectories, even though clients with a single destination IP address are used. be.

In another implementation, shown in the upper right, a single MAC address and PHY connection is used, but the client's identity changes dynamically. As shown, the client's IP address dynamically changes from IP C _1,1 to IP C _1,2 to IP C _1,3 , while the physical medium has source media addresses MAC C _1,1 and Destination address MAC R is kept constant. The data is then forwarded to the gateways M _0,0 , M _0,1 , M _0,3 in a random order determined by the SDNP signaling server.

Good security is achieved by combining all three last-mile disguise schemes: multi-PHY last-link and multi-route communication where dynamic client addressing is used. This is shown in the bottom right of FIG. 52C. Here, multi-PHY last-links and multiple routers are used, and transmitted data packets are transmitted from clients with dynamic IP addresses to multiple SDNP gateways via multiple routes. As shown, the first packet from a client with a dynamic source network address IP C _1,1 is a multi-PHY last link defined by source media address MAC C _1,1 and destination media address MAC R ₁ . is sent to destination IP M _0,0 via multiple routes. A second data packet from the client with dynamically selected source network address IP C _1,2 is sent to a multi-PHY last defined by source media address MAC C _1,2 and destination media address MAC R ₂ . The link is sent to destination IP M _0,1 via multiple routes. A third data packet from the client with dynamically selected source network address IP C _1,3 is sent to a multi-PHY last defined by source media address MAC C _1,3 and destination media address MAC R ₃ . The link sends it to destination IP M _0,3 via multiple routes. Thus, the combination of client IP address, SDNP gateway IP address, client MAC address, and router MAC address all change randomly and dynamically, making call tracing and metadata collection nearly impossible.

Client device IP address spoofing and last-mile routing obfuscation with dynamic IP addressing to multiple gateways, multi-PHY forwarding, and multi-route forwarding can be determined by the client device or the signaling server. The misdirection process can be implemented using random number generation or other pseudo-random algorithms. A key principle is to make routing and forwarding changes unpredictable.

FIG. 52D shows two less robust versions of last-mile data transfer of Ethernet packets over multiple routes. In the diagram on the left, static client addressing and multi-PHY last-link connections are used. In the diagram on the right, dynamic client addressing and multi-PHY last-link connections are used. This implementation and the multi-PHY version shown in FIG. 52C differ in that a single router R is used in the version of FIG. 52C rather than distributing the data transfer over multiple routers. In short, in multi-route forwarding, where a single router is used in a last-link connection, sequential data from clients is distributed over multiple physical media, i.e., multi-PHY last-links, and then re-collected by a single router R. be. Data is then sent from this common router to the rest of the last mile including multiple gateway links in the last mile to multiple SDNP gateways defined by different destination IP addresses and other parallel sections (not shown). .

WiFi wireless communication can also be used as an adjunct to Ethernet for last-mile communication between SDNP clients and SDNP gateways. WiFi communication, especially when using Ethernet data packets, requires data packets with 3 or 4 MAC addresses (2 for wireless links and 1 or 2 for wired network connections). Figure 53 shows the same WiFi packet format adapted for SDNP last mile and last link communications. Only three 6B length MAC addresses are required for an access point applicable to last link communication. Specifically, it contains the receiving radio base station or "receiver" MAC address 1 field 235, the transmitting radio base station or "transmitter" MAC address 2 field 236, and the MAC address of the wired network connection to the WiFi router. MAC Address 3 field 237, Ethernet or "net". In operation, the MAC address numbers loaded into the receiver and transmitter data fields are either (i) data packets received over the air and transferred to Ethernet, or (ii) converted to wireless communications. Depending on the "To DS"/"From DS" direction setting, it is determined whether the incoming data on Ethernet is The MAC Address 4 data field 239 is optional and only used when the WiFi device is used as a wireless bridge in "wireless delivery mode". Such modes can be used for last-mile communications over long distances, such as in deserts, as an alternative to cellular or microwave networks, but the use of WiFi communications in typical SDNP last-miles is typically limited to last-link connections to SDNP clients. is focused on. Therefore, the discussion below will focus on the access point mode of WiFi routers, with the understanding that the SDNP techniques herein are equally applicable to wireless distribution mode routing.

Similar to Ethernet data packets, the preamble 230 and start frame delimiter SFD 232 contain Layer 1 data for synchronizing data and devices. The physical layer convergence procedure PLCP 232 mixes Layer 1 and Layer 2 information (related packet length, data rate, header error checking, etc.). In accordance with the IEEE 802.11 standard, the remaining data fields include a frame control 233 (which specifies the WiFi version packet type as management, control, reservation, or "data", which is the type used to transmit SDNP payloads). layer 2 data link information, including

Duration & ID 234 contains the NAV duration. However, if the WiFi device is in power saving mode, this field will contain the station ID. NAV or Network Allocation Vector is a virtual carrier sensing mechanism used in power saving modes of wireless communication systems. The NAV duration can be viewed as a counter that counts down to zero at a constant rate. This senses the medium and determines if the radio is idle or still communicating. In idle mode, a counter repeatedly counts the NAV duration to see if any sensitive wireless communication activity has been detected. A sequence control or "sequence" field 238 contains the packet sequence and fragment number that define the layer 2 packet frame. Frame check 240 includes a 32-bit CRC checksum of the entire data packet, ie an error checking data link trailer.

WiFi payload 241 is a long data field from 0B to 2,312B used to transmit WiFi payloads. For SDNP last-mile communications, this field contains IP datagrams used in last-mile communications, such as IP header 434, transport header 436, and SDNP payload 435.

IP header 434 differs depending on whether the IP datagram follows the IPv4 or IPv6 protocol as determined by protocol field 447 containing binary 4 or protocol field 448 containing binary 6. FIG. Both preambles 440 and 444 contain transport header flags 470 that are used to determine the layer 4 transport method used, such as TCP, UDP, or maintenance functions ICMP and IGMP. Specifically, TCP transport is used for software and data files, and 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 transport header 436 varies depending on transport header flags 470 . The IP header 434 includes IPv4 source address 441 and destination address 442 or IPv6 source address 445 and destination address 446 .

Like Ethernet data packets, last-mile routing of WiFi packets depends on both IP and MAC addresses, denoted by the symbolic name of the device to which the IP or MAC address points. Figures 54A-54D illustrate the sequential last-mile routing of WiFi packets. Each figure contains two WiFi packets. The upper packet consists of IPv4 datagrams and the lower packet consists of IPv4 datagrams. Since IPv4 and IPv6 use different formats with different field lengths, usually no two WiFi packets displayed will have the same length, even if the same payload is carried.

In the first step of the communication sequence, as the WiFi wireless medium, SDNP payload A travels from SDNP client 1400 to WiFi base station/router 1402W over last link 1404 and to router 1402X by wire over BS link 1415. do. The data packet is then transmitted from router 1402X to SDNP gateway 1401 via gateway link 1414 . In response from the SDNP gateway to the client, the SDNP payload G is wired over gateway link 1414 from SDNP gateway 1401 to router 1402X, then over BL link 1415 to WiFi router 1402W, and then WiFi radio used as the communication medium. and travels to client 1400 via last link 1404 . The SDNP client has the numeric MAC address MAC C _1,1 and the numeric IP address IP C _1,1 , the WiFi router 1402W has the numeric MAC address MAC W, the router 1402A has the numeric MAC address MAC R, and the SDNP client The gateway has a numeric MAC address MAC M _0,0 and a numeric IP address IP M _0,0 . The IP addresses of WiFi router 1402W and wired router 1402X are not required for last-mile communication, as shown.

Unlike the SDNP cloud, where the packet routing of SDNP datagrams is completely controlled by the SDNP network, in last-mile communication where IP datagrams are used, the SDNP payload is not interpreted or impacted on routing. . That is, each communication forwarded in the last mile includes a fixed source IP address and a fixed destination IP address. The physical medium or channel used for transmitting WiFi packets in wireless communication and the physical medium or channel used for transmitting Ethernet (registered trademark) packets in wired communication are determined by the MAC address that connects each communication node in the last mile. managed.

For example, FIG. 54A shows IPv4 and IPv6 Last Link WiFi packets used for single PHY wireless routing over Last Link 1404 to WiFi router 1402W. This includes the transmitter MAC address MAC C _1,1 and the receiver MAC address MAC W. It is then routed from WiFi router 1402W to Ethernet router 1402X with "net" MAC destination address MAC R via BS link wireline 1415 . Layer 3 network routing includes only end devices, namely the SDNP client 1400 with source IP address IP C _1,1 and the SDNP gateway 1401 with destination address IP M _0,0 . Unlike Ethernet data packets, WiFi packets have a sender or source wireless MAC address MAC C _1,1 , a receiver or wireless destination MAC address MAC W, and an Ethernet "net" address MAC Three addresses of R are included. In this direction of data transmission, wired router 1402X acts as a network destination for WiFi router devices. Thus, a WiFi data packet specifies two media: WiFi wireless last link 1404 and Ethernet wired BS link 1415 . FIG. 54B shows a diagram of SDNP payload A transported over packet gateway link 1414 by corresponding Ethernet. As shown, the source and destination IP addresses are unchanged from IP C _1,1 and IP M _0,0 , but the source and destination MAC addresses are changed from their original values to MAC R and MAC M _0, changed to ₀ .

The response communication includes exchanging the destination and source IP addresses and adjusting the MAC address accordingly. 54C shows IPv4 and IPv6 Ethernet packets used for data transfer from SDNP gateway 1401 to wire-based router 1402X over gateway link 1414. FIG. For layer 3 datagram information, the IP source address 441 contains the network address of the SDNP gateway 1401, IP M _0,0 , and the IP destination address contains the value IP C _1,1 , which is the address of the client. . The MAC address of the Gateway Link Ethernet (registered trademark) packet is MAC M _0,0 for the source address 183 and MAC R for the destination MAC address 182 .

FIG. 54D shows IPv4 and IPv6 WiFi packets for wired BS link 1415 and WiFi wireless based last link 1404 . Network layer 3 routing includes the SDNP gateway 1401 address IP M _0,0 and the SDNP client address IP C _1,1 as source address 445 and destination address 446 . The function of the MAC address field 237 labeled "net" changes according to the radio mode. In the transmit mode shown here, this field contains the wired source Ethernet MAC address of the wireless incoming data, ie the numeric MAC R of the router 1402X sending the data packet to the WiFi access point. In the receiver mode shown in FIG. 54A above, this field defines the Ethernet destination for data received as radio packets and converted to Ethernet packets. In the example shown, "net" field 237 contains the same MAC address as router 1402X, MAC R, in both transmit and receive modes. That is, WiFi access points use a single Ethernet router for last-mile connectivity.

Optionally, for multi-routed communication via the last mile, the wired router used in routing of data packets received by WiFi access points, i.e. in receive mode, is used in routing of data packets sent by WiFi access points, i.e. in transmit mode. may differ from the wired routers used in For example, the network MAC address 237 of a wireless packet in receive mode may contain the numerical MAC address MAC R ₁ , and in transmit mode the data may be changed to another router connection MAC R ₂ . Thus, optionally, the BS link can be configured with a direction dependent multi-PHY implementation. In transmit mode, the last link WiFi packet used for single PHY radio 1404 last link routing from the WiFi router 1402W to the SDNP client 1400 contains a sender MAC address 236 of numeric MAC W and a receiver of numeric MAC C _1,1 . A MAC address 235 is included. In this direction of data transmission, wired router 1402A acts as the source of data transmitted from the WiFi router device. Thus, a WiFi data packet specifies two media: WiFi wireless last link 1404 and Ethernet wired BS link 1415 .

Cellular networks are another form of wireless communication that can accommodate SDNP last-mile communication. In cellular networks, incoming Ethernet packets are repartitioned into radio-specific Medium Access Control (MAC) packets. Data may be transmitted and received multiplexed (TDMA), code-divided (CDMA), or with content spread over multiple sub-channel frequencies (OFDM). For 4G/LTE communication based on Orthogonal Frequency Division Multiplexing (OFDM), Layer 2 data packets are all stacked in three different levels of Embedded Service Data Units (SDUs) within Layer 2. Specifically, the lowest level consists of a PHY PDU 299 containing a single frame MAC SDU 304 with a MAC header 303 and padding 305 spanning 20 timeslots 300 containing PHY Layer 1 data. MAC SDUs 304 include Radio Link Control or RLC SDUs 308 .

Radio Link Control (RLC) is a Layer 2 protocol used in 3G (UMTS) and 4G/LTE (OFDM) based telephony. Radio Link Control functions respond to higher layer requests in one of three modes: acknowledged mode, unacknowledged mode, transparent mode, error detection, error correction, duplicate detection, and Provides data packetization. Data packetization includes concatenation, segmentation, and reassembly of RLC SDUs, as well as reordering and resegmentation of RLC data PDUs. For example, single-frame RLC SDU 308 inevitably limits the duration of payload transmission and data file size after time has been allocated to perform radio overhead functions. Therefore, the single-frame RLC SDU 308 needs to be segmented and mapped to different RLC Layer 2 formats (multi-frame RLC SDU 319).

As shown in FIG. 55, the mapping of single-frame RLC SDU 308 to the various K, K+1, K+2 segments 313, 314, 315, etc. of multi-frame RLC SDU 319 is not done one-to-one. As shown in the example, the mapping of single-frame RLC SDU 308 ends in the middle of K+2 segment 315 . Instead, the untransmitted portion of the remaining K+1 segments are transmitted in new single-frame RLC SDUs 312, after the padding time 310 required for radio clock synchronization has been allowed, and after the RLC header 311 has been processed. occurs only in In this way, the transmission of data encapsulated in K+2 slots resumes exactly where it left off, as if the data flow had not been interrupted. Operationally, 4G pauses playback of a DVD-encoded movie in the middle of a DVD chapter, waits a while to perform other functions, and then resumes playback exactly where it was paused. Similar to operation. As such, no data content is lost, the cellular system's RF data delivery rate is maximized with no wasted wireless bandwidth other than packet overhead (such as PDU headers), and minimal data rate degradation due to clock synchronization padding time 310. be limited.

Multiframe RLC SDUs 319 encapsulate PDCP PDUs 320 in one-to-one correspondence with each K segment. For example, K segment 313 transmits an IP payload including PDCP header 321A and data 323, (K+1) segment 314 transmits an IP payload including PDCP header 321B and data 324, and (K+2) segment 315 transmits PDCP An IP payload including header 321C and data 325 is transmitted (and so on). The term PDCP is an acronym for Packet Data Convergence Protocol, specified in 3G and 4G/LTE communication protocols, which performs functions such as compression, encryption, integrity assurance, and user and control data transfer. . The PDCP header varies depending on the type of data being transferred, such as user data, control data, and so on.

Since 4G data packet data transfer carries a continuously concatenated data stream, the payload size is not quantized into blocks of defined length like Ethernet and WiFi data packets. . Instead, the data fields 323, 324, 325 . . . carried by the corresponding layer 2 data segments 313, 314, 315 . can incrementally accommodate payloads of any size, such as Further, in OFDM-based communications, data is transmitted simultaneously on multiple frequency subcarriers in each time slot. That is, total data throughput is not simply determined by duration in a single channel, as in TDMA. However, for convenience, it is often convenient to keep the IP datagram size to match that of the Ethernet or WiFi standards.

As shown, IP header 434 differs depending on whether the IP datagram follows the IPv4 or IPv6 protocol as determined by protocol field 447 containing binary 4 or protocol field 448 containing binary 6. FIG. Both preambles 440 and 444 contain transport header flags 470 that are used to determine the Layer 4 transport method used, such as TCP, UDP, or maintenance functions ICMP and IGMP. Specifically, TCP transport is used for software and data files, and 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 transport header 436 varies according to transport header 470 . The IP header 434 includes IPv4 source address 441 and destination address 442 or IPv6 source address 445 and destination address 446 .

As an example of 4G communication where IPv6 datagrams are used, FIG. 56A shows cellular radio 1404 last link routing to cellular tower and base station 1402Q. Specifically, in source MAC field 300A, the RLC PDU defines the cellular source media address as MAC C _1,1 , which is the client device. Similarly, the destination MAC field 300B specifies the cellular receiver media address as the MAC BS representing the cellular tower and base station. Layer 3 network routing consists only of last mile end devices, namely the SDNP client 1400 with the source IP address IP C _1,1 indicated in the source data field, and the SDNP gateway 1401 with the destination address M _0,0 . be. As mentioned above, the data fields 323, 324, 325 do not necessarily correspond to specific sections of the IPv6 datagram data payload. Here, data field 323 consists of source IP address 445 , destination IP address 446 , and part of SDNP payload A 435 including transport header 436 . Data fields 324 and 325 carry the remaining unsent portion of SDNP payload 435 .

FIG. 56B shows a data packet of response message SDNP payload G from cellular tower and base station 1402Q to mobile client device 1400 over cellular last link 1404. FIG. Here, the source and destination addresses from previous data packets are swapped. That is, the cellular source media address 300A is loaded with the media address MAC BS, the cellular destination media address 300B is the MAC address of the client, MAC C _1,1 , and the IPV6 datagram source IP field 445 is IP M _0,0 . , and the destination IP 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 previous examples.

Multi-PHY communication over the last link can include any of the aforementioned media used in various combinations. Multi-PHY implementations include multiple PHYs that transmit data at the same or different data rates and use common or different Layer 2 protocols such as USB, Ethernet 10BASE-T, 100BASE-T, 1000BASE-T, DOCSIS3. can include wired connections for Wired physical media can consist of Ethernet or USB compliant network cables, coaxial cables, fiber optics, or twisted-pair copper connections for DSL, but with reduced performance.

Wireless multi-PHY communications can include WiFi, cellular, satellite, or a combination of proprietary radio formats operating in radio and microwave bands. Wireless last link communications can also include short-range technologies such as Bluetooth® or microcellular networks such as Japan's PHS. Wireless protocols include 2G, 2.5G, 3G including analog TDMA, GSM, CDMA, UMTS, OFDM or WiFi protocols such as 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac , 4G/LTE cellular formats, and proprietary formats for satellite or custom radio links. The term "multi-PHY communication" used in the context of this disclosure refers to the combination of both the OSI physical layer and the data link layer, i. means and should not be construed as limiting the claim to mean only Layer 1 physical media.

FIG. 57A shows an example of multi-PHY communication where common Layer 2 protocols are used, including Ethernet, WiFi and cellular implementations. In the top multi-PHY Ethernet example, two Ethernet cables consisting of wired or fiber links 24A and 24B running 100BASE-T and 1000BASE-T respectively are used and router 27 to desktop computer 36 . Desktop 36 is shown running SDNP software 1335C to facilitate hyper-secure communications in the last mile.

In the central multi-PHY WiFi example, a notebook is sent from WiFi router 100 through two WiFi channels, shown as WiFi link 29A running the 801.11n protocol at 2.4 GHz, and WiFi link 29B communicating at 802.11ac at 5 GHz. A communication is made to the book 35 . In order to operate in multi-PHY mode, the notebook's built-in multi-band antenna 26B must allow the notebook 35 to transmit and receive signals on multiple frequencies simultaneously. Similarly, a multi-band antenna 26 should allow the WiFi router to transmit and receive signals on multiple frequencies simultaneously. A notebook 35 is shown running SDNP software 1335C to facilitate hyper-secure communications in the last mile.

In the bottom multi-PHY cellular communication example, two different radio channels are used, including cellular links 28A and 28B with corresponding frequencies of 1.8 GHz and 900 MHz, through multi-band cellular tower 18A to cellular base station 17. to the tablet 39 at the same time. In the example shown, the cellular link consists of a 4G/LTE network. As shown, the built-in multi-band antenna 18B should allow the tablet 39 to transmit and receive signals on multiple frequencies simultaneously. A tablet 39 is shown running the SDNP app 1335A to facilitate hyper-secure communications in the last mile.

Such multi-PHY communication using a common Layer 2 protocol requires a hacker to have physical access to two different Layer 2 data links, each with their own security, thus confusing cyberattacks. can be done. Additionally, if the client is running SDNP software 1335C, SDNP app 1335A, or SDNP firmware 1335B (not shown), routing of SDNP payloads over multi-PHY connections uses unique dynamic security credentials, Intercepting and interpreting SDNP packets by real-time hacking becomes very difficult.

FIG. 57B shows an example of multi-PHY communication in which mixed Layer 1 media and Layer 2 protocols are used. In this example, a combination of cellular, WiFi and satellite systems are used to transmit the last link data. The mixed media multi-PHY communication example at the top uses a combination of a 100BASE-T Ethernet wired or fiber link 24B and an 802.11ac WiFi link 29B operating at 5 GHz, from the WiFi router 100 to the desktop computer 36. Communication takes place. Desktop 36 is shown running SDNP software 1335C to ensure hyper-secure communications in the last mile. An example of this is a combination of wired and wireless communications. In this case, wireless packet sniffing cannot intercept or monitor wired data. Mixed Ethernet and WiFi, this multi-PHY last-link distributed scheme consists of secure desktop computers within a building or campus that communicate with private servers housed securely in limited-access server rooms. It is particularly suitable for deployment in corporate office networks where

In the middle mixed-media multi-PHY communication example of FIG. 57B, two different radio technologies are used, and communication takes place from a mobile phone 32 incorporating a multi-band antenna 18C. The 802.11n protocol at 5 GHz is used as an example, with one PHY connection communicating from WiFi link 29C to WiFi router 100 and antenna 26 . A second PHY connection, cellular link 28 C, uses a 1.8 GHz carrier operating in 4G/LTE protocol to facilitate last link connections to cellular tower 25 and base station 17 . Since the cellular tower 25 and the WiFi antenna 26 operate in unrelated systems, this multi-PHY approach completely hides the relationship between the data packets carried by the multiple physical media of the last link. A mobile phone 32 is shown running the SDNP app 1335A to ensure hyper-secure communications in the last mile.

The example at the bottom of FIG. 57B shows a similar method of implementing combined cellular and satellite multi-PHY last link communication. Via two long-range wireless networks, from satellite/cell phone 32Z running SDNP app 1335A to cellular tower 25 and base station 17 via cellular link 28D at 1.8 GHz and illustratively at 1.9 GHz. Communications are provided to communications satellite 92 via satellite link 95W. Communications are then made from satellite 92 to ground satellite antenna and base station 92B via broadband link 95X. This is not necessarily the same frequency as the client communication.

Another variety of multi-PHY communications is shown in FIG. 57C. In this example, multiple physical media are presented that share a common protocol but allow for multiple simultaneous communication channels through frequency division. Such systems require high-bandwidth media because performance degrades as the operational load increases, ie, as more users utilize the bandwidth and throughput capabilities of the medium. Only three of these very high bandwidth media are currently available. (ii) a DOCSIS 3 cable system using optical fiber; and (iii) a multi-GHz low altitude satellite communication system. Specifically, in the multi-PHY cable system illustration at the top, multiple bands are used, from a set-top box or cable modem 102B running SDNP firmware 1335M to a cable over coax or fiber 105 running the DOCSIS3 protocol. A communication is made to the CMTS 101 .

The lower diagram shows a multi-PHY satellite network in which multiple carrier bands 95Z formatted with proprietary communication protocols are used to communicate from satellite-enabled mobile phones 32Z running SDNP application 1335A to communication satellites 92. ing. Communication between satellite 92 and terrestrial satellite antennas and base station 92B uses trunkline protocol 95X, which mixes thousands of calls, making it difficult for a hacker to identify and intercept a particular call, allowing clients to The use of multi-PHY communication on multiple bands on link 95Z ensures client hyper-secure communication.

Another example of a data packet used in multi-PHY last link routing is shown in FIG. In this figure, communication from the SDNP client 1400 to the router 1402A is via two separate PHY connections comprising, as an example, Ethernet wired or fiber links 24A and 24B running protocols 100BASE-T and 1000BASE-T respectively. is done. Router 1402 A is then connected to SDNP gateway 1401 via gateway link 1414 . Both Ethernet packets define the source IP address 445 ie 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 through a PHY implemented by a wire or fiber link 24A includes a destination MAC address 182 containing MAC R and a source MAC address 183 containing MAC C _1,1 . An Ethernet packet B routed via a PHY implemented by a wired or fiber link 24B contains a destination MAC address 182 containing MAC R and a different source MAC address 183 containing MAC C _1,2 ( This defines an alternate PHY connection).

By changing the source media address from MAC C _1,1 to MAC C _1,2 , the Ethernet communication is redirected from the 2.6 GHz 100BASE-T connection to the 1000BASE-T connection. In operation, data packets from the SDNP client device 1400 are fragmented and then distributed between SDNP payload A and SDNP payload B according to the SDNP algorithm and shared secret. Fragmented by SDNP payload A carried in Ethernet packet A over wire or fiber link 24A and SDNP payload B carried in Ethernet packet B over wire or fiber link 24B Data is transferred over the multi-PHY last link.

Another example of a data packet used in multi-PHY last link routing is shown in FIG. In this figure, the 802.11n protocol at 2.4 GHz and the 802.11ac protocol at 5 GHz are used as an example, respectively, to transmit signals from SDNP client 1400 to WiFi router 1402W over two separate PHY connections, including WiFi links 29A and 29B. is communicated to. Next, router 1402 W is connected to router 1402 X via BS link 1415 , and router 1402 X is connected to SDNP gateway 1401 via gateway link 1414 . Both WiFi packets define the source IP address 445, ie the client device as IP C _1,1 and the destination IP address 446 of the SDNP gateway as IP M _0,0 . WiFi packet A, routed via the PHY implemented by WiFi link 29A, has a wireless transmitter source MAC address 236 containing MAC C _1,1 , a wireless receiver destination MAC address 235 containing MAC W, and MAC R. A network destination MAC 237 is included. WiFi packet B, which is routed via the PHY realized by WiFi link 29B, has a wireless transmitter source MAC address 236 including MAC C _1,2 , a wireless receiver destination MAC address 235 including MAC W, and MAC R. A network destination MAC 237 is included.

The change in source media address from MAC C _1,1 to MAC C _1,2 redirects the transmission from the 2.6 GHz WiFi radio to the 5 GHz transceiver. In operation, data packets from the SDNP client device 1400 are fragmented and then distributed between SDNP payload A and SDNP payload B according to the SDNP algorithm and shared secret. Fragmented data is transferred over the multi-PHY last link with SDNP payload A transmitted in WiFi packet A over WiFi link 29A and SDNP payload B transmitted in WiFi packet B over WiFi link 29B. .

FIG. 60 shows yet another example of data packets used in multi-PHY last link routing. In this figure, 4G/LTE protocol at 1.8 GHz and 4G/LTE protocol at 900 MHz are used as an example, respectively, to transmit signals from SDNP client 1400 to cellular tower 1402Q over two separate PHY connections, including cellular links 28A and 28B. is communicated to. Next, router 1402 Q is connected to router 1402 X via BS link 1415 , and router 1402 X is connected to SDNP gateway 1401 via gateway link 1414 . Both cellular radio packets define the source IP address 445, namely the client device as IP C _1,1 and the destination IP address 446 of the SDNP gateway as IP M _0,0 . A cellular packet A routed through the PHY provided by cellular link 28A includes a radio transmitter source MAC address 300A containing MAC C _1,1 and a cellular tower destination MAC address 300B containing MAC BS. A cellular packet B routed over the PHY implemented by cellular link 28B includes a radio transmitter source MAC address 300A containing MAC C _1,2 and a cellular tower destination MAC address 300B containing MAC BS.

The change in source media address from MAC C _1,1 to MAC C _1,2 redirects the transmission from the 4G/LTE cellular radio at 1.8 GHz to 900 MHz. In operation, data packets from the SDNP client device 1400 are fragmented and then distributed between SDNP payload A and SDNP payload B according to the SDNP algorithm and shared secret. Fragmented data is transferred over the multi-PHY last link with SDNP payload A carried in cellular packet A over WiFi link 28A and SDNP payload B carried in cellular packet B over WiFi link 28B. .

As noted above, multi-PHY communications can also include heterogeneous media. In that case, the data packets for each connection must be formatted according to the Layer 2 protocol of the corresponding physical medium. For example, FIG. 61 illustrates hybrid last link communication including Ethernet and WiFi. In this figure, 100BASE-T and 802.11ac at 5 GHz respectively are used as an example, from the SDNP client 1400 over two separate PHY connections, including an Ethernet wired or fiber link 24A and a WiFi link 29B. Communication is made to WiFi router 1402W. Next, router 1402 W is connected to router 1402 X via BS link 1415 , and router 1402 X is connected to SDNP gateway 1401 via gateway link 1414 . Both WiFi packets define the source IP address 445, ie 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 through a PHY implemented by a wired or fiber link 24A, includes a source MAC address 183 containing MAC C _1,1 and a destination MAC address 182 containing MAC W. FIG. WiFi packet B, which is routed via the PHY realized by WiFi link 29B, has a wireless transmitter source MAC address 236 including MAC C _1,2 , a wireless receiver destination MAC address 235 including MAC W, and MAC R. A network destination MAC 237 is included.

The transmission is redirected from Ethernet to WiFi by changing the source media address from MAC C _1,1 to MAC C _1,2 . In operation, data packets from the SDNP client device 1400 are fragmented and then distributed between SDNP payload A and SDNP payload B according to the SDNP algorithm and shared secret. With the SDNP payload A transmitted in Ethernet packet A over wired or fiber link 24A and the SDNP payload B transmitted in WiFi packet B over WiFi link 29B, the fragmented data is transferred to multiple PHY last links. transferred through

FIG. 62 shows a mechanism of hybrid last link communication composed of WiFi communication and cellular communication. Here, the SDNP client 1400 is connected to two different radio base stations through two different physical connections. Specifically, WiFi link 29A connects to 2.4 GHz, 802.11n WiFi router 1402W, and cellular link 28B connects to station 1402Q with a carrier frequency band of 900 MHz, 4G/LTE. Routers 1402 W and 1402 Q connect to router 1402 X via BS links 1415 A and 1415 B respectively, and router 1402 X connects to SDNP gateway 1401 via gateway link 1414 . Both WiFi and 4G cellular packets define the source IP address 445, ie 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 physical layer via the connection that constitutes WiFi link 29A has _a transmitter MAC radio source address 236 that constitutes MAC C 1,1 and _a MAC radio receiver destination address 235 that constitutes MAC W. , and MAC network destinations 237 that make up MAC R. The cellular B routed physical layer connection realized by the WiFi link 29B includes a MAC source address 300B _comprising MAC _C 1,2 and a MAC destination 300B comprising MAC BS.

Changing the destination media address from MAC C _1,1 to MAC C _1,2 redirects transmissions from the WiFi LAN to the cellular network. In operation, data packets from the 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. Transfer of fragmented data over the multi-PHY last link is performed by SDNP payload A carried by WiFi packet A over WiFi link 29A and SDNP payload B carried by cellular packet B on cellular link 28B. be done.

Another form of multi-PHY communication uses physical media, which can support multiple channels at different frequencies and use different protocols for each data packet. Such an implementation can be simplified by using a DOCSIS3-based cable distribution system running SDNP software. The OSID communication stack for the DOCSIS3 cable distribution system for SDNP is shown in FIG. The figure shows a layer 3 network covering cable modem termination equipment CMTS 101 and cable connection equipment such as cable modem CM 103 and set top box STB 102, in addition to layer 1 PHY connections and layer 2 data links. It is Specifically, the cable modem termination system equipment CMTS 101 and its associated stack 378 include a Layer 1 PHY connected to the cloud server 22 and the Internet 20 or to a video headend, IPTV system, or VoIP system (not shown). A network interface 361 is included. A combination of network interface 361 and data link layer 366 is included in 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 and specifically to link level control LLC 369 . Link Level Control 802.2 LLC 369 consists of a hardware independent protocol defined according to IEEE specification 802.2. This packet data is then modified by link security 368 to apply basic packet security. This is mainly done to prevent unauthorized viewing of content such as pay-per-view unicast broadcasts.

The Layer 1 PHY Cable Interface 362 is then routed to the corresponding Layer 1 PHY Cable Interface 363 in the Cable Modem CM 103 or Set Top Box STB 102 via the distribution network 102, which consists of either coaxial cable 104 or optical fiber 91. Send a data frame. Cable interface 363 represents the PHY layer of the cable network interface shown as OSIO communication stack 379 of cable modem CM 103 or set top box STB 102 . Upon receiving a data packet, Cable MAC Interface 371 interprets the cable MAC address and passes the payload to Link Security 372 for decryption and finally to Hardware Independent Link Layer Control 802.2 LLC 373. interpretable. Input data to the CM or STB cable network communication stack is then routed through transparent bridging 374 to the CM or STB device interface communication stack (specifically Device Independent Link Layer Control 802.2 LLC in accordance with IEEE 802.2 specifications). 375). This packet is then passed to HSD & IPTV MAC block 376 or WiFi 802.11 MAC block 377 to update the packet's MAC address. For WiFi communications, the data packet is then passed from the 802.11 MAC block 377 to the WiFi PHY Layer 1 radio interface 365 for transmission over the WiFi antenna 26 . For wired connections, data packets are passed from HSD and IPTV MAC block 376 to Ethernet or HDMI interface block 364 for connection to TV 39 or desktop 36 .

The PHY layer and data link layer establish connections from the CMTS to any number of cable modems (CMs), as previously described. Within the CMTS communication stack 378 and the CM communication stack 379, data packets are transmitted over OSI layer 3 as IP datagrams IPv4, IPv6 or ICMPv6 using IP addresses recognized by DNS name servers in the cable network or the Internet. Prepared in layers 360A and 360B respectively. For last-mile communication, SDNP datagrams using IPv4 or IPv6 data packets with an SDNP source or destination IP address are generally not available. This is because connecting devices that are not enabled by SDNP software or firmware cannot interpret routing addresses in SDNP datagrams.

The operation of transport layer 4 within a cable modem network varies from device to device. For CMTS 101, layer 4 transport layer 1420 of OSI communication stack 378 uses UDP exclusively because its operation requires real-time communication (eg, streaming video data). From this, it can be said that the cable communication 102 is more like an SDNP real-time network than the Internet. Because cable modems are interoperable as clients (i.e., end communication devices) with both the Internet and cable networks, the CM 103 or STB 102 OSI communication stack 379 layer 4 transport layer 1420B uses UDP for real-time operation. Internet data using TCP. Such usage is not desirable for OTT carriers using VoIP over Internet. This is because cable networks interpret IP datagrams as data and automatically use TCP and transport protocols, which creates problems in QoS, latency, and propagation delay for real-time communications. This problem does not occur with cable modems that support SDNP. When a CM or STB is running SDNP firmware or software, the SDNP software will state when TCP usage is guaranteed (for software or files) and when not (i.e. for real-time data). is determined according to

The application layer, OSI layers 5-7, sits above transport layer operations 1420A in CMTS 101 and above transport layer 1430B in CM 103 or STB 102 . In CMTS 101, these applications typically handle communication tasks such as SNMP 1431A, an Internet standard protocol for collecting and organizing information-connected devices on IP networks. Other features include DHCPv4 1432A and DHCPv6 1433A. DHCP (an acronym for Dynamic Host Configuration Protocol) is a client and client that automatically provides IP hosts with necessary routing information such as dynamically generated (non-static) IP addresses, default gateways, and subnet masks. Both protocols of the server. Although specific to Internet generation (i.e. IPv4 or IPv6), dynamic IP address generation functions such as NAT gateways and SNMP are generic and can be used by both CMTS 101 and CM 103 or STB 102 DOCSIS3 cable Applies equally to the system.

The application layer implementation of the secure dynamic communication network and protocol disclosed herein, when implemented as SDNP firmware 1430A running on the CMTS 101 operating system, performs any number of unique tasks including: can.
- Operate as a pass-through without interpreting the SDNP payload 1430; In this case, CM 103 must be enabled to open and read the SDNP payload. That is, CM 103 must be an SDNP client.
- Operates as a last mile remote SDNP gateway. That is, it interprets the content of the SDNP payload and transforms the content into DOCSIS3 specific messages (including link security) for forwarding to CM 103 . In such cases, CM 103 need not run any SDNP client software or firmware.
- Works as a last-mile SDNP bridge. Convert IP datagrams to SDNP datagrams and send SDNP datagrams to CM 103 . In this case, the CM 103 needs to run SDNP client software or firmware to connect to the SDNP bridge. That is, it is necessary to form an ad-hoc SDNP "floating" network.

As shown, the OSI communication stack 379 of the CM 103 and STB 102 contains many applications classified as OSI layers 5-7, including the previously mentioned communication-related applications SNMP 1431B, DHCPv4 1432B, and DHCPv6 1433B. include. Another feature, the utility TFTP 1434B (Simple File Transfer Protocol), is primarily used in DOCSIS 3 as a means of downloading software and software updates from the CMTS to cable modems and set-top boxes throughout the cable network. In cable networks, HTTP 1435B, or Hypertext Transfer Protocol, is used to display dynamic menus, primarily useful in smart TVs. Other applications (abbreviated as "Otr" 1436B) include gaming apps, diagnostics, IPTV apps, and video recording functions. The SDNP firmware 1430B running on CM 103 or STB 102 is enhanced to establish hyper-secure last mile communication and connectivity with all users and last links regardless of whether CMTS 101 is running SDNP software. be.

FIG. 64 shows the structure of a DOCSIS3 data packet adapted to deliver an SDNP payload 1430. FIG. As shown in the figure, PHY Layer 1 includes physical media device frames 390 of variable length and variable duration, and data link Layer 2 MAC data including preambles 391, variable length payloads or codewords 392, and guard times 393. contains. Preamble 391 includes either an upstream preamble or a downstream preamble, depending on the direction of communication. For upstream preambles, preamble 391 includes physical media device PMD header 398, MAC header 399A, and data PDU 400A. For downstream preambles, preamble 391 includes MPEG header 401, MAC header 399B, and data PDU 400B. Upstream preamble data PDU 400A and downstream preamble data PDU 400B include MAC destination address (DA) 403B and MAC source address (SA) 403A. The contents of variable length payload 392 may include short codewords 394 or long codewords 397 .

Short code word 394 includes payload 395A with data A and error correction 396A with FEC A. For long codewords 397, the payload is divided into multiple payload blocks 395A, 395B, and 395C carrying DataA, DataB, and DataC. Each payload contains its own error checking block 396A, 396B and 396C with corresponding data FEC A, FEC B and FEC C. After error checking, the data delivered from DOCSIS3 contains 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 is packed into one continuous IP datagram, in this example one IPv6 datagram. This includes an IP source address 445, an IP destination address 446, a data field 435 containing the SDNP payload 1430, and a transport header 436 containing layer 4 data. Thus, DOCSIS3 uses a packet-switched data protocol to flexibly distribute data over cable networks.

As shown in FIG. 65A, data packets are transmitted on multiple channels, ie, different frequencies, on the hybrid cable fiber network. In DOCSIS 3.0, the frequency range for data channels is 5 MHz to 1,002 MHz, which includes analog TV signals 1440 (triangle), QAM data 1441, and a "diplexer" control channel 1443. Phase 1 of DOCSIS 3.1 extended the frequency range to 1,218 MHz and added DOCSIS 3.1 data channel 1442 for OFDM modulation in the frequency band above the current channel allocated primarily to QAM. is facilitated.

OFDM is preferred over QAM modulation schemes because it allows for closer spacing of the channels. Comparing the modulation schemes, QAM frequency distribution 1445A has wider tails of spectral components than OFDM frequency distribution 1445B. Specifically, the spectral sideband width from f ₀ to f ₋₅₀ , the bandwidth from the carrier edge to the frequency where the signal drops -50 dB, is 4.3 normalized frequency units in the QAM frequency distribution 1445A, but OFDM frequency distribution 1445B is only 0.4 normalized frequency units. The narrower spectrum allows more communication channels to fit in the same spectrum, increasing the overall network bandwidth and maximum aggregate data rate. Phase 2 deployment of DOCSIS 3.1 extends the frequency range to 1,794 MHz. Much of the band originally allocated to QAM data 1441 is replaced with new channels explicitly allocated to OFDM data 1442 .

In a DOCSIS compliant cable network, one CMTS unit can support many CMs and manage available channels. While the CMTS can dynamically allocate downstream communications and channel selection as needed, upstream communications require a controller to easily accommodate situations where multiple CMs are trying to transmit data at the same time. Tension management is required. Therefore, each modem must request an uplink channel from the CMTS before sending data. This process is illustrated in FIG. 65B. This process consists of a series of communication operations between CMTS 101 running SDNP application 1335L and CM 103 running SDNP firmware 1335M. The routing of IP datagrams in multi-PHY communication uses the IP addresses "IP CMTS" and "IP CM1" and multiple MAC addresses. For example, CM 103 uses "MAC CM1", CMTS 101 uses "MAC CMTS1", "MAC CMTS2", "MAC CMTS3", and "MAC CMTS4". In the top diagram showing the frequency versus time graph, CM 103 issues a request to transmit RQST 1445A on a dedicated channel.

If no response is received, a second RQST 1445B is sent to obtain a response from CMTS 101 on another channel in the form of MAP data packet 1446 . The contents of MAP data packet 1446 indicate when to send to CM 103 and which channels can be used for upstream communication. After receiving MAP data packet 1446, CM 103 transmits its own upstream data flowing in parallel over two channels in uplink data packets 1447A and 1447B. The division of data transmitted simultaneously over two channels, shown in the middle diagram, is called channel bonding. Channel bonding is a means of increasing the communication bandwidth and data rate between CMTS and CM. It is also a dynamic means of ensuring that available bandwidth does not go unused. In the diagram below, CMTS 101 responds by channel bonding four channels (1448A, 1448B, 1448C, 1448D) and transmitting data in parallel and of different durations.

In both upstream and downstream communication over hybrid fiber cable networks, bandwidth is dynamically allocated among multiple channels and divided into small time segments called "minislots." 65C shows upstream communication from CM 103 to CMTS 101. FIG. Such upstream communication typically includes a single message or request to send. In the illustrated example, data is transmitted on frequencies f1 and f2 consisting of a total of five time minislots. As shown, minislots 1, 2, and 3 are transmitted at time intervals K, (K+1), and (K+2) on frequency f1, and minislots 4 and 5 are transmitted at time intervals K and (K+1) on frequency f2. , and not at (K+2). Upstream data packet 1450A, shown in abridged form, has an IP source address "IP CM1" and an IP destination address of the last mile communication, namely "IP M _0, " which is the gateway node of the SDNP network hosted by server 1201A. ₀ ” is specified.

For last link communication, upstream data packet 1450A specifies "MAC CM1" as the cable modem's source MAC address and specifies _a channel on frequency f1 as the PHY medium, in this case MAC destination "MAC CMTS1". do. Data packet 1450A containing SDNP payload A occupies a total of three minislots: minislots 1, 2, and 3, even though they collectively transmit one data packet and payload. However, one data packet and payload are transmitted over these three minislots. In contrast, minislot 4 and minislot 5 each contain only one data packet. That is, data SDNP payload B and SDNP payload C corresponding to 1450B and 1450C respectively are included. Like data packet 1450A, packets 1450B and 1450C both specify the destination IP address of the SDNP cloud, specifically SDNP gateway node M _0,0 .

However, with respect to the MAC destination address, rather than specifying the same MAC address and physical medium as the first packet, both packets 1450B and 1450C specify the MAC destination address "MAC CMTS2." This address can be used to specify that data packets 1450B and 1450C are transmitted on a different frequency than data packet 1450A (in this case frequency f ₂ instead of frequency f ₁ ). The actual values of these frequencies are dynamically mapped by CMTS 101 and are not specifically specified. A DOCSIS3 compliant system is therefore a multi-PHY solution, allowing a single CMTS unit to simultaneously communicate with cable modems or set-top boxes on multiple frequencies and using multiple protocols such as 256 QAM and OFDM.

Rather than allowing the CM and CMTS to decide which data packets use a common carrier channel or frequency as is the common case in DOCSIS3 systems, the disclosed secure dynamic communication of last mile communication Depending on the network and protocol, the SDNP Client CM 103 specifies different MAC destination addresses to force communication on multiple frequencies and channels (ie, multi-PHY operation). Since data packets 1450A and 1450B/C of CM 103 specify different destination MAC addresses, namely MAC CMTS1 and MAC CMTS2 respectively, these data packets automatically trigger multi-PHY operation over the last link. do. Alternatively, if the CMTS takes another easy way of requesting unique channel assignments (e.g., using command or control requests), then this instead of using MAC addresses to invoke multi-PHY communication. Alternatives can be used.

FIG. 65D shows a downstream data flow diagram from CMYS 101 to CM 103, how bonding can be used to achieve high data rates in multi-PHY downstream communication. As shown, all data packets specify a source 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 CMTS 101 MAC source address specification. As shown, data packet 1450G containing SDNP payload G specifies a MAC source address "MAC _CMTS6 " corresponding to communication on frequency f6 transmitting data in minislots 15 and 16. FIG. Data packet 1450H contains SDNP payload H and specifies MAC source address "MAC _CMTS7 " corresponding to communication on frequency f7 transmitting data in minislots 17 and 20. FIG. Data packet 1450I containing SDNP payload I specifies MAC source address "MAC _CMTS8 " corresponding to communication on frequency f8 transmitting data in minislots 21, 22 and 23. FIG. Finally, data packet 1450J containing SDNP payload J specifies a MAC source address “MAC _CMTS9 ” corresponding to communication on frequency f9 transmitting data in minislot numbers 24 and 25. FIG. In this way, related and unrelated data packets can be transferred from CMTS 101 to CM 103 in parallel using multi-PHY methods without channel contention or data collisions with concurrent upstream data. can be sent.

Hyper-secure call routing

Hyper-secure call routing according to the secure dynamic communication networks and protocols disclosed herein can be performed using one of three methods for command and control.
- Tri-channel communication. Call or communication routing involves three sets of servers: an SDNP media server for audio, video, or data file transmission, an SDNP signaling server for selecting call routing, and a telephone number and corresponding SDNP address. controlled by an SDNP name server for storing static mappings.
- Dual channel communication. Call or communication routing is accomplished by two sets of servers: an SDNP media server for audio, video, or data file transmission, and an SDNP name server that routes calls and maps telephone numbers to corresponding SDNP addresses. controlled by
• Single channel communication. Data transport, route planning, and SDNP address mapping are all performed by a single set of servers.

In general, tri-channel communications are more resistant to cyberattacks because no single set of servers contains all the information about a call. In all cases, however, the SDNP network uses distributed processing to limit the information stored on a particular server. Additionally, during data transfer via single, dual or tri-channel communication, the SDNP media server connects to the fourth type of server, the DMZ server. The DMZ server is used to store the SDNP shared secret required for processing the SDNP data payload, such as scrambling, splitting, mixing, junk data insertion/removal, encryption, etc. In operation, incoming data packets received by the media server are sent to the DMZ server where the data packets are modified before being returned to the media server. The media server is unaware of how the data packets were modified, or the logic or algorithms used to process the data. Executable code and tables stored on the DMZ server are encrypted to prevent code analysis. Also, the DMZ server works offline without a network or Internet connection.

The following diagram shows an example implementation of tri-channel SDNP communication and the sequence used to initiate a call or send a file over the network. The operation of dual-channel communication can be viewed as a slight modification from tri-channel communication, with the functionality of an SDNP name server built into the signaling server. Single-channel communication consists of integrating all three operations into a network of multifunction servers acting as SDNP communication nodes.

Fragmented data transfer within the SDNP cloud is typically performed using dynamic mesh routing, but fewer routing options are available for last-mile communications. Specifically, are continuous data packets routed to (i) a single SDNP gateway (i.e., single-route last-mile communication) or (ii) multiple SDNP gateways (multi-route (last mile communication), or Other last mile routing options include dynamic source addressing and multi-PHY last link connectivity. These delivery options are specified in IP data packets generated at the signaling server. Despite the fact that these SDNP data packets specify source and destination IP and MAC addresses, it is not possible to know the exact path a particular data packet takes in the last mile communication. . Instead, the intermediate path is determined by the operation of routers, devices owned by local network operators, mobile network operators, and network service providers providing last-mile services, rather than by the SDNP signaling servers. Thus, last mile communication resembles a skipping rope with fixed ends but a myriad of uniquely shaped paths between them.

In more detail, the terms single-route, multiple-route, and mesh-route communication refer to the paths of media packets. In other words, we mean the path that the "content" of a pass travels back and forth between callers. Tri-channel, dual-channel, and single-channel communication, on the other hand, refer to the command and control system used to manage transmission over a network of SDNP nodes. Given the foregoing, the following series of diagrams illustrate the series of steps or "process" used in making a call or initiating a communication in accordance with the secure dynamic communication network and protocol of the present disclosure. .

FIG. 66 is an abstract representation of a single-route, last-mile network for tri-channel communications consisting of an SDNP client 1600, IP routers 1602A, 1602B, and 1602C, a signaling server 1603A, an SDNP name server 1604A, and an SDNP gateway 1601. be. These computer servers, as shown in the figure, are _{network nodes} named and an SDNP communication node used to facilitate network communication by IP address. Network connection 1610 facilitates the last link between client C _1,1 and its nearest router 1602A, and network connection 1611 facilitates the gateway link between SDNP gateway M _0,0 and its nearest router 1602B. , network connection 1612 facilitates the gateway link between SDNP signaling server 1603A and its nearest router 1602C, and network connection 1616 interconnects topologically adjacent routers 1602A and 1602C. The IP address of a router is not used as a source or destination address in IP datagrams, so the notation "R" is used for all layer 3 routers to indicate that they are routers. Although the Layer 1 and Layer 2 discussion gives each router a unique ID, this is not relevant to the discussion of Layer 3 call routing in IP networks. The SDNP signaling server 1603A (node S) connects via network connection 1613 to the SDNP name server 1604A (node NS) and via a plurality of network connections 1614 to the SDNP cloud nodes M _0,n . Signaling server 1603A also connects to other signaling servers (not shown) via network connection 1615 .

Making a call (ie, establishing a "session") using an SDNP network involves performing the following sequence of steps, starting with a call made by an SDNP client.
1. SDNP call (or callout) request2. SDNP address request3. SDNP address distribution4. SDNP routing directives5. Initiate an SDNP call (or callout)

The first step, Call Request, is shown in FIG. Here, the originator, client 1600 at address “IP C _1,1 ” uses IP datagram 1620 to access signaling server 1603A at address “IP S” via paths 1610 , 1616 and 1612 . The datagram's command and control payload 621 contains Layer 4 data transport that uses TCP to ensure data integrity, delivery, urgency, security credential information, and the party to call or "recipient". A number of call parameters are specified, including contact information for When calling another SDNP client (ie, in the case of an "SDNP call"), this contact information includes the Confidential ID (CID) of the called client, data present in the client's SDNP phone book. For "callouts" (calls to parties who are not SDNP clients), the contact information includes a phone number. The CID of the SDNP client is anonymous in nature, known only to the SDNP nameserver, but the phone number is never spoofed. The phone number in the C&C payload is encrypted to protect the called party's privacy. Alternatively, the entire C&C payload 1621 can be encrypted. The C&C payload 1621 may be in ciphertext form, but the IP address of the IP datagram 1620 cannot be encrypted. This is because routers 1602A and 1602C cannot route the datagram once it is encrypted.

The second step, "SDNP Address Request", is shown in FIG. Here, the SDNP signaling server at address “IP S” connects to the SDNP name server at address “IP NS” via path 1613 of IP datagram 1622 . The command and control payload of the datagram defines Layer 4 data transport as TCP and contains the CID or encrypted telephone number of the called party (recipient). For SDNP calls, name server 1604A translates the CID to the SDNP address of the called client. For callouts, name server 1604A decodes the recipient's phone number and then converts it to the SDNP address of the nearest SDNP gateway to the recipient's location. 69, name server 1604A then passes the client or gateway's SDNP address in IP datagram 1623 from source address "IP NS" to signaling server 1603A at address "IP S".

Signaling server 1603A utilizes the SDNP addresses of the originator and recipient to route the call as a hyper-secure connection if the recipient is an SDNP client, or to the nearest SDNP gateway if the recipient is not an SDNP client. FIG. 70 shows the process of preparing routing instructions and delivering these instructions to all media nodes required to complete the caller's connection. As shown, the originator's delivery request contained in the delivery and urgency fields of C&C payload 1621A is used to select the datagram delivery method, as shown in operation 1650, after verification of the account information is complete. used for Delivery methods usually have VIP, guaranteed, or special categories and affect the routing of packets or subpackets (if packets are split or fragmented). For example, VIP delivery uses the fastest route for data transfer, but minimizes reading of the same route by other clients. In guaranteed transmission, duplicate data packet fragments are sent over the network (ie, using redundancy) to ensure timely delivery of the fastest packets and ignore late packets. In combination with the SDNP address data obtained from C&C payload 1623A, operation 1651 maps the best route from the originator to the recipient's SDNP address, or to the gateway closest to the recipient if the recipient is not an SDNP client. do. The urgency request data contained in the C&C payload 1621A may be categorized into package urgency operations 1652 based on criteria such as snail delivery (no rush), normal delivery, priority delivery, urgent delivery, etc., in order of decreasing propagation delay. used for the selection of

The urgency request information is then used for routing selection by operation 1653 and zone selection for sub-packet routing. These parameters, along with any applicable security credential information 1621B, compose routing commands and control packets through operation 1660. FIG. These C&C data packets are delivered to the last-mile participating communication nodes using TCP-specified Layer 4 transport, but use UDP as the Layer 4 transport protocol when used to deliver real-time data. Contains routing information for For example, a last mile routing created according to zone U1 security credential information is generated as an IP datagram 1625 containing a C&C payload 1626 used to route data from client node C _1,1 to SDNP gateway node M _0,0 . be done. The IP datagram 1625 is delivered to the SDNP client using TCP data transport, while the C&C payload 1626 titled "Last Mile Routing U1" contains the data used to route the packet in real time. As such, it requires the use of UDP as the layer 4 transport mechanism. The SDNP C&C packet composition operation 1660 also generates a number of other C&C messages that are delivered as TCP data packets to nodes in the SDNP cloud. An example of a cloud command data packet is an IP datagram 1627A containing a C&C payload 1628A used to route data from SDNP M _0,0 to SDNP M _0,1 . As shown in FIG. 71, these SDNP routing indication packets are sent over serial connections 1612, 1616, 1610 to media nodes, including client nodes C _1,1 , to SDNP gateway nodes M _0,0 , and also to It is distributed to other nodes in the SDNP cloud via connection 1614 .

The initiation of a call is shown in FIG. In this figure, a media SDNP datagram 1630 containing SDNP data (sound, video, text, etc.) is added to an IP header containing a C&C data packet 1626, IP C _1,1 to IP M _0,0 and SDNP It is routed from client 1600 via last link network connection 1601 to routers 1602A and 1602B and finally reaches SDNP gateway 1601 via gateway link 1611 . Together, the identification tag, security zone, preamble, and SDNP data fields make up the payload of the SDNP media packet contained in media SDNP datagram 1630 .

The routing of the aforementioned SDNP call, i.e., a hyper-secure call, from _SDNP gateway M _0,0 to SDNP client C 7,1, which includes mobile phone 32 running SDNP app 1335A, is illustrated in the simplified network diagram of FIG. 73A. . SDNP datagram 1631A, including media SDNP payload A and header 1628A, is routed between media nodes at SDNP addresses M _0,0 and M _0,1 . However, the SDNP gateway 1601 has two addresses: an IP address “IP M _0,0 ” for last-mile communication and an SDNP address “SDNP M _0,0 ” for communication within the SDNP cloud. Since the content of each SDNP datagram changes as the packet traverses the SDNP cloud, it is clear that the content such as sound, video, and text contained in SDNP media payloads A, B, and C will not be the same, Content from 20 different conversations or communiqués may be included. Data routing and packet security mechanisms within the SDNP cloud are disclosed in the aforementioned U.S. patent application Ser. No. 14/803,869 entitled "Secure Dynamic Communication Network and Protocol," It describes how the content and encryption of data packets traveling anonymously through the SDNP cloud dynamically and continuously change, eventually converging on the client's device.

SDNP datagram 1631B, including media SDNP payload B and header 1628B, is thereby routed between the media nodes at IP addresses IP _0,4 and M _0,f . Data exiting the SDNP cloud via SDNP gateway 1601 B is converted from SDNP datagrams to IP datagrams 1632 . IP datagram 1632, including header 1628C and SDNP media payload C, uses security credential information for zone U2, which constitutes the last mile. IP datagram 1632 is then routed over the last mile over wire or fiber link 24 to network router 27 and then over cellular network 25 and cellular link 28 to cell phone 32 . Since the mobile phone 32 is an SDNP client, communications over the last mile remain hyper-secure. In this simplified example, all data packets reaching the last mile from the cloud are routed through a single SDNP gateway 1601B. In practice, multiple SDNP gateways can be used for last-mile data routing.

The last mile communication in "Call Out" is shown in Figure 73B. Routing through the SDNP cloud uses the same SDNP datagrams 1631A and 1631B as used for calls to SDNP clients, but the SDNP gateway 1601B is the last server running the SDNP software. Therefore, IP datagrams containing non-SDNP payloads are used for last-mile communication in callouts. That is, IP datagram 1635 is routed from gateway IP M _0,0 to the PSTN at IP address IP C _7,9 to carry voice in the form of VoIP. The PSTN converts the VoIP call format to a traditional telephone call format using the phone number and analog sounds in sound packets 1636 . In such cases, Last Mile does not constitute hyper-secure communication.

In the multi-route last-mile communication illustrated in FIG. 74, command and control data packets delivered by SDNP signaling server 1603A include C&C data packets 1625X sent to client 1600 over data links 1612 and 1610, data link 1614X, and and a C&C data packet 1627Y sent to SDNP gateway 1601Y on data link 1614Y. Other C&C data packets (not shown) are sent to other servers hosting media nodes via data link 1614X. C&C data packet 1625X is sent from address "IP S" to address "IP C _1,1 " and contains the C&C payload that constitutes last mile routing U1. Last mile routing U1 includes two different routing instructions. one with tag ₁ and preamble ₁ from 'IP C _1,1 ' to 'IP M _0,0 '; _{, 1} ” are included. As shown in the example, a C&C data packet sent to a communication node in the SDNP cloud includes a data packet sent from 'IP S' to 'IP M _0,0 ' containing the instruction SDNP cloud routing 1 and a data packet sent to “IP M _0,1 ” containing an indication of SDNP cloud routing 2.

SDNP group call

The last mile media packet routing from the SDNP client 1600 to multiple SDNP gateways, shown in FIG. 1630Y is included. Data header 1626X containing tag 1 and preamble 1 is routed from address "IP C _1,1 " to address "IP M _0,0 " and data header 1626Y containing tag 2 and preamble 2 is routed to address "IP C _1,1 ” to the address “IP M _0,1 ”.

Data flowing backwards from the SDNP cloud to the client via multi-route communication includes header 1626 U, tag 8, preamble 8, SDNP data U, source address SDNP gateway address M _0,0 , and Included is a data packet 1630U containing the destination address "IP C _0,0 ". At the same time, this data also includes a data packet 1630V comprising a header 1626V, a tag 9, a preamble 9, SDNP data V, a destination address SDNP gateway address M _0,1 and a destination address “IP C _0,0 ”. The SDNP application program running on the SDNP client 1600 then combines the incoming data packets SDNP data U, SDNP data ∨, etc. to recreate the message text and voice (sound).

Routing-directed C&C data packet delivery can be extended to initiate three-way or group calls, group messaging, and other multi-client communications. In such group communiques or "conference calls", client messages are sent to multiple recipients simultaneously. This group function is invoked by a caller requesting a group call to first define a group of clients to connect to and then by the signaling server to route the data packets associated with each individual group call. Tell the required media nodes how to handle. An example of group call routing instructions is shown in FIG. Here, signaling server 1603P sends routing instructions to SDNP client 1600A over data link 1614A and to multiple media servers 1600Z in the SDNP cloud over data link 1614Z.

Thus, TCP data packet 1627A containing last mile routing U1 is delivered from signaling server 1603P at address "IP S1" to the SDNP client at address "IP _C1,1 " to "set up" a group call with the caller. . C&C data packets, represented by exemplary TCP data packets 1627Z, are sent simultaneously across the SDNP cloud in zone Z1 over data link 1614Z from signaling server address "IP S1" to various destination addresses "IP M _0,y ". distributed (where y represents an integer variable). Collectively, the routing directives of the SDNP cloud establish packet routing from the originator's gateway across the SDNP cloud to two or more other SDNP gateways that are closest to the called SDNP client.

As shown in the example, other SDNP clients may be located in different geographic regions and may be within separate security zones such as zones U7 and U9. In some cases, these clients may be far enough away from the signaling server 1603P that another signaling server 1603Q can be used to plan packet routing for these SDNP clients. Signaling server 1603Q communicates routing instructions for zone U9 to SDNP client 1600M via data link 1614M and to SDNP client 1600L via data link 1614L. For example, C&C data packet 1625M carries a last mile routing indication U9 from the signaling server at "IP S4" to the SDNP client 1600M at its address "IP _C9,1 ". Another C&C data packet (not shown) is similarly sent to the SDNP client at address "IP _C9,4 ". Data packet 1627H containing an indication of last mile routing U7 is sent from signaling server 1603Q at "IP S4" to client 1600H at address "IP _C7,1 " via data link 1614H.

Signaling servers 1603P and 1603Q of nodes S1 and S4 also exchange information as C&C data packets over data link 1613Z. This information is used to establish which parts of routing are performed by signaling server 1603P and which parts are performed by signaling server 1603Q, dividing the routing task among multiple signaling servers. In the example, signaling server node S1 manages last mile routing for zone U1 and the SDNP cloud, and signaling server node S4 manages last mile communications in zones U7 and U9.

Data routing during a call or communiqué is shown in FIG. 77A. Here, the voice sent by SDNP data 1 in data packet 1630A is routed by header 1626A to the closest SDNP gateway media node M _0,0 from the originator at IP address "IP C _1,1 ". This data packet is repacketized for SDNP cloud transport and sent to gateway media nodes M _0,4 and M _0,8 . The path taken by packet routing within the SDNP cloud is unknown to conference call participants, cannot be controlled centrally, and changes dynamically according to network conditions. In this example, all SDNP data packets in the SDNP cloud are fragmented using techniques such as dynamic scrambling with junk data insertion and removal, mixing, and segmentation, in addition to anonymous addressing and dynamic encryption. It uses mesh data transmission. As shown in the example, cloud transport directs incoming communications of SDNP gateway node M _0,0 to other gateways (in this example, SDNP gateway nodes M _0,4 and M _0,8 ).

A data packet 1630H carrying the caller's voice, i.e., SDNP data 1, exits gateway node M _0,4 and uses header 1626H, using zone U7 security credential information, to media "IP M _0,4 ". It is routed from the node to client _1600H at "IP C 7,1". Header 1626H is given to client 1600A in C&C data packet 1627A prior to preparing the media data packet, as illustrated in FIG. In this way, all media packets carrying real-time data can be ready without delay when the content is ready for data transmission. Timely routing of dynamic data is essential to achieving good QoS in real-time networks. Failure to do so may result in unacceptably long propagation delays.

Once routed through the SDNP cloud, the SDNP data 1 payload is delivered to the conference participants (i.e., SDNP clients 1600M and 1600L) in zone U9, i.e., from the gateway media node M _0,8 to the client IP address "IP C _9,1 ” and “IP C _9,4 ”. These last mile data packets 1630M and 1630L include headers 1626M and 1626L specifying identifying packet tags, tag8 and tag9 used to recognize content associated with the same conversation, carry SDNP embedding instructions, keys, seeds, etc. and the 'L4' data field used to request UDP for Layer 4 transport. The data routing instructions sent from the signaling server use the TCP transport protocol to ensure their accuracy, but since the media packet content is real-time data, it uses the more suitable UDP Layer 4 protocol instead of TCP.

Figure 77B shows the same conversation. Here, content originates from client 1600H in zone U7. That is, client C _7,1 initiates a conversation. To compare this data with the audio content from client C _1,1 , the payload is identified as "SDNP data 5" in all data packets. Aside from the uniqueness of the payload, the only change from the previous figure is that the last mile source and destination IP addresses of data packets 1630H and 1630A are reversed. Specifically, for the SDNP user in zone U7, the source IP address of data packet _1630H is changed to IP C 7,1 and its destination is SDNP gateway address IP M _0,4 . For zone U1, the source IP address of data packet 1630A is changed to IP C _1,1 and its destination is changed to the SDNP gateway address IP M _0,0 . Multiple conference call participants speak simultaneously and data packets from _SDNP client node C _1,1 sent to other call participants, including client node C 7,1, are sent to client node C _7,1 It must be assumed that they may occur simultaneously and respond to client node C _1,1 .

At network level 3 for last mile communication, data collisions for opposite direction traffic do not occur. However, in physical link layer and data link layer 1 and 2, the use of time multiplexing for last mile communication avoids contention for the same communication link. However, this arbitration is done so fast that the communication appears to be full-duplex communication with no voice packet delay. In both Figures 77A and 77B, the direction of client data flow in zone U9 (cloud to client data flow) is unchanged. However, in FIG. 77C, zone U9 client node C9,1 initiates the conversation. In this case, client nodes C _9,4 , C _1,1 and C 7,1 are all recipients of voice, ie _SDNP voice data 6 .

In an alternative embodiment shown in Figure 78, the group call can be a mix of SDNP calls to SDNP clients and "call-out" calls to regular phone numbers. Similar to the call or communiqué shown in FIG. 77A, the voice sent by SDNP data 1 in data packet 1630A is transmitted by header 1626A from the originator at IP address "IP C _1,1 " to the most media node M _0,0 including media node M 0,0 . routed to the closest SDNP gateway. This data packet is repacketized for SDNP cloud transport and sent to gateway media nodes M _0,4 and M _0,8 .

As shown in the example, cloud transport directs incoming communications of SDNP gateway node M _0,0 to other gateways (in this example, SDNP gateway nodes M _0,4 and M _0,8 ). A data packet 1630H carrying the caller's voice, i.e., SDNP data 1, exits gateway node M _0,4 using a header 1626H and using zone U7 security credential information to the media of "IP M _0,4 ". It is routed from the node to client _1600H at "IP C 7,1". The SDNP data 1 payload is also delivered to the conference call participants via the gateway media node M _0,8 . The last mile communication from this SDNP gateway consists of two types of connections. Specifically, a hyper-secure connection to the SDNP client 1600M, and an unsecured "call-out" connection to PSTN 1, including traditional telephone systems that do not use VoIP or packet protocols. Last mile data packets 1630M and U9 sent to zone U9 SDNP clients at address "IP _C9,1 " include headers 1626M, SDNP It contains preamble 9 information used to convey embedding instructions, keys, seeds, etc., and an 'L4' data field used to request UDP for Layer 4 transport.

Gateway node M _0,8 also sends IP packet 1635 to PSTN 1 at address IP C _7,9 . In this case, rather than sending a payload containing SDNP data 1, the IP payload has been converted to a VoIP sound package and can be intercepted by packet sniffing. Telephone switching system PSTN 1 then passes this unprotected IP packet to telephone 37 indicated by POTS data 1636 (including the called telephone number followed by a continuous analog line connection between telephone 37 and PSTN 1). converts analog POTS telephone connections to Because this connection and other callout connections are not hyper-secure, the content transmitted by Callout Last Link is subject to hacking, eavesdropping, and other surveillance techniques. Unless a hierarchy is implemented that defines client access privileges, the security of the entire call is compromised by the weakest link, for example all participants in a group call can hear everything.

This point is illustrated in the table of FIG. 79A. The group call now consists of hyper-secure participants on the SDNP network client nodes C _1,1 , C _{7,1 , C 9,1 , and C 9,4 with telephone} numbers “Ph#1” and “Ph #2” participants. As shown, the SDNP client C _1,1 is the host of the group, and the _SDNP clients C 7,1 , C _9,1 are the participants (i.e. they can listen to other participants' utterances). can hear and speak itself), the SDNP client C _9,4 is a "listener" (can hear but cannot speak, i.e. its voice cannot be heard by the participants). The participant on the callout phone number "Ph#1" is also a listening and speaking participant, while the caller on "Ph#2" is only allowed as a callout "listener" and cannot speak in the group call. can't. The group host defines these listening and speaking privileges, ie user authentication, at call setup time.

Look again at the table in the column titled "Normal Calls" and note that everyone in the group call, callers authorized by the host, can hear the call. Callers who attempt to hack into the call, or callers who are not authorized by the host, cannot be connected or forced into the call, nor can they be notified that the call is occurring. cannot be determined. The same method applies to group chats. Group chat participants can read and write messages, while view-only members can only read comments and cannot insert their own text on the chat.

With authentication and identity verification for controlling network access made in accordance with the present disclosure, the SDNP system provides privacy features not available in traditional group chats and group calls. This function is invoked by selecting private mode. For example, clicking the padlock or other privacy icon before texting or speaking. In such cases, communications are only sent to authenticated SDNP clients and not to SDNP clients whose identities have not yet been confirmed by authentication. Additionally, it is not sent to callout listeners or participants on insecure devices. This point is clearly shown in the table above. Private calls in the "Unauthenticated SDNP Clients" column have all Group Call clients muted (muted) on both their microphones and speakers. On the other hand, in the "Authenticated SDNP Clients" column, all SDNP clients can listen and participants C _1,1 , C _7,1 and C _9,1 can also speak in addition to listening. However, all callout devices have both microphones and speakers muted, so only authenticated SDNP clients can listen and comment in private mode. In this way, group calls with multiple SDNP clients with guaranteed identities, or group calls on callout connections with unknown parties, can be performed on the public portion of the call without exposing sensitive information on the callout device. can participate in each other. To exclude a "callout" caller from a private discussion, simply have the SDNP participant click the private icon before speaking or texting. After the private discussion is over, the callout caller is reconnected by undoing the private button. While the callout caller is disconnected (i.e. basically "on hold"), the SDNP system can play waiting music, silence it, or use white noise (such as the sound of the sea or rain). ) can be played.

Group chat text messages can be managed in the same way. In a normal group chat, all text messages are sent to the SDNP app on the SDNP client device and sent to all call chat members by SMS text messages. Text messages can only be sent by participants. Text messages sent by 'listener' or 'read-only' chat members are ignored and not forwarded to the chat group. If a participant clicks the lock icon or privacy icon before sending a message, the message will only be sent to the SDNP client and not to the callout client. For SDNP clients receiving private messages, once their identity has been authenticated, the messages are made available for reading. If the client's identity has not been verified, the message may be blurred, obscured, obscured, or displayed with an icon such as a padlock. If the client goes through the authentication procedure and the identity is confirmed, it will be displayed normally.

Combining identity verification with privacy privileges regulated by the SDNP network system certification, it will no longer be possible to open private texts or eavesdrop on private calls, even in group chats and group calls, simply by hacking the device. . This functionality cannot be guaranteed by relying solely on device security parameters, information that can be hacked locally. The barriers to hacking system parameters are very high, as fake security or identity credentials will not match system logs and will be rejected as invalid SDNP clients.

You can also further enhance the privacy during group calls and group chats. This unique embodiment of the hyper-secure last mile table in FIG. 79B is referred to herein as a hyper-private call or hyper-private chat. To use hyperprivacy, a caller or message must comply with four criteria.
• All recipients of group call communiqués must be SDNP clients, not callout devices.
• Calls or texts must be pre-selected as hyperprivate communiques, whether they are calls, texts or images.
Recipients of group call or group chat communiqués must have their identities verified by authenticating the connection.
• Recipients of hyperprivate communiques must be pre-selected as "private" participants or private listeners.

The first three criteria are essentially the same as the private party example in a group call above, but the fourth criterion, calling callers eligible to receive hyperprivate calls or texts as "private" SDNP clients. The requirement to read is great and further enhances access to sensitive information. For example, as shown in the table, SDNP participant clients C _1,1 and C 7,1 and _SDNP listener client C _9,4 are all designated as "private" parties of the group call. On the other hand, SDNP client C _9,1 is only designated as a participant and not as a private participant. By definition, a call participant or listener cannot be registered as a private party.

As before, during a normal call, all participants, namely SDNP clients C _1,1 , C 7,1 , and C _9,1 , and callout participant Ph# ₁ , listen to all conversations. , you can read all text messages and also speak and send text messages at any time. On the other hand, "listeners", including client _C9,3 , Ph#2, can listen to all conversations and read texts, but cannot speak or send messages in group calls or chats. . However, in a hyperprivate call, selecting the switch or icon to designate a hyperprivate communiqué will automatically block all unauthenticated parties in a group call or chat, as well as all parties other than "private" parties. is disabled. Furthermore, all callout connections and unauthenticated users are also disabled. So, during operation, when a private participant selects the privacy icon, only private participants (including the host of the private group) can view, browse, talk, and text the group. All other participants' microphones and speakers are muted, and likewise they cannot send or receive texts or attachments to the group. Specifically, in hyper-private mode, only clients C _1,1 and C _7,1 can both listen and talk, and read and write text, once authenticated, while private clients C _{9, 4} can only listen to conversations or read group texts.

With the last mile routing control features described above, group calls and group chats can be managed in a variety of ways. For example, a group call host can decide who can call or join a group, who can talk and text, and who can only listen and read. For standard private calls, selecting private mode allows all SDNP clients (once authenticated) to participate in the communique with the same privileges as during standard non-private group communication. In hyperprivate mode, only SNDP clients defined as private participants and private listeners can communicate during hyperprivate mode operation.

The method of choosing who is and who is not qualified as part of a hyperprivate communique, ie, as a private participant or listener, can be set in several ways. In ad-hoc hyperprivate group communication, the group host determines the callers and non-callers of a private call. In SDNP "system-defined" hyper-private group communications, the SDNP network operator predetermines the callers and non-callers of a private call. In rule-based hyper-private group communication, the SDNP network defines rules that determine who is eligible to be a private caller and who is not. These rules may be based on the company's employment list. For example, vice presidents and above can participate in hyperprivate calls. In government and security organizations, criteria may be set by US security clearance, passport number, police badge number, etc. The SDNP-enabled last-mile communication method defined in this disclosure may support either of these illustrated scenarios, or use other criteria to separate the population into two groups, thereby hyper-private You can set which groups have access to the communiqué and which do not.

Although this concept can be extended to multiple groups, hierarchical access criteria are generally more suitable for dispatcher-based professional communication systems than telephony. The application of the SDNP approach to professional communications is therefore not addressed in this application.

One of the challenges of group calls is that everyone tries to speak at the same time. Overlapping conversations create confusion, poor listening, and unnecessary pauses. This problem can be solved by using the push-to-talk feature (a feature that emulates a transceiver or CB radio). Only one participant can speak at a time in push-to-talk or PTT operations. When a participant wants to talk, pressing the switch will mute everything else on the network mic and put all other participants in the group call into listen-only mode. As shown in the table in FIG. 80A, in a normal PTT conversation, when the host presses the PTT button (see "Host PTT" column), it takes precedence over the group call and the caller who presses the talk button will take precedence over all other callers, including All other callers, including callout phone connections, will have their microphones automatically muted and placed in listener-only mode. If the host does not press the PPT button, the PTT functionality is handed over to other SDNP participants on a first-come, first-served basis, as shown in the column labeled "Other PTT." SDNP nodes (C _9,4 , Ph#1, etc.) designated as listeners or callout devices can hear the PTT conversation, but their microphones are muted for the entire group call.

The PTT feature can be extended to a private push-to-talk feature by using the SDNP last mile feature that identifies callers whose identities have been authenticated to the network. When the privacy feature or privacy icon is selected, all unauthenticated participants are removed from the group call and their speakers and microphones are muted. Callout connections are muted as well, as they are inherently unauthenticable. Mute is two-way, so excluded participants cannot hear the conversation and their microphones are disconnected. For authenticated participants, the operation has the same priority as normal PTT. That is, the host has priority to speak, otherwise authenticated participants can invoke the PTT call feature on a first-come, first-served basis.

The table in Figure 80B illustrates the concept of a hyperprivate group call that can be extended to PTT functionality. In normal operation, the PTT function is the same as the previous case. However, in hyperprivate mode, only authenticated parties previously designated as private participants or private listeners can participate in the hyperprivate conversation. For example, in hyperprivate mode, SDNP clients C _9,1 and C _9,5 cannot speak or listen because they were not previously registered as private participants or listeners. Similarly, all callout-connected devices are muted during hyperprivate mode operation. In this way, access to various parties of a PTT group call can be explicitly controlled. Muting is the process of excluding some participants (such as callout listeners) from receiving data packets that carry the audio of the conversation while continuing to supply data packets to unmuted participants. In the disclosed method, data packets are sent individually to all participants in a normal conversation and only to a subset of the list when muting is activated by the user of the client.

In another embodiment of the invention, data packets are sent in broadcast mode to all participants of the group call, but using a different encryption method. For a normal conference call, data packets are sent to all users using an encryption scheme in which all participants hold a copy of the decryption key. In private or mute mode, data packets broadcast to users utilize different encryption, with only selected users sharing the decryption key. Participants with this decryption key can join the conference call, and participants without this key cannot. An advantage of using broadcast packets is that less bandwidth is required for last-mile communication than sending individual packet requests. In yet another embodiment, a single packet is sent to the gateway, which the signaling server duplicates and distributes to all participants in normal call mode and select callers in private or mute mode.

Hyper-secure file storage

The "Secure Dynamic Communication Network and Protocol" was invented and developed as a hyper-secure communication system for telephony and real-time data transfer, where the inherent security mechanisms of the SDNP network and protocol enable hyper-secure file and ideal for data storage. Very simply, in a hyper-secure call, when scrambled and encrypted data is sent from one caller to another as anonymous fragmented data, in other words, one SDNP client sends another When end-to-end communication to an SDNP client occurs, hyper-secure file and data storage is such a form in which data transmission is halted and buffered indefinitely until called back. can be thought of as communication. Hyper-secure distributed file storage is also referred to as decentralized data storage.

This simplified explanation that this storage is communication that stops in the middle of packet delivery is a more technically accurate statement than it first appeared. US patent application Ser. No. 14/803,869, referenced above, explicitly disclosed and described the operation of temporarily buffering data packets until another packet arrives. Buffering within the nodes of the SDNP cloud is done in milliseconds rather than months, and the SDNP system has the ability to wait or hold data without losing information and recover the original content. Of course, such a simplified implementation lacks some features required for long-term file management, such as directories, menus, file recycling, security credential updating, and other features. there is

An example of data transmission from a client to a fragmented data storage network is shown in FIG. As shown in the figure, an SDNP client 1700A with IP address IP C _1,1 sends an SDNP client with corresponding IP addresses IP F _{7,1 , IP F 9,1 and IP F 9,4 through the} SDNP cloud. Transfer a series of data packets to file storage servers 1700H, 1700M, and 1700L. In operation, client node C _1,1 sends a header 1726X and a series of data packets 1730X from address IP C _1,1 to SDNP gateway M _0,0 . Data packet 1730X is illustrated with data packets 1730H, 1730L, and 1730M and corresponding headers 1726H, 1726L, and 1726M, respectively. To ensure accuracy, Layer 4 transport uses TCP instead of UDP. These packets contain an SDNP Zip or other ID in the form of a tag X that is used to identify the packet for routing. For data packets 1730H, 1730L, and 1730M, tag 1, tag 2, and tag 3, respectively. The payload part of each packet contains unique data, for example in three fragmented files SDNP file 1, SDNP file 2 and SDNP file 3, respectively. This last mile security credential information uses the zone U1 information and its corresponding preamble 1 .

Once a data packet enters the SDNP cloud, it is routed to another destination according to its identity and the instructions of a signaling server (not shown). Data packet 1730H containing header 1626H and tag 1, carrying SDNP file 1, is routed to _SDNP gateway node M0,4. SDNP gateway node M _0,4 then uses the security credential information for zone U7 to route packet _1730H to file storage node F 7,1. On the other hand, packet 1730L with ID tag 2 carrying SDNP file 2 is routed solely to SDNP gateway node _M0,8 . SDNP gateway node M _0,8 then routes packet 1730L to file storage node F _9,4 using the security credential information for zone U9.

At about the same time, packet 1730M carrying SDNP file 3 with tag 3 as an ID is also routed to SDNP gateway nodes M _0,8 alone, but not necessarily with data packet 1730L with tag 2 as an ID. Do not use the same mesh routing paths. SDNP gateway node M _0,8 further routes tagged 3 packet 1730M to file storage node F _9,1 , also using the security credential information for zone U9.

Thus, SDNP file 1 is delivered to file storage node _F7,1 using security credentials for zone U7, and SDNP file 2 and SDNP file 3 are delivered to file storage node F7,1 using security credentials for zone 9. delivered to storage nodes F _9,4 and F _9,1 respectively. These files are owned by client node _C1,1 , but the client does not have access to the security credential information used to encode and protect the contents of these files. Since none of the file storage nodes contain all the data, and the client owning the data does not have access to the security credentials used when the data is stored, hackers cannot is difficult for the following reasons: (i) the file contents are inconsistent and split into unusable pieces; (ii) all files use different security credentials; (iii) all files are stored in different locations and in different last-mile networks; (iv) these various stored data are from the same SDNP source file. there is no way to know Zones containing file storage servers are sometimes referred to as "storage-side" zones and are sometimes distinguished from zones where file owners reside (ie, zones on the other side of the SDNP cloud). By this definition, zone U1 is the SDNP client zone, also called the "file owner" zone, while zones U7 and U9 are the "storage side" zones.

The application method of the SDNP network communication protocol on the file storage will be described with the flow chart of FIG. 82A using the “write operation” as an example. Here we provide a general procedure for SDNP clients and file owners to store or write their data to a hyper-secure file storage server. As shown, SDNP client 1700A splits unparsed file 1705 using SDNP split operation 1057 and parse function 1052 to generate a multipart file or document. In this example, it is a three part file consisting of parsed files 1706A, 1706B and 1706C. If desired, the contents of the file may be scrambled before splitting. These three files are transferred over the SDNP network as unrelated data or communiqués. The procedure for routing to the final destination through the SDNP network uses the same method disclosed herein for hyper-secure last-mile communication and already described for mesh routing within the SDNP cloud. Specifically, last mile hyper-secure transport 1707 is using security credential information according to zone U1. The SDNP cloud's hyper-secure mesh transport 1708 employs zone Z1 security credentials. Although these hyper-secure data transmission operations are represented as large blocks, packet forwarding is performed throughout the network of routers, servers, and softswitches described in this disclosure with master keys, central control, and control over packet contents. Done using a distributed system with no access rights.

Zone U1 last mile routing allows data packets to be sent through an infrastructure containing a limited number of routing options, but multi-PHY last link routing, sequential packet routing to multiple SDNP gateways, and The methods described for hyper-secure last-mile communications, including the use of dynamic source addressing (ie, renaming the client's IP address), are equally applicable to hyper-secure file storage operations. Once a data packet reaches the SDNP cloud, that transport uses anonymous mesh routing with scrambled and dynamically encrypted data to monitor the file content as well as the metadata associated with this communication. also prevent Eventually, all three data packets reach different SDNP file storage servers 1700H, 1700M, and 1700L and are sent to SDNP nodes F _{7,1 , F 9,1 , and F 9,4 in different} security zones, respectively. placed. After network transport, parsed file 1 is processed according to zone U7 file security operations 1709A and stored in _SDNP file storage node F7,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 . Thus, no single file contains all the data, and a single security credential cannot unlock all component files to recreate the original file.

In the hyper-secure storage file "read operation" shown in FIG. 82B, the order of data transfer between the file storage server and the SDNP client (ie, the owner of the file) is reversed. Reading a hyper-secure file is a process that reverses the process in which the file was originally saved in reverse order and is accomplished by: (i) identifying the parsed file in each storage server, ( ii) remove local storage security measures from each parsed file, (iii) return each recovered parsed file back to the SDNP client via the SDNP cloud and hyper-secure last mile, (iv) various associations Collect the parsed files from the communiqué; (v) merge the parsed files using the client's local security credential information and descramble appropriately to recover the original files;

To further illustrate the hyper-secure file "read operation", the relevant content of file storage server _1700H stored on file storage node F7,1 is processed and parsed using zone U7 file security operation 1709A. file 1 is recovered. Irrespective of parsed files 2 or 3, parsed file 1 is transported by hyper-secure transport operation 1708 using zone Z1 security credential information, followed by last-mile hyper-secure transport operation in zone U1. 1707 back to the SDNP client node C _1,1 using the SDNP cloud shown in simplified form. At the same time, the relevant content of file storage server 1700M stored on file storage node F _9,1 is processed using zone U9 file security operations 1709B to recover parsed file 2 . Irrespective of parsed files 1 or 3, parsed file 2 is transported by hyper-secure transport operation 1708 using zone Z1 security credential information and subsequently by zone U1 last-mile hyper-secure transport operation. 1707 back to the SDNP client node C _1,1 using the SDNP cloud shown in simplified form. Meanwhile, the relevant content of file storage server 1700L stored on file storage node F _9,4 is processed using zone U9 file security operations 1709C to recover parsed file 3 . Irrespective of parsed files 1 or 2, parsed file 3 is transported by hyper-secure transport operation 1708 using zone Z1 security credential information and subsequently by zone U1 last-mile hyper-secure transport operation. 1707 back to the SDNP client node C _1,1 using the SDNP cloud shown in simplified form.

Independent packet routing for three parsed files during a read operation is illustrated in FIG. Here, server node 1700H transfers data packet 1731H containing SDNP file 1 and ID "tag 7" using TCP transport from file storage address IP F 7,1 to _SDNP gateway at address IP M _0,4 . Send to server. Packet 1731H includes a header 1727H containing preamble 7 and other information provided in command and control packets previously delivered by the signaling server in tri-channel communications.

Meanwhile, server node 1700L transfers data packet 1731L containing SDNP file 2 and ID "tag 9" using TCP transport from file storage address IP F _9,4 to SDNP gateway server at address IP M _0,8 . Send to Packet 1731L includes a header 1727L containing preamble 9 and other information provided in command and control packets previously delivered by the signaling server in tri-channel communications. Server node 1700M sends data packet 1731M containing SDNP file 1 and ID "tag 8" using TCP transport from file storage address IP F _9,1 to SDNP gateway server at address IP M _0,8 . do.

Packet 1731M includes a header 1727M containing preamble 9 and other information provided in command and control packets previously delivered by the signaling server in tri-channel communications. The three data packets 1731H, 1731L, 1731M traverse the SDNP cloud using zone Z1 security credential information and finally emerge from the SDNP gateway M _0,0 hosted by the SDNP cloud server 1701U. These data packets are now sent sequentially in successive data packets 1731X using corresponding zone header 1727X and zone U1 security credential information to client device 1700A at address IP C _1,1 .

Take another look at Figure 82B. After the three parsed files 1, 2, 3, namely 1706A, 1706B, 1706C have been sent to the SDNP client device 1700A using independent routing, these files are combined into a single unparsed file by a mixing operation 1061. file 1705, after which a descrambling operation is performed according to zone U1 security credential information, if applicable (not shown).

Rather than adding additional file server operations to protect data at rest, security operations 1709A, 1709B, and 1709C are actually the last mile between the SDNP cloud and corresponding storage servers 1700H, 1700M, and 1700L. Configure hyper-secure communication. As a Layer 3 network connectivity tool using the SDNP communication protocol, SDNP file storage can be scrambled, fragmented, and distributed across multiple distributed non-volatile data drives, including the use of data disguise techniques such as junk data insertion and junk files. and stores encrypted data and is inherently hyper-secure. Apart from the data security methods described above, the hyper-secure storage disclosed herein allows for the use of meaningful metadata, traceability to the file owner, the path through which the file was delivered, or otherwise unknown from the original source file. Anonymous filenames are used that do not contain any information such as the identity of any other file storage server holding such components.

Aside from Layer 1 PHY implementation and Layer 2 transport, protocols can change significantly without affecting storage capabilities, access times, or global accessibility, such as interoperability of SDNP networks, physical realization of storage servers, etc. There is Figure 84A shows an example physical implementation of an SDNP file storage server. In the top configuration example, the SDNP gateway 1701B is connected to the SDNP file server via the router 27. FIG. To improve network performance and resilience to attacks, the central example configuration uses optical fiber 91 to connect the SDNP gateway 1701B directly to the SDNP file storage server 1740A, without an intervening router. . In the bottom example, the file storage server is equipped with server controller 1740B and storage drives 1740C and 1740D to allow for the addition of larger memory arrays. These drives can be any medium, such as hard disk drives or flash drive-based non-volatile memory. To enforce access restrictions, the SDNP gateway and the SDNP file storage server are physically co-located, and only fiber links are used to connect them. These facilities can even share the same room, eg, physically fixed in a storage room, with tightly controlled access control and monitoring of who enters the facility.

FIG. 84B further illustrates that a portion of the fragmented data file can be stored locally at the file owner's site. As shown, the file owner's desktop 36 includes (i) a local file storage server 1740A accessed via WiFi router 1352 connected to SDNP gateway node M _0,0 on server 1701A; ) file storage servers _1740B connected to SDNP gateway nodes M0,4, and (iii) file storage servers _1740C connected to SDNP gateway nodes M0,8, and so on. Can be saved across multiple devices. Because data is stored and fragmented on distributed drives 1740A, 1740B, 1740C, even if local file server 1740A and file owner desktop 36 share the same WiFi 1352, notebook 35, tablet 33, Other devices such as mobile phone 29 cannot access the stored files.

The process of uniquely storing each parsed portion of a file on separate file storage servers, called non-redundant hyper-secure file mapping, is illustrated in Figure 85A. As shown in this figure, client device 1700A, including SDNP client node _C1,1 , sends parsed file 1706A to file storage server 1700H, parsed file 1706B to file storage server 1700M, and parsed file 1706B to file storage server 1700M. File 1706C is stored exclusively on file storage server 1700L, respectively, between storage nodes _F7,1 , _F9,1 , and _F9,4 and parsed files 1, 2, and 3. corresponds to one-to-one file mapping. Delivery of these files uses hyper-secure last-mile communications to ensure the safety of data transmission and its storage. Non-redundant file mapping has the disadvantage that the temporary or permanent loss of any of the file storage servers makes file access and recovery difficult. In the context of this specification, the terms "resilient" and "resilient" refer to guaranteed and timely access to stored data, i.e. stored data is not lost or accessed. is used to indicate that it has unimpaired reliability over a considerable period of time. This means that the non-redundant hyper-secure file mapping shown here is less resilient because any single point of failure causes file access problems. Weak resilience can be overcome by redundant systems in which the same data is stored on multiple file storage servers.

Another metric that describes or assesses the resilience of a data storage system is the Read Redundancy Factor, RRF, defined herein. This metric is used to define the number of backup systems that provide data access when the primary data storage is unavailable. In this example, there is one place for each unique piece of data. This results in a read redundancy factor of zero, ie, mathematically RRF=0. In other words, a single point of connection, or failure of the file server, can result in temporary or permanent data loss as the file owner cannot read the file.

FIG. 85B shows file mapping with a read redundancy factor of RRF=1. 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 . With such an implementation, even if file storage server node F _9,1 fails or becomes unavailable, parsed file 3 will still have the parsed file from file storage server node F _9,4 . 2 can be accessed from the file storage server node F _7,1 respectively. So even if any one storage node fails, read access to hyper-secure files will not be lost. FIG. 85C is a hyper-secure file mapping with RRF=2. This file mapping includes file storage servers 1700L, 1700M, and 1700H, but adds a second group of file storage servers 1700J, 1700E, and 1700F, each corresponding to a file storage server node. F _8,2 , F _4,4 and F _6,8 are provided. Thus, file storage server 1700J serves as a backup for file storage server 1700L, file storage server 1700E serves as a backup for file storage server 1700M, and file storage server 1700F serves as a backup for file storage server 1700H. The example shown consists of a file parsed into three sections, but the document can be split into more sections if desired. In order to guarantee hyper-secure storage, the number of divisions of the original file should not be less than 2, ideally 3 or more is recommended.

To illustrate the process of storing and reading redundant files using hyper-secure file storage, we describe the transaction sequence of the communique and file transfer functions overlaid on the SDNP network used to facilitate the storage process. to decide. The network of FIG. 86 includes, as an example, a client device 1700A implementing client node C _1,1 , a router 1702G, a signaling server 1715 implementing an SDNP node S, a name server 1714 implementing an SDNP node NS, an SDNP cloud node M cloud server 1701U implementing M _0,0 , M _0,4 and M _0,8 and SDNP file storage server _1700H implementing SDNP file storage nodes F 7,1 , F _9,4 and F _9,1 respectively; 1700L and 1700M are included.

In FIG. 87A, a client device 1700A at address "IP C _1,1 " signals address "IP S" with a data packet 1710A containing a C&C payload 1711A and a description of the file size and desired level of security and redundancy. Issue a file write request to server 1715 . In FIG. 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 . The choice of file address server node to use is based on random selection methods from the list of storage nodes and geographic conditions such as nodes available near the client or available in disaster-free areas. There is a way. Selection may also be based on performance parameters such as unused memory capacity of nodes, propagation time to file storage nodes, reliability ratings of node uptime, and other considerations. In FIG. 87C, name server 1714 sends signaling server 1715 data packet 1710C containing the IP or SDNP addresses of file storage server nodes F _{7,1 , F 9,4 ,} and F _9,1 . The signaling server 1715 then calculates the last mile and mesh cloud delivery of the parsed files to the file storage servers 1700H, 1700L and 1700M.

In Figure 87D, signaling server 1715 sends data packet 1710D to client device 1700A, which is routed from address "IP S" through router 1702G to "IP _C1,1 ". Data packet 1711D includes C&C payload 1711D. This payload indicates last mile routing for an upcoming file transfer in zone U1 of the client zone. Specifically, each packet is designated by tag 1, tag 2, and tag 3 (abbreviated as tag X), and the address "IP C _1,1 " to "IP M _0,0 " SDNP gateway Contains routing information for multiple packets to At the same time, signaling server 1715 sends data packet 1710E to SDNP gateway 1701U. This packet is routed from the address "IP S" to "IP M _0,0 ". This packet contains a C&C payload 1711E indicating SDNP cloud routing using the zone Z1 security credential information of the packet with ID tag X. In this case, the route from the SDNP gateway address “SDNP M _0,0 ” to the next node in the cloud, namely the address “SDNP M _0,5 ” (not shown). According to "Secure Dynamic Communication Networks and Protocols", the routing of data packets across the SDNP cloud using meshed anonymous fragmentation transport is dynamically selected based on the current state of the real-time network. Specifically, the routing within the SDNP cloud of real-time data packets sent to the SDNP gateway depends on the propagation delay between nodes within the SDNP cloud and the urgency assigned to each real-time data packet by the signaling server. ing.

The signaling server 1715 of FIG. 87E sends C&C data packets to the last mile nodes on the storage side, zones U7 and U9. As shown, data packet _1710F is sent to SDNP gateway M0,4. Packets are routed from address “IP S” to “IP M _0,4 ”, and C&C payload 1711F contains a data packet with tag 1 sent to gateway node M _0,4 and, after receipt, last mile address “IP F _{7 , 1} ''. A second data packet 1710G is forwarded from the signaling server 1715 to the file storage server _1700H at address “IP F 7,1 ”. The C&C payload for storage in zone U7 defines an incoming packet with ID tag 1 from source address "IP M _0,4 ", but the destination field is empty because the function of the node is storage, not communication. remains, that is, padded with null values. Once command and control data packets have been delivered to the network, file transfers are performed.

FIG. 88 describes fragmented data transport during hyper-secure storage of files. Here, client 1700A sends a series of data packets 1712X containing SDNP data files 1, 2, and 3 over TCP data transport from address "IP C _1,1 " to the SDNP gateway at address "IP M _0,0 ". send. Each data packet contains a unique identifier ID, TAG1, TAG2, and TAG3. These files are then transferred via the SDNP cloud to the other gateways, namely the SDNP gateway nodes M _0,4 and M _0,8 . A packet containing SDNP data 1 arriving at gateway node M _0,4 is data packet 1712A, using zone U7 security credential information and TCP from address "IP M _0,4 " to "IP F _7,1 ". transferred. On the other hand, data 2 and data 3 packets arriving at gateway node M _0,8 are routed from address "IP M _0,8 " to address "IP F ₉ " using zone U9 security credential information in data packets 1712B and 1712C. _{, 4} ” and “IP F _9,1 ”, respectively. Storage may also include local encryption within the file server to prevent data scanning of the drive. This encryption process is performed locally and has nothing to do with SDNP's security measures. The data packet contents SDNP data 1, SDNP data 2, and SDNP 3 contain the actual fragmented files to be stored.

A preamble within each data packet, eg, preamble 1 of data packet 1712A, may also include the encryption key provided by the client as part of the symmetric key encryption operation. Using symmetric key encryption, the SDNP client node C _1,1 generates split keys for encryption and decryption. The symmetric cryptographic key is provided to file storage server node F 7,1 delivered by data packet _1712A in this example. In the future, each time a client requests to read or access the contents of a stored file, the file storage server node F _7,1 will encrypt the requested file using this encryption key before sending it back to the client. . It is not possible to open this file read by other clients, because only that client holds the relevant decryption key. Although this method provides an additional layer of protection, it also has drawbacks. Multiple "owners" of client files needed to facilitate redundant access if the original client device is stolen, damaged, or lost, as only one client can access the file as a read operation cannot be used.

In performing data transfer or file storage processes, signaling server 1715 sends instructions regarding "link response" message routing to file storage servers 1700H, 1700L, and 1700M. A link response is a data packet and C&C payload confirming to the client that the write operation was successful and that each parsed file has been saved. These messages are sent to the client file owner independently from each file storage server involved in transferring and storing the parsed file. File servers independently send write acknowledgments to clients without knowledge of each other, and this write communication response uses independent security credentials that contain a unique state that differs from the operational state at the time of the write operation. sent. The routing of these link response messages does not necessarily use the reverse of the same routing path used to transfer the file. These responses can be used by cyber attackers as tracebacks to find file owners. Instead, the link response uses the packet ID to reveal to the client that the file being saved is part of the same file, saved as part of the same fragmented write operation. to

In operation, the Signaling Server sends routing link response messages to the file storage server, client file owners, and all intermediate SDNP nodes involved in link response message routing. Signaling server 1715 coordinates link response message routing using data packets containing command and control payloads, as shown in the example of FIG. 89A. In this example, file storage server 1700H receives data packet 1721G containing C&C payload 1722G containing header data for "link 1 reply" routing from address IP F _7,1 to address IP M _0,4 . The SDNP gateway node M _0,4 describes the routing of tag 1 data packets from address 'SDNP M _0,4 ' to another node in the SDNP cloud, in this case address 'SDNP M _0,14 '. receive data packet 1712F containing C&C payload 1722F. Similarly, signaling server 1715 sends data packet 1721M of file storage server 1700M containing a packet last mile routing indication of tag 3 of “link 3 response” from address “IP F _9,1 ” to “IP M _0,8 ”. to send. Although the storage-side last-mile routing of 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 not nearly the same.

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 containing payload "FS Link 1". This packet is routed from address 'IP F 7,1 ' to the _SDNP gateway at address 'IP M _0,4 ' using the security credential information for zone U7. From the SDNP gateway, data packets with tag 1 are routed through the SDNP cloud to the client-side gateway at address 'SDNP M _0,0 '. Here the address is converted to a last mile data packet 1720X and then using TCP transport, zone U1 security credentials and tag 1 data, i.e. preamble 1 and FS link 1, to address "IP M _{0, 0} ” to “IP C _1,1 ”.

Similarly, file storage server 1700L responds with data packet 1720B identified by tag 2 and containing payload "FS link 2". This packet is routed from address 'IP F _9,4 ' to the SDNP gateway at address 'IP M _0,8 ' using the security credential information for zone U9. From the SDNP gateway, the data packet identified with tag 2 is routed through the SDNP cloud to the client-side gateway at address "SDNP M _0,0 " (routing not shown). Here, after the address has been converted to a last mile data packet 1720X, the data packet uses TCP transport, Zone U1 security credentials, and tag 2 data, i.e., preamble 2 and FS link 2, to address "IP M _0,0 ” to “IP C _1,1 ”.

A third parsed file identified by tag 3 and carrying payload "FS Link 3" is sent 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 at address 'IP M _0,8 ' using the security credential information for zone U9. From the SDNP gateway, the tag 3 data packet is routed through the SDNP cloud to the client-side gateway at address “SDNP M _0,0 ”. Here, after the address is converted into a last mile data packet 1720X, the address ""IP M _0,0 " to "IP C _1,1 ".

FIG. 89C shows an example of the contents of FS Link data packet 1720A returned from file storage server 1700H to the client and file owner. As shown in the figure, the data packet includes an _SDNP gateway from address "IP F 7,1" to address "IP M _0,4 " using TCP with a packet containing ID tag 1 created in security zone U7. The last mile routing to is described. In addition to describing data payload 1741A, response preamble 1719A also includes optional security credential information used to enforce or enhance security of FS link data packets 1720A delivered to the client. However, in tri-channel communication, the response security credential information contained in response preamble 1719A is typically not required and is irrelevant to the credential information subsequently used by the client to access and open hyper-secure stored files. The access credential information required to create a link from a client to a file stored on file storage node F 7,1 is instead stored in data field _1741A and includes the following:
• A unique network tag, SDNP address, or pseudo-address required to identify the file storage server where that portion of the fragmented file is stored.
• A zone description that defines the security credential information used to encode files in a "storage-side" security zone (not the client's zone).
• Seed 1, which can contain the numeric seed or time or state 920 used during encoding of the file before saving.
• Seed 2, which can contain a numeric seed 929 used to perform file encoding as part of the save operation.
• Key 1, which contains the decryption key 1030 for decrypting the "storage side" encryption of zone U7. Partial decryption of this key that can only be operated in combination with a shared secret held on a DMZ server running as part of a file storage server, or in combination with another security credential such as a numeric seed. can represent a key.
• Key 2, which is sent to the client and contains a cryptographic key 1022 used to send secure commands from the client to the file storage server using symmetric key encryption.
- A file name or other information used to allow a client to identify a saved file without revealing how it was saved.

The foregoing data packets have been used for illustrative purposes and should not be construed as limiting the contents of the data packets to the exact same elements or forms illustrated. The FS link 1720X received at the _SDNP client node C1,1 is processed to create a file link for the client's device after it is received from the file storage server participating in storing the fragmented file. . As shown in Figure 89D, this operation combines FS links 1741A, 1741B, and 1741C using compound operation 1753 to produce FS link aggregate File Storage Read Links 1754. File storage links 1754 are posted to the client's hyper-secure text messenger or file management system, allowing easy single-button recall of hyper-secure files. Hyper-secure operation is invisible to the user. File owners need not consider the fact that files are actually fragmented, encoded, and stored across distributed file storage systems. Recalling a file is done as if the file exists locally. Therefore, FS links are a key element for accessing all files stored across distributed file storage systems.

A simplified representation of FS link communication is shown in FIG. 90A. Here, all three file storage servers send their respective FS links to client node _C1,1 and corresponding client device 1700A. Specifically, the file storage server 1700H transmits FS link 1, the file storage server 1700M transmits FS link 2, and the file storage server 1700L transmits FS link 3. Within client device 1700A, the SDNP application software on client node C _1,1 aggregates the three incoming FS links 1, 2, and 3 to form one link to the save file. This combined link is displayed in the SDNP messenger as confirmation of file storage. In non-redundant file management, FS link information is sent only to client devices. For user file management, the file link can be named when the file is requested to be stored or when a confirmation message is received.

The file storage link is sent directly from the file storage server to the client, not through the signaling server, so only the client with the link can access the file. This FS link is required to retrieve and read the fragmented file. Without the FS link, the save file and its contents are permanently lost and irreversibly unrecoverable. An alternative way to reduce the risk of losing the FS link is to send the FS link to two client devices, the client device and its ancillary device. The ancillary device could be a second device owned by the client or, in a business case, a second device owned by the company. As a further alternative, the second device may be another server with its own login security and user identity verification capabilities.

Redundant link access to fragmented distributed stored files created in accordance with this specification is applicable to both read-redundant file storage systems (ie, RRF≧1) and non-redundant file storage systems. FIG. 90B illustrates the use of redundant links in a hyper-secure distributed memory system without read redundancy (RRF=0). In such a system, file mappings between parsed files 1706A, 1706B, and 1706C and their corresponding file storage servers 1700H, 1700M, and 1700L are non-redundant. As shown, FS links 1, 2, and 3 have two client devices: 1700A hosting SDNP client node C _1,1 and auxiliary client device 1700B hosting backup client node C _2,1 . sent to. If one of these FS links is lost or becomes unavailable for some reason, the backup client's FS link can be used for file recovery. In this regard, this SDNP distributed storage system is a non-redundant read implementation with single-link redundancy, ie, RRF=0 and LRF=1.

An example of a hyper-secure memory with both read redundancy and link redundancy is shown in FIG. 90C. In this figure, parsed files 1, 2, and 3 are each mapped to two file storage servers. That is, the read redundancy factor RRF=1 is realized. Also, each FS link is sent to two clients to achieve a link redundancy factor LRF=1. The storage system's tolerance to both read and link related failures means that the system is considered a true redundant hyper-secure file management system with an overall storage redundancy factor of SRF=1. This disclosure defines the storage redundancy factor SRF as the redundancy factor equal to the lowest value of RRF and LRF. For example, if RRF=0 and LRF=1, then SRF=0. If RRF=3 and LRF=2, then the overall storage redundancy factor is SRF=2. To achieve an overall system SRF=3, each parsed file would need to be stored on four separate file storage servers (see FIG. 85C above) and FS links sent to four separate clients. .

Therefore, the overall storage redundancy factor SRF is a direct measure of the resilience of a distributed storage system from failures. This principle is summarized in the graph of FIG. The horizontal axis of the graph indicates the number of file storage servers used in the file storage system, and the vertical axis indicates the number of FS links sent to individual clients. As shown, the single file storage server has no redundancy. That is, 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. That is, LRF=0 regardless of the number of available file storage servers. In either case, ie one storage server or one client link, the overall storage redundancy factor is SRF=0. This means that the file storage system has no resilience, as illustrated by the L-shaped area.

As shown in the figure, if the parsed file divided into three as described above is stored in three file storage servers, the read redundancy factor will be RRF=1. Link redundancy with LRF≧1 is achieved when at least two clients receive the FS link. Any combination of LRF=1 or RRF=1 results in L-shaped region 1724B with SRF=1. In other words, a certain degree of system resilience is obtained. Even if 6 servers are used, the system has only a limited degree of resilience, ie SRF=1, if the FS link is sent to only 2 clients.

By sending FS links to 3 clients and redundantly storing data on 6 storage servers, region 1724C defines the conditions to achieve SRF=2, a fairly robust storage resilience. Area 1724D shows RF=3 with even more resilience, using 6 file storage servers and 4 clients receiving keys. The lower left corner (bottom row and leftmost column) storage is the least resilient, and the upper right corner storage is the most resilient.

A hyper-secure distributed file storage created in accordance with the present disclosure achieves long-term sustainable security by adapting or reusing many creative elements from SDNP communications. These unique elements include:
Parsing files and distributing fragmented content to a large number of file storage servers that are not connected to the network;
transfer files between clients and file storage servers using end-to-end hyper-secure communication that dynamically scrambles DNP-encrypted anonymous fragmented data transfers without a master key;
A method in which the client's security credential information used when the storage server first fragmented and encoded the stored data is inaccessible, i.e., the "client required" for the file storage server to decode, access, or read the file. storing fragmented files on a file storage server in a manner that does not retain 'last mile security credential information';
- Optionally, a method in which the client (file owner) does not have the security credential information required to decode the stored data, apart from using a security link, i.e. the "client-side" last mile , encoding the fragmented file on the storage server using a method that does not retain the "storage-side" last-mile security credential information used to encode the file locally;
limit the number of file storage links required to locate and open a file, and limit user access to links to file owner client devices and any redundant or backup devices;
Require client multi-factor authentication and identity verification to perform file links and invoke read or erase operations;
• Use of anonymous data packet routing and anonymous file names. The use of file links for data recall reveals no information about the location or encoding of hyper-secure file storage, and no routing information is stored on SDNP networks or hyper-secure file storage systems, except for file links. ,
Distributing fragmented files across multiple storage servers using private file server locations and using anonymous IDs with no information on the client, SDNP network, or other storage servers;
- The SDNP signaling server used to plan file routing for distributed storage does not access the fragmented file content or security credential information used to encode the file, and the SDNP used to transfer file content. Employ tri-channel communication, in which media nodes use single-hop SDNP data packets that do not contain client or file storage server IDs or addresses;
・Perform dynamic file renaming and data relocation after regular or repeated access to files, and recreate security credential information during file rewrite operations.
・Encrypt the file storage server directory locally to prevent file analysis.

With the above, the elimination of identifiable file IDs, the use of fragmented files distributed across the network (possibly on a global scale), and the use of zone-specific security credential information make hyperlinks unachievable without access to file storage links. Allows access to and reconstruction of secure stored files. Since these FS links are limited in number and delivered only over the SDNP communication system, identity verification further enhances their security.

An overview of the implementation of the above functions of hyper-secure file storage can be represented in a manner similar to hyper-secure communication using the functional symbols shown in FIG. 9A above. For simplicity of explanation, any combination of scrambling 926 using state or time 926C, junk data insertion 1053, parsing 1052 and splitting 1057, and encryption 1026 as shown in the upper illustration of FIG. , can be represented by the SDNP encoding function 1750 . Similarly, decode function 1751 summarizes encryption 1032 using state or time 926B, mixing 1061, junk data removal 1053B, and unscrambling 928.

Using the aforementioned security features, the top illustration of Figure 93A shows the process of distributed file storage with client-side encoding. As shown, file 1705 is parsed 1052 and split 1057 to create parsed file 1706 in client device 1700A used to implement SDNP client C _1,1 . be. The resulting fragmented file is then encoded using the security credential information for zone U1 by a last mile communications SDNP encoding operation 1750B performed according to the methods disclosed herein. Fragmented files sent in sequential or multi-route last-mile communications then arrive at SDNP gateway M _0,0 and are decoded using SDNP decoding operation 1751C according to the security credential information of zone U1 and parsed files Recover 1706. Parsed file 1706 is re-encoded by SDNP encoding operation 1750C according to the zone Z1 security credentials of the SDNP cloud. During mesh transport, after performing a series of decoding and encoding operations (not shown) in zone Z1 in the SDNP cloud, the final data packet arrives at the respective SDNP gateway, for example gateways M _0,8 , where it undergoes SDNP decoding. The file 1706 parsed by operation 1751D is recovered and subsequently re-encoded by SDNP encoding operation 1750D according to the zone U9 security credential information. In this example, parsed file 1706 is then fragmented (split) into two files, and these files 2 and 3 are recovered by SDNP decoding function 1751E and stored on file storage servers 1740B and 1740C, respectively. In this method, data files stored on file storage servers are fragmented, which would otherwise (except for local drive encryption) become accessible to cyberattacks of these drive data. Therefore, security is achieved through file fragmentation and distributed storage.

A higher level of file security is achieved using the process shown in the lower illustration of Figure 93A. It shows the process of distributed file storage with full client-side encoding. As shown, the file 1705 is processed by the SDNP encoding operation 1750A to be a scrambled, encrypted, parsed file within the client device 1700A used to implement the SDNP client _C1,1 . 1706 is created. Operation 1750A also includes splitting file 1706 into three fragmented files 1, 2, and 3. FIG. Fragmented files 1, 2, and 3 are then encoded using zone U1 security credential information by an SDNP encoding operation 1750B for last mile communication performed according to the methods disclosed in this application. . These fragmented files, sent in sequential or multi-routed last-mile communications, then reach the SDNP gateway M _0,0 to recover the scrambled, encrypted and parsed files 1706 security in zone U1. Decoded using SDNP decode operation 1751C according to the credential information. Parsed file 1706 is then re-encoded by SDNP encoding operation 1750C according to the zone Z1 security credential information of the SDNP cloud.

During mesh transmission, after performing a series of decoding and encoding operations (not shown) in zone Z1 in the SDNP cloud, the final data packets arrive at respective SDNP gateways, for example gateways M _0,8 , where they undergo SDNP decoding operations. Recover the file 1706 parsed by 1751D and then re-encode this file using the SDNP encoding operation 1750D according to the zone U9 security credential information. Fragmented files 2 and 3 of scrambled, encrypted, parsed file 1706 are then recovered using SDNP decoding function 1751E and stored on file storage servers 1740B and 1740C, respectively. This file is therefore protected not only by fragmented distributed storage, but also by a combination of scrambling, junk data, and encryption known only to the client's security zone. Similarly, file 1 is transferred via the SDNP cloud to gateway M _0,4 and stored in file storage 1700H in zone U7, as shown in packet 1712A of FIG.

In these two examples described, higher security can be achieved by removing the final SDNP decode operation 1751E, as shown in the illustration of FIG. 93B. In this manner, files stored on the file storage server remain encoded by SDNP encoding operation 1750D using zone U9 security credential information. In the upper illustration of the figure, the file is fragmented by the client, but the encoding is done according to the security credential information on the storage side of zone U9. In the lower illustration of the figure, the file is encoded according to the client-side security credential information U1 and encoded a second time according to the storage-side security credential information of zone U9. In addition to being protected by fragmented distributed file storage, such double-encoded files contain files encoded with U1 security credentials within files encoded with zone U9 security credentials. Therefore, it is described as nested hyper-secure storage. An advantage of the nested security disclosed herein is that neither the client nor the storage server have the information needed to open a saved file.

An overview of an exemplary method for implementing hyper-security decentralized file storage is shown in FIG. The example shown in this figure removes the encoding and decoding used for hyper-secure communication and SDNP cloud routing to show only the net effect of file encoding. The upper left corner shows the case of client zone fragmentation. Here the document is fragmented according to the security credential information of zone U1, but there are no additional security measures imposed by the storage side of the network. The lower left corner shows the encoding case in the client zone. The document is now encoded by operation 1750B. That is, it is scrambled, junked, fragmented, and encrypted according to the security credential information of network U1. However, no security measures are taken on the storage side of the network.

The upper right corner shows the case of fragmentation in client zone U1, but additional steps of SDNP encoding are introduced on the storage side according to zone U9: scrambling, junk insertion, fragmentation and encryption. there is The bottom right corner is an example of fully nested hyper-secure file storage. The file is encoded and fragmented according to the SDNP encoding operation 1750B using the zone U1 client-side security credential information, and then the file is encoded twice according to the storage-side last mile zone 9 security credential information.

Recalling and reading the file requires the recall of the data to use a security operation involving the reverse function to perform the encoding in exactly the reverse order, as shown in FIG. In the upper left case, parsed files 1706 called from different file storage servers to retrieve fragmented data in the client zone are recombined using merge operation 1061 to recover the original file 1705. do. Bottom left is the case of recalling client zone encoded data, where a parsed file 1706 recalled from a different file storage server completes the splitting operation 1750B, including mixing, decoding, and unscrambling. The inverse function SDNP decode operation 1751H is used to recover and access the original file 1705 . In the upper right case of a file encoded in storage zones and fragmented in client zones, the reverse operation is performed as follows: First, an SDNP decode operation 1751F is performed to undo the results of the zone U9 security operation to recover the parsed file 1706, followed by a file split operation 1057 performed according to the zone Z1 security credential information by a file merge operation 1061. cancel the result of

In the lower right example of reading a fully nested hyper-secure file, the data stored on a different file storage server is decoded, scrambled, junk, and junked by SDNP decode operation 1751D using zone U9's security credential information. It reconstructs the multipart file 1706 in its encrypted, parsed, and encrypted state. Zone Z 1 -specific SDNP decoding operation 1751 H then performs the sequential inverse functions of encoder 1750 B: mixing, decoding, unscrambling operations, recalling original file 1705 . Performing the sequential inverse functions to recover a file requires performing the sequence of operations used to create the file in reverse order. For example, if encoding is done in the order of segmentation, scrambling, and encryption, the reverse function, decoding, must perform the operations in the order of decoding, unscrambling, and mixing. However, if the sequential encoding of a data packet involves scrambling, encryption, and packet segmentation, then the reverse function, decoding, involves mixing, decryption, and finally unscrambling. There is

To invoke a file, i.e. perform a "file read operation", the client clicks on the "file storage read link" to invoke the centralized file link to invoke a file stored in the system's hyper-secure file storage system. to initiate the necessary steps to read. The reading process involves the following steps shown in FIG. 96A.
• File owner and client 1700A or authorized user clicks "file storage read link" in an SDNP application such as SDNP-enabled hyper-secure messenger 1196, file manager, or other SDNP-enabled interface.
• Using dialog interface 1765, or optionally command line instructions, client 1700A specifies file requests 1761; This includes reading the file, editing the file (creating a copy of the file with write permissions), erasing the file (deleting), updating the links (reissuing security credentials), or redistributing the file (removing file fragments). move to a different file storage server and issue a new file storage read link to the file owner client).
• In a 'verify client' operation 1762, the SDNP signaling server 1715 verifies the identity of one or more clients requesting the file (authentication). Using dialog box 1767, the client must verify its identity using a PIN and optionally a second factor such as device or security token detection. Alternatively, the SMS text can be sent to another device owned by the same client. For files that require access authorization by multiple clients, the identities of all users must be verified (multi-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/erase privileges (permissions). After the results are displayed in dialog box 1768, confirm whether the user wishes to download or read the file. If the identity cannot be verified, the requestor may be instructed to try again. After the specified number of attempts is reached, the file administrator 1700Z (if any) is notified of the failed attempts and the account is locked. A dialog box may notify the user to report the problem to the file manager. Or, suspected hacking can result in blank dialog boxes or even kick the user out of the SDNP application altogether.
• In a document request management operation 1764, the SDNP Signaling Server 1715 notifies the File Access Manager of the file access request and the nature of the request (management) to the File Storage Manager 1700Z. This management procedure is either: (i) be skipped completely; (ii) record the file access request in the file access administrator's account; (iii) send a message to the file storage administrator to notify immediately of the attempted file access; or ( iv) Seek approval from the file storage administrator via dialog box 1769 before granting access permissions to the client requesting the file.

After these Authentication, Authorization, and Administration (AAA) steps, once authorization is obtained, the client requests access to the file using the steps shown in the flowchart of FIG. ). These procedures include:
• In read request operation 1770 , requesting client 1700 A sends a file read request to SDNP signaling server 1715 .
• At a request storage server name operation 1771, the SDNP signaling server 1715 sends a file storage server name request to the SDNP name server 1714 requesting the current SDNP address of the associated file storage server (eg, file storage server 1700M). According to the SDNP method, the SDNP addresses of SDNP clients (including file servers) are changed at least once a day to protect against long-term client long-term traceability.
• In a deliver storage name operation 1772, the SDNP name server 1714 delivers the requested file name "FS Address" to the SDNP signaling server 1715, which sets up file call routing accordingly.
• At routing directive operation 1773, the SDNP signaling server sends a file routing directive to the nodes in the SDNP cloud, such as client 1700A, server 1700U, and file storage servers. This time using zone U9 security credential information including state or time 920, numeric seed 923, decryption key 1030, and optional encryption key 1022 (used in symmetric key encrypted communications).
In a local file recovery operation 1774, all storage-side last-mile DMZ servers decode the parsed file using applicable security credentials, including state or time information specific to the creation of the file; This data is packaged into one or more data packets in preparation for recovery and transmission.
• In a file delivery operation 1775, each parsed file is delivered to the requesting client using independent delivery over the SDNP network according to the routing instructions of the SDNP signaling server. For example, file storage server 1700M sends its file to client 1700A.
- The received parsed data file is further decoded according to the client zone security credentials and the parsed files are merged to recreate the original parsed file that can be viewed or transferred.

These procedures are illustrated in the following series of figures. In FIG. 97A, a client device at address "IP C _1,1 " makes a file read request to signaling server 1715 at address "IP S" using data packet 1810A. This request includes a TCP transmission, header information related to the file, and a C&C payload 1811A specifying two or more FS links. FS links anonymously describe the location of stored file fragments using tags or pseudo-addresses that must be converted to SDNP addresses or IP addresses for routing. However, since Signaling Server 1715 does not know the current SDNP addresses of these named user identities, it must request the current information from SDNP Name Server 1714 . In FIG. 97B, signaling server 1715 sends data packet 1810B 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 . In FIG. 97C, signaling server 1714 sends data packet 1810C 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 . The Signaling Server 1715 then calculates the last mile of the parsed file to the File Storage Server and delivery by the mesh cloud.

The signaling server 1715 of Figure 97D sends C&C data packets to the last mile nodes 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 _F7,1 " and carries a C&C payload containing "file 1 read instruction" 1811G. . This packet instructs the file storage server to send the file with ID tag 1 to the _SDNP gateway at address "IP F 7,1 " to address "IP M _0,4 " using the U7 security credential information. At the same time, data packet _1810F is sent to SDNP gateway M0,4. This packet is routed from address "IP S" to "IP M _0,4 ", contains C&C payload 1811F, and that a data packet with tag 1 is expected by gateway node M _0,4 , data packet to be forwarded in the SDNP cloud with the Z1 security credential information, for example to address SDNPM _0,31 .

The second data packet 1810I contains a C&C payload 1811I containing a "file 3 read command" and is sent from the SDNP signaling server 1715 at address "IP S" to the file storage server 1700M at address "IP _F9,1 ". be done. This instruction instructs file storage server 1700M to send the file with ID tag 3 to the SDNP gateway at address IP M _0,8 using zone U9 security credential information. Other C&C packets (not shown) are similarly sent to other file storage servers and gateways (nodes _F9,4 , _M0,8 , etc.) and nodes in the SDNP cloud.

In FIG. 97E, signaling server 1715 transmits data packet 1810D to client device 1700A. This packet is routed from address "IP S" through router 1702G to "IP C _1,1 ". Data packet 1810D uses zone U1 security credential information to indicate to the client that multiple incoming data packets with IDs of tag 1, tag 2, etc. are expected from SDNP gateway 1701U at address "IP M _0,0 ". C&C payload 1811D to notify the At the same time, signaling server 1715 sends data packet 1810E to SDNP gateway 1701U. This packet is routed from the address "IP S" to "IP M _0,0 ". This packet contains a C&C payload 1811E for last mile routing of zone U1 applicable to incoming data packets identified as Tag 1, Tag 2, and Tag 3 packets forwarded from within the SDNP cloud.

File transfers are performed when command and control data packets are delivered to the network. The first step of this transfer is shown in FIG. Here, data packet 1741R containing FS link 3 provides information such as illustrated state 920, numeric seed 929, decryption key 1030, and encryption key 1022 to SDNP decode operation 1751R. For SDNP decoding operation 1751R, this information is processed by DMZ server 1752 to perform functions involving shared secrets such as packet decryption 1032R, mixing 1061R, junk removal 1053R, and unscrambling 928R. These executions all occur in state 920, the state the parsed file was in when it was last encoded. Encryption Key 1022 is not specifically required to decode the file, but can be used for symmetric key encryption of the parsed file back to the client and file owner.

FIG. 99 illustrates file routing and data transmission. Here, file 1 is sent from address "IP F _7,1 " to "IP M _0,4 " using U7 security credential information in TCP data packet 1720A, and U9 security credential information is used in TCP data packet 1720B. File 2 is sent from address "IP F _9,4 " to "IP M _0,8 " in TCP data packet 1720C using U9 security credential information from address "IP F _9,1 " to "IP M _{0 , 8} ”. After transmission over 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 ".

A read operation loads data into the SDNP app in a "read-only" format. As long as the files are sandboxed within the SDNP application, they are protected by the capabilities of the SDNP application and network, and are not dependent on the login procedures or weak security measures of the device's operating system. The need for read-only access to private documents is widespread among businesses. Many files created by corporate finance, legal, manufacturing, engineering, quality control, and other departments are examples of materials that represent read-only content. In many cases, the internal files of these companies must be forwarded, or electronically distributed, to company executives for review before being published.

Accidental or premature disclosure of disseminated information could have devastating consequences, with serious economic or legal consequences for the company, as well as personal liability for its officers. For example, unpublished financial reports of publicly traded companies are kept strictly confidential until they are made public. In the United States, Regulation FD, or "Fair Disclosure," means that information must be made available to all at the same time without prejudice. If an outside party were to access such information prior to publication, it would be a violation of Regulation FD. If a court determines that a breach of Regulation FD occurred because the company failed to maintain and ensure the confidentiality of documents, the company could be penalized for the breach, and officers may Even if it is not insider trading, you may be held personally liable.

Within the SDNP app, the files obtained are partitioned (sandboxed) and protected against transfer of data from one account ID to another. For example, files cannot be exchanged between business and personal accounts. Depending on the reader's authorization privileges, the user may or may not be allowed to download the obtained file from the SDNP application to unencoded storage in the device memory. Downloading a file outside of an SDNP-enabled application compromises the security of the file and the data it contains. For data in SDNP applications, access is controlled, user actions are restricted, and both the device and the SDNP network must verify the user's identity. Defeating such multi-layered multi-factor authentication is much more difficult than defeating the simple four-digit pin required to open a mobile phone. By contrast, once a file has been downloaded to a computer, tablet, or mobile phone, it is nearly impossible to prevent unauthorized access, identify who accessed it, or who made a copy of the file. becomes impossible.

Thus, using SDNP communication, file owners can lock or compartmentalize sensitive documents and files. This will allow others to read your documents and files, but not download them to your phone. Additional procedures may be used to prevent taking screenshots or photographs of the LCD display. In other cases where security and privacy are not required, the files obtained can be transferred from the SDNP app to the phone's memory for unlimited use.

In an edit operation, a file in editable format is downloaded to the device and passed to the application program required to edit the file. With respect to performing file requests and data exchanges, there is no fundamental difference between file read requests and file edit requests in SDNP network operations, except for the operation of the client's SDNP application. Thus, from the point of view of data transfer in an SDNP network, these operations are functionally the same. Therefore, the difference between read and edit operations can be considered to lie mainly in the execution of layers 5 to 7, which consist of application-specific files.

Applications that edit the retrieved files include: (i) device-embedded applications (such as Simpletext) that are native to the device's operating system but run outside of the SDNP application; (ii) reside on the device's operating system but Third-party applications (e.g., Microsoft Word, Adobe Acrobat, etc.) that run outside the SDNP application; or (iii) secure applications that run within the SDNP application and are not directly accessible from the device or its operating system. . For example, a company's press release can be edited within the SDNP application sandbox, but cannot be downloaded to the mobile phone's memory. As an additional measure to maintain business security, all company-owned files, i.e. files sandboxed in the SDNP business account compartment, are , cannot be transferred to the user's personal SDNP account.

After editing, saving the edited file to the SDNP file storage server does not overwrite the existing file unless the owner of the file specifically requests to do so. Instead, a second version is saved in addition to the first version of the file, and removal of the previous version requires the user to perform an erase operation on the file. Because hyper-secure file storage mandates identity verification, the process of saving edited files may involve unique system features not available to file storages that do not have dedicated hyper-secure network communication capabilities. . One such unique feature is the signature verification feature used to sign and date (or stamp for Asia) files. Signature functionality may include registered receipts sent to the document owner and original document creator.

For hyper-secure data storage created in accordance with this specification, the erase operation overwrites any existing parsed files with random numbers, and optionally performs another random number overwrite after one hour, and Small but potentially detectable analog fluctuations in bit charge or magnetic field are further obscured. The file records are also overwritten and the data drive's file records are complicatedly disturbed. After erasing the data and file records, the client's data link is destroyed within the client device using the SDNP system's self-destroying message feature, and all residual data on the FS link is discarded from the SDNP system. However, if the filesystem administrator used third-party software to track per-user activity, the administrator would not be able to access the deleted files themselves, but would be able to identify the file's owner and creation date. , can maintain metadata about the history of a file, such as who accessed the file, when it was accessed, and when it was deleted.

The SDNP network and hyper-secure last-mile features can also support corporate account features and operating procedures that differ from personal account profiles. As previously mentioned, the Personal Account Erase operation involves rewriting junk data into files, erasing index records on the drive that indicate the file's existence, and using self-destruct messages to replace the file's previously fragmented storage location. All pointing FS links are destroyed, and so on. However, for corporate accounts, the file storage administrator may require prior approval to permanently destroy files. For example, using an approval process similar to dialog box 1769 in FIG. 96A (but sent to the administrator rather than the owner of the file).

If your company's file administrator chooses not to allow deletion of files, the following scenarios may occur: (i) the file owner is notified that the file will not be deleted and the file read link is maintained in the message history of the SDNP application or SDNP communicator; (ii) the file owner is notified that the file will not be deleted; e.g. stored for "archival purposes", but using the SDNP system's self-message destruction provision feature, the personal file read link is removed from the SDNP application, i.e. the file owner attempts to delete the file then only the file storage administrator can call this file, or (iii) the file owner's personal file read link is removed from the SDNP application using the self message destruction provision feature of the SDNP system, but the file The owner is not notified that the file is held by the company.

Due to the last-mile hypersecurity inherent in the operation of the anonymous fragmented distributed file storage system disclosed herein, even file storage administrators can retrieve stored files without a "file storage read link" It is not possible. Every time a file is saved or edited, an administrator must have a corresponding file storage read link to access the file. Corporate accounts can provide this level of oversight, but the sheer volume of data created by tracking every change to every file can be difficult for any file management system. As disclosed herein, the intelligent filtering possible in our SDNP system tracks only attempted file deletions. In this approach, the administrator does not monitor file creation, only track attempts to delete files. When the file owner attempts to delete the file, only then is the corresponding file storage read link transferred to the administrator's database or console for approval or archival purposes.

The size of the database can be further minimized by designating specific employees and contractors for whom monitoring is required. For example, if a company becomes involved in a financial audit or patent litigation, typically all parties involved are advised not to erase related data and files. Using the file management capabilities enabled by the SDNP file storage system disclosed herein, all attempts by staff to delete files associated with an investigation are logged and "at that point" file storage is performed. It can be tracked by sending a copy of the link to the file storage administrator or possibly to an independent investigator. Such a method is beneficial because it limits the amount of data to be monitored and naturally alerts administrators to suspicious activity suggestive of attempts to conceal fraudulent activity. The use of redundant file storage links as described above is essential to prevent accidental or malicious loss of file storage name links due to destruction of the client and file owner's devices themselves. In the case of an enterprise, the backup copy may be kept on a computer in the secure office or on the company's central server.

In cases where extremely high security is required, such as national security concerns, a multi-step approach to erasing files may be used: (i) overwrite the file with random data, (ii) copy all other files from the storage drive to the other storage device, (iii) mass erase the drive, (iv) reformat the drive, ( v) overwrite the drive's storage field with a random number, and optionally (vi) copy the saved file if necessary. Unlike traditional overwriting of file data, the bulk erase process affects the read/write storage medium itself, naturally randomizing its electrical, magnetic, or optical properties at the molecular level. Bulk erasing of magnetic drives can use large electromagnets, but bulk erasing of flash requires exposing the IC to high temperatures and potentially ionizing radiation at high operating voltages. Magneto-optical drives can be bulk erased using high magnetic fields. Rewritable optical drives can be bulk erased using a bright scanning laser that scans transversely to the disc format track. In any case, batch erasing is an extreme example where there is no data left on the storage media after erasure, and there is a risk that the storage media will be damaged and cannot be used again.

Another important element of a hyper-secure distributed file storage system is maintaining file data and link access integrity. To prevent accidental loss of the link, it is beneficial to re-establish, ie, revalidate, the file storage read link and reissue security credentials from time to time. This process, referred to herein as a "link update" command, can be initiated manually or automatically from the client, or from the file storage server at predefined time intervals. For client-initiated requests, the SDNP signaling server sends command and control packets to the corresponding server. When the link update is initiated as shown in FIG. 100, the files are processed in SDNP decode operation in state _320X , which is the "old" state at time t1 when they were previously created with zone U9 security credential information. 1751F and decoded. The file is then re-encoded by SDNP encode operation 1750D using the new state _920Y at time t2 and saved to the storage drive. The updated storage link (eg, FS link 3) is then sent back to the file owner, client device 1700A, over the SDNP network. The resulting file contains the encoded data updated with the security credential information for zone U9 at _time t2. However, the security credential information of the client in zone U1 that was used to create and parse the original file is not updated. To read this file, the read operation first decodes the file using the zone U9 security credential information in the state corresponding to _time t2, then transfers it to client node _C1,1 , after which the file is first The file should be decoded using the zone Z1 security credential information associated with the time it was created.

Another measure to increase security is to move all parsed files of the selected file storage link to a new or different file storage server by means of a file redistribution operation. This operation can either send the parsed files to an entirely new server or redistribute the files among existing storage nodes. In either case, security credential information is updated and a new file FS link is issued and sent to clients with access to the file. This operation is illustrated by an example in FIG. Here, the content of file storage _SDNP node F 7,1 in zone U7 is decoded by SDNP decode operation 1751H using state 920X at time t ₁ when the file was created. The file is then transferred over the SDNP network (not shown) to file storage SDNP node F _9,4 where it is encoded by SDNP encoding operation 1750L using zone U9 security credential information as state 920Y corresponding to time t2. encoded. After this, the file is saved and the updated FS Link 2 is sent to the file owner and other clients with file access rights.

In parallel with the above file transfer, the contents of file storage SDNP node F _9,4 of zone U9 are decoded by SDNP decode operation 1751L using state 920X at time t ₁ when this file was created. The file is then transferred over the SDNP network (not shown) to file storage SDNP node F _9,1 where it undergoes an SDNP encoding operation 1750M using zone U9 security credential information as state _920Y corresponding to time t2. encoded by After this, the file is saved and the updated FS Link 3 is sent to the file owner and other clients with file access rights. Similarly, the contents of file storage SDNP node F _9,1 in zone U9 are decoded by SDNP decode operation 1751M using state 920X at time t ₁ when this file was created. The file is then transferred over the SDNP network (not shown) to file storage SDNP node _F7,1 , where it undergoes an SDNP encoding operation using the security credential information of zone U7 as state _920Y corresponding to time t2. 1750H encoded. After this, the file is saved and the updated FS Link 1 is sent to the file owner and other clients with file access rights. In this way, all three files have been relocated, new security credential information has been issued, and new file storage read links based on updated FS links 1, 2, and 3 have been issued to clients authorized for access. is issued.

Another required maintenance function performed by a hyper-secure file storage system is an operation used to check for the existence of files without live links, or "zombie files." This operation is similar to a link update operation, except that it is initiated by the file storage server rather than the client or file owner. During this operation, each file storage server tracks the time since the file was last accessed. If the last operation on the file exceeds a specified time interval (eg, no activity for a month), the file storage server contacts the client to see if the link is still active. The file storage server can connect to the client in the same way that was used to send the FS link to the client. When files are stored, the file storage server retains the client's SDNP zip or pseudo-address.

If no activity occurs within the specified time, the file storage server connects to the SDNP signaling server and sends a request to reconfirm that the link is still active. The SDNP signaling server then plans the delivery route of the FS link verification request to each participating file storage server. Each file storage server sends this request to the client over the SDNP network. All participating SDNP client nodes respond by confirming that the file link still exists on the device. If the file link is verified, then the client has the option to perform a link update. However, if the device does not respond, i.e. there is no active file read link, the file storage server will notify the administrator that the file link is stale or missing and will wait 1-3 months. After such a period of time, unowned zombie files are permanently and irrevocably deleted.

Registration communication

Another feature of SDNP communications conducted in accordance with this specification is the ability of the network to distribute or store "registration communications." Registered communications provide hyper-secure delivery of communiqués, hyper-secure storage of files as signed, time-stamped messages, and electronic signature (e-sign) and electronic stamping (e-stamping) of communications for the purpose of establishing legal validity. There is a function to perform e-chop). Enrollment communication also includes the ability to send "certified messages". This is done in a handshake fashion, using a signed or stamped time-stamped reply to confirm receipt of the document or file. All registration communications are initiated by the client device's SDNP application, but are authenticated through last-mile communications, ie, communications that occur over the last mile of the SDNP network. Any attempt by the client to tamper with the stamp confirmation will result in discrepancies between the stamp confirmation message and network records.

Because SDNP communication uses "state", i.e., uses time and other unique variables to establish message-specific security credentials with communiqués and file storage, timestamps are used in SDNP communication. It is an essential function for This is illustrated in the SDNP communicator application window 1800 of FIG. Here, each text message sent or received has a corresponding time stamp 1801A and 1801B indicating when the message was sent, received, and read, respectively. Time information, including the global time reference established by the SDNP signaling server, is delivered to clients over the last mile network. The SDNP client app then integrates this timestamp into the information display.

In registration communications, the communiqué generates a formal timestamp as part of the process. An example of the registration communication process is shown in FIG. In this figure, a hyper-secure message is executed and optional attachment step 1802 is initiated. This operation uses a dialog box 1803 in which the client, i.e., the sender, sending the message or file chooses whether or not to attach the file to the message, and if so, uses the directory browser. to find the file. Next, a command dialog 1804 is used to send a registration message, whereupon dialog box 1805 is used to select whether to use normal distribution or registration distribution. The message is then sent using hyper-secure communications implemented in accordance with the present invention.

In a 'Message Accepted' step 1806, the recipient performs the sequence of steps required to verify its identity in order to access the message and to send an authenticated receipt confirming receipt of the received message and file. do. The process begins with an authenticate receipt operation 1807 that asks the receiving client to confirm its identity. If the recipient's identity is not authenticated, the recipient cannot access the message, the message is discarded, and the sender is notified of the failure of the authentication step. In this way, the sender can be warned that the recipient's device may have been stolen. Once the recipient's identity has been verified, the recipient is asked to accept or reject the received message and attachments by an acknowledge receipt operation 1808 . If the message is rejected, the sender will be notified.

If the recipient selects an acknowledgment and accepts the message, it performs a receipt management step 1809 to confirm receipt of the message by selecting electronic signature (e-sig) or electronic stamping/marking (e-chop). must be signed. The sender can specify the desired options. In some countries, both an electronic stamp and an electronic signature are required to be legally binding. A subsequent dialog box (not shown) prompts the user to specify his electronic signature or electronic stamp in the file directory of the device. Alternatively, audio or video recordings can be used for confirmation. The receiver is instructed what to record or what to read during recording. Once the message is signed, it can be read by the recipient and attachments can be viewed or downloaded on the spot, depending on the sender's requirements.

Upon receipt of document, signed + time-stamped message receipt 1811 identifying message recipient, received embedded text and attachment name, date and time message received, e-sig, e-chop, audio recording, audio + video recording. , or any combination thereof is sent in send acknowledgment operation 1810 . The archive receipt option 1812 allows the sender to save a signed and time-stamped copy of the message receipt 1811 in the system's hyper-secure file storage system. This allows the sender to receive the file read link 1813 needed to retrieve the message. Alternatively, the message receipt 1811 may be downloaded to the sender's device.

Encryption-based security issues

In today's world full of corporate fraud, IP theft, cybercrime, hacking, criminal gangs, drug cartels, mafias, yakuza, jihadists, and terrorists, government security agencies provide callers with untraceable anonymity. Any communication system that provides communication, i.e., any communication system that uses encryption to protect data and hide the identity of the caller (figuratively a payphone), is a valuable resource for network operators, application developers, and device manufacturers. It claims to be a reckless and irresponsible business practice.

Unfortunately, the fact exists that communications that rely on encryption to provide security protect both criminals and law-abiding citizens alike. As mentioned above, this theme has also come to the fore in countless news articles about the criminal activities of ISIS terrorists, their terrorist acts in Paris and Belgium using a telephone application program called Telegram. End-to-end encryption, also called end-user-based encryption, is used herein to facilitate secure communications. End-to-end encryption is particularly troublesome for security agencies because the decryption key is held only between the communicating parties and not by the intervening network or its operator. Security agencies opposing Telegram argue that end-to-end encryption with big keys is a national and even global security risk that allows terrorists to operate covertly using open communications. are doing. The arguments in favor of Telegram support personal privacy no matter what.

A federal judge ruled in favor of the FBI in a December 2, 2015 shooting in San Bernardino, Calif. that killed 14 and injured 22. Ordering Apple to "unlock" mobile phones has rekindled the privacy debate. Washington Post, Feb. 17, 2016, article entitled "Apple Firmly Resists FBI Demands to Decrypt iPhones Linked to San Bernardino Attacks." Apple and its CEO gave several reasons for refusing to comply with the court order. This article (https://www.washingtonpost.com/world/national-security/us-wants-apple-to-help-unlock-iphone-used-by-san-bernardino-shooter/2016/02/16/ 69b903ee-d4d9-11e5-9823-02b905009f99_story.html).

Most notably, security is designed so that even if the police obtain a warrant, Apple itself does not hold the decryption key (which is essentially another form of end-to-end encryption). nightmare), insisting that the newer iPhones cannot be unlocked for law enforcement. Apple claimed that only the phone's user or someone who knew the phone's password could unlock the phone. The government, meanwhile, countered that it didn't need to unlock the encryption feature, only to disable the ability to wipe the phone's memory after 10 failed login attempts. In an online statement, Apple CEO Tim Cook countered that such behavior compromises the iPhone's security. "Once created, the technology can be used over and over again and on any device," he said in a statement. In the physical world, it would be equivalent to having a master key that can open hundreds of millions of locks, from restaurants and banks to stores and homes. No sensible person would accept such a thing. He continued: "It's not something we take lightly to oppose this order. We feel compelled to speak up in the face of what appears to be excesses by the U.S. government."

The final point Apple argued was that the U.S. Department of Justice was beyond its powers, and that it was a legal argument, not a technical position, that the state could, without any justification, It aptly represents the sentiment of constitutionalists and privacy advocates that there is no right to monitor communications or invade individual privacy. While this San Bernardino case qualifies for obvious reasons, the idea of creating a generic backdoor that can open the communications device under discussion invites abuse by authorities. The Atlantic magazine defended Apple's claims in a February 23, 2016 article, "Apple is right: FBI wants to break into many iPhones." On the same day, the British Guardian also reported, "Apple claims that the FBI wants access to many iPhones."

It was strange that the same privacy position was taken by the US Congress at this time. On March 1, the Guardian magazine published a follow-up article titled, "U.S. Congress Tells FBI That Forcing Apple To Unlock The iPhone(R) Is A 'Messenger Of Fools.'" lawmakers have accused the U.S. Department of Justice of over-commitment and invasion of privacy. "The road to hell starts at the back door," Brad Smith, Microsoft's general counsel, said at the RSA conference in San Francisco. Smith challenged those in the computer security industry present at the meeting to "stand with Apple on this critical case."

During the ruckus, many security experts, including NSA whistleblower Edward Snowden, expressed the position that unlocking cell phones was not as difficult as the FBI claimed. Via a video link from Moscow, Snowden told the Common Cause Blueprint of the Great Democracy conference (March 8-9): "The FBI says Apple has 'exclusive technical means' to unlock cell phones. With all due respect, that's bullshit." Before the case went to court, the FBI reported that it had already found a way to break into locked iPhones. On March 29, 2016, Fortune magazine reported: "The FBI may not tell Apple how they cracked the iPhone."

The legal and geopolitical implications of Apple v. FBI are far-reaching. Following the FBI's precedent, other countries are expected to require backdoors for all network-connected communication devices, including cell phones owned by US citizens traveling abroad. Moreover, with the successful iPhone(R) hack, criminals are constantly discovering or reinventing these methods to commit new forms of cybercrime and identity theft. deaf. To avoid being outmaneuvered by criminals, governments may use the same techniques as criminals to expand surveillance and espionage, and different departments within the same government may use similar methods to influence each other's activities. Even spying can happen. On a related note, various governments are considering limiting the level of encryption used in end-to-end communications.

Taken as a whole, these events are the realization that no combination of existing security measures currently available in the public domain guarantee both security and privacy, or at least support criminals and terrorists. is clearly strengthened. This problem stems from relying solely on encryption to provide both network security and end-to-end security, and the associated caller privacy. Enhancing the security of text, voice, or files by increasing the bit size of encryption keys increases the security of communiqués, making them more difficult to break. Enhanced security maintains security and privacy, combats identity theft, and protects businesses and law-abiding citizens. Unfortunately, increased security also shields criminals and terrorists from prying eyes, allowing them to operate with impunity and invisibility.

This is illustrated in FIG. 104A. Here, originator 1825A is communicating with recipient 1825Q over an insecure network, such as Internet 1821, which suffers from cyber-attacks from various channels. In other words, the network has a huge "attack surface" of vulnerabilities. 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 network 1821 . The problem is determining the size of the encryption key to use. As shown in table 1824, the larger the cipher key, the more combinations are available and the more difficult it is to break the cipher. 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. . Improving network security equates to improving end-to-end security, as indicated by line segment 1823 . Advanced network security is beneficial in preventing attacks by malicious outsiders, but excessive end-to-end encryption is a double-edged sword. If the key size is large, for example, AES256 or AES512 is employed, the system provides "secret" network performance, which naturally provides the same grade of security to the caller. However, even if the caller is suspected to be a criminal or terrorist, neither network operators nor governments can detect and monitor the caller's activity.

The trade-offs of key size are complicated. If the encryption key is too small, criminals can target the network and its users, and if the encryption key is too large, criminals can use the network to hide illegal activities or investigate fraud and fraud. This is because it can interfere with detection activities by the government. In a corporate environment, end-to-end encryption prevents the ability to monitor employee work activities or comply with corporate investigations or intellectual property litigation, so corporate security policies should ensure that such encryption is completely enforced. There are cases of refusal.

It is difficult even to judge which size keys are cryptable and which sizes are secure, and the situation will change as technology evolves. Referring again to table 1824, the number of possible combinations that need to be analyzed in a brute-force attack is calculated as a function of the cipher's key size. A 16-bit key has only 65k combinations, while a 56-bit key has 10 ¹⁶ combinations and a 128-bit key has over 10 ³⁸ combinations. Furthermore, a 256-bit key has 39 orders of magnitude more number combinations than a 128-bit key. Ignoring the use of pattern recognition, a brute force attack tries every possible combination to crack the code. In an EETimes article titled "AES security against brute force attacks" (http://www.eetimes.com/document.asp/doc_id=1279619), the author wrote a circa 2012 super Estimates the amount of time it takes a computer to perform a brute force attack. A petaflop is 1,000 trillion or ¹⁰¹⁵ floating point operations per second, or 1,000 teraflops. Therefore, it takes only 399 seconds to calculate a 56-bit key, 1.02×1018 years to calculate a 128-bit key, ^1.872 ×1037 years to a 192-bit key, and ^1.872 ×1037 years to a 256-bit key. 3.31×10 ⁵⁶ years.

The time required to launch a brute force attack is also changing. Since this document was written, the world's fastest computer has already tripled in speed. According to a BBC News article dated July 30, 2015, "Supercomputers: President Obama orders world's fastest computer", investigators said the target speed for the next generation of supercomputers was set at a record-holding rate at the time. It is reported to be 20 times faster than the machine, a machine capable of computing 1 exaflop (10 quadrillion floating point operations per second). This means that the time required to crack a code will continue to decrease with each passing year. Yet another new approach to cracking cryptography employs massively parallel processing, the method used to mine bitcoins. Instead of using a single supercomputer, thousands to millions of computers can be used simultaneously, allowing simultaneous attacks and dramatically reducing decryption time. Today's fastest microprocessors have already surpassed 1.1 teraflops, so if 30,000 best-in-class microprocessors work together, we can achieve speeds that rival the world's fastest computers today. Noda. Only one million microprocessors are needed to realize a computer with exaflop computing power. Dedicated ASICs can erode security even further, but quantum computing is sure to change it far beyond that, orders of magnitude faster.

In conclusion, end-to-end encryption with large keys is not a good solution for achieving communication privacy and security. An alternative approach enabled by SDNP networks and hyper-secure last-mile communications separates end-to-end encryption from network security, as disclosed herein. As shown in FIG. 104B, communication between SDNP clients 1700A and 1700Q, representing respective originators and recipients, takes place over an SDNP network 1831. FIG. Small attack surface of the network is routed using three-channel communication for dynamic scrambling, fragmentation, junk insertion, and control Anonymous multi-route and mesh data transfer using hop-by-hop encryption realized by Security credential information dynamically changes at every hop in the last mile communication and SDNP cloud, and this process is represented in simplified form using SDNP encoding operation 1832 and SDNP decoding operation 1833 .

As illustrated in table 1834 and indicated by line segment 1830, these methods in various combinations achieve security equivalent to secret or top-secret encryption standards without relying solely on encryption. Line segment 1830 is flat, thus indicating no interdependence between end-to-end encryption displayed on the y-axis and network security displayed on the x-axis. Instead, the network security level can be adjusted from case A to case D by applying different SDNP security schemes. These security operations are performed by the SDNP software, but both senders and receivers have security credential information used as data packets are transferred through the SDNP network 1831 and its various security zones. I don't notice. In particular, a client in conversation is unaware that it is participating in the last-mile network cryptographic key exchange. As a distributed network, the use of encryption within the SDNP cloud has nothing to do with last-mile security and there is no system master key. As such, the security of the SDNP network 1831 does not rely on end-to-end encryption performed by encryption 1026 and decryption 1032 to create encrypted pipes, tunnels 1820 .

The encryption used in SDNP network 1831 need not use the same key size as end-to-end encrypted tunnel 1820 . As shown in the graph, commercial and enterprise security applications for end-to-end encryption use 128b key encryption ( AES128, etc.) can be used. In fact, end-to-end encryption can utilize RSA or other ciphers without compromising network security. The SDNP network 1831 is protected by FIPS 140-2 military grade security compliant AES encryption even in the absence of an end-to-end encrypted tunnel 1820 . As mentioned above, the SDNP network 1831 prevents all external cyber-attacks and man-in-the-middle attacks. An end-to-end encrypted tunnel 1820 protects the caller from hacking intervention from the network operator or other "inside" sources. In this regard, the end-to-end encryption of the present disclosure is primarily used to ensure sender privacy, not to achieve transmission security of data packets.

The strength of end-to-end encryption can be increased, decreased, or even eliminated without compromising network security, making this approach adaptable to a wide range of applications. For example, if 128b key encryption, indicated by dashed line 1835, is too stringent for small business or personal use, the number of bits can be reduced without sacrificing personal privacy. For military or government applications, the encryption key length can be increased to 192b, 256b, or 512b as needed. In this regard, the SDNP system of the present disclosure overcomes deficiencies of current encryption-based communications and provides functionality not available in alternative applications, devices, or networks.

Security management

Another important feature of SDNP communication is its unique approach to security management. Security controls are required in many situations, such as:
monitoring of employee communications conducted pursuant to HR policies or employee surveys;
・monitoring and recording employee communications in support of financial audits, statutory accounting, financial reporting, etc.;
・Documentation of intercompany communications as part of mergers and acquisitions,
- Documentation of intercompany communications as part of IP or corporate litigation;
- responding to requests for communiqués and documents under subpoenas and criminal investigations;
-Account information, monitoring of calls and messages, and compliance with national security file access legal orders.

With proper authorization, an SDNP network administrator can facilitate access of SDNP network traffic to designated "SDNP Security Agents" for purposes of communication monitoring and data monitoring. The process by which an SDNP security agent is established and activated includes a multi-layered authorization and authentication process that must be performed prior to any monitoring activity. To prevent abuse, no individual can initiate monitoring, not even the SDNP network administrator. Dynamic of SDNP communication as a distributed network with no central control, no master network key, DMZ servers, dynamic SDNP encoding and decoding performed using zone-specific security credentials running offline There is no mechanism for recovering data or retroactively recalling conversations due to their inherent nature. Data only exists in the SDNP network for short periods of time, typically less than 100 milliseconds. As a distributed system, an SDNP network is by design inherently free of centralized control functions and thus pre-call metadata. As such, SDNP networks only support speculative security monitoring. That is, before intercepting a communiqué, it is necessary to establish monitoring by a designated SDNP security agent.

Furthermore, because fragmented mesh communication within the SDNP cloud is dynamic, SDNP nodes within the cloud, across an SDNP gateway, do not transmit data packets containing one complete conversation. Most nodes transmit less than 5% of the data, typically 10 milliseconds at a time, before changing routing. According to SDNP communication, dynamic routing always redirects communication through different media servers. Therefore, cloud access is unsuitable for communiqué recovery and monitoring. Data packets in the SDNP cloud consist of useless jumbles such as irrelevant sounds, data, speech, and junk data that can be captured. Instead, monitoring by a designated SDNP security agent can be productive only on last-mile communications that must pass the complete set of relevant data packets either within the client device or, preferably, within the SDNP gateway. can.

An example of data packet routing during security monitoring is shown in FIG. 105A. Here, SDNP security agent 1840 is monitoring the conversation between SDNP client device 1600A and SDNP client device 1600H. The conversation occurs with data packets sent via the SDNP cloud from the SDNP client device 1600A through the last mile router 1602G to the SDNP gateway 1701U, but the data packets sent from the client device 1600A are closed by the SDNP gateway 1700U, Securely routed to designated SDNP security agent 1840 . Specifically, during transmission over UDP, the last mile data packet 1630A is routed from the SDNP client at address "IP C _1,1 " to the address "IP M ₀ ," coming out from the SDNP gateway at address "IP M _0,4 ". _,0 " and is delivered to the SDNP client address "IP _C7,1 " via zone U7 last mile. During the permitted monitoring period, cloned SDNP data 1 is securely delivered to Security Agent 1840 SDNP at SDNP address "IP SA". A duplicated monitor data packet 1841 operates in the same manner as an SDNP group call, except that the duplicated data clone is invisible to the caller. Callers are therefore unaware that they are being monitored.

Security monitoring is also effective for incoming calls. In FIG. 105B, SDNP data 7 is sent from client device _1600H at address "IP C 7,1 " to the SDNP gateway at address "IP M _0,4 ". After transmission from the SDNP cloud, the data is delivered to two destinations from the SDNP gateway at address "IP M _0,0 ". Client 1600A with address “IP C _1,1 ”, which is the first destination, receives response data packet 1640A containing SDNP data 7 . The second destination, SDNP security agent 1840, receives the same payload via data packet 1842, including the clone data “SDNP data 7”. Since the delivery of data packet 1842 is invisible to the originator, the originator is unaware that it is being monitored.

The same method can be applied to monitor fragmented distributed file storage. However, rather than catching fragmented data files, security agents need only receive copies of the relevant FS links. Such an example is shown in FIG. Here, SDNP file storage device 1700H sends data packet 1740H containing FS link 1 from address "IP F _1,1 " to gateway address "IP M _0,4 ". The cloned payload "FS link 1" is also delivered to the SDNP security agent 1840 at address "IP SA" by data packet 1843 sent from gateway address "IP M _0,0 ". As with real-time communications, the file owner, client 1600A, is unaware that it is being monitored by an SDNP security agent.

The same monitoring mechanism also works for multi-route last-mile communications, where data packets enter and exit the SDNP cloud through multiple SDNP gateways. This case is shown in FIG. Here, the last mile communication from client device 1600A includes split data packet 1630A containing payload SDNP data 1 and data packet 1630B carrying payload SDNP data 2 entering the cloud via SDNP gateways 1701U and 1701V, respectively. After routing in the SDNP cloud, the data packets are recombined and emerge from the cloud as a single data packet 1630L with a payload containing the combined data SDNP data3. In operation, the SDNP gateways at addresses 'IP M _0,0 ' and 'IP M _0,11 ' clone incoming SDNP data 1 and SDNP data 2 from client node C1,1 on instructions from the signaling server. , forward them to the SDNP security agent 1840 at address "IP SA". Cloned data is used for all SDNP data transfers, except that the security agent operates in its own unique security zone, i.e. zone SA using credential information not available to any other device. It is sent in data packets 1841A and 1841B using the same hyper-secure method as the method. As such, there is no record or evidence that a designated security agent monitored a particular conversation.

Because SDNP monitoring activities are covert and essentially equivalent to an undetectable, invisible conference call, the SDNP system employs independent verification methods to authorize and verify network monitoring use. It is important to specify and confirm which SDNP security agents are authorized to perform monitoring. The SDNP security agent can be any SDNP client except network administrators. As a safeguard against system corruption, SDNP network operators and administrators are not permitted to act as SDNP security agents. In other words, a user in control of a network cannot subvert its functionality for their own use, even under threat or extortion.

An SDNP security agent may be an individual, a government agent, a government-appointed agent, or a legal officer. Specific required qualifications for designated security agents vary by company or country, subject to applicable local laws. Monitoring hardware for SDNP security agents uses communication devices or computer servers with recording, data storage, and advanced decryption capabilities. All communications sent from the SDNP network to a designated SDNP security agent are transported in the same hyper-secure communications as the client's own communiqué, so security monitoring remains confidential of the call, except for monitoring by authorized security agents. does not infringe on sex or the privacy of the caller.

Moreover, the monitoring of authorized SDNP agents and the implementation of authorized functions does not compromise the integrity and security of the network in any way. Operational details and DMZ shared secrets are never exposed to network operators or security agents. Operation of the SDNP system is automatic and autonomous without human operator intervention or involvement, and the DMZ server is secured using zone-specific credentials not available through online access. there is Therefore, security monitoring does not compromise the security of the system or make the SDNP network vulnerable to cyberattacks.

The data payload is delivered to the SDNP security agent in the same format as created by the originator. Since all network SDNP encoding is decoded as part of delivery to the SDNP security agent, the delivered data packets do not contain any network security countermeasure information. However, if the client employs end-to-end encryption, the SDNP security agent requires that the client share an end-to-end decryption key with the network or use an independent key server utility accessible from the SDNP network. end-to-end encryption on the client unless you agree in advance. Again, such end-to-end encryption and decryption keys are included in the SDNP method primarily for privacy protection, and are unrelated to the encryption used in SDNP's dynamic encoding function. .

To minimize the risk of monitoring unauthorized use, the SDNP administration used to establish and approve designated SDNP security agents to monitor clients or client groups is a multi-step process. Although the SDNP system includes provisions for performing surveillance, the legal application of this function is the responsibility of network operators, network administrators and authorization authorities or authorities. These parties are personally responsible for ensuring that surveillance is lawful and in compliance with the laws of the country concerned.

The need for surveillance can arise from a variety of circumstances. In a company, a complaint from a whistleblower or an allegation of sexual harassment can trigger an HR investigation or rush to court accounts. Court subpoenas (sometimes including gag orders) related to litigation may also require monitoring. In enterprise matters, communication using a company's SDNP network is generally limited to company communiqués and excludes private and personal communications. Most countries protect private communications unless criminal intent is suspected. In the case of national security or law enforcement activities, the originator's SDNP accounts, both public and private, may be subject to surveillance. In such a case, the corporate SDNP network operator for the company implements the company's communications monitoring process, while the independent telecommunications SDNP network operator is the only provider capable of performing caller-side private communications monitoring. In some countries, a judge-approved subpoena must be filed in order for the government to begin monitoring civilian communications, claiming the government has the power to monitor virtually all private communications. Some countries do. In the case of international communications, it is even more difficult to determine which laws apply and what the network's position should be on enabling call monitoring.

An example of the AAA process used to enable monitoring is shown in FIG. The process of approving client monitoring includes a network administrator 1850 used to configure the monitoring operation, a security agent 1840 responsible for client monitoring, and three approval agents 1851A, 1851B used to approve the monitoring process. 1851C, preferably operating autonomously and independently from a network operator or administrator. The process begins with a network administrator 1850 requesting a monitor request 1862 in response to an investigation or court order. The administrator uses command dialog box 1862 to specify the telephone number of the individual for whom monitoring is requested. If the request is to monitor a group of individuals, all participants can be entered into a file one by one with their respective phone numbers and uploaded to the system.

In approval step 1863, network administrator 1850 uses exemplary dialog box 1864 to identify candidate security agents 1840 that are recommended for performing the monitoring function. For companies, the individual may be a human resources director, legal counsel, member of an audit committee, representative of an independent accounting firm, or independent investigator. In the case of litigation, a security agent may be a solicitor, district attorney, FBI agent, or other duly appointed member of a board of inquiry (e.g., a special prosecutor's board of inquiry panel in cases of government misconduct). . The system then checks the SDNP name server 1714 to make sure the Security Agent has an SDNP account and complies with the rules specified by the company or network operator. In cases involving national security, additional checks of the proposed security agent's credentials and criminal background may be conducted before approval.

If the security agent is approved, an approval step 1865 forwards the monitoring request to the approval agents 1851A, 1851B, and 1851C, which include the name or description of the person to be monitored, or the security agent assigned to perform the monitoring. Review the information listed in dialog box 1866, which includes the name and status of the supervisor, the expected duration of the surveillance investigation, and the reason for the investigation. Each authorization agent can either accept or reject the request. Network operator or company rules determine whether monitoring operations are approved based on unanimous approval of the approval agents or by simple majority vote. The identity of the approval authority may be disclosed in the case of a business, but may remain anonymous due to the anonymous communication capabilities of the SDNP network, such as in criminal cases.

If monitoring is approved, the client's database 1868 is updated with the name server 1714 in an administrative step 1867 to tag the monitored SDNP client and identify the approved SDNP client as a security agent, in this example the data Shaded rows are identified. The SDNP addresses in this database are updated together daily as the SDNP addresses are shuffled to maintain the same relationship between monitored clients and designated security agents. When the investigation schedule expires, the surveillance link is automatically disconnected. In an administration step 1869, a link is sent to the SDNP security agent 1840 so that it can receive all ongoing communications of the identified monitored client. How the agent uses this information is not a matter of SDNP network operation. Unauthorized disclosure of personal information by a security agent may constitute a crime for which the security agent is entirely responsible.

The monitoring method of the present invention allows the SDNP network to support criminal investigations of fraud and potential terrorist activity while maintaining a secure communication medium for law-abiding citizens. The SDNP network can securely deliver private client communications to authorities in compliance with court orders without jeopardizing the privacy of innocent civilians or jeopardizing the security of the SDNP global communications network. Future communications over the SDNP network remain anonymous and hyper-secure, as no backdoors or master keys are used to honor court orders. In this way, secure dynamic communication networks and protocols and their hyper-secure last-mile communications can provide security features not possible by other means and are employed by OTT and almost all messenger and communicator apps. It completely avoids the risks of supporting crime and terrorism caused by over-reliance on end-to-end encryption.

Overcoming SS7 vulnerability

Even if the Apple-FBI dispute wasn't much of a problem for the telecoms and security industries, the 60 Minutes episode (http://www.cbsnews.com/news/60-minutes-hacking-your- phone/) revealed serious security vulnerabilities in SS7 (Signaling System 7), the signaling control channel of traditional wireless telephones. As the show clearly demonstrates, the SS7 vulnerability exposes all smartphones and connected devices to packet sniffing and cyberattacks, allowing anyone who knows a person's phone number to eavesdrop on conversations and view SMS texts, attachments, and images.

Signaling System 7 (SS7) is a telephony signaling protocol developed in 1975 and used in all forms of digital telephony worldwide. SS7 consists of a message transfer part, or "MTP", which operates at PHY layer 1, data link layer 2, and network layer 3, and handles the routing of calls. End-to-end routing is managed by the Signaling Connection Control or "SCCP" operating at transport layer 4. The protocol also includes a number of application layer 7 functions related to billing, roaming and call authentication. The SS7 protocol, although absolutely necessary, is highly vulnerable to attack and poses a serious risk to the security of conventional telephony.

In April 2016 (https://en.wikipedia.org/wiki/Signalling_System_No._7), the US Congressional Oversight Committee reported: "The applications of this vulnerability could be endless, from criminals monitoring individual targets, to foreign companies conducting industrial espionage against US companies, to nation states monitoring US government officials... ) This vulnerability has serious implications not only for individual privacy, but also for innovation, competitiveness, and national security in the United States.Many innovations in digital security, such as multi-factor authentication using text messages, Technology can become useless."

SS7 cyberattacks basically fall into the category of packet sniffing, which uses the unique format of SS7 information as a guide to intercept both content and metadata. The SS7 protocol basically provides information templates that are used to interpret packet information. As shown in Figure 109, the problem begins with the SIM card, or "Subscriber Identity Module". SIM cards contain various types of personal information about subscribers and their accounts. As shown, a carrier SIM card 1880, typically issued by a network provider, is portable to a cellular network as illustrated by antennas 25A, 25B and 25C and their corresponding radio links 28A, 28B and 28C. Used to identify phone 32 . Each SIM card contains a unique identifier, the ICCID or "Integrated Circuit Card ID", which is an 18 or 19 digit number used to identify it internationally. The International Mobile Subscriber Identity or IMSI identifies the individual operator network, ie the home network in which the SIM card works. The local network provider uses the IMSI number to communicate with the SIM card and establish a call.

The SIM card also contains a three-digit "operating area identification code" or MCC to identify the country of issue of the SIM card. MCC is required as part of the dialing sequence when making an international call from a mobile phone. Examples of MCCs include 310-316 in the United States, 234-235 in the United Kingdom, 460 in China, 208 in France, 250 in Russia, 262 in Germany, 302 in Canada, and 724 in Brazil. The MCC is used in combination with the "mobile network code" or MNC to identify the network provider that issued the SIM card. A complete list of these codes is listed at "https://en.wikipedia.org/wiki/Mobile_country_code". The SIM card also contains a 15-digit "Mobile Station International Subscriber Telephone Number" or MSISDN to uniquely define the subscriber and the type of network the SIM operates on. In addition to the user's phone number, the SIM card also holds an SMS text directory that records the time and date of incoming and outgoing calls and texts. In recent years, carriers have begun using dedicated SIM cards with so-called secure elements to store credit card credentials in order to facilitate mobile payments.

Since the MCC, MNC, and MSISDN codes are sent as part of the connection process, SS7 intrusion and packet sniffing can easily identify the SIM card's home country and carrier, as well as the subscriber's associated phone number. . Transmitted data 1881 can easily be used to track the caller's identity through phone books, online information, or social media, ie through profiling. Once identified and associated, the phone number and SIM can be used to monitor subscriber activity wherever the subscriber travels around the world. Encryption does not obscure the underlying call information or metadata. Even with end-to-end encryption, data packets can easily be identified as being from the same conversation and captured and stored for subsequent decryption attempts.

Aside from metadata and content, the originator's location is also compromised by the SS7 vulnerability. In a cellular network, a phone sends a message to a local base station identifying it as available at a particular base station. These registration packets are sent periodically. By monitoring these packets, the location of a phone using a particular SIM card can be determined even when the phone is not on the phone or GPS is turned off. It can be specified even if the setting is not turned on. In this manner, the subscriber's location and movements can be tracked without the subscriber's knowledge.

Despite this inherent vulnerability of SS7, hyper-secure last-mile communication performed according to a secure dynamic communication network and protocol, by obfuscating meaningful call data at the last link. Repel the SS7 attack. In particular, hyper-secure last-mile communications have significant security advantages over traditional telephone communications or OTT Internet communications, such as:
• In hyper-secure last-mile communication, the phone number or IP address of the party receiving the call or message is not revealed, even if the other party is not an SDNP client.
• Hyper-secure last-mile communication does not identify whether sequential data packets are part of the same call or represent different destinations and unrelated data packets.
• By hiding call specificity in data packets, hyper-secure last-mile communication obscures metadata about call times.
• Hyper-secure last-mile communications dynamically encode payloads, prevent unauthorized access to packet content, and protect the privacy of voice, video, text communications, photos, files, and other content.

Therefore, as previously described, communications using the disclosed secure dynamic communications network and protocol and hyper-secure last-mile communications are immune to SS7 vulnerabilities. Since SDNP communication is carried out using a proprietary protocol and transmitted by encoded payloads, even packets transmitted over open, unencrypted channels such as 2G, 3G, 4G/LTE telephony , it is not possible to extract call data or content from SDNP data packets. Therefore, attempts to launch cyberattacks against SDNP coding and fragmented data transfers using packet sniffing are ineffective.

SDNP camouflage function

Given the above, the only impact of the SS7 vulnerability on SDNP communication is to reveal the location of the caller. Since the phone number of the mobile communication company's SIM is linked to each user's ID, when the mobile phone is turned on, communication with the nearest mobile phone base station always occurs even if there is no call. This base station information can be used to triangulate the user's position and track the subscriber's movements even with GPS turned off. Because such unauthorized tracking relies on SS7, devices using legacy mobile operator SIM cards are vulnerable to location tracking, even those acting as SDNP clients. be.

As shown in the simplified network schematic diagram of FIG. 110, the hyper-secure last-mile communication enhancement referred to in this disclosure as the "SDNP Impersonation Feature" prevents subscriber tracking entirely. To implement this feature, the regular mobile carrier SIM card 1880 is replaced with an SDNP SIM card 1882 . No personal subscriber information is recorded on the SDNP SIM card 1882 because the SDNP SIM card is registered with the SDNP network operator, not the subscriber. The SDNP SIM card 1882 is similar to a prepaid SIM card in that it allows network access, but does not contain any personal information. Instead, all of an account holder's personal information is stored securely within the nameservers of the SDNP network and cannot be accessed by hackers or subjected to cyberattacks.

In operation, the SDNP impersonation feature hides the true identity of the owner by using a SIM card 1882 that is known only to the SDNP network operator. Thus, the phone number contained within the SIM card is used to establish the PHY layer 1 and data link layer 2 connection 28B between the mobile phone 32 and the base station 25B, but does not perform any routing. . Instead, the source and destination addresses of data packets for last-mile routing are managed by SDNP application 1335A and SDNP gateway 1601A according to instructions from SDNP signaling server 1603A.

Calls from SDNP apps routed through SDNP gateway 1601A are displayed with a number different from the SIM card number. This conversion from physical SIM card numbers to SDNP phone numbers is performed by SDNP name server 1604A. Disguise the physical SIM card number for all users by converting SDNP phone numbers to SIM phone numbers according to the conversion table 1885 during call routing. Using the disguise feature of SDNP completely hides the true identity of the phone's owner. To call an SDNP client, an outside caller calls the SDNP number, even if he or she is not the SDNP client. The SDNP network automatically routes this call to the SDNP client without exposing the SIM card's phone number. Similarly, an SDNP client makes a call to a non-SDNP party and the recipient of this call sees the incoming call from the SDNP number rather than the SIM card number. In this way, SDNP performs telephony functions similar to NAT gateways for Internet communications. The only difference is that the SDNP system is a real-time network and the Internet is not.

Since the true user identity of the mobile phone 32 is not revealed by the call 28B, triangulation of the mobile phone's location is useless as all communications with that user remain anonymous. So tracking the location of an unidentified cell phone does nothing useful to a hacker and avoids the SS7 vulnerability. If the SDNP client is traveling abroad, the traveler can purchase a local prepaid SIM card and link it to the SDNP number. SDNP subscribers will continue to receive calls placed to SDNP phone numbers, but roaming charges are avoided because last link communication occurs using the local SIM card. In this way, one SDNP phone number can be used as a global number without long distance charges.

SDNP subnet

The SDNP communication cloud can be remotely deployed across any network of interconnected computers, privately or publicly hosted, using proprietary softswitches, which are software-based communication nodes. Examples of server networks include privately owned and publicly rented networks, such as those hosted by Microsoft, Google, and Amazon. Figure 111 shows two SDNP clouds deployed on two separate server networks. As shown in this figure, an SDNP cloud consisting of servers 1901A, 1901B, 1901C, and 1901D has SDNP communication nodes M _0,0 , M _0,4 , M _0,7 and M _0,8 respectively. are hosting. A second SDNP cloud consists of servers 1902A, 1902B, and 1902C, hosting SDNP nodes M _10,0 , M _10,1 , and M _10,2 , respectively. Since each of these clouds utilizes separate security credential information for Zone Z0 and Zone Z10, the two SDNP clouds are completely separate and cannot share information directly. However, a single SDNP client, shown as mobile phone 32 running SDNP app 1335, authenticates properly to both clouds, even though it is hosted by different computer server leasing providers. is accessible. As shown in the example, SDNP client C _1,1 uses hyper-secure last-mile communication through router 1910 to access _SDNP gateway node M 0,7 in zone Z0 cloud, and through the same router 1910 to SDNP gateway node M 0,7. can access the SDNP gateway node M _10,0 in the zone Z10 cloud using hyper-secure last-mile communication without risk of commingling conversations or data packets between them.

Access to the two independent clouds is through a common communicator application UI/UX 1920 . Access to each cloud is compartmentalized into separate dialog sandboxes 1921A and 1921B. Information can be downloaded from the personal account sandbox 1921A to the mobile phone, but how data is exported from the business account sandbox 1921B depends on the company and its security controls.

To connect a device to the SDNP cloud, an SDNP app needs to be installed on the device as software or firmware. Installation occurs as follows: (i) download the application, (ii) verify device identity with an authentication code generated on the SDNP network, (iii) establish personal identification credentials, and (iv) a specific SDNP. Obtaining approval to participate in the cloud. Once activated, the SDNP application creates a hyper-secure last-mile connection to an independent SDNP cloud. Identity confirmation and user authentication for business accounts is often more complex than required for personal account access and may require multi-factor authentication methods.

Because SDNP communication is software-based and each communication cloud uses its own security credentials, there is no interaction between installed SDNP communication networks, even if they are hosted on the same server. Since each SDNP cloud customized by zone-specific security credentials is uniquely defined, two SDNP clouds are different and cannot share data directly. Advantageously, multiple SDNP clouds can coexist in the same server or server network without the risk of data leakage. Access to business networks is controlled as defined according to the cloud owner's requirements. Therefore, when sharing a common host server, mixing two accounts and communication clouds is prohibited and operates with the same security as if two different phones were required to connect to two different networks. The autonomy of zone-specific SDNP clouds, or "subnets", is shown in more detail in FIG. In this figure, servers 1121A, 1901B, 1901C, 1901D are hosting two clouds simultaneously. One cloud is SDNP communication nodes M _0,0 , M _0,4 , M _0,7 and M _0,8 in zone Z0 and the other cloud is zone Z7 SDNP communication nodes M _7,0 , M _7,4 , M _7,7 and M _7,8 . Despite operating within the same server, hyper-secure communication using the protocol established by SDNP can prevent direct data exchange. Access is therefore governed by last-mile communication rather than direct cloud-to-cloud data exchange.

SDNP communication is not limited to privately leased, publicly available servers, but can also be customized for various types of businesses or government agencies. In fact, private companies often prefer to host their own networks, especially for business-critical applications. Examples of private networks include FedEx, Walmart, IBM, and others. For confidentiality reasons, networks used by research institutes, universities, and medical centers are also often hosted independently by organizations. Private server networks are also often employed for hosting purposes such as: That is, SalesForce. com, Box. Global business cloud applications such as com, Dropbox, eTrade, SAP, eBay, Amazon.com. com, Priceline. e-commerce platforms and comparison shopping networks such as.com, e-Insurance; media streaming services such as YouTube, Amazon Prime, Netflix, Hulu, Comcast Xfinity; and social media such as Facebook, Twitter and Snapchat.

In larger enterprises, IT departments may choose to operate separate networks for parent organizations and subsidiaries. However, many private companies see infrastructure costs as an important factor in network design. Rather than supporting two completely different hardware-based systems, the SDNP system provides corporate organizations with the ability to deploy networks using a combination of separate shared server resources. As shown in Figure 113, two legal entities, eg, a parent company and its subsidiary, jointly host a server network consisting of both separate and shared servers. Specifically, servers 1903, 1904B, 1904C, and 1904D host communication nodes _M7,0 , _M7,4 , _M7,7 , and _M7,8 , respectively, in zone Z7 for the parent enterprise entity. , while servers 1901A, 1901B, 1901C, and 1903 respectively host communication nodes M _0,0 , M _0,4 , M _0,7 , M _0,8 in zone Z 0 for local subsidiaries of the company. As shown, server 1903 hosts, for example, two SDNP communication nodes, node M _7,0 for the parent entity and node M _0,8 for the subsidiary. Even if server 1903 and other servers (not shown) are shared by both entities, no data is shared directly between the parent and subsidiary SDNP clouds due to the different security credential information. Employees are typically restricted to accessing only their employer's cloud, but executives may need access to both clouds. Properly authorized users as shown in the SDNP Communicator App UI/UX 1920 contain individual dialog sandboxes 1921C and 1921D for various legal entities. In this way, one mobile phone or tablet can access multiple SDNP clouds of different entities without the risk of data commingling, as if the user had multiple mobile phones. .

The SDNP App's multi-profile feature, which enables or disallows access to multiple SDNP clouds using last-mile hyper-secure security credentials, supports an unlimited number of account profiles from a single SDNP App. For example, in FIG. 114, SDNP client C _1,1 receives data from the global SDNP telco in zone Z99, which includes servers 1909A through 1909E hosting _SDNP nodes M _99,1 through M 99,5, respectively, without long distance charges. In addition to being able to make international calls, other services such as, for example, a corporate cloud in zone Z9 consisting of servers 1905A, 1905B, and _1905C hosting SDNP nodes _M9,0 , _M9,4 , and M9,8. Access to the cloud is also possible and also calling subscribers of the zone Z0 cloud via servers 1901A, 1901B, 1901C hosting SDNP nodes M _9,0 , M _0,4 and M _0,8 respectively. can also Access rights to specific clouds are applied through last-mile communication to the SDNP gateway and are managed by the system's SDNP signaling server and the SDNP name server used to manage authorized users.

SDNP communication is equally applicable in high security and restricted access networks required in the government and security sectors. For example, in the United States, various organizations such as local and state law enforcement agencies, the FBI, the United States Defense Forces, the United States National Security Agency, the United States Armed Forces (individual and joint), and the United States Department of State use security-restricted communications to: Needs with parliamentary and legislative server networks. Other countries likewise host separate networks for various government agencies.

To support access to specific clouds with a "need-to-know" policy, SDNP communication methods and techniques can be leveraged to implement a nested subnet architecture. FIG. 115 is an example of a nested SDNP cloud structure, one consisting of leased computer servers 1907A through 1907D hosting SDNP communication nodes M0,0, M0,4, M0,5, M0,9 respectively. is shown as a secure cloud of Communications in this outer network “shell” contain security credential information for zone Z 0 and are displayed in a “secret” level dialog sandbox 1912 E displayed in SDNP communicator 1920 . The nested cloud includes government-hosted servers 1906A, 1906B, 1906C, and hardened security credentials for zone Z8, including corresponding _SDNP server nodes _M8,0 , _M8,2 , M8,4. A security inner core is also included. Client C _1,1 access to Zone Z8 Core requires "top secret" security permission and must communicate through hardened communication sandbox 1921F. One example of a governmental application of this technology is in the US Department of State, where top secret communications in zone Z8 are restricted to access by ambassadors and secretaries of state, while other US embassy staff around the world use security credentials in zone Z0. Only hyper-secure "top secret" communication using information is available.

Claims (17)

A method of sending data packets from a client device to the cloud, comprising:
said data packet is included in a communication;
the cloud comprises a plurality of media nodes and a plurality of gateway nodes;
The method is
the client device sending a call request to a signaling server, the call request including contact information about the called party;
the signaling server determining a route for communicating with the called party, the route comprising a first route including a first gateway node and a second route including a second gateway node; wherein none of the first gateway node, the second gateway node, and other media nodes have information indicative of the entirety of the first route or the second route; ,
the signaling server sending command and control packets to the client device, the first gateway node, and the second gateway node, respectively, wherein the command and control packets are sent to the client device, the said step comprising a routing instruction packet sent by a first gateway node and said second gateway node;
the client device transmitting a first data packet included in the communication from the client device to the first gateway node in response to the command and control packet and second data included in the communication; and C. sending packets from the client device to the second gateway node. the first data packet is transmitted from the client device to the first gateway node over a first physical medium;
2. The method of claim 1, wherein the second data packet is transmitted from the client device to the second gateway node via a second physical medium. wherein the first physical medium comprises a cellular telephone link;
3. The method of claim 2, wherein the second physical medium comprises a WiFi channel. providing the first data packet with a first IP source address;
3. The method of claim 2, further comprising providing a second IP source address for said second data packet. providing the first data packet with a first IP source address;
and providing a second IP source address for the second data packet. Before the signaling server sends the command and control packets to the client device, the first gateway node, and the second gateway node, respectively, the signaling server transmits the contact information about the callee. 2. The method of claim 1, wherein the name server is contacted using a. the contact information for the callee includes a confidential identification of the callee;
The name server converts the confidential ID to the SDNP address of the called party,
7. The method of claim 6, wherein the signaling server uses the SDNP address of the callee when determining the route for communicating from the client device to the callee. the contact information about the callee includes a telephone number of the callee;
the name server translates the telephone number to the address of the gateway node closest to the callee's location;
7. The method of claim 6, wherein the signaling server uses an address of a gateway node closest to the callee's location when determining the route for communicating from the client device to the callee. . 7. The method of claim 6, passing information to the name server each time the client device accesses the cloud. The command and control packet sent by the signaling server to the client device comprises: a first routing instruction to send the first data packet to the first gateway node; and the second data packet. to the second gateway node. Each of the first gateway node and the second gateway node has a first address for communicating with the client device and a second address for communicating within the cloud. 11. The method of claim 10. said client device transmitting said first data packet and said second data packet to said first gateway node and said second gateway node via a router, respectively;
The method is
providing the first data packet with a first MAC source address;
6. The method of claim 5, further comprising providing the second data packet with a second MAC source address. further comprising providing a plurality of signaling servers;
the signaling server partitions the task of routing the packets from the client device to the callee;
2. The method of claim 1, wherein none of said plurality of signaling servers has information indicating the entire transmission route of said packet. further comprising concealing at least one content contained in the first data packet and the second data packet using a combination of concealment techniques;
2. The method of claim 1, wherein the concealment techniques include encryption, scrambling, junk data insertion, segmentation and/or mixing, and are based on predetermined states. 15. The method of claim 14, wherein the state includes time, node number, network identifier, or GPS location. the first physical medium comprises a cellular telephone link modulated using a first carrier frequency;
3. The method of claim 2, wherein the second physical medium comprises a cellular telephone link modulated using a second carrier frequency. the first physical medium comprises a WiFi channel modulated using a first carrier frequency;
3. The method of claim 2, wherein the second physical medium comprises a WiFi channel modulated using a second carrier frequency.

Images