Patent Application
20180115520
Current networks rely on a variety of traditional components that were not created with sufficient security controls, making it very complex to build any type of secure architecture. These insecure framework components make it nearly impossible to properly secure services on computer networks (like web sites, file shares, etc.) from large classes of attacks or to protect users of those services from malicious attacks.
When a user starts a connection to a service, for example a secure web service, the first thing that happens is the user receives a location based on the service name, provided through Domain Name Services (DNS), and routing services. Traditionally critical routing and security information is simply handed out without any validation or integrity checking. This information includes DNS Name to IP-address mappings and routing information on how to reach the IP-address in question. These IP-addresses are used to both route information to the device and act as the identifier of a device on the network. Unfortunately, since IP-address can easily be duplicated, spoofed, or otherwise compromised multiple types of attacks can be used including causing parties in the communication to connect to malicious hosts. Another problem with existing service information systems is that the information can be used by malicious and unapproved users, opening up attacks on the services including Denial of Service (DoS) attacks, network probes, and Zero-day attacks.
After receiving the location and routing information, the user now connects to the secure web service traditionally over TCP/IP. However, TCP/IP is vulnerable to a multitude of attacks. Once a service is started it will accept a number of packets from anyone on the network. For example, TCP/IP will accept an entire connection start-up and only the application layer of the network stack might request a username/password. Even secure protocols, such as IPSec, will accept 2-3 packets before the authentication of the user is verified, and TLS will accept the entire connection before authentication happens. This open period allows attackers to detect the service is available, probe for version numbers, and send any number of attacks that will attempt to be processed.
After the user is connected to the secure web service, they then commonly rely on third party certificates to validate the identity of the server. Unfortunately, there are thousands of signing authorities who are trusted to create legitimate certificates for any server on the Internet. Because there are so many, malicious parties can often get legitimate looking but invalid certificates thereby voiding any security provided by the certificate system. In addition, the only means to mark a certificate as bad is done through Certificate Revocation Lists (CRL). Currently there are potentially a million certificates on CRLs, making checking the list so slow that most browsers simply turn off the checks. This means that an attacker can potentially keep compromising connections for months after the certificate is discovered. In addition, although this system helps validate the service is legitimate, commonly nothing is done to cryptographically validate the user. Configuration of client certificates is so complex and cumbersome that companies just turn off client certificates, falling back to simple username and password.
To prevent some of this risk, services are commonly firewalled or isolated behind a Virtual Private Network (VPN). Traditional Virtual Private Networks are built to connect specific devices (laptops, servers, etc.) to an entire internal organizational network. While preventing some of the malicious attacks to both the services and users of the network, it opens the organizational network up to attacks through the VPN tunnel. Ideally, the connectivity between users accessing organizational services would be limited to just the services that were needed; however, VPNs commonly open up the entire network giving a level of exposure to the internal organization that is unnecessary. In addition, VPN tunnels are designed to connect to a single location so if an organization has some resources in the cloud, some on-site, and some at a remote office the user either has to tunnel all the traffic through a single location, which causes extra costs and loss of performance, or has to manually switch between VPN tunnels for each destination. Neither of these VPN solutions help prevent a number of attacks including Man-in-the-Middle attacks or DoS attacks. Finally, even VPNs traditionally do not control user access in a cryptographically verifiable manner, relying again on username and password to grant access, which are not cryptographically provable and vulnerable to a number of authentication attacks.
The next level of solutions organizations consider, is to deploy something like IPSec to all critical endpoints requiring secure keying material be distributed (usually manually) to every end-point. Commonly keys are managed and created at a central location (i.e. central management console) and then handed out to the parties that need them as communication is expected or established. This architecture places all the critical information of the network at a single centralized location, which should it be attacked would compromise everything on the network. In addition, this architecture assumes that every node will be able to connect to the management console before establishing communication. When nodes are distributed across the world, across different organizations, or exist in isolated unconnected networks this eliminates all functionality provided by the central management console. Also, the key management challenges force enormous burdens on the network administrators, and yet, still don't address many security issues including DNS, IPSec service probes, trusted certificates, etc.
Service—any group of functions available over a network. Examples include web services, database services, filesharing, FTP, etc. The service need not be offered over a single IP port (i.e. FTP) or on a single server (i.e. a cluster of web servers).
Agent—Software or circuitry that acts on behalf of an end-point or device to perform a set of functions. The agent can be written in any common programming language, embedded into a chip, or otherwise delivered for multiple operating systems or components.
User Agent or Client Agent—the software that acts on behalf of the user or client. client, client agent or user agent can be used interchangeable, unless specifically noted. For services that communicate in a traditional client-server architecture the client agent performs a set of functions for the client. In a peer-to-peer architecture the client or user agent may directly access functionality offered over the network through the COI.
Service Agent—the software that acts on behalf of the service. The service agent can exist on the same device as the service or be placed on a gateway or relay device in between the service and the client agents accessing the service.
COI—Community of Interest is a group of zero or more user agents accessing zero or more services. The services and user agents are added to the COI by the Network Owner. The COI becomes a virtual overlay controlling access and service discovery across any type of network (i.e. LAN, WAN, etc.).
Network Owner—the software that manages one or more COIs. In a distributed model any user agent can become a Network Owner. In some other embodiments the Network Owner software may be more centralized managing COIs across an entire organization and may or may not also as a user agent. The centralized approach would more closely resemble a central management console (CMC).
EIS—Encrypted Information Server an information distribution server allowing clients to query and post a variety of both public and private data records in a secure manner. In one or more preferred embodiments the EIS is implemented primarily on top of a traditional DNS server and architecture. However other embodiments could include a directed messaging service or publish/subscribe structure.
Service Provider—Any agent that offers one or more services for inclusion into a COI. The services offered do not have to be secure or behind the SPProtocol. Service providers can offer services from any network location (LAN, WAN, Cloud, Disconnected) etc.
SPProtocol—For the purposes of some embodiments the basic protocol follows that as described in “MinimaLT: Minimal-Latency Networking Through Better Security” by Petullo, W. M. ET AL. (attached hereto as Appendix A). The technology herein describes additions to the basic protocol structure to support different types of connections and first packet data. The resulting protocol will be called the SPProtocol for the purposes of this description.
User Device—Any device a user or automated process can interact with including Smart Phones, Desktops, Laptops, Tablets, embedded processors (thermostats, IoT devices), etc.
Communication Protocol—Any method used to exchange information between two parties. Examples include IPSec, TCP/IP, SPProtocol, etc
Secure Service—Any end-point that can accept secure connections. This would include services that use the SPProtocol as a communication library and talk a secure protocol directly. Although the SPProtocol is one or more preferred embodiments, any communication protocol could be used, ideally which provides encryption. Secure service may also include services that are behind a gateway device or service that decodes the secure traffic and transfers the data to the services behind the gateway (See
Architectural Integration Points—These are well defined interfaces into an architecture that allow external software to interact with the system. For example, if an organization already maintains a list of users, an integration point may allow existing user lists to be imported and used by the system. Commonly these integration points are defined by an Application Programming Interface or other specification for low level integration or through a set of scripts or tools for higher level integrations.
Perfect Forward Secrecy—provides protections such that when members of a group are removed the privacy of future messages or communications remains intact and the members who were removed are excluded.
Perfect Backwards Secrecy—provides protection such that when a new member is added to a group they cannot see previous messages.
The detailed description that follows is represented largely in terms of processes and symbolic representations of operations by conventional computer components, including a processor, memory storage devices for the processor, connected display devices and input devices. Furthermore, some of these processes and operations may utilize conventional computer components in a heterogeneous distributed computing environment, including remote database servers, computer servers and memory storage devices.
It is intended that the terminology used in the description presented below be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain example embodiments. Although certain terms may be emphasized below, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such.
The phrases “in one embodiment,” “in various embodiments,” “in some embodiments,” and the like are used repeatedly. Such phrases do not necessarily refer to the same embodiment. The terms “comprising,” “having,” and “including” are synonymous, unless the context dictates otherwise. Such terms do not generally signify a closed list.
“Apparent,” “associated,” “at least,” “automatic,” “based,” “better,” “between,” “capable,” “compatible,” “complete,” “conditional,” “configured,” “consecutive,” “corresponding,” “current,” “dark,” “each,” “encrypted,” “existing,” “first,” “having,” “higher,” “in,” “intermediate,” “internal,” “local,” “lower,” “maximum,” “minimum,” “mobile,” “new,” “nominal,” “on,” “other,” “partly,” “performed,” “proximate,” “published,” “real-time,” “recognized,” “remote,” “resident,” “respective,” “responsive,” “scalar,” “scheduled,” “second,” “selected,” “sequential,” “several,” “target,” “tentative,” “third,” “triggered,” “usable,” “while,” “with,” or other such descriptors herein are generally used in their normal yes-or-no sense, not merely as terms of degree, unless context dictates otherwise. In light of the present disclosure those skilled in the art will understand from context what is meant by “remote” and by other such positional descriptors used herein. Terms like “processor,” “center,” “unit,” “computer,” or other such descriptors herein are used in their normal sense, in reference to an inanimate structure. Such terms do not include any people, irrespective of their location or employment or other association with the thing described, unless context dictates otherwise. “For” is not used to articulate a mere intended purpose in phrases like “circuitry for” or “instruction for,” moreover, but is used normally, in descriptively identifying special purpose software or structures. As used herein, the term “contemporaneous” refers to circumstances or events that are concurrent or at least roughly contemporaneous (on the same day, e.g.).
Reference is now made in detail to the description of the embodiments as illustrated in the drawings. A computer implemented method is disclosed that allows clients, either user agents or service agents, to securely find and connect to services. The method relates to key management, secure protocols, secure information sharing, architectural integration points, and the like. While embodiments are described in connection with the drawings and related descriptions, there is no intent to limit the scope to the embodiments disclosed herein. On the contrary, the intent is to cover all alternatives, modifications, and equivalents. In alternate embodiments, additional agents, or combinations of illustrated agents, may be added to, or combined, without limiting the scope to the embodiments disclosed herein. For example, the embodiments set forth below are primarily described in the context of a distributed model where it is assumed where any user agent can become a Network Owner. However, these embodiments are exemplary and are in no way limited to such a distributed model. For example, other embodiments may utilize more centralized control, in which case the Network Owner may focus on COI management and may or may not also act as a user agent.
The embodiments described herein allow clients (user agents and services) to securely communicate.
In some embodiments, the user device or user agent may route all of the traffic not destined for specific secured services to the Filtered Internet, and in other embodiments only specific domains, IP-addresses, or traffic during specific periods would be routed to the Filtered Internet. Since no static routing has to be included for specific secured services, the user agent can route traffic directly to different secured services at the same time even if the services exist in different physical networks, at different organizations, or even use a different local network interface (i.e. one secured service exists on local mesh network while a second service is accessed over the WiFi).
In addition, if all traffic out of the User Device is routed to the Filtered Internet gateway, the gateway can perform common internal intrusion detection functions (like looking for data being sent over known back door ports or protocols) even through the user device is not on the organizational network. This technique could work across all types of devices including IoT devices, and embedded devices.
Client device 200 may also include one or more instances of processing units 202, memory 204, user inputs 208, and display hardware 212 all interconnected along with the network interface 206 via a bus 216. Memory 204 generally comprises a random access memory (“RAM”), a read only memory (“ROM”), and a permanent mass storage device, such as a disk drive.
Memory 204 may likewise contain one or more instances of operating systems 210, web browsers 214, and local apps 224. These and other software components may be loaded from a non-transitory computer readable storage medium 218 into memory 204 of the client device 200 using a drive mechanism (not shown) associated with a non-transitory computer readable storage medium 218, such as a floppy disc, tape, DVD/CD-ROM drive, flash card, memory card, or the like. In some embodiments, software components may also be loaded via the network interface 206, rather than via a computer readable storage medium 218. Special-purpose circuitry 222 may, in some variants, include some or all of the event-sequencing logic described herein (including transistor-based circuitry within an imaging module 260 configured to capture interior image data that depicts a borehole as described herein, e.g.).
Server 300 may also include one or more instances of processing units 302, memory 304, user inputs 308, and display hardware 312 all interconnected along with the network interface 306 via a bus 316. Memory 304 generally comprises a random access memory (“RAM”), a read only memory (“ROM”), and a permanent mass storage device, such as a disk drive.
Memory 304 may likewise contain an operating system 310, hosted website 320, and aggregation module 326. These and other software components may be loaded from a non-transitory computer readable storage medium 318 into memory 304 of the server 300 using a drive mechanism (not shown) associated with a non-transitory computer readable storage medium 318, such as a floppy disc, tape, DVD/CD-ROM drive, flash card, memory card, or the like. In some embodiments, software components may also be loaded via the network interface 306, rather than via a computer readable storage medium 318. Special-purpose circuitry 322 may, in some variants, include some or all of the event-sequencing logic described below.
As shown, server 300A includes (in a memory 304 or other storage medium 318 thereof, e.g.) at least a long-term service public key 441A paired with a long-term service private key 442, an encrypted service record (ESR) 443A containing particular information 449 as described below, a publish key 444, and one or more modules 445 (as components of special-purpose circuitry 322, e.g.). As shown, entity 410 includes one or more instances of antennas 411, of long-term service public keys 441B, or of net view access keys 448 for facilitating secure communications. Likewise entity 420 includes one or more instances of antennas 421, of long-term service public keys 441C, or of encrypted service records 443B by which to attempt to access the one or more servers.
Operation 530 describes configuring a first entity with a first net view access key and the long-term service public key (configuring entity 410 with another copy of the long-term service public key 441B as well as a first net view access key 448 that matches or is paired with publish key 444, e.g.). This can occur, for example, in a context in which entities 410, 420 are each an instance of client device 200 having one or more processing units 202 for communicating with the one or more servers 300 (with server 300A via a respective network interface 206 and one or more wireless linkages 461, 462 across a free space medium 468, e.g.). Alternatively or additionally, one or more modules 445 may be configured to perform operation 530 (in lieu of or in conjunction with a processing unit 202, e.g.). As used herein, an “entity” refers to one or more local or distributed devices (peripherals or client devices 200, e.g.) in use by or for one or more automated processes or human users 115.
Operation 545 describes transmitting a published encrypted service record that includes the first connectivity information encrypted to the first net view access key and signed by the first long-term service private key to the first entity (one or more modules 445 transmitting an instance of a published encrypted service record 443 that includes the first connectivity information 449 encrypted to the first net view access key 448 and signed by the first long-term service private key 442 to the first entity 410, e.g.). This can occur, for example, in a context in which the published encrypted service record 443 is widely available but not usable outside the first entity 410 (i.e. by virtue of being decryptable only via the net view access key 448); in which the one or more servers 300 has confirmed a provenance of the encrypted service record 443A by signing the encrypted service record 443A using the first long-term service private key 442; in which the first entity 410 could not otherwise be confident in the provenance of an ESR 443 that has arrived at the first entity 410; and in which the first entity 410 is thereby able to trust the one or more servers 300 much sooner (without needing to receive and validate new certificates from the server 300A, e.g.) or in which another entity 420 having a valid long-term service public key 441C and ESR 443B would otherwise be able to gain access into server 300A.
As shown, server 300B includes (in a memory 304 or other storage medium 318 thereof, e.g.) at least a short-term service public key 631 paired with a short-term service private key 632, a long-term service public key 441 paired with a long-term service private key 442, one or more determinations 644 as described below, one or more client public keys 611B, authority information 646 (describing at least one of the one or more authorities), and one or more modules 645 (as components of special-purpose circuitry 322, e.g.). An authority 405A trusted at least by server 300B may be implemented as a Network Owner (that owns at least network 602, e.g.) having a network owner public key 681 paired with a network owner private key 682.
As shown entity 610 includes (in a memory 204 or other storage medium 218 thereof, e.g.) one or more instances of a user public key 601 paired with a corresponding user private key 602 (for long term use over the course of months or more, e.g.), of a client public key 611A (identical to client public key 611B) paired with a corresponding client private key 612 (for short term use during a single session, e.g.), a service locator record 614, authority info 616 (describing at least one of the one or more authorities 405), an identity record 617, and a session key 618. Entity 610 may trust an authority 405B of its own or may be configured to use authority 405A (as a shared authority). A signal 667 from entity 610 may include one or more such data items as described below. As shown entity 620 may have one or more instances of identity records 627 or of session keys 628 because of which entity 620 is a security risk. In some variants, suitable security protocols are described such that entity 610 receives a signal 668 in reply to a proper request and that entity 620 receives no reply whatsoever to a superficially similar request.
Referring to
When a Network Owner configures a COI, several components can be used to assist in setting up the included services and member users. The first is a Service Provider at item 1203, which provides a list of services that can be attached. The Service Provider could offer services on the local organization network (i.e. at items 1291-1293), which may be on a single device or across multiple devices; services started on a Cloud network at item 1294; or third party services, which are not managed by the organization. Each service may be configured from the Network Owner with a set of policy requirements, which might include logging data, authentication, etc. In embodiments where the communication protocol requires authentication, the authentication can be directed to a specific Authenticator at item 1202, thereby ensuring that users are authenticated by external resources (i.e. LDAP or SAML) or by additional factors (i.e. face recognition or fingerprint) prior to access. When adding User Members to a COI the Network Owner can individually invite users or can specify a Validator at item 1201 where any user profile that has a particular attribute, verified with a cryptographic certificate issued by a trusted party, can join the COI. These Architectural Control Points (i.e. Validators, Authenticators, Policy Specifications) allow the COI to be dynamically created while allowing an organization to maintain a similar level of control to what is typical in traditional networks.
In one or more preferred embodiments, once the keys, policies, and service locations for the system have been distributed, communications may be established using a secure protocol, such as the SPProtocol at item 1280. The SPProtocol not only provides encryption of the communication channel, it also uses keying information prior to connection acceptance to automatically provide key based authentication and access control. In addition, the SPProtocol may provide several performance improvements and additional security improvements including support for detailed and traceable auditing of every packet back to a specific user agent. Organizations which then use the cryptographic identities (approved through validators or by the Network Owner knowledge) for all connections can then trace to a specific User Profile every packet and data block on the network. Unlike traditional IP protocols, which cannot be accurately traced to a user login or device; attacks, fraud, or misuse of the network can be accurately tied to a user agent and handled accordingly.
In one or more preferred embodiments, an EIS (at item 1210, e.g.) offers data blocks for services and user agents to validate each other (See
In one or more preferred embodiments, the Network Owner (implemented as user agent 1230, e.g.) for a COI at item 1220 controls both who is a member of the COI and which services are included in the COI. This information is then distributed through an Encrypted Information Server (i.e. EIS at item 1210) that can disseminate information, but is not trusted with knowledge about the information being exchanged or given the ability to change the information. The Network Owner (implemented as user agent 1230, e.g.) also delegates specific controls to other parties including:
While a Network Owner could manage an entire organization, one benefit over traditional systems is that any user agent on the network can become a Network Owner allowing distributed control of resources, distributing risk across different administrative or user agent groups within the network, allowing localized control of isolated resources, and allowing multiple organizations or users from different network domains to use resources no matter the physical location of the resource. Combined with a single chain of trust which flows from the Network Owner a much higher security level can be maintained.
Communication within the system is based on public/private key pairs. The discussed technology uses keys (public portion) for identity and discovery, separating off how to reach a particular service, user agent, Network Owner, or other COI participants into queries done through various information services.
Throughout this description, public/private key pairs are designated by kX. If only the public portion of the key is used then it will be designated as kpX. In addition to public/private key pairs, the invention also uses a number of symmetric keys that are typically used for encrypting specific communication payloads, of particular note are the session keys (skSession at item 1180) used to encrypt the actual data going over a network channel. These symmetric keys are typically keying material exchanged or negotiated though common key exchange methods (like Diffie-Hellman) with the other party.
Referring again to
Every participant within the COI may create their own unique public/private key pairs for identification, validation, and communication purposes. In other embodiments, the keys could be handed out to participants from a central key authority. For some embodiments ed25519 public/private key pairs are used as the number of bytes needed to transmit the public key is small. However, any type of public/private keying system which supports the relevant types of operations (signing, session or temporary key exchange, etc.) could be used instead. The public key is then used to identify a participant on the network. This allows routing, authentication, and trusted information to be built on a unique identity tokens (the public keys) within the network. Participants on the network may use unique keys per function, as described herein where the kUser key is different than the kNO key, or participants could use the same key pair for all functions within an end point software, for example a user agent may use the same key for all functions (i.e. kUser, kMO, kNO, and kNM).
Where information is encrypted to a public/private key pair a number of different methods may be used in practice. For example, a symmetric key may be negotiated between the two parties and then used to send the information or a unique nonce may be used to send data between the two keys. The specific embodiment used to send information to a private key pair does not impact the overall technology as long as the method maintains the secrecy of the data transmitted.
Most organizations will have numerous user agents (at item 1230, at item 1231), services (at item 1270, at item 1271, at items 1291-1294) and COIs at item 1120 across the organization; but for the purposes of this paper typically a single user agent to a single service will be used for examples.
Communication between network participants (user agents, Network Owner, services, etc.) typically flows through the EIS server at item 1210 or a messaging server at item 1211. For the purposes of this description, the EIS server manages continuous communication needs (the current location of a service, the current user membership certificate, etc.) whereas the messaging service typically handles single event messages (i.e. invitation messages, key lookups, etc.). However, different messaging architectures could be used to exchange the data between participants.
Referring again to
Techniques described herein provide a computer-implemented method to share secure information over an untrusted communication medium while providing integrity and validity of the data. An information server accepts signed encrypted data, without knowing what the data contains, and hands out the data to any requesting party in a reliable manner The EIS (Encrypted Information Server) structures information in such a way that requesting parties can easily find the information they are looking for, and yet, provided information can be verified for a first level of integrity before being stored.
The system includes an Encrypted Information Server (EIS) at item 1210 that offers signed and often encrypted data blocks to requesting users. The EIS may provide additional management and accounting functions including a) managing how long records last (time to live), b) auditing for accounting and reliability purposes (i.e. by assigning the kpNO to a specific user account and then tracking all records signed by the kNO all record can be attached to the user account), c) billing, or d) acting as a STUN (Session Traversal of UDP protocol through network translators) server to assist client-to-service communication. The EIS could be a single machine (virtual or physical) or reside across a cluster of machines. The EIS information could reside on a single machine, such that all information would be looked up at a single location, or the EIS information might exist as a hierarchy across a set of servers where the information requested would be specific to a particular server. In some variants the EIS is built on top of a Directory Name Server (DNS) architecture, but the EIS could be built upon any type of informational server (web, specialized protocol, publish/subscribe model, etc.). In other embodiments the EIS may have multiple interfaces for example one through DNS type queries and one through secure web queries. Although secure web queries provide some security upgrades over traditional DNS, the performance and hierarchical structures inherent in DNS are beneficial. The described embodiments improve the security of traditional DNS protocols and could be used as a stand-alone security upgrade.
The purpose of the EIS is to disseminate information about secure services in a method that protects against misuse and misinformation, thereby preventing a number of categories of attack including many types of DoS, Man-in-the-middle routing attacks, etc. At a low level the EIS serves up encrypted data blocks, but it also provides a level of validation to the blocks before they are stored helping prevent dissemination of bad data. The EIS could be implemented as a pushed message system where each block of information is delivered directly to the participants as it is received or, as in the example embodiment, the EIS is a server that gives out the latest information on request.
The ideal security posture is to create a single trust relationship, ideally between the Network Owner and any member users and services. The purpose of the architecture is to create a trust model where no trust is placed in any external resources without Network Owner approval. To achieve this, every piece of critical information is signed directly by the kNO at item 1100 or flows directly from trust given by the Network Owner (implemented as user agent 1230, e.g.). For example, once a service has been deemed trusted by the kNO at item 1100, usually via a user invitation or other message, the service (i.e. at item 1270) within the COI at item 1220 can sign their own records with the kLT at item 1170 service key. In other embodiments, the trust relationship trying to be achieved may be different and therefore the types of records and specific signing details might be modified.
Lookups within the EIS are done on one of three models 1) lookup a name for information about that participant (e.g. at item 1500 or with a key at item 1507), 2) lookup a key (i.e. .kpY e.g. at item 1508, at item 1503, or at item 1505) to get an information record from the identity (e.g. service agent) that owns that key, or 3) lookup a key tuple kpX.kpY to get an information record destined for kpX from kpY. The order of the tuple kpX verus kpY first does not matter for security reasons as long as it is consistent across the information server and clients.
In one or more preferred embodiments, the lookup structure is constricted such that the last name item (i.e. kpY) in the lookup of any record (i.e. kpX.kpY or .kpY) is used for signing the record. This means that even though the EIS has no knowledge of what records are used for which types of information, the EIS can still verify that the record has been signed by the appropriate key. (See
Referring to flow 1500 at
In addition, since almost all records are stored under public keys, which appear to be random data, it becomes difficult for an outsider to tell what type of data is stored in the different records. Since the entire data block is encrypted and the lookup structure is the same, a user membership record at item 1504 looks similar to a machine owner policy record at item 1506.
When a client request is made to the EIS server, the requester submits a nonce (a random unique number) to the server. The EIS signs each requested record at item 1605 and the nonce with the kDir at item 1110, before sending back the response to the client. This step insures that the records cannot be replayed maliciously (send a client an out of date record thereby denying them the ability to connect). If a bad record is received, the client can detect that the record is not from the approved EIS and keep waiting to hear from the legitimate EIS server (a common race condition used for DNS attacks). This process typically relies on the client receiving the EIS Approval record at item 1501 that is signed by a trusted authority (usually the kNO at item 1100 for a COI at item 1220) to verify the EIS signature. Referring to
Finally, the EIS server itself (or other types of DNS servers) can be subjected to attacks including Denial of Service attacks. To help control the malicious data that can be submitted by an attacker, the nonce used to verify the integrity of records can be specially selected to force the client to perform a probabilistic number of computations, or work, prior to the submission of a query. This slows down the number of fake queries that can be generated and reduces the DoS severity. As part of this process, the query and the nonce are cryptographically hashed by the client, prior to submitting the query, and the resulting hash is checked to ensure it meets specific requirements. The requirements are typically similar to “the first X bits of the hash are zero”. Since the hash value is dependent on the nonce, by changing the value of the nonce the resulting value of the hash will change. However, since most hash functions are not predictable in the outcome (changing one bit in the nonce may change many bits in the hash), the client would need to test many nonce values to find a hash that meets the requirements. For example, in some embodiments the first 12 bits of the hash have to equal the current time of the query. The number of bits checked is directly related to the amount of work the client has to perform. For example if the first 12 bits have to be zero, the client would probabilistically need to select about 2̂11 random nonces, perform the hash, and verify the result to find a nonce that generates an acceptable hash. By making the checked value of the hash non-static (i.e. not 12 leading zeros) then a legitimate query cannot simply be resent thousands of times as part of a DoS attack, as the nonce would need be to updated as time changes. Other embodiments may use different numbers of checked bits (to change the amount of work desired) and may use a different algorithm for what the checked bits should equal (i.e. all zeros, the time, etc.) Referring to
Because the EIS at item 1200 provides private, and yet, universally accessible information; it also provides a number of benefits from Denial of Service or Distributed Denial of Service attacks.
The EIS adds on top of the already existing DoS attack protections built into the SPProtocol or other DoS resistant protocols, the ability to dynamically move and adjust to network conditions including when the network is under attack from DDoS attacks (by updating a private EIS service record like that of
Referring to
1) Step at item 1400. Create the Network View key (with serial or generation numbers as needed see Key Management section), kNView at item 1120.
In one or more preferred embodiments step 3C is delayed until the very end to limit the amount of unsynchronized errors when changes are made to the COI. The Service Ownership and User Membership Records can be posted in any order, however, by delaying the Service Ownership publication until the end of modifications or user agent addition there are fewer delays waiting for access while the COI is synchronized.
Once of the critical steps when starting a service is exchanging information between the Network Owner (implemented as user agent 1230, e.g.) and the Service at item 1270. In one or more preferred embodiments, at a minimum the Network Owner needs to transmit the kpNO to the Service and the service needs to send back the kpLT. Since the public keys are relatively long and consist of essentially random looking data, it is difficult for users to manually enter the information. There are multiple ways to automate or make this exchange simpler; for example, by the user agent selecting a lookup id, which is easy to type and relatively short, and entering the lookup id into both the Network Owner and the Service. The lookup id is then used to exchange information through something like the EIS server, a messaging system or other exchange. Alternate methods might include scanning a bar code, entering an IP-address and port the service will listen on, etc. One or more preferred embodiments would support multiple methods to allow for exchanges in different types of configurations.
When a user agent is deleted from the COI (assuming the Network Owner wants to keep perfect-forwards-secrecy):
When a user agent is added to the COI:
When a service is added to the COI follow steps 3 from the initial COI start up (
When a service is deleted from the COI:
In the sample embodiment, before connecting to a private service the user agent at item 1201 receives from the Network Owner (implemented as user agent 1230, e.g.) an invitation containing the Network Own-er public key, kpNO, COI domain (location of the EIS Server) at item 1210, an optional Network View Key kNView at item 1120, and the Service's public key kpLT (if using the SPProtocol). Referring to
3) Steps at items 1434-1435. Query the Service Record (at item 1503 or at item 1505) using the kpLT from the EIS. If there is a Network View Key this record will be encrypted to the kNView at item 1120 key.
If there is no kpNView key used, the service may provide more traditional public access (with or without authentication) allowing non-members of a COI to see the Service Record at item 1505. This provides functionality for where anonymous services are desired (i.e. public web site) or where the location information does not need to be secured—as the service is widely used, but still authenticated (i.e. public subscriptions—digital media sites).
Service records like those of
Other informational records may be used on the EIS server to exchange public or private information in a manner that can be validated to come from a specific party and used to extend a root-of-trust to other resources. For example, the Public Lookup Record at item 1507 can be used to allow services to publish an easy to remember name for long term access. One use might be when a web service needs to access a database service, the web service (which acts like a user agent) is configured with the databases simple name, dbl.org, The web service then queries the lookup record at item 1507 for dblorg.kpNO of the Network Owner, obtains the kpLT key for the database, then gets the Service Record (at item 1503 or at item 1505) for the database service, and starts a connection. For service-to-service communication needs or for permanently registered user sites (www.org) the Public Lookup Record can make connection initiation simpler.
In embodiments where additional trust is placed in the EIS, name lookup records might not be signed. For example a lookup value of “service.org” could be unsigned and unencrypted giving out a kpLT key for the service.
In one or more preferred embodiments, the EIS is used in combination with the other technology areas described to provide security from end-to-end within a network. However, by using the EIS as a stand-alone system, improvements are still made over the current state-of-the-art in terms of denial of service prevention, service cloaking, policy and control distribution, and user access controls. In other embodiments, the specific data used for access to the service (for example the kpNView key) could be exchanged with similar functioning items (for example a symmetric key) without changing the core invention. In addition, if alternate protocols were desired for accessing the service (for example IPSec), the specific access data included in the Service Record (i.e. IPSec keys) would be changed, thereby supporting a wide range of access methods. The EIS system could be used to provide trusted information for any type of information sharing. For this discussion focus has been on providing end-to-end security within a network; but it could be used to disseminate information for many other types of data (medical, financial, or other privacy records).
Although the discussion focuses on user agents to service communications, the system can also be used to support service-to-service communications or embedded system communication. In service-to-service communication cases, which are typically accessed through a client-to-server relationship, the client side communicates through a Client or User agent and the server side communicates through a Service Agent or included SDK. For embedded systems (like Internet-of-Things devices) the communication happens similarly; however, it may be desirable to change the invitation model such that the Network Owner can scan a bar code or other embedded device identification and use that information to enroll the device into a COI as either a service or as a user agent. Finally, although the most benefits are received by providing a secure service, for services that are offered to anonymous user agents (no authentication or access control required), they can still be supported in the current system by publishing unencrypted service information (at item 1507 and at item 1505), and allowing the kpLT keys offered to be attached to any COI.
Communication may also occur between two user agents, for example in a peer-to-peer model. In this configuration the user agent acts as both the initiator of the communication (as described by the client or user agent) and as a recipient of the communication (as described by the service or Service Agent). Because minimal information is needed to establish communication and no reliance on the physical network characteristics, a peer-to-peer communication model can be configured over any type of network including mesh, directed, or broadcast networks.
Finally, COIs can exist as independent and virtual overlays on any physical network with similar or dissimlar agents: COI groups can overlap users in different physical locations, a single user agent may be part of dozens of COIs or not be a member of any COI, and COIs can exist with users in different organizational hierarchies.
Keys are managed on the network through a collection of techniques. The simplest is when a User Contact Key at item 1130 or Network Owner key at item 1100 needs to be change or roll, they can simply sign the new key with the old key and publish a roll message. However, if the keys are lost or stolen the simple key replacement strategy is to delete the old COI or membership and rebuild the COI. The following descriptions assists when new user agents are added or removed from the COI, which may happen regularly, to make the key rotation less costly (in terms of performance and synchronization) the following technique can be used.
For group communication, the present invention uses a Network View key kNView at item 1120. Although the kNView key could be a simple public/private key or symmetric key, which is distributed to everyone within the COI, that is unique and independently created when a new version is needed, by creating some additional structures around the key the Network Owner can be more efficient with processing and reduce the amount of time the COI at item 1220 is out of synchronization (where user agents and services have different keying material), thereby increasing the amount of up time.
In one or more preferred embodiments the kNView at item 1120 key is broken up into three components:
Using the first three components the Network Owner can derive the kNView key from a set of hashes done to the kRootNview key. This key kNView key is then specified by the tuple kNView, serial number, and generation number.
The Network Owner to create a new kNView[1,1] (i.e. with a serial number of 1 and generation number of 1) key goes through the following steps:
The result of the cryptographic hash is the Network View key with serial number 1, kNView[1,1]. Generically, the Network View key at a particular serial number is the hashed result from hashing the kRootNView key max-serial number+1 number of times.
This results in a series of keys, where earlier serial numbered keys can be derived from later ones (i.e. if the User agent has the key kNView[3,1] for the 3rd serial number, the agent can derive independently the second and first serial numbered keys kNView[2,1] and kNView[1,1]).
When deleting a user agent in order for future communication to remain private (i.e. provide Perfect Forward Secrecy) from the user agents just deleted, the keys need to be modified. In some embodiments to do this the Network Owner:
By updating the Service Ownership Records last the COI can continue to function while portions of the network are out of synchronization (as user agents will have both the current kNView key and can create any prior kNView keys as needed for services that have not been updated). If the User Membership Record has a serial number that is greater than the one in the Service Record, the user agent simply has to cryptographically hash the key the difference number of times (User Membership serial#—Service Record serial#). A second benefit is that all new network members can see any communications that use prior Network View keys without having to be specifically sent the entire history of keys.
When evaluating key synchronization models where all participants need to have the same key, there is a period of time where the first participant has key2 and the second participant has the old key, key1. If the keys are distributed from a centralized management console the time for complete synchronization across a large network with at item 11000s of participants can be significant. By using the discussed kNView keys with serial and generation numbers, in the most common cases where a user agent is deleted (see steps above) a user agent at item 1231 can continue to connect to a service with the old or new key until the Service Ownership Record at item 1502 is updated, meaning that the period of time the COI is not synchronized has no impact on the ability of users to connect to services on the network.
A second, but less common, property that may be desired by organizations is Perfect Backwards Secrecy, where when a new member is added to the COI they should be unable to read older messages or COI activities. This property is not as commonly used. However, some embodiments provide this functionality by increasing the Generation Number at item 1310 of the Network View Key and creating a new kRootNView at item 1315 and kNView key. This modifies the key to a value that cannot be computed from earlier keys and requires synchronization of all members before everyone can participate. The process is:
To make connection startups more flexible there are several methods for configuring the SPProtocol. In order to start a connection using the SPProtocol the client typically needs to have the Short Term Service key, kST at item 1160, a location for the service (typically IP-address and port), and create its own client key kClient at item 1150 that is then used to create a session key skSession (see
As the SPProtocol can provide secure communication means even in a completely disconnected network with or without a Network Owner, the protocol can be used on physically isolated networks and super localized network (e.g. blue tooth) without an increase in security risk or loss of control.
The SPProtocol implements controls to limit DoS attacks, in that it will generate puzzles that are then sent back to potential connections. In some scenarios, organizations will want to turn off this feature to provide more “dark service” benefits, as it potentially gives attackers confirmation that a service exists when they launch a DoS attack.
Even though all communication is encrypted, the SPProtocol allows external auditing of sessions across a network. When the Service Record is published, it may include an optional auditing key kpAuditing that should have access, via network sniffing or when session traffic is routed through a network gateway, to all session traffic. In one or more preferred embodiments, when the client negotiates a session key skSession between the service short term key kpST and the client's short term key kClient (typically done as a two party key agreement), the client will also negotiate a session key between kClient and the kpAuditing keys creating skAuditor. The skAuditor key is then combined with the session key skSession and including in the public packet headers. In another embodiment, if an auditing key is published, the session key being used (i.e. skSession) is encrypted to the auditing key (i.e. kpAuditing) such that it can only be read by the auditor and then included in public packet headers of the session. The encrypted session key (or combined skAuditor and skSession key) may be included in just the tunnel creation packets or, in other embodiments, may be included in every packet. Once the session key is received by the auditor, the auditor can view all the data within the session including the authentication used by the client and any user profile or user identity information. Finally, it is beneficial to include the service's long term public key kpLT in the tunnel creation data to assist the auditor in keeping track of the tunnel identity. The auditor could then monitor for malicious use, enforce policy decisions, or otherwise control the session from a network gateway, through network traffic manipulation, or through out-of-band techniques to the service itself.
SPProtocol supports first packet data and authentication, thereby allowing faster start up times and reducing the round trips required to communicate (which is the main cause of slow connections on high latency networks). The SPProtocol's first packet authentication also increases the security of the service by eliminating any communication with the underlying service protocol (i.e. http) until the request has been authenticated and creates a “dark service” that is hidden from the network. First packet authentication, where the very first packet within a connecting includes the full authentication information, insures that prior to any processing being done on the data within the connection that the client is fully authenticated and authorized to send data. “The SPProtocol, by combining first packet authentication with an encrypted channel that uses any form of authenticated encryption (provides confidentiality, integrity, and authenticity assurances), ensures that every packet within a communication channel becomes traceable to the user credentials used in the first packet. Unlike other protocols that just validate the single packet with authentication in it, the SPProtocol allows every packet to be authenticated to specific user credentials. The SPProtocol also allows first packet data within a connection startup further reducing the number of round trips before useful communication occurs.
The SPProtocol supports dark services with two main methods: the first is that under most error cases (i.e. bad authentication, wrong communication key, badly formatted packet) no error messages are sent back to the client. To attackers trying to probe the network it becomes difficult without proper authentication credentials to create a packet that will generate any type of response, thereby making it difficult to even identify that the service exists. Technical support, including network connectivity issues, can be handled out-of-band with errors sent directly to administrators. The second control that makes dark services possible is that the information required to connect, specifically the Service Short Term Key kpST, is not publicly available, as the COI and EIS combine to allow the kpST to be encrypted and accessible only to those members who are approved. These techniques combine to create services which are hidden from access, dark, and limit the types of successful attacks which can be launched.
When the SPProtocol is implemented directly by clients and services there are no tunnel modifications required; however, to support existing (non-SPProtocol enabled) services or clients, tunneling agents can be used to reduce round trip times over wide area networks. There are two main locations of a connection tunnel that require modification in order to support first packet data payloads for stateful connections. The first is at the client side, traditionally a client will request a connection then, if successful, they will send authentication information and then the first packet of data. Each step has to be done in order and may generate multiple round trips of packets. Because of this lock step process, the client tunnel does not have access to the data to be sent until after the connection is accepted. The depicted variant of the invention uses a predictive and adaptive acceptance model to decide if the client can start sending data early. This allows the client to act under the traditional connection model, with minimal modification while still reducing the round trips
The predictive acceptance model in some embodiments is currently based primarily on if previous connections have been successful at item 1701 and it may respond to the client agent at any point in the connection start-up process. In the sample process embodiment the main decision points on if the connection can be predictively accepted, rather than waiting for the connection to traditionally accepted by the sever are: at item 1701 Has the service been successfully contacted recently, at item 1702 Does the user agent have current credentials, or at item 1703 will first data processing be helpful. In other embodiments, the predictive model could be simpler (always accept the client connection request immediately and just work around the behavior issues of closing a connection mid-stream without being able to signal how much data was lost to the client) or more complex at item 1711 based on network topologies, latency or bandwidth of the network, service location, type of authentication required, network conditions, or any other external or internal to the connection factors.
Assuming the service being offered over the network does not natively speak the SPProtocol, then the following process is used on the service side of the tunnel to process and control the first packet data.
If the client or server agent is integrated with SPProtocol directly, the need for some predictive behaviors (where the connection exists in a partially formed state) and caching requirements may be avoided and the client's control over what types of data may be included in the first packet may be improved. Other configurations may include where either the client or server side natively supports the SPProtocol, then only those portions of the process that do not have native SPProtocol support (the client to client-tunnel or server-tunnel to server) would be used. For example, if the Service uses the SPProtocol as a network library or SDK, implementing the connection directly there is no Server Tunnel used and the Service directly responds to client tunnel requests.
As can be visually seen in
The SPProtocol supports multiple delivery options, including guaranteed in-order delivery to not-guaranteed and not in ordered delivery, by treating the individual data blocks within the connection independently. Since commonly every SPProtocol requires authentication, the tunnel itself may have state even while supporting individual data blocks within the tunnel being stateless. Data blocks within the tunnel are passed within a data wrapper which marks which blocks require reliable delivery.
To support guaranteed data, each guaranteed data block is saved in a re-transmit queue that is only cleared out when an acknowledgment (ACK) is received for that data block (or in certain errors cases like the connection shuts down). Blocks of data that are not guaranteed are discarded once transmitted to the other end-point. For example in one scenario an endpoint transmits a set of data blocks to another endpoint. Only those data blocks that have guaranteed delivery are saved to the re-transmission queue.
The second area of modification from traditional models (like TCP) is that the ACK system is more flexible allowing data block or transmission IDs to be ignored. Instead of an ACK message containing a single number of the last in-order message id each side of the connection has seen, it now contains a set of the messages missed since the last synchronization or ignore message. Each side then sends ignore messages at periodic intervals that tell the first side which message IDs can be ignored. For example, ignore all message IDs earlier than at item 1100. In addition to providing more flexibility, the ability to ignore packet loss in some situations allows additional benefits when transmitting common low-priority control data like acknowledgments, status queries, etc. Low priority packets can then be passed as non-guaranteed data so if the data block is lost it doesn't matter (commonly this is because the data will either be repeated later or was time sensitive and not relevant after the initial transmission window).
In addition to supporting multiple types of data delivery options, the SPProtocol extends the initial connection setup control messages to specify how data can be routed outside the tunnel after data is received. These routing options, setup by the service when it is created, can be selected by approved connections allowing extended deployment options. Referring to
By routing communication channels based on service key kpLT and through the SPProtocol's support for extended routing options for data coming into the channel, it becomes possible to create a protected Internet pipe for mobile user devices or user agents that have to access the Internet through an untrusted source.
In some variants, one or more systems above include key and trust management components allowing participants to be cryptographically identified. These identities are then used to configure dynamic or centralized relationships between user agents and the services they can access. The embodiment for the trust management system can be easily modified to support a wide range of identity relationships no matter how simple or complex the organizational roles or rules that are desired.
In some variants, one or more systems above include an independent encrypted information server (EIS) which allows participants to quickly, and yet securely, share information across networks or even organizations. By using selective encryption and validation, the information can be shared across public servers and infrastructure without compromise while still allowing clients to verify the integrity of the data. The EIS server allows service locations to be hidden and prevents denial-of-service attacks against both the server itself and the services hosting their location information on the EIS.
In some variants, one or more systems above include protocol improvements for communication improve the underlying security, but also integrate the benefits provided by the trust model and EIS server out to every destination. Security improvements include elimination of attacks from anonymous users (zero day or known attacks), protection from denial-of-service attacks, full encryption, and cryptographic identification on every packet. The protocol improvements also support significant performance enhancements, improving the speed and flexibility of connections.
Operation 3140 describes decrypting the first encrypted identity record received at the one or more servers with a first session key generated at the one or more servers (configuring one or more modules 645 so that the one or more servers 300 decrypt the first encrypted identity record 617 using an instance of session key 618 generated at the one or more servers 300, e.g.). This can occur, for example, in a context in which the session key 618 would otherwise need to be transmitted from the first entity 610 to the one or more servers 300 in order for both to have the same session key 618 and in which such transmission would put the security of network 602 at risk. In some variants the one or more modules 645 may also configure the first encrypted identity record 617 as a chain of two or more certificates that includes client public key 611 signed by user private key 602 using a first network owner private key 682. Alternatively or additionally, the encrypted identity record 617 and a service locator record 614 that includes service public key 631 signed by the one or more authorities 405 may be configured as identical (by setting one to match a value of the other, e.g.).
Operation 3155 describes communicating something by the one or more servers to the first entity as an automatic and conditional response to a determination that the first encrypted identity record received from the first entity is trustworthy after having generated the first session key partly based on the first client public key and partly based on the first service private key (configuring the one or more modules 645 so that the one or more servers 300 first generate a local instance of session key 618 and later decide to communicate to the first entity 610 as an automatic and conditional response to a determination 644 that the first encrypted identity record 617 received from the first entity is appropriately signed and not garbled, e.g.). This can occur, for example, in a context in which the first entity 610 initiated communication to the one or more servers 300 such that an initial packet of the communication included client public key 611B as described below, in which the automatic and conditional response would otherwise be excessively or insufficiently selective during such an instance of session initiation, in which the determination 644 that the first encrypted identity record 617 received from the first entity 610 is trustworthy includes determining that the first encrypted identity record 617 includes the first client public key 611B properly signed by the one or more authorities 405 (including at least one authority 405A trusted by server 300B, e.g.), and in which authority 405A either consists of a shared password or owns network 602 (as depicted in
Operation 3165 describes communicating nothing whatsoever by the one or more servers to a second entity as an automatic and conditional response to a determination that a second session key or second identity record received from the second entity is untrustworthy (configuring the one or more modules 645 so that the one or more servers 300 communicate nothing to “second” entity 620 as an automatic and conditional response to a determination 644 that a second identity record 627 or second session key 628 received from the second entity 620 is untrustworthy, e.g.). This can occur, for example, in a context in which the “second” entity 620 would otherwise use the fact of a non-empty response (an acknowledgment or error message, e.g.) from the one or more servers 300 to confirm a suitable point of entry (into server 300B or network 602, e.g.) toward which to target a denial-of-service or other effective attack.
With respect to the numbered clauses and claims expressed below, those skilled in the art will appreciate that recited operations therein may generally be performed in any order. Also, although various operational flows are presented in a sequence(s), it should be understood that the various operations may be performed in other orders than those which are illustrated, or may be performed concurrently. Examples of such alternate orderings may include overlapping, interleaved, interrupted, reordered, incremental, preparatory, supplemental, simultaneous, reverse, or other variant orderings, unless context dictates otherwise. Furthermore, terms like “responsive to,” “related to,” or other past-tense adjectives are generally not intended to exclude such variants, unless context dictates otherwise. Also in the numbered clauses below, specific combinations of aspects and embodiments are articulated in a shorthand form such that (1) according to respective embodiments, for each instance in which a “component” or other such identifiers appear to be introduced (with “a” or “an,” e.g.) more than once in a given chain of clauses, such designations may either identify the same entity or distinct entities; and (2) what might be called “dependent” clauses below may or may not incorporate, in respective embodiments, the features of “independent” clauses to which they refer or other features described above.
While various system, method, article of manufacture, or other embodiments or aspects have been disclosed above, also, other combinations of embodiments or aspects will be apparent to those skilled in the art in view of the above disclosure. The various embodiments and aspects disclosed above are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated in the final claim set that follows.
This application claims the benefit of U.S. provisional patent application Ser. No. 62/410,659 (filed 20 Oct. 2016), which is hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62410659 | Oct 2016 | US |
