From: John Young <jya@pipeline.com>
To: cypherpunks@cyberpass.net
Message Hash: abc891b91c57d2fac6bd8086a47924976240aec8f8bb09373d16e7c9bae8406a
Message ID: <199811181839.NAA01188@smtp2.atl.mindspring.net>
Reply To: N/A
UTC Datetime: 1998-11-18 19:19:01 UTC
Raw Date: Thu, 19 Nov 1998 03:19:01 +0800
From: John Young <jya@pipeline.com>
Date: Thu, 19 Nov 1998 03:19:01 +0800
To: cypherpunks@cyberpass.net
Subject: National Security KRA Framework
Message-ID: <199811181839.NAA01188@smtp2.atl.mindspring.net>
MIME-Version: 1.0
Content-Type: text/plain
These are excerpts from US Patent 5835596: "International
cryptography framework" issued on November 10, 1998, to
inventors Keith S. Klemba, Santa Clara, CA, and Roger
Merckling, Gieres, France and assigned to Hewlett Packard.
Source:
http://www.patents.ibm.com/patlist?icnt=US&patent_number=05835596&x=19&y=4
It's an update of US Patent 5651068 issued for the same
methodology in July, 1997. Summaries of the patents are
also available at < http://www.uspto.gov >.
INTERNATIONAL CRYPTOGRAPHY FRAMEWORK
SUMMARY OF THE INVENTION
The invention provides a four-part technology framework
that supports international cryptography, which includes a
national flag card, a cryptographic unit, a host system, and a
network security server. Three of the four service elements
have a fundamentally hierarchical relationship. The National
Flag Card (NFC) is installed in the Cryptographic Unit (CU)
which, in turn, is installed into a Host System (HS).
Cryptographic instructions on the Host system cannot be
executed without a Cryptographic Unit, which itself requires
the present of a valid National Flag Card before its services
are available. The fourth service element, a Network
Security Server (NSS), can provide a range of different
security services including verification of the other three
service elements.
The framework supports the design, implementation, and
operational elements of any and all national policies, while
unifying the design, development, and operation of
independent national security policies. The invention thus
gives standard form to the service elements of national
security policies, where such service elements include such
things as hardware from factors, communication protocols,
and on-line and off-line data definitions. [Snip drawing and
detailed descriptions.]
APPLICATION OF THE FRAMEWORK
The invention has various applications. In particular, the
framework is ideally suited for various national security
schemes and operates consistently across a variety of local
laws. For example the framework could be used to support a
key escrow policy. Key escrowing is a process where the
keys or family keys used for cryptography are kept by a third
party, in the national context, typically a government agency.
This allows the third party to decrypt information when, for
example, a law enforcement agency is required to see the
contents of an encrypted message.
For example if the policy of nation-X requires key escrow,
then when nation-X NFC's are put into circulation they
contain a key escrowed by nation-X. Law enforcement
would be able to use the electronic stamp on a message to
determine that the message was encrypted under the policy
of nation-X. It would also be able to determine unique
identification information of the specific NFC used to enable
the CU. If nation-X agrees to cooperate, the escrowed key
for the NFC involved may be obtained to decrypt the
suspicious message.
The actual encryption algorithm used in nation-X may be the
same encryption algorithm that is used in nation-Z, such that
when a user from nation-X visits nation-Z it is only
necessary to put a NFC from nation-Z into the CU. The
encryption algorithm in the CU remains the same, but what
is governing the use of cryptography is the policy of nation-
Z. For example, the policy of nation-Z may require a trap
door, such that the government of nation-Z is able to take a
back door into the users system to read the deciphered text.
In this case the nation-Z NFC provides a back door rather
than an escrowed key to law enforcement. Several such
schemes are known in the art and it is a feature of the
invention that the framework is readily adapted to
accommodate such schemes as may be implemented in a
particular national policy without affecting the basic
hardware, or data structures of a user system, with the
exception of the NFC.
Thus, the encryption algorithms in CU may be the same
encryption algorithms used everywhere. The NFCs control
the use of these encryption algorithms in accordance with
the local law. Because the NSS is a trusted third party that
validates proper local use of the framework, it is not
possible to use cryptography unless a locally accepted NFC
is installed in the CU. In the example above, even though the
encryption engine operates properly in nation-X, it would
not operate in nation-Z unless the NFC was replaced with a
nation-Z's NFC. For international communication of
encrypted information, (e.g. where an encrypted message is
generated in nation-Z and sent to nation-X) the involvement
of cryptography for such messages will be independently
controlled by two NFCs -- the X flag card in nation-X and
the Z-flag card in nation-Z. The invention therefore offers
the ability to support government policy, whatever that
policy may be, and still provide uniform cryptographic
services.
In addition to the nationalization issues that are illustrated
above, within a certain nation there may be multiple
encryption policies (e.g. nation-X might have a policy for
banking that is more liberal than its policy for
manufacturing). Accordingly, the framework is adapted to
operate within each country under several different national
policies, or with several different levels of encryption. For
example, just as there are different stamps for first class and
priority mail, the framework may allow for different levels
of encryption based on the type of NFC installed.
It is a feature of the framework that CUs may have the major
standard encryption algorithms built-in (e.g. DES, RSA,
DSS, MD5). However, it is also possible to install custom
algorithms into the CU providing that the policy in the
governing NFC permits this type of activity. Software
algorithms can be transferred completely or partially into the
CU from either the NFC or the NSS. Hardware algorithms
can be added to the CU via the NFC. The actual encryption
of a message may involve the NFC, CU, or NSS, or any
combination thereof. As soon as the NFC is removed from
the CU these custom algorithms are no longer operative,
perhaps not even present, in the CU.
[End excerpts]
Return to November 1998
Return to “John Young <jya@pipeline.com>”
1998-11-18 (Thu, 19 Nov 1998 03:19:01 +0800) - National Security KRA Framework - John Young <jya@pipeline.com>