Methods and apparatus for HyperSecure last mile communication
11696367 · 2023-07-04
Assignee
Inventors
Cpc classification
H04L63/0428
ELECTRICITY
H04L63/30
ELECTRICITY
H04W4/06
ELECTRICITY
H04L63/18
ELECTRICITY
H04W88/06
ELECTRICITY
H04L12/28
ELECTRICITY
International classification
H04L12/28
ELECTRICITY
H04W4/06
ELECTRICITY
Abstract
A variety of techniques for concealing the content of a communication between a client device, such as a cell phone or laptop, and a network or cloud of media nodes are disclosed. Among the techniques are routing data packets in the communication to different gateway nodes in the cloud, sending the packets over different physical media, such as an Ethernet cable or WiFi channel, and disguising the packets by giving them different source addressees. Also disclosed are a technique for muting certain participants in a conference call and a highly secure method of storing data files.
Claims
1. A communication network comprising a client device and a cloud of secure dynamic communication network and protocol (SDNP) media nodes, the cloud of SDNP media nodes comprising an SDNP gateway node, the client device including an application program able to interpret data concealed by an SDNP concealment process; the SDNP concealment process comprising at least one of encryption, scrambling, splitting and insertion of junk data; a first digital data packet containing a first digital payload traversing a last mile connection between the client device and the SDNP gateway node; and a second digital data packet containing a second digital payload contemporaneously traversing the cloud of SDNP media nodes; wherein data in each of the first and second digital data packets is concealed using an SDNP concealment process and wherein the SDNP concealment processes performed on the first and second data packets, respectively, comprise different algorithms, sequences, or security credentials.
2. The communication network of claim 1 wherein the SDNP concealment process used on the first digital data packet uses security credentials associated with a last mile security zone, the security credentials associated with a last mile security zone being different from security credentials associated with a security zone wherein the second digital data packet is present.
3. The communication network of claim 1 wherein the concealment process used on each of the first and second digital data packets, respectively, is determined by a state.
4. The communication network of claim 3 wherein the state comprises a time at which each of the first and second digital data packets, respectively, was created.
5. The communication network of claim 3 wherein the first digital data packet transverses the last mile connection in a direction from the client device to the SDNP gateway node, the communication network comprising a third digital data packet traversing the last mile connection in a direction from the SDNP gateway node to the client device, and wherein the state used in the concealment process for the first digital data packet is different from the state used in the concealment process for the third digital data packet.
6. The communication network of claim 1 wherein the data in the first digital data packet contains video, sound, images, text, or data files, or a mix thereof.
7. The communication network of claim 1 wherein first digital data packet contains data from a sensor or a transducer.
8. The communication network of claim 1 wherein the second digital data packet is traversing from the SDNP gateway node to another SDNP node in the cloud.
9. The communication network of claim 8 where the first digital data packet contains header data that enables the SDNP gateway media node to identify the first digital data packet as a valid incoming data packet.
10. The communication network of claim 1 comprising a second client device, a second SDNP gateway node, and a third digital data packet traversing a last mile connection between the second client device and the second SDNP gateway node, wherein data in the third digital data packet is concealed with an SDNP concealment process using algorithms or security credentials that are different from algorithms or security credentials in the SDNP concealment process used to conceal the data in the first digital data packet.
11. The communication network of claim 10 wherein the second client device is the ultimate destination of the first digital data packet, and wherein the first digital data packet contains the address of the second client device concealed using an SDNP concealment process.
12. The communication network of claim 10 wherein the second client device is the ultimate destination of the first digital data packet, and wherein the first digital data packet does not contain the address of the second client device.
13. The communication network of claim 1 wherein the last mile connection comprises different physical mediums, including low earth orbit satellites, geosynchronous satellites, cellular communication networks, and microwave radio communication.
14. A communication network comprising a client device and a cloud of secure dynamic communication network and protocol (SDNP) media nodes, the cloud of SDNP media nodes comprising an SDNP gateway node; a last mile connection between the client device and the SDNP gateway node, the last mile connection comprising at least one intermediate data router; a first digital data packet containing a first digital payload traversing a portion of the last mile connection between the at least one intermediate router and the SDNP gateway node; and a second digital data packet containing a second digital payload contemporaneously traversing the cloud of SDNP media nodes; wherein data in each of the first and second digital data packets is concealed using an SDNP concealment process, the SDNP concealment process comprising at least one of encryption, scrambling, splitting and insertion of junk data; and wherein the SDNP concealment processes performed on the first and second data packets, respectively, comprise different algorithms, sequences, or security credentials.
15. The communication network of claim 14 wherein the at least one intermediate data router comprises a WiFi router, a network router, an Ethernet router, a cable network, or a cellular network.
16. The communication network of claim 14 wherein the last mile connection includes a wireless portion and a wireline portion.
17. The communication network of claim 14 wherein the at least one intermediate router includes SDNP firmware, thereby enabling the router to function as a remote SDNP gateway node.
18. The communication network of claim 17 comprising a third digital data packet containing third digital payload, the third digital data packet traversing a last link portion of the last mile connection between the client device and the at least one intermediate router, the third digital payload containing data that is encrypted but is not concealed using an SDNP concealment process.
19. The communication network of claim 18 wherein the client device and the at least one intermediate router contain the same encryption key so as to enable the client device and the at least one intermediate router to be able to encrypt and decrypt data in the third digital payload.
20. The communication network of claim 19 wherein the third digital payload is encrypted in accordance with either a secure wired local area network (LAN) or WiFi protected access (WPA) protocol.
21. The communication network of claim 14 wherein the last mile includes two routers running SDNP firmware and forming a wireline or wireless SDNP bridge.
22. The communication network of claim 21 wherein the SDNP bridge comprises an Ethernet cable or a WiFi data link.
23. The communication network of claim 21 wherein the SDNP bridge comprises a cable wireline connection using coaxial cable or optical fiber.
24. The communication network of claim 21 wherein the SDNP bridge comprises a cellular communication network.
25. The communication network of claim 21 wherein the SDNP bridge comprises a radio communication network among vehicles.
26. The communication network of claim 21 wherein the SDNP bridge comprises a microwave satellite link.
27. The communication network of claim 26 comprising additional client devices enabled with SDNP software and linked by satellite communication with the cloud of SDNP media nodes.
28. The communication network of claim 27 wherein the additional client devices include a ship, airplane, or train.
29. The communication network of claim 28 wherein at least one of the additional client devices is in the form of a local area network for exchanging digital data packets with multiple persons.
30. The communication network of claim 25 where the client device is in the form of a local area network for exchanging digital data packets with multiple persons.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
(1) In the drawings listed below, components that are generally similar are given like reference numerals. It is noted, however, that not every component to which a given reference number is assigned is necessarily identical to another component having the same reference number. For example, an encryption operation having a particular reference number is not necessarily identical to another encryption operation with the same reference number. Furthermore, groups of components, e.g., servers in a network that are identified collectively by a single reference number are not necessarily identical to each other.
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
(18)
(19)
(20)
(21)
(22)
(23)
(24)
(25)
(26)
(27)
(28)
(29)
(30)
(31)
(32)
(33)
(34)
(35)
(36)
(37)
(38)
(39)
(40)
(41)
(42)
(43)
(44)
(45)
(46)
(47)
(48)
(49)
(50)
(51)
(52)
(53)
(54)
(55)
(56)
(57)
(58)
(59)
(60)
(61)
(62)
(63)
(64)
(65)
(66)
(67)
(68)
(69)
(70)
(71)
(72)
(73)
(74)
(75)
(76)
(77)
(78)
(79)
(80)
(81)
(82)
(83)
(84)
(85)
(86)
(87)
(88)
(89)
(90)
(91)
(92)
(93)
(94)
(95)
(96)
(97)
(98)
(99)
(100)
(101)
(102)
(103)
(104)
(105)
(106)
(107)
(108)
(109)
(110)
(111)
(112)
(113)
(114)
(115)
(116)
(117)
(118)
(119)
(120)
(121)
(122)
(123)
(124)
(125)
(126)
(127)
(128)
(129)
(130)
(131)
(132)
(133)
(134)
(135)
(136)
(137)
(138)
(139)
(140)
(141)
(142)
(143)
(144)
(145)
(146)
(147)
(148)
(149)
(150)
(151)
(152)
(153)
(154)
(155)
(156)
(157)
(158)
(159)
(160)
(161)
(162)
(163)
(164)
(165)
(166)
(167)
(168)
(169)
(170)
(171)
(172)
(173)
(174)
(175)
(176)
(177)
(178)
(179)
(180)
(181)
(182)
DESCRIPTION OF THE INVENTION
(183) After nearly one-and-a-half centuries of circuit-switched telephony, today's communication systems and networks have within only a decade all migrated to packet-switched communication using the Internet Protocol carried by Ethernet, WiFi, 4G/LTE, and DOCSIS3 data over cable and optical fiber. The benefits of comingling voice, text, pictures, video, and data are many, including the use of redundant paths to insure reliable IP packet delivery, i.e. the reason the Internet was created in the first place, along with an unparalleled level of system interoperability and connectivity across the globe. With any innovation, however, the magnitude of challenges new technology creates often match the benefits derived.
(184) Disadvantages of Existing Communication Providers
(185) As detailed throughout the background section of this disclosure, present-day communication suffers from many disadvantages. The highest performance communication systems today, comprising custom digital hardware owned by the world's major long-distance carriers such as AT&T, Verizon, NTT, Vodaphone, etc., generally offer superior voice quality but at a high cost including expensive monthly subscription fees, connection fees, long-distance fees, complex data rate plans, long-distance roaming charges, and numerous service fees. Because these networks are private, the actual data security is not publically known, and security infractions, hacks, and break-ins are generally not reported to the public. Given the number of wire taps and privacy invasions reported in the press today, private carrier communication security remains suspect, if not in their private cloud, in the very least in their last-mile connections.
(186) “Internet service providers” or ISPs form another link in the global chain of communications. As described in the background of this invention, voice carried over the Internet using VoIP, or “voice over Internet protocol” suffers from numerous quality-of-service or QoS problems, including The Internet, a packet-switched network, is not designed to deliver IP packets in a timely manner or to support real-time applications with low latency and high QoS The routing of an IP packet takes an unpredictable path resulting in constantly changing delays, bursts of high data-error rates, and unexpected dropped calls IP packet routing is made at the discretion of the Internet service provider, which controls the network within which the packet is routed and may adjust routing for balancing its own network's loading or to better serve its VIP clients at the expense at degrading connection quality of general traffic traversing its network. Over-the-top or OTT providers such as Line, KakaoTalk, Viber, etc. catching a free ride on the Internet act as Internet hitchhikers and have no control over the network or factors affecting QoS. Using heavyweight audio CODECs that fail to provide comprehendible voice quality audio even at moderate data rates VoIP based on the TCP transport protocol suffers from high latency and degraded audio caused by delays induced during handshaking and IP packet rebroadcasting. Unaided UDP transport provides no guarantee of payload integrity.
(187) Aside from QoS issues, the security of today's devices and networks is abysmal, representing a level totally unacceptable to support the future needs of global communication. As detailed in the background section of the US patent application entitled Secure Dynamic Communication Network and Protocol, network security is prone to a large array of cyber-assaults on communicating devices, including spyware, Trojan horses, infections, and phishing; on the last link, including spyware, IP packet sniffing, wiretaps, and call interception of cyber pirate “faux” cellphone towers; and in the local network or telco portion of last-mile connectivity, involving spyware, IP packet sniffing, infections such as viruses, and cyber pirate “man in the middle attacks”. The cloud itself is subject to unauthorized access by breaking security at any cloud gateway, by infections such as viruses, from cyber pirates launching man-in-the-middle attacks, from denial-of-service attacks, and from unauthorized government surveillance. In summary, today's communication security is compromised by numerous vulnerabilities easily exploited by cyber pirates and useful for committing cybercrime and violations of cyberprivacy, including: Revealing the destination of an IP packet, including the destination IP address, the destination port #, and the destination MAC address. Revealing the source of an IP packet, including the source IP address, the source port #, and the source MAC address. Revealing the type of Layer 4 transport employed and by the port # the type of service requested and application data encapsulated in the IP packet's payload In unencrypted files, all application and file data encapsulated in the IP packet's payload, including personal and confidential information, login information, application passwords, financial records, videos, and photographs. A dialog of communications, enabling a cyber party the repeated opportunity to break encrypted files Numerous opportunities to install malware, including spyware and phishing programs and Trojan horses into communicating devices and routers using FTP, email, and web page based infections
(188) Reiterating a key point, the fundamentally intrinsic weakness of packet-switched communication networks using Internet Protocol, is that any hostile party or cyber-pirate intercepting an IP packet can see what devices were involved in creating the data contained with the IP packet, where the IP packet came from, where the IP packet is being sent to, how the data is being transported, i.e. UDP or TCP, and what kind of service is being requested, i.e. what kind of application data is contained within the payload. In this regard, a cyber pirate is able to determine the “context” of a conversation, improving their opportunity to crack encryption, break password security, and gain unauthorized access to files, data, and payload content.
(189) Encryption—To defend against the diverse range of cyber-assaults as described, present day network managers, IT professionals, and application programs primarily rely on a single defense—encryption. Encryption is a means by which to convert recognizable content also known as “plaintext”, whether readable text, executable programs, viewable videos and pictures, or intelligible audio, into an alternate file type known as “ciphertext”, that appears as a string of meaningless textual characters.
(190) The encryption process, converting an unprotected file into an encrypted file, involves using a logical or mathematical algorithm, called a cypher, to change the data into equivalent textual elements without revealing any apparent pattern of the encryption's conversion process. The encrypted file is then sent across the communication network or medium until received by the destination device. Upon receiving the file, the receiving device, using a process known as “decryption, subsequently decodes the encoded message to reveal to original content. The study of encryption and decryption, known broadly as “cryptography”, blends elements of mathematics, including number theory, set theory and algorithm design, with computer science and electrical engineering.
(191) In simple “single key” or “symmetric key” encryption technologies, a single key word or phrase known a priori by both parties can be used to unlock the process for encrypting and decrypting a file. In World War II, for example, submarines and ocean ships communicated on open radio channels used encrypted messages. Initially, the encryptions were single-key-based. By analyzing the code pattern, Allied cryptologists were sometimes able to reveal the encryption key word or pattern and thereafter were able to read encrypted files without discovery. As encryption methods became more complex, breaking the code manually became more difficult.
(192) Code evolved into mechanical machine-based ciphers, an early form of computing. At the time, the only way to break the code was stealing a cypher machine and using the same tools to decipher a message as those encrypting the files. The challenge was how to steal a cypher machine without the theft being detected. If it were known that a code machine had been compromised, the enemy would simply change their code and update their cypher machines already in operation. This principle is practiced still today—the most effective cyber-assault is one that goes undetected.
(193) With the advent of computing and the Cold War, encryption became more complex but the speed of computers used to crack encryption codes also improved. At each step in the development of secure communications, the technology and knowhow for encrypting information and the ability to crack the encryption code developed nearly at pace. The major next evolutionary step in encryption came in the 1970s with the innovation of dual-key encryption, a principle still in use today. One of the best-known dual key encryption methods is the RSA public key cryptosystem, named after its developers Rivest, Shamir, and Adleman. Despite published recognition for RSA, contemporaneous developers independently conceived of the same principle. RSA employs two cryptographic keys based on two large prime numbers kept secret from the public. One algorithm is used to convert these two prime numbers into an encryption key, herein referred to as an E-key, and a different mathematical algorithm is used to convert the same two secret prime numbers into a secret decryption key, herein referred to also as a D-key. The RSA-user who selected the secret prime numbers, herein referred to as the “key publisher’, distributes or “publishes” this algorithmically generated E-key comprising typically between 1024b to 4096b in size, to anyone wishing to encrypt a file. Because this key is possibly distributed to many parties in an unencrypted form, the E-key is known as a “public key”.
(194) Parties wishing to communicate with the key publisher then use this public E-key in conjunction with a publically available algorithm, typically offered in the form of commercial software, to encrypt any file to be sent to the particular key publisher. Upon receiving an encrypted file, the key publisher then uses their secret D-key to decrypt the file, returning it to plaintext. The unique feature of the dual-key method in general and RSA algorithm in particular is that the public E-key used to encrypt a file cannot be used for decryption. Only the secret D-key possessed by the key publisher has the capability of file decryption.
(195) The concept of a dual-key, split-key, or multi-key exchange in file encryption and decryption is not limited specifically to RSA or any one algorithmic method, but methodologically specifies a communication method as a sequence of steps. For example, in a dual-key exchange over a switch packet communication network a device, e.g. a notebook wishing to receive a secure file from a cell phone first generates two keys, an E-key for encryption and a D-key for decryption using some algorithm. The notebook then sends the E-key to the cell phone using a public network communication carrying an IP packet. The IP packet in unencrypted form, contains the MAC address, IP source address “NB” and port address of the notebook along with the destination IP address “CP” and corresponding port of the cell phone as well as the transport protocol TCP and an encrypted copy of an E-key as its payload.
(196) Using an agreed upon encryption algorithm or software package, the cell phone then processes a plaintext file using an encryption algorithm and encryption E-key to produce an encrypted file, i.e. ciphertext, carried as a payload of IP packet in a secure communication from the cell phone to the notebook. Upon receiving the IP packet, the algorithm decrypts the file using secret decryption key, i.e. D-key. Since the D-key is made consistent with its corresponding E-key, in essence the algorithm employs knowledge of both keys to decrypt the ciphertext back into unencrypted plaintext 697B. While the payload of IP packet 696 is secured in the form of an encrypted file, i.e. ciphertext, the rest of the IP packet is still unencrypted, sniffable, and readable by any cyber pirate including the source IP address “CP” and port and the destination IP address “NB” and associated port. So even if the payload itself can't be opened, the communication can be monitored.
(197) Virtual Private Networks—Another security method, also relying on encryption, is that of a “virtual private network” or VPN. In a VPN, a tunnel or secure pipe is formed in a network using encrypted IP packets. Rather than only encrypting the payload, in a VPN the entire IP packet is encrypted and then encapsulated into another unencrypted IP packet acting as a mule or carrier transmitting the encapsulated packet from one VPN gateway to another. Originally, VPNs were used to connect disparate local area networks together over a long distance, e.g. when companies operating private networks in New York, Los Angeles, and Tokyo wished to interconnect their various LANs with the same functionality as if they shared one global private network.
(198) The basic VPN concept can be envisioned as encrypted communication between two devices, for example where a first server, as part of one LAN supporting a number of devices wirelessly through RF and wireline connections is connected by a “virtual private network” or VPN comprising encrypted content traversing the VPN tunnel to a second server having wireline connections to desktops, notebooks, and to other WiFi base station. In addition to these relatively low bandwidth links, first server may also connects to a supercomputer via a high bandwidth connection. The resulting data communications comprises a sequence of data packets comprising an inner VPN packet embedded within an outer IP packet. In operation, an outer IP packet from server A, specifying a source IP address and source port # is sent to server B at destination IP address and destination port #. This outer IP packet established communications between the first and second servers to form an encrypted tunnel to one another for data to pass within. The VPN payload carried by the outer packet contains a last-mile IP packet, providing direct communication between a terminus device, e.g. a desktop with source IP address “DT” and its corresponding ad hoc port #, and another terminus device, e.g. a notebook with source IP address “NB” and its corresponding ad hoc port #. Although any communication session can be initiated, in one example a request for a file transfer is performed through the VPN tunnel.
(199) To establish this transfer securely using a virtual private network, the VPN tunnel is created and the session initiated before the actual communication is sent. In corporate applications, the VPN tunnel may not be carried over the Internet, but instead often is carried by a dedicated ISP or carrier owning their own fiber and hardware network. This carrier oftentimes enters into an annual or long-term contractual agreement with the company requiring VPN services to guarantee a specific amount of bandwidth for a given cost. Ideally, server-to-server communication occurs over a high-speed dedicated link connects directly with no intermediate or “last-mile” connections to disturb the VPN's performance, QoS, or security.
(200) In operation, traditional VPNs require a two-step process—one to create or “login” to the VPN, and a second step to transfer data within the secure pipe or tunnel. The concept of tunneling can be envisioned hierarchically as outer IP packets carried by 7-layer communication stacks (used for carrying the VPN connection) comprising Layers 1 through Layers 4, where Layer 5 is used to create a virtual VP session 723, and where Layer 6, the presentation layer, is used to facilitate encryption required to form a VPN gateway-to-gateway pipe between servers. While the VPN connection employs Internet Protocol to send the IP packets, the VPN's PHY Layer 1 and VPN data link Layer 2 is often supported by a dedicated carrier to minimize unpredictable routing over the Internet. Application Layer 7 data transferred as device-to-device communication between communicating desktops for example, is delivered as tunneled data including all seven OSI layers needed to establish communication as if the VPN were not present. In this manner the VPN may be envisioned as a communication protocol operating within Layer-7 used to carry VPN inner packets.
(201) In operation, outer IP packet once passed from one communication stack to another is opened to reveal encapsulated data, the true message of the packet. In this way, the end-to-end communication occurs ignorant of the details used to create the VPN tunnel, except that the VPN tunnel must be formed in advance of any attempt to communicate and must be closed after the conversation is terminated. Failure to open the VPN tunnel first will result in the unencrypted transmission of an IP packet susceptible to IP packet sniffing, hijacking, infection and more. Failure to close the VPN after a conversation is complete, may provide a cybercriminal the opportunity to hide their illegal activity within someone else's VPN tunnel, and if intercepted, may result in possible criminal charges levied against an innocent person.
(202) While VPNs are common ways for multiple private local area networks to interconnect to one another using private connections with dedicated capacity and bandwidth, the use of VPNs over public Networks and the Internet is problematic for two party communications. One issue with VPNs is the VPN connection must be established in advance, before it can be used, not on a packet-by-packet basis For example, in a VoIP call connected over a packet-switched network, before a cell phone can contact the intended call recipient at a second cell phone, it must first establish a VPN session. To do so, the caller's cell phone must first be loaded with VPN connection application. The caller then must send IP packets to VPN host, typically a service provider. These packets are carried through any available last-mile routing, e.g. radio communication from the cell phone to a nearby WiFi base station, followed by wireline communication to a local router, then by wireline communication to the VPN host. Once the session between the caller's cell phone and VPN host is established, the caller's cell phone must then instruct the VPN host to create a VPN tunnel from the caller's cell phone to the VPN host. This leg of the VPN tunnel is facilitated as a Layer 5 session with the tunnel encrypted by Layer 6.
(203) Once the VPN connection is set up, then the caller's cell phone may then place a call via any VoIP phone app to any other phone. If the phone being called is not connected to the same VPN, the application must establish a “call out” link over the last mile from the VPN host nearest to the destination cell phone, i.e. the person being called. If the VoIP application is unable or unauthorized to do so, the call will fail and immediately terminate. Otherwise, the inner IP packet will establish an application Layer 5 session between calling and destination cell phones confirming the IP test packets are properly decrypted and intelligible.
(204) To place a call the call necessarily comes from a Layer 7 application running on the caller's phone, i.e. a cell phone app using the carrier's data plan, and not from the phone's normal dialup functions, because the telephonic carrier's SIM card in the phone is not compatible with the VPN tunnel. Once the call is initiated, the caller's cell phone transmits a succession of IP packets representing small pieces or “snippets” of sound in accordance with its communication application. These packets are sent from the application in caller's cell phone through the network, e.g. through a WiFi link to a nearby WiFi base station then through a wireline connection to a router, and finally through wireline connection to the VPN host. The data is then sent securely to the VPN host through a VPN tunnel to the terminus device of the VPN network, the destination VPN gateway. In this example the VPN tunnel doesn't extend all the way to the destination cell phone, but instead stops short of device being called. Beyond the VPN's destination gateway, the data is no longer encrypted because the VPN carrier is no longer involved. For data packets leaving the VPN tunnel, VPN host forewords the data onward over the last mile connection of the destination device, e.g. a wireline connection to a nearby router, then by wireline connection to the local cell phone system and tower, transmitting the call as a normal cellular phone call using 2G, 3G or 4G telephony. The process of calling from a cell phone app to a phone not running the same app is called a “call out” feature.
(205) The foregoing example highlights another problem with connecting to a VPN over a public network—the last-mile link from the VPN host to the person being called are not part of the VPN, and therefore do not guarantee security, performance or call QoS. Specifically the caller's last mile comprising connections are all open to sniffing and subject to cyber-assaults. Once the call is completed and the caller's cell phone hangs up, the VPN link must be terminated whereby VPN Layer 5 coordinates closing the VPN session and the caller's cell phone disconnects from VPN host.
(206) The adaptation of the virtual private network, a technology originally created for computer-to-computer data transfers, suffers several major issues. Last mile communication from the destination VPN gateway to the destination cell phone is not secure and is at risk for sniffing and surveillance. The last mile communication between the caller's cell phone and the VPN gateway is secure only if the caller uses a data communication based app. If the caller connects to the VPN gateway using a telephonic link, i.e. a dial in feature, then last mile communications from a caller's cell phone to the nearest VPN gateway is not secure and is at risk for sniffing and surveillance. The call can only be secured end-to-end if both parties employs data communication and not telephony over their respect last mile links and provided that both parties know to join the same VPN prior to initiating the call.
(207) The last bullet point highlights the paradox of secure VPN communication—the person being called needs to know they are being called before they are called in order to join the network. To inform the person they are being to be called, they must first be contacted and instructed to log into the VPN before the call can commence. In essence they must receive an un-secured phone call to connect to a secure phone call. The unsecured phone call is easily hacked, sniffed, and surveilled. Moreover, the metadata of the unsecured call exposes who is calling who is being called, and what time the call occurs. Call metadata is extremely useful in tracking a person's activity or to profile them as a target for criminals.
(208) Even ignoring the security concerns, there is no guarantee that placing a call or sending documents through a VPN may not fail for any number of other reasons including: The VPN may not operate with sufficient low 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 sufficient low latency to support real-time applications, VoIP or video; The nearest VPN gateway to the caller or to the intended recipient, i.e. “the last mile” may be very far away, possibly even farther than the distance to the call recipient without the VPN, exposing the connection to excessive latency, network instability, uncontrolled routing through unknown networks, variable QoS, and numerous opportunities for man-in-middle attacks in the unprotected portion 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 support links to local telcos; Local carriers or government censors may block calls or connections into or out of known VPN gateways for reasons of national security or regulatory compliance; Using corporate VPNs, VoIP calls may limited to and from only company employees and specified authorized users, financial transactions and video streaming may be blocked, private email to public email servers such Yahoo, Google, etc. may be blocked, and numerous web sites such YouTube, chat programs, or Twitter may be blocked as per company policy. In cases of unstable networks, a VPN may get stuck open and retain a permanent session connected to a caller's device until manually reset by the VPN operator. This can lead to lost bandwidth for subsequent connections or expensive connection fees.
(209) Comparing Networks—Comparing communication offered by “over-the top” or OTT providers, to that of communication systems employing public networks to connect to an ad hoc VPN, quickly reveals that aside from the VPN link itself, the majority of both communication systems have nearly identical components and connections. Specifically, the last mile of the caller comprising a cell phone WiFi radio connection, WiFi base station, wireline connections, and router represent the same last-mile connectivity in both implementations. Similarly, on the last mile of the other party, the caller's cell phone, cell phone connection, cell base station and tower, wireline connections, and router are identical for both Internet and VPN versions. The main difference is that in a public network, the VPN tunnel offering secure communication between VPN hosts is replaced by server/routers carrying insecure communication throughout the cloud. Another difference is in OTT communications, the call is instantly available, and where using a VPN extra steps are required to set up the VPN and to terminate the VPN session prior to and following the call.
(210) In both examples, the last-mile connections offer unpredictable call QoS, exposure to packet sniffing, and the risk of cyber-assaults. Because server/routers carrying a call are likely managed by different ISPs in different locales, one can interpret the servers as existing different clouds. For example the publically open networks owned and operated by Google, Yahoo, Amazon, and Microsoft may be considered as different clouds, e.g. the “Amazon cloud” even though they are all interlinked by the Internet.
(211) A competing network but less popular topology, the peer-to-peer network or PPN, comprising a network made of a large number of peers with packet routing managed by the PPN and not by the router or ISP. While peer-to-peer networks existed in hardware for decades, it was Napster who popularized the concept as a means to avoid the control, costs, and regulation of Internet service providers. When sued by the U.S. government regulators for music copyright violations, the progenitors of Napster jumped ship, invading the early OTT carrier Skype. At that time, Skype's network converted from a traditional OTT into a Napster-like PPN.
(212) In PPN operation, every device that makes a login connection to the PPN becomes one more node in the PPN. For example if in one geography, a cell phone with PPN software installed logs into the peer-to-peer network, it like all the other connected devices in the region becomes part of the network. Calls placed by any devices hops around from one device to another to reach is destination, another PPN connected device. For example, if a caller's cell phone uses its PPN connection to call another PPN connected device, e.g. destination cell phone, the call follows a circuitous path through any device(s) physically located in the PPN between the two parties. For example, the call emanating from a caller's cell phone connects by WiFi through a local WiFi base station to a nearby desktop, then to another person's notebook, to a different desktop, onto another desktop, and finally to the destination cell phone through a local cell phone base station and tower. In this manner all routing was controlled by the PPN and the Internet was not involved in managing the routing. Since both parties utilize, the PPN software used to connect to the network also acts as the application for VoIP based voice communication.
(213) In the case where a cell phone attempts to call a non-PPN device cell phone on the opposite side of the world, the routing may necessarily include the Internet on some links, especially to send packets across oceans or mountain ranges. The first part of the routing in the local geography proceeds in a manner similar to the prior example, starting from the caller's cell phone and routed through a WiFi base station, desktop, notebook, more desktops, and so on. At this point, if the nearest notebook is connected to the network, the call will be routed through it, otherwise the call must be routed through a local cell phone base station and tower to the destination cell phone, and then back to cell phone base station and tower before sending it onwards.
(214) If the call is transpacific, then computers and cell phones cannot carry the traffic across the ocean so the call is then necessarily routed up to the Internet to 3.sup.rd party server/router in a hosted cloud and onward through connections to 3.sup.rd party server/routers in a different cloud. For example, as it approached its destination, the call then leaves the Internet and enters the PPN in the destination geography first through a desktop which in turn connects to WiFi, to a notebook, and to a base station. Since WiFi does not run the PPN app, the actual packet entering WiFi must travel to either a tablet or cell phone in the WiFi subnet and back to WiFi before being sent on to cell phone base station and tower via a wireline connection. Finally, the caller cell phone call connects to the destination cell phone, which is not a PPN enabled device. The connection thereby constitutes a “call out” for the PPN because it exits PPN network. Using this PPN approach, like a VPN, placing a call involves first registering a calling device to the PPN network by completing a PPN login. Thereafter, the call can be placed using the PPN app. The advantage of the PPN approach is little or no hardware is needed to carry a call over a long distance, and that since every device connected to the PPN regularly updates the PPN operator as to its status, loading and latency, the PPN operator can decide a packet's routing to best minimize delay.
(215) The disadvantages of such an approach is that packets traverse a network comprising many unknown nodes representing a potential security threat and having an unpredictable impact on call latency and call QoS. As such, except for Skype, peer-to-peer networks operating at Layer-3 and higher are not commonly employed in packet-switched communication networks.
(216) A comparative summary of ad hoc VPN providers, Internet OTT providers, and PPN peer networks is contrasted below.
(217) TABLE-US-00002 Network Virtual Private VPN Internet OTT Peer-to-Peer PPN Nodes Public/Hosted Servers Public Routers/Servers PPN Users Node Capability Known Infrastructure Known Infrastructure Mixed, Unknown Cloud Bandwidth Guaranteed Unpredictable Unpredictable Last-Mile Bandwidth Provider Dependent Provider Dependent PPN Dependent Latency Unmanageable Unmanageable Best Effort Network Stability Unmanageable Unmanageable, Redundant Best Effort Call Setup Complex Login None Required Login User Identity User Name Phone Number User Name VoIP QoS Variable to Good Variable Variable Cloud Security Encrypted Payload Only Unencrypted Unencrypted Last-Mile Security Unencrypted Unencrypted Unencrypted Sniffable Packet Header (Cloud) Entire Packet Entire Packet Entire Packet (Last Mile)
(218) As shown, while VPN and the Internet comprise fixed infrastructure, the nodes of a peer-to-peer network vary depending on who is logged in and what devices are connected to the PPN. The cloud bandwidth, defined in the context of this table as the networks' high-speed long-distance connections, e.g. networks crossing oceans and mountain ranges, is contractually guaranteed only in the case of VPNs, and is otherwise unpredictable. The last-mile bandwidth is local provider dependent for both Internet and VPN providers but for PPN is entirely dependent on who is logged in.
(219) Latency, the propagation delay of successively sent IP packets is unmanageable for OTTs and VPNs because the provider does not control routing in the last mile but instead depends on local telco or network providers, while PPNs have limited ability using best efforts to direct traffic among the nodes that happen to be online at the time in a particular geography. Likewise, for network stability, PPNs have the ability to reroute traffic to keep a network up but depend entirely on who is logged in. The Internet, on the other hand, is intrinsically redundant and almost certain to guarantee delivery but not necessarily in a timely manner. Network stability for an ad hoc VPN depends on the number of nodes authorized to connect to the VPN host. If these nodes go offline, the VPN is crippled.
(220) From a call setup point of view the Internet is always available, PPNs require the extra step of logging into the PPN prior to making a call, and VPNs can involve a complex login procedure. Moreover, most users consider OTT's use of phone numbers rather than separate login IDs used by VPNs and PPNs as a major beneficial feature in ease of use. All three networks listed suffer from variable VoIP QoS, generally lagging far behind commercial telephony carriers.
(221) From a security point of view, all three options are bad with the last mile completely exposed to packet sniffing with readable addresses and payloads. VPNs offer encryption of the cloud connection but still expose the IP addresses of the VPN hosts. As such no network option shown is considered secure. As such, encryption is used by various applications to try to prevent hacking and cyber-assaults, either as a Layer 6 protocol or as an embedded portion of the Layer 7 application itself.
(222) Overreliance on Encryption—Regardless of whether used for encrypting IP packets or establishing VPNs, today's network security relies almost solely on encryption and represents one weakness in modern packet-switched based communication networks. For example, numerous studies have been performed on methods to attack RSA encryption. While limiting the prime numbers to large sizes greatly reduces the risk of breaking the decryption D-key code using brute force methods, polynomial factor methods have been successfully demonstrated to crack keys based on smaller prime number-based keys. Concerns exist that the evolution of “quantum computing” will ultimately lead to practical methods of breaking RSA-based and other encryption keys in reasonable cyber-assault times.
(223) To combat the ever-present risk of code breaking, new algorithms and “bigger key” encryption methods such as the “advanced encryption standard” or AES cipher adopted by US NIST in 2001 have emerged. Based on the Rijndael cipher, the design principle known as a substitution-permutation network combines both character substitution and permutation using different key and block sizes. In its present incarnation, the algorithm comprises fixed block sizes of 128 bits with keys comprising varying lengths of 128 bits, 192 bits, and 256 bits, with the corresponding number of repetitions used in the input file transformation varying in rounds of 10, 12, and 14 cycles respectively. As a practical matter, AES cipher may be efficiently and rapidly executed in either software or hardware for any size of key. In cryptography vernacular, an AES based encryption using a 256b key is referred to as AES256 encryption. AES512 encryption employing a 512b key is also available.
(224) While each new generation raises the bar in cryptography to make better encryption methods and to more quickly break them, profit-minded cybercriminals often concentrate on their targets rather than simply using computing to break an encrypted file. As described previously, using packet sniffing and port interrogation, a cyber pirate can gain valuable information about a conversation, a corporate server, or even a VPN gateway. By cyber-profiling, it may be easier to launch a cyber-assault on a company's CFO or CEO's personal computers, notebooks, and cell phones rather than attack the network itself. Sending emails to employees that automatically install malware and spyware upon opening an embedded link completely circumvent firewall security because they enter the network from “inside” where employees necessarily must connect and work.
(225) The chance of breaking encryption also improves if data moves through a network without changing, i.e. statically. In the network of
(226) In either case, throughout this disclosure, each data slot represented by fixed size boxes comprises a prescribed number of bits, e.g. two bytes (2B) long. The exact number of bits per slot is flexible just so long as every communication node in a network knows what the size of each data slot is. Contained within each data slot is audio, video, or textual data, identified in the drawings as a number followed by a letter. For example, as shown, the first slot of data packet 790 contains the content 1A where the number “1” indicates the specific communication #1 and the letter “A” represents the first piece of the data in communication #1. Similarly, the second slot of data packet 790 contains the content 1B where the number “1” indicates it is part of the same communication #1 and the letter “B” represents the second piece of the data in communication #1, sequentially following 1A.
(227) If, for example, the same data packet hypothetically included content “2A” the data represents the first packet “A” in a different communication, specifically for communication #2, unrelated to communication #1. Data packets containing homogeneous communications, e.g. where all the data is for communication #1 are easier to analyze and read than those mixing different communications. Data arranged sequentially in proper order makes it easy for a cyber-attacker to interpret the nature of the data, whether it is audio, text, graphics, photos, video, executable code, etc.
(228) Moreover, in the example shown, since the packet's source and destination IP addresses remain constant, i.e. where the packets remain unchanged during transport through the network in the same form as the data entering or exiting gateway servers 21A and 21F, because the underlying data doesn't change, a hacker has more chances to intercept the data packets and a better chance to analyze and open the files or listen to the conversation. The simple transport and one-dimensional security, i.e. relying only on encryption for protection, increases the risk of a cyber-attack because the likelihood of success is higher in such overly simplified use of the Internet as a packet-switched network.
(229) Securing Real-Time Networks and Connected Devices
(230) In order to improve the quality of service (QoS) of telephonic, video, and data communication while addressing the plethora of security vulnerabilities plaguing today's packet-switched networks, a new and innovative systemic approach to controlling IP packet routing is required, one that manages a global network comprising disparate technologies and concurrently facilitates end-to-end security. The goals of such an inventive packet-switched network include the following criteria: 1. Insure the security and QoS of a global network or long-distance carrier including dynamically managing real-time voice, video, and data traffic routing throughout a network; 2. Insure the security and QoS of the “local network or telco” in the last mile of the communication network; 3. Insure the security and QoS of the “last link” of the communication network, including providing secure communication over unsecured lines; 4. Insure the security of communicating devices and authenticate users to prevent unauthorized or fraudulent access or use; 5. Facilitate a secure means to store data in a device or online in network or cloud storage to prevent unauthorized access; 6. Provide security and privacy protection of all non-public personal information including all financial, personal, medical, and biometric data and records; 7. Provide security and privacy protection of all financial transactions involving online banking and shopping, credit cards, and e-pay; and 8. Provide security, privacy, and as-required, anonymity, in transactional and information exchange involving machine-to-machine (M2M), vehicle-to-vehicle (V2V), and vehicle-to-infrastructure (V2X) communication.
(231) Of the above stated goals, the inventive matter contained within this disclosure relates to the second topic described in item #2, i.e. to “the security and QoS of the local network or telco in the last mile of the communication network” This topic can be considered as secure last mile connectivity without sacrificing real-time communication performance.
(232) Glossary
(233) Unless the context requires otherwise, the terms used in the description of the Secure Dynamic Communication Network And Protocol have the following meanings:
(234) Anonymous Data Packets: Data packets lacking information as to their original origin or final destination.
(235) Client or Client Device: A device, typically a cell phone, tablet, notebook, desktop, or IoT device connected to an SDNP Cloud over a Last Mile.
(236) Concealment: The encoding process by which the contents of a SDNP packet or portions thereof are rendered unrecognizable using any sequential combination of security operation such as scrambling, splitting, junk data insertions, and encryption. Recovery of concealed data requires execution of the anti-function or decoding processes in reverse order, e.g. decryption, junk data removal, mixing and unscrambling.
(237) Decryption: A mathematical operation used to convert data packets from ciphertext into plaintext.
(238) Disaggregated Data Storage: The process of fragmenting data files and concealing their content before storing the various fragmented files on different data storage nodes.
(239) DMZ Server: A computer server not accessible directly from the SDNP network or the Internet used for storing selectors, seed generators, key generators and other shared secrets. A DMZ may also be referred to as an “air gapped” server, i.e. a computer with no wired network connection or access.
(240) Dynamic Encryption/Decryption: Encryption and decryption relying on keys that change dynamically as a data packet traverses the SDNP network.
(241) Dynamic Mixing: The process of mixing where the mixing algorithms (the inverse of splitting algorithms) change dynamically as a function of a seed based on a state, such as the time, state, and zone when a mixed data packet is created.
(242) Dynamic Scrambling/Unscrambling: Scrambling and unscrambling relying on algorithms that change dynamically as a function of a state, such as the time when a data packet is created or the zone in which it is created.
(243) Dynamic Splitting: The process of splitting where the splitting algorithms change dynamically as a function of a seed based on a state, such as the time, state, and zone when a data packet is split into multiple sub-packets.
(244) Encryption: A mathematical operation used to convert data packets from plaintext into ciphertext.
(245) Fragmented Data Transport: The routing of split and mixed data through the SDNP network.
(246) Junk Data Deletions (or “De-junking”): The removal of junk data from data packets in order to restore the original data or to recover the data packet's original length.
(247) Junk Data Insertions (or “Junking”): The intentional introduction of meaningless data into a data packet, either for purposes of obfuscating the real data content or for managing the length of a data packet.
(248) Key: A disguised digital value that is generated by inputting a state, such as time, into a key generator which uses a secret algorithm to generate the key. A key is used to select an algorithm for encrypting or decrypting the data in a packet from a selector. A key can be used to safely pass information regarding a state over public or unsecure lines.
(249) Key Exchange Server: A computer server, often third party hosted and independent of the SDNP network operator, used to distribute public encryption keys to clients, and optionally to servers using symmetric key encryption, especially for client-administered key management, i.e. client based end-to-end encryption to prevent any possibility of network operator spying.
(250) Last Link: The network connection between a Client's device and the first device in the network with which it communicates, typically a radio tower, a WiFi router, a cable modem, a set top box, or an Ethernet connection. In the case of Ethernet communication, the Last Link comprises a physical “tethered” (i.e. wired) connection to a cable modem or optical fiber modem. For WiFi connectivity (e.g. in a cafê), the Last Link comprises a WiFi router connected to a DSL, cable, or fiber network. In a cellular network, the Last Link comprises the radio link between the cellular tower and the mobile phone, which may comprise, for example a 3G or 4G/LTE connection.
(251) Last Mile: The network connection between a Client and a gateway media node in an SDNP or other type of network or cloud, including the Last Link. The Last Mile typically comprises communication over networks owned and operated by local telco's and cable companies, e.g. Comcast cable, Verizon cellular, Korean Telecom, British Telecom, etc.
(252) Mixing: The combining of data packets from different sources, which may include different data types, to produce one longer data packet (or a series of smaller sub-packets) having unrecognizable content. In some cases previously split data packets are mixed to recover the original data content. The mixing operation may also include junk data insertions and deletions and parsing.
(253) Multiple PHY or Multi-PHY: Communication involving alternating transport of related sequential data packets over multiple physical mediums, e.g. optical fiber and 4G, different WiFi channels and frequencies, 4G and WiFi, Ethernet WiFi, etc.
(254) Parsing: A numerical operation whereby a data packet is broken into shorter sub-packets for storage or for transmission.
(255) Router: A device that directs the routing of a datagram to the destination address specified in its IP header. For packet routing outside of the SDNP network, the IP address employed may represent a valid Internet IP address (one recognized by a DNS server) or may represent the NAT address assigned by a network address translator operated by the local network provider (e.g. Comcast assigns its own internal IP addresses for communication within the Comcast cable/fiber network).
(256) Scrambling: An operation wherein the order or sequence of data segments in a data packet is changed from its natural order into an unrecognizable form.
(257) Splitting: An operation wherein a data packet (or a sequence of serial data packets) is split into multiple sub-packets, which are routed to multiple destinations. A splitting operation may also include junk data insertions and deletions.
(258) SoftSwitch: Software comprising executable code performing the function of a telecommunication switch and router.
(259) SDNP: An acronym for “Secure Dynamic Communication Network and Protocol” meaning a hyper-secure communications network made in accordance with this invention.
(260) SDNP Address: An address used for routing SDNP packets through the SDNP cloud or over the Last Mile comprising the ad hoc IP address of the next destination device, i.e. only enough information to execute a single hop.
(261) SDNP Administration Server: A computer server used to distribute executable code and shared secrets to SDNP servers globally or in specific zones.
(262) SDNP Bridge Node: A SDNP node connecting one SDNP Zone or Cloud to another SDNP Zone or Cloud having dissimilar security credentials.
(263) SDNP Client or Client Device: A network connected device, typically a cell phone, tablet, notebook, desktop, or IoT device running a SDNP application in order to connect to an SDNP Cloud, generally connecting over a Last Mile.
(264) SDNP Cloud: A network of interconnected SDNP Servers running SoftSwitch executable code to perform SDNP Communications Node operations.
(265) SDNP Gateway Node: A media node connecting an SDNP Cloud to a Client Device via a Last Mile. SDNP Gateway nodes require access to at least two Zones—that of the SDNP Cloud and of the Last Mile.
(266) SDNP Media Node: SoftSwitch executable code that processes incoming data packets with particular identifying tags in accordance with instructions from the signaling server or another computer performing the signaling function, including encryption/decryption, scrambling/unscrambling, mixing/splitting, tagging and SDNP header and sub-header generation. An SDNP Media Node is responsible for identifying incoming data packets having specific tags and for forwarding newly generated data packets to their next destination.
(267) SDNP Media Server: A computer server hosting a SoftSwitch performing the functions of a SDNP Media Node in dual-channel and tri-channel communications and also performing the tasks of a SDNP Signaling Node and a SDNP Name-Server Node in single-channel communications.
(268) SDNP Name Server: A computer server hosting a SoftSwitch performing the functions of a SDNP Name-Server Node in tri-channel communications.
(269) SDNP Name Server Node: SoftSwitch executable code that manages a dynamic list of every SDNP device connected to the SDNP cloud.
(270) SDNP Network: The entire hyper-secure communication network extending from client-to-client including last link and last mile communication, as well as the SDNP cloud.
(271) SDNP Node: A SDNP communication node comprising a software-based “SoftSwitch” running on a computer server or alternatively a hardware device connected to the SDNP network, functioning as an SDNP node, either as Media Node, a Signaling Node, or a Name Server Node.
(272) SDNP Server: A computer server comprising either a SDNP Media Server, a SDNP Signaling Server, or a SDNP Name Server and hosting the applicable SoftSwitch functions to operate as an SDNP node.
(273) SDNP Signaling Node: SoftSwitch executable code that initiates a call or communication between or among parties, determines all or portions of the multiple routes for fragmented data transport based on caller criteria and a dynamic table of node-to-node propagation delays, and instructing the SDNP media how to manage the incoming and outgoing data packets.
(274) SDNP Signaling or Signal Server: A computer server hosting a SoftSwitch performing the functions of a SDNP Signaling Node in dual-channel and tri-channel SDNP communications, and also performing the duties of the SDNP Name-Sever Node in dual-channel communications.
(275) SDNP Tag: A source address, SDNP zip code, or any other code used to identify an incoming data packet or a sub-packet thereof.
(276) Security Operation: The process of modifying a data packet to perform concealment (or to recover the content of a concealed packet) using the state-dependent security credentials related to the zone and state of the where the packet is created.
(277) Security Settings or Security Credentials: Digital values, such as seeds and keys, that are generated by seed generators or key generators using secret algorithms in conjunction with a constantly changing input state, such as network time, and that can therefore be safety transmitted over public or insecure lines.
(278) Seed: A disguised digital value that is generated by inputting a state, such as time, into a seed generator, which uses a secret algorithm to generate the seed. A seed is used to select an algorithm for scrambling, encrypting or splitting the data in a packet from a selector. A seed can be used to safely pass information regarding a state over public or unsecure lines.
(279) Selector: A list or table of possible scrambling, encryption or splitting algorithms that are part of the shared secrets and that are used in conjunction with a seed or key to select a particular algorithm for scrambling, unscrambling, encrypting, decrypting, splitting or mixing a packet or packets.
(280) Shared Secrets: Confidential information regarding SDNP node operation, including tables or selectors of scrambling/unscrambling, encryption/decryption, and mixing/splitting algorithms, as well as the algorithms used by seed generators, key generators, zone information, and algorithm shuffling processes stored locally on DMZ servers not accessible over the SDNP network or the Internet.
(281) Single PHY: Communication of related data packets transported over a single physical medium, e.g. exclusively over optical fiber, or Ethernet, or WiFi, or a cellular network.
(282) State: An input, such as location, zone, or network time that is used to dynamically generate security settings such as seeds or keys or to select algorithms for specific SDNP operations such as mixing, splitting, scrambling, and encryption.
(283) Time: The universal network time used to synchronize communication across the SDNP network
(284) Unscrambling: A process used to restore the data segments in a scrambled data packet to their original order or sequence. Unscrambling is the inverse function of scrambling.
(285) Zone: A network of specific interconnected servers sharing common security credentials and shared secrets. Last mile connections comprise separate zones from those in an SDNP Cloud.
(286) Secure Dynamic Communication Network And Protocol (SDNP) Design
(287) To prevent cyber-assaults and hacking of packet-switched communication while minimizing real-time packet latency, insuring stable call connectivity, and delivering the highest integrity of voice communication and video streaming, the disclosed secure dynamic communication network and protocol, or SDNP, is designed based upon a number of guiding principles including: Real-time communication should always occur using the lowest latency path. Unauthorized inspection or sniffing of a data packet should provide no context as to where the packet came from, where it is going, or what is in it. Data packet payloads should be dynamically re-encrypted, i.e., decrypted and then encrypted again using a different encryption algorithm, with no risk of being hacked in any reasonable time. Even after they have been decrypted, data packet payloads may still contain incomprehensible payloads comprising a dynamically scrambled mix of multiple conversations and unrelated data mixed with junk packet fillers.
(288) Implementation of the above guidelines involves a variety of unique methods, functions, features and implementations including in various embodiments some or all of the following The SDNP employs one or more dedicated clouds comprising telco, i.e. telecommunication system, soft-switch functions realized using proprietary command and control software not accessible through the Internet. All intra-cloud communication occurs using dedicated SDNP packet routing within proprietary clouds based on SDNP addresses and dynamic ports (i.e. proprietary NAT addresses), not on DNS recognized IP addresses. SDNP addresses are not usable or routable over the Internet or outside the SDNP cloud. The SDNP network constantly identifies and dynamically routes all real-time communication through the lowest latency paths available. No secure or real-time communication is routed outside the SDNP cloud or over the Internet except in cloud-to-cloud and last-mile communication, and then generally using single-hop routing with invisible addresses. Routing data contained within a data packet identifies the routing for a single hop between two adjacent devices, identifying only the last and next server's SDNP or IP addresses The phone number or IP addresses of the caller and the call recipient, i.e. the clients' respective source and destination addresses, are not present in the IP packet headers nor are they present in the encrypted payload Command and control related shared secrets exist in system software installed in secure DMZ servers not accessible through the Internet. SDNP packet communication may occur through three independent channels—a “name server” used to identify elements within the SDNP cloud, “media servers” used for routing content and data, and “signaling servers” used for packet and call command and control. Routing information, along with keys and numeric seeds (as needed) may be supplied to all participating media servers through an independent signaling channel prior to the call or communiqué and not with content. The signaling server supplies the media servers with only the last and next destination of a packet traversing the network. Media packets contain fragmented data representing only a portion of a call, document, text or file, dynamically mixed and remixed with other packets containing fragmented data from other sources and of different types. Special security methods are employed to protect the first- and last-mile communication, including separating signaling server-related communications from media and content-related packets. Packet transport is content-type dependent, with voice and real-time video or streaming based on an enhanced UDP, while signaling packets, command-and-control packets, data files, application files, systems files, and other files which are sensitive to packet loss or latency utilize TCP transport. Special security and authentication methods are used to confirm that a 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 imposter.
(289) To ensure secure communication with low latency and high QoS in VoIP and real-time applications, the disclosed “secure dynamic communication network and protocol” or SDNP, utilizes an inventive “dynamic mesh” network comprising Dynamic adaptive multipath and meshed routing with minimal latency Dynamic packet scrambling Dynamic fragmentation using packet splitting, mixing, parsing, and junk bit packet fillers Dynamic intra-node payload encryption throughout a network or cloud Dynamic network protocol with address disguising and need-to-know routing information Multichannel communication separating media and content from signaling, command and control, and network addresses Dynamic adaptive real-time transport protocol with data type specific features and contextual routing Support of client-encrypted payloads with user-key management Lightweight audio CODEC for high QoS in congested networks
(290) As described, SDNP communication relies on multi-route and meshed communication to dynamically route data packets. Contrasting single-path packet communication used for Internet OTT and VoIP communications, in SDNP communication in accordance with this invention, the content of data packets is not carried serially by coherent packets containing information from a common source or caller, but in fragmented form, dynamically mixing and remixing content emanating from multiple sources and callers, where said data agglomerates incomplete snippets of data, content, voice, video and files of dissimilar data types with junk data fillers. The advantage of the disclosed realization of data fragmentation and transport is that even unencrypted and unscrambled data packets are nearly impossible to interpret because they represent the combination of unrelated data and data types.
(291) By combining fragmented packet mixing and splitting with packet scrambling and dynamic encryption, these hybridized packets of dynamically encrypted, scrambled, fragmented data comprise meaningless packets of gibberish, completely unintelligible to any party or observer lacking the shared secrets, keys, numeric seeds, and time and state variables used to create, packet, and dynamically re-packet the data.
(292) Moreover, each packet's fragmented content, and the secrets used to create it, remain valid for only a fraction of a second before the packet is reconstituted with new fragments and new security provisions such as revised seeds, keys, algorithms, and secrets. The limited duration in which a cyber-pirate has available to break and open the state-dependent SDNP data packet further enhances SDNP security, requiring tens of thousands of compute years to be processed in one tenth of a second, a challenge twelve orders of magnitudes greater than the time available to break it.
(293) The combination of the aforementioned methods facilitates multi-dimensional security far beyond the security obtainable from static encryption. As such, the disclosed secure dynamic communication network and protocol is referred to herein as a “HyperSecure” network.
(294) Data Packet Scrambling—In accordance with the disclosed invention, secure communication over a packet-switched network relies on several elements to prevent hacking and ensure security, one of which involves SDNP packet scrambling. SDNP packet scrambling involves rearranging the data segments out of sequence, rendering the information incomprehensible and useless. As shown in
(295) The unscrambling operation, shown in
(296) Should the scrambling algorithm selected for implementing unscrambling operation 927 not match the original algorithm employed in packet scrambling, or should seed 929 or state or time 920 not match the time scrambling occurred, then the unscrambling operation will fail to recover the original unscrambled data packet 923, and the packet data will be lost. In data flow diagrams, it is convenient to illustrate this packet unscrambling process and sequence using a schematic or symbolic representation, as depicted herein by symbol 928.
(297) In accordance with the disclosed invention, numerous algorithms may be used to perform the scrambling operation so long that the process in reversible, meaning repeating the steps in the opposite order as the original process returns each data segment to its original and proper location in a given data packet. Mathematically, acceptable scrambling algorithms are those that are reversible, i.e. where a function F(A) has an anti-function F.sup.−1(A) or alternatively a transform has a corresponding anti-function such that
F.sup.−1[F(A)]=A
(298) meaning that a data file, sequence, character string, file or vector A processed by a function F will upon subsequent processing using the anti-function F.sup.−1 return the original input A undamaged in value or sequence.
(299) Examples of such reversible functions are illustrated by the static scrambling algorithms shown in
(300) In mod-3 mirroring, the first and third data segments of every three data segments are swapped while the middle packet of each triplet remains in its original position. Accordingly, data segments 1A and 1C are swapped while 1B remains in the center of the triplet, data segments 1D and 1F are swapped while 1E remains in the center of the triplet, and so on, to produce scrambled data packet output 936. In mod-3 mirroring, the line of symmetry is centered in the 2.sup.nd, 5.sup.th, 8.sup.th, . . . , (2+3n).sup.th position.
(301) In mod-4 mirroring, the first and fourth data segments and the second and third of every four data segments are swapped, and so on to produce scrambled output data packet 937 from input data packet 931. Accordingly, data segment 1A is swapped with 1D; data segment 1B is swapped with 1C; and so on. In mod-4 mirroring, the line of symmetry is centered between the second and third data segments of every quadruplet, e.g. between the 2.sup.nd and 3.sup.rd data segments, the 6.sup.th and 7.sup.th data segments, and so on, or mathematically as 2.5.sup.th, 6.5.sup.th, . . . , (2.5+4n).sup.th position. In mod-m mirroring, the m.sup.th data segment of input data packet 932 is swapped with the first, i.e. the 0.sup.th data segment; the 0.sup.th data segment is swapped with the m.sup.th element; and similarly the n.sup.th element is swapped with the (m-n).sup.th data segment to produce scrambled output data packet 938.
(302) Another scrambling method also shown in
(303) In a 2-frame phase shift, the first data segment 1A of input data packet 930 is shifted by two frames into the position previously occupied by data segment 1C, the 4.sup.th frame 1D is shifted into the last position of scrambled output data packet 941, the next to the last data segment 1E is shifted into the first position and the last position 1F is shifted into the second position. Similarly, in a 4-frame phase shift, the data segments of input data data packet 930 are shifted by four places with first frame 1A replacing the frame previously held by 1E, 1B replacing 1F, 1C replacing 1A, and so on, to produce scrambled output data packet 942. In the case of the maximum phase shift, the first frame replaces the last, the second frame originally held by 1B becomes the first frame of output data packet 943, the second element is shifted into the first position, the third position into the second place, and so on. Phase-shifting one frame beyond the maximum phase shift results in output data unchanged from the input. The examples shown comprise phase-shifts where the data was shifted to the right. The algorithm also works for phase shifts-to the left but with different results.
(304) The aforementioned algorithms and similar methods as disclosed are referred herein to as static scrambling algorithms because the scrambling operation occurs at a single time, converting an input data set to a unique output. Moreover, the algorithms shown previously do not rely of the value of a data packet to determine how the scrambling shall occur. As illustrated in
(305) In the example shown, unscrambled data packet 930 is converted parametrically in step 950 into a data table 951, containing a numeric value for each data segment. As shown data segment 1A, the 0.sup.th frame, has a numeric value of 23, data segment 1B, the 1.sup.st frame, has a numeric value of 125, and so on. A single data packet value is then extracted in step 952 for the entire data packet 930. In the example shown, sum 953 represents the linear summation of all the data segment values from table 951, parametrically totaling 1002. In step 954 this parametric value, i.e. sum 953, is compared against a condition table, i.e. in software a set of predefined if-then-else statements, to compare sum 953 against a number of non-overlapping numerical ranges in table 955 to determine which sort routine should be employed. In this example, the parametric value of 1002 falls in the range of 1000 to 1499, meaning that sort # C should be employed. Once the sort routine is selected, the parametric value is then no longer required. The unscrambled data input 930 is then scrambled by the selected method in step 956 to produce the scramble data packet output 959. In the example shown, Sort # C, summarized in table 957, comprises a set of relative moves for each data segment. The first data segment of scrambled data packet 959, the 0.sup.th frame is determined by moving the 1D data segment to the left by three moves, i.e. a 3 shift. The 1.sup.st frame comprises data segment 1B, unchanged from its original position, i.e. a move of 0 places. The 2.sup.nd frame comprises 1E, a data segment shifted left by two moves from its original position. The same is true for the 3.sup.rd frame comprising data segment 1F shifted left by two moves from its original position. The 4.sup.th frame of scrambled data packet output 959 comprises data segment 1C shifted right, i.e. +2 moves, from its original position. The 5.sup.th frame comprises data segment 1A, shifted five moves to the right, i.e. +5, from its original position.
(306) In this manner, summarized in table 957 for sort # C, every data segment is moved uniquely to a new position to create a parametrically determined scrambled data packet 959. To unscramble the scrambled data packet, the process is reversed, using the same sort method, sort # C. In order to insure that the same algorithm is selected to perform the unscrambling operation, the parametric value 953 of the data packet cannot be changed as a consequence of the scrambling operation. For example, using a linear summation of the parametric value of every data segment produces the same numerical value regardless of the order of the numbers.
(307) Dynamic scrambling utilizes a system state, e.g. time, to be able to identify the conditions when a data packet was scrambled, enabling the same method to be selected to perform the unscrambling operation. In the system shown in
(308) The benefit of using a hidden number to select a scrambling algorithm instead of just a numeric seed, is it eliminates any possibility of a cybercriminal recreating the scrambling table by analyzing the data stream, i.e. statistically correlating repeated sets of scrambled data to corresponding numeric seeds. Although the seed may be visible in the data stream and therefore subject to spying, the hidden number generator and the hidden number HN it creates is based on a shared secret. The hidden number HN is therefore not present in the data stream or subject to spying or sniffing, meaning it is not transmitted across the network but generated locally from the numeric seed. This mathematical operation of a hidden number generator thereby confers an added layer of security in thwarting hackers because the purpose of the numeric seed is disguised.
(309) Once the algorithm is selected, the numeric seed may also be used as an input variable in the algorithm of scrambling process 963. Dual use of the numeric seed further confounds analysis because the seed does not directly choose the algorithm but works in conjunction with it to determine the final sequence of the scrambled data segments. In a similar manner, to unscramble a dynamically scrambled data packet, seed 929 (or alternatively the state or time 920) must be passed from the communication node, device or software initially performing the scrambling to any node or device wishing to unscramble it.
(310) In accordance with the disclosed invention, the algorithm of seed generation 921, hidden number generator 960, and the list of scrambling algorithms 962 represent “shared secrets,” information stored in a DMZ server (as described below) and not known to either the sender or the recipient of a data packet. The shared secret is established in advance and is unrelated to the communication data packets being sent, possibly during installation of the code where a variety of authentication procedures are employed to insure the secret does not leak. As described below, shared secrets may be limited to “zones” so that knowledge of one set of stolen secrets still does not enable a hacker to access the entire communication network or to intercept real-time communiqués.
(311) In addition to any shared secrets, in dynamic scrambling, where the scrambling algorithm varies during data packet transit, a seed based on a “state” is required to scramble or unscramble the data. This state on which the seed is based may comprise any physical parameter such as time, communication node number, network identity, or even GPS location, so long as there is no ambiguity as to the state used in generating the seed and so long as there is some means to inform the next node what state was used to last scramble the data packet. The algorithm used by the seed generator to produce a seed is part of the shared secrets, and hence knowledge of the seed does not allow one to determine the state on which the seed is based. The seed may be passed from one communication node to the next by embedding it within the data packet itself, by sending it through another channel or path, or some combination thereof. For example, the state used in generating a seed may comprise a random number generated by a counter and subsequently incremented by a fixed number each time a data packet traverses a communication node, with each count representing a specific scrambling algorithm.
(312) In one embodiment of dynamic scrambling, during the first instance of scrambling a random number is generated to select the scrambling method used. This random number is embedded in the data packet in a header or portion of the data packet reserved for command and control and not subject to scrambling. When the data packet arrives at the next node, the embedded number is read by the communication node and used by the software to select the proper algorithm to unscramble the incoming data packet. The number, i.e. the “count” is next incremented by one count or some other predetermined integer, the packet is scrambled according to the algorithm associated with this new number, and the new count is stored in the data packet output overwriting the previous number. The next communication node repeats the process.
(313) In an alternative 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 number is forwarded to every communication node used to transport the specific data packet as a “shared secret”. A count, e.g. starting with 0, is also embedded in the data packet in a header or portion of the data packet reserved for command and control and not subject to scrambling. The data packet is then forwarded to the next communication node. When the packet arrives at the next communication node, the server reads the value of the count, adds the count to the initial random number, identifies the scrambling algorithm used to last scramble the data packet and unscrambles the packet accordingly. The count is then incremented by one or any predetermined integer, and the count is again stored in the data packet's header or any portion of the data packet reserved for command and control and not subject to scrambling, overwriting the prior count. The random number serving as a shared secret is not communicated in the communication data packet. When the data packet arrives at the next communication node, the server then adds the random number shared secret added to the revised counter value extracted from the data packet. This new number uniquely identifies the scrambling algorithm employed by the last communication node to scramble the incoming packet. In this method, only a meaningless count number can be intercepted from the unscrambled portion of a data packet by a cyber-pirate, who has no idea what the data means.
(314) In another alternative method, a hidden number may be employed to communicate the state of the packet and what algorithm was employed to scramble it. A hidden number combines a time-varying state or a seed, with a shared secret generally comprising a numeric algorithm, together used to produce a confidential number, i.e. a “hidden number” that is never communicated between communication nodes and is therefore not sniffable or discoverable to any man-in-the middle attack or cyber-pirate. The hidden number is then used to select the scrambling algorithm employed. Since the state or seed is meaningless without knowing the algorithm used to calculate the hidden number and because the shared-secret algorithm can be stored behind a firewall inaccessible over the network or Internet, then no amount of monitoring of network traffic will reveal a pattern. To further complicate matters, the location of the seed can also represent a shared secret. In one embodiment, a number carried by an unscrambled portion of a data packet and observable to data sniffing, e.g. 27482567822552213, comprises a long number where only a portion of the number represents the seed. If for example, the third through eighth digits represent the seed, then the real seed is not the entire number but only the bolded numbers 27482567822552213, i.e. the seed is 48256. This seed is then combined with a shared secret algorithm to generate a hidden number, and the hidden number is used to select the scrambling algorithm, varying dynamically throughout a network.
(315) The application of scrambling of data packets in a SDNP network is described in U.S. application Ser. No. 14/803,869, filed Jul. 20, 2015, entitled “Secure Dynamic Communication Network and Protocol”. The application of data packet scrambling in Last Mile communication will be described in further detail in this disclosure.
(316) As described, the data traversing the network, albeit scrambled, can be referred to as “plaintext” because the actual data is present in the data packets, i.e. the packets have not been encrypted into ciphertext. By contrast, in ciphertext the character string comprising the original data, whether scrambled or not, is translated into a meaningless series of nonsense characters using an encryption key, and cannot be restored to its original plaintext form without a decryption key. The role of encryption in the disclosed SDNP based communication is discussed further in the following section on “Encryption.”
(317) In order to change the sequence of data packets during transport through the network, packet “re-scrambling” is required, as shown in
(318) In accordance with the disclosed invention, the static and dynamic scrambling of data renders interpretation of the unscrambled data meaningless, reordering sound into unrecognizable noise, reordering text into gibberish, reordering video into video snow, and scrambling code beyond repair. By itself, scrambling provides a great degree of security. In the SDNP method disclosed herein, however, scrambling is only one element utilized to provide and insure secure communication free from hacking, cyber-assaults, cyber-piracy, and man-in-the-middle attacks.
(319) Packet Encryption—In accordance with the disclosed invention, secure communication over a packet-switched network relies on several elements to prevent hacking and ensure security, one of which involves SDNP encryption. As described previously, encryption from the Greek meaning “to hide, to conceal, to obscure” represents a means to convert normal information or data, commonly called “plaintext”, into “ciphertext” comprising an incomprehensible format rendering the data unreadable without secret knowledge. In modern communication, this secret knowledge generally involves sharing one or more “keys” used for encrypting and decrypting the data. The keys generally comprise pseudo-random numbers generated algorithmically. Numerous articles and texts are available today discussing the merits and weaknesses of various encryption techniques such as “Cryptonomicon” by Neal Stephenson© 1999, “The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography” by Simon Singh© 1999, “Practical Cryptography” by Niels Ferguson© 2013, and “Cryptanalysis: A Study of Ciphers and Their Solution” first published in 1939.
(320) While the concept of encryption or ciphers is ancient and well known to those skilled in the art, the application of cryptography in the disclosed secure dynamic communication network and protocol is unique, facilitating both end-to-end encryption and single-hop node-to-node dynamic encryption to the network architecture itself, independent of any client's own encryption. SDNP communication is architected with the basic precept that given sufficient time, any static encrypted file or message can eventually be broken and its information stolen, no matter how sophisticated the cipher. While this supposition may in fact be incorrect, there is no need to prove or disprove the proposition because the converse, i.e. waiting till a specific encryption method fails, may result in unacceptable and irreversible consequential damage.
(321) Instead, SDNP communication is based on the premise that all encrypted files have a limited “shelf life”, metaphorically meaning that encrypted data is good (secure) for only a finite period of time and that the confidential data must be re-encrypted dynamically at regular intervals, ideally far more frequently than the best estimates of the time required to crack its encryption with state-of-the-art computers. For example, if it is estimated by cryptologists that a large server farm of crypto-engines can break a given cipher in one year, then in SDNP communication a data packet will be re-encrypted every second or even every 100 ms, intervals many orders of magnitude shorter than the best technology's capability to crack it. As such, SDNP encryption is necessarily dynamic, i.e. time variant, and may also be spatially variant, i.e. depending on a communication node's location in a packet-switched network or geography. Thus, as used herein, the terms “re-encrypting” or “re-encryption” refer to decrypting a data packet and then encrypting it again, typically with a different encryption algorithm or method.
(322) SDNP encryption therefore involves converting data from unencrypted plaintext into ciphertext repeatedly and frequently, rendering the information incomprehensible and useless. Even if a given packet's data encryption is miraculously broken, by employing SDNP's dynamic encryption methods, the next data packet utilizes a completely different encryption key or cipher and requires a completely new effort to crack its encryption. By limiting the total content of each uniquely encrypted data packet, the potential damage of unauthorized access is mitigated because an exposed data packet contains, by itself, a data file too small to be meaningful or useful by a cyber-pirate. Moreover, by combining dynamic encryption with the aforementioned SDNP scrambling methods, communication security is enhanced tremendously. Even in its unencrypted form, the intercepted data file contains only a small snippet of data, voice, or video scrambled into a meaningless and incomprehensible sequence of data segments.
(323) To avoid the shelf life security concerns, SDNP encryption is dynamic and state-dependent. As shown in
(324) Encryption operation 1020 can use any algorithm, cryptographic, or cipher method available. While the algorithm may represent a static equation, in a one embodiment the encryption operation uses dynamic variables or “states” such as time 920 when encryption occurs, and an encryption generator 1021 to produce “E-key” 1022, which also may be dependent on a state such as time 920 at which the encryption was performed. For example, the date and time of encryption may be used as a numeric seed for generating an encryption key that cannot be recreated even if the encryption algorithm were discovered. Time 920 or other “states” may also be used to select a specific algorithm from an encryption algorithms list 1023, which is a list of available encryption algorithms. In data flow diagrams, it is convenient to illustrate this packet encryption operation and sequence using a schematic or symbolic representation, as depicted herein by the symbol shown for encryption operation 1026. Throughout this invention disclosure, a padlock may also symbolically represent secure and encrypted data. Padlocks with a clock face located atop the padlock specifically indicate a secure delivery mechanism, e.g., encrypted files that, if not received within a specific interval or by a specific time, self-destruct and are lost forever.
(325) The decryption operation shown in
(326) Should the encryption algorithm selected for implementing decryption operation 1031 not match the inverse of the original algorithm employed in packet encryption operation 1020, should state or time 920 not match the time encryption occurred, or should D-key 1030 not have a predefined numeric relationship to E-key 1022 used during encryption, then the decryption operation 1031 will fail to recover the original unencrypted data 990 and the packet data will be lost. In data flow diagrams, it is convenient to illustrate this packet decryption operation and sequence using a schematic or symbolic representation, as depicted herein by the symbol shown for decryption operation 1032.
(327) As described previously in this disclosure, knowledge regarding the use of encryption and decryption keys in cryptography and of common encryption algorithms, such as symmetric public key encryption, RSA encryption, and AES256 encryption among others, are commonplace and well known to those skilled in the art. The application of such well known cryptographic methods in the disclosed SDNP communication system is, however, not readily susceptible to hacking or decryption because of hidden information, shared secrets, and time-dependent dynamic variables and states unique to the disclosed SDNP communication.
(328) So even in the unlikely case where a cyber-pirate has sufficient computer power to eventually crack a robust encryption method, they lack certain information embedded into the SDNP network as non-public or shared secrets required to perform the decryption operation, and must also crack the encryption in a fraction of a second before the encryption changes. Moreover every data packet traversing the disclosed SDNP network utilizes a different encryption method with unique keys and dynamic states. The combination of missing information, dynamic states, and limited informational content contained within any given packet, renders obtaining meaningful data theft from any given data packet both challenging and unrewarding to a cyber-pirate.
(329) The application of dynamic encryption and decryption of data packets in a SDNP network is described in the above-referenced U.S. application Ser. No. 14/803,869, entitled “Secure Dynamic Communication Network and Protocol”. The application of data packet cryptography in Last Mile communication will be described in further detail in this disclosure.
(330) In order to intercept an entire document, video stream, or voice conversation to reconstruct a coherent data sequence, a cyber-assault must successively crack and decrypt not one but thousands of successive SDNP packets. The daunting challenge of continuously hacking a succession of SDNP packets is further exacerbated by combining dynamic encryption with the previously described methods regarding data packet scrambling. As illustrated in
(331) As shown, scrambling and encryption represent complementary techniques in achieving secure communication. Unencrypted scrambled data traversing the network, is referred to as “plaintext” because the actual data is present in the data packets, i.e. the packets have not been encrypted into ciphertext. Encrypted data packets, or ciphertext, comprise scrambled or unscrambled character strings translated into a meaningless series of nonsense characters using an encryption key, and cannot be restored to its original plaintext form without a corresponding decryption key. Depending on the algorithm employed, the encryption and decryption keys may comprise the same key or distinct keys mathematically related by a predefined mathematical relationship. As such, scrambling and encryption represent complementary techniques in achieving secure communication in accordance with the disclosed invention for SDNP communication.
(332) The two methods, scrambling and encryption, can be considered independently even when used in combination, except that the sequence used to restore the original data packet from an encrypted scrambled data packet must occur in the inverse sequence to that used to create it. For example, if the data packet 990 was first scrambled using scrambling operation 926 and then encrypted using encryption operation 1026, then to restore the original data packet, the encrypted scrambled data packet 1024 must first be decrypted using decryption operation 1032 and then unscrambled using unscrambling operation 928. Mathematically, if a scrambling operation F scrambles a string of bits or characters into an equivalent scrambled version and an unscrambling operation F.sup.−1 undoes the scrambling, whereby
F.sup.−1[F(A)]=A
(333) and similarly if an encryption operation G encrypts a string of plaintext into equivalent ciphertext and a decryption operation G.sup.−1 undoes the encryption whereby
G.sup.−1[G(A)]=A
(334) then in combination, the successive operation of scrambling and then encrypting followed by decrypting and then unscrambling returns the original argument A, the unscrambled plaintext data packet. Accordingly,
F.sup.−1{G.sup.−1[G(F(A))]}=A
(335) because the sequence occurs in inverse order, specifically decrypting [G.sup.−1] encrypted scrambled packet [G(F(A))] restores scrambled plaintext data packet F(A). Subsequent unscrambling operation F.sup.−1 of scrambled plaintext packet F(A) restore the original data packet A.
(336) Provided linear methods are employed, the sequence is reversible. For example, if the data packet is first encrypted and then scrambled, then to restore the original data packet the scrambled ciphertext must first be unscrambled and then decrypted. Accordingly,
G.sup.−1{F.sup.−1[F(G(A))]}=A
(337) Changing the sequence does not work. Decrypting a data packet that was previously encrypted and then scrambled without first unscrambling it will not recover the original data packet, i.e.
F.sup.−1{G.sup.−1[F(G(A))]}≠A
(338) Similarly unscrambling a packet that was scrambled and then encrypted will also fail to restore the original data packet, because
G.sup.−1{F.sup.−1[G(F(A))]}≠A
(339) To summarize, if the plaintext packet is scrambled before it is encrypted, it must be decrypted before it is unscrambled; if the plaintext packet is encrypted before it is scrambled, it must be unscrambled before it is decrypted.
(340) While it is understood that scrambling and encrypting may be performed in either sequence, in one embodiment of the SDNP methods in accordance with this invention, encryption and decryption occur more frequently during network transport than scrambling and therefore encryption should occur after scrambling and decryption should occur before unscrambling, as illustrated in
(341) One means to enhance to enhance security in any implementation using static scrambling encryption is to insure that each data packet sent is subjected to different scrambling and/or encryption methods, including changes in state, seeds, and/or keys at time t.sub.1 when each data packet enters the communication network.
(342) However, a more robust alternative involves dynamically changing a data packet's encryption or scrambling, or both, as the packet traverses the network in time. In order to facilitate the required data processing to realize a fully dynamic version of SDNP communication, it is necessary to combine the previously defined processes in order to “re-scramble” (i.e., unscramble and then scramble) and “re-encrypt” (i.e., unencrypt and then encrypt) each packet as it passes through each communication node in a packet-switched communication network. As used herein the term “re-packet” or “re-packeting” will sometimes be used to refer to the combination of “re-scrambling” and “re-encryption,” whether the packet is initially decrypted before it is unscrambled or unscrambled before it is decrypted. In either case, the unscrambling and decryption operations at a given node should be performed in an order that is the reverse of the scrambling and encryption operations as the packet left the prior node, i.e., if the packet was scrambled and then encrypted at the prior node, it should first be decrypted and then unscrambled at the current node. Typically, the packet will then be scrambled and then encrypted as it leaves the current node.
(343) The “re-packet” operation at a communication node is illustrated in
(344) The application of re-packeting of data packets in a SDNP network is described in the above-referenced U.S. application Ser. No. 14/803,869, entitled “Secure Dynamic Communication Network and Protocol”. The application of data packet re-packeting in Last Mile communication will be described in further detail in this disclosure.
(345) Packet Mixing and Splitting—Another key element of the secure dynamic communication network and protocol disclosed herein is its ability to split data packets into sub-packets, to direct those sub-packets into multiple routes, and to mix and recombine the sub-packets to reconstruct a complete data packet. The process of packet splitting is illustrated in
(346) The purpose of parse operation 1052 is to break data packet 1054 into smaller data packets, e.g. data sub-packets 1055 and 1056, for processing of each of the constituent components. Breaking data packet 1054 into smaller pieces offers unique advantages such as supporting multipath transport, i.e. transmitting the data packets over multiple and different paths, and facilitating unique encryption of constituent sub-packets using different encryption methods.
(347) The splitting operation can use any algorithm, numerical method, or parsing method. The algorithm may represent a static equation or include dynamic variables or numerical seeds or “states” such as time 920 when the incoming data packet 1054 was first formed by a number of sub-packets, and a numerical seed 929 generated by seed generator 921, which also may be dependent on a state such as time 920 at the time of the data packet's creation. For example, if each date is converted into a unique number ascending monotonically, then every seed 929 is unique. Time 920 and seed 929 may be used to identify a specific algorithm chosen from a list of available methods, i.e. from algorithm 1050. Packet splitting, or un-mixing, comprises the inverse procedure of mixing, using the same algorithm executed in the precise reverse sequence used previously to create the specific packet. Ultimately everything that is done is undone but not necessarily all in one step. For example, a scrambled encrypted data packet might be decrypted but remain scrambled. Processed by splitting operation 1051, un-split incoming data packet 1054 is converted into multiple data packets, e.g. split fixed-length packets 1055 and 1056 using parse operation 1052 to algorithmically perform the operation. In data flow diagrams, it is convenient to illustrate this packet splitting operation 1051 including parsing 1052 and junk operation 1053 using a schematic or symbolic representation, as depicted herein by the symbol shown for splitting operation 1057.
(348) Thus, as used herein, the term “splitting” may include parsing, which refers to the separation of a packet into two or more packets or sub-packets, and it may also include the insertion of junk packets or sub-packets into the resulting “parsed” packets or sub-packets or the deletion of junk packets or sub-packets from the resulting “parsed” packets or sub-packets.
(349) The inverse function, packet-mixing operation 1060 shown in
(350) In accordance with this invention, packet mixing and splitting may utilize any of a large number of possible algorithms.
(351) The application of data packet mixing and splitting in a SDNP network is described in the above-referenced U.S. application Ser. No. 14/803,869, entitled “Secure Dynamic Communication Network and Protocol”.
(352) The application of data packet mixing and splitting, along with scrambling, unscrambling, encryption, decryption, and deception in Last Mile communication collectively comprise the SDNP Last Mile security operation. This SDNP Last Mile security operation is “directional” meaning the operation performed for and on all outgoing data packets is different than the operations performed on incoming data packets.
(353) The SDNP Last Mile security operation is also symmetric and reversible over the Last Mile, meaning that using local security credentials such as keys, seeds, shared secrets specific to the particular Last Mile, the operations performed on an outbound data packet in a client's device are undone in the SDNP gateway, generally by performing the anti-function, i.e. the mathematical inverse, or every functional operation originally executed by the client's device but in reverse sequence. As such, the SDNP gateway is enabled to recover the original content in preparation for routing through the SDNP cloud. Similarly, for incoming data packets into a client's device using zone-specific security credentials for the Last Mile, the SDNP Last Mile security operation executed in the client device undoes each security operation performed by the SDNP gateway by executing the anti-function in reverse sequence. In this manner, the client device can recover the original data on all incoming data packets.
(354) The SDNP Last Mile security operation is dynamic and localized, i.e. zone specific, using state dependent conditions, e.g. location, time, etc. to determine which parameters were used at the time the data packet was prepared and for what region, geography, or locale specific for a particular Last Mile. By being localized, data packet preparation performed in different regions and over different Last Mile connections never have the same coding or use identical security credentials. Furthermore, these Last Mile security credentials always differ from those used in the SDNP cloud. Moreover, being dynamic, the state used for creating the data packets changes constantly, further obfuscating the actual security process performed on each data packet and rendering no two data packets alike.
(355) By the unique combinational application of directional symmetric reversible dynamic localized security operations specific to each Last Mile communication, the algorithmic application of dynamic scrambling, dynamic fragmentation, dynamic deception, and dynamic encryption made in accordance with this invention insures HyperSecure communication not achievable from the use of simple static encryption methods. The pervasive application of dynamic methods valid for durations of only tens of milliseconds not only makes interpretation nearly impossible, but gives a hacker no time in which to decipher or interpret the data packet before another arrives. In practice, SDNP Last Mile security operations may be executed using software, firmware, hardware, dedicated security ICs, or any combination thereof.
(356) Although a myriad of combinational sequences are possible, one example of SDNP Last Mile security operation is illustrated in
(357) These packets are then split into multiple pieces by splitting operation 1057 using parsing operation 1052 and sent separately to encryption operation 1026. Each piece is then encrypted using common or distinct encryption keys and the resulting ciphertext is arranged into a serial SDNP payload shown as data packet 1199A. The packet is then formatted into IP data packets, i.e. “IP packet preparation”, in preparation for communication onto the Last Link and Last Mile. All operations performed are dynamic, occurring at a particular time or with a specific state 920A during the security process execution.
(358) In the case of incoming data packets shown in the lower half of the illustration, incoming data from the Last Link comprising a serial SDNP payload 1199B, i.e. from “IP packet recognition” is first decrypted in pieces or as a whole by decryption operation 1032 followed by mixing operation 1061 to recover the true data stream. The data packets are then de-junked, i.e. the junk data is removed from the data packets using de-junk operation 1053B, followed by packet unscrambling operation 928 to recover the “data received”. All operations performed on incoming data packets must use the state 920B used when the SDNP gateway created the data packet, i.e. containing information of a particular time or with a specific state 920B at the packet's birth. This state information may be sent through a different communication by a signaling server or may be carried in the incoming data packet as plaintext or alternatively as static ciphertext, i.e. with a decryption key already known by the SDNP Last Mile security operation. Details of state 920B, cannot however, be encrypted using a key requiring the state information contained within state 920B, or otherwise the code will be unable to open and use its own security credentials.
(359) Another example of SDNP Last Mile security operation is illustrated in
(360) These packets are then split into multiple sub-packets by splitting operation 1057, using parsing operation 1052, and sent separately to encryption operation 1026. Each piece is then encrypted using common or distinct encryption keys and the resulting ciphertext is arranged into multiple SDNP payloads shown as data packets 1199C, 1199D, and 1199E. The packets are then formatted into separate and distinct IP data packets, i.e. “IP packet preparation”, in preparation for communication onto the Last Link and Last Mile. All operations performed are dynamic, occurring at a particular time or with a specific state 920C during the security process execution.
(361) In the case of incoming data packets shown in the lower half of the illustration, incoming data from the Last Link comprising parallel SDNP payloads 1199F, 1199G, and 1199H, i.e. from “IP packet recognition” are first decrypted piecewise by decryption operation 1032 followed by mixing operation 1061 to recover the true data stream. The data packets are then de-junked, i.e. the junk data is removed from the data packets using de-junk operation 1053D, followed by packet unscrambling operation 928 to recover the “data received”. All operations performed on incoming data packets must use the state 920D used when the SDNP gateway created the data packet, i.e. containing information of a particular time or with a specific state 920D at the packet's birth. This state information may be sent through a different communication by a signaling server or may be carried in the incoming data packet as plaintext or alternatively as static ciphertext, i.e. with a decryption key already known by the SDNP Last Mile security operation.
(362) The SDNP Last Mile Security operation need not use the same algorithms or methods for both incoming data and outgoing data packets. As exemplified in
(363) The digital output of audio video CODEC 1182A is then mixed with textual data from virtual keyboard 1183 (a keypad realized on a touch screen) and with data files 1179A using content mixer 1184. This mixer, in turn, sends data files to SDNP Last Mile security operation 1190A, and provides SDNP header information to IP packet preparation operation 1191A in order to identify and label real time data packets from static files. SDNP Last Mile security operation 1190A then passes the secure data packets to IP packet preparation operation 1191A, which thereafter embeds the SDNP payloads into IP data packets in accordance with routing instructions received by the SDNP signaling server 1603. The data packets my be distributed into multiple IP packets for multi-route Last Mile communication or may be concatenated into a serial data string and embedded and fit into one or more serial data packets for singe route Last Mile communication. These packets are then passed in to the client PHY operation 1192A to add Layer 1 and Layer 2 data to complete the IP data packet.
(364) In the reverse operation shown in the lower half of the illustration, incoming data from the Last Link received by client PHY 1192B is passed to IP packet recognition operation 1191B, which identifies the incoming data as a valid message or as an unknown and possibly malicious data packet. Valid messages are identified using SDNP tags, seeds, keys, and other identifiers communicated beforehand to the client device and to IP packet recognition operation 1191B by signaling server 1603. Anthropomorphically, IP packet recognition operation 1191B expects and even anticipates valid incoming data packets. Unexpected data packets lacking proper identification are discarded and never opened or processed further. In this manner, a hacker cannot disguise themselves and send valid data to any SDNP node without first registering their identity to the SDNP cloud.
(365) IP packet recognition operation 1191B passes the valid data packets to SDNP Last Mile security operation 1190B, which in turn performs all necessary operations to reconstruct the true content of the data packet—data comprising a serially arranged amalgamate of video, audio, text, and data files. Content de-mux 1193, a de-multiplexer that undoes the mixing operation used in data packet creation, e.g. it un-mixes the serial data file created by mixer operation 1184 performed in the other caller's phone, is then used to separate the various file types. Outputs of content de-mux 1193 include text shown displayed in messenger window 1196, data files 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 via speaker 1194 into sound 1198B.
(366) For Last Mile data transport, data must be embedded or wrapped in a multi-tiered arrangement shown in
(367) In SDNP routing, MAC header 431 in Layer 2 describes the MAC connection for the Last Link, i.e. the connection between the client device and the first device in the Last Mile link. By using source and destination addresses of the client device and the SDNP gateway, header 434 in Layer 3 specifies the end points of routing over the Last Mile. Because the Last Mile is not part of the SDNP cloud however, the precise route data packets take over the Last Mile is not explicitly stated or controllable. In SDNP Last Mile communication, transport header 436 in Layer 4 specifies UDP is used for SDNP real time payloads, and also specifies the ad hoc assigned SDNP port address used in each packet—an address changing dynamically to thwart port interrogation cyber-attack strategies.
(368) SDNP payload 438, the payload of the Last Mile IP packet, contains SDNP preamble 1198 containing zone information, keys, and seeds, and SDNP data field 1199A, a serial string of multiple segments of independently encrypted ciphertext. The decrypted form of the ciphertext comprises plaintext files 1197A, 1997B, and 1197C, each containing their own unique SDNP header, and corresponding data files data 91, data 92, and data 93 respectively. The individual sub-headers include information involving tag, zips, addresses, urgency, and QoS data as applicable.
(369) The roles of SDNP preamble and headers vary depending on the command and control methods employed. In tri-party Last Mile communication, a signaling server instructs the client device and the SDNP gateway or gateways how to communicate with one another to make a call, send a file, or open a session. As such, the instructions are communicated to both devices using a command and control data packet with TCP transport prior to sending any media data packets. As such, the minimum data required in the Last Mile communication between the client and the SDNP gateway is a tag or address used to identify the incoming packet. In some cases, for example, if a signaling server cannot be reached, then in an alternative embodiment, the SDNP data packet can carry additional data in its preamble and packet headers.
(370) The data packet and accompanying table 1177 shown in
(371) The length of each data field specified by L Fld X can vary from zero or 0B (a null data field), to a maximum hexadecimal length of FFFF or 65,535B. For practical reasons of compatibility with Ethernet, the maximum data packet length for any one field is preferably limited to 1500B or hexadecimal 05DC, and the aggregate length of all data fields should not exceed the jumbo packet size of 9000B or hexadecimal 2328. The specified length of each data field can vary independently. A zero field length, e.g. where L Fld 8=0000 hexadecimal, results in elimination of the corresponding data 8 field but does not eliminate the corresponding header Hdr 8. Headers are only eliminated by Field # specification.
(372) In accordance with this SDNP protocol, the apportionment of content across the various data fields is extremely flexible. Data directed to single destination may be contained within a single data field, or for purposes of deception may be split into multiple data fields and merged with junk data. The size of the data fields may vary independently. Data fields may also be included containing purely junk data or alternatively entire data packets may be generated containing only junk data. For efficient packet routing however, data targeted for different destinations should be partitioned into separate data fields each with their own unique headers.
(373) The SDNP packet format is applicable for end-to-end transport throughout the entire SDNP network including across multiple clouds and zones such as the SDNP cloud or in Last Mile communication. Although the contents of the SDNP data packets change as they traverses the network, the SDNP packet format remains unchanged. Since this format includes minimal data overhead, the SDNP data packet format is equally applicable for large payloads or for time critical real-time communication. The packet format is applicable for bidirectional data flow, i.e. for data flow from the Last Mile into an SDNP gateway and across the SDNP cloud, or conversely for delivery of data packets emanating from the cloud, exiting a SDNP gateway for transport across the last mile to the destination client device.
(374) In operation, the direction of SDNP data routing is determined by the Network Layer-3 source and destination addresses described within IP header 434 of
(375) Payload 438 is made of two portions, a readable portion comprising preamble 1198, and an unreadable potion 1199a containing data in a “concealed form”. The content of this packet may employ any number of concealment techniques to obscure its content such as encryption, scrambling, and possibly containing junk data. The concealment method must be undone to extract usable content 1197a, 1997b and 1197c. These packets contain the destination addresses of the future outgoing packets. The addresses exist only in an unconcealed or decrypted form for only a brief moment before the next packets can be prepared and encrypted.
(376) As described, SDNP preamble 1198 comprises information relevant to the entire packet. Aside from the data field specifications,
(377) Seeds and keys can be delivered securely in public, i.e. in non-encrypted form, because the data lacks the information needed to use them—they comprise only part of the security credential. The other portions of security credentials, the missing pieces, may be sent previously in another data packet, or may comprise shared secrets of algorithms, look-up tables, and codes not delivered over the network and not part of the message. Encryption keys may be symmetric keys, where both the sender and the recipient hold the key, or public keys, where the public, including the sender, has access to the encryption key but only the recipient, i.e., the party generating the encryption key, holds the decryption key. Moreover, all the security credentials are limited to a specific security zone, e.g. U1, and are dynamic, limited to a specific time or state that expires if unused within a specified time. If the seed and key data fields are not used as security credentials, e.g. because the signaling server independently instructs the SDNP devices regarding security operations, then these fields can be filled with numeric values falsely appearing as encryption keys, misdirecting a cyber-attacker into wasting time analyzing a decoy security key.
(378) In Last Mile communication, the intermediate routers between the client's device and the SDNP gateway do not process, interpret or open the transported data packets because they are not part of the SDNP network and lack the ability to query or interpret the SDNP packet data contained within. Instead, all security operations are exclusively executed at the two end points, the SDNP client and the SDNP gateway because only these devices operate as SDNP communication nodes. Since each end point executes SDNP protocols dynamically, the Last Mile communication is HyperSecure over the entire Last Mile. If the other calling party also runs SDNP software, then the second party's Last Mile is also secured by the aforementioned SDNP methods and HyperSecure communication is guaranteed “end to end”—from one caller to the other.
(379) In the event, however, that the end device is not a SDNP client, then the router nearest the caller, i.e. the Last Link router, can be enabled with SDNP firmware, and the Last Link can be reasonably secured from special functions performed by the SDNP enabled router even though it is not SDNP enabled. This alternative Last Link security method is described in greater detail in subsequent sections of this disclosure and will not be elaborated upon in this section. The described method, while applicable for securing Last Link communication, is not sufficient for protecting other portions of the Last Mile.
(380) Referring again to
(381) Although the signaling server may supply most of the described information to the SDNP client and SDNP gateway, one fundamental component necessarily carried by the Last Mile data packet is an “address field” or tag needed to identify the data packet. The field, referred to as the SDNP payload's destination address (abbreviated in the illustration as “Dest Addr”), may comprise any unique identifier sufficient to distinguish the identity of one data field from another. Its purpose is similar to the function of bar codes used to tag and track luggage in an airport or boxes shipped by a courier. Address types may for example comprise a numeric tag, a SDNP zip, an IPv4 or IPv6 address, a NAT address, or even a POTS regular phone number, so long that the identifier is unique to prevent conflict in identifying the data packet. The size of the destination address field varies with the type of address type selected.
(382) To maintain packet anonymity during routing, it is preferable to employ confidential codes such as a SDNP Zip code as the SDNP destination address rather than using true phone numbers or IP addresses. In operation, whenever a data packet from an SDNP client arrives at a SDNP gateway, the SDNP payload is decrypted and then each data field header is inspected for the identifying destination addresses. Before the data header can be inspected, the data packet must be decrypted or processed to undo the concealment methods used in the packet's creation. In the case of dual-channel or tri-channel communication, as shown in
(383) Once a specific data field is found to contain the identified destination address, e.g. a SDNP Zip code, matching instructions from signaling server 1603, the data field is extracted, optionally mixed with other related content by mixer 1184Z and rewrapped into a new IP or SDNP datagram by SDNP packet preparation operation 1191Z for delivery to its next destination. The new data packet headed into the cloud includes an SDNP header 434Z containing the destination of the new packet and the data content, SDNP payload 435Z. The destination supplied by the signaling server 1603 to the gateway media node as an IP address or SDNP address may comprise another SDNP server operating as a SDNP cloud node or may involve Last Mile communication to another SDNP client. In such tri-channel communication cases, the destination address is not really an address but a means to identify the packet, where its next destination is already known by the SDNP gateway. In the case where the destination of the packet is for SDNP cloud routing the data packet is then processed by SDNP cloud security operation 1190Z in accordance with Z1 security credentials for the cloud, not U1 credentials used in the Last Mile.
(384) In single channel communication, as shown in
(385) If a media node receives a data packet without first receiving instructions from a signaling server, the media node will revert to default instructions as to how to process the incoming data packet, and how to prepare outgoing data packets. Should the media node not hold any instructions on how to handle unannounced incoming packets, the data packet will be discarded. If the media node is enabled with instructions on how to process unidentified packets, the media node will first confirm in accordance with security credentials that the packet is a valid SDNP packet, and process it accordingly. If the sender cannot, however, be identified, e.g. if an encryption code, seed, or source address is invalid, then the packet will be discarded as a fraud.
(386) Returning to
(387) The packet field labeled “Data Type”, if used, facilitates context-specific routing, distinguishing data, pre-recorded video, text and computer files not requiring real time communication from data packets containing time sensitive information such as voice and live video, i.e. to distinguish real-time routing from non-real-time data. Data types include voice, text, real-time video, data, software, etc.
(388) The packet fields labeled “Urgency” and “Delivery” are used together to determine best how to route the data in a specific data field. Urgency includes snail, normal, priority, and urgent categories. Delivery includes various QoS markers for normal, redundant, special, and VIP categories. In one embodiment of this invention, the binary size of the various data fields as shown in table 1177 is chosen to minimize the required communication bandwidth. For example, data fields as shown may range from 0 to 200B whereby eight data fields of 200B per data field means that a SDNP packet can carry 1,600B of data.
(389) Both
(390) A similar process is employed when the SDNP gateway receives a data packet from the cloud (including another gateway) and sends the data packet to a client device, e.g. from the SDNP cloud to the client's phone (the callee). As shown in
(391) The resulting operation extracts a number of data fields. A subsequent operation splits these data fields in content-splitting operation 2184Z to extract specific content comprising data field 1 and its associated data field header 2117D labeled as Hdr 1 using recognition operation 2191D. Header Hdr 1 contains the data field's destination address, data type, urgency, and delivery information. The extracted data field is then rewrapped into a new IP or SDNP datagram by SDNP packet preparation operation 1191Z for delivery to its next destination. The new data packet headed into the cloud includes an SDNP header 2434Z containing the destination of the new packet (the IP address corresponding to the person's phone number) and the data content, SDNP payload 2435Z. The outgoing packet then processed by SDNP Last Mile security operation 2190Z in accordance with U1 security credentials for the Last Mile, not Z1 credentials used in the cloud.
(392) If a signaling server is not available, i.e. in single-channel communication, then the media node must process an incoming data packet using instructions previously delivered it as a default instruction. In such instances, the incoming data packet is checked against criteria needed to confirm the sender is a valid SDNP client (such as a SDNP zip code or an authentication code delivered previously as a predetermined shared secret). If the packet is determined to be valid, the packet is processed in accordance with the default instructions. If not, the packet is discarded.
(393) The aforementioned methods are exemplary and not intended to limit the processing and routing of data packets to a particular data packet format.
(394) Security and Privacy in Communication
(395) An important consideration in Last Mile communication is a network's ability to support both secure communication and private communication. Although privacy and security are often associated, they are not the same thing. Security as the term is used in communication is considered the “discipline to prevent unauthorized access to communication data in recognizable form”. Security does not however, cover cases where an individual or agency has the right to access or monitor a communication. Privacy is defined as “the state or condition of being free from being observed or disturbed by other people and in being free of public attention”. In legal terms privacy is defined to be a person's right to control access to his or her personal information.
(396) In communication, the privacy rights of an individual in their voice calls, video, text, emails, personal messaging, etc. vary dramatically by country. The role in complying with applicable governmental regulations to provide legally valid access to communication is discussed in a subsequent section. That aside, an ideal network and communication system should be able to prevent hacking of communication, i.e. it should be absolutely secure, and it should be capable of insuring all communications are limited to those with the right to know, i.e. it should be private.
(397) When assessing the privacy and security capabilities of a network, the network's Last Mile and its connected devices must be considered carefully. Depending on the security credentials used to establish information access privileges, the Last Mile and its connected devices frequently determine a network's security and privacy, i.e. the Last Mile represents the weakest link. Four possible combinations of communication networks must be considered: Secure and private networks. From an individual's perspective, this case represents ideal network performance, one that insures both security of the information and privacy for the individual. In its extreme, a truly secure private network means any individual, government, agency or corporation can not intercept meaningful communication nor obtain private data about a person's behavior, actions, their contacts and associates, their personal preferences and activities, etc. Although privacy rights advocates consider an idealized secure private network as the gold standard in confidential communication, governments, security organizations, and corporations view absolute autonomy in communication as problematic, allowing individuals to engage in criminal activities and terrorism with absolute secrecy and impunity. Unsecure networks lacking privacy. A network that is not secure and has no privacy provisions (such as Internet OTT carriers today) represents a severe risk to any individual, group, club, company, or government using the communication channel. Because a cyber-hacker can easily access calls and data, any malevolent party can use this information for any purpose they choose. For practical jokers and spammers, unsecure communication channels can be commandeered to invoke chaos, flood networks with spam, initiate denial of service attacks, and create damaging mischief. For ideologues, political activists, and religious cults, unsecure communication can be used to leak sensitive information to precipitate political change, discredit government officials, stimulate riots, or even topple governments (see the historical fiction movie “The Fifth Estate” (DreamWorks© 2013) as an example chronicling WikiLeaks release of hundreds of thousand of sensitive government documents precipitating a firestorm of international repercussions). For economically motivated cyber-criminals such as those associated with organized crime and mafia, attacks focus on money crimes, for example, theft, diversion of funds, fraud, identity theft, money laundering, extortion, blackmail, and other felonies. For those involved in fear and intimidation such as drug cartels, gangs, and terrorists, unsecure communication can be monitored to track the location, movements, and actions of their competitors, enemies, and targeted victims for purposes of planning and implementing violent crimes such as assaults, kidnapping, murder, bombings, or acts of terrorism. Finally in the case of personal cyber-attacks, unsecure communications can be used to illegally hack databases containing individuals' private information including social security numbers, passports, banking information, credit card information, medical records, and other personal confidential information. Secure networks lacking privacy. Examples of secure networks lacking privacy commonly include corporate accounts where the IT (information technology) manager or security department have the right and authority to monitor all corporate communications to insure no inappropriate or illegal communication is occurring over the company's network. Even though the network is secure from hackers and cyber-criminals, the communications on such a network are not private and may be monitored by authorized agents to detect wrongdoing including unauthorized personal use of company communication infrastructure, corporate espionage, violation of confidentiality agreements, unauthorized disclosure of intellectual priority (IP leaks), sexual harassment, violations of the fair disclosure regulation (reg. FD), insider trading, violation of FCPA (foreign corrupt practices act), graft, bribery, fraud, financial reporting violations, securities violations, and more. In corporate communication, an individual is informed upon joining the company that their corporate communications are not private and may be monitored including company phone calls, email, text, personal messaging and SMS, and other communiqué. In the case of court proceedings, whether civil or criminal, these communiqués may also be subpoenaed and entered into evidence in court even if personal information is comingled with corporate information. In essence if an employee of a company utilizes company communication, devices, and networks for personal use, then (except in the case of attorney-client privilege) all the information is fair game and should not be considered private. For this reason and others, the mixed use of personal messengers such as Line and KakaoTalk for business and personal use is especially problematic because an employee cannot invoke privacy rights to prevent inspection of their text chats, pictures, and files. Quasi-private, unsecure networks. A quasi-private unsecure network is one where the network carrying the data can be hacked, e.g. wire tapped, but private transactions can be confidentially performed despite the lack of security provided certain conditions are met. In this manner privacy is established by confirming the identity of a caller (or callers) by various means using shared secrets, undiscoverable even by a hacker intercepting the call. A common example of a private unsecure communication is a voice banking transaction. The caller confirms their identity by answering a series of ever-changing questions to which an imposter would be unlikely to know the answers, e.g. “we see you ate dinner last night and paid with our credit card. Could you tell me what city did you eat dinner in?” Or, “you receive a regular billing from a winery. What winery is it?” Another example question is “could you tell me the last name of your favorite grade school teacher?” For these methods of identity verification to work, the bank must either have access to non-public information (such as credit card statements) or the bank and its clients must establish a set of shared secrets when the account was first set up, generally in person and not electronically. After the identity if the caller is confirmed, the client can instruct the institution to perform certain actions that would not benefit a cybercriminal. For example, “please move $10,000 from my savings to my checking account.” If the money transfer is wired to another bank, however, even a more rigorous verification must occur to insure the client's privacy. In any case, privacy depends on meeting the condition that the communication cannot reveal shared secrets either electronically or aurally, otherwise all privacy is lost and accounts may be at risk. As such authenticated communication on an unsecure line is referred to as quasi-private meaning conditional privacy. Another example or quasi-private communication over a unsecure network can be performed by utilizing a security token, a device issued by the bank that only the client possesses. The pseudo-random number generated by the device is told to the bank's operator who confirms the number is consistent with the bank's authorized numbers. Since the number is 8 or more digits the chance of guessing the right code the first time is miniscule. If the wrong token number is reported, the call is terminated, the account is frozen, and the fraud department is alerted to investigate. In any such case, the importance of insuring privacy over an unsecure network depends on being able to communicate without verbally revealing any confidential details such account numbers, PINs, credit card information, etc., i.e. the communication is only quasi-private.
(398) Identity Verification and AAA—The concepts of security and privacy rely on accurate and reliable identity verification i.e. that a caller is who they say they are. Identity verification, also known as “authentication”, is important to enable valid use of data and communication, and to prevent illegal or unapproved access. Reliable identity verification is important in national security, law enforcement, IP ownership, business enterprise, and in individual rights. Example of the importance of identity verification include the following: To a country's national security, caller identity verification is important in tracing the identity of criminals, spies, terrorists, drug traffickers, and anyone divulging national secrets or threatening national security. It is equally important to be able to identify individuals who are authorized to access, read, or send confidential, secret, or top secret communiqués, data, and files. For law enforcement, caller identity verification is important in identifying individuals or organizations involved in criminal activities such as robberies, arson, drug trafficking, smuggling, prostitution and human trafficking, extortion, blackmail, and other felonies. It is equally important to be able to identify individuals who are authorized law enforcement agents including police, fire, paramedic, park ranger, air marshal, TSA and airport security, port authority, customs, and coast guard services. For IP owners such as movie studios, identity identification is important in identifying individuals, organizations, and entities engaged in piracy and the unauthorized distribution of copyrighted material such as music, movies, books, videos, etc. It is equally important in confirming the valid and legal distribution of IP and copyrighted material. To business enterprises, identity verification of its employees is important to track the intentional or accidental release of material non-public information, to identify those engaged in commercial espionage, to identify individuals engaged in the illegal disclosure of intellectual property, and those committing other crimes such as fraud or personal use of company communication. It is equally important in confirming the identity of those to which company confidential information is available, and specifically to authorize which specific types of data they have access. For example, the engineering department of a company should not have access to the personnel records of the marketing department in order to compare how much the marketing staff is being paid. To individuals, identity verification is important to insure a caller's “privacy” by confirming the person or persons with whom you are communicating are not imposters.
(399) So the role of identity verification is to confirm a person's identity, i.e. to authenticate they are who they claim to be, and to identify, block, and ultimately apprehend those misrepresenting their identity. Authentication is the first “A” of the triple-A security model, or AAA standing for “authentication, authorization, and administration”. Numerous methods such as a PIN code, passwords, fingerprints, tokens, and query response methods may be used to verify a person's identity and to authenticate they have an account on the system.
(400) Once authenticated, a valid user's identity is then used to determine the access rights and privileges to communiqués, data, files, system operation, etc. These privileges and access rights collectively are referred to as a user's “authorization” as granted by the system. i.e. an authenticated user can only access the communications, data, files and system features for which they are authorized. Authorization is therefore synonymous with “privileges” or “access”.
(401) The third “A” in AAA stands for administration. Administration is the bookkeeping of recording authorized access to the network and files, e.g. for the purpose of pay-per-use billing administration, and to monitor and report attempts for unauthorized access to the network, files, and system operation. Administration is also important is tracking changes in security credentials, PINs, passwords, etc. needed in the authentication operation.
(402) A network's ability to perform AAA procedures is paramount to insure privacy and to prevent corruption of the network from unauthorized users or network operators. Any network unable to insure the identity of its users can be corrupted for illegal purposes. Network corruption by unauthorized users is unavoidably problematic in OTT communication because no means exist is to validate caller identity. Unauthorized access and network communication by unidentified users, i.e. anonymity, is a significant risk in modern communication.
(403) Anonymity—The principle of anonymity in communication is the practice of intentionally hiding a caller's identity in order to communicate without traceability. A nearly symbolic example of anonymous communication is a payphone. In a payphone call, payment is by, untraceable cash, the payphone number is public, and anyone can use the phone, meaning the identity of the caller is not known and there is no certain means to determine if a caller is who he or she claims to be. Because the phone number is unlisted, no individual owns the number and (except through sophisticated voice recognition software) there is no way to identify the caller's identity. In the case of a registered device such as cell phone, the identity of the device's owner can be traced through the phone number, but the identity of the caller may still remain unknown. For example, the phone may be stolen, or a pay-per-use SIM card may be used to obscure the caller's true identity. Alternatively, a notebook, tablet, or cell phone can be connected through WiFi in a public café, offering similar anonymity as any public payphone or phone booth.
(404) Some OTT carriers have chosen to operate a VoIP phone service as a payphone, with no identity verification of its subscribers. For example in a recent online report (http://money.cnn.com/2015/11/17/technology/isis-telegram/) CNN Money revealed “An app called Telegram is the ‘hot new thing among jihadists”. Research confirms the Telegram application was instrumental in ISIS terrorists secretly planning its attack on Paris. In the article “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), Telegram founder Pavel Durov said: ‘The right for privacy is more important than our fear of bad things happening, like terrorism’.
(405) Another example of privacy and anonymity being used to commit crimes reported in the press is that of BitTorrent—an application and data network often used to illegally download or share copyrighted material. In the news story by CNN Money Tech (http://money.cnn.com/2011/06/10/technology/bittorrent_lawsuits/) entitled “50,000 BitTorrent users sued for alleged illegal downloads” users were reportedly sued under new anti-piracy laws for illegally downloading the move “The Hurt Locker” and other copyrighted material. The network operator BitTorrent has taken the payphone position that they are not responsible for what people do using their network for their private activities. Freedom of speech advocates support this position while law enforcement and governments, national security, and IP rights advocates abhor this attitude as reckless and irresponsible. Regardless of the politics of the matter, as long as communication systems are incapable of performing caller verification, the discussion to stop anonymous calling is purely academic.
(406) Caller verification and authentication is especially important for corporations and business enterprises to control access to company confidential data including intellectual property, engineering developments, product evaluations, manufacturing knowhow, confidential financial reports and projections, business status, sales forecasts, inventory and WIP, quality audits, business and IP contracts, customer lists, employee records, and other trade secrets. When accessing company communications, the access privileges granted any employee, contractor, or officer depends on confirming their identity. In conference calls including investor calls, identity verification is important to confirm who is present on the call and to insure that no one is listening without their need-to-know.
(407) Ironically, while caller verification can be used to thwart criminals and deter corporate espionage, the same identity verification is beneficially useful to insure a caller's privacy. If both parties in a call or text chat confirm their identity through some prescribed authentication procedure, imposters have no access to a call or its data, protecting the call from criminal attacks.
(408) Lastly, a distinction must be made to distinguish anonymous callers from anonymous calls. An anonymous caller is an individual who disguises their true identity from the network on which they are communicating. An anonymous call, however, does not require the caller has anonymity from the network, just that their true identity during communication is obfuscated in the call data packets. A registered account holder on the SDNP network can, in accordance with this disclosure, place a call or send data using anonymous data transport even though the network knows their identity and phone number. In this way, law-abiding citizens can communicate anonymously without the need to hide their identity from the SDNP network operator. If a caller is engaged in normal private calls, entertainment, or business, their SDNP call remains private and secure even though the network knows their identity as stored in the SDNP name server database.
(409) Examples of the need for legal anonymous communication includes global gaming where it is important to protect a gamer's identity, especially that of children. Another case potentially benefitting from anonymity is in vehicle-to-vehicle (V2V) communication to prevent drivers with road rage from exacting revenge by identifying the personal data of other drivers aggravating their driving. In contrast, if a caller is engaged in criminality or other nefarious activity in their communication, law officials can (in accordance with applicable law) gain access to their calls and data transmissions. In this manner the network operator can satisfy the requirements of court orders and subpoenas without exposing the identity or opening the calls of law abiding citizens.
(410) In summary, using the disclosed SDNP communication methods, only identifiable SDNP subscribers can place anonymous calls. Unidentified callers have no access to the SDNP network or ability to place anonymous calls.
(411) National Security and Privacy—The nature of secure and private communication is further confounded when the roles and laws of governments are considered. Every country asserts their sovereign right to control communications within their borders. With the advent of the Internet and dynamically routed packet switched data networks, however, network surveillance and monitoring faces a plethora of technical and legal challenges. One concern is the issue of monitoring server-to-server network “through” traffic—data packets crossing through a country without ever stopping. Since Internet traffic is dynamically routed, a network operator has no idea what data packets its network of servers is carrying. Any nation can, of course, attempt to intercept and decode this high-volume bulk data, but because of encryption, access without knowing the encryption keys is challenging, especially for real time monitoring. And because the callers may not reside within the country, a particular nation has no jurisdiction to subpoena or demand the encryption keys used to place the call. Such network through-data is analogous to radio wave traffic traversing the earth's atmosphere. Even though the radio waves may pass overhead, there is no practical way to stop them. Similarly, except by totally isolating a country's infrastructure from the Internet, there is no realistic way to stop network through-data traffic.
(412) A more pragmatic solution to governing communications is to focus monitoring on Last Mile communications, i.e. to intercept and monitor calls and call data where the source and/or destination of a call occurs within a country's borders. This approach has several advantages over intercepting bulk through-data traffic including (i) the magnitude of the data is smaller, i.e. more manageable to analyze, (ii) the last mile communication carrier or network operator is subject to the laws of the country in which it resides (iii) the last mile carrier or network operator may be subpoenaed to surrender any available encryption keys, (iv) the device of the caller must electronically “register” itself to connect to the last mile network and in so doing relinquish information about the caller, and (v) the location of any network connected device can be determined using network addresses, GPS data, or radio signal triangulation.
(413) Unlike the legal and technical challenges of enforcing network through-data regulation, the laws governing Last Mile communication and call termination are wholly the right of the nation in which the Last Mile network operator resides. Depending on the privacy laws of a nation, a nation's government can insist on the level of access it requires in Last Mile communications, including combinations of the following: No right to monitor any data or calls without a court issuing a subpoena based on probable cause. With a court order, the right to secretly monitor any call or data communication. The right to monitor metadata of any call without a court order. The right to monitor all calls and data communications without a court order. The right to intercept, monitor, and as needed, block any and all communications.
(414) For example, various governments such as the United States have taken the position they reserve the right to monitor “metadata” of calls without a court order. Metadata includes data packet information regarding who is calling who, how long the call lasted, where the callers were located at the time of the call, etc. without actually accessing the call data itself. In essence, metadata comprises the data header of an IP packet but not its payload. In contrast, the monitoring of calls and data communication involves access to the payload itself, not just the header data. In such cases where the payload may be encrypted, the government may insist on the network operator supplying it with master encryption keys, should they exist. One issue raised by privacy advocates, is government abuse of power. Specifically should a network rely on a single set of master encryption keys, then relinquishing these keys in response to a court order to enable government surveillance of a specific individual in fact allows the government to monitor everyone's calls, even if the court order was limited to an individual or group. This issue is sometimes referred to as the quandary “who should police the police?”
(415) Another consideration concerns the privacy rights of individuals placing an international call. In such cases, the callers should be aware that the relevant laws for government access depends on the location of both callers, i.e. where the two last-mile networks occur. A call from the United States to the China would be subject to US law for the caller in the United States and to Chinese law for the other caller in China. In such situations, call access by one government may be greater than the other. As such, a caller in the country with greater privacy rights may consider their privacy violated by the other country's government, but since they called that country they have no legal grounds for complaint.
(416) In the case of communication using the previously disclosed secure dynamic communication network and protocol, interception of through-data in HyperSecure cloud communication of fragmented scrambled dynamically encrypted data packets transported anonymously across the SDNP network is virtually impossible. As such, the privacy and security of a Hyper-Secure call are determined by the device and by Last Mile communication. By adapting disclosed SDNP methods for Last Mile communication, a Last Mile capable of HyperSecure communications and high-integrity privacy can be realized as disclosed herein.
(417) Furthermore, mechanisms adjusting the SDNP network's security and privacy settings to accommodate the local law governing Last Mile communication for each nation are disclosed. These methods include safeguards enabling an authorized security authority to monitor communication pursuant to law and court actions without exposing the call data to hackers and cyber-criminals. As such, in HyperSecure Last Mile communication disclosed herein, the use of “back doors” vulnerable to cyber-attacks is not employed.
(418) HyperSecure Last Mile Communication Methods & Apparatus
(419) To ensure end-to-end HyperSecurity, the application of the methods disclosed previously for encrypted scrambled anonymous fragmented data packet routing within a SDNP cloud must similarly be adapted for communication within the Last Mile. Securing Last Mile communication is particularly problematic because the data may be carried on networks not hosted by the SDNP operator, packet routing may involve conventional IP packet routing, and the last mile network's intrinsic security may be unknowingly compromised by a cybercriminal, possibly complicitous with a last mile network operator.
(420) In accordance with this invention, Last Mile communication necessarily involves the transport of IP datagrams outside of the data cloud network using a packet format different from data packets within the SDNP cloud. As illustrated in
(421) As described in the above-referenced U.S. application Ser. No. 14/803,869, SDNP packets change dynamically as they move through the network, with updated routing addresses and constantly changing payloads performed in accordance with shared secrets and dynamic “states” (such as time). For example, data packet 1222B sent by node M.sub.0,0 comprises Layer 3 SDNP datagram B with unique SDNP addresses and uniquely encrypted payload. Downstream, data packet 1222C output from node M.sub.0,f comprises Layer 3 SDNP datagram C with different SDNP addresses and a re-encrypted payload. Several tens of milliseconds later, the same payload reaches node M.sub.0,f which processes the data and forwards data packet 1223G comprising IP datagram G over the Last Mile.
(422) Since the changes are performed in accordance with defined states, the original packet data can be recovered by performing a series of anti-function operations executed in the inverse order to which they were performed. For example, the SDNP functional sequence comprising the steps of scrambling, junk insertion (deception), and encryption can be undone by the inverse sequence decryption, junk deletion, and unscrambling, provided the same state used to execute the function is invoked to perform the corresponding anti-function. State data for a packet may be carried as a time, a seed, or a key either embedded in the packet's payload or sent in advance of the packet. Data transport and processing within the SDNP cloud operate using SDNP cloud specific shared secrets and security credentials. The media nodes sharing a common set of shared secrets and security credentials may be referred to as a security “zone”. The zone used for security credentials operating within the SDNP cloud cannot be revealed to any user's communication outside the SDNP cloud. As such, all Last Mile communication must comprise a different SDNP security zone than the SDNP cloud.
(423) In the example shown, server 1201A and server 1201F hosting corresponding nodes M.sub.0,0 and M.sub.0,f operate as SDNP gateways, i.e. they communicate with devices outside of the SDNP cloud as well as with other intra-cloud SDNP nodes. Communication from these gateways to communication devices outside the cloud represents “Last Mile” communication. Accordingly, the gateway nodes must understand the zone security credentials of both the SDNP cloud and the Last Mile network to which they connect, acting as a translator during packet routing. Semantically, the term Last Mile is an abstraction meaning communication outside the SDNP cloud and does not specifically refer to a distance of one mile. Instead the term Last Mile covers any communication between a client device and the SDNP cloud of any distance, regardless of whether the client device is operating as an SDNP client, i.e. running SDNP application software or firmware, or not.
(424) The term Last Mile also applies to both the client device initiating the call and the client device being called. While literally speaking, the caller's data represents the “first mile” of the call rather than the last—the distinction between first and last miles is arbitrary. Specifically, in any duplex conversion or in any IP communication “session”, the device receiving the call necessarily responds to the call or session request by sending a reply to the caller. In any two-way communication, the first mile connection is therefore invariably functioning as the last mile in the reply data path. In essence the first mile for the caller is concurrently the last mile for the response. As such the defined term Last Mile is used to throughout this application to mean both the first mile and last mile, regardless of which device initiated the call or communication session.
(425) Communication outside of the SDNP cloud to any device other than an SDNP Client necessarily occurs using IP datagrams and not by SDNP datagrams. For example, referring again to
(426) Since the hardware and firmware used in Last Mile communication may vary significantly and may include phone lines, fiber communication, cable TV networks, 3G and 4G radio networks, microwave communication towers, and satellites, analysis of Last Mile communication must be considered for a variety of Layer 1 physical networks and their corresponding Layer 2 data link formats employed. Formats may, for example, include analog (POTS), Ethernet, WiFi, 3G, 4G/LTE, and DOCSIS3. The corresponding security and privacy capability of each Last Mile implementation is considered on a case-by-case basis in the following section on SDNP “call out” communication.
(427) SDNP Call Out Over Unsecured Lines—As a term of art, any call leaving a defined network to be transported across a separate (and generally dissimilar) network is commonly referred to as a “call out”, a term meaning data or voice leaves one network to be transported on another. For example, communication within between clients running Skype applications is commonly referred to as a Skype call, but placing a call from a Skype client to a regular or cell phone number is referred to as a Skype call out feature, or “Skype out” call. In general, call outs to regular phones involve some additional cost, either as a subscription or as a pay-per-use fee.
(428) In the context of this disclosure, communication from the SDNP cloud over an unsecured Last Mile connection to any device other than an SDNP Client is herein referred to the defined term “SDNP Call Out”.
(429) In the lower case, the SDNP Call Out occurs across a digital network to any digital device (such as cell phone 32) not enabled as an SDNP client, i.e. not enabled with SDNP software or firmware. In such cases, data packet 1223 carries the call or data, generally using in accordance with Internet protocol, i.e. IP packet format consistent with the 7-layer OSI model. The IP datagram includes IP or NAT addresses in its source and destination address fields, and IP or VoIP data as its payload. The digital path may involve various forms of digital data such as Ethernet, WiFi, or 4G/LTE that vary along the Last Mile connection.
(430) In either of the exemplary schematics, because the Last Mile communication data is carried outside of the SDNP network over an unsecured communication channel or network, then the call is not secure and is subject to hacking, spying, wire tapping, and other cyber assaults. As described in the background section of this application, unsecured lines and connections for the Last Mile, whether twisted-pair copper wires, coax cable, fiber, Ethernet, WiFi, cellular, or satellite, are intrinsically not secure unless special security methods such as encryption are inserted in the end-to-end data path. The security of the most secure data cloud or VPN is therefore compromised by its weakest link—in this example, the Last Mile. Even encryption does not guarantee security, especially on a single well-defined electrical, microwave, or radio wave connection. In addition to lacking security, the schematic examples do not include any mechanism for identity verification. Incapable of authentication, the Last Mile has no guarantee of privacy. The exemplary schematics therefore represent unsecure Last Mile networks lacking caller privacy.
(431)
(432) A slight improvement to the aforementioned unsecured Last Mile implementation can be achieved using identity validation.
(433) The lower schematic illustrates an SDNP call-out from SDNP gateway 1220A onto an unsecured digital Last Mile. Data carried by IP datagram 1223 to an electronic device such as desktop PC 36, while unsecured, can be authentication using an electronic ID verification method such as token 1226 to which a cyber-attacker does not have access. Because the line is unsecure and sniffable, care must be taken in the digital dialogue not to reveal account numbers or confidential data.
(434) Specific examples of quasi-private unsecured calls are shown in several examples to follow. In
(435) In
(436) Other examples of identity-verified unsecured Last Mile communication are illustrated in
(437) HyperSecure Last Mile Communication—By adapting techniques of the secure dynamic communication network and protocol, HyperSecure communication can be achieved over the Last Mile. To facilitate HyperSecurity, the connected device must execute SDNP code as a “SDNP client”. The SDNP client comprises operating instructions, shared secrets, and SDNP connectivity information, hosted on the connected communication device. The SDNP client may comprise software running on an operating system, firmware running on a microcontroller or programmable IC, or in a dedicated hardware or integrated circuit.
(438) Because the SDNP gateway 1201A and the SDNP app 1335 communicate using a SDNP payload 1222, caller identities and call payloads are incomprehensible to packet sniffing, specifically the SDNP payload 1222 contains source and destination SDNP pseudo-addresses unrecognized by DNS servers and the payload comprises SDNP data that may be scrambled, fragmented, mixed with junk data insertions, and dynamically encrypted. SDNP payload 1222 is embedded in IP datagram 1223, which directs routing over the Last Mile using IP addresses or NAT addresses of the cellular, cable, or ISP carrier's network used for Last Mile connectivity rather than an SDNP address.
(439) Another aspect of SDNP based HyperSecure Last communication, is that any SDNP client is intrinsically capable of authentication and identity verification. Privacy features, therefore are not based on the network's ability to achieve privacy to support AAA, but whether not the client software or firmware are designed to facilitate the verification process. Because any HyperSecure Last Mile is identity verification capable, it should be understood that the following HyperSecure Last Mile examples apply both to private and non-private secure communication. So unlike unsecure last mile networks with quasi-privacy features, private communication over a HyperSecure Last Mile is determined by the SDNP client, not the network, and capable of supporting any degree of single-factor or multi-factor authentication procedure desired by the client.
(440) Specific examples of HyperSecure calls are shown in several examples to follow. In
(441) This zone-specific SDNP payload is next wrapped in an IP datagram packet with an IP header containing last mile network specific IP addresses, either NAT or Internet addresses, to facilitate packet routing between SDNP gateway 1201A and the communicating devices, i.e. tablet 33 and cell phone 32 acting as SDNP clients. Because the intermediate devices in Last Mile routing are not SDNP clients, the construction of the SDNP payload within IP datagram B remains fixed as it travels across the Last Mile. In other words, data packets 1223B, 1223C, and 1223D are identically constructed datagrams, all comprising SDNP datagram B with identical SDNP payloads—payloads that do not change as the packets hops from device to device along the Last Mile. Simply summarized, only an SDNP network node or an SDNP client can reconstruct an SDNP payload embedded in a Level 3 datagram, whether an IP datagram or a SDNP datagram.
(442) As shown, data packet 1223B comprising IP datagram B is carried by NSP operated wired or fiber link 24 to network router 27, followed by data packet 1223C also comprising IP datagram B carried by ISP operated wired or fiber link 24A to WiFi router 26. WiFi router 26 then facilitates Last Link communication using data packet 1223D comprising IP datagram B over WiFi link 29 with mobile devices such as cell phone 32 and tablet 33, both running SDNP app 1335A. As such, these devices function as a SDNP client capable of interpreting the data contained within data packet 1223D comprising IP datagram B, including decrypting, de-junking, unscrambling and mixing the payload's content with data fragments from other data packets to recreate the original message or sound.
(443) In
(444) As in the previous example, because the intermediate devices in Last Mile routing are not SDNP clients, the construction of the SDNP payload within IP datagram B remains fixed as it travels across the Last Mile. In other words, data packets 1223B, 1223C, and 1223D are identically constructed datagrams, all comprising SDNP datagram B with identical SDNP payloads—payloads that do not change as the packets hops from device to device along the Last Mile.
(445) In
(446) In
(447) As shown, cable CMTS 101 routes CMTS datagram C to cable modem 103, which in turn extracts the payload data packet 1223B comprising IP datagram B with the unaltered SDNP payload for Last Link delivery. The Last Link to SDNP client enabled devices may occur in several formats including over Ethernet 106A to desktop computer 36 running SDNP client app 1335C, or over copper twisted pair 7 to cordless phone 5A running SDNP client firmware 1335B. Cable CMTS 101 also routes CMTS datagram C to cable modem 103, which in turn extracts the original IP datagram, e.g. IP datagram B, and sends it and other video content to cable TV set top box over cable 106. Cable set top box then forwards IP datagram B and content via HDMI-2 107 to UHD interactive TV 39, running SDNP app 1335D. Alternatively SDNP firmware can be hosted by cable TV set top box 102.
(448) In
(449) The Last Leg in a home network comprises WiFi link 29 connecting cable (WiFi) modem router 26 to various home devices by data packet 1223D comprising IP datagram B wirelessly. To facilitate end-to-end HyperSecurity such devices must operate as an SDNP client either using software or firmware loaded onto the device. For example notebook 35 and desktop computer 36 operate as SDNP clients using computer app 1335C, cell phone 32 and tablet 33 operate as SDNP clients using mobile app 1335A. IoT devices, in this case refrigerator 34K are able to operate as an SDNP client if their control system is loaded with SDNP firmware 1335E. If however, such devices do not or cannot embed the SDNP client's software, end-to-end security must be achieved by other means.
(450) Identity-Paired Last Link Security—In cases when a connected device cannot act as an SDNP client, HyperSecurity cannot be guaranteed end-to-end. In such case, the use of a SDNP remote gateway can extend HyperSecure communication to cover the Last Mile of communication except for the Last Link. If the Last Link, the portion of the Last Mile connecting directly to a communication device, is not enabled as a SDNP host, then Last Link security must be insured through the local area network (LAN) used to facilitate Last Link communication.
(451) Between SDNP remote gateway 1350 and any connected device other than a SDNP client (such as desktop computer 36), communication is performed by a local area network or LAN connection such as Ethernet, WiFi or other protocols. Security is facilitated by LAN security protocols and device pairing between the communication device and the SDNP remote gateway. Device pairing is the process whereby an authentication sequence between two communicating devices establishes the identity of the two devices, preventing unauthorized access.
(452) In
(453) Since the SDNP connection and HyperSecure communication extends only to SDNP router 1351, the Last Link must rely on authentication and encryption to achieve security on wireline connections. For Ethernet such security can utilize any number of security methods (http://www.computerweekly.com/feature/iSCSI-security-Networking-and-security-options-available) including iSCSI operating on Layers 1 through Layer 3, such as virtual local area network operation or VLAN utilizing encryption among authenticated devices. Alternatively security can be achieved using Layer 4 to Layer 6 methods using the “IP Security” or IPSec framework. Originally developed for data storage and promoted by Cisco as an industry standard, IPSec offers two security modes. In the “Authentication Header” mode, the receiving device is able to authenticate the sender of data. In this mode, the data field is encrypted but the header uses a recognizable IP address. 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 can function properly and the packet can reach its correct network destination.
(454) In either case, security relies on authenticating devices to allow them to connect to the network. In home networks, e.g. personal networks connecting to computers, shared storage drives, IoT and other device connections, network-connected hardware does not change frequently. In such cases, authentication essentially involves a registration process of a device gaining access to a network or router. Rather than identifying a specific user's identity, this type of authentication is between devices, i.e. device-to-device, generally using some device tag, name, or ID number to identify and recognize the devices approved for connection. Establishing a network connection involves a setup phase when the devices are first introduced to one another and approved by the user for connection, followed by an automated authentication sequence each time a wireline device is physically connected to the other or for WiFi whenever the two devices come within range of one another. The setup phase, referred to herein as identity pairing, may also be referred to as device registration, device bonding, device pairing, pairing, or pair bonding. A similar process is used with devices to connect a Bluetooth headphone to a cell phone or to pair bond a Bluetooth cell phone to a car's hands free audio system. Protocols include challenge handshake authentication protocol or CHAP, Kerberos V5, Simple Public-Key Generic Security Services Application Programming Interface (GSSAPI), Secure Remote Password (SRP), and Remote Authentication Dial-In User Service (RADIUS). Some methods such as RADIUS rely on encryption methods that have been broken, but still are used in combination with other techniques.
(455) While Ethernet communication protects identity-paired devices such as Ethernet modem 103C, the output of the modem, comprising analog telephone signals conducted over copper twisted pair conductors 7 to cordless phone 5A and to desktop phone 37, the Last Link is not secure. Moreover, the communication format of cordless phone 5A is not secure and subject to interception and monitoring. For this reason, the use of home phones in secure communication is ill advised.
(456) The distribution of video content is another subject of interest in security. For example in the communication of SDNP router 1351 to HDTV 39, a video communication format such as High Definition Multimedia Interface (HDMI), DisplayPort (DP), Digital Visual Interface (DVI), and less popular Gigabit Video Interface (GVIF), or Unified Digital Interface (UDI) commonly comprises the physical connection to the HDTV or display monitor. Originally the security of this connection and its data was the concern of movie studios and content providers, with a focus on preventing the illegal copying and distribution of copyrighted material. One security protocol developed by Intel Corp. for maintaining security of the video link is High-bandwidth Digital Content Protection or 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 checks for authorization of the TV receiver or display before sending the content. DHCP therefore uses authentication to prevent non-licensed from receiving data, it encrypts data to prevent eavesdropping of information, and key revocation of compromised devices.
(457) With HDCP content flow from a modem to the TV can be secured by authentication, i.e. using identity pairing. With advent of smart TVs, however data flow is bidirectional. As a means to facilitate upstream data flow, i.e. from the TV to the modem or set top box, starting at revision 1.4, HDMI now embeds a high-speed bidirectional data channel known as HEC or HDMI Ethernet Channel. This data channel means HDMI connected devices can send and receive data via 100MC/sec Ethernet, making them ready for IP-base application such as IP-TV. The HDMI Ethernet Channel allows Internet-enabled HDMI devices to share an Internet connection via the HDMI link, with no need for a separate Ethernet cable. As such secure communication can be facilitated over HDMI using the same security protocols and identity pairing available in Ethernet.
(458) In
(459) Security between the SDNP gateway, i.e. SDNP WiFi router 1352, and the connected device is achieved using any number of industry standard protocols such as WiFi Protected Access WPA-II or WPA2 (IEEE 802.11i-2004) a replacement for the older WPA and its unsecure predecessor WPE. WPA2 communication is protected using CCMP, an acronym for Counter Mode Cipher Block Chaining Message Authentication Code Protocol based on AES processing with a 128-bit key and a 128-bit block size. CCMP provides data confidentiality, requires authentication, and sets access control. Authentication involves identity pairing at setup. Re-pairing must be performed manually. CCMP security, while good, is not HyperSecure, lacking anonymous data packets and dynamic nature of the SDNP communication provided from a SDNP client.
(460) In the
(461) Security between the SDNP gateway, i.e. SDNP WiFi router 1352, and the connected device is achieved using any number of industry standard protocols such as the aforementioned WiFi Protected Access protocol WPA2 using CCMP facilitating data confidentiality, requires authentication, and sets access control. WPA2 achieves security using identity pairing, device verification implemented as a Layer 2 protocol. The method is cumbersome involving manual authentication methods.
(462) An alternative protocol used for local area networks recently introduced for IoT communications—a proximal network called the AllJoyn framework. The framework discovers devices, creates sessions, and facilitates secure communication. The framework is designed to support IoT device connectivity using numerous Layer 2 transport layers, including WiFi, Ethernet, serial bus communication, and power line PLC. Applications may be based on C, C++, Obj. C, and Java operating on numerous platforms including Linux, Windows, MacOS, Android, iOS, RTOS real time operating system, and open source development environment Arduino.
(463) AllJoyn compliant applications authenticate one other and exchange encrypted data to enable end-to-end application level security. Authentication and data encryption are executed on application Layer 7. Transport layer 2, also referred to as the router layer, transmits security-related messages between application endpoints but does not implement any security logic itself. A callback function known as “Auth Listener”, also implemented on application Layer 7, facilitates authentication using PINs, passwords, or authentication certificates. Security is achieved using AES128 peer-to-peer encryption. Like WPA, AllJoyn employs identity pairing in an authentication process in advance of executing command and control sequences. Supported authentication methods include a pre-shared key or PSK, secure remote password (SRP) key exchange or logon with username and password. The protocol also supports ephemeral (elliptic curve Diffe-Hellman) key exchange (i) with no authentication, (ii) authenticated with a pre-exchanged key, and (iii) authenticated with an X.509 ECDSA certificate.
(464) The same technology can be applied to business enterprises. In the
(465) Unless additional security methods are implemented, this Last Link is insecure—especially for WiFi data packets that can be sniffed from a distance. Examples of WiFi connected IoT business devices include central heating and air conditioning 34D, lighting 34G, surveillance systems 34J, security systems 34H, POS terminals 38, and WiFi Hotspot connected devices such as tablet 33. Business enterprise wireline connected devices depend on the nature of the business. In banking, devices include Ethernet connected ATM machine 38D. In gas stations, devices include by example Ethernet connected gas pump 38A.
(466) In summary, Last Link can be secured with non-SDNP clients communicating with a SDNP remote gateway. In this manner the majority of the Last Mile is HyperSecure while the Last Link employs identity paired encrypted security.
(467) SDNP Bridge Communication—As described above, Last Mile data transport outside the SDNP cloud necessarily employs IP datagrams, i.e. data packets using Internet source and destination addresses, or alternatively using NAT addresses of the network operator. In case of private networks, e.g. those operating within office buildings, or in cooperation with local network service providers willing to host SDNP soft-switches on their servers, it is also possible to utilize SDNP datagrams to achieve HyperSecure communications on portions of Last Mile.
(468) As described previously, HyperSecure communication relies on servers to host SDNP soft-switch software or firmware and to communicate using SDNP datagrams and anonymous addresses, not with IP datagrams Within the SDNP cloud, these SDNP soft-switch enabled servers are referred to as SDNP nodes, as designated by the SDNP node notation M.sub.0,0, M.sub.0,1, M.sub.1,0, M.sub.1,1, etc. The above-referenced U.S. application Ser. No. 14/803,869 also disclosed communication between multiple independent SDNP clouds connected by SDNP bridges—SDNP gateways routing IP datagrams to other SDNP clouds.
(469) The concept of an SDNP bridge can similarly be adapted for portions of Last Mile communication. To create a SDNP sub-network or mini-cloud within the Last Mile, two or more servers must be enabled by SDNP bridge software or firmware. Unlike SDNP client software or firmware operating in an end device, i.e. in a calling device, SDNP bridge operation is used for routing data, not to operate as the final connection. As such, two or more adjacent SDNP bridges can operate as a standalone SDNP bridge network, SDNP mini-cloud or SDNP ad hoc network. The SDNP bridge function, as disclosed, represents a Layer 3 construct analogous to Layer 2 description of bridge mode operation of a WiFi router. Within the SDNP-bridge or SDNP bridge network, communication occurs using SDNP datagrams. Communication to the SDNP-bridge from outside the SDNP-bridge or SDNP bridge network uses IP datagrams with SDNP payloads.
(470) Operation of a SDNP bridge within Last Mile communication is exemplified in the schematic representation shown in
(471) Within the SDNP-bridge connection, i.e. between SDNP bridge router 1350 and WiFi-enabled SDNP bridge router 1352Z, HyperSecure communication occurs using SDNP datagram 1222B. SDNP routing information is extracted from the SDNP addressing contained within SDNP payload 1222A. Together, the SDNP-bridge and SDNP connection comprise a HyperSecure wireline leg of Last Mile communication, capable of supporting identity and account verification and supporting privacy.
(472) The connection from SDNP-bridge router 1352Z to the non-SDNP client device, i.e. notebook 35, utilizes IP datagram 1223B with an IP address and IP payload over a local area network, either WiFi or Ethernet. Security of this Last Link, albeit not HyperSecure, is secured by any of the aforementioned Ethernet and WiFi security protocols such as iSCSI, IPSec, WPA, AllJoyn, and others.
(473) Implementation of the SDNP bridge can occur between any two SDNP enabled devices carried by any number of physical media, meaning SDNP bridging is a Layer 3 protocol operating agnostically from Layer 1 PHY and Layer 2 Transport layer realizations. For example, in the topmost schematic shown in
(474) The SDNP-bridge can be extended to systems utilizing proprietary hardware, such as cable TV systems. For example the topmost schematic shown in
(475) The SDNP-bridge methods disclosed can also be used to transport data over radio networks. In the bottommost schematic of
(476) SDNP bridge communication can be adapted to automotive applications employing automobiles as a peer-to-peer ad hoc communication network. In the lower schematic of
(477) The concept of SDNP bridge networks is especially beneficial for communication over large geographies and in transportation and shipping involving cars, trucks, emergency vehicles, trains, airplanes, boats and ocean ships. In particular, to achieve wide area coverage for communication, satellite networks are required. The system typically involves network connectivity with the satellite operator referred to as a satellite bridge or backhaul, and the satellites link to its clients and subscribers also known as satellite distribution.
(478) Distribution of HyperSecure communication data packets to various clients from SDNP enabled satellite 93 comprises data packet 1222C and SDNP data packet-A containing a SDNP payload. Satellite communication is bidirectional, with the downlink from satellite 93 to terrestrial clients capable of a higher signal strength and faster data rate than the uplink connection. In other words, a satellite can transmit higher data rates and with stronger signal intensity to an earthly client than the client's response. Examples of satellite 93 links to subscribers include satellite link 95B to dish Internet subscriber 92G running SDNP firmware 1335T, to sat phone 92F running SDNP firmware 1335S, to satellite antenna array 92H sitting atop high speed train 1360C running SDNP firmware 1335G, to satellite antenna array 92E sitting atop ocean vessel 1360B running SDNP firmware 1335R, and to satellite antenna array 92D sitting atop aircraft 1360A running SDNP firmware 1335Q.
(479) In the case of large vehicles such as ships, aircraft, and trains, each system connects this HyperSecure satellite communication link to its own internal communication system or local area network.
(480) Ocean vessel satellite ship communication utilizes multiple bands of satellite communications including high altitude and near earth orbit satellites.
(481) Since Ku band satellite antenna 1383A is primarily used for distribution of TV and movie content, SDNP security is not generally required. Tracking and positioning is performed by antenna control 1383. Multi-channel data from satellite antenna 1383A is fed into L-band multiswitch 1381 separating signals into fixed video broadcast data routed to TV receivers and tuners 1382 and digital video broadcasting DVB data. Video content is fed into central communication servers 1380. If, however, secure communication is required, Ku band satellite antenna 1383A can be adapted to execute SDNP software.
(482) Data from low-earth-orbit satellite antennas 1383B and 1383C running corresponding SDNP firmware 1335U and 1335V relays information from the satellite antennas to central communication servers 1380 running SDNP software 1335Z. Within range of land, the communication system is also capable of communication using 4G/LTE cellular network 25 hosted by cellular base station 17 running SDNP firmware 1335N. Communications through servers 1380 are distributed throughout the ship using SDNP WiFi router 1362 running SDNP firmware 1335L. WiFi Hotspot communication of WiFi access point 26 is distributed throughout the ship using WiFi antennas 1361. Communication to SDNP clients such as cell phone 32 running SDNP app 1335 facilitates end-to-end HyperSecure communication. Devices not enabled as SDNP clients, must rely on identity pairing using WAP, AllJoyn, or other security protocols.
(483)
(484) The function of communication in automotive and in professional trucking is multifaceted involving Voice communication Navigation, maps, road information, alerts Entertainment, Hotspot services, infotainment Wireless payments, tolls Emergency services, roadside assistance Collision avoidance Dispatcher scheduling (professional, ridesharing)
(485) Additional functions are also required for autonomous vehicles, i.e. self-driving cars. Based primarily on older cellular networks such as a CDMA (2.5G) controlled central unit referred to as a “telematics” module, existing automotive systems have been shown to be extremely subject to hacking, cyber-assaults, and privacy attacks. To eliminate this vulnerability the entire network must be secured without significant expense, i.e. installing new network is not fiscally an option. Instead, the security infrastructure must be overlaid atop the hardware network as security methods deployed in Layer 3 through Layer 7. This strategy is compatible with the SDNP Last Mile implementations disclosed herein.
(486)
(487) As shown in
(488) Another important function in automotive communication is that of vehicle-to-vehicle communication also referred to as V2V communication. The purpose of V2V communication is primarily for collision avoidance. But in accordance with the disclosed SDNP methods herein, V2V communications can also function as a HyperSecure ad hoc peer-to-peer network. Such inter-vehicle SDNP communication is illustrated in
(489) In the case where a SNP client or gateway communicates with a non-SDNP device, communication occurs using IP datagrams. For example SDNP gateway 1201A converts SDNP datagram A with a SDNP payload into data packet 1223A comprising IP datagram B with an embedded SDNP payload. As shown, cellular base station 17 communicates to automobile 1390A over a 2.5G or 3G cellular link 28A using data packet 1223B containing IP datagram B with an embedded SDNP payload but is able to communicate to automobile 1390C over a 3.5G or 4G/LTE cellular link 28B using data packet 1223C also containing IP datagram B with an embedded SDNP payload. In this manner the SDNP payload is distributed independent of the network used to carry the data packets.
(490) Automobiles enabled with SDNP firmware 1335F may also form an ad hoc peer-to-peer SDNP bridge or bridge network. For example, automobile 1390A communicates with automobile 1390B over a V2V radio link 1391A using data packet 1222B containing SDNP datagram C rather than an IP datagram. Similarly, automobile 1390B communicates with automobile 1390C over a V2V radio link 1391B using data packet 1222C containing SDNP datagram D, and does not rely on IP datagrams. Regardless of the type of datagram employed, the embedded content remains HyperSecure using SDNP payloads.
(491) Another feature of the SDNP ad hoc V2V network is its ability to perform tunneling functions, i.e. passing data through one vehicle to another without the intervening car being able to monitor or interpret the data it is passing through. In the case where cellular link 28B fails because automobile 1390C is out of range, as an alternative path, cellular base station 17 can utilize the SDNP bridge network to reach the same caller, in the example shown through cellular link 28A, V2V radio link 1391A, and finally through V2V radio link 1391B. During data transport, data packets 1223B, 1222B and 1222C, change from IP datagram B to SDNP datagram C and finally to SDNP datagram D. Since the SDNP payload intended for automobile 1390C is uniquely created for the destination automobile, automobile 1390B and its occupants cannot hack or monitor the contents of SDNP datagram C even though are relaying data packet 1222B through the ad hoc network.
(492) Aside from conventional Last Mile communication, the same SDNP bridge technology can be used to send large amounts of data using HyperSecurity over long distances, i.e. digital trunk communication. Three such example are shown in
(493) In conclusion, the security and privacy features offered in Last Mile communication depend on the two communicating devices.
(494) In the bottom example SDNP gateway 1395 communicates openly with a non-SDNP client lacking any security provisions using data packet 1223C comprising an IP datagram with a sniffable IP address and an IP payload. As such the Last Mile connection is not secure and not private. In the example second from the bottom, SDNP gateway 1395 communicates with a non-SDNP client offering features of device authorization and identity pairing. Communication is by means of data packet 1223B comprising an IP datagram with a sniffable IP address but using an encrypted payload comprising ciphertext where only the identity-paired device can perform decryption. While the communication is not private or anonymous, it does offer enhanced security, at least for limited durations.
(495) The example next to the top illustrates that SDNP gateway 1395 can route communications through any bridge or router 1397 and still achieve HyperSecurity, provided that data packet 1223A comprises a SDNP payload within the IP datagram. The level of security achieved, depends only on the end device, not on the router. In the top example, communication between a SDNP gateway 1395 and a SDNP Client 1396 using data packets 1222 comprising SDNP datagrams with SDNP addressing, i.e. using source and destination addresses not recognizable by Internet DNS name servers, and using SDNP secured payloads, is HyperSecure, offering superior security, full privacy provisions, and anonymous packet routing.
(496) HyperSecure Last Mile Packet Routing—Independent of the Layer 1 physical hardware and Layer 2 data link algorithms and methods employed, routing of packets between an SDNP client or SDNP-bridge and the SDNP gateway relies on IP datagrams to carry and route the data packets across the Last Mile. Unlike data routing within the SDNP cloud directed by SDNP signaling servers, the SDNP cloud or its signaling servers do not control IP datagrams traversing the Last Mile. As such, some variability in Last Mile propagation delays is to be expected. Fortunately because the distances of Last Mile communication and the number of possible routes are limited, this uncertainty is small compared to the total end-to-end propagation delay of a global communication. Variation in total propagation delays because of Last Mile variability is estimated to be less than 10% of the aggregate delay.
(497)
(498) An alternative representation of the Last Mile network connection depicts each communication device as an IP stack representing the PHY, data link, and network connections as OSI Layers 1, 2, and 3. For example,
(499) In turn, router 1402A connects to router 1402B using Ethernet where the PHY Layer 1 physical connection and the corresponding data link Layer 2 of the WiFi router's IP stack 1412A connects to corresponding Layer 1 and Layer 2 in Ethernet router IP stack 1412B. Finally, router 1402B connects to SDNP gateway server 1401 using Ethernet where the PHY Layer 1 physical connection and the corresponding data link Layer 2 of the Ethernet router's IP stack 1412B connects to corresponding Layer 1 and Layer 2 in the gateway's IP stack 1422. In operation, routers carry data undisturbed, so that network Layer 3 IP datagrams, flow from one IP stack to another transparently, specifically from Layer 3 in IP stack 1411 to 1412A, 1412B and finally to 1422. In this manner, the network carries the IP datagrams as single route data across a virtual Last Mile connection 1409 even if the data physically passes through multiple devices
(500) In other words, Layer 3 network data flows through the Last Mile independent of the physical connections used to carry the IP datagrams, i.e. Layer 3 Last Mile communication operates agnostically to the underlying Layer 1 and Layer 2 implementations used for data transfer. This principle can by represented in simplified form by removing the intermediate nodes from the schematic as shown in
(501) Another consideration of Last Mile communication is that the payload of IP datagram 1405 contains all the information for upper OSI layers, including the transport Layer 4 data, session Layer 5 data, presentation Layer 6 data, and application Layer 7 data. Aside from Layer 4 data needed to select UDP or TCP transport protocols, the remaining data in the IP datagram's payload is specific to the disclosed SDNP communication and cannot be interpreted by routers operating along the last mile unless they themselves run SDNP software or firmware. Accordingly, only the end devices, i.e. the caller or SDNP client and the SDNP gateway, can interpret Last Mile communication even though the Last Mile network itself may comprise an amalgamate of different devices, carriers, and network operators.
(502) Although the SDNP payload is secured by numerous secrets including scrambling, fragmentation, junk data insertions and deletions, state dependent formatting, and dynamic encryption, the IP addresses of an IP datagram passing over a Last Mile network, necessarily reveal the source and destination addresses of the client's device 1400 and of the SDNP gateway server 1401. In order to provide a degree of anonymity over the Last Mile, address deception is beneficial, i.e. misdirecting cyber-attackers by dynamically changing the source and destination addresses in the IP datagram. IP deception can be accomplished by dynamically changing the IP address of the caller's connected device, herein referred to as “dynamic client addressing”, or by communicating with multiple SDNP gateways, i.e. multi-route Last Mile communication.
(503) The first method of IP address deception described involves dynamically altering the source address of sequential data packets. As shown in
(504) This method is illustrated using IP stacks in
(505) The IP datagrams 1405N sent to router device 1402A along network connection 1408 comprise a fixed destination IP address IP M.sub.0,0 and sequential source addresses IP C.sub.1,1, IP C.sub.1,2, IP C.sub.1,3, etc., represented in mathematical notation as IP C.sub.1,n where n=1, 2, 3, . . . uniquely identifying each sequential packet. Each sequential IP packet also includes a corresponding payload SDNP 1, SDNP 2, SDNP 3, and so on. Note that although this description refers to each IP address using mathematical shorthand notation IP C.sub.1,n, it is understood that the IP addresses comprise real IP addresses made in accordance with IPv4 or IPv6 international standards and exclude any reserved IP addresses.
(506) Another option to enhance security is to employ multiroute packet transport in the Last Mile. In a manner similar to data transport within the SDNP cloud, in multiroute Last Mile communication, audio and sequential data is parsed and fragmented, then divided into separate packets and addressed to different SDNP gateways. An example of multiroute data transport using static IP addresses is shown in
(507) In the path between the client device 1400 and one of the three gateways 1401A, 1401B or 1401C shown, the IP datagrams are routed through multiple Last Links 1404A, 1404B, and 1404C to multiple routers 1402A, 1402B, and 1402C. These routers may comprise (i) completely independent routers employing identical physical mediums such as WiFi or Ethernet, (ii) multiple router channels in a common hardware device, e.g. multiple trellis channels in a DOCSIS3 cable modem or (iii) different physical mediums for communication, e.g. one routed through WiFi, another through 3G, etc.
(508) For example,
(509) As shown, the PHY and data link between the client device 1400 and the routers 1402A, 1402D, and 1402C comprises a single medium, e.g. WiFi. Although the Last Link connections are represented as single lines splitting into three it should be understood that the physical connections are all made point-to-point and not by electrical Y connectors used to create parallel wires. Instead the depiction means the connections are to indicate the effect of the connection, i.e. the PHY layer of client IP stack 1411 expands one PHY connections into three, i.e. connecting to the PHY layer of IP stacks 1412A, 1412C, and 1412D. Functionally, this Last Link operates as a single output to three input expander where one client connects to three router functions, regardless of whether the router functions are contained into one common electronic apparatus or carved into distinct and separate routers. Note that, as shown, Last Link 1404 constitutes a single type of communication media—either cable, fiber, WiFi, Ethernet, or cellular.
(510) The remaining portions of the Last Mile however may comprise any media, not necessarily the same as the Last Link. An alternative Last Link involves multiple dissimilar PHY layers connecting to independent routers. Such an implementation, an IP stack executing multi-route last mile HyperSecure communication using static IP addresses over multiple PHY last links is illustrated in
(511) The combination of dynamic source addressing and multiroute data transport is illustrated in
(512) As such, each successive data packet contains changing SDNP payloads, employs dynamically changing source addresses, routed through different Last Links to unique SDNP gateways. In order to transport data over multiple Last Links, namely Last Links 1404A, 1404B, and 1404C, either a single router with multiple IP inputs such as a DOCSIS3 cable modem with trellis encoding, or over multiple forms of media, e.g. multiple bands of WiFi, combinations of radio and WiFi, or other combinations of wireline and wireless communication are used. In one example,
(513) The same multi-route approach can be combined with dynamic client addressing and multiple PHY last layers as shown in the IP stack depiction of
(514) In many cases, the Last Link comprises a single route, where beyond the first router multiroute data transport is employed. In
(515) In a similar manner, a second data packet 1405B comprises payload SDNP 2 with dynamic IP source address C.sub.1,2 and destination address M.sub.0,1. Data packet 1405B is routed over Last Link 1404 and through routers 1402A and 1402C to SDNP gateway 1401B. A third data packet 1405C comprises payload SDNP 3 with dynamic IP source address C.sub.1,3 and destination address M.sub.0,3. Data packet 1405C is successively routed over Last Link 1401 and through routers 1402A, 1402D and 1402E to SDNP gateway 1401C. As such, each successive data packet contains changing SDNP payloads, employs dynamically changing source addresses, routed through a common Last Links to unique SDNP gateways.
(516) This Last Mile connection is illustrated using IP stacks in
(517) Physical Realization of Last Mile Routing—Physical realization of the Last Mile may comprise communication over a variety of media, including Ethernet, WiFi, cellular, or DOCSIS3 enabled cable and fiber links. Regardless of the medium used, routing of data packets over the Last Mile is primarily controlled by three variables, namely, The media access control (MAC) addresses of communicating devices, The source IP address of the IP datagram, The destination IP address of the IP datagram.
(518) As such, MAC addresses control the physical media used to perform each hop in the Last Mile communication, i.e. Layer 1 and Layer 2 information, while the IP addresses identity the client device and the SDNP gateway, i.e. the devices at the two ends of the Last Mile. Although the payload used in HyperSecure communication follows the protocols defined in accordance with the secure dynamic communication network and protocol, intermediate devices in the Last Mile, i.e., routers and other devices on the route of a packet between the client device and the gateway, are generally not enabled to execute SDNP functions because of the lack of SDNP executable code in such devices. Therefore, the SDNP payload has no bearing on the routing of Last Mile HyperSecure data packets.
(519) One example is the use of Ethernet for Last Mile communication. Adapting the Ethernet data packet described previously in
(520) IP header 434 varies depending on whether the IP datagram follows the IPv4 or IPv6 protocol as determined by protocol field 447 comprising binary 4 or protocol field 448 comprising binary 6. Preambles 440 and 444 both contain a transport header flag 470 used to determine the Layer 4 transport method employed, e.g. TCP, UDP or the maintenance functions ICMP and IGMP. Specifically, in accordance with the secure dynamic communication network and protocol, TCP transport is employed for software and data files, while UDP is employed for real time data such as VoIP and video. The length and format of the transport header 436 varies in accordance with transport header 470. IP header 434 contains IPv4 source and destination addresses 441 and 442 or IPv6 source and destination addresses 445 and 446.
(521) Last Mile routing of Ethernet packets depends both on the IP addresses and the MAC addresses, represented by exemplary names of the devices to which the IP or MAC address refer to, e.g. MAC C.sub.1,1 or IP M.sub.0,0. The symbolic names, representing a numeric address made in accordance with the Ethernet formatted Internet protocol, are used in lieu of numerical addresses for the sake of clarity. Note that IP address IP C.sub.1,1 follows different formats and employs a different number of bytes for IPv4 and IPv6 names. Moreover the format for the MAC address varies with the Layer 2 data link protocol employed. As such, the MAC address MAC C.sub.1,1 for cellular radio is not the same as the MAC address for the same device communicating using WiFi or Ethernet. MAC addresses have no relationship to IP addresses, i.e. the IP address and MAC address for the same client have no relationship.
(522) Sequential Last Mile routing of Ethernet packets is shown in the examples of
(523) Unlike in the SDNP cloud where packet routing of SDNP datagrams is completely controlled by the SDNP network, in Last Mile communication using IP datagrams, the SDNP payload cannot be interpreted or affect routing, meaning each communication transported across the Last Mile contains fixed source and destination IP addresses. The physical media or channels used to direct the Ethernet packets is governed by the MAC addresses connecting each communication node in the Last Mile. For example,
(524) In the reply communication from SDNP gateway 1401 to client 1400, SDNP payload G traverses the same network in reverse sequence, i.e. where the source and destination addresses are swapped. As shown in
(525) One convenient means to represent Last Mile communication from an SDNP client is by utilizing “abridged” data packets containing data fields containing source and destination MAC addresses, source and destination IP addresses, and the SDNP payload. The abbreviated form is convenient for illustrating data flow in any communication “session”, i.e. the constructing of successive data packets transmitted across the Last Mile to the SDNP gateway, and the responses thereto. For example, successive Ethernet packets (shown in abridged form) sent from a SDNP client to the SDNP gateway is illustrated in the top portion of
(526) To facilitate Layer 2 interconnection among each communication node to its neighbors, the MAC addresses in different segments of the Last Mile necessarily change. As shown, all successive packets traveling across the Last Link from the client to the router employ source and destination MAC addresses MAC C.sub.1,1 and MAC R. Since a single MAC address is used for the client in successive data packets, the Last Link comprises a single physical medium, i.e. a single-PHY Last Link. Transport over the gateway link employs source and destination MAC addresses MAC R and MAC M.sub.0,0 respectively.
(527) So although the data packet shown encloses a SDNP payload, routing over the Last Mile necessarily uses sniffable MAC and IP addresses—addresses that can be interpreted by monitored by unauthorized listeners. By tracking packets with identical source and destination IP addresses an unauthorized listener can deduce that the data packets are likely part of the same conversation or session and even though they cannot open the SDNP payload, they can still gather metadata such as call times, files sizes, data rates, etc. to develop a profile of the caller. Moreover, by following the MAC and IP addresses, metaphorically like a trail of breadcrumbs, a hacker can potentially trace a call's origin to the end device, i.e. the client device, and thereafter personally identify the caller.
(528) As disclosed herein, a superior way to prevent client device tracing, obfuscate related call packets, and inhibit the gathering of metadata is to dynamically change MAC and IP addresses in Last Mile and Last Link communication. These inventive methods of deception include: Sending data packets over changing communication mediums by dynamically changing the Last Link MAC addresses, referred to herein as “multi-PHY Last Link” communication, Disguising the caller by dynamically changing the identity of the client device's IP address, referred to as “dynamic client addressing”, Changing the communication path of successive data packets over the Last Mile by dynamically changing the IP address of communication to and from different SDNP gateway IP addresses, referred to herein as “multi-route Last Mile” communication.
(529) The combination of multi-PHY, dynamic client addressing, and multi-route Last Mile communication renders tracking and tracing of Last Mile and Last Link Communication extremely challenging because only the SDNP caller and the SDNP gateway know which packets are part of the same call or session. These methods can be used separately or in combination.
(530) For example, the lower half of
(531) In order to execute multi-PHY Last Link communication, i.e. to route data in the Last Link over multiple physical mediums, the MAC address of the SDNP client must be dynamically changed in sequential data packets. Each MAC address corresponds to a specific PHY layer, e.g. Ethernet 100BASE-T and 1000BASE-T connections. In the case of three physical mediums, the client's MAC address is dynamically changed successively packets from MAC C.sub.1,1 to MAC C.sub.1,2, then to MAC C.sub.1,3. If only two mediums are available, the MAC addresses can be varied in a random pattern to avoid pattern recognition, such as MAC C.sub.1,1, MAC C.sub.1,2, MAC C.sub.1,2, MAC C.sub.1,1, MAC C.sub.1,2, MAC C.sub.1,1, MAC C.sub.1,2, MAC C.sub.1,1, . . . . While the source MAC address is varied, the MAC destination for the Last Link may remains constant, i.e. as MAC R. Since all of the Last Link's multi-PHY paths terminate in the same router, the data path through the remainder of the Last Mile remains fixed as a single route communication. In other words, even though the Last Link utilizes a multi-PHY connection, the Last Mile enters the SDNP cloud through a single gateway and the Last Mile comprises single-route communication.
(532) Although the multi-PHY approach provides a degree of deception, packet sniffing data packets from the specific call can still be identified because they share a common client IP address. This method of detection is thwarted using dynamic client addressing—an operation where the client changes its IP address with each packet it sends. As an example,
(533) As shown, in dynamic client addressing data packets carrying SDNP payload A employ a dynamically selected source IP address 441 comprising IP C.sub.1,1, while data packets carrying SDNP payload B employ a dynamically selected source IP address comprising IP C.sub.1,2, data packets carrying SDNP payload C use a dynamically selected source IP address comprising IP C.sub.1,3 and so on. The number of dynamically selected addresses is nearly unlimited, especially in IPv6. Moreover, IP addresses may be reused so long that some time, e.g. 1 second, transpires before the address is recycled. In the case of dynamic client addresses with a single-PHY Last Link, the value of the source MAC address 183 remains constant, in this example at MAC C.sub.1,1, even though the IP source address changes. In the case of dynamic client addresses with a multi-PHY Last Link, the value of the source MAC address 183 varies successively, changing from MAC C.sub.1,1 to MAC C.sub.1,2 and then to MAC C.sub.1,3. There is no particular mathematical correspondence between the client's changing MAC address and its dynamic IP address.
(534) Although dynamic client addressing appears to comprise messages sent from different users, the data packets still traverse most of the Last Mile (other than the Last Link in multi-PHY implementations) over a single route. A more advanced method to confound packing sniffing of Last Mile communication is to employ “multi-route” communication. In multi-route communication more than one SDNP gateway IP address is employed to connect the client to the SDNP cloud. Because SDNP network routing is prescribed by signaling servers and uses identifying SDNP tags on each packet, the SDNP cloud is able to route packets to a destination regardless of whether the data enters the SDNP cloud through a single gateway or through multiple gateways.
(535) The most effective degree of deception is to combine dynamic client addressing with multi-route Last Mile communication. This novel combination of security features is shown in
(536) Last Mile deception as described previously represents ten different cases as summarized in the table of
(537) The operation of the single-route Last Mile communication is shown topologically in
(538) In the case of the static client addressing over a single-PHY Last link shown in the upper left corner, each successive packet takes the same path over the entire Last Mile using unchanging IP addresses. In the case of the static client addressing over a multi-PHY Last link shown in the lower left corner, each successive packet takes a different path over the Last Link as prescribed by dynamically changing MAC addresses. The remainder of the Last Mile comprises a single route as specified by unchanging IP addresses. Despite the single route transport, changing the physical media of the Last Link makes caller tracing more difficult. In the case of the dynamic client addressing over a single-PHY Last link, shown in the upper right corner, each successive packet takes the same path over the entire Last Mile using an unchanging destination IP address and a constant client MAC address for the Last Link. Deception is instead achieved by changing the identity of the client by means of changes in the dynamic source IP address. In the case of single route communication with both dynamic client addressing and a multi-PHY Last Link, shown in the lower right corner, the client's MAC address and source IP address change dynamically and randomly even though all packets are routed to a single SDNP gateway.
(539) Dynamic client addressing is the process whereby a client device employs one or more temporary ad hoc IP addresses. The process involves two stages. In the first stage, when a device first logs on to a network it registers its presence on the local subnet by contacting the nearest router. The router then redirects the connection to the nearest DHCP server on the same subnet. DHCP, an acronym for dynamic host configuration protocol (DHCP) is a network management protocol used to dynamically assign IP addresses. In the registration process, the client device downloads one or more IP addresses and stores the addresses in its communication data register. Until such time that the assigned IP addresses are renewed by the local DHCP server, either by starting a new session or requesting new addresses, whenever the client device communicates it uses these IP addresses. Because the addresses are dynamically issued within a specific subnet, the client device's IP addresses are not Internet addresses.
(540) In the second stage when the client device either places a call or logs onto the SDNP network, the device automatically contacts the SDNP signaling server based on a static IP address of the SDNP server. The SDNP server upon receiving the incoming message uploads the ad hoc IP address or addresses to the SDNP name server. The SDNP name server then assigns SDNP addresses as pseudo-code for each of the temporary IP addresses. In operation, just before routing the packet's SDNP source address is substituted by its local ad hoc IP address. In the case of SDNP dynamic addressing, the identity of the client device is camouflaged, by repeatedly sending packets with changing source addresses. In this manner, dynamic deception obscures the true identity of the client device.
(541) Upon reaching a SDNP gateway, the source addresses for outgoing packets discard the client IP addresses and substitute the SDNP address of the gateway server instead. Each outgoing SDNP packet then swaps the local IP address of the device with its local ad hoc IP address just prior to transport. Unlike Internet packet transport where the source and destination IP addresses remain constant and are required for replies, in SDNP transport each hop uses new IP addresses. So when a 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 for replies.
(542) The operation of “multi-route” Last Mile communication is shown topologically in
(543) The lower left corner example uses a multi-PHY connection for the Last Link, meaning the MAC address for the client changes dynamically. Such an approach compensates for the fact that the identity of the client maintains a static IP address. As part of end-to-end multi-route Last Mile communication, each unique Last Link connects to separate routers on successive packets' journeys to distinct SDNP gateways. As such, a first packet is routed from a client with static address IP C.sub.1,1 to the router with MAC address MAC R.sub.1 over a unique PHY medium before finally being routed to SDNP gateway with IP address IP M.sub.0,0. A second packet the identical client address IP C.sub.1,1 is routed to a different router with media address MAC R.sub.2 over a unique PHY medium before finally being routed to SDNP gateway with IP address IP M.sub.0,1. Similarly a third packet also with static client IP address C.sub.1,1 is routed to a router with a media address MAC R.sub.3 over a unique PHY medium where it is subsequently routed to SDNP gateway M.sub.0,3. The use of multiple routers opportunistically uses the multiple PHY Last Link to deliver Last Mile packet in entirely separate trajectories despite utilizing a client with a singular source IP address.
(544) In another embodiment shown in the upper right corner, the identity of the client changes dynamically even though only a single MAC address and PHY connection is used. The IP address of the client shown dynamically changes from IP C.sub.1,1 to IP C.sub.1,2 to IP C.sub.1,3 while the physical medium remains constant with a source media address MAC C.sub.1,1 and a destination address MAC R. The data is then routed onward to gateways M.sub.0,0, M.sub.0,1, and M.sub.0,3 in random order as determined by the SDNP signaling servers.
(545) Superior security is achieved by combining all three methods of Last Mile deception, namely multiple route communication using a multi-PHY Last Link and dynamic client addressing. This case is illustrated in the lower right hand corner of
(546) Camouflaging of the client device IP address and obfuscation of last mile routing by dynamic IP addressing, multi-PHY transport and multi-route transport to multiple gateways can be determined either by the client device or by the signaling server. The misdirection process can be achieved using random number generation or other pseudo-random algorithms. A key principle is that the routing and transport changes are unpredictable.
(547) Two slightly less robust versions of Last Mile data transport of Ethernet packets over multiple routes are shown in
(548) As an adjunct to Ethernet, WiFi wireless communication also can be employed for Last Mile communication between a SDNP client and a SDNP gateway. WiFi communication requires a data packet with three or four MAC addresses, two for the radio link, one or two for the wired network connection, specifically using Ethernet data packets.
(549) Similar to Ethernet data packets, preamble 230 and start frame delimiter SFD 232 contain Layer 1 data for synchronizing the data and device. Physical layer convergence procedure PLCP 232 comprises a mix of Layer 1 and Layer 2 information (related packet length, data rates, error checking on the header, etc.). In accordance with IEEE 802.11 standards, the remaining data fields comprise Layer 2 data link information including Frame Control 233 specifying the WiFi version packet type as management, control, reserved, or “data”, the type used in delivering SDNP payloads.
(550) Duration & ID 234 contains the NAV duration unless the WiFi device is in power savings mode, in which case the field includes the station ID. NAV or network allocation vector is a virtual carrier-sensing mechanism used for power saving in wireless communication systems. The NAV duration can be considered as a counter, counting down to zero at a uniform rate, whereupon it senses the medium to determine if the radio is idle or still communicating. In idle mode, the counter counts the NAV duration repeatedly, checking to determine if any radio communication activity demanding attention is detected. Sequence control or “Sequence” field 238 describes the packet sequence and fragment number defining the Layer 2 packet frame. Frame check 240 contains a 32-bit CRC checksum of the entire data packet, i.e. a error check data link trailer.
(551) WiFi payload 241 is a OB to 2,312B long data field used to carry the WiFi payload. In SDNP Last Mile communication, this field contains the IP datagram used in Last Mile communication including IP header 434, transport-header 436 and SDNP payload 435.
(552) IP header 434 varies depending on whether the IP datagram follows the IPv4 or IPv6 protocol as determined by protocol field 447 comprising binary 4 or protocol field 448 comprising binary 6. Preambles 440 and 444 both contain a transport header flag 470 used to determine the Layer 4 transport method employed, e.g. TCP, UDP or the maintenance functions ICMP and IGMP. Specifically, in accordance with the secure dynamic communication network and protocol, TCP transport is employed for software and data files, while UDP is employed for real time data such as VoIP and video. The length and format of the transport header 436 varies in accordance with transport header flag 470. IP header 434 contains IPv4 source and destination addresses 441 and 442 or IPv6 source and destination addresses 445 and 446.
(553) Similar to Ethernet data packets, Last Mile routing of WiFi packets depends both on the IP addresses and the MAC addresses, represented symbolically by the names of the devices to which the IP or MAC address refer to. Sequential Last Mile routing of WiFi packets is shown in the examples of
(554) In the first step of the communication sequence, SDNP payload-A travels from SDNP client 1400 to WiFi base station/router 1402W over Last Link 1404 as WiFi radio medium, and by wireline onto router 1402X over BS link 1415. Router 1402X then delivers the data packet across gateway link 1414 to the SDNP gateway 1401. A response from the SDNP gateway to the client involves SDNP payload G traveling from SDNP gateway 1401 by wireline over gateway link 1414 to router 1402X, across BL link 1415 to WiFi router 1402W, and across Last Link 1404 to client 1400 using WiFi radio as the communication medium. SDNP client has numeric MAC and IP addresses MAC C.sub.1,1 and IP C.sub.1,1, WiFi router 1402W has numeric MAC address MAC W, router 1402A has numeric MAC addresses MAC R, and SDNP gateway has numeric MAC and IP addresses MAC M.sub.0,0 and IP M.sub.0,0. The IP addresses of WiFi router 1402W and wireline router 1402X are not required in the Last Mile communication shown.
(555) In contrast to the SDNP cloud, where packet routing of SDNP datagrams is completely controlled by the SDNP network, in Last Mile communication using IP datagrams, the SDNP payload cannot be interpreted or affect routing, meaning each communication transported across the Last Mile contains fixed source and destination IP addresses. The physical media or channels used to direct WiFi packets in radio communication and to direct Ethernet packets in wireline communication is governed by the MAC addresses connecting each communication node in the Last Mile.
(556) For example,
(557) Reply communication involves swapping destination and source IP addresses and adjusting the MAC addresses accordingly.
(558)
(559) Optionally, in multiroute communication over the Last Mile, the wireline router used for routing data packets received by the WiFi access point, i.e. in receive mode, may be different than the one used for routing data packets to be transmitted by the WiFi access point, i.e. in transmit mode. For example, the network MAC address 237 for radio packets in receiver mode may have a numeric MAC address MAC R.sub.1 while in transmit mode, the data may be changed to a different router connection MAC R.sub.2, meaning the BS link may optionally comprise a directionally dependent multi-PHY implementation. In transmit mode, Last Link WiFi packets used for single-PHY radio 1404 Last Link routing from WiFi router 1402W to SDNP client 1400 contain xmitter MAC address 236 with a numeric value MAC W and receiver MAC address 235 containing numeric value MAC C.sub.1,1. In this direction of data transmission, the wireline router 1402A acts as the source of data to be transmitted by the WiFi router device. As such, the WiFi data packet species two mediums, WiFi radio Last Link 1404, and Ethernet wireline BS link 1415.
(560) Cellular networks represent another form of wireless communication adaptable for SDNP Last Mile communication. Cellular networks re-partition incoming Ethernet packets into radio-specific media access control (MAC) packets. Data may be transmitted and received by multiplexing time (TDMA) in, by code division (CDMA), or by spreading the content across multiple sub-channel frequencies (OFDM). In the case of 4G/LTE communication based on OFDM or orthogonal frequency division multiplexing, the Layer 2 data packets are stacked across three different levels of embedded service data units or SDUs all within Layer 2; specifically the lowest level comprises the PHY PDU 299 containing the single frame MAC SDU 304 along with MAC header 303 and padding 305 spread across 20 time slots 300 comprising the PHY Layer 1 data. MAC SDU 304 in turn contains radio link control or RLC SDU 308.
(561) Radio link control (RLC) is a layer 2 protocol used in 3G (UMTS) and 4G/LTE (OFDM) based telephony. The function of radio link control is to react to upper layer requests in one of three modes, i.e. acknowledged mode, unacknowledged mode, and transparent mode, as well as to provide error detection, error correction, duplicate detection, and packetizing of data in accordance with specified formats. Packetizing of the data includes concatenation, segmentation, and reassembly of RLC SDUs along with reordering and re-segmentation of RLC data PDUs. For example, after allocating time for performing radio overhead functions, single frame RLC SDU 308 is unavoidably limited in the duration and data file size available for carrying a payload. Single frame RLC SDU 308 must therefore be split into segments and mapped into a different RLC Layer 2 format—multi-frame RLC SDUs 319.
(562) As illustrated in
(563) The multi-frame RLC SDUs 319 encapsulate PDCP PDUs 320 in a one-to-one correspondence with each K segment. For example, the K.sup.th segment 313 carries PDCP header 321A and an IP payload comprising data 323, the (K+1).sup.th segment 314 carries PDCP header 321B and an IP payload comprising data 324, the (K+2).sup.th segment 315 carries PDCP header 321C and an IP payload comprising data 325, and so on. The term PDCP is an acronym for Packet Data Convergence Protocol as specified in 3G and 4G/LTE communication protocol, performing functions such as compression, encryption, integrity assurance, as well as user and control data transfer. PDCP headers vary with the type of data being transported, e.g. user data, control data, etc.
(564) Since data transport in 4G data packets carry a continuously concatenated stream of data, payload size is not quantized into defined length blocks as they are in Ethernet and WiFi data packets. Instead data fields 323, 324, 325 . . . carried by corresponding Layer 2 data segments 313, 314, 315 . . . can incrementally support any size payload, as shown comprising IP header 434 and IP payload 435 containing transport-header 436 and SDNP payload 1430. Moreover, in OFDM-based communication each time slot concurrently carries data on multiple frequency subcarriers, meaning that the total data throughput is not simply determined by time duration over a single channel as it is in TDMA. For convenience, however, it is often convenient to maintain IP datagram size to match that of Ethernet or WiFi standards.
(565) As shown, IP header 434 varies depending on whether the IP datagram follows the IPv4 or IPv6 protocol as determined by protocol field 447 comprising binary 4 or protocol field 448 comprising binary 6. Preambles 440 and 444 both contain a transport header flag 470 used to determine the Layer 4 transport method employed, e.g. TCP, UDP or the maintenance functions ICMP and IGMP. Specifically, in accordance with the secure dynamic communication network and protocol, TCP transport is employed for software and data files, while UDP is employed for real time data such as VoIP and video. The length and format of the transport header 436 varies in accordance with transport header bit 470. IP header 434 contains IPv4 source and destination addresses 441 and 442 or IPv6 source and destination addresses 445 and 446.
(566) As an example of 4G communication using IPv6 datagrams,
(567)
(568) Multi-PHY communication over the Last Link may comprise any of the aforementioned media used in various combinations. Multi-PHY implementations may comprise multiple wireline connections carrying data at the identical or dissimilar data rates and employing common or distinct Layer 2 protocols such as USB, Ethernet 10BASE-T, 100BASE-T, 1000BASE-T, or DOCSIS3. Wireline physical media may comprise Ethernet or USB compliant network cables, coaxial cables, optical fiber, or even twisted-pair copper connections for DSL, albeit at a degraded level of performance.
(569) Wireless multi-PHY communication may include combinations of WiFi, cellular, satellite, or proprietary radio formats running in the radio frequency and microwave bands. Wireless Last Link communication may also include short-range technologies such as Bluetooth or micro-cellular networks such as PHS in Japan. Wireless protocols may include cellular formats for 2G, 2.5G, 3G, and 4G/LTE including for example analog, TDMA, GSM, CDMA, UMTS, and OFDM, WiFi protocols such 802.11a, 802.11b, 802.11g, 802.11n, and 802.11ac, as well as proprietary formats for satellite communication or custom radio links. Since Layer 2 protocols vary in accordance with Layer 1 physical mediums, the term multi-PHY communication as used in the context of this disclosure shall mean the combination of both OSI physical and data link layers, i.e. Layer 1 and Layer 2 together, and should not be construed as limiting claims to mean Layer 1 physical media exclusively.
(570) Examples of multi-PHY communication using a common Layer 2 protocol are shown in
(571) In the center example of multi-PHY WiFi, WiFi router 100 communicates to notebook 35 over two WiFi channels shown as WiFi links 29A and 29B, the former running 801.11n protocol over 2.4 GHz, and the latter using 802.11ac to communicate over a 5 GHz channel. In order to operate in multi-PHY mode, notebook 35 must be enabled to concurrently send and receive signals at multiple frequencies using a multi-band antenna 26B internal to the notebook. Similarly WiFi router must be capable of sending and receiving signals at multiple frequencies concurrently using multi-band antennas 26. To facilitate HyperSecure communication over the Last Mile, notebook 35 is shown running SDNP software 1335C.
(572) In the lower example showing multi-PHY cellular communication, cellular base station 17 communicates concurrently over multi-band cellular tower 18A to tablet 39 using two different radio channels comprising cellular links 28A and 28B with corresponding frequencies 1.8 GHz and 900 MHz. In the example shown, the cellular link comprises a 4G/LTE network. As shown, tablet 39 must be enabled to concurrently send and receive signals at multiple frequencies using an internal multi-band antenna 18B. To facilitate HyperSecure communication over the Last Mile, tablet 39 is shown running SDNP app 1335A.
(573) Such multi-PHY communication using a common Layer 2 protocol confounds cyber attacks because the hacker must gain physical access two different Layer 2 data links each of which may include their own security. Furthermore, provided the client is running SDNP software 1335C, SDNP app 1335A, or SDNP firmware 1335B (not shown), the routing of the SDNP payloads across the multi-PHY connections utilizes unique dynamic security credentials rendering real time SDNP packet interception and interpretation too demanding for real-time hacking.
(574) Examples of multi-PHY communication using mixed Layer 1 media and Layer 2 protocols are shown in
(575) In the middle schematic of a mixed-medium multi-PHY communication shown in
(576) A similar method to achieve multi-PHY Last Link communication combining cellular and satellite is shown in the bottom illustration of
(577)
(578) The bottom illustration represents a multi-PHY satellite network where satellite enabled cellular phone 32Z running SDNP app 1335A communicates to communication satellite 92 using multiple carrier bands 95Z formatted with a proprietary communication protocol. Communication between satellite 92 and terrestrial satellite antenna and base station 92B uses a trunk line protocol 95X mixing thousands of calls, making identification and interception of a specific call problematic for a hacker while use of multi-PHY communication over multiple bands in the client link 95Z insures HyperSecure communication for the client.
(579) Another example of the data packets used in multi-PHY Last Link routing is shown in
(580) The change in the source media address from MAC C.sub.1,1 to MAC C.sub.1,2 redirects Ethernet communication from the 2.6 GHz 100BASE-T connection to the 1000BASE-T connection. In operation, data packets from SDNP client device 1400 are fragmented and are then apportioned into SDNP payload A and SDNP payload B in accordance with SDNP algorithms and shared secrets. Fragmented data transport across the multi-PHY Last Link occurs with SDNP payload A carried by Ethernet packet A across wired or fiber link 24A and SDNP payload B carried by Ethernet packet B on wired or fiber link 24B.
(581) Another example of the data packets used in multi-PHY Last Link routing is shown in
(582) The change in the source media address from MAC C.sub.1,1 to MAC C.sub.1,2 redirects the transmission from the 2.6 GHz WiFi radio to the 5 GHz transceiver. In operation, data packets from SDNP client device 1400 are fragmented and then apportioned into SDNP payload A and SDNP payload B in accordance with SDNP algorithms and shared secrets. Fragmented data transport across the multi-PHY Last Link occurs with SDNP payload A carried by WiFi packet A across WiFi link 29A and SDNP payload B carried by WiFi packet B on WiFi link 29B.
(583) Yet another example of the data packets used in multi-PHY Last Link routing is shown in
(584) The change in the source media address from MAC C.sub.1,1 to MAC C.sub.1,2 redirects the transmission from the 1.8 GHz 4G/LTE cellular radio to 900 MHz. In operation, data packets from SDNP client device 1400 are fragmented then apportioned into SDNP payload A and SDNP payload B in accordance with SDNP algorithms and shared secrets. Fragmented data transport across the multi-PHY Last Link occurs with SDNP payload A carried by cellular packet A across WiFi link 28A and SDNP payload B carried by cellular packet B on WiFi link 28B.
(585) As described previously, multi-PHY communication can also comprise dissimilar media. In such cases, the data packet for each connection must be formatted in accordance with the Layer 2 protocols for the corresponding physical media. For example,
(586) The change in the source media address from MAC C.sub.1,1 to MAC C.sub.1,2 redirects the transmission from the Ethernet to WiFi. In operation, data packets from SDNP client device 1400 are fragmented then apportioned into SDNP payload A and SDNP payload B in accordance with SDNP algorithms and shared secrets. Fragmented data transport across the multi-PHY Last Link occurs with SDNP payload A carried by Ethernet packet A across wired or fiber link 24A and SDNP payload B carried by WiFi packet B on WiFi link 29B.
(587)
(588) The change in the source media address from MAC C.sub.1,1 to MAC C.sub.1,2 redirects the transmission from the WiFi LAN to a cellular network. In operation, data packets from SDNP client device 1400 are fragmented then apportioned into SDNP payload A and SDNP payload B in accordance with SDNP algorithms and shared secrets. Fragmented data transport across the multi-PHY Last Link occurs with SDNP payload A carried by WiFi packet A across WiFi link 29A and SDNP payload B carried by cellular packet B on cellular link 28B.
(589) Another form of multi-PHY communication involves physical mediums capable of supporting many channels at different frequencies and using distinct protocols for different data packets. Such an implementation can be facilitated using a DOCSIS3-based cable distribution system executing SDNP software. The OSI communication stack for a SDNP enabled DOCSIS3 cable distribution system is illustrated in
(590) The Layer 1 PHY cable interface 362 then sends the data frames over distribution network 102 comprising either coaxial cable 104 or optical fiber 91 to the corresponding Layer 1 PHY cable interface 363 within cable modem CM 103 or set top box STB 102. Cable interface 363 represents the PHY layer of the cable network interface shown as OSI communication stack 379 of cable modem CM 103 or set top box STB 102. Upon receiving a data packet, cable MAC interface 371 then interprets the cable MAC addresses, passing its payload to link security 372 for decryption and ultimately to hardware independent link layer control 802.2 LLC 373 for interpretation. The input data to the CM or STB cable network communication stack is then passed through transparent bridging 374 to the CM or STB device interface communication stack, specifically to device independent link layer control 802.2 LLC 375 in accordance with the specification for IEEE 802.2. The packet is then passed to either HSD & IPTV MAC block 376 or to WiFi 802.11 MAC block 377 to update the packet's MAC addresses. In the case of WiFi communication, the data packet is then passed from 802.11 MAC block 377 to WiFi PHY Layer 1 radio interface 365 for transmission on WiFi antenna 26. In the case of wireline connections, the data packet is then passed from HSD & IPTV MAC block 376 to Ethernet or HDMI interface block 364 for connecting to TV 39 or desktop 36.
(591) The PHY and data link layer as described establish connections from a CMTS to any number of cable modems (CMs). Within CMTS communication stack 378 and within CM communication stack 379, data packets are prepared within OSI Layer 3 layers 360A and 360B, respectively, as IP datagrams IPv4, IPv6 or ICMPv6 using IP addresses recognized by the cable network or by the Internet's DNS name servers. In Last Mile communication SDNP datagrams using IPv4 or IPv6 data packets with SDNP source and destination IP address are generally not used because connected devices not enabled by SDNP software or firmware have no ability to interpret the SDNP datagram routing addresses.
(592) Transport Layer 4 operation within the cable modem network varies by device. In the case of CMTS 101, Layer 4 transport layer 1420 of OSI communication stack 378 exclusively employs UDP because its operation necessitates real time communication, e.g. the streaming of video data. From this perspective, cable communication 102 is more like the SDNP real time network than the Internet is. Because the cable modem has interoperability with both the Internet and the cable network as a client, i.e. end communication device, Layer 4 transport layer 1420B in OSI communication stack 379 of CM 103 or STB 102 uses UDP for real time operations and employs TCP for Internet data. Such use is problematic for OTT carriers using VoIP over the Internet, as the cable network will interpret the IP datagrams as data, automatically employing TCP and the transport protocol and degrading real time communication QoS, latency, and propagation delay. This issue does not arise in SDNP enabled cable modems—in cases where the CM or STB is operating SDNP firmware or software, the SDNP software contextually decides when the use of TCP is warranted (for software and files) and when it is not, i.e. for real time data.
(593) The application layers, namely OSI Layer 5 through Layer 7, sit atop Layer transport operations 1420A in CMTS 101 and atop transport layer 1420B in CM 103 or STB 102. In CMTS 101 these applications typically involve communication tasks such as SNMP 1431A, Internet-standard protocol for collecting and organizing information connected devices on IP networks. Other functions include DHCPv4 1432A and DHCPv6 1433A. DHCP, an acronym for dynamic host configuration protocol is a protocol for both clients and servers to automatically supply an IP host with necessary routing information including dynamically generated (non static) IP address, default gateway and subnet mask. Although Internet generation specific, i.e. for IPv4 or IPv6, the function of dynamic IP address generation, like a NAT gateway or SNMP, is generic and equally applicable in DOCSIS3 cable systems for both CMTS 101 and CM 103 or STB 102.
(594) The application layer implementation of the secure dynamic communication network and protocol disclosed herein, when realized as SDNP firmware 1430A running atop the CMTS 101 operating system can perform any number of unique tasks including: Operating as a pass-through without interpreting the SDNP payload 1430 in which case CM 103 must be enabled to open and read the SDNP payload, i.e. CM 103 must be a SDNP client. Operating as a Last Mile remote SDNP gateway, i.e. interpreting the contents of a SDNP payload and converting the contents to a DOCSIS3 specific message (including link security) for forwarding to CM 103. In such cases CM 103 need not be running SDNP client software or firmware. Operating as a Last Mile SDNP bridge, converting IP datagrams to SDNP datagrams, and communicating the SDNP datagrams to CM 103. In such cases, CM 103 must be running SDNP client software or firmware to connect to the SDNP-bridge, i.e. forming an ad hoc SDNP “floating” network.
(595) As shown, OSI communication stack 379 for CM 103 and STB 102 includes numerous applications classified as OSI Layer 5 through Layer 7 including the aforementioned communication related apps SNMP 1431B, DHCPv4 1432B, and DHCPv6 1433B. Another function, the utility TFTP 1434B or “trivial file transfer protocol” is primarily used in DOCSIS3 as a means to download software and software updates from the CMTS to cable modems and set top boxes throughout the cable network. In cable networks, the HTTP 1435B or hypertext transfer protocol is primarily for painting dynamic menus useful in smart TVs. Other applications (labeled by the shorthand notation “Otr” 1436B) include gaming apps, diagnostics, IPTV apps, video recording functions, and more. SDNP firmware 1430B running on CM 103 or STB 102 extends, HyperSecure Last Mile communication all the way to the user and Last Link regardless whether CMTS 101 is running SDNP software or not.
(596)
(597) Short codeword 394 contains payload 395A comprising data A and error correction 396A containing FEC A. In the event of long codeword 397, the payload is divided into multiple payload blocks 395A, 395B, and 395C carrying data A, data B, and data C, respectively, with each payload containing its own error checking blocks 396A, 396B, and 396C including corresponding data FEC A, FEC B, and FEC C. After error checking, the delivered data from DOCSIS3 comprises data blocks 395A, 395B and 395C in the case of a long codeword and only data block 395A in the case of a short codeword. The combination of data A, data B, and data C merge into a contiguous IP datagram, in this example an IPv6 datagram, containing IP source address 445, IP destination address 446 and data field 435 containing SDNP payload 1430 and transport header 436 containing Layer 4 data. In this manner DOCSIS3 flexibly delivers data over a cable network using packet-switched data protocol.
(598) As shown in
(599) OFDM is preferred to QAM modulation methods because the channels can be more tightly spaced. Comparing modulation schemes, QAM frequency distribution 1445A exhibits a wider tail in spectral content than OFDM frequency distribution 1445B. Specifically, the spectral sideband width from f.sub.0 to f.sub.−50, i.e. the width from the carrier edge to the frequency where the signal drops by −50 dB, is 4.3 normalized frequency units wide in QAM frequency distribution 1445A, but only 0.4 normalized frequency units wide in the case of OFDM frequency distribution 1445B. Because the spectral width is narrower, more communication channels can be packed into the same spectrum increasing the overall bandwidth and the maximum total data rate of the network. In phase 2 deployment of DOCSIS 3.1, the frequency range is extended to 1,794 MHz. Many of the bands originally assigned for QAM data 1441 are replaced by new channels assigned explicitly for OFDM data 1442.
(600) In a DOCSIS-enabled cable network, one CMTS unit supports many CMs managing the available channels. Although the CMTS can allocate downstream communication and channel selection dynamically as needed, upstream communication requires contention management to facilitate the case where multiple CMs attempt to send data concurrently. As such, each modem must request an uplink channel from the CMTS before sending data. This process is shown in
(601) After receiving no response, a second RQST 1445B is sent resulting in a reply from CMTS 101 on a different channel, in the form of MAP data packet 1446. The contents of MAP data packet 1446 instruct CM103 when to transmit and what channels it can use for its upstream communication. After receiving the MAP data packet 1446, CM 103 sends its upstream data concurrently spread over two channels in uplink data packets 1447A and 1447B. The splitting of data sent concurrently over two channels shown in the center illustration is referred to a channel bonding. Channel bonding is a means by which communication bandwidth and data rate between the CMTS and CM can be increased. It is also a dynamic method to insure no available bandwidth goes unused. In the bottom illustration, CMTS 101 replies by channel bonding four channels, namely 1448A, 1448B, 1448C, and 1448D and sending data concurrently but of differing durations.
(602) In both upstream and downstream communication across the hybrid fiber-cable network, bandwidth is allocated dynamically among multiple channels, divided into small time segments referred to as “minislots”.
(603) For Last Link communication, upstream data packet 1450A specifies “MAC CM1” as the cable modem's source MAC address and specifies the PHY medium, in this case the channel on frequency f.sub.1 as the MAC destination “MAC CMTS1”. Data packet 1450A containing SDNP payload A occupies three minislots in total, namely minislots 1, 2, and 3 even though together they carry a single data packet and payload. In contrast, minislot-4 and minislot-5 each contain only a single data packet each, i.e. 1450B and 1450C with corresponding data SDNP payload B and SDNP payload C. Like data packet 1450A, both packets 1450B and 1450C specify a destination IP address of the SDNP cloud, specifically SDNP gateway node M.sub.0,0.
(604) For the MAC destination address, however, rather than specifying the same MAC address and physical media as the first packet, both packets 1450B and 1450C stipulate a MAC destination address of “MAC CMTS2”. This address can be used to specify that the data packets 1450B and 1450C should be carried on a different frequency than data packet 1450A—in this case frequency f.sub.2, not frequency f.sub.1. The actual values of the frequencies are dynamically mapped by CMTS 101 and not specifically identified. A DOCSIS3 enabled system thereby represents a multi-PHY solution whereby a single CMTS unit can communicate concurrently to a cable modem or set top box over multiple frequencies and using multiple protocols such as 256 QAM or OFDM.
(605) Rather than allowing the CM and CMTS to determine which data packets use a common carrier channel or frequency as is the normal case for DOCSIS3 systems, in accordance with the disclosed secure dynamic communication network and protocol for Last Mile communication, the SDNP client CM 103 specifies different MAC destination addresses to force communication over multiple frequencies and channels, i.e. to force multi-PHY operation. Because CM 103 data packets 1450A and 1450B/C stipulate different destination MAC addresses, namely MAC CMTS1 and MAC CMTS2 respectively, the data packets automatically invoke multi-PHY operation over the Last Link. Alternatively if the CMTS facilitates another means by which to request unique channel allocation, e.g. using a command and control request, then the use of the MAC address to invoke multi-PHY communication may be substituted by the alternate means.
(606)
(607) HyperSecure Call Routing—HyperSecure call routing made in accordance with the disclosed secure dynamic communication network and protocol may be performed using one of three methods for command and control Tri-channel communication, where routing of a call or communiqué is controlled using three sets of servers, namely the SDNP media servers for carrying audio, video, or data files; the SDNP signaling servers for selecting the routing of a call, and a SDNP name server for storing the dynamic mapping of phone numbers to their corresponding SDNP addresses, Dual-channel communication, where routing control of a call or communiqué uses two sets of servers, namely the SDNP media servers for carrying audio, video, or data files; and the SDNP signaling servers for routing the call, and for performing the function of a SDNP name server mapping of phone numbers to their corresponding SDNP addresses, Single-channel communication, where the data transport, the route planning, and the SDNP address map are all executed by a single set of servers.
(608) In general, tri-channel communications offers greater immunity to cyber-assaults because no one set of servers contains all the information about a call. In every case however, the SDNP network utilizes distributed processing to limit the information contained within any given server. Furthermore, during data transport in single-, dual- or tri-channel communication, the SDNP media servers connect to a fourth type of server—DMZ servers. DMZ servers are used for housing SDNP shared secrets needed for processing the SDNP data payloads, including scrambling, splitting, mixing, junk data insertions and removals, and encryption. In operation, incoming data packets received by a media server are delivered to the DMZ server where the data packets are modified and passed back to the media server. The media server is unaware how the data packets have been modified or what logic or algorithm was used to process the data. The executable code and tables stored in a DMZ server are encrypted to prevent analysis of the code. Furthermore, DMZ servers operate offline with no connection to the network or Internet.
(609) The following graphics illustrate one exemplary implementation of tri-channel SDNP communications and the sequence used to initiate a call or send a file over the network. Operation of dual-channel communication can be considered as a minor modification to tri-channel communication where the SDNP name server functions are merged into the signaling servers. Single-channel communication comprises the integration of all three operations into a network of multifunction servers operating as SDNP communication nodes.
(610) Although fragmented data transport within the SDNP cloud is generally performed using dynamic meshed routing, Last Mile communications offers fewer routing options, specifically where successive data packets may be either (i) routed to a single SDNP gateway, i.e. as single-route Last Mile communication, or alternatively (ii) routed to multiple SDNP gateways, i.e. as multi-route Last Mile communication. Other Last Mile routing choices include dynamic source addressing and multi-PHY Last Link connectivity. These delivery options are specified within the IP data packets generated in the signaling servers. Despite the fact that these SDNP data packets specify their source and destination IP and MAC addresses, the precise path that a particular data packet takes in the Last Mile is not known. Instead the intermediate path is determined by operation of the routers, devices owned by local network operators, mobile network operators, and network service providers serving the Last Mile, and not by the SDNP signaling servers. Last Mile communication is therefore analogous to a jump rope where the two ends are fixed but where a myriad of uniquely shaped paths connect them.
(611) Reiterated for clarity's sake, the term single-route, multi-route, and meshed-route communication refers to the path of media packets, i.e. the path “content” traverses between callers, while the terms tri-channel, dual-channel, and single-channel communication refers to the command and control system used to govern transport over the network of SDNP nodes. Given the foregoing, the following set of illustrations depict the sequence of steps, i.e. the “process”, used in making a call or initiating a communiqué in accordance with the disclosed secure dynamic communication network and protocol.
(612)
(613) Using the SDNP network, placing a call, i.e. establishing a “session”, involves the following sequence of steps initiated from the SDNP client making the call, i.e. the “caller” 1. SDNP call (or call out) request 2. SDNP address request 3. SDNP address delivery 4. SDNP routing instructions 5. Commence SDNP call (or call out)
(614) The first step, the “call request” is illustrated graphically in
(615) The second step, the “SDNP address request” is illustrated in
(616) Signaling server 1603A then utilizes the SDNP addresses of the caller and the callee to route a call between them, either as a HyperSecure connection if the callee is an SDNP client, or to the nearest SDNP gateway if the callee is not an SDNP client. The process used to prepare routing instructions and distribute them to every media node required to complete the caller's connection is shown in
(617) The urgency request information is then used to select routing and zones for sub-packet routing by operation 1653. These parameters, along with any applicable security credentials 1621B, are combined to synthesize the routing command and control packets through operation 1660. These C&C data packets are delivered to the Last Mile's participating communication nodes using TCP specified Layer 4 transport, but contain routing information that when used in delivering real time data employ UDP as its Layer 4 transport protocol. For example, Last Mile routing made in accordance with zone U1 security credentials is generated as IP datagram 1625 containing C&C payload 1626 used for routing data from client node C.sub.1,1 to SDNP gateway node M.sub.0,0. IP datagram 1625 is delivered to the SDNP client using TCP data transport, but the C&C payload 1626 entitled “Last Mile routing U1” contains data used by to route packets in real time, necessitating the use of UDP as its Layer 4 transport mechanism. SDNP C&C packet synthesis operation 1660 also generates numerous other C&C messages delivered as TCP data packets to nodes within the SDNP cloud. One example of a cloud instruction data packet is IP datagram 1627A containing C&C payload 1628A used for routing data from SDNP M.sub.0,0 to SDNP M.sub.0,1. As shown in
(618) Commencement of the call is shown in
(619) Routing of the aforementioned SDNP call, i.e. a HyperSecure call from SDNP gateway M.sub.0,0 to a SDNP client C.sub.7,1 comprising cell phone 32 running SDNP app 1335A is shown in the simplified network diagram of
(620) Accordingly, SDNP datagram 1631B containing media SDNP payload B and header 1628B is routed between media nodes with IP addresses IP M.sub.0,4 and M.sub.0,f. Data exiting the SDNP cloud through SDNP gateway 1601B is converted from a SDNP datagram into IP datagram 1632. The IP datagram 1632 with header 1628C and SDNP media payload C utilizes security credentials for zone U2, which is the zone comprising the Last Mile. IP datagram 1632 is then routed over the Last Mile over wired or fiber link 24 to network router 27, and thereafter routed over cellular network 25 and cellular link 28 to cell phone 32. Because cell phone 32 is a SDNP client, communications over the Last Mile remain HyperSecure. In this simplified example, all data packets exiting the cloud onto the Last Mile are routed from a single SDNP gateway 1601B. In reality, more than one SDNP gateway may be employed in Last Mile data routing.
(621) Last Mile communication for a “call out” is shown in
(622) In multiroute Last Mile communication, shown in
(623) SDNP Group Calls—Last Mile media packet routing from SDNP client 1600 to multiple SDNP gateways, shown in
(624) Data flowing in the reverse direction from the SDNP cloud to the client using multi-route communication, as illustrated in
(625) The C&C data packet delivery of routing instructions can be extended to initiate three-way or group calls, group messaging, and other multi-client communications. In such group communiqués or “conference calls”, a client message is sent to multiple recipients concurrently. This group function is invoked by the caller whose request for a group call first defines the group of clients to be contacted, then by the signaling server that instructs the required media nodes how to handle routing of data packets associated with the specific group call. An example of group call routing instructions is shown in
(626) As such, TCP data packet 1627A containing Last Mile routing U1 is delivered from signaling server 1603P at address “IP S1” to SDNP client at address “IP C.sub.1,1” to “set up” the group call with the caller. C&C data packets represented by exemplary TCP data packet 1627Z are concurrently distributed throughout the SDNP cloud for zone Z1 over data links 1614Z from signaling server address “IP S1” to various destination addresses “IP M.sub.0,y” where y represents a integer variable. Collectively, the SDNP cloud routing instructions establish packet routing from the caller's gateway throughout the SDNP cloud to two or more other SDNP gateways located nearest the SDNP clients being called.
(627) As shown by example, the other SDNP clients may be located in different geographic regions and may be within separate security zones, for example zones U7 and U9. In some cases, these clients may be sufficiently far from signaling server 1603P that another signaling server 1603Q may be used to plan packet routing for these SDNP clients. Signaling server 1603Q communicates routing instructions in zone U9 to SDNP client 1600M over data link 1614M and to SDNP client 1600L over data link 1614L. C&C data packet 1625M, for example, communicates Last Mile routing instructions U9 from signaling server at “IP S4” to SDNP client 1600M at its address “IP C.sub.9,1”. Another C&C data packet (not shown) is similarly sent to the SDNP client at address “IP C.sub.9,4”. Data packet 1627H, containing instructions for Last Mile Routing U7, is sent over data link 1614H from signaling server 1603Q at “IP S4” to client 1600H at address “IP C.sub.7,1”.
(628) Signaling servers 1603P and 1603Q at nodes S1 and S4 also exchange information as C&C data packets over data link 1613Z. This information is used to establish which portions of the routing is to be performed by signaling server 1603P and which portions will be performed by signaling server 1603Q, essentially dividing the routing task across multiple signaling servers. In the example shown, signaling server node S1 manages the Last Mile routing for zone U1 and for the SDNP cloud while signaling server node S4 manages Last Mile communication in zones U7 and U9.
(629) Data routing during a call or communiqué is shown in
(630) Data packet 1630H carrying the caller's voice, i.e. SDNP data 1, exits gateway node M.sub.0,4 and is routed using header 1626H from media node at “IP M.sub.0,4” to client 1600H at “IP C.sub.7,1” using zone U7 security credentials. Header 1626H was supplied to the client 1600A within C&C data packet 1627A prior to preparing the media data packet, as described in
(631) Once routed through the SDNP cloud, SDNP data 1 payload is delivered to zone U9 conference call participants, namely SDNP-clients 1600M and 1600L, from gateway media node M.sub.0,8 to client IP addresses “IP C.sub.9,1” and “IP C.sub.9,4”. These Last Mile data packets 1630M and 1630L contain headers 1626M and 1626L specifying the identifying packet tags tag8 and tag9 used to recognize content associated with the same conversation, preamble 9 information used for carrying SDNP embedded instructions, keys, seeds, etc. and a “L4” data field used for stipulating Layer 4 transport as UDP. Although data routing instructions delivered by the signaling server utilize a TCP transport protocol to insure accuracy, media packet content represents real-time data, and therefore beneficially utilizes UDP Layer 4 protocols instead of TCP.
(632)
(633) At the network level 3 of Last Mile communication, no data collisions of opposing direction traffic occur. At the physical and data link layers 1 and 2, however, Last Mile communication may involve time multiplexing to avoid contention for the same communication link. This mediation occurs, however, with such rapidity that the communication likely appears to be full duplex with no delay in voice packets. Note that in both
(634) In an alternative embodiment shown in
(635) In the example shown the cloud transport directs incoming communication at SDNP gateway node M.sub.0,0 to other gateways, in this case SDNP gateway nodes M.sub.0,4, and M.sub.0,8. Data packet 1630H carrying the caller's voice, i.e. SDNP data 1, exits gateway node M.sub.0,4 and is routed using header 1626H from media node at “IP M.sub.0,4” to client 1600H at “IP C.sub.7,1” using zone U7 security credentials. SDNP data 1 payload is also delivered to conference call participants through gateway media node M.sub.0,8. Last Mile communication from this SDNP gateway comprise two different types of connections, specifically a HyperSecure connection to SDNP-client 1600M and an unsecured “call out” connection to PSTN 1 comprising a conventional phone system not employing VoIP or packet protocols. Last Mile data packet 1630M delivered to zone U9 SDNP client at address “IP C.sub.9,1 contains header 1626M specifying the identifying packet identifier “tag 9” used to recognize content associated with the same conversation, preamble 9 information used for carrying SDNP embedded instructions, keys, seeds, etc. and a “L4” data field used for stipulating Layer 4 transport as UDP.
(636) Gateway node M.sub.0,8 also sends an IP packet 1635 to PSTN 1 at the address IP C.sub.7,9. Rather than carrying the payload comprising SDNP data 1, in this case the IP payload has been converted into a VoIP sound package, one that could be intercepted by packet sniffing. The phone switch system, PSTN 1 then converts this unsecured IP packet into an analog POTS phone connection to phone 37 shown by POTS data 1636 comprising the phone number being called followed by a continuous analog circuit connection between phone 37 and PSTN 1. Because this and any other call out connections are not HyperSecure, the content carried by the call out Last Link is at risk for hacking, wiretaps, and other surveillance techniques. Unless some hierarchical structure defining access privileges of the clients is implemented, the security of the entire call is compromised by the weakest link, meaning everyone on a group call can hear everything.
(637) This point is exemplified in the table shown in
(638) Referring again to the table in the column entitled regular call, please note that everyone on the group call, i.e. callers approved by the host, has the ability to listen to the call. Callers attempting to hack into the call and not approved by the host have no means to connect or force their way onto the call or even the ability to determine a call is transpiring. The same methods are applicable to group chats where participants can read and write messages, but view only members can only read the comments but cannot interject their own text onto the chat.
(639) Using authentication and identity verification for controlling network access made in accordance with this disclosure, the SDNP system offers privacy features not available in conventional group chats and group calls. This feature is invoked by selecting private mode, e.g. example by clicking a lock symbol or other privacy icon before texting or speaking. In such cases, the communication is sent only to SDNP clients who are authenticated and not to SDNP clients who have not yet confirmed their identities through authentication and not to any call out listeners or participants on unsecured devices. This point is clarified in the aforementioned table where, in a private call under the column labeled “Unauthenticated SDNP Client,” all group call clients have both their microphone and speaker muted while in the column labeled “Authenticated SDNP Client,” all SDNP clients can listen, participants C.sub.1,1, C.sub.7,1, and C.sub.9,1 can also talk, but all call out devices have both their microphone and speakers muted, meaning only an authenticated SDNP client can hear or comment in private mode. In this way, a group call with a mix of SDNP clients of assured identity, and with call out connections with unknown parties can mutually participate in the public portion of a call but without revealing confidential information to the call out devices. The “call out” callers are removed from private discussions simply by having any SDNP participant click their private icon before speaking or texting. At the end of the private discussion, the private button is released and they are reconnected. During the time the call out callers are disconnected, i.e. essentially placed “on hold”, the SDNP system can either play waiting music, go silent, or play white noise (like ocean or rain sounds).
(640) Text messages in a group chat can also be managed in the same manner. In a regular group chat all text messages are sent to the SDNP app on SDNP client devices and sent by SMS text message to all call out chat members. Text messages can be sent only by participants. Text messages sent from “Listeners” or “Read Only” chat members are ignored and will not be forwarded to the chat group. If a participant clicks the lock or privacy icon before sending a message, the message will be sent only to SDNP clients and not to any call out clients. For SDNP clients receiving a private message, if they have authenticated their identity the message will visible for reading. If they have not authenticated their identity, the message will be obscured, covered, hidden, or represented by an icon, e.g. a lock, until the viewer performs an authentication to confirm their identity.
(641) By combining authentication of identity with privacy privileges regulated by SDNP network system authorization, hacking the device is insufficient to open a private text or listen to a private call, even in group chats and group calls. This feature cannot be guaranteed by relying only on device security parameters—information that can be hacked locally. System parameters are much harder to trick because fake security and identity credentials will not match the system logs and will be rejected as invalid SDNP clients.
(642) An additional degree of privacy can also be added in executing group calls and group chats. This unique embodiment of the HyperSecure Last Mile described in the table shown in
(643) Although the first three criteria are essentially the same as those in the aforementioned example of private parties in a group call, the fourth criterion, the requirement that any caller eligible to receive hyper-private calls or text must be loaded on a predefined list of clients as a “private” SDNP client, is unique and further limits access to sensitive information. For example, as shown in tabular form, SDNP participant clients C.sub.1,1 and C.sub.7,1, and SDNP listener client C.sub.9,4 are all designated as “private” parties in the group call. In contrast SDNP client C.sub.9,1 is only designated as a participant but not as a private participant. By definition, no call participant or listener can be registered as a private party.
(644) As in the previous example, during a regular call all participants, i.e., SDNP clients C.sub.1,1, C.sub.7,1, and C.sub.9,1 and call out participant Ph #1, can hear all conversations and read all text messages as well as talk or text at any time, while “listeners,” comprising clients C.sub.9,3 and Ph #2, can hear all conversations and see texts but cannot talk or send messages in the group call or chat. In a hyper-private call, however, selecting a switch or icon to designate a hyper-private communiqué automatically blocks not only all unauthenticated parties on the group call or chat, but it also disables any party other than “private” parties. It also disables all call out connections and all unauthenticated users. So in operation, when any private participant selects the privacy icon, only private participants (including the private group host), can see, read, talk or text to the group. All other parties have their microphones and speakers muted, and likewise are unable to receive or send texts or attachments to the group. Specifically, in in hyper-private mode, once authenticated, only clients C.sub.1,1, and C.sub.7,1 can both listen and talk as well as read and send text while private client C.sub.9,4 can only listen to a conversation or read group text.
(645) With the above Last Mile routing control capabilities, group calls and group chats can be managed in any number of ways. For example, the group call host can determine who can join the call or group, who can talk and text, and who can only listen and read. In a standard private call, selecting the private mode enables all SDNP clients, once authenticated, to engage in communiqués with the same privileges they had during standard non-private group communication. In the hyper-private mode, only SDNP clients defined as private participants and private listeners can communicate during hyper-private mode operation.
(646) Selection of who is qualified to be part of a hyper-private communiqué, i.e. who is identified as a private participant or listener, and who is not, can be established in several ways. In ad hoc hyper-private group communication, the group host decides who is a private caller and who is not. In SDNP “system defined” hyper-private group communication, the SDNP network operator decides in advance who is private caller and who is not. In rules-based hyper-private group communication, the SDNP network has defined rules to determine who is eligible to be a private caller and who is not. These rules may be based on a company employment list, e.g. where only vice-president and higher may participate in a hyper-private call. In government and security organizations, the criteria may be set by national security clearance, passport number, police badge number, etc. The SDNP-enabled Last Mile communication methods defined herein can support any of these exemplary scenarios, or employ any other criteria to bifurcate a population into two groups, thereby establishing those that have hyper-private communiqué access and those that do not.
(647) While the concept can be extended to more than one group, hierarchical access criteria are generally more applicable to dispatcher-based professional communication systems than to telephony. The application of SDNP methods for professional communications will therefore not be addressed further in this application.
(648) One challenge for group calls is the problem of everyone trying to talk at the same time. Overlapping speech is confusing, hard to hear, and may also result in unwanted static. This issue can be remedied by using the push-to-talk feature, a function emulating a walkie-talkie or CB radio. In push-to-talk or PTT operation only one participant can be speaking at a time. When a participant wishes to talk, depressing a switch mutes all other on the network microphones putting every other party in the group call into a listen only mode. As shown in the table of
(649) Using the SDNP Last Mile capability for identifying callers that have authenticated their identity to the network, the PTT feature can be extended to private push-to-talk functions. Whenever the privacy feature or icon is selected, all unauthenticated parties are removed from the group call, muting their speakers and microphones. Call out connections by definition cannot be authenticated and therefore are muted as well. Muting is bidirectional, preventing the excluded parties from listening to the conversation but also disconnecting the excluded participant's microphones as well. For those parties that are authenticated, operation precedes the same as a regular PTT, where the host has priority to talk and otherwise any authenticated participant can invoke the PTT talk feature on a first come, first served basis.
(650) The table in
(651) In an alternative embodiment data packets are sent in broadcast mode to all participants in the group call but using different encryption methods. In the case of normal conference calls the data packets are sent to all users using an encryption where all participants have a copy of the decryption key. In private mode or mute mode the data packets broadcasted to the users utilize a different encryption where only select users share the decryption key. Those with the key are able to participant in the call and those without are excluded. The advantage of using a broadcast packet is that it requires less bandwidth for last mile communication than sending separate packets demands. In yet another embodiment a single packet is sent to the gateway, and the signaling server clones the packet for distribution to all participants in normal call mode and to select callers in private or mute mode.
(652) HyperSecure File Storage—Although the secure dynamic communication network and protocol was invented and developed as a HyperSecure communication system for telephony and real time data transport, the security mechanisms intrinsic to the SDNP network and protocol render it perfectly suited for HyperSecure file and data storage. In its simplest description, if a HyperSecure call involves anonymous fragmented data transport of scrambled encrypted data from one caller to another, i.e. end-to-end communication from one SDNP client to another SDNP client, then HyperSecure file and data storage can be envisioned as a communication that is stopped halfway and stored in a buffer indefinitely until recalled. Another name for Hypersecure distributed file storage is Disaggregated Data Storage.
(653) This simplified description, that storage is a communication that is stopped in the middle of packet delivery, is technically more accurate than it may first appear. In the above-referenced U.S. application Ser. No. 14/803,869 the buffering of data packets temporarily until other packets catch up was explicitly disclosed and described operationally. While buffering within the nodes of the SDNP cloud occurs in a scale of milliseconds rather than months, the SDNP system has the ability to wait or hold data without losing the information recovered to recover the original content. Of course, such a simplified implementation lacks certain features needed for long-term file management such as directories, menus, recycling of files, refreshing of security credentials and other such features.
(654) An example of the data transport from a client to a fragmented data storage network is shown in
(655) Once the data packets enter the SDNP cloud they are routed to different destinations in accordance with their identity and the instructions of a signaling server (not shown). The data packet 1730H with header 1626H and tag 1 carrying SDNP file 1 is routed to SDNP gateway node M.sub.0,4. SDNP gateway node M.sub.0,4 then routes the packet 1730H to file storage node F.sub.7,1 using security credentials for zone U7. Meanwhile, the packet 1730L with its ID as tag 2 carrying SDNP file 2 is independently routed to SDNP gateway node M.sub.0,8. SDNP gateway node M.sub.0,8 then routes the packet 1730L to file storage node F.sub.9,4 using security credentials for zone U9.
(656) Nearly contemporaneously, the packet 1730M with its ID as tag 3 carrying SDNP file 3 is independently also routed to SDNP gateway node M.sub.0,8, not necessarily using the same meshed routing path as data packet 1730L with an ID of tag 2. SDNP gateway node M.sub.0,8 also routes the packet 1730M with tag 3 to file storage node F.sub.9,1 also using security credentials for zone U9.
(657) In this manner, SDNP file 1 is delivered to file storage node F.sub.7,1 using security credentials for zone U7, while SDNP file 2 and SDNP file 3 are delivered to file storage nodes F.sub.9,4 F.sub.9,1 respectively with both using security credentials for zone 9. Although the files are owned by client node C.sub.1,1, the client does not have access to the security credentials used to encode and protect the contents of the files. Since no one file storage node contains all the data, and since the client owning the data does not have access to the security credentials used to store the data, it is difficult for a hacker to steal the files' contents because (i) they are fragmented into incongruent and unusable pieces (ii) all the files use different security credentials to scramble and encrypt the data, (iii) they are stored in different locations and on different Last Mile networks and (iv) there is no way to tell the various stored data comes from the same SDNP source file. Zones containing the file storage servers may also be referred to as “storage side” zones to distinguish them from the zone where the file owner is located, i.e. on opposite sides of the SDNP cloud. By this definition, zone U1 is the SDNP client zone, also referred to the as “file owner” zone, while zones U7 and U9 are “storage-side” zones.
(658) The application of the SDNP network communication protocols on file storage is further illustrated is the flow chart of
(659) While zone U1 Last Mile routing may involve sending the data packets over a infrastructure involving a limited number of routing choices, the methods described for HyperSecure Last Mile communication, including multi-PHY last link routing, routing of sequential packets to multiple SDNP gateways, and the use of dynamic source addressing, i.e. changing the name of the client's IP address, are equally applicable to HyperSecure file storage operations. Once the data packets reach the SDNP cloud, their transport utilizes anonymous meshed routing with scrambled dynamically encrypted data preventing monitoring of the file content or even the metadata associated with the communication. Ultimately, all three data packets arrive at different SDNP file storage servers 1700H, 1700M, and 1700L with corresponding SDNP node names F.sub.7,1, F.sub.9,1, and F.sub.9,4 located in different security zones. After network transport, parsed file 1 is processed in accordance with zone U7 file security operation 1709A and stored on SDNP file storage node F.sub.7,1. Parsed files 2 and 3 are processed in accordance with zone U9 file security operations 1709B and 1709C and stored on SDNP file storage nodes F.sub.9,1 and F.sub.9,4. In this manner, no one file contains all the data, and no single security credential can unlock all the component files to recreate the original.
(660) In the “read operation” of a HyperSecure stored file shown in
(661) To further elaborate in the described HyperSecure file “read operation”, the relevant contents of file storage server 1700H saved in file storage node F.sub.7,1 is processed using Zone U7 file security operations 1709A to recover parsed file 1. Independently of parsed files 2 or 3, parsed file 1 is communicated back to SDNP client node C.sub.1,1 using the SDNP cloud shown in simplified form by HyperSecure transport operation 1708 using zone Z1 security credentials, and then by zone U1 Last Mile HyperSecure transport operation 1707. Concurrently, the relevant contents of file storage server 1700M saved in file storage node F.sub.9,1 is processed using Zone U9 file security operations 1709B to recover parsed file 2. Independently of parsed files 1 or 3, parsed file 2 is communicated back to SDNP client node C.sub.1,1 using the SDNP cloud shown in simplified form by HyperSecure transport operation 1708 using zone Z1 security credentials, and then by zone U1 Last Mile HyperSecure transport operation 1707. Meanwhile, the relevant contents of file storage server 1700L saved in file storage node F.sub.9,4 is processed using Zone U9 file security operations 1709C to recover parsed file 3. Independently of parsed files 1 or 2, parsed file 3 is communicated back to SDNP client node C.sub.1,1 using the SDNP cloud shown in simplified form by HyperSecure transport operation 1708 using zone Z1 security credentials, and then by zone U1 Last Mile HyperSecure transport operation 1707.
(662) The independent packet routing of the three constituent parsed files during the read operation is exemplified in
(663) Meanwhile, server node 1700L sends data packet 1731L carrying SDNP file 2 and with ID “tag 9” using TCP transport from file storage address IP F.sub.9,4 to SDNP gateway server at address IP M.sub.0,8. Packet 1731L includes header 1727L containing preamble 9 and other information that in tri-channel communication was provided previously in a command and control packet delivered by the signaling server. Independently and concurrently server node 1700M sends data packet 1731M carrying SDNP file 3 and with ID “tag 8” using TCP transport from file storage address IP F.sub.9,1 to SDNP gateway server also at address IP M.sub.0,8.
(664) Packet 1731M includes header 1727M containing preamble 9 and other information provided in tri-channel communication previously using a command and control packet delivered by the signaling server. The three data packets 1731H, 1731L, and 1731M traverse the SDNP cloud using zone Z1 security credentials till they finally emerge from SDNP gateway M.sub.0,0 hosted by SDNP cloud server 1701U where the data packets are sequentially sent by successive data packets 1731X using corresponding zone headers 1727X and zone U1 security credentials to client device 1700A at address IP C.sub.1,1
(665) Referring again to
(666) Rather than adding extra file server operations to secure stored data, the security operations 1709A, 1709B and 1709C actually comprise Last Mile HyperSecure communication between the SDNP cloud and the corresponding storage-servers 1700H, 1700M, and 1700L. As an artifact of Layer 3 network connectivity using the SDNP communication protocol, SDNP file storage is intrinsically HyperSecure, comprising scrambled, fragmented, encrypted data stored across distributed nonvolatile data drives including the use of data deception methods such as junk data insertions and junk files. Aside from the foregoing data security methods, HyperSecure storage as disclosed herein utilizes anonymous file names lacking any meaningful metadata, traceability to the file owner, routing by which the file was delivered, or the identity of any other file storage server holding missing components from the original source file.
(667) Despite the interoperability on the SDNP network, the physical realization of the storage servers, i.e. their Layer 1 PHY implementation and Layer 2 transport, protocols may vary substantially without impacting storage functionality, access times, or global accessibility.
(668)
(669) The process of storing each parsed portion of a file uniquely into separate file storage servers, referred to non-redundant HyperSecure file mapping, is illustrated in
(670) Another metric describing or rating the data storage system's resiliency is a metric defined herein as read redundancy factor RRF, a term defining the number of backup systems providing data access in case the primary data storage is unavailable. In the example shown, there is one location for each unique piece of data. This results in a read redundancy factor of zero, or mathematically RRF=0, meaning that a single point connection or file server failure may result in temporary or permanent data loss because the file cannot be read by the file owner.
(671) An alternative file mapping with a read redundancy factor of RRF=1 is shown in
(672) To illustrate the process by which redundant files are stored and read using HyperSecure file storage, it is beneficial to illustrate the transactional sequence of communiqués and file transfer functions overlaid atop the SDNP network used to facilitate the storage process. The network shown in
(673) In
(674) In
(675) In
(676)
(677) The preamble in each data packet, e.g. preamble 1 in data packet 1712A, may also contain an encryption key supplied by the client as part of a symmetric key encryption operation. Using symmetric key encryption, the SDNP client node C.sub.1,1 generates a split key, one for encryption and its complement for decryption. The symmetric encryption key is then supplied to the file storage server node F.sub.7,1 delivered by data packet 1712A in this example. In the future, whenever the client requests to read or access the contents of the stored file, file storage server node F.sub.7,1 encrypts the requested file using this encryption key before sending the file back to the client. Because only the client possesses the associated decryption key, only the client can open the read file. While this method provides an extra layer of protection, it has the disadvantage that only a single client can access the file as a read operation, preventing the use of multiple client file “owners” needed to facilitate redundant access in the case the original client device is stolen, damaged, or lost.
(678) Around the time of the data transfer and file storage process, the signaling server 1715 also sends instructions to file storage servers 1700H, 1700L and 1700M regarding “link reply” message routing. A link reply is a data packet and C&C payload confirming to the client that the write operation was successful and storage of each parsed file is complete. These messages are sent to the client file-owner independently from each file storage server involved in storing the transferred parsed files. The file servers send their write-confirmation replies to the client independently with no knowledge of one another, and the write-communication replies are transmitted using independent security credentials including unique states different than the states operative at the time of the write operation. Routing of these link reply messages does not necessarily utilize a reverse direction of the same routing path as those used to transfer the files. Such a reply could potentially be used by cyber-attackers as a trace back to find a file's owner. Instead, the link reply utilizes a packet ID to identify to the client that the stored files are part of the same file and stored as part of the same fragmented write-operation.
(679) In operation, the signaling server sends routing for the link reply messages to the file storage servers, to the client file-owner, and to all the intermediate SDNP nodes involved in the link-reply message routing. The signaling server 1715 coordinates the link reply message routing as shown by example in
(680) The actual routing of the link reply messages from participating file storage server nodes is shown in
(681) In a similar manner, file storage server 1700L replies with data packet 1720B identified by tag 2 and carrying a payload “FS link 2”. The packet is routed from address “IP F.sub.9,4” to SDNP gateway at address “IP M.sub.0,8” using zone U9 security credentials. From the SDNP gateway, the tag 2 identified data packet is routed through the SDNP cloud (routing not shown) to client side gateway at address “SDNP M.sub.0,0” where the address is converted to Last Mile data packet 1720X and routed from address “IP M.sub.0,0” to address “IP C.sub.1,1” using TCP transport using zone U1 security credentials, and carrying tag 2 data, namely preamble 2 and FS link 2.
(682) The third piece of the parsed file identified by tag 3 and carrying a 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.sub.9,1” to SDNP gateway at address “IP M.sub.0,8” using zone U9 security credentials. From the SDNP gateway, the tag 3 identified data packet is routed through the SDNP cloud to client side gateway at address “SDNP Mom” where the address is converted to Last Mile data packet 1720X and routed from address “IP Mom” to address “IP C.sub.1,1” using TCP transport using zone U1 security credentials, and carrying tag 3 data, namely preamble 3 and FS link 3.
(683)
(684) The foregoing data packet is used for illustrative purposes and should not be viewed as limiting the data packet's contents to the precise elements or format as shown in the example. The FS links 1720X received by SDNP client node C.sub.1,1 once received from the file storage servers participating in storing the fragmented file, are then processed to create a file link for the client's device. As illustrated in
(685) A simplified representation of the FS Link communication is shown in
(686) Since the file storage link is sent to the client directly from the file storage servers and not through a signaling server, only the client with the link has access to the file. This FS link is required to recall and read the fragmented file. Without the FS link, the stored file and its contents will be lost forever and become irreversibly irretrievable. To reduce the risk that the FS link may be lost, an alternative approach sends the FS link to two client devices—the client device and an auxiliary device. The auxiliary device may be a second device owned by the client or in business cases, a second device owned by the company. Alternatively, the second device may comprise another server with its own login security and user identity verification.
(687) Redundant link access to fragmented distributed stored files made in accordance with this invention may applied to both read redundant, i.e. RRF≥1, and non-redundant file storage systems. The use of a redundant link in a HyperSecure distributed memory system lacking read redundancy (RRF=0) is illustrated in
(688) An example of HyperSecure memory comprising both read and link redundancy is shown in
(689) As such, the overall storage redundancy factor SRF is a direct measure of the resiliency of the distributed storage system from failure. This principle is summarized in the graph of
(690) As shown, storing a three part parsed file on 3 file storage servers as shown previously results in a read redundancy factor RRF=1. Provided at least two clients receive the FS link, the link redundancy of LRF≥1 is achieved. The combination of either LRF=1 or RRF=1 produces L-shaped region 1724B where SRF=1, i.e. providing some degree of system resiliency. Note that even when 6 servers are employed, if the FS links are sent to only two clients the system still exhibits only a limited degree of resiliency, i.e. SRF=1.
(691) By sending the FS links to 3 clients and storing data redundantly on 6 storage servers, region 1724C defines the conditions where SRF=2 offering a fairly robust degree of storage resiliency. Region 1724D illustrates a further enhancement in resiliency where SRF=3 using six file storage servers and 4 clients receiving keys. So the bottommost row and leftmost column have the lowest storage resiliency and the upper right hand corner has the best storage resiliency.
(692) HyperSecure distributed file storage made in accordance with this disclosure achieves long-term sustainable security by adapting, i.e. re-purposing, numerous inventive elements from SDNP communication. These inventive elements include: Parsing a file and distributing its fragmented content across a number of un-related network connected file storage servers, Transporting files between client and file storage servers using end-to-end HyperSecure communication comprising SDNP dynamically scrambled encrypted anonymous fragmented data transport with no master key, Storing the fragmented files in file storage servers in a manner where the storage servers lack access to client security credentials used to initially fragment and encode the stored data, i.e. where the file storage server does not possess the “client side” Last Mile security credentials required to decode, access, or read the file, Optionally encoding fragmented files in storage servers in a manner where a client (file owner) lacks the security credentials need to decode the stored data except through a secure link, i.e. where the “client-side” Last Mile does not possess the “storage side” Last Mile security credentials used to locally encode the files, Limiting the number of file storage links needed to locate and open the file and restricting user access to such links to the file owner's client device along with any redundant or backup devices, Requiring client multi-factor authentication and identity verification in order to execute a file link and invoke a read or erase operation, Utilizing anonymous data packet routing and anonymous file names whereby use of the file link for data recall provides reveals no information as to the location or encoding of the HyperSecure file storage and where, with exception of the file link, no routing information is stored in the SDNP network or HyperSecure file storage system, Distributing a fragmented file across a number of storage servers using undisclosed file server locations, and except through the file storage link, using anonymous identities unknown to the client, the SDNP network, or to other storage servers, Employing tri-channel communication where the SDNP signaling servers used to plan file routing for distributed storage have no access to the content of the fragmented files or the security credentials used to encode the files and where the SDNP media nodes used to transport the file content utilize single hop SDNP data packets lacking the identity or address of the client or the file storage server, Employing dynamic file renaming and data relocation at regular intervals and after repeated file access, regenerating encoding a security credentials at the time of the file rewrite operation, and Locally encrypting the file storage server directory to thwart file analysis.
(693) Using the foregoing, the lack of any discernable file identity; the use of fragmented file distributed across a network (possibly on a global scale); and the use of zone-specific security credentials renders access to and reconstruction of a HyperSecure stored file inconceivable without access to file storage link. Such FS links, limited in number and distributed only through the SDNP communication system, are further secured by identity verification.
(694) The execution of the foregoing features for HyperSecure file storage can be represented schematically in the same manner as HyperSecure communication using the functional symbols shown previously in
(695) Using the aforementioned security functions, the top illustration of
(696) A greater degree of file security is achieved by using the process shown in the lower illustration of
(697) During meshed transport, after a series of zone Z1 decoding and encoding operations in the SDNP cloud (not shown), the final data packets arrive at their respective SDNP gateways including, for example, gateway M.sub.0,8 where SDNP decode operation 1751D recovers scrambled, encrypted, parsed file 1706, then re-encodes it using SDNP encode operation 1750D in accordance with zone U9 security credentials. The fragmented files 2 and 3 of scrambled, encrypted, parsed file 1706 are then recovered using SDNP decode function 1751E and stored respectively in file storage servers 1740B and 1740C. The file is therefore secured not only by fragmented distributed storage, but by some combination of scrambling, junk data, and encryption known only to the client's security zone. In a similar manner file 1 is transported through the SDNP cloud to gateway M.sub.0,4 where it is stored in file storage 1700H in zone U7 as shown for packet 1712A in
(698) In both examples described, a greater degree of security can be achieved by eliminating the final SDNP decode operation 1751E shown in the illustrations of
(699) A summary of exemplary methods of implementing HyperSecure disaggregated file storage is shown in
(700) The upper right corner reveals the case for client zone U1 fragmentation, but where the extra step of SDNP encoding, i.e. scrambling, junk insertions, fragmentation, and encryption, is introduced on the storage side in accordance with zone U9. The lower right corner represents an example of full nested HyperSecure file storage where the file is encoded and fragmented in accordance by SDNP encode operation 1750B with the zone U1 client side security credentials, and then the file is encoded a second time in accordance with the zone U9 security credentials of the storage side Last Mile.
(701) To recall and read the file, data recall must utilize security operations comprising anti-functions executed in the precise reverse order of the encoding, as illustrated in
(702) In the lower right hand example to read a fully-nested HyperSecure file, data stored on different file storage servers is decoded by SDNP decode operation 1751D using zone U9 security credentials to reconstitute file 1706, a multipart file still scrambled, junked, parsed, and encrypted in accordance with zone Z1 security credentials. Zone Z1 specific SDNP decode operation 1751H then performs the sequential anti-functions of encoder 1750B, an operation comprising mixing, decryption, unscrambling to recall original file 1705. The operation of executing a sequential anti-function to recover a file should occur in the inverse order of the sequence used to create it. For example, if encoding involves splitting, then scrambling, and then encrypting, the inverse or anti-function, i.e. decoding, should comprise the operational sequence of decrypting, then unscrambling, and then mixing. If, however, encoding sequentially involves scrambling, then encrypting, and then splitting a packet, then the inverse or anti-function, i.e. decoding, should comprise the sequence of mixing, then decrypting and finally unscrambling the data packets
(703) To invoke a file recall or “file read operation” the client invokes the aggregated file link by clicking on the “file storage read link” to initiate the steps needed to recall and read a file stored on the system's HyperSecure file storage system. The read process involves the following steps as illustrated in
(704) After these authentication, authorization, and administration (AAA) steps, upon approval, the client makes a request to access the file using the steps illustrated in the flow chart shown in
(705) The steps are represented in the following sequence of illustrations. In
(706) In
(707) A second data packet 18101 is sent from SDNP signaling server 1715 at address “IP S” to file storage server 1700M at address “IP F.sub.9,1” containing a C&C payload 18111 containing a “File 3 Read Instruction”. This instruction commands file storage server 1700M to send a file with ID tag 3 to SDNP gateway ate address IP M.sub.0,8 using zone U9 security credentials. Other C&C packets (not shown) are similarly sent to the other file storage servers and gateways such as nodes F.sub.9,4 and M.sub.0,8 as well as the nodes in the SDNP cloud.
(708) In
(709) Once the command and control data packets are distributed to the network, the file transfer can ensue. The first step in the transfer is shown in
(710) File routing and data transport is shown in
(711) In the read operation, the data is loaded into the SDNP app in its “read only” form. As long as the file remains sandboxed within a SDNP application, the file is protected by the features of the SDNP application and network and does not rely on the device's operating system's login procedures and weak security provisions. The need for read only access to private documents is pervasive in business. Files generated by a corporation's finance, legal, manufacturing, engineering, and quality departments illustrate examples of material that frequently represent read-only content. In many cases these company private files must be forwarded, i.e. distributed electronically, to corporate executives for review prior to their release.
(712) Accidental or premature disclosure of the communicated information can be devastating, carrying severe economic and even legal consequences for a company and personal liability for its officers. For example, a public company's unreleased financial report is strictly confidential until it is published. In the United States, regulation FD or “fair disclosure” means the information must be made publically available to everyone at the same time without preference. If any outside party gains access to that information prior to its public release, it is a violation of regulation FD. If a court determines that the regulation FD violation occurred because the company was negligent in its duty to maintain and insure the document's confidentiality, then the company may penalized for its infraction and its officers may be held personally liable, even if no insider trading resulted from the selective disclosure.
(713) Within the SDNP app, a retrieved file is compartmentalized (sandboxed) to prevent transfer of the data from one account identity to another, e.g. files may not be swapped between business and personal accounts. Depending on the reader's authorization privileges, a user may or may not be allowed to download the retrieved file out of the SDNP application and into un-encoded storage in device memory. Downloading the file outside a SDNP enabled application compromises the security of the file and the data it contains. For data residing within a SDNP application, access is controlled, a user's actions are limited, and both the device and the SDNP network must verify the user's identity. Such a multi-tiered multi-factor authentication is far more difficult to overcome than defeating the simple 4-number pin needed to open a phone. In contrast, once a file is downloaded into a computer, tablet, or cell phone, it is nearly impossible to prevent unauthorized access, to determine who has access, or who has made a copy of the file.
(714) So using SDNP communication, a file owner can lock, i.e. compartmentalize, sensitive documents and files so that others may read them but not download them into their phone. Additional steps can be used to prevent screen shots or photographs of the LCD display screen. In other cases where security or privacy are not required, transfer of retrieved files from the SDNP app into the phone's memory is enabled and available for use without restriction.
(715) In an edit operation, an editable form of the file is downloaded into the device and passed into an application program needed to edit the file. To execute a file request and data exchange, there is no fundamental difference in the SDNP network operation between a file read request and a file edit request other than in the operation of the client's SDNP application—from the perspective of the SDNP network's transfer of data, the operations are functionally equivalent. The differences between the read and edit operations therefore can be considered to reside primarily in the execution of Layer 5 through Layer 7 comprising application specific files.
(716) To edit the retrieved file, the application may be (i) an device embedded application (such as Simpletext) native to the device's operating system but operating outside of the SDNP application, (ii) a third party application running atop the device's operating system but outside of the SDNP application, e.g. Microsoft Word, Adobe Acrobat, etc., or (iii) a secure application running inside the SDNP application and not directly accessible by the device or its operating system. For example, a corporate press release may be edited within the SDNP application sandbox but cannot be downloaded into the phone's memory. As an added provision for maintaining business security, any file owned by a business, i.e. sandboxed in the SDNP business account compartment, cannot be transferred into the user's personal SDNP account even though both personal and business profiles are running within the same SDNP application.
(717) After editing, storage of the edited file back onto the SDNP's file storage servers does not overwrite the existing unless the file owner specifically requests to do so. Instead the second version is stored in addition to the first and elimination of the earlier version requires the user to execute an erase operation. Because HyperSecure file storage invariably requires identity verification, the process of saving the edited file may include unique system features not available from file storage lacking dedicated HyperSecure network communication. Once such unique feature is a signature verification function used to sign and date (or in Asia to stamp/chop and date) the file. The signature function may include a registered receipt sent to the document holder and to the original document creator.
(718) For HyperSecure data storage made in accordance with this invention, an erase operation involves overwriting all the existing parsed files with random numbers and optionally doing it again one hour later to further obscure small but potentially detectable analog variations in the electric charge or magnetic field of the stored bit. The file record is also overwritten to confound the data drive's file record. After erasing the data and file record, the client's data link is destroyed in the client device using the SDNP system's self-destructing message feature, and any remnant of the FS link is purged from the SDNP system. If however, a file system administrator has been tracking activity of their user base with third party software, the administrator may still retain metadata on the file's history including its owner, its creation date, who accessed the file and when, and when it was erased, even though they have no access to the file itself.
(719) The SDNP network and HyperSecure Last Mile functions may also support different features and operating procedures for corporate accounts than for personal account profiles. As described previously, the erase operation on a personal account involves rewriting junk data into the file, purging the drive's index record of the file's existence, and destroying all FS links to the file's previous fragmented storage locations using self-destructing messages. For corporate accounts, however, a file storage administrator may require their prior approval to permanently destroy a file, e.g. using an approval process similar to dialog box 1769 in
(720) If the company's file administrator chooses not to allow the files deletion, several scenarios may occur including (i) the file owner is notified the file will not be deleted and the file read link is retained in their SDNP application or SDNP communicator message history, (ii) the file owner is notified the file will not be deleted, e.g. it will be preserved for “archive purposes”, but their personal file read link will be removed from their SDNP application using the SDNP system's self destructing messages provision, meaning once the owner tries to delete the file only the file storage administrator can recall it, or (iii) the file owner's personal file read link will be removed from their SDNP application using the SDNP system's self destructing messages provision but they are not informed the file has been retained by the company.
(721) Because of Last Mile HyperSecurity intrinsic to the operation of the disclosed anonymous fragmented distributed file storage system, without a “file storage read link” the stored files are un-retrievable, even by the file storage administrator. For the administrator to gain access to a file, they must be the corresponding file storage read link whenever a file is saved or edited. While this level of monitoring is possible for a corporate account, the copious amounts of data generated in tracking every change to every file will invariably will overwhelm any file management system. An intelligent filter possible with the disclosed SDNP system as is disclosed is to track only attempted file erasures. In this approach, the administrator does not monitor the creation of files but tracks only attempts to delete them. Whenever a file owner attempts to delete a file, then and only then, is the corresponding file storage read link transferred to the administrator's database or console for approval or archiving.
(722) The database size can further be minimized by identifying specific employees and contractors to which monitoring is required. For example, if a company becomes involved in a financial audit or a patent lawsuit, normally the parties are informed not to erase any relevant data or erase any files. Using file management features enabled by the disclosed SDNP file storage system, any file erasure attempts of staff related to the investigation can be tracked by logging the attempted erasure, and “at that time” sending a copy of the file storage link to the file storage administrator or to the independent investigator as the case may be. Such a method is beneficial because it limits the amount of data to be monitored and it naturally alerts management to suspicious activity suggesting an attempted cover-up of wrongdoing. To prevent the accidental or malicious loss of a file storage name link by destruction of the client and file owner's device itself, the use of redundant file storage links as disclosed previously is imperative. In corporate cases, the backup copy may be maintained on computer located within a secured office, or in a centralized company server.
(723) In cases of extreme security, e.g. in cases of national security, erasing a file may comprise a multistep method including (i) overwriting the file with random data, (ii) copying all other files off of the storage drive onto some other storage device (iii) performing a bulk erase of the drive, (iv) reformatting the drive, (v) overwriting the drive's storage fields with random numbers, and optionally (vi) copying back the preserved files as required. Unlike a conventional data overwrite of a file a 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 a magnetic drive can utilize a large electromagnet, bulk erasing of flash may involve elevating the ICs to a high temperature and possibly subjecting them to ionizing radiation at elevated operated voltages. Magneto-optical drives can be bulk erased using high magnetic fields. Re-writable optical drives can be bulked erased using a bright scanning laser scanned transverse to the disk format tracks. In any event, bulk erasing represents the extreme case where the storage media after erasing is either completely devoid of data, even at risk of damaging the storage media so that is may never be used again.
(724) Another important factor in a HyperSecure distributed file storage system is to maintain the integrity of the file data and the link access. To insure the link is not accidently lost, from time-to-time it is beneficial to reestablish, i.e. reconfirm, the file storage read link and reissue the security credentials. This process, referred to herein as a “refresh link” command can be initiated from the client manually or automatically, and may also be initiated from a file storage server after some predefined interval. For requests initiated from the client, the SDNP signaling server communicates a command and control packet to the corresponding servers. Once a link refresh is initiated as shown in
(725) As another provision for enhanced security, the redistribute file operation moves every parsed file for a selected file storage link to new or different file storage servers. The operation may send the parsed files to completely new servers, or alternatively the files may be redistributed among existing storage nodes. In each case, the security credentials are updated and a new file FS link issued and sent to the client or clients with access to the file. This operation is shown by example in
(726) Concurrent to the aforementioned file transfer, the content of file storage SDNP node F.sub.9,4 in zone U9 is decoded by SDNP decode operation 1751L using state 920X, the state at time t.sub.1 when the file was created. The file is then transported over the SDNP network (not shown) to file storage SDNP node F.sub.9,1 where it is encoded by SDNP encode operation 1750M using zone U9 security credential as state 920Y corresponding to time t.sub.2. The file is then stored and an updated FS link 3 is sent to the file owner and other clients with file access. In a similar manner, the content of file storage SDNP node F.sub.9,1 in zone U9 is decoded by SDNP decode operation 1751M using state 920X, the state at time t.sub.1 when the file was created. The file is then transported over the SDNP network (not shown) to file storage SDNP node F.sub.7,1 where it is encoded by SDNP encode operation 1750H using zone U7 security credential as state 920Y corresponding to time t.sub.2. The file is then stored and an updated FS link 1 is sent to the file owner and other clients with file access. In this manner all three files are relocated and issued new security credentials and the clients with authorized access are issued new file storage read links based on updated FS links 1, 2, and 3.
(727) Another necessary maintenance function performed by the HyperSecure file storage system is the operation used to check for files lacking any live links, i.e. “zombie files.” The operation is similar to that of the refresh link operation except that the file storage server, rather than the client or file owner initiates it. In operation, each file storage server tracks the time since a file was last accessed. If the last operation on the file exceeds a specified interval, e.g. one month with no activity, the file storage server contacts the client or clients to confirm if the link is still active. The file storage server is able to contact the client using the same method employed to send the FS link to the client. At the time a file is stored, the file storage server retains a SDNP zip or pseudo-address of the client.
(728) Should no activity occur during the specified interval, the file storage server then contacts the SDNP signaling server with a request to reconfirm that the link remains active. The SDNP signaling server then plans the delivery route of the FS link verification request for each participating file storage server. Each file storage server then sends its request to the client via the SDNP network. Every participating SDNP client node responds with a confirmation that the file link is still present in the device. If the file link is confirmed, at that time the client has the option to perform a link refresh. If, however, no device responds, i.e. no active file read link remains, then the file storage server informs the administrator that a file link has gone stale or is missing, and after some interval such as one to three months, the unclaimed zombie file is permanently and irrevocably erased.
(729) Registered Communication—Another feature of SDNP communication made in accordance with this invention is the network's ability to deliver or store “registered communications”. Registered communication involves the HyperSecure delivery of communiqués or the HyperSecure storage of files as signed time-stamped messages including the ability to e-sign and e-chop the communication for purposes of establishing legal validity. Registered communication also includes the ability to send a “certified message” a handshaking method confirming receipt of a document or file using a signed or chopped time-stamped reply. All registered communication, while initiated by the SDNP application in a client device, is certified through Last Mile communication, i.e. communication across the Last Mile of the SDNP network. Any attempt by a client to fraudulently alter a stamp confirmation will result in a inconsistency between the message and the network record of the stamp confirmation, i.e. the return receipt.
(730) Because of the use of “state” in SDNP communication, i.e. where time and other unique variables are employed to establish the message specific security credentials in communiqués and in file storage, time stamping is an intrinsic feature of SDNP communication. This point is exemplified in SDNP communicator application window 1800 shown in
(731) In a registered communication, the communiqué generates an official stamp as part of the process. One example of a registered communication process is shown in
(732) In “message accepted” step 1806, the receiving party completes a series of steps needed to confirm their identity to access the message and to send an authenticated receipt confirming their acceptance of the incoming message and file. This process starts with receipt authentication operation 1807 where the receiving client is asked to confirm their identity. Without authenticating their identity, the receiving party will not be able to access the message, the message will be destroyed and the sender will be notified of the failed authentication step. In this manner, the sender may be alerted to the possibility that the receiving party may have had their device stolen. Once the identity is confirmed, the receiving party is asked in receipt authorization operation 1808 whether they wish to accept the incoming message and attachment or reject it. If the message in rejected the sender is informed.
(733) If the receiving party accepts the message by choosing yes, they must complete receipt administration step 1809 to sign for accepting the message, either by choosing an electronic signature (e-sig), and/or selecting a stamp/chop (e-chop). The sender can specify the options required. In some countries both a chop and a signature are required to be legally binding. A subsequent dialog box (not shown) directs the user to locate their signature or chop in the device's file directory. Alternatively, an audio/video recording may be used as confirmation. The recipient will be instructed what to read during the recording. Once the message is signed, then the message becomes visible to the recipient and the attached file becomes available for viewing and possibly for downloading depending on the sender's requirements.
(734) Upon accepting the document, a signed time-stamped message receipt 1811 identifying the message recipient, the embedded text and attached filename received, the data and time the message was received, and a signature comprising either an e-sig, an e-chop, an audio recording, an audio-video recording, or some combination thereof is sent to the send in acknowledgment operation 1810. In archive receipt option 1812 the sender has the opportunity to save a copy of the signed time stamped message receipt 1811 to the system's HyperSecure file storage system, for which the sender will receive file read link 1813 needed to recall the message. Alternatively, message receipt 1811 may be available for download into the sender's device.
(735) Issues with Encryption Based Security—Governmental security agencies argue that in today's world of corporate fraud, IP theft, cybercrime, hacking, criminal gangs, drug cartels, Mafioso, Yakuza, jihadists, and terrorists, any communication system providing callers with untraceable anonymous communication, i.e. systems using encryption to secure data and hide the identity of the caller (metaphorically, a payphone), represents a reckless and irresponsible business practice for the network operator, application developer, and device manufacturer.
(736) Unfortunately, it is true that communication relying on encryption to achieve security protects criminals and law-abiding citizens alike. As mentioned previously, this subject has become the focus of countless news stories about the criminal activity of ISIS terrorists and their attacks on Paris and Belgium using a phone application program called Telegram. This app facilitates secure communication using end-to-end encryption, also known as end-user based encryption. Because the decryption keys are held only by the two communicating parties and not by the intervening network or its operator, end-to-end encryption is especially troublesome for security agencies. Security agencies rallying against Telegram argue that large-key end-to-end encryption represents a national and even a global security risk enabling terrorists to operate secretly using open communications. Arguments favoring Telegram support personal privacy at any cost.
(737) The privacy debate arose again in regards to the Dec. 2.sup.nd 2015 shooting in San Bernardino, Calif., killing 14 and injuring 22 when a federal judge ruled in favor of the FBI ordering Apple to assist in “opening” a locked phone allegedly owned by the shooter. In a Feb. 17, 2016, Washington Post article entitled “Apple Vows to Resist FBI Demand to crack iPhone Linked to San Bernardino Attacks”. Apple and their CEO cited several reasons for their refusal to comply with the court order. The article is available online at (https://www.washingtonpost.com/world/national-security/us-wants-apple-to-help-unlock-iphone-used-by-san-bernardino-shooter/2016/02/16/69b903ee-d4d9-11e5-9823-02b905009f99_story.html),
(738) Most notably, Apple steadfastly maintained that it was unable to unlock its newer iPhones for law enforcement, even when officers obtain a warrant, because they are engineered in such a way that Apple does not hold the decryption key—essentially raising the specter of yet another example of the challenge of end-to-end encryption. Apple contended that only the phone's user—or someone who knew the password—would be able to unlock the phone. The government rebutted that it does not need them to unlock the encryption feature, just disable the features that wipes the phone's memory after ten unsuccessful login attempts. In an online statement, Apple's CEO Tim Cook countered such a step would dangerously weaken iPhone security. “Once created,” he wrote, “the technique could be used over and over again, on any number of devices. In the physical world, it would be the equivalent of a master key, capable of opening hundreds of millions of locks—from restaurants and banks to stores and homes. No reasonable person would find that acceptable.” He continued, “Opposing this order is not something we take lightly. We feel we must speak up in the face of what we see as an overreach by the U.S. government.”
(739) The last point advanced by Apple, that the US justice department was overreaching its authority, is a legal argument not a technical position, one echoing the sentiments of constitutionalists and privacy advocates that the state doesn't have the legal right to monitor communications or invade a person's privacy without probable cause. While the particular San Bernardino case clearly meets the bar of probable cause, the idea of creating a universal backdoor that can open any communication device it is argued, invites abuse by authorities. In their Feb. 23.sup.rd 2016 article, the publication The Atlantic agreed “Apple Is Right: The FBI Wants to Break Into Lots of Phones”. The same day The Guardian reported “FBI seeking access to a dozen iPhones, Apple claims”.
(740) Oddly, the same pro-privacy position was taken by the United States Congress. On March 1.sup.st in a follow up story by the Guardian entitled “Congress tells FBI that forcing Apple to unlock iPhones is ‘a fool's errand’”, US legislators accused the US Justice Department of overreaching and undermining privacy. “The path to hell starts at the backdoor,” Microsoft's general counsel, Brad Smith, told the RSA Conference in San Francisco. Smith challenged the computer security industry represented at the gathering to “stand up with Apple in this important case”.
(741) During the firestorm, numerous security experts including NSA whistleblower Edward Snowden promulgated the position that unlocking the phone is not as difficult as the FBI purported. Talking via video link from Moscow to the Common Cause Blueprint for a Great Democracy conference (March 8-9), Snowden said: “The FBI says Apple has the ‘exclusive technical means’ to unlock the phone. Respectfully, that's bullshit.” Before the case could even come to court, the FBI reported they had already found a way to break into the locked iPhone. In a Mar. 29, 2016, article Fortune Magazine reported “FBI Might Not Tell Apple How It Cracked the iPhone.”
(742) The legal and geopolitical fallout of the Apple-FBI case is far reaching. Following the FBI's lead, other nations are expected to insist on backdoors to all communication devices connected to their network—including phones carried by US citizens traveling abroad. Moreover, now that the iPhone has been successfully hacked, criminals will invariably discover or re-invent these methods to engage in new forms of cybercrime and identity theft. Not to be outsmarted by criminals, governments may seek to employ the same methods for expanding surveillance and espionage, and even various departments within the same government may use these methods to spy on the activities of one another. In related stories, various governments are considering limiting the level of encryption used in end-to-end communication.
(743) Collectively, these events clearly reinforce the realization that no obvious combination of existing security methods presently available in the public domain insure both security and privacy, at least not without also aiding criminals and terrorists. The problem stems from the exclusive reliance of encryption to achieve both network security and end-to-end security and its associated caller privacy. Increasing the security of text, voice, or files by increasing the bit size of an encryption key makes any communiqué more secure and difficult to crack. The enhanced security protects business and law-abiding citizens in maintaining security and privacy, and in combatting identity theft. Unfortunately, the same enhanced security indiscriminately protects criminals and terrorists from detection, allowing them to operate with impunity and invisibility.
(744) This point is illustrated in
(745) The key size tradeoff is complex. If the encryption key is too small, criminals can attack the network and its users as targets. If the encryption key is too large, criminals can use the network to hide their illegal activities and thwart investigator's efforts to detect ongoing fraud and malfeasance. In corporate environments, the company's security policy may reject end-to-end encryption altogether because it prevents monitoring of employee activities or complying with corporate investigations and IP lawsuits.
(746) Even determining what size key is breakable and what is secure is challenging, changing with evolution of technology. Referring again to table 1824, the number of possible combinations that must be analyzed in a brute force attack is calculated as a function of a cipher's key size. While a 16-bit key only has 65 k combinations, a 56-bit key has 10.sup.16 combinations, and a 128-bit key has more than 10.sup.38 combinations. A 256-bit key has combinations 39 orders-of-magnitude larger than the 128-bit key. Ignoring the use of pattern recognition, a brute force attack tries every combination to it cracks a code. In an EETimes article entitled “How secure is AES against brute force attacks?” (http://www.eetimes.com/document.asp?doc_id=1279619), the authors estimate the time required for a circa 2012 supercomputer capable of 10.5 petaflops to perform a brute force attack. A petaflop is a thousand trillion or 10.sup.15 floating point operations per second, or one thousand teraflops. As such, a 56-bit key requires only 399 seconds, a 128-bit key requires 1.02×10.sup.18 years, a 192-bit key requires 1.872×10.sup.37 years, and a 256-bit key requires 3.31×10.sup.56 years.
(747) The time required to mount a brute force attack also is changing. Since the article was written, the world's fastest computer has already tripled in speed. Reported in the BBC news article Jul. 30, 2015, entitled “Supercomputers: Obama Orders World's Fastest Computer,” investigators report the targeted speed of the next gen supercomputer is twenty times faster than the record holder, i.e. a machine capable of one exoflop, or a billion-billion floating point operations per second. This means that the time needed to crack encryption continues to erode with every passing year. Another newer approach to cracking encryption is to employ massively parallel processing, the same method as Bitcoin mining. Instead of having one super computer, using thousands or millions of computers in parallel allows an attack to proceed concurrently reducing the time proportionately. Today's fastest microprocessors already break 1.1 teraflops so thirty thousand best-in-class microprocessors operating conjunctively equal the world's fastest computer at the present time. Only one million microprocessors are needed to realize an exoflop computer. Dedicated ASICs can further erode the security while quantum computing promises to change compute power by many orders of magnitude.
(748) In conclusion, large key end-to-end encryption is not a good solution to achieve privacy and security in communications. The alternative approach enabled by the SDNP network and HyperSecure Last Mile communication as disclosed herein separates end-to-end encryption from network security. As shown in
(749) As described by table 1834 and illustrated by line segment 1830, these methods in various combinations achieve security equivalent to secret or top-secret encryption standards without exclusively relying on encryption. Since line segment 1830 is flat, it means there is no interdependence between end-to-end encryption shown on the y-axis, and network security shown on the x-axis. Instead, the network security level can be adjusted from case A to case D by applying a variety of SDNP security methods. These security operations are performed by SDNP software in a manner where the caller and callee are unaware of the security credentials used to transport the data packets across SDNP network 1831 and its various security zones. In particular, the conversing clients do not knowingly participate in any encryption Last Mile network's key exchange. As a distributed network, the use of encryption within the SDNP cloud is unrelated to Last Mile security, and no master keys exist for the system. As such, SDNP network 1831 security does not depend on end-to-end encryption performed by encryption 1026 and decryption 1032 to produce encrypted pipe or tunnel 1820.
(750) Encryption used by SDNP network 1831 need not utilize the same size keys as end-to-end encrypted tunnel 1820. As shown in the graph, commercial and corporate security applications of end-to end encryption can employ 128b key encryption (such as AES128) illustrated by dotted line 1835 even if the single-hop dynamic encryption within the SDNP cloud employs AES256. In fact, end-to-end encryption can utilize RSA or other cyphers without compromising network security. The SDNP network 1831 is still protected by AES encryption compliant with FIPS140-2 military grade security even if the end-to-end encryption tunnel 1820 is not. As described, the SDNP network 1831 protects against all outside cyber-assaults and man-in-the-middle attacks. The end-to-end encrypted tunnel 1820 protects callers from intervention from network operator and other “inside” hack jobs. In this regard, end-to-end encryption in this disclosure is primarily used for insuring caller privacy, not to achieve data packet transport security.
(751) Because the end-to-end encryption can be increased or decreased in strength or even eliminated without risking the network's security, the method is adaptable for a wide range of applications. For example, if the 128b key encryption illustrated by dotted line 1835 is too rigorous for small companies or personal use the number of bits can be decreased without giving up personal privacy. In military or government applications the encryption key length can be increased to 192b, 256b or even 512b as required. In this regard, the disclosed SDNP system overcomes the deficiencies with present day encryption based communication, offering features unavailable by any alternative application, device, or network.
(752) Security Administration—Another key feature of SDNP communication is its unique approach to security administration. Security administration is required in numerous situations including: Monitoring of employee communications performed in accordance with HR policies or employee investigations, Monitoring and recording of employee communications in support of financial audits, forensic accounting, or fiscal reporting, Documenting intercompany communications as part of a merger and acquisition transaction, Documenting intercompany communication as part of IP or corporate litigation, Complying with demands for communiqués and documents in accordance with subpoenas and criminal investigations, Complying with legal orders for account information, call and message monitoring, and file access in matters of national security.
(753) With proper authorization, a SDNP network administrator can facilitate access of SDNP network traffic to a designated “SDNP security agent” for the purpose of communication monitoring and data surveillance. The process by which a SDNP security agent is established and enabled involves a multi-tiered approval and authentication process necessarily performed in advance of the monitoring activity. To prevent abuse, no one individual is capable of independently commencing monitoring, not even a SDNP network administrator. Because of the dynamic nature of SDNP communication as a distributed network lacking central control, having no master network keys, and employing dynamic SDNP encoding and decoding executed using zone-specific security credentials operating in offline in DMZ servers, there is no mechanism to recover data or recall conversations ex post facto. Data resides within the SDNP network for only short durations, typically less than 100 milliseconds. As a distributed system, by design the SDNP network intrinsically lacks central control, without which even metadata of prior calls is unavailable. As such, the SDNP network only supports a priori security monitoring, meaning monitoring by a designated SDNP security agent must be established in advance of intercepting communiqués.
(754) Moreover, because of the dynamic nature of fragmented meshed communication within the SDNP cloud, no SDNP node within the cloud, i.e. beyond the SDNP gateway, carries the data packets of a complete conversation. Most nodes carry no more than 5% of the data and typically only for 10 ms at a time before the routing changes. In accordance with SDNP communication, dynamic routing constantly redirects communication through different media servers. As such, cloud access is not useful for recovery or monitoring of communiqués. Although the SDNP cloud's data packets can be captured, they comprise a useless jumble of unrelated sounds, data, conversations, and junk data. Instead, monitoring by a designated SDNP security agent can only productively occur in the Last Mile where the complete set of related data packets necessarily traverse, either within the client device or preferably in the SDNP gateway.
(755) An example of data packet routing in security monitoring is shown schematically in
(756) Security monitoring works for incoming calls as well. In
(757) The same method is applicable for monitoring of fragmented distributed file storage. Rather than capturing the fragmented data files, however, the security agent need only receive a copy of related FS links. Such as example is shown in
(758) The same monitoring mechanism works for multi-route Last Mile communication where data packets enter and leave the SDNP cloud through more than one SDNP gateway. This case is illustrated in
(759) Because SDNP monitoring activities are clandestine and essentially equivalent to an undetectable invisible conference call, it is critical to the SDNP system employs independent checks to approve and confirm the use of network monitoring and to designate and confirm the SDNP security agent authorized to execute the monitoring. The SDNP security agent can be any SDNP client except for the network administrator. As a safeguard against system corruption, any SDNP network operator or SDNP administrator is not allowed to act as a SDNP security agent, i.e. those administrating the network cannot subvert its capabilities for their own use even should they be threatened or blackmailed.
(760) The SDNP security agent may constitute an individual, a government agent, a government designated representative, or a law officer. The particular requisite qualifications of a designated security agent vary by company or country in accordance with applicable local law. A SDNP security agent's monitoring hardware may comprise a communication device or a computer server with recording, data storage, and sophisticated decryption capability. All communication sent from the SDNP network to the designated SDNP security agent is transported with the same HyperSecure communication as the client's communiqués themselves, and therefore security monitoring does not compromise the confidentiality of the call or the caller's privacy except for the monitoring performed by the authorized security agent.
(761) Moreover, the implementation of monitoring and the allowed capabilities of an authorized SDNP agent does not compromise network integrity and security in a means whatsoever. No operating details or DMZ shared secrets are revealed to the network operator or to any security agents—operation of the SDNP system occurs automatically and autonomously without the intervention or involvement of human operators while the DMZ servers provide security using zone specific credentials not available through online access. Security monitoring, therefore, does not degrade system security or render the SDNP network vulnerable to cyber-attacks.
(762) Data payloads are delivered to SDNP security agent in the same form they are created by the caller. As part of delivery to the SDNP security agent, all network SDNP encoding is decoded so that no network security provisions are present in the delivered data packets. If, however, the client employs end-to-end encryption, the SDNP security agent will have to break the client's end-to-end encryption unless the client agrees in advance to share end-to-end decryption keys with the network or to use and independent key server utility accessible by the SDNP network. To reiterate, such end-to-end encryption and decryption keys are primarily included in the SDNP method for privacy purposes and are unrelated to any encryption used in the SDNP dynamic encoding function.
(763) To minimize the risk of monitoring abuse, SDNP administration used to establish and authorize a designated SDNP security agent to monitor a client or group of clients is a multistep process. While the SDNP system includes provisions for performing monitoring, the legal application of this feature is the responsibility of the network operator, the network administrator, and authorizing agency or agents. Together these parties are personally responsible to insure monitoring is performed legally and in compliance with the laws of the country in which the monitoring is performed.
(764) The need for monitoring could arise from any number of situations. In a company, a whistleblower complaint or a claim of sexual harassment could trigger a HR investigation or precipitate forensic accounting. A court subpoena associated with a litigation matter (potentially including a gag order) may also require monitoring. In corporate matters, communication using the company SDNP network is generally limited to company communiqués and does not cover private and personal communications. In most countries, private communication is protected unless criminal intent is suspected. In cases of national security or law enforcement actions, both public and private SDNP accounts of a caller may be subject to monitoring. In such cases, the corporate SDNP network operator for the company would implement the monitoring process for company communications, while independent telecommunication SDNP network operator would be the only provider in a position to execute monitoring of the caller's private communications. In some countries, the government must present a judge-approved subpoena to commence monitoring of private citizens while in other countries a government may assert the authority to monitor any and all private communication on a de facto basis. In cases of international communication, it is more difficult to determine which laws are applicable and what the network's position on enabling call monitoring should be.
(765) One example of the AAA process used to enable monitoring is illustrated in
(766) In authorization step 1863, the network administrator 1850 identifies a candidate security agent 1840 recommended for performing the monitoring function using exemplary dialog box 1864. In corporate cases, the individual may be an HR director, legal counsel, a member of the audit committee, and independent accounting firm representative, or an independent investigator. In legal cases the security agent may be a law officer, district attorney, FBI agent or other duly appointed investigating committee member, e.g. in cases of government malfeasance such as a special prosecution committee investigations panel. The system then checks with SDNP name server 1714 to insure that the security agent has an SDNP account and that they comply with the rules specified by the company or network operator. In some cases involving national security a follow-on investigation of the proposed security agents credentials and criminal record may be performed before they are approved.
(767) Once the security agent is approved, in authorization step 1865 the request for monitoring is forwarded to authorizing agents 1851A, 1851B, and 1851C, who review the information presented in dialog box 1866 including the name of description of the subject, the name or position of the security agent tasked to perform the monitoring, the expected duration of the monitoring probe, and the reason for the probe. Each authorizing agent can accept or reject the request. The rules of the network operator or company then determine if the monitoring operation is approved based on unanimous approval of the authorizing agents or by simple majority. The identity of the authorizing agents may be known, as in corporate cases, or in criminal cases their identities may remain anonymous protected by the anonymous communication features of the SDNP network.
(768) Once the monitoring is approved, in administration step 1867, the database 1868 of clients is updated in name server 1714 to tag the SDNP client to be monitored and to identify the SDNP client authorized as the security agent, in this example the shaded row of data. The SDNP addresses in this database are updated together on a daily basis when the SDNP addresses are shuffled to maintain the same relationship between the client being monitored and the designated security agent. Once the date of the probe expires, the monitoring link is automatically severed. In administrative step 1869, the SDNP security agent 1840 is sent a link enabling them to receive all ongoing communication of the identified client being monitored. Their use of this information is not a matter of SDNP network operation. The unauthorized release of a person's private information by the security agent may constitute a crime for which the security agent is wholly responsible.
(769) Through this inventive monitoring method, the SDNP network is thereby capable of supporting criminal investigations of malfeasance and potential terrorist activities while maintaining a secure communication medium for law-abiding citizens. The SDNP network is able to securely deliver to authorities private client communication in compliance with legal court orders without risking the privacy of innocent civilians or compromising the security of the SDNP global communication network. Since no backdoor or master key was employed in honoring the court order future communication over the SDNP network remains anonymous and HyperSecure. In this manner the secure dynamic communication network and protocol and its HyperSecure Last Mile communication is able to offer security features not available by any other means and completely avoids the risk of aiding criminality and terrorism created by the excessive reliance on end-to-end encryption employed by OTTs and virtually every messenger and communicator app.
(770) Overcoming SS7 Vulnerabilities—If the Apple-FBI controversy was not enough trouble for the communications and security industries, a 60 Minutes episode (http://www.cbsnews.com/news/60-minutes-hacking-your-phone/) revealed severe security vulnerability with Signaling System 7 or SS7, the signal control channel for conventional wireless telephony. As clearly demonstrated in the show, the SS7 vulnerability potentially exposes every smartphone and connected device to packet sniffing and cyber-attacks, allowing eavesdropping of wireless conversations and viewing of SMS text, attached files, and pictures simply by knowing a person's phone number.
(771) Signaling System 7 is a telephony signaling protocol developed in 1975 used in all forms of digital telephony globally. It comprises a message transfer part or “MTP” operating on PHY layer 1, data link layer 2, and network layer 3 to handle the routing of calls. End-to-end routing is managed using a signaling connection control part or “SCCP” operating at the transport Layer 4. The protocol also includes a number of application Layer 7 functions involved in billing, roaming, and call authorization. The SS7 protocol, albeit unavoidably necessary, is extremely vulnerable to attack and represents a severe risk to securing conventional telephony.
(772) In April 2016 (https://en.wikipedia.org/wiki/Signalling_System_No._7) a U.S. Congress oversight committee reported “the applications for this vulnerability are seemingly limitless, from criminals monitoring individual targets to foreign entities conducting economic espionage on American companies to nation states monitoring US government officials . . . . The vulnerability has serious ramifications not only for individual privacy, but also for American innovation, competitiveness and national security. Many innovations in digital security—such as multi-factor authentication using text messages—may be rendered useless.”
(773) SS7 cyber-attacks essentially come under the category of packet sniffing, intercepting both content and metadata by using the specific formatting of SS7 information as a guide. The SS7 protocol essentially provides an information template by which packet information can be interpreted. As shown in
(774) The SIM card also includes a “mobile country code” or MCC a three-digit number to identify the country where the SIM card originated. When placing international cellular phone calls from a mobile phone, the MCC is required as part of the dialing sequence. Examples of MCCs include 310-316 for the United States, 234-235 for the United Kingdom, 460 for China, 208 for France, 250 for Russia, 262 for Germany, 302 for Canada, and 724 for Brazil. The MCC is used in conjunction with a “mobile network code” or MNC to identify the network provider that issued the SIM card. A complete list of codes is listed online at https://en.wikipedia.org/wiki/Mobile_country_code. The SIM card also includes a 15-digit “mobile station international subscriber directory number” or MSISDN to uniquely define the subscriber and the type of network the SIM operates on. The SIM card also holds a user phone number and a SMS text directory including a record of incoming and outgoing calls and texts sent along with time and date information. In recent years, carriers have begun using specialized SIM cards with so-called secure elements to store credit card credentials in order to facilitate mobile payments.
(775) Because the MCC, MNC and MSISDN codes are transmitted as part of the connection process, the home country and carrier of any SIM card and the subscriber's associated phone number can easily be identified by SS7 intrusions and packet sniffing. The transmitted data 1881 can easily be used to trace the identity of the caller through phone directories, online information, or social media, i.e. through profiling. Once identified and correlated, the phone number and SIM can be used to monitor the activities of the subscriber no matter where they may travel globally. 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, captured and stored for subsequent deciphering attempts.
(776) Aside from metadata and content, a caller's location is also compromised by the SS7 vulnerability. In any cellular network, the phone sends out messages to the local cell towers identifying it is available in the particular cell. These registration packets are sent at regular intervals. Monitoring these packets allows the location of a phone with a particular SIM card to be located even if the phone is not in a call and even if GPS is turned off. In such a manner, the location and travel of a subscriber can be tracked without their knowledge.
(777) Despite SS7 intrinsic vulnerabilities, HyperSecure Last Mile communication made in accordance with the secure dynamic communication network and protocol repels SS7 attacks by obscuring meaningful call data in the Last Link. In particular, HyperSecure Last Mile communication offers significant security advantages over conventional telephony or OTT Internet communications including the following: HyperSecure Last Mile communication does not reveal the phone number or IP address of the party being called or messaged, even if that party is not a SDNP client. HyperSecure Last Mile communication does not identify if sequential data packets are part of the same call or represent unrelated data packets with differing destinations. By hiding the call specificity of data packets, HyperSecure Last Mile communication obscures metadata regarding call times. HyperSecure Last Mile communication dynamically encodes payloads, preventing unauthorized access to packet contents and protecting the privacy of voice, video, and text communication as well as pictures, files and other content.
(778) So as described, communication using the disclosed secure dynamic communication network and protocol and HyperSecure Last Mile communication is not affected by SS7 vulnerability. Since SDNP communication occurs using its own protocol and is carried by encoded payloads, no call data or content can be extracted from an SDNP data packet even for packets carried over an open unencrypted channel such as 2G, 3G, and 4G/LTE telephony. Packet sniffing is, therefore, ineffective in launching cyber-attacks against SDNP coding and fragmented data transport.
(779) SDNP Camouflaging—Given the foregoing, the only impact SS7 vulnerability has on SDNP communication is in revealing a caller's location. Because the phone number in a carrier's SIM is linked to each user's identity, whenever the cell phone is turned on it necessarily communicates with the nearest cell phone towers even when no phone call is occurring. This cell tower information can then be used to triangulate a user's location and trace a subscriber's travels even with GPS turned off. Since such unauthorized tracking relies on SS7, devices using a conventional carrier's SIM cards are vulnerable to location tracking, even those operating as SDNP clients.
(780) As shown in simplified network schematic
(781) In operation, SDNP camouflaging hides the true identity of the owner by employing a SIM card 1882, known only to the SDNP network operator. As such, the phone number contained within the SIM card is used to establish a PHY Layer 1 and data link Layer 2 connection 28B between cell phone 32 and cell tower 25B but not to provide routing. Instead the data packet source and destination addresses for Last Mile routing are managed by SDNP app 1335A and SDNP gateway 1601A in accordance with instructions from SDNP signaling server 1603A.
(782) Routed through SDNP gateway 1601A, calls from the SDNP app appear with a different number than the SIM card number. This translation from the physical SIM card number to the SDNP phone number is performed by SDNP name server 1604A, which during call routing translates the SDNP phone number into the SIM phone number in accordance with translation table 1885, thereby camouflaging the physical SIM card number to any users. Using SDNP camouflaging, the true identity of the phone's owner is completely hidden. To place a call to the SDNP client, outside callers place their call to the SDNP # even if they are not SDNP clients themselves. The SDNP network automatically routes the call to the SDNP client without ever revealing the SIM card phone number. Similarly a SDNP client places a call out to non-SDNP callee, the call recipient sees an incoming call from the SDNP #, not from the SIM card number. In this manner, the SDNP performs a function in telephony similar to that of a NAT gateway in Internet communication except that the SDNP system is a real time network and the Internet is not.
(783) Because the true user identity of phone 32 is never revealed by call 28B, triangulating the location of the phone is not useful because its user and all communication remain anonymous. As such, tracking the location of unidentified cell phones is not beneficial to hackers, and circumvents SS7 vulnerabilities. In the event that an SDNP client is traveling internationally, the traveler can purchase a local prepaid SIM card and link it to their SDNP number. The SDNP subscriber will still receive calls placed to their SDNP phone number, but the Last Link will occur using the local SIM card thereby avoiding roaming charges. In this manner a single SDNP phone number functions as a global number without long distance expenses.
(784) SDNP Subnets—Using its unique SoftSwitch software-based communication nodes, the SDNP communication cloud can be deployed remotely across any network of interconnected computers, private or publically hosted. Examples of server networks include privately owned publically leased networks such as those hosted by Microsoft, Google, and Amazon.
(785) Access to the two independent clouds is made through a common communicator application UI/UX 1920. Access to each cloud is compartmentalized in separate dialog sandboxes 1921A and 1921B. Although information may be downloaded from personal account sandbox 1921A into the phone, exporting data from business account sandbox 1921B depends on the business and the company's security administration.
(786) Connecting a device to the SDNP clouds requires installation of a SDNP app, either as software or firmware, into the device. Installation involves (i) downloading the application (ii) confirming the device identity with a SDNP network generated authorization code (iii) establishing personal identification credentials, and (iv) receiving approval to join a specific SDNP cloud. Once activated, the SDNP application creates HyperSecure Last Mile connection to the independent SDNP clouds. In many cases identity validation and user authentication for the business account are more elaborate than that needed for personal account access, and may entail multi-factor authentication methods.
(787) Because of SDNP communication is software-based, with distinct and separate security credentials for each communication cloud, there is no interaction between any installed SDNP communication networks even when hosted by the same servers. With zone specific security credentials uniquely defining each customized SDNP cloud, no two SDNP clouds are alike and are therefore unable to share data directly. Beneficially, multiple SDNP clouds can co-exist within the same server or server network with no risk of data leakage. Access to a business network is controlled, as defined in accordance with the cloud owner's requirement. As such, comingling of the two accounts and communication clouds is prohibited when sharing common host servers, operating with the same security as if two different phones were required to connect to the two separate networks. The autonomy of zone specific SDNP clouds, or “subnets” is further demonstrated in
(788) SDNP communication is not limited to privately leased publically available servers but may also be customized for different types of corporations or government agencies. In fact, private corporations often prefer to host their own networks, especially in business critical applications. Examples of private networks include FedEx, Walmart, IBM, etc. For confidentiality's sake, networks used by research institutes, universities, and medical centers are also frequently self-hosted. Private server networks are also employed to host global business cloud applications such as SalesForce.com, Box.com, Dropbox, eTrade, SAP, etc.; ecommerce platforms and comparison-shopping networks like eBay, Amazon.com, Priceline.com, e-Insurance; media streaming services like YouTube, Amazon Prime, Netflix, Hulu, Comcast Xfinity; and social media such as Facebook, Twitter, and Snapchat.
(789) In larger corporations, the IT department may choose to operate separate networks for the parent entity and its subsidiaries. In many privately hosted businesses, however, infrastructure costs are considered an important factor in network design. Rather than supporting two completely different hardware based systems, the SDNP system offers a company the ability to deploy its networks using a combination of separate and shared server resources. As illustrated in
(790) The multi-profile feature of the SDNP app using Last Mile HyperSecure security credentials to enable or prohibit access to multiple SDNP clouds supports a limitless number of account profiles from a single SDNP app. In
(791) SDNP communication is equally applicable in high security and restricted access networks needed for government and security. For example, in the United States security restricted communication is needed by a variety of departments including local and state law enforcement, FBI, US National Guard, U.S. National Security Agency, U.S. armed forces (separately and jointly), the U.S. state department, along with congressional and legislative server networks. Other countries similarly host separate networks for various government agencies.
(792) To support access to a specific cloud on a “need-to-know” basis, nested subnet architectures can be implemented using SDNP communication methods and technology. For example, in