Secure communication system5671285Abstract Encryption/decryption capable terminal units, such as FAX point-of-sale units, on non-secure telecommunications, use public keys for accessing selected target terminals, but make their messages secure by encryption according to private keys. Each subscriber terminal registers, with a central database controller, a unique public key code. Each terminal includes a quick-access storage for a finite number of telephone numbers and related public keys for other terminals. To send a message, the source FAX first queries its local storage for the public key of the target terminal. If the public key is present, it sends a message encrypted with the public key for the target terminal, along with a digital signature. When the message is transmitted, the encrypted public key for the target terminal, and the digital signature of the source terminal user's private key are combined to form a message packet for decryption by the target terminal. The target terminal queries its own key storage to permit decrypting using its own private key and the public key of the sender. The central database controller provides unknown telephone numbers and public keys, and archives, groups, forwards and timestamps messages, and authorizes credit card transactions, without forwarding credit card numbers and without capability to decrypt such message. Credit transactions require the central database controller to communicate separately with the credit provider, but these messages may be similarly encrypted using the public key and private key concept. Claims I claim: Description BACKGROUND OF THE INVENTION
______________________________________
PHONE NUMBER PUBLIC KEY
______________________________________
AR1 KR1
AR2 KR2
. . . . . .
AR(n) KR(n)
______________________________________
Implementation at the subscriber FAX terminal is by firmware having the following capabilities: a) Interpreting standard FAX communication protocols; b) Accepting public keys and private keys; c) After-hours remote updating) d) Capability to store and verify a significant number of public keys. Implementation at a secure central database site includes the following capabilities: a) Verification of data; b) Verification of digital signatures; c) Time-stamping and secure storage of each encrypted page; d) Preparation and maintenance of audit trails; e) Forwarding to a number of user FAX terminals a group broadcast; f) Accessing the public keys of new and updated users through a highly secure protocol without requiring any end-user interaction. 1. Registering with the Central Database on Startup The public key and private key are generated at the factory and stored within the individual fax terminal., Following the initial communication with the central database, the public key will be sent and registered with the CDC. This public key and associated telephone number must be securely maintained by the CDC. After transmittal of the information, the following activities occur: 1.1. Validating communication security 1.2. Registering public key 1.3. Acknowledging. 2. Terminal to Terminal Communication with Directory Help From CDC Each subscribing FAX terminal, including FAX1, FAX2, . . . FAX(n) may be set to a beginning group of "frequently called numbers." Thereafter, whenever there is a call from, or a call to, a new number, there must be a decision whether to treat the number as a "frequently called number." The following activity occurs: 2.1 Validating communication source and destination. 2.2 Requesting public key. 2.3 Receiving public key. 2.4 Storing public key. 2.5 Generating random key (K?) and digital signature. 2.6 Sending (K?) and digital signature. 2.7 Sending encrypted FAX. 3. Terminal to Terminal Communication When a transmission is made to a FAX unit which is included in the list of frequently called numbers, or if the public key and telephone number are known, the following activity occurs: 3.1 Retrieving public key 3.2 Generating (K?) and digital signature. 3.3 Sending encrypted FAX. The safe facsimile user terminal FAX1 comprises to functional units as follows:" 1. Hardware--The subscriber facsimile unit 1 includes both random access memory (RAM) 6 and read-only memory (ROM) 4. Representative sizes are two kilobytes RAM and six kilobytes ROM, plus a real-time clock. The unit contains a universal asynchronous receiver transmitter (UART) 7 capable of handling serial communication. 2. firmware--The firmware typically resides in ROM. Much of the firmware in ROM is devoted to encryption/decryption and digital signature processing required for a secure system. A significant amount of firmware capacity is also dedicated to support of CCITT protocols. Firmware to support the invention includes: 1) Storing and maintaining the local table containing the public keys and telephone numbers; 2) After-hours uploading and downloading of data by interaction with the central database; 3) Automatic initialization with the central database; 3) Providing levels of security; 4) Maintaining an audit trail with automatic backup to the central database. The user facsimile terminal unit functions as follows: Each unit contains a unique private code generated at the factory, stored in the central database control unit, and unknown to anyone else. This may be randomly generated, and even be unknown to the unit owner, so long as the code specifically identifies a particular unit, and so long as the code permits the central database controller to connect to the terminal unit. Upon initial installation behind a FAX machine or FAX board, the FAX terminal automatically registers (after a verification process) its public key pair with the central database controller CDC. Once registered, any existing facsimile terminal can access this hardware key through its public key pair. Prior to sending each FAX message, the FAX terminal first queries its local quick-access RAM for the public key of the FAX target. If the public key of the FAX target is found, by a positive comparison with the addressee information, the connection can be made. If the query comparison is negative, the sending FAX automatically calls the CDC, and after a verification process, the CDC transmits updating information to the quick-access storage of the sending FAX. This updating information includes the public key and the telephone number of the receiving fax; the receiving FAX uses this public key for the encryption and digital signature of the FAX message. All new FAX units going on-line into the network must initially register with the CDC. The CDC thus has available in one of its memory units the public key registry for each new subscriber as well as the public key for each older subscriber. These new public keys and telephone numbers are immediately available, on demand, and in the general course of business are also sent to each facsimile terminal on a time-available basis, after hours. This is also true for updated facsimile terminal units which now have new FAXphone numbers in the CDC. The next periodic after-hours update automatically checks and updates all of the existing phone numbers and public keys contained within each facsimile terminal unit. Note that each FAX updates and maintains its own internal table of FAXphone numbers and public keys. The CDC is also responsible for the monthly billings, which may be transmitted encrypted. COMMUNICATIONS MODES The fax terminal offers a variety of communications modes. These are selected by the end-user from external setting switches on the FAX terminal case. These communications modes include: 1. No security. 2. No encryption required; signature required. 3. Encryption, no signature required. 4. Encryption required, signature required. 5. Encryption required, signature required, time-stamping required. The source FAX unit FAX-1 transmits a communications mode identification and subsequently transmits a message to the selected target FAX according to the selected level of security. Tame-stamping of each page can be performed on each page by using the real-time clock of the FAX terminal hardware. Additional time-stamping capability is available by the time-stamping and storage of the encrypted FAX communication by the CDC 21. This is extremely secure since the CDC can time-stamp (and store) each page of the encrypted FAX message, but cannot read the message since the message is encrypted. Each FAX maintains a record of the number of FAX pages that were sent each month, along with their level of protection, that is, along with a notation of their communication modes. Every month, each FAX terminal automatically dials into the CDC (after hours, generally late at night) and downloads this information for billing and audit trail maintenance purposes. Concurrently, the facsimile terminal checks and authenticates each of its locally stored telephone numbers and public keys with the CDC. OPERATION FIG. 1 shows the local database and control card which make up a secure FAX terminal 1. FAX1 includes FAX hardware and connections respectively to and from the FAX hardware. It also includes input and output connections to the CDC 2. FAX1 itself comprises a random access memory (RAM) 6 of suitable size to buffer input and output messages. It also comprises a read only memory (ROM) 4 for its operating firmware. Microcontroller 5, which carries out the functions demanded by its firmware coding in ROM 4, controls the flow of FAX data and also controls encryption and decryption. Upon installation, pursuant to a one-time activation program, each new security FAX key will resister with the CDC, which will contain an associated public key for each telephone number assigned to a secure FAX. There will always be an associate private key for each local key. When a FAX message is transmitted, the FAX sender will first query its local database for the public key of the FAX recipient. If the public key is present, the FAX sender (FAX1) begins by sending a FAX message to the target FAX receiver (AF.quadrature.2), using the stored number, in encrypted fashion. The FAX1 unit dials the target FAX unit using the public telephone system or other non-secure communication channel. When the FAX message is transmitted, the public key for the target FAX receiver and the private key for the FAX sender are used for the encrypting of the data and the creation of a digital signature. If the query to the local database is unsuccessful in locating the public key for the target FAX recipient, then a number-finding operation is set in motion. The FAX terminal will call the CDC for the phone number and public key to the target FAX unit, which in this example is FAX2. Assuming the situation where the sending FAX (FAX1) already stores the public key for the target FAX (FAX2 . . . FAX(n)) the transmission of an encrypted FAX message (e.g., "FAX1 ›common!.fwdarw.k?.backslash.FAX(n)) is performed in the following steps: 1. The sending FAX (FAX1) generates a random key (k?). 2. FAX1 encrypts a concatenated secure address (<k?*kP>FAX(n=2). 3. FAX1 signs this message with the FAX1 private key kP>FAX1 and sends the encrypted message to FAX2. Only FAX2 can decrypt the message with its private key and obtain the random key (k?) which it can then use to decrypt the message text. FAX1 and FAX2 verify random key (k?) during this transmittal. 1. Expanding FAX Security To Include All Modem Communications Since both FAX and data communication involve the use of a modem, the central site security system requires little modification to be expanded from FAX to data communication, particularly since FAX communication is essentially data communication. Since the function of the modem is mainly to convert digital data to analog data (by the sender and from analog data to digital data (by the receiver) data transmitted via a modem, whether from the FAX or from a computer, is treated the same way. No distinction is made once the transmission of data occurs. Accordingly, no security, system modification is required by either the sending or receiving device or to the functioning of the central site. Then sending device will still search its internal database for the target phone number and public key, and query the central site if necessary/ The data transmission to the target site will be the same, regardless of the source or destination. Only the header message will be modified to include a new type of data-only flag. 2. Expanding Security To Include Modem Placement of Purchase Orders Encrypted on a Non-Secure Communication Medium FIG. 3 shows the method for authorizing credit card purchases via the Internet without risking the credit card number. Internet shopping is convenient and effective--security of the credit card is the major problem at present. The problem is that communication of the credit card number, in the clear, across a non-secure communications channel may provide sufficient data to a thief to steal the credit authorization codes. In a typical transaction, customer views the offering information and determines interest in purchasing the item. Customer may transmit a purchase order, a digital signature providing authorization, and even transmit the credit card number. The transaction is quick and simple. Unfortunately, the credit card number may have been picked off by a thief. Using the technique of this invention, the customer views the product offerings of the storekeeper, determines interest, and wires a purchase order with a digital signature providing authorization but does not transmit the credit card number, at least not in the clear. The Storekeeper acknowledges the customer's interest by transmitting the public key of the store together with an order identification (ID). The customer then encrypts and sends order, credit card type and number, credit card expiration date together with the encrypted order ID. The storekeeper now sends a request to the Central Data Base (CDB) to verify the card, amount and order ID with the credit card credit company. The CDB, after verification with the credit card credit company, sends to Storekeeper a "verified, accepted, and charged) message with the order ID. The storekeeper simply fills the order, depending upon the credit card credit company to reimburse the storekeeper and collect from the customer--but never did learn the actual credit card code number. Method of Modem Placement of Purchase Orders Encrypted on a Non-Secure Communication Medium FIG. 3 shows the method for placing credit card purchase orders on a non-secure line, with the credit card number never put at risk--that is, the credit card number is never transmitted without encryption, and need not even be known by the storekeeper. The method includes the following steps: Step 1--Customer C and merchant M confer on non-encrypted communication channel to place an order for items. (C.fwdarw.M) Step 2--Merchant M sends to customer C a data group including order identification number, total price, and the public key &the central database. (M.fwdarw.C) Step 3--Customer C sends back to merchant M a data group including order identification number plus an encrypted data group including total price, order identification number and credit card information, using the CDB public key. (Merchant M cannot decrypt this encrypted data group.) (C-**.fwdarw.M) Step 4--Merchant forwards to central database the complete message (minus the non-encrypted order identification number) from Step 3. (M-**.fwdarw.CDB) Step 5--Central database queries credit availability from a credit provider, using its own secure or dedicated communication channel, and where establishes the validity of the credit transaction for the particular purchase order (OK) or invalidity (NAY). Step 6--Central database sends back to merchant M, possibly encrypted, with a OK| or Nay|| for the order plus total dollar amount and order identification number. (CDB.fwdarw.M) Step 7--Merchant M transmits OK or Nay for the order back to customer C, who has remained on line. At no time during this entire process of seven steps does merchant M, much less any interlopers on the communication channel, have access to the actual credit card information. The Central Site System Important functional aspects of the system include: 1. Real-time communication with additional sites. 2. Rapid retrieval of data a and information. 3. Storage of all user accounts. 4. Ability to store and broadcast data to groups. 5. Maintenance of a billing system/ 6. Storage of large quantities of data. 7. Maintenance and availability of demographic and company information. 8. High level of security using public key technology. Definitions For purposes of this invention, the xsystem central site, xsystem local-central site, xsystem storage control site and system data central site have definitions which differ slightly from the usual definitions of such sites, as follows: Central Site: A repository of basic information consisting of public key, phone numbers and FAX numbers, able to respond to requests for public keys, communicate with other central sites encrypt data, store data, broadcast data, and perform security operations and numerous other functions. Local Central Site: A central site in some localized region. (This term is used interchangeably with "central site" for purposes of the invention.) Data Central Site: The repository for all demographic, company profile, group information, and billing information site assigned to one central site. Storage Central Site: The repository for all stored and archived data. Each local central site will be able to rapidly retrieve public key data based on a phone number. Each phone number and possibly an additional field will be compressed into a unique index number for both space and speed of retrieval purposes. Using this unique index, the system central site can rapidly access its database to find and then transmit the required public key once a secure connection is established. Stored Data Transmission Stored data will be transmitted pursuant to a request from the sender, along with the proper security sequence and request. All requests to release stored data must be verified before data is sent. The local archive index would then be accessed to either retrieve the archived file from local storage or if not there from the storage central a site. To ensure that each system central site would not get rapidly overloaded with this transmission of data which could take quite a while through standard phone lines, each system central site would download the appropriate data to a front end computer which would then download the data to the requester. In the case where requested archives were stored in both the local and storage central sites, the local site would download data to the requester before the storage central site to avoid any transmission conflicts. Using front end computers for the downloading and uploading of data permits the storing and transmission of large amounts of data without taxing local site resources. It could also handle dedicated lines for this data transmission for companies that require large volumes of archived storage. By necessity, the storage of data at the storage central site may become an enormous task. Companies with large amounts of data may want to use the storage central site as a repository or to even have the storage central site call into their system via a dedicated line and perform a remote backup operation. Doing this would require vast storage resources but would not tax any operations of the data central site. Additionally, many of these backup operations will be able to be performed via the front-end computers. The Data Central Site The data central site is the site of storage and search of all user account information. Whereas each central site will maintain a list of immediate information concerning FAX and telephone numbers and public keys for the rapid transmission of such key to the sending site, additional information will also be stored for each account. This information will reside in one large data central site and will contain much demographic information including: telephone number FAX number, company name, contact with room for multiple contacts, address, country, etc. Additional information can also be stored concerning all types of information including: key personnel, products services, name of company, billing information, SIC numbers, etc. Data site services will include the searching through the database according to any number or combination of criteria--for a fee. This fee will be based on the number of searches, the number of criteria, the particular infuriation, and the resulting list of names. The fee would also be dependent upon the mount of data provided in the resulting list and the number of required fields. Most of this data would be provided upon the registration of the sending hardware device. Upon receipt of the initial code, the central site would transmit a form either via FAX, modem, or the mail requiring registration information, additional company information would also be added from follow-up questionnaires (which accompany bills) and the entry of data from existing sources. Billing Billing will be performed on a monthly basis by the data central site. This will be automatically performed though a number of steps. Each month, the user site will automatically dial into its local central site and downloaded information concerning the number of public keys requested, the number of secure FAXes and total number of pages transmitted, the number of digital signatures requested, etc. The local central site will add additional information to this data to storage charges, time stamp charges, and store and forward charges acquired during monthly usage. Once data of all accounts is accumulated, this billing information will then be downloaded to the data central site in one large transmission stream. If data cannot be acquired from the user site, a fixed charge of $25 will be assigned. This charge will be adjusted the next time the user turns on their computer or FAX machine since the first task of the security device will be the sending of this data to the local site. If after 15 days, no data is still received by the local site, the user site will be notified, and the security device functioning will be suspended until this data is downloaded to the local central site. Once all billing data resides in the data central site, billing can be automatically processed. Depending on account information, bills can be automatically printed and sent through the regular mail or sent via e-mail or by FAX Additional charges may also be accrued at the data central site for storage of data at that site, late charges, group maintenance, etc. Summary of Central Site System The central site system is comprised of several parts. At each user site is a security device capable of communicating via phone lines with a local central site. This communication via modem works similarly for both fax and computer data transmissions. Numerous central sites reside in "local" regions throughout the country with more able to be added, as needed. These central sites all perform the 'same series of tasks including: communication with the user site device, storing and time stamping of data, maintaining groups of data, etc. Each central site is supported by several front-end computers, capable of off-loading much of the system and transmission requirements from that particular central site. Each central site will communicate via a direct high-speed line with its adjoining central sites, the data central site will reside in only one place and will perform many specific tasks including the maintenance of all account and billing information. All billing will be performed from this site. Additionally, much of this account information can be queried (for a fee. The storage central site is the repository of most encrypted data, large files, storage data, etc. and also exists at one specialized site This site would also off-load and store data from any local central site. It could also maintain direct links to remote client sites for large (and scheduled) backups. In conclusion, this central site system is a real-time, high-volume system. It can meet the needs of almost every business or individual and yet is highly secure and extremely not-intrusive. It is designed for flexibility, multiple functionality, and expandability. By utilizing state-of-the-art technology, it can provide a wide range of services and features and incorporate new features and services as the technology continues to develop. CENTRAL DATABASE CONTROLLER The central database controller (CDC) must perform may functions. Most importantly, it must securely maintain all of the public keys provided to each fax. The public key/private key concept is central to the entire security design. The CDC functions as the repository of all the public keys in the central database. When first installed, each FAX automatically registers with public key with the CDC after the validation sequence is successfully completed. {The individual FAX maintains its own private key pair. This provides the CDC with the information--telephone number and public key--to maintain contact with all subscribing FAX terminal units. The integrity of the CDC central database is mandatory for this system to work safely. It is therefore extremely important that the CDC first verify the FAX (sender or target) before proceeding with any further communications. Verification Assume that FAX1 intends to send a faxcom to FAX2, but does not possess the public key of FAX2. FAX1 simply calls the CDC and asks, by providing a very small message incorporating a random encryption key (k?) and FAX1 digital signature. The CDC then verifies the caller FAX ID by comparing it with the identified caller public key, uses k? to encrypt the responding information, and sends the FAX2 public key, encrypted with (k?) to FAX1. BILLING, TIMESTAMPING AND SPECIAL FEATURES The CDC is responsible for the billing of all services. The fax units are designed to dial automatically to the CDC on a monthly basis to update their internal public key and FAXphone number table and to provide billing information to the CDC on the number of secure FAX pages sent and their levels of security. The higher the security, the greater the fee for a unit of usage. A monthly subscriber fee may be charged, with unit-of-service billing for units of service above a threshold. Timestamping and archive storage may conveniently be charged on a unit of service basis. Timestamping of data is an important service. Any user who requests timestamped, either by the document or each page, can have the message automatically sent to the CDC (in encrypted form). The CDC wilt then include the timestamp data superimposed on the FAX message before sending it to the target FAX terminal. The CDC may pass a copy of the message to archive storage, with the message still encrypted, including the timestamp. Group or broadcast capability may also be located at the CDC or at the individual FAX terminal. While the invention has been shown preferably in the form of a terminal unit communicating in a secure fashion with other terminal units over public telephone lines, stated alternatives such as dedicated lines may be used. Individual units are generically referred to as FAX units, but point-of-sale terminals or other devices which communicate fairy complex messages with a small or large amount of handshake return messages are included in the term "FAX," so long as the unit has communication capability over distance and has capability to operate with public and private keys and perform encryption/decryption functions. The alterations described, plus other changes which may be evident to those skilled in the art, are included within the spirit and scope of the invention as defined in the following claims.
|
Same subclass Same class Consider this |
||||||||||