Method for setting of true communication being checked, method for protected communication, method for renewal of micro-software, method for execution of enciphered communication and method for giving to device checked on identity of right on electron transaction
Abstract
The invention relates to the crypto-systems of communication. A method for setting of true communication being checked among majority of users which contains deposition operation. A majority of secret asymmetrical crypto-keys used by the majority of users are deposited in a trust storage center, each key of the majority of keys is checked in the storage center, each key of the majority of keys is certified after checking and connection of each user from majority of users is initiated with using of the corresponding key from the majority of keys depending on the results of certification.
Term
No projected expiry on record.
- Priority
- Filed
- Granted
- Today
131 claims: 130 independent, 1 dependent
- 1The method of establishing reliable verifiable communication among multiple users, containing the operation depositing, characterized in that that a number of secret asymmetrical deposits are deposited in a trusted storage center cryptographic keys used by multiple users are checked Each of the multiple keys in the storage center certify each of the multiple keys after verification and initiate communication of each of the multiple users with using the appropriate one of a variety of keys depending on certification results. 1. Способ установления достоверной проверяемой связи среди множества пользователей, содержащий операцию депонирования, отличающийся тем, что депонируют в доверенном центре хранения множество секретных асимметричных криптографических ключей, используемых множеством пользователей, проверяют каждый из множества ключей в центре хранения, сертифицируют каждый из множества ключей после проверки и инициируют связь каждым из множества пользователей с использованием соответствующего одного из множества ключей в зависимости от результатов сертификации.
- 2The way to establish authentic verifiable communication between users, containing a deposit operation, characterized in that they are deposited in trusted storage center secret asymmetric cryptographic key, associated with each of the multiple users, verify each of these keys in the storage center, they certify each of these keys after, check and initiate a secure connection by the initiating user to the receiving depending on the results of the certification of keys as initiating and receiving users. 2. Способ установления достоверной проверяемой связи между пользователями, содержащий операцию депонирования, отличающийся тем, что депонируют в доверенном центре хранения секретный асимметричный криптографический ключ, связанный с каждым из множества пользователей, проверяют каждый из этих ключей в центре хранения, сертифицируют каждый из этих ключей после, проверки и инициируют защищенную связь инициирующим пользователем с принимающим пользователем в зависимости от результатов сертификации ключей как инициирующего, так и принимающего пользователей.
- 3The method according to p. 2, characterized in that the proven the authenticity of the device initiating user performs the operation confirmation of certification of keys of both initiating and receiving users before initiating a secure connection. 3. Способ по п. 2, отличающийся тем, что проверенное на подлинность устройство инициирующего пользователя выполняет операцию подтверждения сертификации ключей как инициирующего, так и принимающего пользователей до инициации защищенной связи.
- 4The method according to p. 2, characterized in that the certification operation includes issuance of the deposited by the storage center certificate that certifies the key of the receiving user, and the operation initiating communication includes initiating user authentication deposited certificate of the receiving user. 4. Способ по п. 2, отличающийся тем, что операция сертификации включает выдачу центром хранения депонированного сертификата, который удостоверяет ключ принимающего пользователя, а операция инициации связи включает проверку инициирующим пользователем подлинности депонированного сертификата принимающего пользователя.
- 5The method according to p. 2, characterized in that it additionally includes the operations of issuing storage center certificates by the authorizing authority for the first and second storage centers, the specified receiving user depositing his key in the second center storage, issuing the first and second custom storage centers certificates for issuing and receiving users and validating originating the user of the certificate of reliability of the second center of snoring and certificate receiving user before initiating a secure connection. 5. Способ по п. 2, отличающийся тем, что он дополнительно включает операции выдачи санкционирующим органом сертификатов центра хранения для первого и второго центров хранения, причем указанный принимающий пользователь депонирует свой ключ во втором центре хранения, выдачи первым и вторым центрами хранения пользовательских сертификатов для выдающего и принимающего пользователей и проверки инициирующим пользователем достоверности сертификата второго центра храпения и сертификата принимающего пользователя до инициации защищенной связи.
- 6The method according to p. 2, characterized in that the proven authenticity device performs key verification operation host user using embedded logic protected from unauthorized actions. 6. Способ по п. 2, отличающийся тем, что проверенное на подлинность устройство выполняет операцию проверки с подтверждением ключа принимающего пользователя с помощью встроенной логики, защищенной от несанкционированных действий.
- 7The method according to p. 2, characterized in that the deposited key is an intermediate Diffie-Hellman protocol number. 7. Способ по п. 2, отличающийся тем, что депонированный ключ представляет собой промежуточный номер протокола Диффи-Хеллмана.
- 8The method of establishing reliable verifiable communication between multiple users with selective external access parties containing a deposit operation, different deposited in the trusted storage center secret asymmetric cryptographic keys associated with multiple users, each the user is associated with at least one key and at least the first selectable external party gets access to the connection with this user, verify these keys in the storage center, certify each of these keys after checking and initiate reliable communication by the sending user to recipient in such a way that provides access to the first external communication parties. 8. Способ установления достоверной проверяемой связи между множеством пользователей с выборочным доступом внешней стороны, содержащий операцию депонирования, отличающийся тем, что депонируют в доверенном центре хранения секретные асимметричные криптографические ключи, связанные с множеством пользователей, причем каждый пользователь связан по меньшей мере с одним ключом и по меньшей мере первая выбираемая внешняя сторона получает доступ к связи с данным пользователем, проверяют эти ключи в центре хранения, сертифицируют каждый из этих ключей после проверки и инициируют достоверную связь посылающим пользователем с получателем таким образом, что предоставляется доступ к связи первой внешней стороны.
- 9The method according to p. 8, characterized in that the operation of initiation connection includes the sending of access information encrypted with the key of the first external parties. 9. Способ по п. 8, отличающийся тем, что операция инициации связи включает посылку информации доступа, зашифрованной ключом первой внешней стороны.
- 10The method according to p. 8, characterized in that the operation Deposit includes registration in the storage center checked for the authenticity of the device associated with the user and with the first the outside. 10. Способ по п. 8, отличающийся тем, что операция депонирования включает операцию регистрации в центре хранения проверенного на подлинность устройства, связанного с пользователем и с первой внешней стороной.
- 11The method according to p. 10, characterized in that the deposit includes the issuance of the certificate by the initiating device the owner identifying the authenticated device and the first external side, and the transfer of the owner’s certificate to the escrow agent for identification of the first external party having access to the communication with the user. 11. Способ по п. 10, отличающийся тем, что депонирование включает операции выдачи инициирующим устройством сертификата первого владельца, идентифицирующего проверенное на подлинность устройство и первую внешнюю сторону, и передачи сертификата владельца агенту депонирования для идентификации первой внешней стороны, имеющей доступ к связи с пользователем.
- 12The method according to p. 8, characterized in that the operation of initiation communication involves sending information available to the second external party associated with the recipient to access the communication. 12. Способ по п. 8, отличающийся тем, что операция инициации связи включает посылку информации, доступной для второй внешней стороны, связанной с получателем, для получения доступа к связи.
- 13The method according to p. 8, characterized in that it additionally includes the recipient's transferring the designation of the second external side in the storage center along with the key of the recipient and the inclusion of the storage center designation of the second external side in the certificate with the key of the recipient. 13. Способ по п. 8, отличающийся тем, что он дополнительно включает операции передачи получателем обозначения второй внешней стороны в центр хранения вместе с ключом данного получателя и включения центром хранения обозначения второй внешней стороны в сертификат с ключем данного получателя.
- 14The method according to p. 13, characterized in that it additionally includes the operation of transferring the certificate of the receiving user to the sending user, and this certificate indicates the second outer side, having access to communication. 14. Способ по п. 13, отличающийся тем, что он дополнительно включает операцию передачи сертификата принимающего пользователя посылающему пользователю, причем данный сертификат указывает вторую внешнюю сторону, имеющую доступ к связи.
- 15The method of secure communication in the system, having at least one transmitting side and a message key that can be restored by a party not involved in communication, characterized in that it is provided to each user computer device, register devices in the center in accordance with control information specified by the owner of the device other than device users, certify devices, and at each certification certificate is generated, common to the center, user and devices initiate a secure connection by the initiating user to recipient using the message key in such a way that it permits access of the given owner to communication. 15. Способ защищенной связи в системе, имеющей по меньшей мере одну передающую сторону и ключ сообщения, который может быть восстановлен стороной, не участвующей в связи, отличающийся тем, что предоставляют каждому пользователю компьютерное устройство, регистрируют устройства в центре в соответствии с управляющей информацией, заданной владельцем устройства, отличным от пользователя устройства, сертифицируют устройства, причем при каждой сертификации генерируется сертификат, общий для центра, пользователя и устройства, инициируют защищенную связь инициирующим пользователем с получателем с использованием ключа сообщения таким образом, что это разрешает доступ данного владельца к связи.
- 16The method according to p. 15, characterized in that the registration operation includes the operation of registering a device only in the center selected from set of centers in accordance with the information given by the owner. 16. Способ по п. 15, отличающийся тем, что операция регистрации включает операцию регистрации устройства только в центре, выбранном из множества центров в соответствии с заданной владельцем информацией.
- 17The method according to p. 15, characterized in that the registration operation includes the registration of the device in the center selected from the set centers in accordance with the information entered into this device by a person not being a user. 17. Способ по п. 15, отличающийся тем, что операция регистрации включает операции регистрации устройства в центре, выбранном из множества центров в соответствии с информацией, введенной в данное устройство лицом, не являющимся пользователем.
- 18The method according to p. 15, characterized in that the registration operation includes device registration operations in the first device registration center in the second center selected from a set of centers in accordance with a given owner information. 18. Способ по п. 15, отличающийся тем, что операция регистрации включает операции регистрации устройства в первом центре регистрации устройства во втором центре, выбранном из множества центров в соответствии с заданной владельцем информацией.
- 19The method according to p. 15, characterized in that the registration operation includes device certification operations with a limited number of attempts to according to the information given by the owner. 19. Способ по п. 15, отличающийся тем, что операция регистрации включает операции сертификации устройства с ограниченным числом попыток в соответствии с заданной владельцем информацией.
- 20The method according to p. 15, characterized in that the registration operation includes the operation of registering the device in the center in accordance with the governing information specified by the owner of the second device, other than the owner first device. 20. Способ по п. 15, отличающийся тем, что операция регистрации включает операцию регистрации устройства в центре в соответствии с управляющей информацией, заданной владельцем второго устройства, отличным от владельца первого устройства.
- 21The method according to p. 20, characterized in that the owner of the second device is a user. 21. Способ по п. 20, отличающийся тем, что владельцем второго устройства является пользователь.
- 22The method according to p. 15, characterized in that the registration operation includes the operation of identifying the owner of the center. 22. Способ по п. 15, отличающийся тем, что операция регистрации включает операцию идентификации владельца данного центра.
- 23The method according to p. 15, characterized in that the recipient is storage device. 23. Способ по п. 15, отличающийся тем, что получателем является устройство хранения.
- 24The method according to p. 15, characterized in that at least one of the operations of this method requires the use of authenticated devices and this device is activated on the required operation only after entering the owner information into this authenticated device. 24. Способ по п. 15, отличающийся тем, что по меньшей мере одна из операций данного способа требует использования проверенного на подлинность устройства и это устройство задействуется на требуемой операции только после ввода информации владельца в данное проверенное на подлинность устройство.
- 25The method according to p. 15, characterized in that the device performs operation of this method in response to a command confirmed by a key other than the user of the person entered into this device. 25. Способ по п. 15, отличающийся тем, что устройство выполняет операцию данного способа в ответ на команду, подтвержденную ключем отличного от пользователя лица, введенным в данное устройство.
- 26The way to establish reliable verifiable communication between multiple users with third party access containing a deposit operation, different by depositing at least one of the many storage centers secret asymmetric cryptographic key associated with each of the many users, verify these keys in the storage center, certify each of these keys after verification and initiate reliable communication a user with a receiving user using a valid key, including the transfer of information to recover the key of the initiating user and the key of the receiving user. 26. Способ установления достоверной проверяемой связи между множеством пользователей с доступом третьей стороны содержащий операцию депонирования, отличающийся тем, что депонируют по меньшей мере в одном из множества центров хранения секретный асимметричный криптографический ключ, связанный с каждым из множества пользователей, проверяют эти ключи в центре хранения, сертифицируют каждый из этих ключей после проверки и инициируют достоверную связь передающим пользователем с принимающим пользователем с использованием проверенного ключа, включая передачу информации для восстановления ключа инициирующего пользователя и ключа принимающего пользователя.
- 27The method according to p. 26, characterized in that the specified connection includes the transfer of information indicating to the storage centers the sending keys and host users. 27. Способ по п. 26, отличающийся тем, что указанная связь включает передачу информации, указывающей центрам хранения ключи посылающего и принимающего пользователей.
- 28The method according to p. 26, characterized in that the specified connection includes information encrypted The key is connected to the storage center. 28. Способ по п. 26, отличающийся тем, что указанная связь включает информацию, зашифрованную ключом, связанньм с центром хранения.
- 29The method according to p. 26, characterized in that it additionally includes the recovery of the deposited key, save the recovered key in the authenticated device in a secure way, do not allow external devices to read this key and enter communication using the key contained in authenticated device. 29. Способ по п. 26, отличающийся тем, что он дополнительно включает операции восстановления депонированного ключа, сохранения восстановленного ключа в проверенном на подлинность устройстве безопасным способом, не допускающим считывания данного ключа внешними устройствами и вхождения в связь с использованием ключа, содержащегося в проверенном на подлинность устройстве.
- 30The method according to p. 29, characterized in that the operation of entry into communication involves the operation of entering a secure communication only for limited time period, and this time limit specifies the specified authenticated device. 30. Способ по п. 29, отличающийся тем, что операция вхождения в связь включает операцию вхождения в защищенную связь только в течение ограниченного периода времени, причем это ограничение времени задает указанное проверенное на подлинность устройство.
- 31The method according to p. 26, characterized in that it additionally includes operations to search for parts of the deposited key and restore full key for these parts. 31. Способ по п. 26, отличающийся тем, что он дополнительно включает операции поиска частей депонированного ключа и восстановления полного ключа по этим частям.
- 32The method according to p. 26, characterized in that it additionally includes an operation of keeping a watchdog by a protected device held communication sessions. 32. Способ по п. 26, отличающийся тем, что он дополнительно включает операцию ведения защищенным устройством контрольного журнала состоявшихся сеансов связи.
- 33The way to establish reliable verifiable communication between multiple users containing operations manufacturing electronic devices, each of which is operated by protected from unauthorized actions logic, characterized in that they initiate a secure connection between the initiating device and the recipient, including the transfer of information specified initiating device to allow access to external communication. 33. Способ установления достоверной проверяемой связи между множеством пользователей, содержащий операции изготовления электронных устройств, каждое из которых работает под управлением защищенной от несанкционированных действий логикой, отличающийся тем, что инициируют защищенную связь между инициирующим устройством и получателем, включая передачу информации, заданной инициирующим устройством, для разрешения доступа к связи внешней стороны.
- 34The method according to p. 33, characterized in that it additionally includes the manufacture of devices designed to reliably verifiable communication and protected from unauthorized user actions. 34. Способ по п. 33, отличающийся тем, что он дополнительно включает операцию изготовления устройств, предназначенных для достоверной проверяемой связи и защищенных от несанкционированных действий пользователя.
- 35The method of establishing reliable verifiable communication between users, containing a deposit operation, characterized in that it is deposited in the center storage secret asymmetric cryptographic key associated with each of dozens of users check these keys in this storage center, certify each of the keys after checking and initiating communication initiating user with the receiving user depending on the confirmation authenticated by the device initiating user certification Keys of transmitting and receiving users. 35. Способ установления достоверной проверяемой связи между пользователями, содержащий операцию депонирования, отличающийся тем, что депонируют в центре хранения секретный асимметричный криптографический ключ, связанный с каждым из множества пользователей, проверяют эти ключи в данном центре хранения, сертифицируют каждый из ключей после проверки и инициации связи инициирующим пользователем с принимающим пользователем в зависимости от подтверждения проверенным на подлинность устройством инициирующего пользователя сертификации ключей передающего и принимающего пользователей.
- 36The method according to p. 35, characterized in that the proven authenticity device carries the operations of storing the key of the storage center in memory and using this key to confirm the certificate of the storage center certifying that the key of the receiving user has been verified. 36. Способ по п. 35, отличающийся тем, что проверенное на подлинность устройство осуществляет операции запоминания ключа центра хранения в памяти и использования этого ключа для подтверждения сертификата центра хранения, удостоверяющего, что ключ принимающего пользователя был проверен.
- 37The method according to p. 35, characterized in that at least one from deposit, verification and certification operations are performed in response to a request from authenticated device. 37. Способ по п. 35, отличающийся тем, что по меньшей мере одну из операций депонирования, проверки и сертификации выполняют в ответ на запрос от проверенного на подлинность устройства.
- 38The method according to p. 35, characterized in that the proven The device authenticates a data structure using the key associated with this device. 38. Способ по п. 35, отличающийся тем, что проверенное на подлинность устройство задает структуру данных, используя ключ, связанный с данным устройством.
- 39The method according to p. 35, characterized in that it additionally includes the operation of generating an authenticated key device, to be deposited. 39. Способ по п. 35, отличающийся тем, что он дополнительно включает операцию генерирования проверенным на подлинность устройством ключа, подлежащего депонированию.
- 40The method according to p. 39, wherein the key is the key encryption communication. 40. Способ по п. 39, отличающийся тем, что ключ является ключом шифрования связи.
- 41The method according to p. 39, wherein the key is the key signatures. 41. Способ по п. 39, отличающийся тем, что ключ является ключом подписи.
- 42The method according to p. 39, characterized in that at least one of operations requires the use of authenticated devices, and this the device performs the required operation only after receiving the authorization information from a third party other than the user associated with it. 42. Способ по п. 39, отличающийся тем, что по меньшей мере одна из операций требует использования проверенного на подлинность устройства, а это устройство выполняет требуемую операцию только после получения санкционирующей информации от третьей стороны, отличной от связанного с ней пользователя.
- 43The way to establish reliable verifiable communication between users, containing a deposit operation, characterized in that they are deposited in trusted storage center secret asymmetric cryptographic key, associated with each of the multiple users, verify these keys in a given center, certify each of the keys after checking and initiating communication session by the initiating user with the receiving user in depending on the certification of the key used in connection with the transfer information allowing access to this session for the external party. 43. Способ установления достоверной проверяемой связи между пользователями, содержащий операцию депонирования, отличающийся тем, что депонируют в доверенном центре хранения секретный асимметричный криптографический ключ, связанный с каждым из множества пользователей, проверяют эти ключи в данном центре хранения, сертифицируют каждый из ключей после проверки и инициации сеанса связи инициирующим пользователем с принимающим пользователем в зависимости от сертификации ключа, использованного при связи, с передачей информации, разрешающей доступ к данному сеансу связи для внешней стороны.
- 44The method according to p. 43, characterized in that the access information includes an indication of the key user's storage center. 44. Способ по п. 43, отличающийся тем, что информация доступа включает указание центра хранения ключа принимающего пользователя.
- 45The method according to p. 43, characterized in that the access information contains an indication of the key user's storage center. 45. Способ по п. 43, отличающийся тем, что информация доступа содержит указание центра хранения ключа передающего пользователя.
- 46Способ по п. 43, отличающийся тем, что информация доступа включает информацию для восстановления ключа, депонированного в центре хранения, причем указанная информация восстановления зашифрована ключом центра хранения. 46. The method according to p. 43, characterized in that the access information Includes information to recover the key deposited in the center. storage, and this recovery information is encrypted with the center key storage.
- 47The method according to p. 43, wherein the communication session includes a key messages encrypted with the sending user key. 47. Способ по п. 43, отличающийся тем, что сеанс связи включает ключ сообщения, зашифрованный ключом посылающего пользователя.
- 48The method according to p. 43, wherein the communication session includes message key encrypted with the key of the receiving user. 48. Способ по п. 43, отличающийся тем, что сеанс связи включает ключ сообщения, зашифрованный ключом принимающего пользователя.
- 50The method according to p. 43, characterized in that the access information includes information indicating the time of communication. 50. Способ по п. 43, отличающийся тем, что информация доступа включает информацию, указывающую время осуществления связи.
- 51The method according to p. 43, characterized in that the access information includes an indication of the geographical area associated with the storage center host user. 51. Способ по п. 43, отличающийся тем, что информация доступа включает указание географической области, связанной с центром хранения принимающего пользователя.
- 52The method according to p. 43, characterized in that the access information includes an indication of the geographical area associated with the storage center sending user. 52. Способ по п. 43, отличающийся тем, что информация доступа включает указание географической области, связанной с центром хранения передающего пользователя.
- 53The method according to p. 43, characterized in that the tested on the authenticity of the sending user device sets the access information, using the key associated with this authenticated device. 53. Способ по п. 43, отличающийся тем, что проверенное на подлинность устройство передающего пользователя задает информацию доступа, используя ключ, связанный с этим проверенным на подлинность устройством.
- 54The method of establishing reliable, verifiable communication between multiple users, containing a deposit operation, different By depositing a secret asymmetrical storage facility in a trusted storage center. a cryptographic key associated with each of a number of users, check the keys in the storage center, certify each of the keys after validated and authenticated devices associated with each user, and initiate communication initiating user with the recipient after certification of the key used in the communication and after confirmation the attributes of the authenticated device associated with the originating by user. 54. Способ установления достоверной, проверяемой связи между множеством пользователей, содержащий операцию депонирования, отличающийся тем, что депонируют в доверенном центре хранения секретный асимметричный криптографический ключ, связанный с каждым из множества пользователей, проверяют ключи в центре хранения, сертифицируют каждый из ключей после проверки и проверенного на подлинность устройства, связанного с каждым пользователем, и инициируют связь инициирующим пользователем с получателем после сертификации ключа, использованного при связи, и после подтверждения атрибутов проверенного на подлинность устройства, связанного с инициирующим пользователем.
- 55The method according to p. 54, characterized in that it additionally includes the operation of issuing a certificate for the user by the storage center additionally including a user key and a key associated with a verified device authenticity. 55. Способ по п. 54, отличающийся тем, что он дополнительно включает операцию выдачи центром хранения сертификата для пользователя, дополнительно включающего ключ пользователя и ключ, связанный с проверенным на подлинность устройством.
- 56The method according to p. 54, characterized in that it additionally includes the operation of issuing a certificate for the user by the storage center containing information indicating a selectable external side other than user to access a communication session involving this user 56. Способ по п. 54, отличающийся тем, что он дополнительно включает операцию выдачи центром хранения сертификата для пользователя, содержащего информацию, указывающую выбираемую внешнюю сторону, отличную от пользователя, для получения доступа к сеансу связи с участием данного пользователя.
- 57The method according to p. 54, characterized in that it additionally includes the operation of issuing a certificate for the user by the storage center additionally including a key selectable external side other than user 57. Способ по п. 54, отличающийся тем, что он дополнительно включает операцию выдачи центром хранения сертификата для пользователя, дополнительно включающего ключ выбираемой внешней стороны, отличной от пользователя.
- 58The method according to p. 54, characterized in that it additionally includes the operation of issuing a certificate by the storage center;includes information indicating the geographic area associated with the center storage. 58. Способ по п. 54, отличающийся тем, что он дополнительно включает операцию выдачи центром хранения сертификата, дополнительно включающего информацию, указывающую географическую область, связанную с центром хранения.
- 59The method according to p. 54, wherein the recipient is storage device. 59. Способ по п. 54, отличающийся тем, что получателем является устройство хранения.
- 60The method of establishing reliable verifiable communication between users, containing a deposit operation, characterized in that they are deposited in trusted storage centers asymmetric cryptographic keys associated with users, and some of these centers storage belong to the first group, while others belong to the second group, check keys in storage centers, certify each of these keys after verification and communicate between the first and second users depending on groups to which the transmitting and receiving storage centers belong users. 60. Способ установления достоверной проверяемой связи между пользователями, содержащий операцию депонирования, отличающийся тем, что депонируют в доверенных центрах хранения асимметричные криптографические ключи, связанные с пользователями, причем одни из указанных центров хранения принадлежат к первой группе, а другие - ко второй группе, проверяют ключи в центрах хранения, сертифицируют каждый из данных ключей после проверки и осуществляют связь между первым и вторым пользователями в зависимости от групп, к которым принадлежат центры хранения передающего и принимающего пользователей.
- 61The method according to p. 60, characterized in that the storage center indicates its group in the certificate containing the user key. 61. Способ по п. 60, отличающийся тем, что центр хранения указывает свою группу в сертификате, содержащем ключ пользователя.
- 62The method according to p. 60, wherein the first user initiates communication with the second user depending on the group indication storage center in the certificate of the second user. 62. Способ по п. 60, отличающийся тем, что первый пользователь инициирует связь со вторым пользователем в зависимости от указания группы центра хранения в сертификате второго пользователя.
- 63The method according to p. 60, characterized in that the second user communicates with the first user depending on the group indication storage center in the first user certificate. 63. Способ по п. 60, отличающийся тем, что второй пользователь осуществляет связь с первым пользователем в зависимости от указания группы центра хранения в сертификате первого пользователя.
- 64The method of establishing reliable, verifiable thread-oriented communication between users, containing deposit operation, different deposited in a trusted storage center an asymmetric cryptographic key associated with each of the users, verify each of the keys in this storage center, certify each of the keys after verification and carry out encrypted thread-oriented user-initiated communication with the receiving user using the cryptographic key initiating user and sending the initial packet containing access information that allows the outside to decrypt the stream and stream subsequent packets, each of which contains information identifying This subsequent packet is associated with the flow, with at least one of the specified subsequent packages do not contain the specified access information. 64. Способ установления достоверной, проверяемой поточно-ориентированной связи между пользователями, содержащий операцию депонирования, отличающийся тем, что депонируют в доверенном центре хранения асимметричный криптографический ключ, связанный с каждым из пользователей, проверяют каждый из ключей в данном центре хранения, сертифицируют каждый из ключей после проверки и осуществляют шифрованную поточно-ориентированную связь инициируемую пользователем с принимающим пользователем с использованием криптографического ключа инициирующего пользователя и передачей начального пакета, содержащего информацию доступа, позволяющую внешней стороне дешифровать поток и поток последующих пакетов, каждый из которых содержит информацию, идентифицирующую данный последующий пакет как связанный с потоком, причем по меньшей мере один из указанных последующих пакетов не содержит указанной информации доступа.
- 65The method according to p. 64, characterized in that the communication session further comprises transmitting a final packet having information, indicating the end of the communication session. 65. Способ по п. 64, отличающийся тем, что сеанс связи дополнительно содержит передачу заключительного пакета, имеющего информацию, обозначающую конец сеанса связи.
- 66The method according to p. 64, characterized in that each subsequent The package also includes unique information indicating the position of this package. in the given sequence. 66. Способ по п. 64, отличающийся тем, что каждый последующий пакет включает также уникальную информацию, указывающую положение этого пакета в данной последовательности.
- 67The method of clause 64, wherein each subsequent The package also includes information with a time stamp. 67. Способ по п. 64, отличающийся тем, что каждый последующий пакет включает также информацию с отметкой времени.
- 68The method according to p. 64, characterized in that the access information contains a hashed initial packet. 68. Способ по п. 64, отличающийся тем, что информация доступа содержит хешированный начальный пакет.
- 69The method according to p. 68, characterized in that said the hashed initial packet is injected with an initiating cryptographic key user 69. Способ по п. 68, отличающийся тем, что указанный хешированный начальный пакет вводят с криптографическим ключом инициирующего пользователя.
- 70Method p. 69, characterized in that the specified information Access also includes information identifying the message. 70. Способ п. 69, отличающийся тем, что указанная информация доступа включает также информацию, идентифицирующую сообщение.
- 71The method according to p. 70, characterized in that at least one of the subsequent packets contains the identifying message information. 71. Способ по п. 70, отличающийся тем, что по меньшей мере один из последующих пакетов содержит идентифицирующую сообщение информацию.
- 72The method according to p. 71, characterized in that the specified information identifying this subsequent packet as being associated with a stream, represents is the package sequence number. 72. Способ по п. 71, отличающийся тем, что указанная информация, идентифицирующая данный последующий пакет как связанный с потоком, представляет собой порядковый номер пакета.
- 73The method according to p. 64, characterized in that it additionally contains the operations of the initiating user receiving information related to the quality of the channel through which the thread-oriented communication is performed, and selective inclusion of information identifying the message in subsequent quality-determined packets this channel. 73. Способ по п. 64, отличающийся тем, что он дополнительно содержит операции приема инициирующим пользователем информации, относящейся к качеству канала, по которому осуществляют поточно-ориентированную связь, и избирательного включения идентифицирующей сообщение информации в последующие пакеты с частотой, определяемой качеством данного канала.
- 74The method of clause 64, wherein the packages include information linking them to the originating user. 74. Способ по п. 64, отличающийся тем, что пакеты включают информацию, связывающую их с инициирующим пользователем.
- 75Firmware update method ensuring a device tested for authenticity, characterized in that they are built into a authenticated device. device key associated with the firmware source is passed firmware for this authenticated device, Moreover, such a transfer is modified by the source of this firmware. provide a certain way that can be confirmed by embedded key, and the inclusion of firmware in this authenticated device depending on the confirmation of the transfer with using the built-in key. 75. Способ обновления микропрограммного обеспечения проверенного на подлинность устройства, отличающийся тем, что встраивают в проверенное на подлинность устройство ключ, связанный с источником микропрограммного обеспечения, передают микропрограммное обеспечение данному проверенному на подлинность устройству, причем такая передача модифицирована источником данного микропрограммного обеспечения определенным образом, который может быть подтвержден с помощью встроенного ключа, и включения микропрограммного обеспечения в данное проверенное на подлинность устройство в зависимости от подтверждения передачи с помощью встроенного ключа.
- 76The method according to p. 75, characterized in that the source firmware initiates a connection, and this checked for the authenticity of the device confirms the connection by verifying the signature using embedded key. 76. Способ по п. 75, отличающийся тем, что источник микропрограммного обеспечения инициирует связь, а данное проверенное на подлинность устройство подтверждает связь путем проверки подписи с помощью встроенного ключа.
- 77The method according to p. 75, characterized in that this The firmware includes executable code. 77. Способ по п. 75, отличающийся тем, что данное микропрограммное обеспечение включает исполнимый программный код.
- 78The method according to p. 75, characterized in that this Firmware includes a cryptographic key. 78. Способ по п. 75, отличающийся тем, что данное микропрограммное обеспечение включает криптографический ключ.
- 79The method according to p. 75, characterized in that it additionally contains the operation of embedding keys used to confirm firmware. 79. Способ по п. 75, отличающийся тем, что он дополнительно содержит операцию встраивания ключей, используемых для подтверждения микропрограммного обеспечения.
- 80The method of implementing encrypted communications in a system containing communicating parties and using a message key, recoverable by a party not involved in communication, characterized in that it is provided to each user a computer device having at least one associated with the device key, register devices in at least one of centers, certify devices with the formation of a certificate for the device and initiate a secure communication session user with the recipient using the message key, and communication session contains an access fragment encrypted with a center key, employee to restore the message key. 80. Способ осуществления шифрованной связи в системе, содержащей сообщающиеся стороны и использующей ключ сообщения, восстанавливаемый стороной, не участвующей в связи, отличающийся тем, что предоставляют каждому пользователю компьютерное устройство, имеющее по меньшей мере один связанный с устройством ключ, регистрируют устройства по меньшей мере в одном из центров, сертифицируют устройства с формированием сертификата для устройства и инициируют защищенный сеанс связи инициирующим пользователем с получателем с использованием ключа сообщения, причем указанный сеанс связи содержит фрагмент доступа, зашифрованный с помощью ключа центра, служащего для восстановления ключа сообщения.
- 81The method according to p. 80, characterized in that the access fragment, encrypted with a center key, contains information identifying key deposited in this center. 81. Способ по п. 80, отличающийся тем, что фрагмент доступа, зашифрованный с помощью ключа центра, содержит информацию, идентифицирующую ключ, депонированный в данном центре.
- 82The method of clause 80, wherein the certificate includes public key from a pair of public / private keys. 82. Способ по п. 80, отличающийся тем, что сертификат включает открытый ключ из пары открытого/секретного ключей.
- 83The method of clause 80, wherein the access information contains information for centers required for key recovery messages. 83. Способ по п. 80, отличающийся тем, что информация доступа содержит информацию для центров, необходимую для восстановления ключа сообщения.
- 84The method according to p. 80, characterized in that the operation communication includes the act of incorporating authenticated verification device access information in a way protected from unauthorized user action. 84. Способ по п. 80, отличающийся тем, что операция осуществления связи включает операцию включения проверенным на подлинность устройством информации доступа способом, защищенным от несанкционированных действий пользователя.
- 85The method according to p. 80, characterized in that the operation of the implementation communication involves encrypting access information using the key of the first center and encrypt access information using the second center key. 85. Способ по п. 80, отличающийся тем, что операция осуществления связи включает операции шифрования информации доступа с помощью ключа первого центра и шифрования информации доступа с помощью ключа второго центра.
- 86The method of providing a proven on the authenticity of the device the right to conduct an electronic transaction between first user and second party and ensure that authenticated device will carry out an electronic transaction in accordance with pre-established rules that cannot be changed by specified user, different that carry out electronic transfer specified authenticated device to a third party request for the right to exercise electronic transaction, and the request includes device authentication, set by specified third party the fact that the device specified for authenticity must be granted the right to perform the specified transaction at least partly in accordance with the confirmation of the fact that The authenticity of the device will only work as indicated. rules, an electronic transfer specified by a third party specified authenticated device of the right to exercise said electronic transactions, and the granting of the right provides for certifying that said third party granted said right, an electronic transmission authenticated device specified second side specified certificates as proof that this device has the right on the implementation of this electronic transaction and will implement it only in accordance with the specified rules, electronic data transmission transactions specified authenticated device specified second side in accordance with the specified rules. 86. Способ предоставления проверенному на подлинность устройству права на проведение электронной транзакции между первым пользователем и второй стороной и обеспечения гарантии того, что проверенное на подлинность устройство будет осуществлять электронную транзакцию в соответствии с заранее установленными правилами, которые не могут быть изменены указанным пользователем, отличающийся тем, что осуществляют электронную передачу указанным проверенным на подлинность устройством третьей стороне запроса на предоставление права на осуществление электронной транзакции, причем запрос включает подтверждение подлинности устройства, устанавливают указанной третьей стороной того факта, что указанному проверенному на подлинность устройству должно быть предоставлено право на осуществление указанной транзакции по меньшей мере частично в соответствии с подтверждением того факта, что проверенное на подлинность устройство будет работать только в соответствии с указанными правилами, электронную передачу указанной третьей стороной указанному проверенному на подлинность устройству права на осуществление указанной электронной транзакции, причем предоставление права предусматривает удостоверение того, что указанная третья сторона предоставила указанное право, электронную передачу проверенным на подлинность устройством указанной второй стороне указанного удостоверения в качестве подтверждения того, что данное устройство имеет право на осуществление указанной электронной транзакции и будет осуществлять ее только в соответствии с указанными правилами, электронную передачу данных транзакции указанным проверенным на подлинность устройством указанной второй стороне в соответствии с указанными правилами.
- 87The method according to p. 86, characterized in that the transfer operation rights includes the operation of transferring specified rules to a specified third party. specified authenticated device. 87. Способ по п. 86, отличающийся тем, что операция передачи права включает операцию передачи указанных правил указанной третьей стороной указанному проверенному на подлинность устройству.
- 88The method according to p. 86, characterized in that said verified the authenticity of the device contains the specified rules before the specified transfer operation right. 88. Способ по п. 86, отличающийся тем, что указанное проверенное на подлинность устройство содержит указанные правила до указанной операции передачи права.
- 89The method according to p. 86, characterized in that said operation transfer of rights provides for the accession of a digital signature specified third parties to the specified certificate. 89. Способ по п. 86, отличающийся тем, что указанная операция передачи права предусматривает присоединение цифровой подписи указанной третьей стороны к указанному удостоверению.
- 90The method according to p. 86, characterized in that the transfer operation the request includes the transfer of authentication of the specified authentication the specified device having a digital signature from the manufacturer of this authentic device. 90. Способ по п. 86, отличающийся тем, что операция передачи запроса включает операцию передачи удостоверения указанной подлинности указанного устройства, имеющего цифровую сигнатуру изготовителя данного достоверного устройства.
- 91The method according to p. 86, characterized in that said operation of establishment includes the operation of establishing whether the specified authenticated device against unauthorized actions Based on the specified authenticity of this authenticated device. 91. Способ по п. 86, отличающийся тем, что указанная операция установления включает операцию установления того, защищено ли указанное проверенное на подлинность устройство от несанкционированных действий, на основании указанной подлинности данного проверенного на подлинность устройства.
- 92The method according to p. 86, characterized in that said verified the authenticity of the device has an associated public key and a secret key asymmetric cryptosystem, and the specified request transfer operation includes The operation of transferring a given public key to a specified third party. 92. Способ по п. 86, отличающийся тем, что указанное проверенное на подлинность устройство имеет связанный с ним открытый ключ и секретный ключ асимметричной криптосистемы, а указанная операция передачи запроса включает операцию передачи данного открытого ключа устройства указанной третьей стороне.
- 93The method according to p. 86, characterized in that said reliable the device has associated with it the first key and the second key asymmetric cryptosystems, and the specified transaction data transfer operation specified second side includes adding a digital signature of this authentic device, created using the specified first key. 93. Способ по п. 86, отличающийся тем, что указанное достоверное устройство имеет связанные с ним первый ключ и второй ключ асимметричной криптосистемы, а указанная операция передачи данных транзакции указанной второй стороне включает добавление цифровой сигнатуры данного достоверного устройства, созданной с использованием указанного первого ключа.
- 94The method according to p. 90, characterized in that said The authentication contains the public key of a public / private pair. keys for the specified authenticated device, and the specified the request transfer operation includes a digital signature of this authenticated device created using the specified device secret key, to this request so that the specified third party is able to confirm that This request came from this authenticated device. 94. Способ по п. 90, отличающийся тем, что указанное удостоверение подлинности содержит открытый ключ из пары открытого/секретного ключей для указанного проверенного на подлинность устройства, а указанная операция передачи запроса включает цифровую сигнатуру данного проверенного на подлинность устройства, созданной с использованием указанного секретного ключа устройства, к данному запросу так, чтобы указанная третья сторона смогла подтвердить, что данный запрос поступил от данного проверенного на подлинность устройства.
- 95The method according to p. 93, characterized in that the specified operation transfer of transaction data to the specified second party includes the transfer operation said second key to the second side. 95. Способ по п. 93, отличающийся тем, что указанная операция передачи данных транзакции указанной второй стороне включает операцию передачи указанного второго ключа второй стороне.
- 96The method according to p. 93, characterized in that said first and The second device keys are the secret and public keys, respectively. 96. Способ по п. 93, отличающийся тем, что указанные первый и второй ключи устройства являются соответственно секретным и открытым ключами.
- 97The method according to p. 91, characterized in that said first and The second device keys are the secret and public keys, respectively. 97. Способ по п. 91, отличающийся тем, что указанные первый и второй ключи устройства являются соответственно секретным и открытым ключами.
- 98The way to establish authentic verifiable communication between multiple users, including the formation of secure communication inside electronic hardware device, characterized in that form a secure connection inside the electronic the hardware device of the first user, and the specified secure communication includes access information providing external access to this secure connection, entering a secure connection with a private signature key dependent from the registration chip on the electronic hardware device of the first the user, and the specified chip-dependent secret key signature was embedded in the copy-protected memory associated with the microchip registering the first user before the electronic hardware device was provided to the first user attach certificate to secure connection, and the specified certificate includes a public key signature, corresponding to the private signature key of the first registration chip a user registered with a trusted signature private key hand, and the transfer of secure communication to the second user. 98. Способ установления достоверной проверяемой связи между множеством пользователей, включающий формирование защищенной связи внутри электронного аппаратного устройства, отличающийся тем, что формируют защищенную связь внутри электронного аппаратного устройства первого пользователя, причем указанная защищенная связь включает информацию доступа, обеспечивающую доступ внешней стороны к данной защищенной связи, вход в защищенную связь с секретным ключом подписи, зависящим от микросхемы регистрации на электронном аппаратном устройстве первого пользователя, причем указанный зависящий от микросхемы секретный ключ подписи был внедрен в защищенную от копирования память, связанную с микросхемой регистрации первого пользователя, до того как электронное аппаратное устройство было предоставлено первому пользователю, присоединяют сертификат к защищенной связи, причем указанный сертификат включает открытый ключ подписи, соответствующий секретному ключу подписи микросхемы регистрации первого пользователя, зарегистрированного с секретным ключом подписи доверенной стороны, и передачу защищенной связи второму пользователю.
- 99The method according to p. 98, characterized in that it additionally contains the operations of receiving a secure connection on an electronic hardware device the second user and checking the public key signature of the registration chip the first user using the signature private key of the trusted party. 99. Способ по п. 98, отличающийся тем, что он дополнительно содержит операции приема защищенной связи на электронном аппаратном устройстве второго пользователя и проверки открытого ключа подписи микросхемы регистрации первого пользователя с помощью открытого ключа подписи доверенной стороны.
- 100The method according to p. 99, characterized in that the certificate is implemented in protected from unauthorized access memory registration chip first user before The electronic hardware device was provided to the first user. 100. Способ по п. 99, отличающийся тем, что сертификат внедряют в защищенную от несанкционированного доступа память микросхемы регистрации первого пользователя до того, как электронное аппаратное устройство было предоставлено первому пользователю.
- 101The method according to p. 100, characterized in that the public key signature trusted side is implemented in unreadable, protected from unauthorized access memory registration chip on electronic hardware device of the second user. 101. Способ по п. 100, отличающийся тем, что открытый ключ подписи доверенной стороны внедряют в нечитаемую, защищенную от несанкционированного доступа память микросхемы регистрации на электронном аппаратном устройстве второго пользователя.
- 102The method according to p. 101, characterized in that the trusted party is the manufacturer of the first user registration chip. 102. Способ по п. 101, отличающийся тем, что доверенной стороной является изготовитель микросхемы регистрации первого пользователя.
- 103The method according to p. 101, characterized in that the public keys signatures of several trusted parties are implemented in unreadable, protected from unauthorized access memory chip registration of the second user. 103. Способ по п. 101, отличающийся тем, что открытые ключи подписи нескольких доверенных сторон внедряют в нечитаемую, защищенную от несанкционированного доступа память микросхемы регистрации второго пользователя.
- 104The method according to p. 98, characterized in that it additionally contains the operations of creating a user-dependent pair of public / private key encryption / decryption inside the electronic the first user's hardware device, and encryption of secure communications with using a secret encryption key inside an electronic hardware device first user. 104. Способ по п. 98, отличающийся тем, что он дополнительно содержит операции создания зависящей от пользователя пары из открытого/секретного ключей шифрования/расшифровки внутри электронного аппаратного устройства первого пользователя, и шифрования защищенной связи с помощью секретного ключа шифрования внутри электронного аппаратного устройства первого пользователя.
- 105The method according to p. 104, characterized in that a couple of public / secret encryption / decryption keys are created using the RSA algorithm. 105. Способ по п. 104, отличающийся тем, что пару из открытого/секретного ключей шифрования/расшифровки создают с помощью алгоритма RSA.
- 106The method according to p. 105, characterized in that the secret key signatures of the first user registration chip are generated using DSA algorithm. 106. Способ по п. 105, отличающийся тем, что секретный ключ подписи микросхемы регистрации первого пользователя генерируют с помощью алгоритма DSA.
- 107The method according to p. 106, characterized in that the secret key Trusted party signatures are generated using the DSA algorithm. 107. Способ по п. 106, отличающийся тем, что секретный ключ подписи доверенной стороны генерируют с помощью алгоритма DSA.
- 108The method of establishing reliable verifiable thread-safe communication between multiple users, containing a deposit operation, different deposited in an asymmetrical trust center a cryptographic key associated with each of a number of users, verify each of these keys in the storage center, certify each of data keys after verification and accept the receiving user first encrypted stream-based transmission from the originating user, moreover, the specified transfer is encrypted using a cryptographic key specified initiating user, and the specified first transfer includes initial package containing access information allowing outside decrypt the stream, and the stream of subsequent packets, each of the subsequent package contains information identifying this subsequent package as associated with the stream, and at least one of the subsequent packets of the first stream does not contain the specified access information. 108. Способ установления достоверной проверяемой поточно-ориентированной связи между множеством пользователей, содержащий операцию депонирования, отличающийся тем, что депонируют в центре доверенного хранения асимметричный криптографический ключ, связанный с каждым из множества пользователей, проверяют каждый из данных ключей в центре хранения, сертифицируют каждый из данных ключей после проверки и принимают у принимающего пользователя первую шифрованную поточно-ориентированную передачу от инициирующего пользователя, причем указанная передача зашифрована с помощью криптографического ключа указанного инициирующего пользователя, и указанная первая передача включает начальный пакет, содержащий информацию доступа, позволяющую внешней стороне дешифровать поток, и поток последующих пакетов, причем каждый из последующих пакетов содержит информацию, идентифицирующую данный последующий пакет как связанный с потоком, и по крайней мере один из последующих пакетов первого потока не содержит указанной информации доступа.
- 109The method according to p. 108, characterized in that it additionally contains the operations of forming the second encrypted thread-oriented transfers from the receiving user to the initiating user with using the cryptographic key of the receiving user, and said second transmission includes an initial packet containing access information, allowing the outside to decrypt the second encrypted flow, and the flow of subsequent packets, with each subsequent packet contains information identifying this subsequent packet as associated with the second encrypted stream. 109. Способ по п. 108, отличающийся тем, что он дополнительно содержит операции формирования второй шифрованной поточно-ориентированной передачи от принимающего пользователя к инициирующему пользователю с использованием криптографического ключа принимающего пользователя, причем указанная вторая передача включает начальный пакет, содержащий информацию доступа, позволяющую внешней стороне осуществлять расшифровку второго шифрованного потока, и поток последующих пакетов, причем каждый последующий пакет содержит информацию, идентифицирующую данный последующий пакет как связанный со вторым шифрованным потоком.
- 110The method according to p. 108, characterized in that the access information the second encrypted stream includes the checksum of the initial packet second encrypted stream registered with a cryptographic key host user. 110. Способ по п. 108, отличающийся тем, что информация доступа второго шифрованного потока включает контрольную сумму начального пакета второго шифрованного потока, зарегистрированного с криптографическим ключом принимающего пользователя.
- 111The method of clause 110, wherein the access information the second encrypted stream includes identifying message information received from the original user 111. Способ по п. 110, отличающийся тем, что информация доступа второго шифрованного потока включает идентифицирующую сообщение информацию, полученную от первоначального пользователя.
- 112The method according to p. 109, characterized in that at least one of the subsequent packets of the second encrypted stream includes an identifying message information. 112. Способ по п. 109, отличающийся тем, что по крайней мере один из последующих пакетов второго шифрованного потока включает идентифицирующую сообщение информацию.
- 113The method according to p. 112, characterized in that the information identifying the subsequent packet of the second encrypted stream as associated with This second encrypted stream is the sequence number of the packet. 113. Способ по п. 112, отличающийся тем, что информация, идентифицирующая последующий пакет второго шифрованного потока как связанный с данным вторым шифрованным потоком, представляет собой порядковый номер пакета.
- 114The method according to p. 113, characterized in that the packets of the second encrypted stream include information linking them with the initiating by user. 114. Способ по п. 113, отличающийся тем, что пакеты второго шифрованного потока включают информацию, связывающую их с инициирующим пользователем.
- 115The method according to p. 109, characterized in that it additionally contains the operations of receiving from the receiving user information relating to the quality of the streaming channel;and selective inclusion of information identifying the message in subsequent packets at a rate determined by the quality of the channel. 115. Способ по п. 109, отличающийся тем, что он дополнительно содержит операции приема у принимающего пользователя информации, касающейся качества канала, по которому осуществляют поточно-ориентированную передачу, и избирательного включения идентифицирующей сообщение информации в последующие пакеты со скоростью, определяемой качеством данного канала.
- 116The method according to p. 115, characterized in that the information regarding the quality of this channel, take continuously, and the speed with which the identifying information is selectively included in subsequent packages, dynamically adjust depending on the information received. 116. Способ по п. 115, отличающийся тем, что информацию, касающемся качества данного канала, принимают непрерывно, а скорость, с которой идентифицирующую информацию избирательно включают в последующие пакеты, динамически регулируют в зависимости от полученной информации.
- 117Update method reliable device firmware, characterized in that they accept transmission a reliable device, confirm the source of the specified transfer using a key embedded in the specified authentic device, the specified key being the key associated with the source firmware, and include this firmware in a reliable device after confirm the source of the firmware. 117. Способ обновления микропрограммного обеспечения достоверного устройства, отличающийся тем, что принимают передачу микропрограммного обеспечения достоверным устройством, подтверждают источник указанной передачи с помощью ключа, внедренного в указанное достоверное устройство, причем указанный ключ является ключом, связанным с источником микропрограммного обеспечения, и включают данное микропрограммное обеспечение в состав достоверного устройства после подтверждения источника микропрограммного обеспечения.
- 118The method according to p. 117, characterized in that the key is embedded in authentic device is a public key verification signature this source of firmware, with the specified operation confirmation includes the operation of checking that the transmission was registered with the signature private key of this source firmware. 118. Способ по п. 117, отличающийся тем, что ключ, внедренный в достоверное устройство, представляет собой открытый ключ проверки подписи данного источника микропрограммного обеспечения, при этом указанная операция подтверждения включает операцию проверки того, что передача была зарегистрирована с помощью секретного ключа подписи данного источника микропрограммного обеспечения.
- 119The method according to p. 118, characterized in that the specified source The firmware is the manufacturer of a reliable device. 119. Способ по п. 118, отличающийся тем, что указанным источником микропрограммного обеспечения является изготовитель достоверного устройства.
- 120The method according to p. 119, characterized in that the transfer Firmware includes a public signature key that must be embedded in a reliable device firmware. 120. Способ по п. 119, отличающийся тем, что передача микропрограммного обеспечения включает открытый ключ подписи, который должен быть внедрен в микропрограммное обеспечение достоверного устройства.
- 121The method according to p. 117, characterized in that the key is embedded in authentic device is a public key verification signature authorized subject, with the specified confirmation operation includes verification operation using signature verification public key authorized entity of the fact that the transfer includes a certificate updates registered with the secret signature key authorized entity, and the renewal certificate includes the public key signatures of this source of firmware. 121. Способ по п. 117, отличающийся тем, что ключ, внедренный в достоверное устройство, представляет собой открытый ключ проверки подписи уполномоченного субъекта, при этом указанная операция подтверждения включает операцию проверки с использованием открытого ключа проверки подписи уполномоченного субъекта того факта, что передача включает сертификат обновления, зарегистрированный с помощью секретного ключа подписи уполномоченного субъекта, а сертификат обновления включает открытый ключ подписи данного источника микропрограммного обеспечения.
- 122The method according to p. 121, characterized in that said operation confirmation includes an additional verification operation using Signature verification public key of this source of firmware ensure that the transfer was registered using a secret the signature key of this firmware source security 122. Способ по п. 121, отличающийся тем, что указанная операция подтверждения включает дополнительно операцию проверки с использованием открытого ключа проверки подписи данного источника микропрограммного обеспечения того факта, что передача была зарегистрирована с помощью секретного ключа подписи данного источника микропрограммного обеспечения.
- 123The method according to p. 122, characterized in that the authorized the subject is the manufacturer of the authentic device, with the source The firmware is a trusted third party. 123. Способ по п. 122, отличающийся тем, что уполномоченным субъектом является изготовитель достоверного устройства, при этом источником микропрограммного обеспечения является доверенная третья сторона.
- 124The method according to p. 123, characterized in that the transfer the firmware includes the signature verification public key, which must be embedded in a reliable device firmware. 124. Способ по п. 123, отличающийся тем, что передача микропрограммного обеспечения включает открытый ключ проверки подписи, который должен быть внедрен в микропрограммное обеспечение достоверного устройства.
- 125The method according to p. 124, characterized in that the transfer Firmware includes a public key verification signature for trusted third party. 125. Способ по п. 124, отличающийся тем, что передача микропрограммного обеспечения включает открытый ключ проверки подписи для доверенной третьей стороны.
- 126The method according to p. 125, characterized in that the transfer firmware includes further information identifying transactions that can be performed by a trusted third party. 126. Способ по п. 125, отличающийся тем, что передача микропрограммного обеспечения включает далее информацию, идентифицирующую транзакции, которые могут быть выполнены доверенной третьей стороной.
- 127The method according to p. 126, wherein the trusted third the party is authorized to replace the source’s public key verification key firmware. 127. Способ по п. 126, отличающийся тем, что доверенная третья сторона уполномочена заменить открытый ключ проверки подписи данного источника микропрограммного обеспечения.
- 128The method according to p. 127, characterized in that the source The firmware is the manufacturer of a reliable device. 128. Способ по п. 127, отличающийся тем, что источником микропрограммного обеспечения является изготовитель достоверного устройства.
- 129Update method reliable device firmware, characterized in that they accept transmission a reliable device and confirm the source of the specified transfer using a key embedded in the specified authentic the device, and the specified key is the key associated with the authorized subject, with the specified confirmation operation includes the verification operations that the transfer includes the certificate of renewal registered by the private key of the signature of the authorized subject, and the certificate of renewal includes the public key of the signature of this source firmware and check using public key verification of the signature of this source of firmware that the transfer was registered using the secret key of the signature given source of firmware, include this firmware providing a reliable device after confirming the source firmware. 129. Способ обновления микропрограммного обеспечения достоверного устройства, отличающийся тем, что принимают передачу микропрограммного обеспечения на достоверное устройство и подтверждают источник указанной передачи с помощью ключа, внедренного в указанное достоверное устройство, причем указанный ключ является ключом, связанным с уполномоченным субъектом, при этом указанная операция подтверждения включает операции проверки того, что передача включает сертификат обновления, зарегистрированный с помощью секретного ключа подписи уполномоченного субъекта, причем сертификат обновления включает открытый ключ подписи данного источника микропрограммного обеспечения, и проверяют с использованием открытого ключа проверки подписи данного источника микропрограммного обеспечения того факта, что передача была зарегистрирована с помощью секретного ключа подписи данного источника микропрограммного обеспечения, включают данное микропрограммное обеспечение в состав достоверного устройства после подтверждения источника микропрограммного обеспечения.
- 130The method according to p. 129, characterized in that the transfer of firmware security software includes a public key verification signature for authorization the subject. 130. Способ по п. 129, отличающийся тем, что передача микропрограммного обеспечения включает открытый ключ проверки подписи для уполномочивания субъекта.
- 131The method according to p. 130, characterized in that the authorized the subject is the manufacturer of this authentic device. 131. Способ по п. 130, отличающийся тем, что уполномоченным субъектом является изготовитель данного достоверного устройства.
Independent claims130
807 paragraphs in 46 sections, as filed
UKRAINA
(19) andA (11) 41387 (13) C2
(51) 7L04 / 08, 9/32
MINISTRY OSVІTI
І SCIENCES OF UKRAIN
OPIS
TO PATENT ON VINACHE
POWER DEPARTMENT OF THE UNTLEKTUALNOЇVLASNOSTI
(54) installed SPOSІB VІROGІDNOGO PEREVІRYUVANOGO ZV'YAZKU, SPOSІB ZAHISCHENOGOZV'YAZKU, SPOSІB do updates MІKROPROGRAMNOGO ZABEZPECHENNYA, SPOSІB ZDІYSNENNYA Schiff-tion ZV'YAZKU TA SPOSІB NADANNYA PEREVІRENOMU ON SPRAVZHNІST Pristrom PRAVANA holding ELEKTRONNOЇ TRANZAKTSІЇ
(21) 96072822
(22) 01/13/1995
(24) September 17, 2001
(31) 08/181859, 08/272203
(32) 01/13/1994, 07/08/1994
(33) from, from
(86) PCT / i395 / 00531,13.01.1995
(46) 09/17/2001, Byul. № 8, 2001 p.
(72) Sudya Frank V., from
(73) sertko, інк, from
(56) 1. out of, 5136643, NC04 / 00, 08/04/1992.
2. out of, 5150411, Н04І_9 / 30, 09.22.1992.
3. out of, 5214698, Н04І_9 / 08, 25.05.1993
(57) 1. A method of establishing reliable verified communication among a multitude of users, containing a escrow operation, characterized in that they deposit in a trusted storage center a plurality of secret asymmetric cryptographic keys used by a plurality of users, check each of the plurality of keys in the center storage, certify each of the plurality of keys after verification and initiate communication with each of the user sets using the corresponding one of the multiple keys depending on the result Certification comrade.
2. A method of establishing reliable verifiable communication between users, containing a deposit operation, characterized in that a secret asymmetric cryptographic key associated with each of a number of users is deposited in a trusted storage center, each of these keys is checked in the storage center, each of these keys is certified after verification and initiate a secure communication by the initiating user with the receiving user, depending on the results of the certification of the keys as initiating, and accept users.
3. The method according to p. 2, characterized in that the authenticated device of the initiating user performs the operation of confirming the certification of the keys of both the initiating and receiving users before initiating the secure communication.
4. The method according to p. 2, characterized in that the certification operation includes issuing by the center
storing the deposited certificate, which verifies the key of the receiving user, and the connection initiation operation includes the verifying user of the authenticity of the deposited certificate of the receiving user.
5. The method according to p. 2, characterized in that it additionally includes the operation of issuing certificates to the first and second storage centers by the sanctioning authority, and the specified receiving user depletes its key in the second storage center, issuing the first and second centers for storing user certificates for the issuing and receiving users and verifying the initiating user of the authenticity of the certificate of the second storage center and the certificate of the receiving user prior to the initiation of the protected link and.
6. The method according to p. 2, characterized in that the device checked for authenticity performs a verification operation with confirmation of the key of the receiving user with the help of embedded logic protected from unauthorized actions.
7. The method according to p. 2, characterized in that the deposited key is an intermediate Diffie-Hellman protocol number.
8. The way to establish reliable verifiable communication between multiple users with external access to the sampling access, containing a deposit operation, characterized in that secret asymmetric cryptographic keys associated with the multiple users are deposited in the trusted storage center, each user at least one key is associated with and at least the first selectable external side obtains access to the connection with this user, checks these keys in the storage center, certifies each of these their keys, after checking, initiate a reliable communication by the sending user with the recipient in such a way that access to the communication of the first outsider is provided.
9. The method according to p. 8, characterized in that the operation of initiation of communication includes the sending of information
IA (11) 41387 (13) C2
σ>
41387
Access mappings encrypted by the first-party key.
10. The method according to p. 8, characterized in that the deposit operation includes the registration operation in the storage center of a verified device validity associated with the user and with the first external side.
11. A method according to claim 10, wherein the depositing includes the operation of issuing the initiating device a certificate of the original owner identifying the device tested for validity and the first external party, and transmitting the certificate of the owner of the agent deduction to identify the first external party having access to the communication with the user.
12. The method according to p. 8, characterized in that the operation of initiating communication includes sending information available to the second external side associated with the recipient to receive access communication.
13. The method according to claim 8, wherein it additionally includes the transfer by the receiver of the designation of the second external side of the storage center together with the key of the recipient and the inclusion of the second external side in the certificate by the key of the recipient.
14. The method according to p. 13, characterized in that it additionally includes the operation of transmitting the certificate of the receiving user to the sending user, and this certificate indicates the second external side having access to the communication.
15. A method of secure communication in a system that has at least one transmitting side and a message key that can be restored by a party not participating in the communication, differing in that they provide each user with a computer device, register devices in the center according to the super-management information set by the device owner, other than the device user, certify the devices, and a certificate common to the center, the user and the device is generated by the certification communication between the initiating user and the recipient using the message key in such a way that it permits the given owner to access the communication.
16. The method according to p. 15, characterized in that the registration operation includes the operation of registering the device only in the center selected from the set of centers in accordance with the information specified by the owner.
17. The method according to claim 15, wherein the registration operation includes the operations of registering a device in a center selected from a set of centers in accordance with the information entered into this device by a non-user.
18. The method according to claim 15, wherein the registration operation includes registering the device in the first device registration center in the second center selected from the set of centers in accordance with the information set by the owner.
19. The method according to p. 15, characterized in that the registration operation includes the operation of certifying the device with a limited number of attempts in accordance with the information specified by the owner.
20. The method according to p. 15, characterized in that the registration operation includes the operation of registering the device in the center in accordance with the control information specified by the owner of the second device, different from the owner of the first device.
21. The method according to p. 20, characterized in that the owner of the second device is the user.
22. The method according to p. 15, characterized in that the operation of registration includes the operation of identifying the owner of the center.
23. The method according to p. 15, characterized in that the receiver is a storage device.
24. The method according to p. 15, characterized in that at least one of the operations of this method requires the use of authenticity verified device and this device is involved in the required operation only after entering the owner’s information into this checked device.
25. The method according to p. 15, characterized in that the device performs the operation of this method to answer the command, confirmed by the key from the person who is personal to the user, entered into this device.
26. A method for establishing a reliable verifiable connection between a plurality of users with a third party access containing an operation of depositing, characterized in that at least one of the plurality of storage centers deposits a secret asymmetric cryptographic key associated with each user set, check these keys In the storage center, certify each of these keys after verification and initiate reliable communication by the transferring user to the receiving user using a verified key. cha, including the transfer of informatsiidlya recovery initiating user key and the receiving user's public key.
27. The method according to p. 26, characterized in that the specified communication includes the transfer of information indicating to the storage centers the keys of the sending and receiving users.
28. The method according to p. 26, characterized in that said communication includes information encrypted with a key associated with the storage center.
29. The method according to p. 26, characterized in that it additionally includes the operation of restoring the deposited key, storing the restored key in the authenticated device in a safe way, preventing the key from being read by external devices and entering into the connection with the use of the key contained in authenticated device.
30. The method according to p. 29, characterized in that the operation of entering into a connection includes the operation of entering into a protected communication only for a limited period of time, and this is limited to
2
41387
A time setting sets the specified authenticated device.
31. The method according to p. 26, characterized in that it additionally includes the operations of searching for parts of the deposited key and restoring the full key for these parts.
32. The method according to p. 26, characterized in that it additionally includes the operation of maintaining a secure log of con fi gured communication sessions.
33. A method of establishing reliable verifiable communication between a multitude of users, containing operations for manufacturing electronic devices, each of which operates under the control of logic protected from unauthorized actions, characterized in that they initiate a secure communication between the initiating device and the recipient, including -chu information, given by the initiating device, to allow access to the communication of the outsider.
34. The method according to p. 33, characterized in that it additionally includes the operation of manufacturing devices intended for reliable communication and protected from unauthorized user actions.
35. A method of establishing reliable verifiable communication between users, containing a deposit operation, characterized in that a secret asymmetric cryptographic key associated with each of a number of users is deposited in a storage center, these keys are checked in this storage center, each certificate is verified after verification initiating communication by the initiating user with the receiving user depending on the confirmation by the authenticated device of the initiating user of the certification key th transmitting and prinimayuschegopolzovateley.
36. The method according to p. 35, characterized in that the authenticated device performs memory storing the key of the storage center in memory and using this key to confirm the storage center certificate certifying that the key of the receiving user has been verified.
37. The method according to p. 35, characterized in that at least one of the operations of deposit, verification and certification is performed in response to a request from the authenticated device.
38. The method according to p. 35, characterized in that the authenticated device specifies the structure of the data using the key associated with the handed over device.
39. The method according to p. 35, characterized in that it additionally includes the operation of generating a device checked for authenticity by a key to be deposited.
40. The method of clause 39, wherein the key is a communication encryption key.
41. The method of clause 39, wherein the key is a signature key.
42. The method according to p. 39, characterized in that at least one of the operations requires the use of authenticated devices,
and this device performs the required operation only after obtaining authorization information from a third party other than the user associated with it.
43. A method of establishing reliable verifiable communication between users, containing a deposit operation, characterized in that a secret asymmetric cryptographic key associated with each of a number of users is deposited in a trusted storage center, these keys are checked in this storage center, each key is certified afterwards verification and initiation of a communication session by the initiating user with the receiving user, depending on the certification of the key used in the communication, with the transmission of information, allowing her access to this session to the outside.
44. The method according to p. 43, characterized in that the access information includes an indication of the storage center key of the receiving user.
45. The method according to claim 43, wherein the access information comprises an indication of the key store of the sending user.
46. The method of claim 43, wherein the access information includes information for recovering a key deposited in the storage center, said recovery information being encrypted with the key of the storage center.
47. The method of claim 43, wherein the communication context includes a message key encrypted with the key of the sending user.
48. The method of claim 43, wherein the communication session includes a message key encrypted with the key of the receiving user.
49. The method of claim 43, wherein the communication session includes a message key encrypted with a key of a party not participating in this communication session.
50. The method according to claim 43, wherein the access information includes information indicating the time of communication.
51. The method of claim 43, wherein the access information includes an indication of the geographic area associated with the storage center of the receiving user.
52. The method of claim 43, wherein the access information includes an indication of a geographical area associated with the storage center of the transmitting user.
53. The method of clause 43, wherein the device of the transmitting user, verified for authenticity, sets the access information using the key associated with this authenticity checked device.
54. A method of establishing reliable, verifiable communication between multiple users, containing a deposit operation, characterized in that they deposit in a trusted storage center a secret asymmetric cryptographic key associated with each of multiple users, check the keys in the center of storage , certify each of the keys of the verification and authenticity of the device associated with each user, initiate communication by the initiating user with the recipient after the certification of the key used
3
41387
used when communicating, and after confirming the attributes of the authenticated device associated with the originating user.
55. The method of claim 54, wherein it additionally includes the operation of issuing a certificate to the user by the storage center, further including a user key and a key associated with the authenticated device.
56. The method of claim 54, wherein it additionally includes the operation of issuing a certificate to the user by the storage center containing information indicating the selected external side other than the user to access the communication session by participating in this user
57. The method according to p. 54, characterized in that it additionally includes the operation of issuing a certificate to the user by the storage center, additionally including a key of a selectable external side different from the user.
58. The method of claim 54, wherein it additionally includes the operation of issuing a certificate by the storage center, further including information indicative of a geographic area associated with the storage center.
59. The method according to p. 54, characterized in that the recipient is a storage device.
60. A method of establishing reliable verifiable communication between users, which includes a deposit operation, characterized in that they deposit asymmetric cryptographic keys associated with users in trusted storage centers, some of these storage centers belong to the first group and others to the second group, verify the keys in the storage centers, certify each of these keys after verification, and communicate between the first and second users depending on the groups to which the centers belong storing transmitting and receiving users.
61. The method according to claim 60, wherein the storage center indicates its group in the certificate containing the user's key.
62. The method according to claim 60, wherein the first user initiates communication with the second user depending on the indication of the group of the storage center in the certificate of the second user.
63. The method according to p. 60, characterized in that the second user communicates with the first user, depending on the instructions of the storage center group in the certificate of the first user.
64. A method of establishing a reliable, verifiable flow-oriented communication between users, containing a deposit operation, characterized in that they deposit in the trusted storage center an asymmetric cryptographic key associated with each of the users, check each of the keys in the storage center, certify each of the keys after verification and perform an encrypted, thread-oriented connection initiated by the user with the receiving user using a cryptographic
the key of the initiating user and the transmission of the initial packet containing the access information allowing the outside to decrypt the stream and stream of subsequent packets, each of which contains information identifying this subsequent packet as being associated with the stream, and at least one of the indicated subsequent packets does not contain access information.
65. The method of clause 64, wherein the communication session further comprises a transmission of the final packet having information indicating the end of the communication session.
66. The method of clause 64, wherein each subsequent packet also includes unique information indicating the position of this packet in the sequence.
67. The method of clause 64, wherein each subsequent packet also includes information with a time stamp.
68. The method of clause 64, wherein the access information comprises a hashed initial packet.
69. The method of clause 68, wherein the specified hash initial packet is entered with the cryptographic key of the initiating user.
70. The method of clause 69, wherein the access information also includes information identifying the message.
71. The method according to p. 70, characterized in that at least one of the subsequent packets contains information identifying the message.
72. The method according to claim 71, characterized in that said information identifying this subsequent packet as associated with a stream is the sequence number of the packet.
73. The method of claim 64, wherein it additionally contains operations for the initiating user receiving information relating to the quality of the channel through which the in-line communication is performed and selectively including the message-identifying information in subsequent packets with a frequency determined by the quality of the channel.
74. The method of clause 64, wherein the packages include information linking them with a initiating user.
75. A method for updating the firmware of a device checked for authenticity, characterized in that a key is inserted into a device checked for authenticity connected with a source of firmware, and the firmware of this device checked for authenticity is modified by the source of this firmware in a certain way, which can be confirmed by the built-in key, and the inclusion of micro-software in this process. verennoena authenticity device according to the evidence supporting the sub-transmission via vstroennogoklyucha.
76. The method according to p. 75, characterized in that the source of the firmware initiates communication, and this authenticated
four
41387
the device confirms the connection by checking the signature using the embedded key.
77. The method according to p. 75, characterized in that the firmware includes executable program code.
78. The method of clause 75, wherein the firmware includes a cryptographic key.
79. The method according to p. 75, characterized in that it additionally contains the operation of embedding the keys used to confirm the micro-software.
80. A method for performing encrypted communication in a system containing communicating parties and using a message key, reconstructed by a party not participating in the communication, which is different in that they provide each user with a computer device that has at least one device-related switch; the lesser of one of the centers, certify the devices by forming a certificate for the device, initiate a secure communication session by the initiating user with the recipient using the key with Messages, moreover, the specified communication session contains an access fragment encrypted with a center key, which serves to restore the message key.
81. The method of clause 80, wherein the access fragment encrypted with the center key contains information identifying the key deposited in this center.
82. The method of clause 80, wherein the certificate includes the public key of the open / secret key pair.
83. The method of clause 80, wherein the access information contains information for the centers necessary to restore the key message.
84. The method of clause 80, wherein the operation of the communication includes the operation of the inclusion of an authenticated information access device by the device protected by unauthorized actions of the user.
85. The method according to claim 80, wherein the operation of communication includes the operation of encrypting access information using the key of the first center and encrypting the access information using the key of the second center.
86. A method for providing a device tested for authenticity to the right to conduct an electronic transaction between the first user and the second party and to ensure that the authenticated device will carry out an electronic transaction in accordance with pre-established rules that cannot be changed by the specified user, characterized in that they carry out an electronic transfer to the specified device checked for authenticity by a third party of the request for the granting of the right to exercise an electronic transaction, where the request includes device authentication, is established by the specified third party to the fact that the authenticated
The device should be given the right to carry out the specified transaction at least partially in accordance with the confirmation that the device tested for authenticity will only work in accordance with the specified rules, the electronic transmission of the device to the authenticity verified by the specified third party to the device e-trans-action, and the provision of the right provides for certifying that the said third party has provided the said right in, the electronic transmission of an authenticated device to the said second party of the said authentication as confirmation that this device has the right to carry out the said electronic transaction and will carry it out only in accordance with the said rules,
87. The method of clause 86, wherein the transfer of the right includes the operation of transferring said rules to said third party specified authenticated device.
88. The method according to p. 86, characterized in that said authenticity checked device contains the specified rules prior to the specified operation of the transfer of the right.
89. The method of clause 86, wherein the said operation of the transfer of the right provides for the digital signature of said third party to be attached to the specified certificate.
90. The method of claim 86, wherein the operation for transmitting the request includes the operation of transmitting the authentication of the specified authenticity of the indicated device having a digital signature of the manufacturer of the authentic device.
91. The method of claim 86, wherein the specified establishment operation includes the operation of determining whether the specified device checked for authenticity is protected from unauthorized actions, based on the specified authenticity of the device tested for authenticity.
92. The method of claim 86, wherein the specified authenticated device has an associated public key and a secret key of the asymmetric cryptosystem, and the specified request transfer operation includes the operation of transmitting this public key device to third parties.
93. The method of claim 86, wherein said reliable device has an associated first key and a second key of the asymmetric cryptosystem, and said operation of transferring data from the specified second party includes adding a digital signature of this authentic device created using the specified the first key.
94. The method of claim 90, wherein the specified authentication contains a public key of a public / secret key pair for the authenticated authenticated device, and the specified transfer operation is for
five
41387
The millet includes a digital signature of the authenticated device authenticated by using the specified device secret key to this request so that the specified third party could confirm that the given request came from this authenticity checked device.
95. The method of claim 93, wherein said transaction data transfer operation to said second party includes an operation of transmitting said second key to the second side.
96. The method according to p. 93, characterized in that said first and second keys of the device are respectively secret and open keys.
97. The method according to p. 91, characterized in that the specified first and second device keys are respectively secret and public keys.
98. A method of establishing reliable verifiable communication between multiple users, including the formation of a secure connection inside an electronic hardware device, differing in that they form a secure connection inside the electronic hardware device of the first user, and the specified secure communication includes access information providing access the external side to this secure connection, the entrance to the secure connection with a private signature key, depending on the registration microchip on the electronic hardware ve first user, wherein nny Decree-dependent chip secret klyuchpodpisi was introduced into a protected Cams-vanija memory associated with the register chip-tion of the first user before the elec-tron hardware device was Lend-Leno first user,
99. The method of claim 98, wherein it additionally comprises the operations of receiving a secure communication on the electronic hardware device of the second user and verifying the open key of the signature of the primary user's registration chip using the public key of the signature of the trusted party.
100. The method of claim 99, wherein the certificate is embedded in the unauthorized access-protected memory of the registration chip of the first user before the electronic hardware device has been provided to the first user.
101. The method of claim 100, wherein the open key of the signature of the trusted party is out-of-hand in the unreadable, protected from unauthorized access memory of the registration chip on the electronic hardware device of the second user.
102. The method of claim 101, wherein the trusted party is the manufacturer of the first user's registration chip.
103. The method according to p. 101, wherein the open signature keys of several trusted parties are inserted into the unreadable, protected, separately authorized access memory of the microcircuit registration of the second user.
104. The method of claim 98, wherein it additionally contains the operations of creating a user-dependent pair of the public / secret encryption / decryption keys of the primary user’s intra-electronic hardware device and encryption of the secure communication using the secret encryption key of the intra-user hardware of the first user.
105. The method according to p. 104, characterized in that a pair of public / secret encryption / decryption keys are created using the algorithm P3A
106. The method according to p. 105, characterized in that the secret signature key of the registration chip of the first user is generated using the algorithm "3"
107. The method according to p. 106, characterized in that the secret key signature trusted party generate using the algorithm "3"
108. A method of establishing a reliable verifiable stream-oriented connection between a set of users, containing a deposit operation, characterized in that they deposit in the center of the trusted storage an asymmetric cryptographic key associated with a plurality of users, check each of the keys in the center storage, certify each of these post-verification keys and receive the first encrypted stream-oriented transmission from the initiating user from the receiving user, and the decree with help transfer constant prices encrypted cryptographic key ukazannogoinitsiiruyuschego user and said pervayaperedacha includes the initial packet, the access soderzhaschiyinformatsiyu allowing external hundred decrypt Rhone-stream and stream posleduyuschihpaketov, each subsequent paketovsoderzhit information,
109. The method of clause 108, wherein it additionally contains the operations of forming a second encrypted stream-oriented transmission from the receiving user to the initiating user using the receiving user's cryptographic key, the second transmission including the initial packet containing information stupid, allowing the outside to decrypt the second encrypted stream, and a stream of subsequent packets, with each subsequent packet containing information identified by this subsequent packet as associated with the second encrypted stream.
110. The method of claim 108, wherein the access information of the second encrypted stream includes the checksum of the initial packet of the second encrypted stream registered
6
41387
bath with a cryptographic key of the receiving user.
111. The method of clause 110, wherein the access information of the second encrypted stream includes an identifying message information received from the original user.
112. The method of clause 109, wherein at least one of the subsequent packets of the second encrypted stream includes information identifying the message.
113. The method of claim 112, wherein the information identifying the subsequent packet of the second encrypted stream as associated with this second encrypted stream is the sequence number of the packet.
114. The method of claim 113, wherein the packets of the second encrypted stream include information relating to the initiating user.
115. The method according to p. 109, characterized in that it additionally contains operations for receiving from the receiving user information relating to the quality of the channel through which the stream-oriented transmission is carried out, and the incorporation of identifying information into the subsequent packets with the rate determined by the quality of the channel.
116. The method of claim 115, wherein the information regarding the quality of the channel is continuously received, and the rate at which the identifying information is selectively included in subsequent packets is dynamically adjusted depending on the information received.
117. The method of updating the firmware of a reliable device, characterized in that it receives a microprogram-a lot of software transmission by a reliable device, confirms the source of the specified transmission using a key embedded in the specified reliable device, and the specified key is key, associated with the source of microprogram software, and include this microprogram software in a reliable device after confirmation of the sources of the firmware.
118. The method of clause 117, wherein the key embedded in the trusted device is the public key for verifying the signature of the given source of the firmware, and the indicated confirmation operation includes the operation of checking that the transfer was it is registered with the help of the secret key of the signature of the firmware sources.
119. The method according to p. 118, characterized in that the specified source of microprogram software is a manufacturer of reliable device.
120. The method of claim 119, wherein the firmware transfer includes a public signature key, which must be embedded in the firmware of the trusted device.
121. The method of clause 117, wherein the key embedded in the trusted device is the public key for verifying the signature of the authorized entity, and the indicated confirmation operation includes a verification operation using the public key verification of the signature of the authorized subject of the fact, that the transfer includes the certificate of renewal registered with the secret key of the signature of the authorized subject, and the update certificate includes the public key of the signature of this source of firmware of sin
122. The method of claim 121, wherein said confirmation operation additionally includes a verification operation using the public key verifying the signature of this source of firmware for the fact that the transfer was registered using the secret signature key of this source of firmware.
123. The method of claim 122, wherein the authorized entity is a manufacturer of a reliable device, the source of the firmware being a trusted third party.
124. The method of claim 123, wherein the firmware transfer includes the public key of the signature verification that must be embedded in the firmware of the trusted device.
125. The method of clause 124, wherein the firmware transfer includes the signature verification public key for a trusted third party.
126. The method of clause 125, wherein the firmware transfer includes further information identifying transactions that can be performed by a trusted third party.
127. The method of clause 126, wherein the trusted third party is authorized to replace the signature verification public key of this source of the firmware.
128. The method according to p. 127, characterized in that the source of the firmware is the manufacturer of a reliable device.
129. A method for updating a firmware of a reliable device, characterized in that it receives a microprogram — a lot of software transmission to a reliable device, and confirms the source of the specified transfer by means of a key embedded in the specified reliable device, and the specified key is a key associated with an authorized entity, whereby the indicated confirmation operation includes the operations of checking that the transfer includes the certificate of renewal registered with the secret key of the sub-pi si of the authorized entity, whereby the certificate of renewal includes the public key of the subscribed source of firmware, and it is checked with the use of the public key of the signature verification of this source of microprogram software that
7
41387
software, include this firmware in a trusted device after confirmation of the firmware sources.
130. The method according to p. 129, characterized in that the transfer of firmware is included
reads the public key of the signature verification to authorize the subject.
131. The method according to p. 130, wherein the authorized entity is the manufacturer of this reliable device.
The present invention relates to crypto-graphic communication systems. More specifically, the present invention relates to the secure creation, certification, storage and distribution of cryptographic keys used in cryptographic communication systems. More specifically, the present invention relates to a cryptographic key deposit system and management of a public key certification provided by a self-certifying device with a chip.
The improvement and dissemination of practical computer equipment and systems for distributed data processing led to a rapid increase in the amount of information transmitted in a digital form. This information is used in the financial and banking sectors, e-mail, electronic data interchange and other data processing systems. Transmission of this information over unequipped or unprotected communication channels is associated with the probability of exposing the transmitted information to the risk of electronic interception or distortion. Cryptographic communication systems ensure the secrecy of such transmissions of signals, preventing them from being listened to by non-authorized parties of messages transmitted over an unprotected channel. Cryptographic communication systems also ensure the integrity of such transmissions of signals, preventing changes by the parties not authorized to do so. which is contained in messages sent to the non-secure channel. Cryptographic communication systems can also ensure the integrity and authenticity of signal transmission, providing for recognizable, non-counterfeit and digital signatures associated with a document that prevent the sender from refusing its own message.
Cryptographic systems include encoding or encrypting digital data transmissions, including the transmission of audio or video messages presented in a digital form to make them incomprehensible to all the recipients to whom they are intended. A non-encrypted message consisting of digitally represented sounds, letters and / or numbers is subjected to numerical encoding and then encrypted using a complex mathematical algorithm that converts a coded message based on a given group of numbers or digits, also known as a key to a cipher. The key to the cipher is a sequence of information bits, which can either be chosen arbitrarily or have special mathematical characteristics, depending on the algorithm used or a cryptographic system. Applied
on computers, complex cryptographic algorithms can convert and process numbers that involve hundreds or thousands of bits in length and can resist any known unauthorized decryption method. There are two basic types of cryptographic algorithms: symmetric key algorithms and asymmetric key algorithms.
In symmetric key algorithms, an identical key to a cipher is used both for encrypting a message by the sender and for decrypting the message by the recipient. Cryptographic systems with a symmetric key are based on the mutual trust of the two parties who share the key to the cipher in order to use the cryptographic system to protect third parties to whom there is a lack of trust. The most well-known symmetric algorithm of the key is the National Standard algorithm for data encryption (UEZ), first published by the National Institute of Standards and Technology (see: Vebega and Red, dated March 17, 1975, vol. 40, No. 52 and August 1, 1975 , t. 40, No. 149). The encryption device manager uses the UEZ algorithm to encrypt the message after loading the cipher key into the non-key (the UEZ cipher key has a length of 56 bits) for a given communication session (key session). The recipient's encryption device uses the reverse form of the UEZ algorithm to decrypt the encrypted message after loading the same cipher key into it that was used for encryption. However, the suitability of cryptographic systems with a symmetric key, in general, was questionable because of the need for the sender and recipient to establish the necessary connection between them to exchange the cipher key via a secure channel to which the third party does not have access. This process of preliminary secure key exchange of a key and implementation only after the encryption of the message is often slow and cumbersome. and it turns out, therefore, to be unacceptable in situations that require the transfer of messages directly or without the request, or in situations that require establishing a connection between the parties that are not familiar with each other. In addition, intercepting a cipher key by an unauthorized third party will allow this party to overhear both participants in an encrypted conversation.
The second type of cryptographic algorithms, asymmetric key algorithms, provides for the use of various cipher keys for encryption and decryption. In a cryptographic system using asymmetric
eight
41387
In this case, the user makes the key encryption open and keeps the decryption key private, and it becomes impossible to determine the private decryption key using the public encryption key. Thus, anyone who knows the public key of a certain user can encrypt a message to this user, while only the user who owns the private key corresponding to that public key can decrypt the message. Such an open / private key system was first proposed by wife Diffie and Helman in the work "New Developments in Cryptography", ІЕЕЕ Тгпзасііопз опіпіогтаіііпоегу, November 1976, and in US Patent No. 4200770 (Helmen and others), which are included in the question as reference.
The initial type of asymmetric key algorithm allows the creation of a secure connection over an unprotected channel by coordinating the creation of a key for the session by the contacting parties. Using the asymmetric key algorithm, the two interacting users, simultaneously and independently, create a robust cipher that cannot compute the eavesdropper and which can be used asymmetrically during this session to encode the communication between users. This interactive way of creating a secure cipher key was described by Diffie and Helman in their publication. 1976 According to this, the previously applied method, known as the Diffie-Helman Dialogue, is shown in fig. 2, each of the two users A, B randomly selects the secret number 21, 22 and then calculates the intermediate number 23, 24, using for this purpose two known open numbers and a secret number 21, 22 selected by this user. After that, each user transfers an intermediate number 23, 24 to another user and then calculates a secret (symmetric) key 25, using his own secret number 21,22 and intermediate the number 24.23, just received from another user. The cipher key obtained jointly is then used symmetrically by both users as UEZ or any other symmetric cipher key to encrypt and decrypt this communication session via an unprotected channel in another relationship, typical of communication using a symmetric key algorithm. This dialogue process requires only a few seconds of real time, and all messages in digital form, including audio and video data converted into digital form, during a specific session, communication can be encrypted by simply pressing a button in the beginning of a session in order to initiate the process of reciprocal key exchange. Since all the numbers selected in the Diffie-Helman Key Dialogue Scheme are very large, calculations cannot be inverted, and the eavesdropper cannot compute the secret key of the cipher, thus ensuring the secrecy of the connection. Since the calculations cannot be inverted, every user knows that any message received using this algorithm was not measured. and the eavesdropper cannot compute the secret key of the cipher, thus ensuring the secrecy of the connection. Since the calculations cannot be inverted, every user knows that any message received using this algorithm was not measured. and the eavesdropper cannot compute the secret key of the cipher, thus ensuring the secrecy of the connection. Since the calculations cannot be inverted, every user knows that any message received using this algorithm was not measured.
It can only be sent by another user, which ensures the integrity and authenticity of communication. This method of interactive key exchange requires the parties to interact in real time in order to create a cipher key and cannot be used for communication without prior request or between parties that are not known to each other. In particular, the dialogue scheme for obtaining the Diffie-Helman key does not work in the case of transferring messages by email with intermediate storage or for long-term storage of documents in the electronic data storage system, since the recipient in this case does not work in the dialogue mode to discuss the session key.
A modified Diffie-Helman non-dialog form, known as Diffi-Helman Certified, can be used when contacting parties are in non-dialog mode. The initial operation of the certification of the Certified Diffie-Helman session key acquisition scheme is shown in fig. 3. One user who is the intended recipient, arbitrarily chooses the secret number 31 (his own key) and then calculates the intermediate number 33 using two open numbers 32 and the secret number 31 chosen by this user. This user then sends an identification confirmation, along with an intermediate number and two public numbers, which together form his public key 34, to the certifying organization, which issues the public key certificate 35, signed in digital form 36 by the certificate issuing organization, thus associating the user's identity with the information regarding the public key 34 of the Diffie-Helman user. The public key 34 published by this user remains the same until the user decides to change the key and select another private key 31. The transfer of messages using the Certified Diffie-Helman method is shown in fig. 4. In order to transmit a message to this user, the sending user first receives the certificate 35 of the recipient user and checks the signature 36 of the issuer of the certificate. The sender then calculates the key of session 42 for this communication session using the intermediate number 33 of the recipient (from the certificate of the recipient) and the sender's own secret number 41 (Personal key), which he chooses arbitrarily. The sender then encrypts message 43 using session key 42 and placing his own intermediate number 40 in an unencrypted form at the beginning of the message. After receiving the message, the recipient calculates key 42 using the unencrypted intermediate number 40 of the sender and its own secret number 31 (or private key) and then uses session key 42 to decrypt the message 43. As in the case of the Diffie-Helman Dialogue, the key the session received by the Diffie-Helman Certified Scheme is then used by both parties for
9
41387
Formation and decryption of messages during this communication session over an unprotected channel in other relationships using a conventional symmetric algorithm, such as ϋΕ3. The certified Diffie-Helman scheme, however, requires that a trustworthy subject of the certification authority sign the certificate of the recipient’s public key so that the sending user can be sure of the truth of the information contained therein. In addition, the private key, arbitrarily chosen by the sender, with which it calculates both the session key and the intermediate number for this message, must not coincide with the private key contained in the public key certificate belonging to the sender; so that others do not recognize the fixed values of the private key (corresponding to the values of the public key that have passed certification),
Another asymmetric key algorithm, named by the SESL algorithm by the names of the authors of the invention Rivest, Shamir and Adman, is described in US patent No. 4405829 (Rivest, etc.), included here as a reference, and takes into account the difficulty of factoring a number that is a product of two large prime numbers. Like the Diffie-Helman Dialogue Scheme, the RZA algorithm is quite easy to compute, but almost impossible to be inverted. Therefore, it is impossible to derive the private key from the value of the public key, and thus the communication secrecy is preserved. If a message is encrypted with a public key using the relay protection algorithm, it can be expanded only with a private key and vice versa. As in the case of the Certified Diffie-Helman scheme, the relay protection algorithm requires so that a trusted subject has certified the user's public keys has been published. However, unlike both Diffie-Helman schemes, the RZA algorithm does not independently issue a "key", which should be applied symmetrically by both parties. Instead, a specific user’s public encryption key indirectly encrypts messages for this user, and the user's private decryption key decrypts these messages encrypted with the user's public key. Thus, the RZA algorithm is a pure-asymmetric key algorithm.
However, due to the complexity of the RZA algorithm and the fact that it provides for the potentiation of messages with very large numbers, encryption and decryption of a message even of moderate length using the RZA algorithm requires a lot of time. Thus, the use of the asymmetric relay protection algorithm for transmitting the UEZ cipher key with the purpose of using it in a symmetric algorithm is much simpler, faster and more efficient. This, previously used, mode of operation is known as the transfer of key RZa and is shown in Fig. 5 and 6. For example, as shown in fig. 5, user
can make an arbitrary UEZ key 51 encrypt the message 52 with this UEZ key. Then the user must encrypt the key51 with the public encryption key 53 of the intended recipient, and send the encrypted UES message 54, along with the encrypted RZA key 55 to the recipient user. After receiving and transmitting, as shown in Fig. 6, the recipient decrypts the UEZ 51 key, using the UEZ 56 encryption key to do this, and uses the 510EZ key to decrypt the message 52. Since the UEZ algorithm requires much less time and computational costs, In comparison with the E_ZA salgoritm, the UEZ symmetric key is used to encrypt and decrypt self-messages, while the asymmetric RLP keys are used to encrypt and decrypt the UEZ symmetric key.
A cryptographic system of an RPA with an open private key also offers a digital “signature” associated with both the message and the person who signed it, and can be used to confirm that the received message was actually sent by the sender and received in an unchanged the form. The digital signature of the RPA is based on the additional characteristics of the RPA, which, in addition to allowing the personal user key to decrypt only those messages that are encrypted using the public key of the user, allows the user to encrypt messages that can only be decrypted by the public key of the user . Since only the user owns the private key, the use of the private key serves as confirmation of the origin of the document, which can be verified by anyone having access to the user's public key. In practice, the sender first uses its own key to encode the message text in the form of a signed message, which can be decrypted by anyone, but can only come from the sender. If desired, the sender can then optionally use the recipient's public encryption key in order to encrypt the signed message intended for transmission. After receiving the cipher text, the recipient, if necessary, decrypts the cipher text with his own decryption key and decodes the signed message with the public key of the sender. Since only the sender knows his only private key, only the sender can send a specific "signed" message; the signature confirms the identity of the sender. Besides, since only the public key of the sender is at the disposal of the recipient, the sender cannot claim that the recipient or the non-authorized third party changed or supported his message; the signature thus excludes the possibility of the sender’s refusal from the author of the message. In addition, since only the sender's private key converts the initial message and only the sender knows the only private key
ten
41387
neither the unauthorized third party can change the message; the signature thus confirms the integrity of the message.
The RZA algorithm also provides for a different type of digital signature, which uses the hashing function to create a brief summary of the message, which is unique to each document. In fig. 7 and 8 show, respectively, the creation of the RZA signature and the verification of the RZA signature using the hashing function. The hash function is another complex mathematical algorithm that is "unidirectional", i.e. there is no possibility to reconstruct the document based on the hash results, and does not allow for "misunderstandings", i.e. it is impossible to prepare another document that would be hashed with such a resume. As shown in fig. 7, the sender first passes the message 72 through the algorithm of the hashing 73 to receive the summary of the message 74, and then encrypts the summary with his private key 75 of the RZA, forming a compact digital signature 76 associated with the message 72. After receiving the message 72 and the summary of message 76, as shown in fig. 8, the recipient encrypts the message 76 encrypted with the sender in the RZ Summary of the message (digitally signed), using the sender's 77 RZA public key. The recipient also uses the same hash 73 algorithm to get a summary of the message74 from the received message. The two summaries of the message received as a result of the two transformations performed by the recipient must be identical, which confirms the fact that the sender signed the message. The recipient also uses the same heh-shuffling algorithm 73 to retrieve the summary of the message74 from the received message. The two summaries of the message received as a result of the two transformations performed by the recipient must be identical, which confirms the fact that the sender signed the message. The recipient also uses the same heh-shuffling algorithm 73 to retrieve the summary of the message74 from the received message. The two summaries of the message received as a result of the two transformations performed by the recipient must be identical, which confirms the fact that the sender signed the message.
To confirm the identity of the sender, you can also use another system of digital signatures called UzA, according to the first letters of the English equivalent of the term Digital Signature Algorithm. The YuzA algorithm is described in the US patent application serial No. 07/738431, which is fully included here as a reference. message summary using your private key; The recipient checks the encrypted resume using the public key of the sender. However, unlike the RZA signature algorithm, which returns the initial summary of the message after being decrypted by the signature block, Algorithm verification YuzAdaet only positive confirmation of the truth of the signature; Messages encrypted using the public key of the intended recipient cannot be later recovered by decrypting the recipient's corresponding personal key. For this reason, the YuzA algorithm is quite suitable for digital signatures, but not for transferring the key and not for directly encrypting the message.
To ensure the efficiency of the public and private key systems, users must trust the centralized organization.
certification key, responsible for the publication and updating of the directory of public encryption keys. The key certification authority must use the trust of all users, both senders and recipients, and distribute the corresponding public keys among all users in such a way that no messages are transmitted to those recipients for whom they are not intended. To this end, as shown above and described in detail below, the certifying organization should distribute information about the name of each user and the public encryption key, supplying the disseminated information with its own digital signature in order to confirm the truth of the information. However, when more than one subject is involved in the certification process, or a hierarchy of subjects There are several different techniques or “trust models” for determining how the user will process the certificates. The three main models are: (1) a purely hierarchical model, (2) a model for applying cross-certification between multiple hierarchical levels and (3) a model of “local trust”. These models are described in the documentation of the American National Standard X9.30, "Cryptography of an open key using irreversible algorithms for the needs of the financial services industry: Part 3: UzA Certification Management" (American Bank Association, Washington, DC Columbia, 1992), fully incorporated as reference . Although there is still no consensus on which of the models of trust mentioned above is the best, this description assumes
The open and private key system described above takes into account the interest in the confidentiality of users who want to send and receive messages privately. However, at the same time, there is also a need to take into account the requirements of the law and the interests of national security. It is necessary to provide an opportunity for public authorities to track or listen to private electronic transmissions in order to apply the law and ensure national security so that suspected criminals, terrorists and foreign spies would not be able to plot, being beyond the reach of the law. While telephone conversations can be tracked by interception, cryptographic algorithms make encrypted information unbreakable even if powerful decryption computers are used.
eleven
41387
widespread use of cryptographic devices in telephones, computers, fax machines and all other types of data processing equipment.
One way to provide government authorities or other authorized investigative bodies with the ability to track down the connection of suspected criminals is to send all users of cryptographic communication systems to put their confession on their private decryption keys in a private or public organization, i.e. allow either a private or state organization to become a trusted custodian of the private keys of users' decryption. In case of need for supervision, the government will have access to or access to the private key to listen to all encrypted messages. This method, however, is unacceptable because
Another way to deposit private keys for encryption in order to ensure both user interest in confidentiality and the interests of law and security is to use a system based on the method described in the “Honest” cryptographic public key system ”report presented by Silvio Micali -references "CRIPTO 92" in March 1993 and published by the Laboratory of Computer Science at the Massachusetts Institute of Technology on October 13, 1993 and in US Pat. No. 5,276,737, which are included here stve reference. Co-transparent manner this method shown in Fig. 9-11, a user wishing to certify svoyotkryty key for encryption purposes, dolzhendeponirovat its private key in the following on-time. As shown in Fig. 9, the user first divides his personal key 91 into several “details” 92, each of which can be individually certified 90 as the real part of the complete private key 91. The private key can be restored only by knowing everything or some specific number of them. -stvo. The user then directs 93 each item to various depositing agents or agents 94, which, as shown in Fig. 10, certify the 95 part as the true part of the private key 91, using a special algorithm and generalizing about this confirmation 96 to the main center of the deposit. As shown in fig. 11, after receiving confirmation 96, 97 that each part of the private key is true, the main depositing center can issue a certificate 98 to the user's public key 99, allowing it to be used in a secret system with the guarantee that,
Can get the secret details of the private key of the contributing user agents, combine them and track the messages of this user. Using this system, users can be guaranteed the confidentiality of their encrypted transmissions, and government agencies can be assured of the possibility, if necessary, to gain access to encrypted information exchange. Since under normal conditions no subject has access to the full private key, the likelihood of illegal or corrupt actions is significantly reduced. In addition, since a greater number of subjects can be selected as depositing agents, the likelihood of someone agreeing with all depositing agents at the same time, thus violating all activities based on trust, is further reduced.
The main deposit center, which certifies as a trusted authority, the authenticity of the user's public key, periodically publishes a public certificate confirming or verifying the connection between the public encryption key and information identifying its owner. The authenticity certificate guarantees the sender that transmissions sent to this named public-key user will in fact be received and read only by the intended recipient. The certificate usually has a recognized international electronic format, such as specified in CCITT X509 Recommendations and published as an international standard by the International Organization of Standards (ISO). An example of the format of the certificate of deposition of the public encryption key is shown in Figure 12. The certificate contains, among other things, the name of the organization or key management center that issued the certificate 121, the owner's public key 122, the information 126 identifying the owner, the serial number 123 of the certificate and the dates 124 indicating the beginning and end of the validity period. The digital signature 125 of the organization that issued the certificate “holds together” the certificate and prevents it from being changed.
The US government has proposed, however, as a government (and, possibly, industrial) standard, another way of allowing it to deposit personal decryption keys and track messages. The US government has developed a microcircuit called a "clipper chip", which can be embedded in government and commercially available telephones and computer devices. The clipper chip is a cheap chip that can be used for encrypting in large volumes and key management; The capston chip is an upgraded version of the clipper chip, which adds a digital signature and has the ability to receive short messages. Like other cryptographic systems, the clipper chip uses a symmetric encryption algorithm, which is a secret algorithm called "skipjack",
12
41387
but using an 80-bit key. Each clipper chip has a special ordinal number, a clipper key, common to all clipper chips, and its own symmetric device key, which will be necessary for the authorized government authorities to decode messages encoded by the device. . When a device is contained in a crystal, the device’s special private key will be divided into two components (which are called “key fragments”), stored separately in two key escrow databases or in two agencies that will be created by government bodies. Law enforcement officials can access these device private keys by obtaining a warrant or other legal authorization in order to intercept or retrieve them.hearings of communications and on the basis of presentation of warrants to depositing agencies.
When users of devices with clipper-chi-pami decide to establish a connection with each other, they first agree on a symmetric session key with which they will encrypt messages. Any method of outputting an asymmetric session key, such as the Diffi-Helm output key, can be used. ENA, and any method of transferring a UEZ session key to inter-users, such as an RZA transmission. At the beginning of each communication session, each user sends to another Access field for legal purposes (BEAP), which contains sufficient information A in order to allow authorities to intercept agentampravoohranitelnyh iliotslezhivat connection. The estimated format1_EAA clipper is shown in Fig. 13 (note that, since the exact details of the format, the creation of the 1_EAA check is currently classified by the US government as 'secret', proposed analysis and fig. 13 are, to a certain extent, speculative). To form 1_EAE, the session key is pre-encrypted using a personal key device; then, the session key encrypted with the device key, the sender's device sequence number and the checksum (test value) of the initial unencrypted session key are encrypted with the clipper family key in order to terminate 1_ЕАЕ. The message is then encrypted with the selected session key. The message, the encrypted session key, and 1_EAE, encrypted with the family key, are transmitted together to the recipient. After receiving the message, the recipient user first loads the received 1_ЕАЕ into the slipper-chip in order to verify the authenticity of 1_ЕАЕ and check whether the session key, encrypted as part of 1_ЕАЕ, matches previously received session key. In the case of BEAR authentication, the clipper chip decrypts the message with the selected session key previously received.
However, a law enforcement agent who, on legal grounds, intercepts or trails negotiations, does not know the session key and therefore must first decrypt 1_EAP,
to get a session key. The agent intercepts the necessary 1_ЕАP, decrypts it using the key clipper family and then presents the crystal number contained in 1_ЕАР, the injunction issued by the court or another legal resolution to the two government depositing agents, receiving, in turn, two private key of the device . The agent connects the two component keyed device keys and uses the device key received to decrypt the session key encrypted with the device key from 1_EAP. The session key can then be used to decrypt valid communications from the communication line. The requirement that the recipient and the recipient create every 1_EAR and confirm the 1_ЕАP of the other party, guarantees that law enforcement agents will have sufficient interception capabilities 1_ЕАр, since every 1_EAP is expected to be passed between users in the same communication medium. In addition, it allows law enforcement agencies to track only one suspected user by decoding 1_EAP prepared by this user, regardless of what kind of user organized the connection.
Unfortunately, with the government proposals concerning the clipper chip, the associated technical problems arising mainly from the fact that the private keys that need to be decrypted are permanently built into the clipper chips during the manufacturing process. Since the private encryption key for a particular device is programmed in a crystal and cannot be changed, the crystal and, probably, the entire device in which it is located should be removed from circulation in the event of a compromise. It is desirable for the user of a particular device to have the possibility of re-programming, depositing and certifying the device on their own, in cases of suspicion of compromise or at certain intervals in order to avoid possible compromise. In addition to the inability of the user to change the re-deposit program, the user of the clipper chip device does not have a choice as to the number or identity of the key deposit agents hired by the government to store his private key. Instead of fragments of the private key are placed two deposited databases or agencies formed by the government. Users may not trust devices with clipper chips because of the risk that the government may have full access to any exchange or transaction performed using a device, access to which may be the object of abuse or corruption. Users may also want their keys to be deposited with more trusted entities than the government proposes, so that their personal keys are more secure.
13
41387
choose your own proxies, who have to deposit their personal keys, based on the required degree of trust.
In addition, it is believed that the government clipper system allows the user to perform only symmetrical communication in real time and does not provide the possibility to use the transfer of messages via e-mail with intermediate accumulation. By encrypting messages, the sender and receiver must first agree on the symmetric key of the session, with which they will encrypt the messages. Usually, this key exchange is performed using the Diffie-Hel-Man dialog, the only key exchange method that can be implemented with a clipper chip .Thus, the possibilities of users, if only they do not wish to organize their own key management system, are limited to one-time, interactive communication, such as speaking and and fax communications in real vremeni.Odnako order In order to use e-mail communication with message transfer with interim accumulation, the user must be able to access the public key of the intended recipient, similar to using a certified Diffie-Helman or certified RZA key transmission scheme, even if the intended recipient does not exist, without allowing the interactive communication. Since it is assumed that the government system "clipper" does not facilitate the solution of this problem, the transfer of messages with intermediate accumulation is difficult. Thus, the standard system proposed by the government tends to limit the communication capabilities of users by dialing communication. The user must be able to access the public key of the intended recipient, similar to using a certified Diffie-Helman or certified RZA key transfer scheme, even if the intended recipient is not present, without allowing the organization to establish an interactive connection. Since it is assumed that the government system "clipper" does not facilitate the solution of this problem, the transfer of messages with intermediate accumulation is difficult. Thus, the standard system proposed by the government tends to limit the communication capabilities of users by dialing communication. The user must be able to access the public key of the intended recipient, similar to using a certified Diffie-Helman or certified RZA key transfer scheme, even if the intended recipient is not present, without allowing the organization to establish an interactive connection. Since it is assumed that the government system "clipper" does not facilitate the solution of this problem, the transfer of messages with intermediate accumulation is difficult. Thus, the standard system proposed by the government tends to limit the communication capabilities of users by dialing communication.
In addition, according to the government system, users' employers do not have access to encrypted information or transfers of their employees. Employers for whom employees develop, receive or transfer confidential or proprietary information should retain the right to access information or transfer data of their employees. Numerous situations are possible in which encrypted information can be available only to certain employees who are directly involved in using cryptographic systems, but not in administration or boards of directors who are responsible for these employees and who own information resources of the corporation. By encrypting data or messages, employees can develop or assign new programs to themselves, products and technologies or can carry out illegal actions and transactions, all this without the knowledge of their employers. In addition, relocation or reorganization of personnel and changes in memory capabilities may result in the loss of large amounts of information that were important during encryption. See the work of Donna B. Parker "Cryptography and the Prevention of Anarchy in the Field of Business Information"
(Presentation by a guest speaker at the First Annual Conference of Computer Security and Communication Security, November 3-5, 1993, Reston, pc. Virginia), included as a reference. In addition to the initiator of transmissions or the sender of transfers, the clipper-chip allows access to transfers only to government agencies. Although employers may require court issuance of a tracking order for their employees, employers may want to monitor their employees in any event of suspicion more confidentially than initiating a federal investigation.
In addition, the establishment of a systematized algorithm that is embedded in a crystal in such a way that it is available only in hardware and only from government-authorized manufacturers of crystals leads to a rapidly changing and highly competitive market for communications and computer hardware. A government agency or a government-authorized manufacturer may be unable or unwilling to design and market improved devices and products specifically designed for specific companies, as a private manufacturer would do. If government agencies authorize only certain suppliers to manufacture crystals with a systematic algorithm, competition will be reduced, and the technology will not be used in other products. In addition, since the details of the skipjack algorithm were not published, there was a suspicion about the possible lack of security of the algorithm, either due to the lack of review of the developers or to a special trap. An important feature of the cryptographic system is that the privacy and security of encrypted messages should depend on the secrecy of the corresponding key values, and not the secrecy of the system details.
Therefore, it is desirable to propose a commercial key deposit system in which the published algorithms are used, which works in such a way that inspires confidence and user confidence and at the same time solves problems related to national security and the requirements of law enforcement agencies.
It is also advisable to offer a commercial key depositing system in which private keys are used, which can be changed by the user at will or at certain intervals of time.
It is also advisable to offer a commercial key deposit system that allows the user to select key deposit agents for securely storing his private key or individual parts of his private key.
It is even more desirable to offer a commercial key deposit system that contains protection against unlimited government access, while allowing access with
14
41387
parties of the user's employers or countries of the countries of which are foreign users.
It is also advisable to offer a commercial key deposit system, which is the alternative proposed by the US government to a clipper chip system.
One of the purposes of the present invention is to propose a commercial key depot system that uses published algorithms and works in such a way that it causes the user's trust and confidence and at the same time solves problems related to national security and law enforcement requirements.
Another objective of the present invention is to propose a commercial key depositing system in which private keys are used, which can be changed by the user at a certain time or at regular intervals.
Another objective of the present invention is to propose a commercial key deposit system that allows a user to select key deposit agents for securely storing his private key or individual parts of his private key.
And another objective of the present invention is to propose a commercial system for the interpretation of a key containing protection from unlimited government access, while allowing access by employers of the user or by countries whose citizens are foreign users.
Another objective of the present invention is also to propose a commercial key depositing system, which is an alternative, proposed by the US government to systemclipper chips.
These and other objects of the present invention are achieved in accordance with the principles of the invention by proposing a cryptographic key depositing system, which uses a method similar to that of Micali’s “honest” depositing, for verifiable separation of the private encryption keys of users into separate components, and to send these components to trusted agents selected by specific users, and by proposing a system that uses the current management of public key certification, provided by the device with crystal, which is also self-certified. In a pre-respectful embodiment of the present invention, the integrated circuit performs the wiring or decoding only if certain conditions are met, namely: (1) if valid
defensive messages, thus providing the persons authorized to do so with sufficient information on the basis of which it is possible to request and receive the keys deposited. Since this invention is based on a certification management system, it can be made very flexible and independent of place and time, as opposed to purely interactive systems. Methods of depositing a private key for decrypting and obtaining a certificate of deposit are also applicable here to the more generalized case of registering a protected device with third-party confidence and obtaining permission from this party that allows the device to communicate with other protected devices.
Another preferred implementation of the present invention proposes a method of distributing verifiable trust messages among a plurality of users, including operations for transferring to a trusted center a deposit of a set of asymmetric cryptographic keys intended for use by a plurality of users; verification of each of the specified set of keys in the depot center; certification of authorization of each of the specified set of keys after verification; and initiation of a message from each of the specified set of users using, respectively, one of the specified set of keys that passed the specified certification. Other implementations of the present invention offer decoding of messages by authorized representatives of law-enforcement agencies based on the control header of the message included in each message, using a special decoding law enforcement unit and checking compliance of the facts of listening to the requirements of the law in order to exclude misuse parties of law enforcement officials and other official persons. Other preferred implementation options include reconfiguring and improving the firmware of the device using a certification system, and encrypting the data stream. using for this purpose a special decoding unit of law enforcement agencies and checking compliance of the facts of listening to the requirements of the law in order to exclude misuse by representatives of law enforcement agencies and other official persons. Other preferred options for implementation include reconfiguring and improving the firmware of the device using a certification system, and encrypting the data stream. using for this purpose a special decoding unit of law enforcement agencies and checking compliance of the facts of listening to the requirements of the law in order to exclude misuse by representatives of law enforcement agencies and other official persons. Other preferred options for implementation include reconfiguring and improving the firmware of the device using a certification system, and encrypting the data stream.
Brief description of the drawings.
These and other objectives and advantages of the present invention will become apparent after studying the following detailed description in conjunction with the accompanying drawings (FIG.), The numerals denote identical parts on which:
in fig. 1A-1C are lists of symbols and abbreviations used in the figures of the present invention;
in fig. 2 shows a flowchart showing the operations of the previously used dialogue method of deriving the Diffie-Hel-Man key;
in fig. 3 shows a flowchart showing the operations of the certification part of the Diffie-Helman certification method used so far;
in fig. 4 shows a flowchart showing the operation of the transmitting part of the applied
15
41387
still certified Diffie-Helman;
in fig. 5 shows a block diagram illustrating the encryption operations using the method of transmission of the RSTR key used so far;
in fig. 6 shows a flowchart showing the decryption operations using the hitherto RLR key transmission method used so far;
in fig. 7 shows a flowchart showing signature creation operations using the RZL key transmission method used so far;
in fig. 8 shows a flowchart showing signature verification operations using the RZL key transmission method used so far;
in fig. 9-11 are the flowcharts showing together the operations of the process of depositing Mikali's key applied up to now;
in fig. 12 shows an example of the format of the certificate of deposit of an open encryption key used so far;
in fig. 13 shows an example of the intended format of the Law enforcement access field (1_ELR) of a device with a clipper chip;
in fig. 14 shows an example of a device certificate format issued by the manufacturers of the device that is the subject of the present invention;
in fig. 15 is a flowchart showing the operations of the method of controlled key depositing with a single depositing agent;
in fig. 16 shows a flowchart showing the operation of the method of controlled key interpretation based on the protected device only;
in fig. 17 shows a flowchart showing the operation of a method for sending an encrypted message with a message control header (MCH);
in fig. 18 shows an example of the SIT in the format of the RZL key;
in fig. 19 is a flowchart showing operations of the method for receiving an encrypted message with the MCH;
in fig. 20 shows an example of a MCH decoding unit and a flowchart;
in fig. 21 shows an example of a self-certified secure device with time stamping;
in fig. 22 shows an example of a certificate holder format of a device owner issued by a device manufacturer that is the subject of the present invention;
in fig. 23 is a flowchart illustrating the operation of a method of re-depositing a key by the owner of the device that is the subject of the present invention;
in fig. 24 is a flowchart illustrating the steps of the method for registering a secure device, which is the subject of the present invention, with a trusted party.
Open key cryptographic systems involving the use of digital signatures can be the cornerstone of the creation of national and even global systems of electronic documentation that does not involve the use of paper. The use of these systems will be of great economic importance in terms of cost savings. A key element in the development and wide distribution of these systems is the credibility of their underlying cryptographic systems and digital signatures from government agencies, banks, corporations and other users, including individual users. Confidence in these systems should not flow out of the trust of each user to their own internal system or other users,
In a preferred embodiment of the present invention, a crystal with a protection of an unauthorized access or a crystal verified device with a protection of an unauthorized access that performs encryption, decryption and digital signature contains an embedded unchangeable pair of private and private signature keys, which is characteristic only for this crystal, and the manufacturer's certificate ". The embedded certificate from the manufacturer allows the device containing the crystal (a) to "sign" in digital formed documents and messages ("data structures") using their own personal key of the device signature and (b) to confirm by adding the manufacturer's certificate to the documents and messages that these structures data deserve confidence since the issuing device relates to a known and proven type and is made by a trusted manufacturer. The valid certificate of the manufacturer states: "The device whose private key corresponds to the public key that is certified here is of type XXX Signed, the manufacturer". Since the private key of the signature is embedded in a method that provides copy protection and since the manufacturer is trusted, documents and messages issued by the device and signed with the private key signature will also be trusted.
The preferred embodiment of the present invention includes eight main phases of use: (1) the creation or manufacture of crystals contained in the device, (2) registration of the encryption key of the device by deposerting agents, (3) ordinary encryption and encryption of user messages, (4) decoding of messages by authorized agents of law enforcement agencies, (5) reconfiguring and improving the device by the owner or employer, (6) audit
sixteen
41387
law enforcement intercepts, (7) encryption of information-oriented flow, and (8) protection of national security.
Making a secure device.
The manufacture of proven devices, which are the subject of the present invention, is based on the presence of the following common signs:
(1) a built-in microprocessor (or micro controller), a miniature computer that serves as an intermediary for all external accesses and performs various computation and programming operations;
(2) a co-processor selected at will, which can perform standard math encryption and decryption at a much higher speed than a general-purpose microprocessor and which, presumably, will contain a source of apparatus noise, such as a diode noise source a system to help generate the subject of certification of random numbers necessary for the formation of a cryptographic key;
(3) an input / output interface or subsystem designed to assist in working with the stream of data and commands coming in and out of the microprocessor, which may include a status indicator or monitor; and
(4) a memory subsystem in which several types of memory storage technology can be used, each of which has different indicators of time and availability, such as: (a) a permanent memory (“ROM”), which A swarm may contain permanent and unchanging programs and data, (b) an electrically-programmable permanent memory device (“EEPROM”) or a “P_AZN” memory device, which may contain semi-permanent programs and data, i.e. they can be from eneny, but are not lost when device power loss iliotklyuchenii and (c) of the storage device with present-random ( "RAM") which may be used in vre-variables for calculations and temporary hraneniyadannyh but cleared when power is turned off.
The entire device is designed and manufactured in such a way that all its elements, especially the areas of permanent and semi-permanent storage, are protected from unauthorized interference, which could lead to the detection of their contents or changes in their mode of operation. One of the ways to protect the elements of the device from outside interference is to use special coatings that are difficult to remove by not destroying the information under the cover. In addition, there are other elements that can erase memory in the event of an attempt to change the physical state of any of the storage areas, or, in the case of sub-visual actions that can signal interventions, such as cooling a device to an abnormally low level. -parameters when attempting to deactivate and deactivate
internal protective mechanisms of the device. Some of these protective devices can be forced into a permanent source of power from the battery so that the device can perform the power-consuming actions to erase important information in case of suspicion of intervention. The present invention does not offer any concretely preferred way of providing protection for a device from outside interference, but is based rather on existing, or may appear in the future, technical means that are considered or can be recognized as providing sufficient degree of protection against unauthorized disclosure or alteration of the data contained in the device. A device with such characteristics is sometimes called an anti-interference module ("TRZM"), an example of which
The manufacturer of crystals can be any of many leading manufacturers of microprocessor chips for computers. The manufacturer, preferably, should be of the number known in the cryptographic industry and enjoy confidence in the quality and reliability of the crystals and the integrity of their manufacturing process.
Crystals manufactured for use in the practice of the present invention should have the following characteristics. First, the crystal must include a pair consisting of a public and a private key in order for the device to issue device signatures, and the personal signature key is not readable and copy protected. Cryptographic keys can be of any acceptable cryptographic type, such as RZL. However, since RZL has both encryption and signature capabilities, and since it is desirable to separate the signature and encryption processes, the cryptographic key of the signature should preferably be a UZA Crystal should also contain an embedded and a manufacturer-protected certificate for a device key signing, an example of the format shown in fig. 14. The device in which the crystal is contained,
A crystal manufactured for use in an embodiment of the present invention should also include the manufacturer's open key for verifying the signature embedded in the crystal with protection against tampering. The manufacturer’s public signature key can be used by the user to verify instructions received from the party. In doing so, the user verifies: whether these instructions are provided with a valid digital signature, created by the manufacturer’s private key in order to determine whether these instructions were issued by the manufacturer or
17
41387
or, the manufacturer's confidence. The crystal may also contain built-in and tamper-proof open keys that can be used by the user to verify instructions received from others. The public key of instructions can be the open key of any other legal entity using a legal entity, such as a Vampke Τπιεί Co., selected by the manufacturer, or it can be the public key of a trustworthy organization with a national or global network, and can be embedded in the crystal by the manufacturer for use. as an “abbreviated” key, to prevent an additional manufacturer’s certificate for a trusted entity from running. The manufacturer can set several command keys for various suitable key depositors,
In addition, the crystal used in the implementation of the present invention should have the ability to create a pair consisting of an open and a private key for encrypting the ideal encryption of data and messages of an individual user. Cryptographic encryption keys can be of any acceptable asymmetric cryptographic type, such as RZA cryptographic keys, preferably should, however, be of the Diffie-Helman type, t. e. The user's secret number is the private key and the published user intermediate number is the public key, which are used together in a Diffie-Helman Certified scheme to generate a session key, which is used to encrypt and decrypt messages. The private key obtained in this way is then stored in the crystals in a non-readable and protected form. In addition, since a pair of public and private key encryption for this device has already been obtained, the crystal must also be able to change the setting and get a new pair of private and private encryption keys along with the first pair of keys. In another version of the implementation, it is possible to use the Diffie-Helman Dialog key generation to ensure that all senders and receivers enter new random numbers to generate session key keys.
In a preferred embodiment of the present invention, the secure device will be able to decrypt encrypted messages only under two conditions. The first condition is that the device must be entered with valid certificates of the main deposition center for both the sending and receiving devices before entering the encrypted data transfer. Each certificate is valid if it is signed by the main deposit center, confirming that the personal decryption key of this device is deposited with one or more suitable depositing agents, and preferably with two or
more Mikali-type agents that apply the key-dividing protocol that is subject to verification. This certificate of the main deposit center must be accompanied by another certificate issued by the manufacturer who established the said main deposit center as a valid deposit agent or must be signed by a third party ( a trustworthy organization with a national or global system), called an open command key holder embedded in the crystallizer. The second decryption condition is that the message to be decrypted must be preceded by a control header (MCH) of the data area (the format for which will be described later), therefore the law enforcement agencies or the employer’s security personnel will have sufficient information
In another embodiment of the present invention, the crystal will also have the ability to create a pair of public and private keys for using user signatures that differ from the built-in key pair, which are used to create device signatures. As with a pair of keys for signing the device, cryptographic signature keys for users can refer to any acceptable cryptographic form, such as RZA, but, presumably, should be UZA, in order to avoid possible confusion with the keys used for message encryption. The private key of the user's signature should not be readable and must be protected from confusion. The user must use a personal signature key to sign his messages as a sender in order to authenticate them and to prevent the author from discarding the authorship of these messages. In another embodiment of the implementation of this device, the crystal also has the ability to use the device signature key in order to sign the certification of the user's public key, which he created for the user, thus confirming that the user signature key pair is created and the private key is stored by the device with known characteristics of protection against unauthorized interference. In other embodiments of the present invention, the crystal may also have a hardware noise source, such as a diode noise source, designed to generate random numbers when creating a key, and the sequence number assigned only to this physical device allows tracing the device or its operations in systems of financial accounting and network management. In this implementation, the signature of the device must confirm not only that the user's device possesses the known characteristics of protection against tampering, but also that each key or a random number formed by the device was pro-
18
41387
voluntarily formed again each time using high-quality random numbers, preferably a source of di-one noise.
When manufacturing a secure device containing a crystal, which is the subject of the present invention, the crystal memory is divided into at least three common areas, like the following: (1) a permanent and immutable memory area containing information and firmware embedded in the crystal in the process manufacturing; (2) a semi-permanent and changeable memory area containing such information as personal encryption keys and user signatures created for the user and stored for the user as a crystal, and this information and keys can be used by the crystal to execute digital signatures or for decryption on behalf of the user, but out-of-device devices and (3) non-permanent and temporary memory areas containing a work area used for temporary storage of input data are never revealed, intermediate results and final results of various data processing operations. Depending on the design, these three main areas may each be located in different types of storage devices, such as ROM for permanent information, EEPROM or "Е1_АЗН" for user information stored by the device and RAM for energy-dependent temporary storage. Another approach may be to use "E1_AZN" memory to store both permanent and non-permanent for energy-dependent temporary storage. Another approach may be to use "E1_AZN" memory to store both permanent and non-permanent for energy-dependent temporary storage. Another approach may be to use "E1_AZN" memory to store both permanent and non-permanentinformation Another option is the use of a chip operating system, which must manage the memory of the microprocessor using the object catalog. With this approach, one part of the memory can be given to a table or directory of other data elements in memory and can include standardized information regarding each object, such as:
- a logical name (for example, "public key manufacturer");
- type (for example, key, certificate, subprogramme of a code, etc.);
- starting address and length of information (inbit);
- the date of the last changes (optional);
- level of protection (permanent, user, or volatile);
- level of disclosure (readable from the outside or unreadable from the outside).
With this method, to the extent that all memory is equally protected from unauthorized intervention, it is not necessary to designate specific areas for protected or unprotected information, since the microprocessor can easily apply the desired level of protection based on the code contained in the corresponding element catalog for an information object. This scheme can also be applied to embedded coding programs with the same ease as to information, and its advantage is its ability to
applications to improve or replace protected coding firmware without the need for physically replacing the device or any of its memory blocks.
Protected areas of device memory, which is the preferred embodiment of the invention, may contain the following types of information, including both data and a built-in encoding program.
A. Permanently built by the manufacturer
1. Can be revealed from the outside.
but. public key of the organization managing the system (optional)
b. manufacturer's public key
at. certificate issued to the manufacturer by the organization managing the system
d. public key device
d. manufacturer's certificate for the device
e. sequence number assigned to the device
g. firmware version numbers
h trusted bank command public keys
2. Cannot be disclosed from the outside.
but. device signature private key
3. Firmware
but. operating system and file system
b. basic cryptographic library routines
at. deposit system routines
other verified application codes
B. Created during user operations and protected for the user.
1. Can be revealed from the outside.
but. public user encryption key
b. certificate of deposit of public key encryption user
at. user's public key
The certificate of the public key of the signature of the user
2. Cannot be disclosed from the outside.
but. user private decryption key
b. user's private key
B. Other non-volatile readable writable storage objects (optional)
but. correspondent signatures certificates
b. certificates of deposit of correspondents
at. Certificates of device correspondents (for checking the SIT)
G. RAM (can be energy dependent)
Public keys (all types), certificates (all kinds), hash values, signature blocks, other information structures that are processed.
Key deposit process
After making the crystal that is the subject of the present invention, and before using the crystal to encrypt or decrypt messages, the public decryption key of the user must be encrypted at the main deposit center or with depositing agents approved by the crystal manufacturer. The user can perform this operation independently, or the manufacturer can initiate and register the deposit agent with the crystal during the manufacturing process, thus freeing the user from
nineteen
41387
It’s important to deposit your keys yourself. However, the manufacturer may leave the user the option to perform a later relocation. For many individual users, giving the manufacturer the right to register a crystal, with or without the possibility of a subsequent reconfiguration, will be sufficient. In addition, consumers, in the most probable degree, will trust depositing agents selected by the crystal manufacturer. Corporations or other employers can program their own crystals and crystals of their employees and can register the crystals with depositing agents of their choice. Corporations, however, will not allow their employees to perform reconfiguration on their own, as this may lead to loss of control over information belonging to the corporation,
In order to create and register a decryption key, the user (or any entity that performs the operation) applies a built-in firmware that was inserted into the crystal and which gives instructions to the crystal to perform certain operations, according to the method of depositing the key by Mick-li, or another applicable the method of depot nirovaniya key (see Fig. 9-11, 15 and 16). Applying any method chosen for depositing a private key with one or several depositing agents, the crystal first randomly forms, or chooses, a secret number that will be the private key for decrypting this user (as well as other public numbers that will be required in , if these numbers are not specified already for any other compulsory arbitrary formation). The crystal will store the private key in a form that is readable and protected from unauthorized interference. As shown in Figure 15, the private decryption key can be deposited with a single depositing agent. The secure device 150 first creates a pair of public and private encryption keys 151 of the user and then sends an encrypted and signed message 152 to the deposit center 153 containing the encryption key pair 151 and the device serial number 154, with a certificate 155 from the manufacturer to confirm the signature. The Deposit Center 153 verifies signatures, decrypts packet messages, and stores the user's private key decryption. The Deposit Center 153 also sends to the user the signed certificate 156, consisting of the ordinal number 154 of the user's device and the public encryption key 151 of the user, as well as the public key 157 for verifying the device signature with the certificate 158 of the deposit center to verify the signature. As soon as the user's device verifies the signature of the deposit center, registration is completed.
If a private key should be deposited with more than one depositing agent, the crystal will divide the private key into several parts, which are called
worn by shards of the key. Using the method of Mikali's interpretation, described earlier and shown in fig. 9 algorithm, the crystal will calculate some values of 90 using Micali’s special algorithm for this, each value based on the mathematical transformation of one of the private key parts 92. The crystal then forms one fractional packet for each trustee or depositing agent 94 specified by the user, in which case each share package 93 includes the user's device's ordinal number, one private key's key and a number of specific values, which allow this authorized person to make sure that the received Oloka personal klyuchayavlyaetsya real part of all lichnogoklyucha, without transmitting a trusted litsuznacheniya all private key. As shown below, if the user is not the owner of the device, but, Rather, the employee of the employer-owner, the share package must also include the unique identification number of the device owner and the device owner’s certificate so that the employer-owner can obtain the employee's personal key without first obtaining a warrant. Then, the crystal signs each shared packet trust using the device’s personal signature key assigned to the device and attaches the manufacturer's certificate to the transmitting crystal, thus confirming that the transmitted information comes from a device of a known and protected type. And finally, the crystal will issue each signed shareware package to a trustee for shipment by the user to the trusted depositing agent. The equity package must also include the unique identification number of the device owner and the certificate of the device owner, so that the employer-owner can obtain the personal key of the employee-user without having to first receive a warrant. Then, the crystal signs each shared packet trust using the device’s personal signature key assigned to the device and attaches the manufacturer's certificate to the transmitting crystal, thus confirming that the transmitted information comes from a device of a known and protected type. And finally, the crystal will issue each signed shareware package to a trustee for shipment by the user to the trusted depositing agent. The equity package must also include the unique identification number of the device owner and the certificate of the device owner, so that the employer-owner can obtain the personal key of the employee-user without having to first receive a warrant. Then, the crystal signs each shared packet trust using the device’s personal signature key assigned to the device and attaches the manufacturer's certificate to the transmitting crystal, thus confirming that the transmitted information comes from a device of a known and protected type. And finally, the crystal will issue each signed shareware package to a trustee for shipment by the user to the trusted depositing agent. Then, the crystal signs each shared packet trust using the device’s personal signature key assigned to the device and attaches the manufacturer's certificate to the transmitting crystal, thus confirming that the transmitted information comes from a device of a known and protected type. And finally, the crystal will issue each signed shareware package to a trustee for shipment by the user to the trusted depositing agent. Then, the crystal signs each shared packet trust using the device’s personal signature key assigned to the device and attaches the manufacturer's certificate to the transmitting crystal, thus confirming that the transmitted information comes from a device of a known and protected type. And finally, the crystal will issue each signed shareware package to a trustee for shipment by the user to the trusted depositing agent.
There is another, preferable, way that the main center for depositing separate key fragments without using the method of Mikali, based only on a protected device, is the main way. Using this method of checking a fragment of a key, shown in FIG. 16, the crystal forms one random number for each fragment of the private key encryption key. Crystalzatem forms one share package 161 for each trustee or depositing agent 163 specified by the user, and each share package includes the device number of the user, one fragment of the private key and a single random number. The crystal signs each share of the trustee using the device’s private key assigned to the device and attaches the manufacturer’s certificate 162 to the transmitting chip, thus confirming that the information transmitted comes from a device of a known and protected type. As in the case of Mikali's method, the crystal will then issue each signed share packet 161 trustee for transfer to the user by the trusted depositing agent 163. In addition, the crystal must also create a (encrypted) message 164 for the main deposit center 165, containing, among other things, the user's public key and the name of the depositing agents assigned by the user, along with a random number issued by
20
41387
together with key fragments for each relevant depositing agent.
However, since each equity package of an attorney contains a private key fragment, it is possible that a third party having access to the communication line between the user and depositing agents may read the contents of all user equity packages and combine the contained private key fragments in these packages to reassemble the complete private key. Then, using a private key, this third party can decrypt and encrypt messages received by the user's name. The best way to avoid such a situation is to use encrypted communication systems when sending equity packages from users to depositing agents. The user must obtain a certificate166 of the public key of the encryption of each depositing agent selected to deposit the user's private key, each certificate is signed by the main depositing center confirming that this particular depositing agent is authorized by the main deposit center to receive and store the key breaking package, and must then verify the signature of the main deposit center using the certificate of the device manufacturer (or organization, management system) or pre-approval certificate. optionally embedded command key. After that, the device will implement for each deponing agent based on the certified public key of encryption of this agent, the transfer 161, including the share packet of the user's private key. On the other hand, the manufacturer can embed several trusted trust agents in the crystal-open encryption keys with a combination of commands for each, as described earlier, for the user to send fragments of his personal key to depositing agents who enjoy the trust of the key holder of the commands, which is usually the main center of deposition. Thus, all the depositing agents of the main deposit center or manufacturer’s “family” may decrypt user requests for deposit, while at the same time sharing with the user the burden of obtaining certificates of the public encryption key of all depositing agents.
As soon as the depositing agent or trusted person 163 receives the corresponding share package 161 from the user or user device, the trustee examines the fragmentation key received in the share package 161 of the attorney from the user's device and, together with the deposit center 165, is awarded that this fragment is a real and faithful part of the whole personal key. The depositing agent and the principal centering agent must have a reliable means of verifying or confirming that the actual fragments of the user's private decryption key have been deposited. It is desirable that the verification of the key fragments by the depositing agents or the main center of the deposit could be carried out without inspection or possession
by these fragments themselves, or even the compounds in one place. The “honest” deposit system of Mikali offers one highly reliable method of checking at the center of the deposit of individual key fragments. In the Mikali method shown in fig. 10 and 11, this check is performed with a set of specific values that were calculated by the user crystal in the process of preparing the equity package using the Mikali special algorithm and which were included, along with a key fragment, in each equity package for depositing agents. The Mikali algorithm and the verification of the key fragment are known to specialists in this area and do not need to be repeated. Each trustee 94 then stores the device manufacturer’s certificate for subsequent use for decoding and validates the key fragment 93,
Using the preferred method of depositing and checking, based only on the protected device and shown in Figure 16, each trustee 163 transmits a message 167 to the main deposit center 165, identifying the user's name, the public encryption key, the device number and the random number that it received. In addition, the user device sends a package containing the random numbers used to verify fragments of a personal code to the central centrifuge 165, and this packet must be encrypted using the public key encryption key of the escrow center. The main deposit center 165 receives 163 messages 164, 167 from the user’s device and from the authorized representatives, and the authorizes that a separate random number received from each authorized representative corresponds to a random number, which, according to the approval of the user's device, it was sent to this authorized person. Note that with this method, the depositing agents 163 and the main deposit center 165 rely, in order to verify the validity of the deposit, solely on the signature of the protected device on the equity packages 161. This method of depositing and checking does not require any additional mathematical operations to ensure the correctness of the interpretation or that the submitted public key certifies the corresponding key fragments. Although, from a society, user, or system management point of view, it may still be desirable to use a verifiable key-deposit algorithm, as in the Mikali process, it is obvious that this is not necessary and can be waived when was sent to this trustee. Note that with this method, the depositing agents 163 and the main deposit center 165 rely, in order to verify the validity of the deposit, solely on the signature of the protected device on the equity packages 161. This method of depositing and checking does not require any additional mathematical operations to ensure the correctness of the interpretation or that the submitted public key certifies the corresponding key fragments. Although, from a society, user, or system management point of view, it may still be desirable to use a verifiable key-deposit algorithm, as in the Mikali process, it is obvious that this is not necessary and can be waived when was sent to this trustee. Note that with this method, the depositing agents 163 and the main deposit center 165 rely, in order to verify the validity of the deposit, solely on the signature of the protected device on the equity packages 161. This method of depositing and checking does not require any additional mathematical operations to ensure the correctness of the interpretation or that the submitted public key certifies the corresponding key fragments. Although, from a society, user, or system management point of view, it may still be desirable to use a verifiable key-deposit algorithm, as in the Mikali process, it is obvious that this is not necessary and can be waived when that in this way the depositing agents 163 and the main deposit center 165 rely, in order to verify the validity of the deposit, solely on the signature of the protected device on the equity packages 161. This method of depositing and checking does not require performing any additional mathematical operations to verify the correctness of the interpretation, or that the public key submitted to the certification corresponds to the deleted key fragments. Although, from a society, user, or system management point of view, it may still be desirable to use a verifiable key-deposit algorithm, as in the Mikali process, it is obvious that this is not necessary and can be waived when that in this way the depositing agents 163 and the main deposit center 165 rely, in order to verify the validity of the deposit, solely on the signature of the protected device on the equity packages 161. This method of depositing and checking does not require performing any additional mathematical operations to verify the correctness of the interpretation, or that the public key submitted to the certification corresponds to the deleted key fragments. Although, from a society, user, or system management point of view, it may still be desirable to use a verifiable key-deposit algorithm, as in the Mikali process, it is obvious that this is not necessary and can be waived when in order to verify the validity of the deposit, exclusively for the signature of the protected device on the equity packages 161. This method of depositing and verifying does not require any additional mathematical operations to be performed to verify the correctness of the de-designation, or that the public key presented to the certification corresponds to the deleted key fragments. Although, from a society, user, or system management point of view, it may still be desirable to use a verifiable key-deposit algorithm, as in the Mikali process, it is obvious that this is not necessary and can be waived when in order to verify the validity of the deposit, exclusively for the signature of the protected device on the equity packages 161. This method of depositing and verifying does not require any additional mathematical operations to be performed to verify the correctness of the de-designation, or that the public key presented to the certification corresponds to the deleted key fragments. Although, from a society, user, or system management point of view, it may still be desirable to use a verifiable key-deposit algorithm, as in the Mikali process, it is obvious that this is not necessary and can be waived when This method of depositing and checking does not require performing any additional mathematical operations in order to verify the correctness of the interpretation or that the public key presented to the certification corresponds to the deleted key fragments. Although, from a society, user, or system management point of view, it may still be desirable to use a verifiable key-deposit algorithm, as in the Mikali process, it is obvious that this is not necessary and can be waived when This method of depositing and checking does not require performing any additional mathematical operations in order to verify the correctness of the interpretation or that the public key presented to the certification corresponds to the deleted key fragments. Although, from a society, user, or system management point of view, it may still be desirable to use a verifiable key-deposit algorithm, as in the Mikali process, it is obvious that this is not necessary and can be waived when
21
41387
additional costs associated with the use of such a process cannot be justified. In addition, with this method of support, only an intrinsically protected device does not exist for the complexity of possible key separation schemes, since there is no need to compile complex secondary algorithms to verify the correctness of any given scheme. You only need to trust the integrity of the device manufacturer who has embedded the firmware code, and be sure that the device will be protected from unauthorized interference.
After checking all the fragments of the personal key of the user, the main deposit center itself further approves the public key of encryption, which corresponds to the personal decryption key approved by all trusted persons of the user; the main deponent center 165 asserts the public key by issuing a signed certificate 168 (which is called the main depositary center certificate, encryption public key certificate or simply the deposit certificate), confirming that the private key corresponds to the public key being certified, already deposited properly. The public key of the user’s device’s signature obtained from the device’s manufacturer’s certificate may also be placed on the certificate of the main depositing authority, thus excluding the need to send or re-verify the device manufacturer's certificate at more advanced stages of the process. The certificate of the main center of the deposit can be formatted as follows:
Version number
Sequence number of the certificate of deposit
Country code of the main deposit center
The name of the main center of deposition
Public key encryption of the main center of depositing (for use in creating1_EAA)
Distinguished user name
Public user encryption key (certified by this document)
The public key verifying the signature of the device user (to verify the signature of the device)
Validity (start / end)
Signature of the main deposit center [Se-certificate of the entire system of the main depot center].
Certificates of the public encryption key issued by the main deposit center are distributed and can be used both by the device owner, in order to bring their device into operation and send the encrypted messages, or by the other party to encrypt messages sent to the owner of the device containing this pair, consisting of the public and private encryption keys of the user.
It should be noted that the present invention does not require more than one depositing agent as a recipient of fragments of a private encryption key of the user; in some
In some cases, it may be sufficient to simply deposit the user's personal key for decryption with the sole depositing agent (or at the deposit center). However, in order to increase trust in the system from the user and the public, it is desirable to distribute the user's private key to decrypt among several depositing agents so that all of the key fragments or a certain number of them are required in order to reassemble the user's key and decrypt his messages. It is also desirable that each de-ponuing agent be an independent, reliable business organization, providing, thus, “shard knowledge”, therefore, in the case of an attempt of theft, bribery, extortion or abuse, it would be much more difficult to illegally obtain the personal key of user decryption -the bodies than if this private key was kept by the individual. It is also desirable that these entities be divided geographically, with the aim of creating an additional obstacle on the way to attempts at subversion or corruption.
Message encryption
A user who wants to send encrypted
message to another user, must have a certificate of deposit on their own device and a certificate of deposit on the public encryption key of the intended recipient, since the device that is the subject of the present invention will not perform encryption or decryption operations in the absence of any of these components. First, the sender must load his own valid certificate into the device, usually when he first receives it from the main deposit center. It is then possible to obtain the public key certificate of the intended recipient from both the directly reputable recipient, from the directory service listing the public key certificates, and from the local sender file, for example, the file with the list of users With which the sender previously exchanged encrypted messages. In one embodiment of the present invention, the originator will not encrypt, and the recipient's device will not decrypt if the certificate of the recipient's public encryption key is not "valid". In order for the recipient's device to decrypt the encrypted message, the recipient's public key certificate must be signed by (a) the manufacturer of the recipient's device (which is unlikely, since device manufacturers will most likely not be involved in depositing users' private keys); or
(b) the main deposit center, with the addition of the certificate of the manufacturer approving the main deposit center as a real trustee; or (c) a trusted person or the main center of deposition, the command key of which is embedded in the device during the manufacturing process. Using a certified public encryption key of the intended recipient, as specified in the certificate of the recipient's public encryption key
22
41387
The sender-recipient then creates a session key for use by the sender and recipient to encrypt and decrypt messages. This session key can be created, preferably, using a Diffie-Helman Certified method or, on the other hand, any other equivalent system. According to the Diffie-Helman Certified Method, the user first creates, optionally, a short-term private key for the message, and then calculates the session key based on his own private key and public key of the recipient (i.e., the intermediate number and the two-party recipient numbers that are contained in the public key certificate encryption recipient). Then, using the session key, the cipher encrypts the message that should be sent to the recipient user.
However, in deciding whether to send or not encrypted message to the intended recipient, the sender may not be able to verify the certificate’s public key certificate certificate or the digital signature on it if the sender’s device was manufactured by a different manufacturer than the recipient’s device. The fact that the recipient’s device was made by another manufacturer may not allow the sender’s device to easily verify either the manufacturer’s signature or the manufacturer’s certificate (which certified the main deposit center that signed the recipient’s key deposit certificate), confirming that the main the center of deposit of the beneficiary is valid and approved by the manufacturer. The same way, The recipient's crystal may not be able to verify these conditions in relation to the sender's certificate in front of the dechi-fraction. The use of a deposit restriction for both parties is required in order to enable law enforcement officials to legitimately intercept and decrypt messages sent and received by the suspect user, without necessarily obtaining the private decryption key of another not being monitored, the party, and, thus, without access to the non-de facto messages of this non-supervised party.
One of the ways to solve this problem, while allowing the release of cryptographic devices by more than one manufacturer, is to embed into a device or certificate issued either by the main center of the user's deposit or by the manufacturer of the public key of a national legal entity for example, the Federal Reserve Bank (FRB), which can be used to verify one more certificate issued by the Federal Reserve Bank to each of the other deposit centers or manufacturers. This certificate must confirm the reliability of a particular main deposit center or manufacturer and must be signed by the Federal Reserve Bank. The sender user can now get the encryption public key certificate
recipient and can trust the main deposit center that issued the certificate, since the main deposit center received authorization from the Federal Reserve Bank, and not from the manufacturer of the crystal, as confirmed by the public key of the Federal Reserve Bank or the certificate. In addition, the signatures of a specific device can also be trusted, since another manufacturer who has certified this device has been authorized by the FBR, as confirmed by a certificate or public key of the FBI. In order to solve this problem at a less limited level than the United States, to create a more international and global system, the possibility of building into a secure device in the certificate of the Federal Reserve Bank or the certificate of the main center of deposition or manufacturer (depending on the trust model used) open The key of a trusted global legal entity, such as the Swiss Bank of International Accounts, and using it in the manner discussed above for the key of the Federal Reserve Bank, in order to authorize the main depository centers and manufacturers at the global scale. Another way, though not connected by US and global organizations, is to ensure that the device is trustworthy for designation centers certified by another manufacturer, is to cross-certify each other by device manufacturers or by major deposit centers. This should allow the sender's device to apply the restrictions of the deposit of the recipient, allowing the sender's device to verify the certification of the certificate of deposit of the recipient in the opposite direction from the manufacturer of the recipient device or the main deponing center to its own.
In any case, when the user, the subject or device “verifies” the “certificate” with a digital signature, regardless of whether it is a manufacturer or deponirovanie certificate issued by the certifying authority or manufacturer, for most or all valid and the proposed public key certification management systems (and this is taken in the present description) it is common that the user, subject or device also verifies the “list of revoked certificates” (“CP1_”) in order to determine: exists whether the holder of the certification or other authority is distributing, distributing or otherwise publishing a list of revoked certificates, updated in accordance with the appropriate security policy, and is this not a certificate, agrees with the name of the publishing authority and the certificate number, canceled. The certificate you are given to the user can be revoked in
23
41387
connection with the death, change of name or place of employment, or loss, theft or destruction of the device (intellectual card of the person) containing the private key. A certificate issued to a legal entity may be revoked due to termination of activities, change of name, or loss, theft or destruction of a device containing a private key. A certificate issued to a device may be revoked due to loss, theft, seizure of the device, device breakage . The verification of the CP1_ input certificate verification is well described in the open literature (for example, АІЧЗІ Х9.30 - Part 3) and does not require further discussion. All users, subjects and devices will usually have access to the appropriate tele-communications and can restore the CP1_ or make the necessary requests. In a similar way, according to the present invention, all organs producing CP1_,
Message Control Header Format
When sending an encrypted message, the sending user also generates a message control field header (MCH) containing the following information:
(1) The intermediate number of the sender for an encrypted message calculated by the sender using a one-time private key, randomly generated by the sender, which was also used by the sender to calculate the session key that the message was encrypted. The recipient user must have an intermediate number to calculate the session key to decrypt the communication.
(2) Name and country code of the main center of deposit of the sender.
(3) The name and country code of the main deposit center of the recipient, obtained from the certificate of the recipient's public key.
(4) The certificate number of the sender’s deposit is encrypted using the public encryption key of the sender’s main depot center (obtained from the sender’s deposition certificate), therefore only the sender’s main deposit center can decrypt it.
(5) The intermediate number of the sender (different from the previous intermediate number of the sender), which is used by the sender to calculate the one-time session key, which has been encrypted the sender's certificate number for the sender’s main deposit center. The sender’s main deposit center must have this one-time key to decrypt the sender's certificate number.
(6) A session key for an encrypted message, encrypted using the user's own public key (an interim number from the sender's own public certificate), with the result that the sender sends the session key for the message to itself. Law enforcement agencies can access this session key for reporting as soon as they receive the private key components.
sender from depositing agents sent
body.
(7) The intermediate number of the sender (different from the two previous intermediate numbers of the sender), which was used by the sender to calculate the one-time key that was used to encrypt the key for the message. Law enforcement agencies must have this number in order to calculate, using also the private key of the ruler (his secret number), obtained from the main center of the deposit of the sender, a one-time key for decrypting the session key for the message.
(8) The recipient's certificate number is encrypted using the public key of the main deposit center of the beneficiary (obtained from the beneficiary deposit certificate), therefore only the main deposit center of the recipient can decrypt it.
(9) The intermediate number of the sender (differing from the three previous intermediate numbers of the sender), which was used by the sender to calculate a one-time key that encrypted the number of the deposit escrow certificate for the recipient’s main deposit center. The recipient's main deposit center must be located with this number in order to calculate a one-time session key for decrypting the recipient's certificate number.
(10) A timestamp (optional) for tracking targets and, possibly, to facilitate observation of the date of the order and time constraints.
(11) Signature of the sender's device.
(12) The certificate of deposit of the open key of the sender issued by the main center of depositing the sender. The sender’s deposition certificate must contain the public key of the signature of the sender’s device, which preliminarily checks the main depot center, and then copies the sender’s device from the certificate from the originator’s device.
(13) The certificate of the main deposit center issued by the Federal Reserve Bank, the manufacturer or any management system that is deemed to be a reliable body is attached to the sender’s deposit certificate in case the receiver's crystal is made by another manufacturer. Sertificate of the manufacturer, the Federal Reserve Bank of Russia or the control system of the body is required only in the first case of establishing a connection between the two parties. The certificate may also be cross-certified by the manufacturer of the recipient or its main deposit center.
Thus, the described control message heads (MCH) can be summarized as follows:
Intermediate number of the sender (allowing the recipient to decrypt the message)
Country code of the main center of deposition of the sender
The name of the main center of deposition of the sender
Country code of the main center of the deposit of the recipient
24
41387
The name of the main center of the deposit of the beneficiary
The number of the deposit certificate of the sender, encrypted for the sender’s main depot center
Intermediate number of the sender (for encrypting the number of the sender's certificate)
Session key for message encrypted by sender
Intermediate sender number (to encrypt session key for message to sender)
The number of the certificate of deposit of the recipient, encrypted for the main center of the depot of the beneficiary
Intermediate number of the sender (for encrypting the number of the certificate of the recipient)
Timestamp
Signed MSN device sender
[Certificate of Deposit of Sender]
[Certificate of Deposit Center].
In fig. 17 shows the process of sending a message 176 with the MCH. The entire SIT 172 (the attached certificates 173, 174, 175 are not technically part of the SIT) is signed by the device of the sender 171, using the private key of the signature of the 1EPA device, attached to the manufacturer’s non-built certificate (as part of the sender’s deposit certificate) device signature key. This ensures that the entire SIT is transferred to the recipient intact and that the recipient's crystal can easily verify that the SIT is unmodified. The certificate of the manufacturer can be accompanied by a certificate of the national (FBI) or a world body confirming the reliability of the manufacturer of the sender's crystal in the event that the recipient's device was manufactured by another manufacturer.
In another embodiment of the present invention, it is possible to use a second, more or less short, MCH format if the overall secrecy is not critical. In the SIT for the corresponding main deposit center, neither the sender's certificate number nor the certificate of the recipient is encrypted. The rejection of the encryption of certificate numbers ensures, when creating the SIT, an economy of time and place. In a further variant of the present invention, it is possible to use a third, even shorter format, SIT for the general case in which both the sender and the recipient use the same main deposit center when the key is deposited when the EC1 is identical to the EC2. By eliminating neoThe identification of the second main deposit center and a special intermediate number, which is used to encrypt the consumer certificate number for the second main deposit center, must be made significantly shorter. In addition, the size of the SIT can be reduced to an even greater extent by transmitting the key of the relay protection to encrypt the key UEZ for the message and for each of the three encrypted internal
BEAR components. According to this method, each intermediate number of the sender can be replaced by a smaller one, transformed with a RZA key 1EEZ. Thus, the sender can, using the RZA, encrypt the key of the message transfer session for the recipient and eliminate the need for the first, intermediate, number in the MCH. The sender can also encrypt the relay session key with the help of the RZA itself (in fact, for subsequent decryption by law enforcement agencies) and, thus, eliminate the need for a third intermediate number in the SIT. The sender can also encrypt the RZA with its own certificate number and certificate number of the recipient and, thus, eliminate the need for the second and fourth intermediate numbers in the MSN. As shown in Figure 18,
Adding random material.
Some may be concerned about the fact that the key of the message transfer session, which is exchanged using only the relay protection key or the Diffie-Helman certified key transfer method, is not secure, because in any of these methods, although the information is provided by both the sender and the recipient , only the sender creates a key message transfer. However, according to the standards of communication security, both the sender and the recipient must introduce random material before each communication session to create a session key, obviously, in order to reduce the likelihood that the sender uses a weak key or reuse the same key, thus exposing against the will of the recipient against an undesirable risk of security. The system of protected devices, considered according to the present invention, allows you to remove these fears in two ways. First, it can guarantee that each sending device will create each key separately, using the random numbers extracted from the noise of the built-in hardware noise source, such as the reverse bias diode discussed above. Then, As long as the device signs the MCN or the control header of the message, the recipient must be sure that every key in sending the message and the random numbers used to create it are reliable and non-repeatable. At the same time, those who insist on increasing security may require random material to be exchanged by both parties involved in a communication session, as provided by type 1 systems for classified information. That each sending device will create each key separately, using random numbers extracted from the noise of an embedded hardware noise source, such as the reverse offset diode, discussed above. Then, until the device signs the MCN or message control header, the recipient must be sure that every key message transfer and random numbers used to create it are reliable and non-repeatable. At the same time, those who insist on increasing security may require random material to be exchanged by both parties involved in a communication session, as provided by type 1 systems for classified information. That each sending device will create each key separately, using random numbers extracted from the noise of an embedded hardware noise source, such as the reverse offset diode, discussed above. Then, until the device signs the MCN or message control header, the recipient must be sure that every key message transfer and random numbers used to create it are reliable and non-repeatable. At the same time, those who insist on increasing security may require random material to be exchanged by both parties involved in a communication session, as provided by type 1 systems for classified information. Then, as long as the device signs the MSN or control header of the message, the recipient must be sure that every key in sending the message and the random numbers used to create it are reliable and non-repeatable. At the same time, those who insist on increasing security may require random material to be exchanged by both parties involved in a communication session, as provided by type 1 systems for classified information. Then, as long as the device signs the MSN or control header of the message, the recipient must be sure that every key in sending the message and the random numbers used to create it are reliable and non-repeatable. At the same time, those who insist on increasing security may require random material to be exchanged by both parties involved in a communication session, as provided by type 1 systems for classified information.
So far, in the present description, the sender is described as creating message transfer session keys based on the recipient's public encryption key contained in his escrow certificate but not based on random material obtained from
25
41387
However, during the communication establishment phase, agreement with the sender about receiving a deposit from the recipient, however, creates a new problem. The recipient cannot just be allowed to format the Diffie-Helman intermediate number and send it to the sender to use when creating the message transfer session key, because after this the recipient can no longer use the deposited private key in his secure device for decrypting messages because their connection cannot be monitored by law enforcement agencies. Existing successes in the application of the deposit scheme require that the sender and the recipient cannot read the message without using the registered secure device.
In order to allow a situation in which both the sender and the recipient enter a random material into the key of the transmission of a message before establishing a connection, it is possible to modify the original key exchange protocol so that the probable receiver device can generate a new one-time secret number Diffie-Helman, separately and independently of this beneficiary’s deposited private key, which will be used to calculate the new intermediate number, which will, in turn, be sent to the sender for olzovaniya when calculating the re-cottages message session key to encrypt the private key soobscheniya.Deponirovanny dolzhenvse recipient still be used for the formation of pro-intermediate numbers (included in the MCH) and odnora-zovyh session keys that are used dlyashifrovaniya different parts of the SIT. This modification requires, however, that the formation of a new secret number takes place in the device of the probable recipient, that this new secret number remains inside the protected device and that the new intermediate number is signed by the device of the probable receiver before being sent to the sender's device the purpose of certifying that a new one-time secret number is indeed protected and retained in the recipient's device. As before, the device sender generates a new secret number that is separate and independent of the sender’s private key deposited and, using the new secret number and the new intermediate recipient number, creates a transfer session key to decrypt the message. The sender's device will also use the new sender number of the sender to form the new sender's intermediate number, which will be sent to the recipient's device as an MCH element for conversion purposes. In this method, the message session key must, therefore, include a random material contributed by the sender and the recipient, if desired.
However, due to the fact that when the modified key exchange protocol is used, the recipient and the sender use the new personal keys of Diffie-Helman for each message, the sign of the deposit is still
“disappears” because law enforcement and corporate governance will never be able to obtain these one-time message transfer keys from depositing agents. Therefore, the requirements of the deposit system and the interested community require that, as before, the key of the message transfer session is transferred to the MST. In practice, in order to ensure equality of listening opportunities, all listed above as parts of the MNPol remain as such. The field transfer of the session key to the sender (which is the only way to read the message for the listening sender of representatives of law enforcement agencies) must still be included in the SIT in order to preserve the principle of equality of listening opportunities. The message session key will be encrypted in the MCH, as before, using the public key to encrypt the sender, which law enforcement agencies still have access to. The new intermediate number of the sender, as before, will be transferred to the recipient as the first element of the SIT, in order to allow law enforcement agencies to listen to the recipient and calculate the session key of the message transmission. Thus, in order to be able to use the Diffie-Helman interactive key exchange technology, this protocol requires that a new intermediate number be created and signed by this device, and a new intermediate number of the sender added by the MCNN is not used instead of the previously established key transfer methods, as this is for the community concerned (law enforcement agencies, employers and others) are the only way to read the message. This method, however, cannot be economical for operations, excluding telephone conversations in the dialogue mode, network operations or operations with a dial-in, since the device must remember too much, that is, special intermediate numbers for each correspondent. This method can, preferably, be used for full-scale communication, for incoming registration on the IT network. e. when a real-time conversation is required. Preferably, use in-line communications, for incoming registration on the IT network. e. when a real-time conversation is required. Preferably, use in-line communications, for incoming registration on the IT network. e. when a real-time conversation is required.
The headers of the community concerned. Usually, the SIT will be placed in front of the
as a message header. In many current e-mail and junk e-mail systems, several recipients are able to read one encrypted message using the MNS transfer option of the MCH device, as discussed above, by encrypting the message transfer session key using the RZA encryption key of each the recipient. This means that when several recipients are scheduled to receive a single encrypted message, the MSN header may include, for each intended recipient, the name of the intended recipient, followed by the message session key, encrypted with OA for
26
41387
each intended recipient using the recipient’s public encryption key. Thus, each intended recipient can place their input message in the MCH header, decrypt their copy of the key to transmit the message, and read the message. Even with several intended recipients, the truth of the MCH is ensured at both ends of the connection: at the end of the sending, the MCH output is provided by the internal logic circuitry of the sender's device, i.e. by the requirement that it create a valid MCH before the message is broadcasted; at the end of the reception, the correctness of the MCH is ensured by verifying by the recipient of the authenticity of the digital signature of the sender's device. As noted earlier, due to the fact that copies of the message key for recipients are embedded in the SIT, no recipient will be able to decrypt the message,
According to this formatting concept, the MCH can be formatted as shown in FIG. 25. As in the case of the use of the preceding SIT formats, the authenticity of the MCH is guaranteed by a digital signature of the sender device 258. In addition, as before, the deposit certificate numbers of the sender and recipient are encrypted with the public encryption keys of the respective main encryption centers 251, 252. In this format, however, signed by the device of the sender, the MCH becomes a modified "recipient list" that is more flexible and easier to read, compared to the way the modern encrypted system operates. ema mail. So, for example, the names of the sender and recipient (or identifiers or addresses of systems) are now shown in the MCH 253, 254 in an unencrypted form. Although this violates the anonymity of the sender and the recipient, in practice it is difficult to send messages via the e-mail system without supplying messages with the names and addresses of the senders and recipients. Therefore, the loss of privacy is great. In addition, the names of the sender's and recipient's employees are 255, 256 (or assigned identification symbols, such as a tax number or a number according to the universal data numbering system )υΝ3) are also shown unencrypted, which greatly simplifies the search duties assigned to the security service. messages sent and received by the appropriate staff. On the other hand, instead of leaving the blocks with the sender, receiver and co-worker names unencrypted, these items can be read with the same success as an unencrypted "sender", "
to decipher and read only those parts
SITs that are intended and encrypted
for him.
In addition, this format is the SIT, shown nafig. 25, allows access by possible divisions within the organization of the employer due to the allocation of secondary lines of the employer (a, b, etc.). In the case of the employers ’concern for ensuring secrecy, the SIT can read the line“ the unit of employees of the sender b ”unencrypted, as discussed above, and contain a valid ID of the company’s division in the encrypted section. Since each element of the MSN has its own designation, there are no restrictions on the number of employees having access; all of them become in a certain sense authorized "recipients" of this message. In addition, unlike previous formats of the MCH, this format of the MCH may include a session key for the transmission of a message, 257 is encrypted directly for the employer, so the employer does not need to contact the main deposit center or agents in order to receive the session transfer key to decrypt the message. This format, although it destroys the employee’s hope of keeping secrets in the workplace, may allow employers to check or restore files of their employees with minimal effort.
In order to create an MSN in this format before sending a message, the sender must first obtain all the necessary names and codes and public keys of the intended recipients and their employers. This information can be extracted from the certificate of deposition of the beneficiary and from his own certificate of deposit. However, in order to generalize this approach and make this information available to the user who wants to send a message, the main deposit centers should include in the standard certificate the deposition of each user, as discussed above, the assigned identification or code number and the public key of the shipping file as his employer as well as any division of the employer. The placement of the certificate of deposit may be indicated using repeated subgroups to effectively use the variable numbers of members of the “interested community”. Each member of the community concerned should have an identification number unique to it, an encryption public key, and possibly a command code (or policy code, as discussed below), instructing the sender's device how to encode the MCH input of this member. The command code can include items of choice, giving the sending device the possibility of including: (1) an identification number assigned only to this party, either unencrypted or using a conditional value, for example, "employee"; (2) placing the key of the message session on a coded or uncoded section;
27
41387
fake number on the coded or non-coded section and (4) placing the time stamp or random number in the beginning of the coded or non-coded section. These (and possibly other) command codes can be labeled as masking digits. Side lists (and / or their codes), their public encryption keys and command flags should inform the sender's device how to format the parts of the SIT intended for the interested community in accordance with the wishes of each party regarding the partial or complete anonymity. It is assumed that, in practice, many members of the interested community will not be concerned about the issue of anonymity, since it will be much easier for them to find and identify the messages of their employees when they keep their own names and identification numbers open. .
Decryption by recipients.
When the intended recipient takes
encrypted message 191 and the field MCH 192, it is necessary to perform several operations, shown in Figure 19 and are necessary for the recipient to read the message. First, the receiver must load his own valid certificate of deposit 193 into his crystal 190, since in the preferred embodiment of the present invention, the crystal will not be engaged in deciphering without it. Typically, the certificate of deposit of the recipient must be stored in the device’s memory, having been previously verified. Then the recipient loads the 190MSN 192 and the deposit certificate 194 from the sender, which also contains the key of verification of the open signature of the sender’s device (if necessary with the appropriate certificate of 195 system, national or global authority). The receiver's 190 crystal verifies the sender’s escrow certificate 194 to verify that the sender’s private key has been deposited. This is done by using the manufacturer’s public key to verify the manufacturer’s signature on the device certificate or, if necessary, the signature of the system authority on the deposit center certificate and authenticate the depositor’s signature on the sender’s deposit certificate. In the preferred embodiment, the public key of the authority managing the system is used to directly verify the certificate of deposit 195. The recipient's crystal then checks the signature of the SIT before proceeding to verify that: (1) the sending device is verified, (2) the sender's key is deposited, as already verified by the sender and (3) the MCH 192 is valid, i.e., the MCH has the required format and contains all the required information. This is done by verifying the signature of the device of the sender, the signature on the certificate of the manufacturer of the device of the sender and, if necessary, the certificate of the governing system of the body of the manufacturer. Public keys are made
The driver and system manager can be embedded in the receiver's 190 crystal in order to facilitate this verification process. In the simplest case, the recipient needs only a one-time confirmation of the authenticity of the certificate 194 of the deposit of the sender, as compared with his own built-in public key of the manufacturer or the key of the commands of the authorized subject of the system. As soon as they prove to be valid for a particular sender, the recipient need only use the previously verified public key of the sender to confirm the signature of the MCH, which leads to a single confirmation of the signature on the message. If either the certificate of the sender 194 or the MCH 192 is invalid, the recipient's crystal does not decrypt the message. And finally
Description of the actions of law enforcement agencies.
In order to intercept and decrypt messages coming to and from a particular user, law enforcement agencies must have permission or a court order to track the user’s communication lines. The court resolution will likely include: (1) the date that the listening has started and the time when law enforcement agencies can start listening on the user's communication lines; (2) the date of "end of listening" and the time after which law enforcement agencies cannot listen to the user's communication lines, and possibly (3) a transitional period after the date of "end of listening" during which the law enforcement authorities can save the user's personal key exclusively for encrypting previously intercepted messages but not to intercept and track any additional exchanges of messages of this user. When tracking the user’s sender’s communications, law enforcement agencies intercept the message and find out by the SIT the name and host country of the sender’s main deposit center in order to determine if they can request the sender’s private key. Then, law enforcement agencies file a court and SIT permission from the intercepted message to the sender's main depot center, which uses its own key to decrypt the certificate number of the sender encrypted in the MSN. sending agents send-la
28
41387
the sender’s device, which later will be required by law enforcement in the decoding process. Then a representative of the law enforcement agency contacts each of the sender’s depositing agents and presents them with the sender’s name and order, receiving from each depositing agent a key split sent to him by the sender. Since the preferred method of intercepting the encryption of the encrypted messages by the law-enforcement agencies is agreed in the application of the decoding unit described below, the requirements of the law enforcement agencies to the depositing agents will also include public key-shi frovaniya decoding unit law enforcement authority so that the key fragments mogliby directly introduced into dekodiruyuschiyblok law enforcement agency, and not handed over to representatives of the law enforcement agency. Each depositing agent sends the key fragment of the law enforcement unit in its possession in the form of an encrypted message, including the date of "start listening", the date of "end of listening" and a possible "transition period", so the decoding unit can implement the conditions recorded in the order. The decoding block then decrypts the encrypted messages containing the key fragments, combines the key fragments and uses the sender’s private key to get the key session for the communication system, the key message being encrypted by the sender in the SMS in the form of a message sent to himself. to the sender and from him
A similar procedure is used to track the recipient’s communication channels. Law enforcement agencies find out from the SIT of the intercepted message the name and country of residence of the recipient's main deposit center and then submit a warrant and SIT from the intercepted message to the recipient's main deposit center, which uses its private key to decrypt the recipient's certificate number encrypted in the SIT. Using the number of the certificate of the recipient, the main center of depositing of the recipient searches for the name of the recipient and the names of his depositing agents, and informs them to the representative of the law enforcement authority. Then the representative of the law enforcement agency comes into contact with each of the depositing agents of the recipient and presents them with the name of the recipient and the order.
by block. The decoding unit then decrypts the encrypted key fragments, combines them, and uses the recipient’s collected private key, along with the intermediate number of the sender, which is located at the beginning of each MCH, to obtain the session key for the communication system. The de-coding block can then track and intercept messages sent to and from the recipient only during the pro-listening period specified in the order, and can continue to decrypt these intercepted messages only until the end of the transition period specified by the order.
In another embodiment of the present invention, the format of an encrypted message with a fragment of a key from each depositing authority sent to the decoding unit of the right-guard bodies may have the following form:
User certificate number
Private Key Fragment: X (i)
Date and time to start listening
Date and time of the end of listening
Court-approved transition period (days / hours)
Date and time (of this message with the splinter key)
Signature of Deposit Agent
[Certificate of Depositing Agent].
In this format, all information except the certificate number must be encrypted with the encryption key of the decoding unit. Since the messages with the key fragment from the de-agenting agents are encrypted for this particular decoding unit, no user or decoding unit can read them. In addition, the dates and times of the “start of listening” and “end of listening” tell the decoding unit when to start listening and decoding messages and when to stop listening; the transient periodises to the decoding block an additional, established time period for decoding any backlog of previously intercepted messages, after this time period the decoding block stops decoding and must erase the subject's personal key. the decoding unit can be used to decrypt the intercepted user messages up to the date specified in the order, and at this moment the decoding unit and the built-in timer in it prevent any further decoding. The decoding block may also refuse to process messages with key fragments in which the date and time exceed twelve (12) hours (or any other specified time period) or with the expiration date and time of termination of the action.
The use of decoding unit.
In the preferred embodiment of the present invention, law enforcement agencies use a special, protected from unauthorized interference decoding unit to intercept and decrypt messages of the users being listened to, according to the designated designated and controlled
29
41387
conditions. An example of a decoding unit and the process occurring therein is shown in FIG. 20. Decoding unit 200 is a protected device of a similar design within the system of protected devices that is the subject of the present invention and, therefore, can ensure compliance with various conditions in order to prevent unacceptable actions of law enforcement officials. The decoding unit 200 has the device's private signature key, the manufacturer’s built-in certificate, and the manufacturer’s public key certificate 202 for the signature public key corresponding to the device’s private key signature. In addition to the manufacturer’s certificate 202, the decoding unit may also include a certificate 203, issued by a law enforcement agency (either on its behalf) or by the security department of a corporation (or on their behalf), the owner of the decoding unit, which both certifies or certifies the connection between the decoding unit and the law enforcement agency or the security body and confirms that the decoding unit is exclusively in possession and under the control of this authority. The decoding unit 200 also has the ability to create a pair of public and private keys, similar to a regular user chip, which is the subject of the present invention for encrypting and decrypting control and control messages received in the decoding unit. The decoding block 2θ0 also has the ability to securely store its private key and issue the corresponding public encryption key in the framework of a self-signed certificate201, with the certificate of its device 202 signed by the manufacturer. The ability to create (and use) a pair of public and private keys allows deponding agents 206 to listen to the user, after submitting to law enforcement officials by representatives of the law enforcement agency, to send the user’s communication channels fragments of the listener’s 204 key to the decoder using the public key encryption of the decoding block, and allows the decoding block to decrypt these key fragments using its private key encryption. However, unlike the ordinary user crystal, which is the subject of the present invention, which deshrupts the message and returns the decoded result to the user, the decoding block never gives the private key of the user being listened to to the law enforcement authorities.
In accordance with this, in order to fulfill its obligations as a secure device and enforce the restrictions on the date and time specified in the permission to hear
The decoding unit 200 must also contain a reliable, calibrated and certified date and time timer 205. The manufacturer of the decoding unit certifies and authenticates the authenticity and calibration of timer 205 when the manufacturer issues a certificate of 202 devices with a list of known device characteristics. When decoding unit 200 receives from key depositors 207 a split of key 204 with an indication of time constraints (based on the order), before or after which the order is invalid, the decoder unit 200 uses its internal timer 205 to check if the valid order continues filed by law enforcement agencies. If the order is not valid, the decoding unit will not listen or decrypt the messages of the user being listened to. If the order has expired (and any period related to the non-transfer period) has expired, the private key of the user being listened to is erased and will not be restored by the decoding unit, according to this order (unless a new order is issued for a new time period). It should be noted that although verified timer 205 can be used in the ordinary crystal user, which is the subject of the present invention, it is necessary in the decoding unit 200 in order for the decoding unit to be able to enforce the restrictions on the date and time nor, specified in the order to listen in. However, the user of an ordinary crystal can contribute to the observance of time limits by calibrating its crystal timer. If the user’s timer is not calibrated, The MCH user device created during the session will contain a zero value in the field for the timestamp. In this case, the decoding unit intercepting the connection will be able to comply only with the date of listening termination specified in the order, refusing to perform the decryption after the expiration of the order period. After that, the decoding unit cannot ensure observance of the start listening data, because prior to the order, while the order remains valid, the order allows decryption of all the MCHs presented with zero timestamp values, even if they were intercepted by the date and start time of the interrogation specified in the order . However, if the timer user is calibrated, the decoding unit of the law enforcement authorities may refuse and refuse to decrypt all the MCH, containing a valid and reliable timestamp with the date and time preceding the date and time of the beginning of the audition specified in the order. Most preferably, the decoding unit according to the present invention decrypts only those messages that actually have time stamps related to the time periods specified in the order. It is assumed that an additional guarantee against a possible violation by law enforcement agencies of specified periods of time may
thirty
41387
to encourage users of the crystals that are the subject of the present invention, to maintain their crystals in a calibrated state. Indeed, in cases where the system is used to encrypt a large number of messages in the data accumulation system, the observance of the time frame for a subsequent warrant or order for the submission of documents may be highly desirable, since otherwise many messages that are not subject to verification may be subject to verification. under the legal framework in the warrant.
Features of monitoring the activities of law enforcement agencies.
In the case of a deposited encryption system, there is the likelihood of easy bribing of law enforcement representatives in order to obtain cryptographic keys that protect information that has great economic value. For example, members of a large criminal organization may be able to steal a number of valuable industrial plans of a certain company, first by illegally listening to the company's communication channels in order to get some message headers and depositing agents, and then bribing low-paid employees -tsii, inviting them to request a warrant in connection with the investigation of the drug trafficking case, in order to obtain an agent’s decryption key from the depositors and, finally, using the private decryption key to steal plans.
One such security measure for a protected device is the use of an internal counter designed to assign a number to each control message header, and the account will be incremented sequentially after each access case. The sequence number of the message (Μ3Ν) can be placed in each encrypted message header in such a way that it will not be visible to others. This can be achieved by encrypting the number either (1) using the sender’s public encryption key, along with a copy of the message transfer session key assigned to the sender, (2) using the public key to encrypt the depositing agent of the sender or the recipient, or (3 ), preferably at leastthe sender, the recipient and their depositing agents, and possibly all the members of the community concerned. However, the sender’s coking agent may, depending on the approach, prefer to place the unencrypted sequence number, which is
going from the need for saving space and
low risk to reveal it. It is very important
run duplicate numbers of managers for
message heads, and, if possible, do not
allow gaps in numbering.
Another security measure may be to allow the user to include an optional secret “title line” in the control header of the message. If a user fears illegal listening on the basis of incorrectly issued orders, he can code a short header, such as “Plan Νο. 123”, to turn his attention and the attention of others to the content of the message. On the other hand, the user can simply maintain his own accounting log (in the software of the e-mail system) with indication of the interconnection and sequence numbers of the messages assigned by the device and user-assigned headers. To save space, the title line can have a zero length, if, as often happens, no title is entered.
The third way to protect is to add to the signed part of the control header of the summary or hash of the content of the message in order not to allow neither the user nor the law enforcement authorities to assert that the content of the decrypted message differed from the actual message sent. This means, for example, that the user will not be able to later replace with a harmless message a previously sent message regarding a drug deal, or corrupt law enforcement officials will not be able to replace the highly valuable industrial plans that these representatives prey on. , a message about a drug deal or a harmless message.
These safety measures can be used as additional safety measures. First, the sequence number of a message generated by the sender's device can be used to track the message both by the sender and the recipient, as well as by the law enforcement and judicial system. While law enforcement agencies can access, for effective control, during periods of active prosecution of criminals, and although the judicial system is not always able to carefully analyze the requests of law-enforcement agencies for the issuance of permits for listening, it is necessary in the future tionary be taken to check the results of the listening, or listen to each of the cases, or listening to a random, or those plays, which for inymprichinam seem unusual. For this reason, the protected device of law enforcement officials, i.e., the decoding unit, is modified to include a secret internal register of sequence numbers of messages and summaries of messages (and title lines, if any), which can be heard and can be read by law enforcement agencies. The electronic authorization sent to the decoder unit by the depositing agents of the listener along with the copy
31
41387
Kami user key may also include an open encryption key and the signature of the court that gave the order. As a result, the decoding block can respond to the requirement to print a log of the record numbers of the messages of the title lines, perhaps by encrypting it with the key of an appropriately authorized recipient, such as the court issuing the order.
In another embodiment, the decoding unit does not proceed to deciphering the intercepted messages until it receives a special court order corresponding to the key fragments received from the depositing agents. For example, messages with key fragments received from depositing agents that were encrypted using the public key of the decoding block encryption can be improved to include (each depositing agent) public key encryption and the signature of the court issuing the order. Or depositing agents can refer to the key fragments on the date the inomer (if any) of the order, and the decoding unit can then receive from the court the certificate of the open court key attached to the original permission to listen ivanie For example,
Name or identification number of the main deposit center
Certificate number of the user being listened
Name or identification number of the court
Order number (if available)
Date and time the order was issued
Date and time to start listening
Date and time to stop listening
Maximum number of messages (facultative)
[Signature of the judge]
Judge's certificate
The certificate of the body controlling the judge (for example, a court, etc.).
The depositing agents can then "re-certify" the public encryption keys and the court signature for the decoding unit by including encrypted messages with a fragment of the key of the defining agents to the decoding unit, additional information that must be presented in each fragment of the key from the every-day agent:
Name or identification number of the main deposit center
Certificate number of the user being listened
Name or identification number of the depositing agent (who sent this message with the key fragment)
Name or identification number of the court
Court encryption public key
Court Signature Public Key
Order number (if available)
Date and time the order was issued
The maximum number of messages (
culturally)
Signature of Deposit Agent
[Certificate of Depositing Agent].
Thus, the decoding unit receives confirmation that all messages with the keys of the key came from the same judge and on the basis of the same order.
The fact that the decoding unit also has public encryption keys and signatures allows the judge as a verification measure after listening to warn inappropriate, illegal and corrective behavior of law enforcement representatives to request and receive (confidential) a log of all message sequence numbers and the title lines of the messages intercepted and decoded by the decoding block during the period of listening. In addition, the decoding unit will not delete, erase or reuse any part of the memory intended for recording the listened messages until the decoding unit receives a separate order from the judge or the court, certified by the previously obtained public key of the signature and giving permission to the decoding unit to perform such an operation. Such an order will be issued either due to the fact that the court has already received the requested log from the decoding unit, or due to the fact that the court has decided that in this case no verification is required. If the memory location intended for recording of listening messages is filled, the decoding unit will no longer decrypt messages until the registration log is sent to the judge or the court has received an order signed by the court that allows the decoder to delete the log of the listened messages soobscheny. Law enforcement can continue to intercept new messages, Waiting for a reset of the log of the listening messages, although the newly received messages will not be decrypted until such time as the entire message log has not been sent for review. The decoding block will also be able to notify law enforcement officers that the log of the messages being listened is close to being filled so that they may require unloading of the control log of message registration so that the decoding block does not stop decoding. These actions and communication operations can be fully automated and carried out almost instantly. The decoding block will also be able to notify law enforcement officers that the log of the messages being listened is close to being filled so that they may require unloading of the control log of message registration so that the decoding block does not stop decoding. These actions and communication operations can be fully automated and carried out almost instantly. The decoding block will also be able to notify law enforcement officers that the log of the messages being listened is close to being filled so that they may require unloading of the control log of message registration so that the decoding block does not stop decoding. These actions and communication operations can be fully automated and carried out almost instantly.
Each data entry in the registration control log may contain, in addition to the summary, a second summary, which is the result of a merge and re-review: (a) a summary of the message and (b) the full text of the previous data entry in the log. This may prevent unscrupulous court personnel from adding and deleting individual journal entries, as well as changing them afterwards.
32
41387
condemnation This concept is reviewed in US Pat. Nos. 5,136,646 and 5,136,647, incorporated herein by reference.
As a final measure, the court may later require the law enforcement agency to submit the message headers and the full content of the summary of messages in the control log of the registration file received by the court. of the log of the number of the messages that were heard, which can be decrypted by the decoding unit before the log and the headers of the listened messages will be sent for inspection. Although this restriction will not affect the overall ability of law enforcement agencies to conduct an investigation, since the transfer of registration registration to a court for verification takes place almost immediately, it may be on the guard of the court in the event of unusual circumstances. In special cases requiring more strict control,
Thus, if: (1) and the sender and the recipient provide the assignment of ordinal numbers to the messages they send and receive, and also enter the corresponding title lines in the control message headers, or register messages in their local software systems, ( 2) and the law enforcement authorities and the court retain a complete record of the registration of each message decrypted by the law enforcement agency, and (3) each message header includes a summary of the message in order not to allow anyone of the parties to change the MSG-tions with the aim to disguise their actions, toprovedennaya after listening to deserve the trust-schaya check may allow the definition-sharing, whether there have been side-pravooh-enforcement authority any zloupotrebleniyaili corruption. Although this system cannot completely exclude the implementation of the scenario of hijacking the plans described above, the knowledge of the criminal organization that its actions can be fully verified by the court and the interested party may serve as a deterrent against unlawful police actions. You can also accept the rule that the law enforcement agency registers and submits to the court all the messages intercepted under the warrant and allows the parties to be heard to demand verification of the interception, especially when the problem concerns a commercial enterprise and the results of the interception were not made any criminal charges. that actions can be fully verified by the court and the interested party can be a deterrent against non-lawful actions of the police. You can also accept the rule that the law enforcement agency registers and submits to the court all the messages intercepted under the warrant and allows the parties to be heard to demand verification of the interception, especially when the problem concerns a commercial enterprise and the results of the interception were not made any criminal charges. that actions can be fully verified by the court and the interested party can be a deterrent against non-lawful actions of the police. You can also accept the rule that the law enforcement agency registers and submits to the court all the messages intercepted under the warrant and allows the parties to be heard to demand verification of the interception, especially when the problem concerns a commercial enterprise and the results of the interception were not made any criminal charges.
Directional flow of information.
In communication systems with directional flow of information, such as a telephone call, in which
Each information exchange is represented by a stream of several message packets from two or more users, the sending device does not have the ability, as part of the MSN, to hash and sign the entire message. Although it may be possible to send an MCN with each information exchange packet, such actions can be very costly in terms of time spent on processing, and the required network bandwidth. In connection with this, the SIT should be transmitted only once, during call setup. The preferred way to handle continuous streams of encrypted data is to designate the sending user as the "sender" and to transmit the MCH at the beginning of the communication session, including, as before, the sequence number of the message ("3") and the hash of the first packet (if there is ), signed by the device. Then, the sender device can form a series of consecutive numbers of individual packets ("3"), starting from zero at the beginning of each communication session. For all subsequent de-package packets, you only need to hash and sub-write this particular packet, and enable (ipodpisat) the hash, Μ3Ν (one for the whole message) and 3Ν packet. The called party will perform similar actions with respect to each packet it sends, assigning the caller's connection number to the session омер3Ν and sequentially numbering its packets, starting from zero and stating the device signature of the called party on the group including the hash, Μ3 that caused the party and 3Ν called party, thus forming a “packet control header” (PCH). The device may optionally include the designation of the current time as a time shift with respect to the time of the beginning of the session (in seconds or milliseconds), which is already proposed in the previously described versions of the MCH. This allows you to more realistically restore the call picture.
In order to further distinguish between the packets of the caller and the called party after the session, it would also be desirable, based on a simple coding scheme, to include the code of the party participating in the communication session (CPC) in the number assignment form to the parties involved in the session communications, such as the calling party = 0, the called party = 1, as well as the higher number numbers to any additional parties to the participants in the same encrypted session. Alternatively, instead of a CPC, it is possible to use a uniquely possible identification number, such as the serial number of the device, the serial number of the device, plus the manufacturer's identification number, or the digits of these numbers.
These methods can also be summarized as a method for creating a key for a multi-party session. For example, the caller can create a session key and use this key to initiate simultaneous calling of several subscribers using the P3A key transfer system. After the first two sides (the caller and the called side), the SIT will be separate for each additional party.
33
41387
The caller’s device will consider a multi-party call as separate calls or as the only call having a single session key, but multiple CPCs. In this case, each called party must be responsible for using the “3” of the calling party because of compliance with its CPC and “3”. On the other hand, based on the use of conventional methods for obtaining a two-way communication key (such as Diffie-Helman methods), there may be circular calls where the central side (for example, the system operator) places all calls and performs real calls. timescale decryption and re-encryption of packets on each side for all others. The central party may also be the person who commutes with the next called party, and in this case, the packets of this called party must be encrypted with the device of that person and then re-encrypted using the session key (s), which the called party uses to communicate with the other party (or parties). See also regarding the use of the Diffie-Helman method with three or more comprehensive work of V. 3eppeieg, Arrііeb SgurЇodga-rpu, b. Shieu 1994, p. 276.
A packet control header (PCH) may be composed as follows:
Μ3Ν initial caller
User code as the party taking part in the call (CPC) (caller = 0, it. P.)
User package sequence number (пакета3Ν)
Time shift relative to the moment of call arrival (msec)
Hash (of this package)
[Signature device].
It may be preferable not to send a PCH with each message packet, which is associated with severe overloading of some systems that use short packets, but instead send packets only periodically. This is close to the mode of operation known as “sliding windows” in network systems communications, when placing in order and repeating packets are performed not for each packet, but only for a large number of packets. Usually, such systems dynamically adjust the "window", or the number of packets sent between instants of detecting errors, based on the noise on the line, i.e. making the window large for a clean line and making it small for a line with a high level of noise, which entails packet duplications due to inaccuracies. If the errors occur frequently, a small window may require the sender to re-send only a small amount of data; In case, if the errors are rare, the check can be rarely performed, although, if an error is detected, the cost of resending the data will be high. Packet control headers can be directly enabled throughout the sliding window of the communication system, thus providing the necessary opportunities for checking the actions of law enforcement agencies to the level of the package while simultaneously maintaining
storage bandwidth modern
communication network.
To further increase the controllability of the listening process, it is desirable to positively mark the end of the communication session with a specific special package. This package can be automatically sent before each device disconnects from another device without users knowing it so as not to allow both users and representatives of law enforcement bodies to argue later that the conversation was or was not completed, although the opposite was true. by issuing instructions to each device to receive from the human user an input signal "now I want to disconnect", as a result of which the device must send a packet "prepare to disconnect ", which then stimulates another device (s) to perform the same operation.
Time Stamp Device.
Another distinguishing feature of the present invention in its preferred variant of realization, as discussed above with respect to the decoding unit, is a reliable and counter-tampering device that can be timed (or add) time stamps with a digit a signature (or data structures containing such timestamps) that can be considered by third parties with confidence. Such devices for setting time marks on written in U.S. Pat. Nos. 5,001,752 and 5,136,643 issued to Addison M. Fisher. In the preferred embodiment shown in FIG. 21, the device (or subsystem) of setting the time stamp 210 may be calibrated and enabled only by a trusted person, such as the manufacturer or someone, The manufacturer’s credibility, in much the same way as a postal meter, can only be set up by the local office of the United States Postal Service and, from this moment on, can be trusted by the public of the mail system for issuing postage stamps only for the amount paid. After calibration, a device (or subsystem) of a simple timestamp 210 will respond to the "time setting" 211 command (or recalibration) only when the command is signed by either the manufacturer or the entity having the manufacturer certificate 212 or from a person trusting the manufacturer, indicating that the subject has been entrusted with setting up and calibrating the device (or subsystem) to set the timestamp in the main device.
34
41387
physically disposing of the device and immediately erasing the time setting command 211 to eliminate the possibility that the owner of the device will be able to get the command to his own disposal and reuse it later to "turn back" the watch of the device.
While being calibrated, and throughout the time while it remains intact, the timestamp device 210 will add timestamps 213 or full time information in the structural fields of the data, based on its internal clockwork, signing 214 the resulting structures data with the private key of the device and supplying them with the manufacturer’s certificate 215. If the main device turns off the power, an unauthorized interference will be made, or a shutdown command will be received, TVO prostanovki time metokprekratit their checkboxes. In this case, in order to avoid violations of the performance of other useful functions that do not require the mandatory presence of reliable timestamps, the device for the timestamping will work according to a predetermined scheme, such as filling in the time stamp field with an unmatched "zero" value, such as one binary zero or binary one (or according to a similar condition) in cases where the structure data field provides for the introduction of a time mark. However, in cases where the data structure field or the main device requires the creation of a true timestamp, such as in the case of the decoding unit of the law enforcement agencies, in the case that this device has stopped issuing timestamps, those functions of the main device that require timestamps do not will be fulfilled; in the case of a decoding block, the blockade will decrypt the intercepted messages. In order to avoid or minimize the likelihood of situations with the power off the main device, each secure timestamper should preferably be equipped with its own separate long-life battery 216 designed to be used only in hours with an indicator that warns the battery from "depletion" and is designed to prevent power loss by timestamping the device before replacing the battery or by some means of preserving sufficient electrical charge (such as a cumulative capacitor, a slot for a second battery, or an additional external power source) during battery replacement operations.
For each time stamp issued by the time stamp device, it is possible to add a certificate of this device, you are given by the manufacturer (or another body that installs time) and confirms the quality and reliability of the time stamp clock. when it was last posted, as well as the expected error in time. When the recipient user receives the data structure with the digital signature of the primary
device, this recipient knows that if the time stamp field is filled with a valid value, the device signature and certificate confirm that the time at the time of creation, signature, and issuance of the data structure is correct. This confirmation is based on: (1) the reliability of the authority that last calibrated the time stamp, (2) the deviations of the clocks correspond to the tolerances specified by the manufacturer on the device certificate and (3) the ability of the clock to turn off in case of unauthorized intervention or power outage. The recipient also knows that if the timestamp field contains a "zero" value, the timestamp hours were not reliably calibrated at the time the device created Lo, signed and released the data structure. This information, concerning the checked characteristics of the device for the time stamping and its internal clock mechanism, it can preferably be encoded directly in the device certificate using a suitable encoding scheme of the determinative value. However, this information may also be derived from the manufacturer’s name and device type, which may be published by the manufacturer of the specification and performance certificate as part of the published “Resource Distribution Operator” during the issuance of a device certificate.
Such timestamps may also be issued by the device as part of other message processing operations performed along with the creation and decoding of the MCH. These time stamps can be added to the personal signature of the device user when the user signs another document or transaction using their personal signature key, which is securely stored in the device. The device must sign or validate the item with the user time signature label. -tel, or it can sign the entire block of the user’s signature (which includes a timestamp, also signed by the user, along with the resulting document hashing). The device can then pass the certificate in order to make the timestamp plausible and credible to a third party who knows the public key of the manufacturer.
Reliable improvement, replacement and re-tuning.
Another distinguishing feature of the present invention is a robust device protected from unauthorized interference, which contains an embedded open key of the manufacturer, a protected non-volatile memory area and a protected central processing unit (CPU), and can enhance or supplement in any reliable way any firmware. built-in manufacturer. The protected device provides improvement or addition, taking as input the data body containing a new or additional firmware
35
41387
a code that is suitable for this type of device and digitally certified by the manufacturer's signature, the signature guaranteeing the device that the new firmware code is developed, tested and approved by the manufacturer and that the device must therefore either: (a) cover one or more firmware versions a microprogram code, or (b) add a new microprogram code as one or several new subroutines in an unused part of the protected memory. In the preferred embodiment of the invention, the protected memory should belong to the type "P1_AZN" and can save the information contained therein regardless of the power shutdown, but can also be erased by the device (albeit relatively slowly) and, if desired, reused. Protected memory can also include any storage area of information (such as a disk storage device), either protected or unprotected from unauthorized interference, in which the code intended for improvement or addition can be stored in an encrypted form, the decryption key of which is known only to a protected device. By storing programs in an encrypted form, the device effectively protects them from being changed by anyone who does not know the decryption key. When a device receives such a signed body of a new micro-software (or software) code, the user enters the code, along with the signature of the manufacturer, and issues a command to the device to "improve the firmware of the process". The device then verifies the manufacturer's signature, using the manufacturer's public key for this, which was built into the device at the time of manufacture. If the manufacturer’s signature is correct, the code is accepted and the device performs the necessary improvement.
The process of reliable improvement of the firmware of the protected device described above may further be extended to involve authorized third parties wishing to upgrade the microprogram software related to the functions of the third parties, including such functions as a real deposit system key, which can be largely developed and implemented by the bank’s main deposit center, regardless of the manufacturer of the secured device oystva If the third party is embedded, the manufacturer may sign a firmware enhancement certificate containing the public key of the third party supplier of the firmware and transfer it to this third party. A third party can then work out test and approve replacement or additional firmware, sign them with a personal key of a third party signature and attach here your certificate for improvement obtained from the manufacturer. After such an improvement, the user must upload to
device as signed code subprograms, as well as the manufacturer's certificate for improvement, then issue the command "perform third party firmware improvement". The device should then verify the third party's signature on the new subprograms of the code with the manufacturer's improvement certificate, and then verify the improvement certificate with the manufacturer's public key embedded in the device during the manufacturing process. If both signatures are true, the improvement is considered to be accepted and the device will perform the required improvement.
In addition to receiving commands to improve or supplement the firmware of a device, a reliable device against unauthorized interference can also receive commands to replace or supplement the public keys of the "commands" built into the manufacturing process. As was shown in advance, a secure device may have public keys, except for those that were built by the manufacturer during the manufacture of the device. Such public "command" keys may include keys from one or more deposit centers described in this invention. These built-in keys, including the keys of the manufacturer or other trusted third parties, can be used to check various certificates, such as certificates of certification, device certificates, certificates of improvement, certificates of the time setting command and others that may be presented in the device for exposure to it. In addition to relying only on public keys embedded in the manufacturing process, the device can also accept external commands in order to embed new open keys, replacing the existing ones. In order for the device to accept and store the public key of the third-trusted party’s private key in the closed area, the manufacturer places the new public key in the signed package (or certificate) with command data signed by the manufacturer and requiring the device to remove the certificate and save the designated public key contained in it. A special package can also indicate to the device, for which types of operations the new key is intended (for example, for use in key deporation, car rental, storage of medical information or other uses). After receiving the public key data packet from the manufacturer, the device must first check the manufacturer’s signature and then accept and place the new public key in the storage device, along with the restriction of using the public key.
The manufacturer may also provide for the embedding of the public key of the third party teams in time, both during the manufacturing process and later, as part of a package with command data, that one of the operations for which this third party key is pre-assigned is to replace its own internal open key verification signature of the manufacturer. Although this
36
41387
Replacing the manufacturer’s own public key is almost never required, there is a possibility that the manufacturer’s corresponding private key (for issuing device certificates and other commands for the device) may be stolen. A manufacturer’s private signature key may allow the thief to issue external commands, assert new values Depositing (doubtful reliability) and approving new persons who have the right to set time. On the other hand, and it is more incredible, the manufacturer’s personal key can simply be lost or destroyed, resulting in the possibility of issuing any valid commands later. Any of these events can be classified in terms used in computer systems like "catastrophe", and it can recall all devices released by this vendor. However, thanks to the present invention, it is possible to avoid or reduce the costs associated with such a recall by allowing a trusted third party to replace the manufacturer’s compromised signature key. If we assume that the manufacturer has already embedded the command keys of one or more third parties, either during the manufacturing process or later using the command data packet and included the replacement of its own public key in the number of actions that the third party’s public key can approve, then the manufacturer can contact this trusted third party and demand that it issue a packet with command data to all devices of the manufacturer, allowing the manufacturer's public key to be replaced providing thus for others and for others, saving potentially huge costs for the physical replacement of all physical devices. Since all device certificates issued by this manufacturer would also have to be replaced, this could be done by issuing each device a requirement to certify the device’s own public key signature. If the private key of the manufacturer is lost or destroyed but not compromised, all previous signatures remain valid, and the user is only required to submit his previous certificate in order to receive a new device certificate issued for the same information and signed with a new key from the manufacturer's signature. Then, the manufacturer should return the new certificates of the device (most likely through an online operation or by e-mail).
The inclusion in the secure device, which is the subject of the present invention, of the mechanism for replacing the manufacturer’s public key or any other verified public key, reduces some systematic security risks that
associated with the use of basic public keys throughout the system. E then provide boleeshirokoe use purely hierarchical mo-DeLay confidence, which usually allow boleekorotkie and simple way of certification, itrebuyut fewer certificates, less effort to determine what the mid-tifikaty use, and less expensive vremenina calculations when verifying signatures.
Owner-controlled re-migration.
As described above, the user also has the ability to reconfigure at any time after manufacturing his device with respect to his own pair of user encryption keys. The user does this by issuing a firmware command to a protected device to execute certain operations of the key depositing method, i.e., create a new pair of personal and open keys, send the key fragments to the depositing agents and, ultimately, receive a new certificate of deposit from the main deposit center. However, it is also desirable to allow the employer or sponsor of the user (or the owner, if the user is a different device or process) to control the processes of setting up and reconfiguring in order to: (a) make sure that the user chooses such depositing agents, which seem acceptable to the working dater, and (b) be sure that the selected dying agent, as the true owner of the device, will remain aware of these selected de-agenting agents, and he can therefore snatch the user's key fragments from the depositing agent without the need to obtain a pre-order or court order. The employer may request access to the keys of a specific device for a number of reasons, such as conducting an internal investigation or recovering encrypted ownership of the information after the loss, theft, or destruction of the corresponding device. The employer may also need to re-configure the device for a number of reasons, for example, for a device whose previous encryption keys or signatures were compromised or deleted, for a device transferred to another employee,
In a preferred embodiment of the invention, the secured device is pre-configured by the manufacturer in such a way that it does not initiate the creation of a key and the deposit process until the device first receives the certificate of the owner of the device 220, such as shown in FIG. 22, including a permanent serial number 221 of this device and signed 225 by the manufacturer. The certificate of the owner 220, issued by the manufacturer at the time of purchasing the device to a corporate customer, also contains the corporation 222 name, identification number 223 assigned to the corporation (such as the Employer Identification Number Tax
37
41387
management (ΕΙΝ) or Dana and Brad Street number (ϋυΝ3)) and a public key 224 verification of the corporation signature corresponding to the signature private key stored by the corporation, and intended to be used to confirm the reconfiguration commands and other commands issued by the corporation to the device. After receiving this information, the device will accept only those re-configuration commands and other commands that are signed with the personal key of the subscriber of the corporate owner corresponding to the public key contained in the certificate holder of the device.
As shown in FIG. 23, when the employer (device owner) wishes to reconfigure the device 230, the employer issues the device 230 with a signed command 231, including: (1) serial number 232 of the device, assigned identification number 233 to the owner, (2) naming the depositing agents 235 and of the 234th Deposit Center, (3) the date and time of issuing the command for reconfiguration, (4) the date and time of command expiration of the instruction misconfiguration 236 and (5) the assigned command reconfiguration serial number 237, and signs the command using the personal key 238 employer. After receiving a valid certificate 239 of the owner and a valid team 231 for resetting the crystal in the secure device 230, first checks the manufacturer’s signature on the owner’s certificate 239 and the employer’s signature on the team 231 for reconfiguration. The secured device then completes the process of creating the key and depositing, as before, the identification number 233 assigned to the owner to each depositing share package and sending the equity packages only to depositing agents 235 specified by the employer in the reset command 231. Subsequent repetition of these commands (which may be electronically given) may be limited by designing the device in such a way that the device saves in the non-volatile memory of the order number of the last few received commands for reconfiguration and refuses to execute these commands again. If the timer is maintained in order, the subsequent repetition of the commands for reconfiguration can also be limited simply by issuing a command to the device timer to observe the command expiration dates and times specified in the command. In the preferred implementation, a device with an uncalibrated clock should refuse to perform a reconfiguration command that has non-zero values for the expiration date and time, but will be valid if the date and expiration date are not stamped. The subsequent repetition of commands for reconfiguration can also be limited simply by issuing a command to the device timer to observe the command’s expiration date and time specified in the command. In the preferred implementation, a device with an uncalibrated clock should refuse to perform a reconfiguration command that has non-zero values for the expiration date and time, but will be valid if the date and expiration date are not stamped. The subsequent repetition of commands for reconfiguration can also be limited simply by issuing a command to the device timer to observe the command’s expiration date and time specified in the command. In the preferred implementation, a device with an uncalibrated clock should refuse to perform a reconfiguration command that has non-zero values for the expiration date and time, but will be valid if the date and expiration date are not stamped.
After receiving from the user of the device, a packet with fragments of a key (or a modified key) containing the identification number assigned to the owner, the depositing agents and the main deposit center must place this identification number in their
the relevant databases must then fulfill the requirements received by the owner to obtain access to the private key encryption. In the preferred embodiment of the invention, the depositing agents and the deposit center must each require that a share packet with a key fragment indicating the identification number assigned to the owner is also accompanied by a certificate of the owner of the corresponding device signed by the manufacturer. This certificate of the owner of the device will allow depositing agents and the main center of depositing to take into account the requirements for the provision of the key, signed with the private key of the signing owner corresponding to the public key of the owner’s signature specified in the certificate holder of the device.
In another embodiment, a secure device may be able to receive commands from the device owner to re-configure, change the deposit, transfer ownership and others without using a separate device owner certificate. The requirement to use a separate owner certificate to issue commands to a device is an administrative burden, because the owner must have certificates based on all the devices belonging to them and look for the appropriate certificate every time he wants to re-configure the device or send any other commands to the device. A more successful approach, as shown in FIG. 26 is issued by the manufacturer to the owner of a single certificate for the open key of the owner’s commands for this family of devices, by providing the seller with a set of public key verification commands 261 inside the device 260 when selling the device 260, and then creating a system based on the internal storage of these keys. At the time the device is initially sold by the manufacturer to the owner of the device 260, it is first recognized that the manufacturer’s certificate of the manufacturer’s certificate 262 is authenticated by using the manufacturer’s public key 263, which is built into the device by the manufacturer. If the owner's team’s open key key area 264 in the device is empty, the device will copy the owner’s open key commands from the owner’s 261 commands to the device’s open key commands 264 from the manufacturer’s owner’s certificate of the manufacturer 262. In the case, the device’s owner’s public key already exists the owner is trying to initiate in the device, the device concludes that the manufacturer sold the device to another person. Since each device will have no more than one owner, the ownership of the ownership of this device will be determined on the basis of the presence or absence in the device 260 of the public key of the owner’s commands 261 instead of (or in addition to) the previous concept of the certificate of the owner.
In case no owner's public key is built in, the device is considered as a single user device.
38
41387
a consumer with no restrictions regarding the re-configuration or transfer of ownership of the device; In this case, the device will consider the absence of a built-in key, the owner as a signal of the need to execute commands of use without calling up the rules discussed above regarding the reconfiguration, change of deposit and transfer of ownership. If in a proven device270, as shown in FIG. 27, the public key of the owner’s commands 271 is embedded, then the user’s commands for reconfiguring, changing depositing and transferring ownership 272 will not be processed unless 273 are signed with the corresponding signature 271 private key. After confirming the signature of 273 of the owner, the protected device 270 performs the deposit change procedure described above. In this way, The owner does not need to issue a certificate to the owner confirming his possession of this device when issuing commands to this device. However, signed owner commands must, of course, be limited to a numbered device or perhaps a certain class of devices whose number match this rule or pattern in order to prevent the transfer of these commands to each device belonging to the owner.
In addition, as shown in FIG. 28, the owner may issue a command to transfer ownership of the device to the device by replacing the original built-in public key with confirmation of the owner’s commands to others (from the buyer, the new owner of the device). The owner of the device sends to the device 280 a command 282 for transferring ownership, including the name of the new owner and the public key for confirmation of commands signed with the use of the private key of the command signature 283 of the current owner. The device checks the command on the transfer of ownership 282, using the public key of commands 281 of the current owner, replaces this key with the public key of the new owner’s 284 command and then executes only the commands of the new owner. In addition, the owner can also add another "secondary owner" , having built in the second open command key. This second public key for confirming commands must have a "rights" field indicating which command to execute which operations it is authorized to accept. Among these rights may be: reconfiguration, adding another owner, deleting the owner (as in the case of a conditional sale), removing all owners and returning back to the position of the consumer who has no definite owner. However, these delineated rights may include more or less rights, or the same number of rights as the original or primary key of confirming commands, including the right to replace or delete the primary key of the owner’s commands. Among these rights may be: reconfiguration, adding another owner, deleting the owner (as in the case of a conditional sale), removing all owners and returning back to the position of the consumer who has no definite owner. However, these delineated rights may include more or less rights, or the same number of rights as the original or primary key of confirming commands, including the right to replace or delete the primary key of the owner’s commands. Among these rights may be: reconfiguration, adding another owner, deleting the owner (as in the case of a conditional sale), removing all owners and returning back to the position of the consumer who has no definite owner. However, these delineated rights may include more or less rights, or the same number of rights as the original or primary key of confirming commands, including the right to replace or delete the primary key of the owner’s commands.
Generalized device registration procedure.
Note that the general ways described above would be to deposit the private key decryption and
obtaining a certificate of deposit can also be applied in the more general case of registering a protected device with a third party trust and obtaining permission from this third party to enable the device to communicate with other secure devices without necessarily limiting it to the scope or purpose, related to the key deposit situation. According to this general process shown in FIG. 24, a programmable secure device 240 that establishes communication with a trusted third party (TTP) 241, is provided with a private signing key with a manufacturer certificate 242 for the corresponding public signing key. It also contains several protected copies of the manufacturer’s open key and the body that controls the system (or global body) (MRA), which may be the same, as well as secured firmware at the system level, which can facilitate remote installation of additional application micro-software and related unopened keys, as discussed elsewhere in the present description. The device 240 can be registered with any of the potentially unlimited number of trusted third parties 241 included in this general registration system by issuing an authorized authority certificate 243 signed by the US (the US) can also assign an additional number of organizations to authorize TTP to accept the system, in accordance with known principles of open key certification hierarchies). As soon as users register a device in a given TTP, they can enter into specialized operations with other trading partners.
In the first operation of this process, the user initiates a request 244 about registering his device 240 with this certified TTP 241. This request 244 includes some information 245 for identifying the user and the nature of the registration request, signed by the device and accompanied by manufacturer’s device certificate 242 confirming the device’s signature and known device type. The selected TTP 241 may also require information and confirmations from the user or other parties to confirm the identity, membership, creditworthiness, etc. of the user who are outside the scope of this protocol, but may affect TTP’s consent or refusal requested permission to perform operations. TTP241, using the appropriate public keys,
Making sure that the user can be allowed to participate in the operations of the type requested, the TTP 241 will issue a response 246, containing the certificate 247, specifically authorized by the device to perform these operations for the user. The certificate of authorization of the device 247 issued by TTR will usually be
39
41387
contain information identifying the TPTR, the user, the user’s device and the operations for which the permit is issued, as well as a re-certified copy of the public key of the user's device signature to provide convenience (as shown below), therefore the user is not required to present his device certificate 242 in each subsequent operation with trading partners. Answer 246 TTP can also contain downloadable firmware and / or public keys 248 intended to be loaded into a secure device of the user in order for it to be able to perform permitted operations. In the case, if the response 246 TTP offers the user to securely upload new firmware or public keys into his device, Answer 246 will also include the TTP certificate issued by 243 issued by the US, confirming the public key of the TTR signature and delegating authority to the improvement of the firmware and public key. When the secure device 240 of the user 240 receives the 246ТТР response, it uses its built-in public key of the USA signature to verify the TTP 244 resolution certificate and uses the TTP public signature key contained in it to verify the authenticity of the firmware and public key enhancements 248 and the authorization certificate 247 of the TSR properties.
As shown in FIG. 24, when a user wishes to perform an operation with trade partner 250, his device will formulate operations 249 in accordance with the rules laid down in the microprogram embedded in the device (or during manufacture, or later loading), as was carefully considered in this specification. and signs operation 249, attaching the certificate to its corresponding public key. This certificate may be a manufacturer device certificate 242, but is more likely to be the TTP device authority certificate 242 containing a copy of the device's public key, re-certified for convenience. The trading partner 250 will typically use the TTP public key to verify the TTP signature on the device’s 247 authorization certificate, and then uses the device’s public key, contained therein, to verify the device signature at operation 249, thus confirming that the device complies with the requirements of the operation protocol imposed by the corresponding microprogram software. In case the trading partner 250 still does not have a public key to verify the signature of a specific TTP, the user can enable his operation 249 issued by TTP from the USHA certificate of permission 243, which can be verified by the trading partner using the US $ public key, which he must already have in order to take part in this system.
The generic process described is thus generalized enough to ensure: (a) the deposit of the private key of the transfer in exchange for the certificate of deposit signed by the deposit center (TTR) when the information contained or entered into the device certificate the user is transferred to the Deposit Center, the device is already provided with firmware, which allows to perform special functions of the key deposit system described above, or (b) if about not so equipped, but mo-Jette be provided, this process will provide a secure boot-Vaeth improved-tion software, so the device can perform posleustanovki require-Bani system implementation of depot nirovaniyu operations. Operation data 249,
The generalized system shown in FIG. 24 thus has many highly desirable features that can facilitate the implementation of complex forms of commercial and administrative activities in an open communication network environment. In particular, many different device manufacturers load each operating device, up to tech support, as long as it can perform secret multi-step operations, firmware to perform additional types of secret multi-step operations, and sign operations created in this way. In addition, there can be any amount of trustworthy third parties, each of which produces different types of resolution solutions for operations and each creates and certifies some class of micros Gram-many applications, such as the deposit of Clue-cha, Digital cash management, car rental or management of user’s medical records. Thus, although the trading partner may be required (from the side of the firmware or user device protocol) to use a relatively equipped secure device, this device can be made, released and equipped by parties other than the original user, and the operations of the original user will still be accepted. While being processed and processed according to the rules of the system, the partner has a copy of the public key 247 of the USA signature confirmation, which allows all versions of the oystv ihprogrammam and recognize each other and rabotatsovmestno if they are certified and ZSHA eeTTR. Some examples of business objectives that can be met by this protocol include systems
40
41387
by placing monetary or other valuable documents and (c) access to medical or other personal information of the user and the use of this information.
The identification number assigned to the owner.
Depending on the need for balancing ease of use and confidentiality rights, the identification number assigned to the owner may optionally appear either in (a) the user’s deposit certificate or (b) in the SIT issued by the process of the usual communication sessions, as well as in the messages with a key splinter sent to the depositing agents. It would have been advisable for the investigating person to attempt to decrypt the messages in order to be able to determine, looking at the SIT containing the identification number of the owner, whether one or both devices belonged to the SIT that was taken by the SIT to the owner. However, other confidentiality interests, including interests of some owners may require exclusion from the SIT of the owner’s identification number in order to increase the secrecy of messaging. In technical cases, when the owner's identification number is included only in the device’s depositing certificate, but not in the SIT of messages, the lead investigator of the person invited by the employer to determine whether the message was received from An employer that is confronted with many MSNs in which the owners of the device are not indicated will be forced to request the main deposition center specified in this SIT if this SIT has not been received from the device belonging to this employer. The main deposition center must decrypt the participant's session certificate number with the SIT, the key of which is deposited in the main deposit center and check whether the user certificate is issued to the employee by the employer. and if the investigator’s request is signed using the employer's owner’s signature key (i.e., the investigator is authorized to conduct the investigation by the employer-owner), the deposit center will provide this information. If the investigator does not have authority, he may be asked to receive a court order to investigate the suspected activity, as reflected in the MSN of the device owners. It is assumed that the majority of device owners will not object to the public disclosure of their names in their user deposit certificates and in the SIT, since in most electronic communication systems it is impractical to suppress physical and logical information about the network address, which often clearly indicates the sender and recipient of the message. way, you can lose very little
owners of the sending device and receiving device.
The identification number assigned to the owner can, however, still be included in the certificate of deposition of the employer or in the MSCN of the messages without publication. Employee deposit certificates and the MCH must include, among other keys, the employee's public encryption key. These keys should usually be present in both the sender’s and the recipient’s certificates of deposit (assuming that both the sender and the recipient have employees). When the sender forms the MCE, it includes one or both of the assigned identification numbers to the employee, each of which is encrypted using the public key of the respective employer so that the sending device uses the SIT to send the message to each employer. consisting of an identification number assigned to this employer-owner, which can only be expanded by him. This method is similar to that discussed above with regard to the use of the MCH’s sender to send the sender’s and the recipient’s certificate numbers encrypted with the public encryption keys of the respective deposit centers, and to send the message session key to the recipient (the usual purpose of the MCH) as well as to the sender in order to give the opportunity to hear the parties. This technique makes it easy for the employer to identify which SITs belong to employees, while avoiding a situation in which all messages belonging to the co-employees of the owner-employer are easily detected in the message stream and in which the identification numbers of the owner are unencrypted and easy to get. which can only be expanded by him. This method is similar to that discussed above with regard to the use of the MCH’s sender to send the sender’s and the recipient’s certificate numbers encrypted with the public encryption keys of the respective deposit centers, and to send the message session key to the recipient (the usual purpose of the MCH) as well as to the sender in order to give the opportunity to hear the parties. This technique makes it easy for the employer to identify which SITs belong to employees, while avoiding a situation in which all messages belonging to the co-employees of the owner-employer are easily detected in the message stream and in which the identification numbers of the owner are unencrypted and easy to get. which can only be expanded by him. This method is similar to that discussed above with regard to the use of the MCH’s sender to send the sender’s and the recipient’s certificate numbers encrypted with the public encryption keys of the respective deposit centers, and to send the message session key to the recipient (the usual purpose of the MCH) as well as to the sender in order to give the opportunity to hear the parties. This technique makes it easy for the employer to identify which SITs belong to employees, while avoiding a situation in which all messages belonging to the co-employees of the owner-employer are easily detected in the message stream and in which the identification numbers of the owner are unencrypted and easy to get. This method is similar to that discussed above with regard to the use of the MCH’s sender to send the sender’s and the recipient’s certificate numbers encrypted with the public encryption keys of the respective deposit centers, and to send the message session key to the recipient (the usual purpose of the MCH) as well as to the sender in order to give the opportunity to hear the parties. This technique makes it easy for the employer to identify which SITs belong to employees, while avoiding a situation in which all messages belonging to the co-employees of the owner-employer are easily detected in the message stream and in which the identification numbers of the owner are unencrypted and easy to get. This method is similar to that discussed above with regard to the use of the MCH’s sender to send the sender’s and the recipient’s certificate numbers encrypted with the public encryption keys of the respective deposit centers, and to send the message session key to the recipient (the usual purpose of the MCH) as well as to the sender in order to give the opportunity to hear the parties. This technique makes it easy for the employer to identify which SITs belong to employees, while avoiding a situation in which all messages belonging to the co-employees of the owner-employer are easily detected in the message stream and in which the identification numbers of the owner are unencrypted and easy to get. encrypted with the open encryption keys of the respective deposit centers, and for sending the key of the message transfer session to the recipient (the usual purpose of the MCH) as well as the sender to enable him to listen to both sides. This technique makes it easy for the employer to identify which SITs belong to employees, while avoiding a situation in which all messages belonging to the co-employees of the owner-employer are easily detected in the message stream and in which the identification numbers of the owner are unencrypted and easy to get. encrypted with the open encryption keys of the respective deposit centers, and for sending the key of the message transfer session to the recipient (the usual purpose of the MCH) as well as the sender to enable him to listen to both sides. This technique makes it easy for the employer to identify which SITs belong to employees, while avoiding a situation in which all messages belonging to the co-employees of the owner-employer are easily detected in the message stream and in which the identification numbers of the owner are unencrypted and easy to get.
Yet the disadvantage of this approach is that the identification number assigned to the employer, encrypted using the public encryption key, always gives the same, thus recognizable value. The best implementation of this approach should be to encrypt the public key of the data block containing the current timestamp (or other arbitrary number), along with the number of the employee’s deposit certificate (which, as is obvious, the employer has the right to know), therefore, The belt tag will provide a non-persistently encrypted data block. The encrypted block can also include several bits of a different text calculated for the eye to see, such as "ЕМР1_" (or, possibly, an identification number assigned to an employee, if there is a place for this) in order to make successful decoding obvious for the subject deciphering the field (in the case when other data elements are given in binary form, when no one can be sure). In this case, the confirmation of the employer's property rights is simple, that the employer can read it. In addition, in order to increase the variability
41
41387
if the timestamp is not sufficiently trustworthy, one more random number can be added to the data block each time, which makes it possible to make all the data blocks of the employer's personal information system not similar to each other.
This improved approach, which will be used by employers and the sender and recipient in sending each message, will allow employers and other sponsors to determine which messages were sent or received by their employees without providing an encrypted MSN for each message in order to determine whether these were sent messages are sent to the owner-owned devices and ensure, thus, the possibility of saving significant amounts of money. Each employer should still contact the main deposit center and depositing agents, as before, in order to obtain the private key for encrypting their employee, and they should prove that he really owns the employee’s device by signing his personal key signature that matches the public key verification key. contained in its owner certificate issued by the device manufacturer. Employers will at least be able to save time, effort and money that would otherwise have been spent on sending additional requests to the parties to the SIT regarding messages received by devices that later turned out not to belong to this owner. And, as before, if the employer suspects the presence of a criminal or other unauthorized activity in communications, followed by an MSS from a communication session with a dream belonging to his devices, the employer can always contact the appropriate law enforcement agency, tell the body why he suspects the existence of a criminal activity and give this body the right to go to court to obtain an order to intercept and / or decode these messages, which seem to be
This way of placing information in the SIT, which is encrypted in such a way that it can only be read by an authorized party, can obviously be extended to other parties besides the sender and the recipient (each of which can decrypt the message transfer session key). ), the main center of deposit of each party (each of which can decipher the certificate number of the corresponding user) and the employer-owner of each party (each of which can decrypt the certificate number of its employee or self-assigned identification number to be able to determine whether the device transmitting the message belongs to it, without entering
contact with no one else and at the same time not identifying oneself in each communication). This method may also be extended to other parties, such as subdivisions within a very large company or, for example, local law enforcement agencies of foreign countries in which a warrant is not required. Of course, all information mapped by these keys can be placed in an open, i.e., unencrypted form, as discussed above, provided that these parties do not object to being named openly and permanently identified in each message. This information can also be omitted in any case where the party is not relevant, for example, when the user does not have employees. The simplest approach would be to use the MCH format in all situations while leaving the field free in the case of their inapplicability. On the other hand, a preferred implementation may be in using different SIT formats within the same system, each format is indicated by a separate version number placed in the first field, so each device that processes the SIT would be able to determine which fields should be present. ozhi-give, and in accordance with this to produce the analysis of MCN. This method should take into account the undefined placement of interested parties in the MSCN, which would be the most flexible system. The cost of the calculations should depend mainly on how many of these fields really need to be encrypted with the public key of each party's encryption. The preferred implementation may be to use different SIT formats within the same system, with each format labeled with a separate version number placed in the first field, so each device that does the processing of the SIT would be able to determine which fields should be expected. and in accordance with this to produce an analysis of MSN. This method should take into account the undefined placement of interested parties in the MSCN, which would be the most flexible system. The cost of the calculations should depend mainly on how many of these fields really need to be encrypted with the public key of each party's encryption. The preferred implementation may be to use different SIT formats within the same system, with each format labeled with a separate version number placed in the first field, so each device that does the processing of the SIT would be able to determine which fields should be expected. and in accordance with this to produce an analysis of MSN. This method should take into account the undefined placement of interested parties in the MSCN, which would be the most flexible system. The cost of the calculations should depend mainly on how many of these fields really need to be encrypted with the public key of each party's encryption. the presence of which fields should be expected, and in accordance with this, analyze the MCN. This method should take into account the undefined placement of interested parties in the MSCN, which would be the most flexible system. The cost of the calculations should depend mainly on how many of these fields really need to be encrypted with the public key of each party's encryption. the presence of which fields should be expected, and in accordance with this, analyze the MCN. This method should take into account the undefined placement of interested parties in the MSCN, which would be the most flexible system. The cost of the calculations should depend mainly on how many of these fields really need to be encrypted with the public key of each party's encryption.
The employer can easily monitor the information / included in the SIT, complementing each data entry with a "policy field" or a code command containing instructions for the employer's device regarding what information should be included in the SIT. As before, the code command may include elements of choice that enable the employer to include the following information: (1) the name and identification number of the employer, either encrypted or in open form; (2) the unencrypted word "employer" with the employer's identification number encoded in the MCH field; (3) the user's certificate number in the encrypted field; (4) key message transmission in the encrypted field; (5) the timestamp in the encrypted field; (6) an arbitrary masking number in any of the encrypted fields. Many of these elements of choice can be realized simultaneously. In addition, these: policy options can be the same for all members of the interested community, including parties involved in the communication system, and allow the parties to be marked with their mail or system identification numbers or simply by using the words "sender" or "recipient" in the relevant unencrypted SIT fields.
42
41387
Many simultaneously deposited keys.
In addition to the above features of improving the firmware and replacing the public keys of the manufacturer, the secure device that is the subject of the present invention should also have the ability to save and use several groups of the encryption keys deposited at the same time. Usually, when a device starts a reconfiguration cycle, that is, receiving and depositing a new private key of the decryption, and as a result receives a certificate of deposition to the corresponding new public encryption key, the device erases the old private key to facilitate the use of the new deposited personal key key. On the other hand, the device can save the old private key only for a short period of time, for example, to restore data, stored in an encrypted form in a storage device and encrypted using a non-cellular encryption key. However, in an alternative implementation, the device may also accept and process the command for re-deponing either from the user or the device owner, as described above, in order to create a second valid deduction certificate relating to the same private and public encryption key. In this implementation variant, the device will perform the escrow process using, quite possibly, a different list of depositing agents and another main deposit center, and will have to receive another equally valid deposit certificate for the same pair of open and private encryption keys signed and issued by the second main center of deposition, which can be used alternately with the first certificate of deposition. This second certificate of deposit of an open encryption key can be used when a device user travels abroad or communicates with parties located in other countries, especially when other countries want to conduct a legitimate examination of communication channels that start or end in this other country. In such cases, by re-depositing the same device key in another country, the user (or the user’s employer) can assist in meeting the possible legal requirements of another country, by providing the user or the employer with the opportunity to interact without interference with the original group of depositing agents in their own country (lawful tapping of the owner, recovery of the lost key, etc.). Then, in order to allow the owner to follow up the SIT of his employees, it may be sufficient if each MST shows the identification numbers of the sender's and recipient's owners, indicating, in such a way, to the owner that he really has the possibility of obtaining the key. For that he really does have the option of obtaining a key. For that he really does have the option of obtaining a key. For
to save time and effort, the owner can send the SIT to the foreign main depot center in order to obtain the number of the foreign certificate of deposit, the corresponding device number and the corresponding certificate of the device, but then turn to their domestic depositing agents who can verify the owner’s certificate, already in their possession and issue a real private key. This procedure frees the device owner from performing additional legal formalities that may be required in order to obtain fragments of the true key from foreign depositing agents.
National security-related measures to limit exports.
At present, the policy of the United States Government is to allow unregulated use of encryption within the United States by American citizens, along with strict restrictions and penalties for the export of encryption devices, software and know-how. It is possible to change the existing system in order to allow the relatively free private use of cryptographic devices in the United States while at the same time imposing restrictions on their international use. Such a system may allow the use of individual interacting "policy areas" open to all software and hardware vendors without changes or minimal changes in the standard message formats used throughout the system. It is also desirable to allow the use of private depositing agents in purely intercorporate situations for one country, when the key deposit system is used only to allow a certain corpration to monitor and control how its own employees use encryption, without or obligations, expressed or implied, to provide law enforcement agencies with access to messages encrypted by keys deposited by the corporation. In particular, such companies may acquire software and hardware for their own use, but may refuse to assume any public obligations to provide access to private keys for short periods of time,
This can be done by assuming first that all the devices in the system are directly or indirectly connected to the authority managing the system (ASL), which (as was shown above) issues certificates to depositing agents, to the main deposit centers and manufacturers of devices, so that each of they could be recognized by the devices in the system as genuine and trustworthy. National or global communication systems
43
41387
for practical purposes, we must support the existence of a multitude of unrelated main deposit centers of agents, each of which must be certified by the United States as genuine. Each certificate issued to the main depot center or depositing agent will be labeled “open d” or “personal.” The “open” main deposit center or deposit agent is one that is equipped and adapted to quickly respond to receiving security-related or by fighting orders or subpoenas challenging the court. Users whose keys are deposited by such agents may receive permission to participate in cross-border communications. To "personal" The main deposit centers or depositing agents are those key storage centers of one company or one country that have developed a key deposit system for their own needs, but do not undertake any obligations at the public level. The certificate of ZMA issued by the main center of deposition or to the depot agent will also include code countries. In addition, the certificate of deposit of the user issued and signed by the main center of deposit and supplied with the certificate of ZMA attached to it issued to the main deposit center will also include the country code of the user. It should be noted that for convenience, the user’s deposit certificate must also indicate whether it has been received from an open or closed depositing agent, although the WSA may not be able to guarantee the correctness of this information.
FIG. 29 and 30 show the fulfillment of deposit requirements when sending and receiving international cryptographic messages. As shown in FIG. 29, the sender’s secured device 290 activates this system, requiring, prior to sending the international message, the deposit certificates 291, 293 from both the sender and the recipient, and if the sender and the beneficiary are deposited in the same main deposit center , their certificates are USHA 292,294, issued to the main deposit center. The country codes 295, 296 of the recipient user and his main deposit center must co-enter in order for the sending device 290 to send a message. In addition, if the sender and recipient are located in different countries 295, 297 and if any of the users uses the closed main deposit center 298, 299, the sending device will refuse to send a message to this recipient. As shown in FIG. 30, the secure device of the recipient 300 will ensure the operation of this system by refusing to decrypt the message if it was sent in any way, in which the sender and
The radiator is located in different countries and in the event that any of the users uses a closed main deposit center. These rules will ensure fulfillment of the desirable policy of preventing international cryptographic communication sessions without depositing, since the main deposit center cannot falsify its open status, confirmed by the ZMA, and even if the main deposition center can falsify the country code of the user (in order to present the user to belong to the foreign community) ), the devices will not allow discrepancies between the user's country codes and the main center of the deposit. Although these rules do not exclude the user's ability to transport his secure cryptographic device across national boundaries, they easily ensure compliance with national interests,
Multiple user device versions.
Another distinguishing feature of the present device is the ability to initiate and simultaneously maintain several communication sessions with various local or remote users using a device for this purpose. Many more powerful computers provide multiple users, often simultaneously in conversation sessions, who may, however, wish to initiate encrypted communication sessions with other subjects in different parts of the world. However, since it would be extremely inefficient to require a separate secure device to provide a session communication of each user on a computer operating in a time-sharing mode, protected by the device, can track the message session key for each communication session by raneniyaego together with the assigned ordinal post-vym number (Mzy) for this session. Then, when any additional packets of this message arrive with the specified MZY, they can be decrypted without delay in sending the encrypted response. In addition, the device may deposit the private keys of the decryption by several users, associating the private key of each user with the identification number assigned to this user, and using each key only after presenting some confirmations of the authenticity of this particular user, such as password, smart card, ΡΙΝ, biometric data, response to the request, etc. .After adding to each pair of public or personal keys made up of the identification about the number and password of the user or a similar sign, the device can then perform the usual control of passwords, such as length, expiration,
44
41387
формах, приведенных здесь исключительно в
as an illustration, not limiting
feature, and the present invention is limited
The following points only
claims
Thus, a cryptographic system and a method, the distinguishing feature of which is the key deposit, is proposed. It should be obvious to a specialist in this field that the present invention can be practically implemented in ways that differ from those described.
<tr><td><p>X</p></td><td><p>Recipient's private key / Exhibitor /</p></td></tr><tr><td><p>Xi ... η</p></td><td><p>Numbered fragments of a private key</p></td></tr><tr><td><p>Xi</p></td><td><p>•</p><p>] - no private key fragment</p></td></tr><tr><td><p>Have</p></td><td><p>Unstable Private Key Sender / Exhibitor /</p></td></tr><tr><td><p>but</p></td><td><p>Open base number</p></td></tr><tr><td><p>R</p></td><td><p>Open main modular number</p></td></tr><tr><td><p>OHH</p></td><td><p>Intermediate number, = 3<sup>x</sup> glosi p</p></td></tr><tr><td><p>It</p></td><td><p>Intermediate room, 53 memory GLOSI r</p></td></tr><tr><td><p>ka</p></td><td><p>Diffie-Helnap Derivative Message Key</p></td></tr><tr><td><p>νΐ.,. η</p></td><td><p>Intermediate death by the way Mika Lee, - and<sup>XI</sup> that p</p></td></tr><tr><td><p>CGDD</p></td><td><p>Random or derived to-key messages</p></td></tr><tr><td><p>M</p></td><td><p>Open message</p></td></tr><tr><td><p>WITH</p></td><td><p>Encrypted message</p></td></tr>
FIG. 1A
45
41387
<tr><td><p>Signature</p></td><td><p>Open</p></td><td><p>Closed</p></td></tr><tr><td><p>K5<sup>+</sup></p></td><td><p>KZ-</p></td></tr><tr><td><p>Ciphering</p></td><td><p>KE +</p></td><td><p>KE "</p></td></tr>
FIG. 1B
opening key signatures
devices
signed by the manufacturer
using the private key ητή) * ''. 'КЗ'лтРдг *
FIG. 1C
<tr><td><p>message to</p></td><td><p>ї<sup>+</sup>Gusr</p></td></tr><tr><td><p>></p></td><td><p>to i</p></td><td><p>,,</p></td><td><p>one</p></td></tr><tr><td><p></p></td><td><p></p></td><td><p></p></td><td><p></p></td></tr>
encrypted message
public encryption key
recipient
FIG. YU
46
41387
<tr><td><p>Hoh</p></td><td><p></p></td><td><p>control decoder box</p></td></tr><tr><td><p>sa</p></td><td><p>sak, η</p></td><td><p>certification authority / for signature signature keys /</p></td></tr><tr><td><p>άεν</p></td><td><p>eac.p</p></td><td><p>trusted device</p></td></tr><tr><td><p>ea</p></td><td><p>depot agent</p></td></tr><tr><td><p>eu</p></td><td><p>esi „. η</p></td><td><p>Depot Office</p></td></tr><tr><td><p>shgdi</p></td><td><p>tGdGI .., Η</p></td><td><p>manufacturer of trusted device</p></td></tr><tr><td><p>o ^ mei</p></td><td><p></p></td><td><p>owner of the device / other person, user check</p></td></tr><tr><td><p>GoSir</p></td><td><p></p></td><td><p>message recipient</p></td></tr><tr><td><p>$ en ^ er</p></td><td><p></p></td><td><p>sender of the message</p></td></tr><tr><td><p>$ 1 ¥ th</p></td><td><p></p></td><td><p>authority system wide</p></td></tr><tr><td><p>izeg</p></td><td><p>i5r / „, p</p></td><td><p>trusted device user</p></td></tr>
FIG. 1E
FIG. 1P
(c (aia)<sub>5eps</sub>|<sub>er</sub> (4aia) KE<sup>+</sup>5Єms) er
FIG. 1C
47
41387
FIG. 2
48
41387
π
about
5E
X
2
ABOUT,
X
Ξ
• Θ *
£
B
CE
">
ABOUT
β
Λ
"=!
ω
B
Ο
η
Λ
¢ 3
Ο
WITH
"
<
FIG. 3
49
41387
FIG. four
50
41387
FIG. 6
51
41387
FIG. eight
52
41387
FIG. 9
53
41387
FIG. ten
54
41387
<tr><td><p>but</p></td><td><p>X</p></td></tr><tr><td><p>0)</p></td><td><p>and</p></td></tr><tr><td><p></p></td><td><p>0! ®</p></td></tr><tr><td><p>Η</p></td><td><p>X <sup>with</sup></p></td></tr><tr><td><p>H</p><p>ABOUT</p></td><td><p>X h (!) About</p></td></tr><tr><td><p>with</p></td><td><p>h <sup>with</sup></p></td></tr>
FIG. eleven
<tr><td><p>Г — 1</p></td><td><p>at</p><p>but,</p><p>s</p><p><m</p></td></tr><tr><td><p>TO</p></td><td><p>with</p></td></tr><tr><td><p>X</p></td><td><p>η</p></td></tr><tr><td><p></p></td><td><p>l</p></td></tr><tr><td><p>sh</p></td><td><p>to</p></td></tr><tr><td><p>n</p></td><td><p>about</p></td></tr><tr><td><p>to</p></td><td><p>with</p></td></tr><tr><td><p>ABOUT,</p></td><td><p></p></td></tr><tr><td><p>f</p></td><td><p>to</p></td></tr><tr><td><p>£ loose</p></td><td><p>· -</p></td></tr><tr><td><p>s</p></td><td><p>R?</p></td></tr><tr><td><p>and</p></td><td><p></p></td></tr><tr><td><p>with<sup>one</sup></p></td><td><p>■> '</p></td></tr><tr><td><p>with</p></td><td><p>BUT.</p></td></tr><tr><td><p>f</p></td><td><p>X</p><p>□:</p></td></tr><tr><td><p></p></td><td><p>about</p></td></tr><tr><td><p></p></td><td><p>h!</p></td></tr><tr><td><p>14</p></td><td><p>. WITH</p></td></tr><tr><td><p></p></td><td><p></p></td></tr>
55
41387
Version number
Serial Ioner Certification
Deposit Center Name
The country code of the center depononanijaka + ЄC
/ for І.EAB use /
Username
KYO user<sup>+</sup>/ for messages /
K5 <sup>+</sup> No / to confirm EEAE / Validity period
Signature of the Deposit Center
FIG. 12
(Kp ^ Ksiєu_
Somtrol cloth Kіііd
Serial number of devices
Control Sunna BIAR
<tr><td><p>Ksh5d</p></td><td><p>Sinnetrichpny message key</p></td></tr><tr><td><p>Ksiku</p></td><td><p>Symmetric key enabled device B.</p></td></tr><tr><td><p>K-rush</p></td><td><p>Symmetric Clipper Generic WEDGE</p></td></tr>
FIG. 13
FIG. 14
56
41387
FIG. 15
57
41387
FIG. sixteen
58
41387
About ί-
FIG. 17
g
-BUT-
E £ "3O" s *
59
41387
181
Version number_
(message key ^ Гесір
The name of the center of deposition of the sender №1)
Country code of the custody center
Name of the center of the deposit of the recipient (ec2.)
Country code of the center of the deposit of the recipient
biomer certification of deposition sender) KE ~<sup>+</sup>Sci
The key of the same ad is £ £ * 5eps / er (to yourself ^
("Certification number of the deposit of the recipient) <sup>+</sup> £ ¢ 2.
18(
(81
181
Time indication (optional
Signature device sender
FIG. 18
60
41387
φ
h
and
□.
and
***
Η
h
about
with
FIG. nineteen
ω f
£ "Φ H £ - *
och oh ha
s to f
61
41387
ace
aa
Oh
κ-θ.
Hg
/ X
MS
(five
ga u
a 5ω Cm
By
* -
5 I
5gH)
* m
ha <sup>to</sup>
ha fga a □ ® xh gaga Ϊ
O. Fga a, a, =
χί = k
about
- ge- (U
ha kaa
with
f
H
ABOUT
ha oga so
X е · e ha cf
l '
from 5
FIG. 20
3 P
ϋ and = χ;>, a>, ω ω; h φ> ιθ їїα υ ze. α
To cn
HE
"G * g
and ha I
us ha
ha ha pho p ha ha ha ha ha p £ h a £ f h Λ x
Oh and kk and "to
41387
63
41387
FIG. 22
64
41387
FIG. 23
65
41387
FIG. 24
66
41387
FIG. 25
67
41387
68
41387
FIG. 27
69
41387
70
41387
W FW]
FIG. 29
71
41387
FIG. thirty
72
41387
DC "Ukrainian Institute of Industrial Property Administration" (Ukrpatent) Ukraine, 01133, Kyiv-133, blvd. Lesі Ukrainian, 26 (044) 295-81-42, 295-61-97
Signed before druku_2002 p. Format 60x84 1/8.
Obsyag_obl.-view. arc Circulation 50 approx. Deputy_
UkrInTEI, 03680, Kyiv-39 Small and medium business, vul. Gorky, 180.
(044) 268-25-22
73
Contents46
81 members in 29 offices
Priority claims14
| Document | Office | Kind | Date |
|---|---|---|---|
| 08181859 | United States of America | – | |
| 18185994 | United States of America | A | |
| 18185994 | United States of America | A | |
| 08272203 | United States of America | – | |
| 27220394 | United States of America | A | |
| 27220394 | United States of America | A | |
| 9500531 | United States of America | W | |
| 9500531 | United States of America | W | |
| 08181859 | – | – | – |
| 08272203 | – | – | – |
| PCTUS9500531 | – | – | – |
| US19940181859 | – | – | – |
| US19940272203 | – | – | – |
| WO1995US00531 | – | – | – |
Members81
| Document | Office | Kind | |
|---|---|---|---|
| CA2176032A1 | Canada | A1 | |
| WO9519672A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU1680395A | Australia | A | |
| WO9519672A3 | World Intellectual Property Organization (WIPO) | A3 | |
| GB9610291D0 | United Kingdom | D0 | |
| HU9601870D0 | Hungary | D0 | |
| IL118363D0 | Israel | D0 | |
| AU6084296A | Australia | A | |
| EP0739560A1 | European Patent Office (EPO) | A1 | |
| PL315574A1 | Poland | A1 | |
| ZA963635B | South Africa | B | |
| CA2223305A1 | Canada | A1 | |
| WO9639765A1 | World Intellectual Property Organization (WIPO) | A1 | |
| GB2301919A | United Kingdom | A | |
| AU5552196A | Australia | A | |
| CN1138927A | China | A | |
| CZ197896A3 | Czechia | A3 | |
| HUT75800A | Hungary | A | |
| MX9602773A | Mexico | A | |
| TW307075B | Taiwan Province of China | B | |
| CO4480074A1 | Colombia | A1 | |
| JPH09507729A | Japan | A | |
| BR9506414A | Brazil | A | |
| AR002213A1 | Argentina | A1 | |
| AP626A | African Regional Intellectual Property Organization (ARIPO) | A | |
| NZ279622A | New Zealand | A | |
| US5799086A | United States of America | A | |
| MX9709760A | Mexico | A | |
| CN1192834A | China | A | |
| US5825880A | United States of America | A | |
| EP0872080A1 | European Patent Office (EPO) | A1 | |
| US5841865A | United States of America | A | |
| US5850451A | United States of America | A | |
| BR9608416A | Brazil | A | |
| US5857022A | United States of America | A | |
| US5867578A | United States of America | A | |
| US5872849A | United States of America | A | |
| KR19990022451A | Republic of Korea | A | |
| AU705473B2 | Australia | B2 | |
| HU216231B | Hungary | B | |
| PL176458B1 | Poland | B1 | |
| JPH11506222A | Japan | A | |
| GB9918950D0 | United Kingdom | D0 | |
| AU4461999A | Australia | A | |
| GB2337145A | United Kingdom | A | |
| US6009177A | United States of America | A | |
| NZ306846A | New Zealand | A | |
| NZ329891A | New Zealand | A | |
| IL118363A | Israel | A | |
| GB2301919B | United Kingdom | B | |
| GB2337145B | United Kingdom | B | |
| AU718265B2 | Australia | B2 | |
| US6209091B1 | United States of America | B1 | |
| NZ500372A | New Zealand | A | |
| EP0739560B1 | European Patent Office (EPO) | B1 | |
| AT202439T | Austria | T | |
| ATE202439T1 | Austria | T1 | |
| DE69521413D1 | Germany | D1 | |
| ES2158081T3 | Spain | T3 | |
| UA41387C2This record | Ukraine | C2 | |
| DK0739560T3 | Denmark | T3 | |
| US2001050990A1 | United States of America | A1 | |
| PT739560E | Portugal | E | |
| GR3036650T3 | Greece | T3 | |
| US2002013898A1 | United States of America | A1 | |
| OA10456A | African Intellectual Property Organization (OAPI) | A | |
| DE69521413T2 | Germany | T2 | |
| US6411716B1 | United States of America | B1 | |
| EP0872080A4 | European Patent Office (EPO) | A4 | |
| US2005204129A1 | United States of America | A1 | |
| JP2005328574A | Japan | A | |
| JP2006246543A | Japan | A | |
| JP2006333520A | Japan | A | |
| JP2007282295A | Japan | A | |
| JP4083218B2 | Japan | B2 | |
| US2009217034A1 | United States of America | A1 | |
| EP0872080B1 | European Patent Office (EPO) | B1 | |
| AT492088T | Austria | T | |
| ATE492088T1 | Austria | T1 | |
| DE69638307D1 | Germany | D1 | |
| US8364967B2 | United States of America | B2 |
Numbers
- Publication
- 41387
- Publication, DOCDB
- 41387
- Publication, EPODOC
- UA41387
- Application
- 96072822
- Application, DOCDB
- 96072822
- Application, EPODOC
- UA19960072822
Titles3
- Ukrainian
- СПОСІБ УСТАНОВЛЕННЯ ВІРОГІДНОГО ПЕРЕВІРЮВАНОГО ЗВ'ЯЗКУ, СПОСІБ ЗАХИЩЕНОГО ЗВ'ЯЗКУ, СПОСІБ ОНОВЛЕННЯ МІКРОПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ, СПОСІБ ЗДІЙСНЕННЯ ШИФРОВАНОГО ЗВ'ЯЗКУ ТА СПОСІБ НАДАННЯ ПЕРЕВІРЕНОМУ НА СПРАВЖНІСТЬ ПРИСТРОЮ ПРАВА НА ПРОВЕДЕННЯ ЕЛЕКТРОННОЇ ТРАНЗАКЦІЇ
- English
- METHOD FOR SETTING OF TRUE COMMUNICATION BEING CHECKED, METHOD FOR PROTECTED COMMUNICATION, METHOD FOR RENEWAL OF MICRO-SOFTWARE, METHOD FOR EXECUTION OF ENCIPHERED COMMUNICATION AND METHOD FOR GIVING TO DEVICE CHECKED ON IDENTITY OF RIGHT ON ELECTRON TRANSACTION
- Russian
- СПОСОБ УСТАНОВЛЕНИЯ ДОСТОВЕРНОЙ ПРОВЕРЯЕМОЙ СВЯЗИ, СПОСОБ ЗАЩИЩЕННОЙ СВЯЗИ, СПОСОБ ОБНОВЛЕНИЯ МИКРОПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, СПОСОБ ОСУЩЕСТВЛЕНИЯ ШИФРОВАННОЙ СВЯЗИ И СПОСОБ ПРЕДОСТАВЛЕНИЯ ПРОВЕРЕННОМУ НА ПОДЛИННОСТЬ УСТРОЙСТВУ ПРАВА НА ПРОВЕДЕНИЕ ЭЛЕКТРОННОЙ ТРАНСАКЦИИ
Classification
- CPC, 11
- G06Q20/02
- G06F7/725
- G06Q20/3821
- G06Q20/3829
- H04L9/0894
- H04L9/3263
- H04L9/0844
- H04L9/085
- H04L9/088
- H04L9/3247
- H04L9/0825
- IPC, 6
- H04L9 08
- H04L9 32
- G06F7 72
- G06Q20 02
- G06Q20 38
- G09C1 00