Threshold Signature of the On-line Certificate

Each member in the coalition checks the validity of the Config_Cert_Request message, looks
in its CRL and BL tables if no member of the coalition is malicious nor his public key is
revoked. If this holds, then each member starts the threshold signature protocol providing an
‘On-line Joint IP address and Public Key Certificate’ for the requester. The member of the
coalition with the lowest IP address will act as the combiner of the partial signatures, replies to
the requester by a Config_Cert_Reply message, and has in addition the task to inform all
nodes by a Config_Advert message that an IP address has been attributed to the node in
question. Then, all nodes increment its Requester Counter (RC) and delete this address from
the FAT and save it in the PAT. Hence, a new coming node will not have the possibility of
choosing this address.

If a malicious node has been discovered among the coalition members, a Config_Alert message
is sent to the honest members of the coalition and to the new joining node. This message
includes the list of approved malicious members and/or the list of approved revoked public
keys. The algorithm for this processing is shown in Figure 1.

The new joining node checks the correctness of this information by means of the On-line
Certificate Authority’s public key. Hence, it will be able to isolate the misbehaving nodes
(either the node sending the Config_Alert message or nodes appearing in this message).
Subsequently, the requester performs a new coalition selection while excluding the malicious
nodes

Figure 1:  Processing a certification request by a co-signer

Trusted Internet Connection

Similar to Departments and Agencies that utilize Networx MTIPS, those using a TIC will already have a contractual relationship in place with their ISP, usually a Networx ISP. Pursuant to that relationship, the ISP, in its ordinary course of business, will use routing tables to ensure that only traffic intended for the Department or Agency’s IP addresses is routed to the Department or Agency’s networks. And the Department or Agency remains responsible for ensuring that only traffic intended for, or originating from, that Department or Agency is routed through the EINSTEIN sensor.

Since EINSTEIN collects network flow information for all traffic traversing a sensor, if, in a rare case the required contractual routing protections fail, in the normal course only network flow information associated with the improperly routed traffic would be collected. This mechanism minimizes the possibility of capturing or releasing Personally Identifiable Information (PII). If improperly routed network traffic matched a pattern of known malicious activity an alert would be triggered. In the event of an alert, and upon further inspection and investigation with the Department or Agency receiving the incorrectly routed traffic, a US-CERT analyst would be able to identify an incorrectly routed traffic error. US-CERT would then work with NCSD’s Network Security Deployment and Federal Network Security branches, the relevant Department or Agency, the ISP and, if necessary, the MTIPS vendor, to remedy the routing problem. In the unlikely event that an ISP’s routing tables mistakenly assign a government IP address to a commercial client, a routing loop would result. The routing loop would cause errors and break the commercial customer’s connection. When the ISP detects the routing loop or the customer reports its broken connections to the ISP, the ISP would correct the error in its ordinary course of business.