WO2013184016A1 - Способ осуществления безопасных коммуникаций в компьютерных сетях (варианты) - Google Patents

Способ осуществления безопасных коммуникаций в компьютерных сетях (варианты) Download PDF

Info

Publication number
WO2013184016A1
WO2013184016A1 PCT/RU2012/000434 RU2012000434W WO2013184016A1 WO 2013184016 A1 WO2013184016 A1 WO 2013184016A1 RU 2012000434 W RU2012000434 W RU 2012000434W WO 2013184016 A1 WO2013184016 A1 WO 2013184016A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
dss
computer
client
specialized
Prior art date
Application number
PCT/RU2012/000434
Other languages
English (en)
French (fr)
Inventor
Валерий Аркадьевич КОНЯВСКИЙ
Юрий Михайлович АКАТКИН
Original Assignee
Konyavskiy Valery Arkadyevich
Akatkin Yury Mikhailovich
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Konyavskiy Valery Arkadyevich, Akatkin Yury Mikhailovich filed Critical Konyavskiy Valery Arkadyevich
Priority to PCT/RU2012/000434 priority Critical patent/WO2013184016A1/ru
Publication of WO2013184016A1 publication Critical patent/WO2013184016A1/ru

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3215—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a plurality of channels

Definitions

  • the patented group of methods connected by a single inventive idea and a common technical result, relates to the field of information technology, involving prompt (in "on line” mode) interaction between users with different rights and levels of authority (from ordinary to administrators), with complexes of interconnected hardware, including hardware and software components (computers, network equipment and browsers) - with computer networks - from general global (for example, Internet) to private local (for example, Virtual Private Network - VPN).
  • This method is based on the formation of cryptographically protected channels (tunnels) between the nodes (gateways) of the networks or the gateway and the remote computer, which provide secure communications over an insecure network and allow the user to work through a secure connection using a standard browser.
  • the SSL / HTTPS secure transport procedure used in it is a standard accessory of popular browsers.
  • a key pair is used, and SSL certificates are used to establish the authenticity (authorization) of the sender and the absence of distortions in the information.
  • the browser sends a request for a secure page via the HTTPS protocol to the network.
  • the objective of the invention is to create a more universal, easy to implement (not requiring any intervention in the material part of the computer) and effective as a result of the method of implementing secure communications in computer networks, each version of which has features that adapt it to different conditions of use.
  • the technical aspect of the achieved result is to increase the level of communication security due to a reduction in the likelihood of successful hacker attacks.
  • this problem is solved in that in a known method for implementing secure communications in computer networks, based on the formation of cryptographically protected channels (tunnels) between the nodes (gateways) of the networks or the gateway and the remote computer, providing cryptographic data protection functions and allowing the user can work through a secure connection using a normal browser; sufficient conditions for protecting communications over the computer’s communication channel with the network provide lzovate- h For the time being - for the period of a trusted communication session (BSS).
  • BSS trusted communication session
  • An individual distinguishing feature which is an attribute of only a specific variant of the method, is the type of communication channel with the network through which secure communications are carried out.
  • this channel is, therefore, available (such may be, in particular, cable, fiber-optic communication lines, Wi-Fi, etc.) - i.e. a channel that does not require any special measures within the method for its education, but the same channel through which the computer communicates with the network in normal operation, outside the BCS.
  • TCP / IP Transmission Control Protocol / Internet Protocol
  • VPNs Virtual Private Networks
  • ES electronic signature
  • the implementation of the DSS concept in the first variant of the method requires the use on the user side of the only specialized hardware tool (DSS client) used for trusted computer boot.
  • DSS client specialized hardware tool
  • the DSS client is a removable storage medium, for example, with a USB interface for communication with a computer, made, in particular, in the “USB key” form factor.
  • ROM Read Only Memory
  • a trusted computer boot should be carried out from the ROM area of the DSS client without using a computer hard drive, the content of which cannot be certain.
  • the complete isolation and power of attorney of the DSS client software environment can provide solid guarantees for the safety of communications during the DSS.
  • a feature of the described first — the most simple in implementation — version of the method is that the DSS client, along with the performance of its main function - trusted computer boot — must recognize the type of communication channel available on the computer with the network and, accordingly, adapt to one of the many possible settings for this channel. Due to the fact that the number of types of channels used in practice and possible options for their settings is not only large, but also has a tendency to further increase, estimates show that at the moment ⁇ 30% of possible communication channels and their settings can fall out of the scope of customer support. For application in these conditions, the second variant of the method is intended, characterized by the allocation for DSS of a specialized communication channel with the network, all settings of which are predefined and fixed.
  • the second variant of the method consists in the fact that in the known method for making secure communications in computer networks, based on the formation between the nodes (gateways) of the networks or the gateway and the remote computer, cryptographically protected channels (tunnels) that provide the functions of cryptographic data protection and allow the user to work through a secure connection using a conventional browser, sufficient conditions for protecting communications over a specialized communication channel with the network also provide the user with time NGOs - on the periods of DSS.
  • this specialized communication channel is first formed, and the trusted download of the tested OS, the composition and setting of which is also chosen so that the user's freedom is limited by the capabilities necessary and sufficient for DCS, is provided further.
  • they organize a connection protected by known methods with the required remote service.
  • the implementation of the DSS concept in the second variant of the method requires the combined use of two hardware on the user side: one general application - to form a specialized communication channel with the network, and one specialized, used for trusted boot computer - client DSS.
  • the use of general-purpose hardware for the formation of a specialized channel contributes to a significant reduction in the cost of preparation for the implementation of the second variant of the method.
  • the DSS client should also be a removable storage medium, in the memory of which there are areas with different access attributes, including tamper-resistant ROM area. At least one of the following data groups is pre-recorded in the latter: the aforementioned OS, a browser, its own cryptographic subsystem, software for organizing a secure connection, private keys and certificates. Computer loading here is also carried out from the ROM area of the DSS client without using a hard disk, then in a predetermined sequence, the browser is started and the DSS is established with the connection protected by the cryptographic procedures created in the dedicated channel provided in the cryptographic subsystem of the DSS client. When choosing a sequence of alternating these actions, one should be guided by the considerations given for the first option.
  • a model of a modulator-demodulator of a signal that is suitable for the characteristics in a format accepted by mobile operators, in particular, the 3G format (3G modem).
  • 3G modem 3G format
  • the data contained in the modem memory for example, in the SIM card installed in it with the subscriber’s identification data, can be additionally used.
  • the differentiation of access to the memory areas of the DSS client is also, in order to reduce time, it is advisable to carry out a special program activated by at least one bi-directional data exchange command between the corresponding application and the user's computer specified in the user interface DSS client, or by setting in the initial data the values of some parameter beyond the range of its permissible values.
  • cryptographically protected channels that provide the functions of cryptographic data protection and allow the user to work through a secure connection using a normal browser, sufficient conditions for protecting communications over a specialized communication channel with the network, similar to the first two options, also provide the user with temporary o - for the period of LTA.
  • a specialized communication channel is formed and trusted loading of the tested OS is carried out with the help of a single integrated channel-forming and loading technical means.
  • they organize a connection protected by known methods with the required remote service.
  • the OS configuration for the above reasons, is defined by the capabilities necessary and sufficient for the implementation of LTAs that restrict the freedom of the user.
  • the specialized integrated channel-forming and boot-up hardware used in the third variant of the method should combine the functions of a signal modulator-demodulator in a format accepted by mobile operators and a removable storage medium. Regions with different access attributes, including an area of ROM protected from unauthorized changes, into which at least one of the following data groups is pre-recorded: the aforementioned OS, browser, its own cryptographic subsystem, software for organizing a secure connection, private keys and certificates.
  • the computer is loaded in the third variant of the method from the ROM area of the DSS + client without using a hard disk, then the browser is started in a predetermined sequence and the DSS is established with the connection protected by the cryptographic procedures created in the specialized cryptographic subsystem of the client DSS +. When choosing a sequence of alternating these actions, one should also be guided by the considerations given for the first option.
  • the differentiation of access to the memory areas of the DSS + client in the third embodiment of the method is also, in order to reduce time, it is advisable to carry out a special program activated by at least one bi-directional data exchange command between the corresponding application and the user's computer, the DSS client specified in the user interface, or by setting the value of a parameter in the source data that goes beyond the range of its permissible values.
  • the DSS + client being a channel-forming hardware
  • a personalized (personalized) SIM card administrators of remote services also have additional opportunities for authenticating users who have contacted them.
  • DSS client or DSS + client use the integration software module, built-in as a browser plug-in (extension) and designed to initiate operations with electronic signatures.
  • File sanitation software is installed on the server side, which checks the correctness of the XSD schemes of the received XML files and removes unauthorized operations from them.
  • an XML file of known structure can be generated (including outside the BSS), which will be signed by the user interface on the user side and then transferred to the remote service in compliance with security requirements.
  • the use of electronic information allows you to control the integrity of the message at the stages of transmission and reorganization and notify the user about the reception of information, which increases the reliability of its processing.
  • a request for access to the required document is sent by the user to the server in the format HTTP: // URL /.
  • a form and a Java script are selected for generating the electronic signature (the form can be partially filled) and sent to the user.
  • visualization and manual filling of the form takes place. After that, they launch a Java script (a call by clicking on the "OK" button), then form an XML file, sign its electronic signature, write the electronic signature in XML or in a separate file and send the XML file that includes the electronic signature to the server (the case is considered when the XML file is relatively small in volume and the signature is signed by him).
  • the ES of the XML file is checked on the server side (by the administrator of the remote service), and if it is correct, then the correctness of its XSD scheme is checked and sanitation is performed - unauthorized operations are deleted. Further, if the resulting XML file is correct, then a notification “document accepted” is generated and in the form of an HTML page with a notification is sent to the user. If the ES is incorrect or the XML file is incorrect, an error code is generated and is also sent to the user.
  • the XML file is relatively large in volume, then on the user side, after manually filling out the form, it is prepared for sending and sent to the server. There, its XSD scheme is checked, unauthorized operations are deleted, and if the resulting XML file is correct, then the hash function is calculated from it. Next, the server generates and transmits to the user an HTML form with a hash function and a Java script.
  • the form containing the hash function is visualized on the user side, upon receipt of which, the user clicks the OK button. Then he signs the hash function of the ES, writes the ES and the hash function in an XML file, and transfers it to the server. There, in turn, the ES of the hash functions from the XML file is checked, then, if it is correct, the incoming hash function is compared with the previously calculated one, and if the hash functions coincide, a notification “ document accepted ”and sent to the user.
  • An error code on the server side is generated and sent to the user in the following three cases: if the initial XML file is incorrect, if the hash function is incorrect, or the received and calculated hash functions do not match.
  • DSS ends with a visualization of the user confirmation of “document accepted” or error.
  • the method can find application in a wide variety of computer systems of the information society - both publicly available and corporate. Most clearly, the advantages of the method should be manifested in systems for providing public services in electronic form (the so-called “electronic government”), with remote banking services (in this area, the client of the DSS or the client of the DSS + optimally suits the role of the so-called electronic means of payment ”stipulated by the Federal Law of the Russian Federation N ° 161- ⁇ “ On the National Payment System ”), as well as in many other areas - in particular, in information and telecommunication systems for medical purposes.
  • the patented method for all its apparent simplicity, there is no reason to consider directly derived from the achieved level of technology, and, according to reports, it is new.
  • DSS as such and the method of its implementation, characterized by the above distinguishing features, are invariant with respect to the used information technologies and computer configurations, expanding the generally accepted paradigm of information security by dynamically creating a trusted computing environment by using proven OS and functional software for limited time of a user interaction with an information resource.
  • a social: aspect it is important that the refusal to maintain a trusted environment during a time of lack of demand for a secure interaction in favor of the DSS concept eliminates the previously unavoidable factor of the user's “attachment” and means of ensuring information security to specific computers, thereby expanding freedom user.

Abstract

Область применения - сетевые информационные технологии. Относится к способам, в которых между шлюзами сетей или шлюзом и удаленным компьютером формируют криптографически защищенные каналы, обеспечивающие функции криптографической защиты данных и позволяющие пользователю работать через защищенное соединение с помощью обычного браузера. Задача изобретения - расширение универсальности и повышение эффективности способа - решена тем, что в нем достаточные условия защиты коммуникаций предоставляют пользователю временно - на период доверенного сеанса связи (ДСС). В течение ДСС обеспечивают доверенную загрузку проверенной операционной системы (ОС) и организуют защищенное известными методами соединение с требуемым удаленным сервисом, причем состав и настройку ОС выбирают такими, чтобы свобода пользователя ограничивалась возможностями, необходимыми и достаточными для ДСС. Представлен в трех вариантах, различающихся по видам каналов связи с сетью и технических средств (ТС), применяемых для поддержания способа: канал связи - имеющийся, ТС - загрузочное специализированное (1); канал связи - специализированный, ТС - каналообразующее общего применения + загрузочное специализированное (2); канал связи - специализированный, ТС - комплексное (каналообразующее + загрузочное) специализированное (3).

Description

СПОСОБ ОСУЩЕСТВЛЕНИЯ БЕЗОПАСНЫХ КОММУНИКАЦИЙ В КОМПЬЮТЕРНЫХ СЕТЯХ (ВАРИАНТЫ)
Область техники
Патентуемая группа способов, связанная единым изобретательским за- мыслом и общим техническим результатом, относится к области информаци- онных технологий, предполагающих оперативное (в режиме "on line") взаи- модействие пользователей, различающихся правами и уровнями полномочий (от рядовых до администраторов), с комплексами взаимосвязанных техниче- ских средств, включающими аппаратные и программные составляющие (компьютеры, сетевое оборудование и браузеры) - с компьютерными сетями - от общих глобальных (например, Internet), до частных локальных (напри- мер, Virtual Private Network - VPN).
Предшествующий уровень техники
По мере проникновения компьютерных сетей во все стороны общест- венной жизни резко обостряется проблема обеспечения информационной безопасности коммуникаций в открытых (в принципе, доступных неопреде- лённому кругу лиц) средах. Для решения этой проблемы ранее было предло- жено множество способов, основанных на криптографических процедурах. Таков, в частности, способ защиты информации на основе коммутируемых виртуальных каналов - Switched Virtual Circuit (SVC) - применяемый в сетях VPN, использующих протокол управления передачей/Интернет протокол Transport Control Protocol/Internet Protocol (TCP/IP) [1 , с.520].
Этот способ основан на формировании между узлами (шлюзами) сетей или шлюзом и удалённым компьютером криптографически защищенных ка- налов (туннелей), обеспечивающих безопасные коммуникации по незащи- щенной сети и позволяющих пользователю работать через защищённое со- единение с помощью обычного браузера. Применяемая в нём процедура безопасного транспорта SSL/HTTPS - стандартная принадлежность популяр- ных браузеров. Для шифрования данных при коммуникациях между пользо- вателем (клиентом) и сервером используют пару ключей, а для установления подлинности (авторизации) отправителя и отсутствия искажений в информа- ции - сертификаты SSL. При установлении защищенного соединения брау- зер передаёт в сеть запрос на безопасную страницу по протоколу HTTPS. По- лучив из сети в ответ открытый ключ с сертификатом, он проверяет действи- тельность последнего и передаёт зашифрованный посредством открытого ключа запрос серверу. Сервер дешифрует запрос с помощью секретного ключа и отправляет клиенту запрашиваемый документ, шифруя его симмет- ричным ключом. Браузер посредством симметричного ключа дешифрует по- лученный документ и отображает его для пользователя. Вследствие возможных рисков, связанных с относительной простотой доступа через VPN к корпоративной среде, ограничиться только закрытием туннелей VPN, как правило, бывает недостаточно: необходимо также убе- диться в защищённости удалённого компьютера, контролировать передавае- мый по туннелю трафик, обезопасить сервер и удалённую систему - в общем, принять меры по формированию доверенной среды. Поэтому, в частности, для усиления средств авторизации применяют смарт-карты и другие мобиль- ные аппаратные средства, обеспечивающие защищенное хранение цифровых сертификатов, генерацию ключей с помощью физических датчиков случай- ных чисел и аппаратное исполнение всех криптографических процедур с за- крытым ключом [2].
Известны также способы, не только обеспечивающие пользователю защищенный уделённый доступ к ресурсам сети, но и позволяющие задавать для удалённого компьютера правила «персонального брандмауэра» (FW), а также проверять клиентскую сеть на наличие обновлений программного обеспечения (ПО) и работающего антивируса. Для этого на удалённый ком- пьютер загружают специальный элемент управления, который отслеживает наличие вредоносных программ и антивирусов, актуальность их баз и т.п.; формирует виртуальный «рабочий стол», изолированный от остальной сис- темы; обеспечивает контроль доступа администратором, определяющим, ка- кие программы можно запускать, куда сохранять файлы и т.д.; шифрование всех временных файлов. Техническое средство, штатной функцией которого является, в частности, поддержание такого рода способов, описано в [3].
Однако в настоящее время можно считать доказанным, что установка и функционирование любых программных средств защиты информации, в т.ч. вышеупомянутых, в неизолированной (недоверенной) информационной сре- де компьютера пользователя приводит к множественным системным уязви- мостям. Достаточные условия защиты коммуникаций в обязательном поряд- ке должны, в том или ином виде, содержать требование доверенности ком- пьютера пользователя. Это требование на существующем уровне техники может быть удовлетворено только дооснащением компьютера пользователя специальным встроенным аппаратным средством - резидентным компонен- том безопасности, в частности, аппаратным модулем доверенной загрузки (АМДЗ) [4].
Данное техническое решение, обеспечивающее долговременные гаран- тии целостности компьютера и изолированности его программной среды, достаточно эффективно и универсально. Однако оно, как известно, по ряду причин не всегда технически возможно и экономически целесообразно.
Наряду с тем, что у компьютера может отсутствовать свободный слот для установки АМДЗ, бывают ситуации, когда пользователю требуется уста- навливать защищенные коммуникации с не принадлежащего ему компьюте- pa, в комплектации которого не может быть уверенности. Кроме того, уста- новка АМДЗ - мероприятие весьма дорогостоящее, а в условиях, когда ком- пьютер большую часть времени эксплуатации изолированной программной среды не требует, для подавляющего большинства владельцев и пользовате- лей - неприемлемое.
Кроме того, постоянное создание в компьютере доверенной программ- ной среды и работа в ней пользователей без жестких временных рамок при- водит к специфической группе рисков, связанных с появлением у подклю- чившихся к коммуникациям, и через них - к доверенным компьютерам, зло- умышленников (хакеров) относительно больших резервов времени, что по- вышает вероятность успешных хакерских атак.
Раскрытие изобретения
Задачей изобретения является создание более универсального, просто- го в осуществлении (не требующего никаких вмешательств в материальную часть компьютера) и эффективного по результату способа осуществления безопасных коммуникаций в компьютерных сетях, каждый вариант которого обладает особенностями, адаптирующими его к различным условиям приме- нения.
Просто определяемый количественно экономический аспект техниче- ского результата, достигаемого в связи с решением этой задачи, состоит в многократном (по сравнению с оснащением компьютера АМДЗ) снижении материальных затрат, необходимых для осуществления предложенного спо- соба. Сложнее поддается количественным оценкам, но не менее существенен экономический аспект результата, связанный с таким расширением универ- сальности способа, при котором он становится по-настоящему массовым и доступным всем без исключения группам пользователей, предоставляя им возможность осуществления безопасных коммуникаций с любого, а не толь- ко со своего доверенного компьютера.
Технический аспект достигаемого результата состоит в повышении уровня защищенности коммуникаций вследствие сокращения вероятности успешных хакерских атак.
В первом варианте изобретения указанная задача решена тем, что в из- вестном способе осуществления безопасных коммуникаций в компьютерных сетях, основанном на формировании между узлами (шлюзами) сетей или шлюзом и удалённым компьютером криптографически защищенных каналов (туннелей), обеспечивающих функции криптографической защиты данных и позволяющих пользователю работать через защищенное соединение с помо- щью обычного браузера, достаточные условия защиты коммуникаций по имеющемуся в компьютере каналу связи с сетью предоставляют пользовате- з лю временно - на период доверенного сеанса связи (ДСС). В течение ДСС обеспечивают доверенную загрузку проверенной операционной системы (ОС) и организуют защищенное известными методами соединение с требуе- мым удалённым сервисом, причем состав и настройку ОС выбирают такими, чтобы свобода пользователя ограничивалась возможностями, необходимыми и достаточными для ДСС.
Предоставление достаточных условий защиты коммуникаций не посто- янно (как это имеет место, в частности, при оснащении компьютера АМДЗ), а временно - лишь на период ДСС - является ключевым отличительным при- знаком всей группы изобретений, в причинно-следственной связи с которым находится их общий технический результат. Индивидуальным отличитель- ным признаком, являющимся атрибутом лишь конкретного варианта спосо- ба, является вид канала связи с сетью, по которому осуществляют защищен- ные коммуникации. Для первого варианта этот канал, таким образом, - имеющийся (таковым могут быть, в частности, кабельные, волоконно- оптические линии связи, Wi-Fi и т.п.) - т.е. канал, не требующий для своего образования принятия в рамках способа никаких специальных мер, а тот же самый, по которому осуществляется связь компьютера с сетью в обычном режиме работы, вне ДСС.
Отличие, состоящее в том, что доверенную загрузку проверенной ОС и организацию защищенного известными методами соединения осуществляют, в противоположность известным способам, не задолго до того, как они ре- ально потребуются, и не на неопределенно продолжительное время, а лишь на период ДСС, приводит к сокращению времени, в течение которого дове- ренная система открыта для доступа извне и является потенциальным объек- том хакерских атак. Этот фактор будет детализирован далее - при уточнении рассмотренного основного отличительного признака.
Выбор состава и настройки ОС такими, чтобы свобода пользователя ограничивалась возможностями, необходимыми и достаточными для ДСС, способствует достижению технического результата благодаря тому, что тем самым пользователь лишается возможности, случайно или преднамеренно, совершать нечто «лишнее», в особенности, то, что при работе с соответст- вующими удаленными сервисами является недопустимым.
Для связи в течение ДСС целесообразно использовать протокол управ- ления передачей/Интернет-протокол типа TCP/IP (Transport Control Proto- col/Internet Protocol), а защищенное соединение организовывать методами, стандартизованными для сетей VPN (Virtual Private Network). Тем самым обеспечивается преемственность нового способа наиболее универсальным и широко применяемым техническим решениям в области информационных технологий. Кроме того, очевидно, что использование VPN на базе TCP/IP не по- стоянно, а временно, значительно повышает безопасность соединения, т.к. чем меньше время использования криптографических ключей, тем меньше и вероятность их дискредитации.
В течение ДСС целесообразно поддерживать достаточные условия для взаимной аутентификации пользователя и затребованного им удалённого сервиса компьютерной сети посредством криптографической процедуры электронной подписи (ЭП). ЭП, как известно, является наиболее эффектив- ным и универсальным методом взаимной идентификации/аутентификации сторон в процессе их электронных коммуникаций. Поддержание достаточ- ных условий ЭП в течение ограниченного времени ДСС, очевидно, дешевле, чем постоянно, а также, аналогично вышеизложенному, при этом сокращает- ся вероятность дискредитации секретных ключей подписания и проверки подписи.
Поддержание достаточных условий ЭП в течение ограниченного вре- мени ДСС в случае, если информация имеет формат XML (extensible Markup Language), заслуживает выделения в отдельный отличительный признак, по- скольку, как известно, работа с документами в формате XML с использова- нием ЭП состоит из двух этапов - относительно длительный этап подготовки XML и относительно непродолжительный этап подписания. Так как отправ- ляемый XML-файл может быть подготовлен пользователем заранее (за пре- делами ДСС), то это сокращает время вероятных атак на ключи подписания и ключи VPN, и, соответственно, вероятность их дискредитации. Если объём XML-файла относительно мал, то процедуру подписания/проверки ЭП целе- сообразно проводить для самого файла, а в противном случае - для его хэш- функции. Эти процедуры в приводимых далее примерах реализации способа будут детализированы.
Реализация концепции ДСС в первом варианте способа требует приме- нения на стороне пользователя единственного специализированного аппа- ратного средства (клиента ДСС), используемого для доверенной загрузки компьютера.
Клиент ДСС представляет собой съёмный носитель информации, на- пример, с USB-интерфейсом для связи с компьютером, выполненный, в част- ности, в форм-факторе «USB-ключ». В памяти клиента ДСС целесообразно выделить области с разными атрибутами доступа, в частности, ROM, RW и hidden (доступ по предъявлении PIN-кода), причем в защищенную от несанк- ционированных изменений область ROM (Read Only Memory) целесообразно заранее записать, по меньшей мере, одну из следующих групп данных: вы- шеупомянутая ОС, браузер, собственная криптографическая подсистема, программные средства организации защищенного соединения, закрытые ключи и сертификаты. Доверенную загрузку компьютера следует осуществлять из области ROM клиента ДСС без использования жёсткого диска компьютера, в содер- жимом которого уверенности быть не может. Затем следует в заранее задан- ной последовательности стартовать браузер и устанавливать ДСС с защитой соединения криптографическими процедурами, предусмотренными в крип- тографической подсистеме клиента ДСС. Как правило, целесообразно зада- вать последовательность указанных действий в порядке их перечисления, од- нако в технически обоснованных случаях возможна ее замена на обратную.
Полная изолированность и доверенность программной среды клиента ДСС - отчуждаемого от компьютера аппаратного средства, для которого мо- жет быть назначен особый режим хранения - способны обеспечить твердые гарантии безопасности коммуникаций в течение ДСС.
Разграничение доступа к областям памяти клиента ДСС целесообразно осуществлять специальной программой, активируемой по меньшей мере од- ной двунаправленной командой обмена данными между соответствующей прикладной задачей и компьютером пользователя, задаваемого в пользова- тельском интерфейсе клиент ДСС, или заданием в исходных данных значе- ния какого-либо параметра выходящим за пределы области его допустимых (имеющих реальный смысл) значений. Такое техническое решение позволяет существенно сократить время, отведенное для управления резервами памяти клиента ДСС, а значит - и вероятность успешной хакерской атаки на их со- держимое.
На стороне же администратора удалённого сервиса, с которым уста- навливают защищенное соединение, целесообразно проводить авторизацию пользователя для определения его прав доступа к соответствующей группе сервисов и, при положительном результате, соединять его с затребованным им сервисом. Здесь сокращение времени, отведенного на авторизацию поль- зователей, соответственно, способствует повышению надежности авториза- ции.
Особенность описанного первого - наиболее простого в осуществлении - варианта способа состоит в том, что клиент ДСС, наряду с исполнением своей основной функции - доверенной загрузки компьютера - должен распо- знавать тип имеющегося в компьютере канала связи с сетью и, соответствен- но, адаптироваться под один из множества возможных вариантов настроек этого канала. В связи с тем, что число видов используемых на практике кана- лов и возможных вариантов их настроек не только велико, но и имеет тен- денцию к дальнейшему росту, оценки показывают, что на текущий момент ~ 30% возможных каналов связи и их настроек могут выпасть из области под- держания клиента ДСС. Для применения в этих условиях предназначен второй вариант способа, характеризующийся выделением для ДСС специализированного канала связи с сетью, все настройки которого заранее определены и фиксированы. При этом, однако, для пользователя возникают некоторые неудобства, связанные с тем, что во втором варианте способа единственным аппаратным средством, которым должен располагать пользователь - загрузочным - уже не обойтись, и потребуется второе аппаратное средство - каналообразующее.
Второй вариант способа состоит в том, что в известном способе осуще- ствления безопасных коммуникаций в компьютерных сетях, основанном на формировании между узлами (шлюзами) сетей или шлюзом и удалённым компьютером криптографически защищенных каналов (туннелей), обеспечи- вающих функции криптографической защиты данных и позволяющих поль- зователю работать через защищенное соединение с помощью обычного брау- зера, достаточные условия защиты коммуникаций по специализированному каналу связи с сетью также предоставляют пользователю временно - на пе- риод ДСС.
Однако здесь с помощью отдельного технического средства этот спе- циализированный канал связи сначала формируют, а доверенную загрузку проверенной ОС, состав и настройку которой также выбирают такими, чтобы свобода пользователя ограничивалась возможностями, необходимыми и дос- таточными для ДСС, обеспечивают далее. В заключение организуют защи- щённое известными методами соединение с требуемым удалённым сервисом.
Для связи в течение ДСС и во втором варианте способа, по вышеука- занным в описании первого варианта способа причинам, также целесообраз- но использовать протокол TCP/IP, а защищенное соединение организовывать методами, стандартизованными для сетей VPN.
По этим же причинам, в течение ДСС здесь также целесообразно под- держивать достаточные условия для взаимной аутентификации пользователя и затребованного им удалённого сервиса компьютерной сети посредством криптографической процедуры ЭП.
Для защиты посредством процедуры ЭП информации в формате XML в нем в течение ДСС также целесообразно поддерживать соответствующие достаточные условия. Если объём XML-файла относительно мал, то проце- дуру подписания/проверки ЭП целесообразно проводить для самого файла, а в противном случае - для его хэш-функции.
Реализация концепции ДСС во втором варианте способа требует со- вместного применения на стороне пользователя двух аппаратных средств: одного общего применения - для формирования специализированного канала связи с сетью, и одного специализированного, применяемого для доверенной загрузки компьютера - клиента ДСС. Использование для формирования спе- циализированного канала аппаратного средства общего применения (из чис- ла серийно выпускаемых и поступающих в широкую продажу) способствует существенному удешевлению подготовки к осуществлению второго варианта способа.
Клиент ДСС, как и в первом варианте, здесь также должен представ- лять собой съёмный носитель информации, в памяти которого выделяют об- ласти с разными атрибутами доступа, в т.ч. защищенную от несанкциониро- ванных изменений область ROM. В последнюю заранее записывают, по меньшей мере, одну из следующих групп данных: вышеупомянутая ОС, браузер, собственная криптографическая подсистема, программные средства организации защищенного соединения, закрытые ключи и сертификаты. За- грузку компьютера здесь также осуществляют из области ROM клиента ДСС без использования жёсткого диска, далее в заранее заданной последователь- ности стартуют браузер и устанавливают ДСС с защитой соединения по сформированному специализированному каналу криптографическими про- цедурами, предусмотренными в криптографической подсистеме клиента ДСС. При выборе последовательности чередования указанных действий сле- дует руководствоваться приведенными для первого варианта соображениями.
Для формирования же специализированного канала связи с сетью мож- но использовать, например, подходящую по характеристикам модель моду- лятора-демодулятора сигнала в принятый операторами сотовой связи фор- мат, в частности, формат 3G (ЗО-модема). Как правило, наличие в такого ро- да канал ообразующих аппаратных средствах, в частности, в ЗО-модемах, именных (персонифицированных) SIM-карт, создает администраторам уда- ленных сервисов дополнительные возможности по аутентификации вышед- ших на связь пользователей. Для их аутентификации могут быть дополни- тельно использованы данные, содержащиеся в памяти модема, например, в установленной в него SIM-карте с идентификационными данными абонента.
Во втором варианте способа разграничение доступа к областям памяти клиента ДСС также, в целях сокращения времени, целесообразно осуществ- лять специальной программой, активируемой по меньшей мере одной двуна- правленной командой обмена данными между соответствующей прикладной задачей и компьютером пользователя, задаваемого в пользовательском ин- терфейсе клиент ДСС, или заданием в исходных данных значения какого- либо параметра выходящим за пределы области его допустимых значений.
Соединять пользователя с затребованным им удаленным сервисом, на стороне администратора такового, также целесообразно только при положи- тельном результате авторизации пользователя на предмет определения его прав доступа к соответствующей группе сервисов. Неудобств, связанных с необходимостью совместного применения во втором варианте способа двух разнородных технических средств, можно из- бежать в третьем варианте способа, основанном на применении на стороне пользователя единственного комплексного технического средства с расши- ренной функциональностью, осуществляющего не только доверенную за- грузку компьютера для ДСС, но и формирование специализированного кана- ла связи с сетью, физически к этому средству привязанному. При этом, одна- ко, происходит некоторое сужение функциональных возможностей способа, связанное с безвариантным заданием специализированного канала, что для определенных условий является недостатком. Поэтому третий вариант спо- соба нельзя считать оптимальным для всех случаев применения и исклю- чающим первые два, однако его следует, тем не менее, рассматривая наряду с ними, считать наиболее совершенным.
Здесь в известном способе осуществления безопасных коммуникаций в компьютерных сетях, основанном на формировании между узлами (шлюза- ми) сетей или шлюзом и удалённым компьютером криптографически защи- щённых каналов (туннелей), обеспечивающих функции криптографической защиты данных и позволяющих пользователю работать через защищенное соединение с помощью обычного браузера, достаточные условия защиты коммуникаций по специализированному каналу связи с сетью, аналогично двум первым вариантам, также предоставляют пользователю временно - на период ДСС.
Однако в третьем варианте способа специализированный канал связи формируют и доверенную загрузку проверенной ОС осуществляют с помо- щью единственного комплексного каналообразующего и загрузочного тех- нического средства. Далее организуют защищенное известными методами соединение с требуемым удалённым сервисом. При этом конфигурацию ОС, по вышеуказанным причинам, задают ограничивающей свободу пользовате- ля возможностями, необходимыми и достаточными для осуществления ДСС.
Для связи в течение ДСС и в третьем варианте способа целесообразно использовать протокол TCP/IP, а защищенное соединение организовывать методами, стандартизованными для сетей VPN.
В течение ДСС и здесь целесообразно поддерживать достаточные ус- ловия для взаимной аутентификации пользователя и затребованного им уда- лённого сервиса компьютерной сети посредством криптографической проце- дуры ЭП.
Аналогично, для защиты посредством процедуры ЭП информации в формате XML в течение ДСС здесь также целесообразно поддерживать соот- ветствующие достаточные условия. Точно так же, если объём XML-файла относительно мал, то процедуру подписания/проверки ЭП целесообразно проводить для самого файла, а в противном случае - для его хэш-функции.
Специализированное комплексное каналообразующее и загрузочное аппаратное средство, применяемое в третьем варианте способа (клиент ДСС+) должно совмещать в себе функции модулятора- демодулятора сигнала в принятый операторами сотовой связи формат и съемного носителя инфор- мации. В памяти последнего также выделяют области с разными атрибутами доступа, в т.ч. защищенную от несанкционированных изменений область ROM, в которую заранее записывают, по меньшей мере, одну из следующих групп данных: вышеупомянутая ОС, браузер, собственная криптографиче- ская подсистема, программные средства организации защищенного соедине- ния, закрытые ключи и сертификаты. Загрузку компьютера и в третьем вари- анте способа осуществляют из области ROM клиента ДСС+ без использова- ния жёсткого диска, далее в заранее заданной последовательности стартуют браузер и устанавливают ДСС с защитой соединения по сформированному специализированному каналу криптографическими процедурами, преду- смотренными в криптографической подсистеме клиента ДСС+. При выборе последовательности чередования указанных действий здесь также следует руководствоваться приведенными для первого варианта соображениями.
По меньшей мере одну из вышеупомянутых групп данных целесооб- разно хранить в устанавливаемом внутрь клиента ДСС+ отдельном аппарат- ном модуле, например, sd-карте, причем после установки этого модуля его следует механически зафиксировать в корпусе клиента ДСС+ так, чтобы из- влечь его без разрушения было бы невозможно. Данная мера позволяет обес- печить уровень защиты от несанкционированной модификации данных, хра- нящихся в отчуждаемой части памяти клиента ДСС+, не хуже, чем всех про- чих данных. Ее можно осуществить, например, капельной пропиткой места установки извлекаемого модуля в корпус клиента ДСС+ низковязким клеем на основе мономера цианакрилата.
Разграничение доступа к областям памяти клиента ДСС+ в третьем ва- рианте способа также, в целях сокращения времени, целесообразно осущест- влять специальной программой, активируемой, по меньшей мере одной дву- направленной командой обмена данными между соответствующей приклад- ной задачей и компьютером пользователя, задаваемого в пользовательском интерфейсе клиент ДСС, или заданием в исходных данных значения какого- либо параметра выходящим за пределы области его допустимых значений.
Поскольку клиент ДСС+, будучи и каналообразующим аппаратным средством, может содержать именную (персонифицированную) SIM-карту, у администраторов удаленных сервисов и здесь появляются дополнительные возможности по аутентификации вышедших на связь с ними пользователей. Для их дополнительной аутентификации можно использовать данные, со- ю держащиеся в памяти каналообразующей части клиента ДСС+, например, в установленной в него SIM-карте с идентификационными данными абонента. Кроме того, в число опций клиента ДСС+, по понятным соображениям, целе- сообразно включить возможность его работы в режиме обычного модема для формирования канала связи компьютера пользователя с сетью вне ДСС.
Очевидно, что и здесь соединять пользователя с затребованным им уда- ленным сервисом, на стороне администратора такового, также целесообразно только при положительном результате авторизации пользователя на предмет определения его прав доступа к соответствующей группе сервисов.
Вариант осуществления изобретения
В качестве общего для всех вариантов и наиболее интересного примера осуществления описанного способа приведем последовательность действий по защите посредством ЭП XML-файла, созданного на пользовательской стороне.
Для этого на пользовательской стороне (клиента ДСС или клиента ДСС+) используют программный модуль интеграции, встроенный как плагин (расширение) браузера и предназначенный для инициирования выполнения операций с ЭП. На серверной стороне устанавливают программные средства санации файлов, проводящие контроль корректности XSD-схем полученных XML-файлов и удаление из них несанкционированных операций. Таким об- разом может быть сформирован (в т.ч. вне ДСС) XML-файл известной струк- туры, который будет подписан ЭП на пользовательской стороне и далее пе- редан удаленному сервису с соблюдением требований безопасности. Приме- нение ЭП позволяет контролировать целостность сообщения на стадиях пе- редачи и санации и извещать пользователя о приеме информации, что повы- шает надежность ее обработки.
Запрос на доступ к требуемому документу отправляется пользователем на сервер в формате HTTP://URL/. На серверной стороне производят выбор формы и Java-скрипта для формирования ЭП (форма может быть частично заполнена) и отправляют пользователю. На пользовательской стороне проис- ходит визуализация и ручное заполнение формы. После этого там запускают Java-скрипт (вызов по кнопке «ОК»), далее формируют XML-файл, подписы- вают его ЭП, записывают ЭП в XML или в отдельный файл и отправляют XML-файл, включающий ЭП, на сервер (рассматривается случай, когда XML-файл относительно мал по объему и ЭП подписывается он сам).
Получив эти данные, на серверной стороне (администратором удален- ного сервиса) проверяется ЭП XML-файла, и, если таковая верна, то проверя- ется корректность его XSD-схемы и производится санация - удаляются не- санкционированные операции. Далее, если итоговый XML-файл корректен, то формируется уведомление «документ принят» и в форме HTML-страницы с уведомлением отправляется пользователю. Если же ЭП неверна или XML- файл некорректен, то формируется код ошибки и также отправляется пользо- вателю.
В итоге на пользовательской стороне происходит визуализация под- тверждения «документ принят» или кода ошибки, чем и завершается ДСС.
В случае, когда XML-файл по объему относительно велик, то на поль- зовательской стороне после ручного заполнения формы он подготавливается к отправке и отправляется на сервер. Там проверяется его XSD-схема, уда- ляются несанкционированные операции, и, если итоговый XML-файл кор- ректен, то по нему рассчитывается хэш-функция. Далее на сервере произво- дят формирование и передачу пользователю HTML-формы с хэш-функцией и Java-скриптом.
На пользовательской стороне при этом визуализируется форма, содер- жащая хэш-функцию, получив которые, пользователь нажимает кнопку «ОК». Далее он подписывает хэш-функцию ЭП, записывает ЭП и хэш- функцию в XML-файл и передает на сервер. Там, в свою очередь, проверяет- ся ЭП хэш-функции из XML-файла, далее, если таковая верна, то сравнивает- ся пришедшая хэш-функция с ранее вычисленной, и, если хэш-функции сов- падают, то формируется уведомление «документ принят» и отправляется пользователю.
Код ошибки на серверной стороне формируется и отправляется пользо- вателю в следующих трех случаях: если первоначальный XML-файл некор- ректен, если ЭП хэш-функции неверна, или пришедшая и вычисленная хэш- функции не совпадают. ДСС, как и в случае, рассмотренном выше, заверша- ется визуализацией у пользователя подтверждения «документ принят» или ошибки.
Промышленная применимость
Способ может найти применение в самых разнообразных компьютер- ных системах информационного общества - как общедоступных, так и кор- поративных. Наиболее явственно преимущества способа должны проявиться в системах предоставления государственных услуг в электронном виде (т.н. «электронного правительства»), при дистанционном банковском обслужива- нии (в этой сфере клиент ДСС или клиент ДСС+ оптимально подходят на роль т.н. «электронного средства платежа», предусмотренного Федеральным законом Российской Федерации N° 161-ФЗ «О национальной платежной сис- теме»), а также во многих других областях - в частности, в информационных и телекоммуникационных системах медицинского назначения. Патентуемый способ, при всей его кажущейся простоте, нет оснований считать непосредственно вытекающим из достигнутого уровня техники, и, по имеющимся данным, он нов. Концепция ДСС как таковая и способ ее реали- зации, характеризующиеся вышеприведёнными отличительными признака- ми, инвариантны относительно используемых информационных технологий и конфигураций компьютеров, расширяя собою общепринятую парадигму информационной безопасности динамическим формированием доверенной вычислительной среды путем использования проверенной ОС и функцио- нального программного обеспечения в течение ограниченного времени сеан- са взаимодействия пользователя с информационным ресурсом. При этом в социальном: аспекте важно то, что отказ от поддержания доверенной среды в течение времени невостребованности защищенного взаимодействия в пользу концепции ДСС исключает неизбежный ранее фактор «привязанности» поль- зователя и средств обеспечения информационной безопасности к конкрет- ным компьютерам, расширяя тем самым свободу пользователя.
Л И Т Е Р А Т У Р А
1. Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, техноло- гии, протоколы. - СПб: Питер, 2002 - 672 с.
2. Орлов С. Виртуальные частные сети: от IP Sec к SSL. Журнал сете- вых решений/LAN, 2008, М>3.
3. Патент России на полезную модель N° 83862, 2009.
4. Конявский В. А. Управление защитой информации на базе СЗИ НСД «Аккорд». - М., Радио и связь, 1999 - 325 с.

Claims

ФОРМУЛА ИЗОБРЕТЕНИЯ
1. Способ осуществления безопасных коммуникаций в компьютерных сетях, основанный на формировании между узлами (шлюзами) сетей или шлюзом и удалённым компьютером криптографически защищенных каналов (туннелей), обеспечивающих функции криптографической защиты данных и позволяющих пользователю работать через защищённое соединение с помо- щью обычного браузера, ОТЛИЧАЮЩИЙСЯ тем, что в нём достаточные условия защиты коммуникаций по имеющемуся в компьютере каналу связи с сетью предоставляют пользователю временно - на период доверенного сеан- са связи (ДСС) - в течение которого обеспечивают доверенную загрузку про- веренной операционной системы (ОС) и организуют защищённое известны- ми методами соединение с требуемым удалённым сервисом, причем состав и настройку ОС выбирают такими, чтобы свобода пользователя ограничива- лась возможностями, необходимыми и достаточными для ДСС.
2. Способ по п.1, ОТЛИЧАЮЩИЙСЯ тем, что в нём для связи в тече- ние ДСС используют протокол управления передачей/Интернет-протокол TCP/IP (Transport Control Protocol/Internet Protocol), а защищённое соедине- ние организуют методами, стандартизованными для сетей VPN (Virtual Pri- vate Network).
3. Способ по п.1, ОТЛИЧАЮЩИЙСЯ тем, что в нём в течение ДСС поддерживают достаточные условия для взаимной аутентификации пользо- вателя и удалённого сервиса компьютерной сети посредством криптографи- ческой процедуры электронной подписи (ЭП).
4. Способ по п.1, ОТЛИЧАЮЩИЙСЯ тем, что в нём в течение ДСС поддерживают достаточные условия для защиты посредством процедуры ЭП информации в формате XML (extensible Markup Language), заранее (вне ДСС) подготовленной пользователем для передачи в компьютерную сеть, причём, если объём XML-файла относительно мал, то процедуру подписа- ния/проверки ЭП проводят для самого файла, а в противном случае - для его хэш-функции.
5. Способ по п.1, ОТЛИЧАЮЩИЙСЯ тем, что в нём на стороне поль- зователя для загрузки компьютера используют специализированное аппарат- ное средство (клиент ДСС), представляющее собой съёмный носитель ин- формации, в памяти которого выделяют области с разными атрибутами дос- тупа, в т.ч. защищённую от несанкционированных изменений область ROM (Read Only Memory), в которую заранее записывают, по меньшей мере, одну из следующих групп данных: вышеупомянутая ОС, браузер, собственная криптографическая подсистема, программные средства организации защи- щённого соединения, закрытые ключи и сертификаты, причём загрузку ком- пьютера осуществляют из области ROM клиента ДСС без использования жё-
14
ЗАМЕНЯЮЩИЙ ЛИСТ (ПРАВИЛО 26) сткого диска, далее в заранее заданной последовательности стартуют браузер и устанавливают ДСС с защитой соединения криптографическими процеду- рами, заложенными в криптографической подсистеме клиента ДСС.
6. Способ по п.п. 1, 5, ОТЛИЧАЮЩИЙСЯ тем, что в нем разграниче- ние доступа к областям памяти клиента ДСС осуществляют специальной программой, активируемой по меньшей мере одной двунаправленной коман- дой обмена данными между соответствующей прикладной задачей и компь- ютером пользователя, задаваемой в пользовательском интерфейсе клиента ДСС, или заданием в исходных данных значения какого-либо параметра вы- ходящим за пределы области его допустимых (имеющих реальный смысл) значений.
7. Способ по п.1 ОТЛИЧАЮЩИЙСЯ тем, что в нём на стороне адми- нистратора удалённого сервиса, с которым устанавливают защищенное со- единение, проводят авторизацию пользователя для определения его прав дос- тупа к соответствующей группе сервисов и, при положительном результате, соединяют его с затребованным им сервисом.
8. Способ осуществления безопасных коммуникаций в компьютерных сетях, основанный на формировании между узлами (шлюзами) сетей или шлюзом и удалённым компьютером криптографически защищенных каналов (туннелей), обеспечивающих функции криптографической защиты данных и позволяющих пользователю работать через защищённое соединение с помо- щью обычного браузера, ОТЛИЧАЮЩИЙСЯ тем, что в нём достаточные условия защиты коммуникаций по специализированному каналу связи с се- тью предоставляют пользователю временно - на период ДСС - в течение ко- торого с помощью отдельного каналообразующего технического средства формируют специализированный канал, далее обеспечивают доверенную за- грузку проверенной ОС, и организуют защищённое известными методами соединение с требуемым удалённым сервисом, причем состав и настройку ОС выбирают такими, чтобы свобода пользователя ограничивалась возмож- ностями, необходимыми и достаточными для ДСС.
9. Способ по п.8, ОТЛИЧАЮЩИЙСЯ тем, что в нём для связи в тече- ние ДСС используют протокол TCP/IP, а защищённое соединение организу- ют методами, стандартизованными для сетей VPN.
10. Способ по п.8, ОТЛИЧАЮЩИЙСЯ тем, что в нём в течение ДСС поддерживают достаточные условия для взаимной аутентификации пользо- вателя и удалённого сервиса компьютерной сети посредством криптографи- ческой процедуры ЭП.
11. Способ по п.8, ОТЛИЧАЮЩИЙСЯ тем, что в нём в течение ДСС поддерживают достаточные условия для защиты посредством процедуры ЭП
15
ЗАМЕНЯЮЩИЙ ЛИСТ (ПРАВИЛО 26) информации в формате XML, заранее (вне ДСС) подготовленной пользовате- лем для передачи в компьютерную сеть, причём, если объём XML-файла от- носительно мал, то процедуру подписания/проверки ЭП проводят для самого файла, а в противном случае - для его хэш-функции.
12. Способ по п.8, ОТЛИЧАЮЩИЙСЯ тем, что в нём на стороне поль- зователя для формирования специализированного канала связи с сетью и за- грузки компьютера совместно используют каналообразующее аппаратное средство общего применения и специализированное загрузочное аппаратное средство (клиент ДСС), представляющее собой съёмный носитель информа- ции, в памяти которого выделяют области с разными атрибутами доступа, в т.ч. защищённую от несанкционированных изменений область ROM, в кото- рую заранее записывают, по меньшей мере, одну из следующих групп дан- ных: вышеупомянутая ОС, браузер, собственная криптографическая подсис- тема, программные средства организации защищённого соединения, закры- тые ключи и сертификаты, причём загрузку компьютера осуществляют из области ROM клиента ДСС без использования жёсткого диска, далее в зара- нее заданной последовательности стартуют браузер и устанавливают ДСС с защитой соединения по сформированному специализированному каналу криптографическими процедурами, предусмотренными в криптографической подсистеме клиента ДСС.
13. Способ по п.п.8, 12, ОТЛИЧАЮЩИЙСЯ тем, что в нём для форми- рования специализированного канала связи с сетью используют подходящую модель модулятора-демодулятора сигнала в принятый операторами сотовой связи формат (модема), а на стороне администратора удалённого сервиса, с которым устанавливают защищённое соединение, для аутентификации поль- зователя дополнительно используют данные, содержащиеся в памяти моде- ма, например, в установленной в него SIM-карте с идентификационными данными абонента.
14. Способ по п.п. 8, 12, ОТЛИЧАЮЩИЙСЯ тем, что в нем разграни- чение доступа к областям памяти клиента ДСС осуществляют специальной программой, активируемой по меньшей мере одной двунаправленной коман- дой обмена данными между соответствующей прикладной задачей и компь- ютером пользователя, задаваемой в пользовательском интерфейсе клиента ДСС, или заданием в исходных данных значения какого-либо параметра вы- ходящим за пределы области его допустимых (имеющих реальный смысл) значений.
15. Способ по п.8, ОТЛИЧАЮЩИЙСЯ тем, что в нём на стороне ад- министратора удалённого сервиса, с которым устанавливают защищённое соединение, проводят авторизацию пользователя для определения его прав доступа к соответствующей группе сервисов и, при положительном результа- те определения, соединяют его с затребованным им сервисом.
16
ЗАМЕНЯЮЩИЙ ЛИСТ (ПРАВИЛО 26)
16. Способ осуществления безопасных коммуникаций в компьютерных сетях, основанный на формировании между узлами (шлюзами) сетей или шлюзом и удалённым компьютером криптографически защищенных каналов (туннелей), обеспечивающих функции криптографической защиты данных и позволяющих пользователю работать через защищенное соединение с помо- щью обычного браузера, ОТЛИЧАЮЩИЙСЯ тем, что в нём достаточные условия защиты коммуникаций по специализированному каналу связи с се- тью предоставляют пользователю временно - на период ДСС - в течение ко- торого с помощью комплексного каналообразующего и загрузочного техни- ческого средства формируют специализированный канал и обеспечивают до- веренную загрузку проверенной ОС, а также организуют защищённое из- вестными методами соединение с требуемым удалённым сервисом, причем состав и настройку ОС выбирают такими, чтобы свобода пользователя огра- ничивалась возможностями, необходимыми и достаточными для ДСС.
17. Способ по п.16, ОТЛИЧАЮЩИЙСЯ тем, что в нём для связи в те- чение ДСС используют протокол TCP/IP, а защищённое соединение органи- зуют методами, стандартизованными для сетей VPN.
18. Способ по п.16, ОТЛИЧАЮЩИЙСЯ тем, что в нём в течение ДСС поддерживают достаточные условия для взаимной аутентификации пользо- вателя и удалённого сервиса компьютерной сети посредством криптографи- ческой процедуры ЭП.
19. Способ по п.16, ОТЛИЧАЮЩИЙСЯ тем, что в нём в течение ДСС поддерживают достаточные условия для защиты посредством процедуры ЭП информации в формате XML, заранее (вне ДСС) подготовленной пользовате- лем для передачи в компьютерную сеть, причём, если объём XML-файла от- носительно мал, то процедуру подписания/проверки ЭП проводят для самого файла, а в противном случае - для его хэш-функции.
20. Способ по п.16, ОТЛИЧАЮЩИЙСЯ тем, что в нём на стороне пользователя для формирования специализированного канала связи с сетью и загрузки компьютера используют специализированное комплексное канало- образующее и загрузочное аппаратное средство (клиент ДСС+), совмещаю- щее в себе функции, например, модулятора-демодулятора сигнала в приня- тый операторами сотовой связи формат, и съемного носителя информации, в памяти которого выделяют области с разными атрибутами доступа, в т.ч. за- щищённую от несанкционированных изменений область ROM, в которую за- ранее записывают, по меньшей мере, одну из следующих групп данных: вы- шеупомянутая ОС, браузер, собственная криптографическая подсистема, программные средства организации защищённого соединения, закрытые ключи и сертификаты, причём загрузку компьютера осуществляют из облас- ти ROM клиента ДСС+ без использования жёсткого диска, далее в заранее
17
ЗАМЕНЯЮЩИЙ ЛИСТ (ПРАВИЛО 26) заданной последовательности стартуют браузер и устанавливают ДСС с за- щитой соединения по сформированному специализированному каналу крип- тографическими процедурами, предусмотренными в криптографической под- системе клиента ДСС+.
21. Способ по п.п. 16, 20, ОТЛИЧАЮЩИЙСЯ тем, что в нем по мень- шей мере одну из вышеупомянутых групп данных хранят в устанавливаемом внутрь клиента ДСС+ отдельном аппаратном модуле, например, sd-карте, причем после установки этого модуля его механически фиксируют в корпусе клиента ДСС+ так, чтобы извлечь его без разрушения было бы невозможно.
22. Способ по п.п. 16, 20, ОТЛИЧАЮЩИЙСЯ тем, что в нем разграни- чение доступа к областям памяти клиента ДСС+ осуществляют специальной программой, активируемой по меньшей мере одной двунаправленной коман- дой обмена данными между соответствующей прикладной задачей и компь- ютером пользователя, задаваемой в пользовательском интерфейсе клиента ДСС+, или заданием в исходных данных значения какого-либо параметра выходящим за пределы области его допустимых (имеющих реальный смысл) значений.
23. Способ по п.п.16, 20, ОТЛИЧАЮЩИЙСЯ тем, что в нём на стороне администратора удалённого сервиса, с которым устанавливают защищённое соединение, для аутентификации пользователя дополнительно используют данные, содержащиеся в памяти клиента ДСС+, например, в установленной в него SIM-карте с идентификационными данными абонента.
24. Способ по п.16, ОТЛИЧАЮЩИЙСЯ тем, что в нём на стороне ад- министратора удалённого сервиса, с которым устанавливают защищённое соединение, проводят авторизацию пользователя для определения его прав доступа к соответствующей группе сервисов и, при положительном результа- те определения, соединяют его с затребованным им сервисом.
18
ЗАМЕНЯЮЩИЙ ЛИСТ (ПРАВИЛО 26)
PCT/RU2012/000434 2012-06-04 2012-06-04 Способ осуществления безопасных коммуникаций в компьютерных сетях (варианты) WO2013184016A1 (ru)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/RU2012/000434 WO2013184016A1 (ru) 2012-06-04 2012-06-04 Способ осуществления безопасных коммуникаций в компьютерных сетях (варианты)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/RU2012/000434 WO2013184016A1 (ru) 2012-06-04 2012-06-04 Способ осуществления безопасных коммуникаций в компьютерных сетях (варианты)

Publications (1)

Publication Number Publication Date
WO2013184016A1 true WO2013184016A1 (ru) 2013-12-12

Family

ID=49712314

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2012/000434 WO2013184016A1 (ru) 2012-06-04 2012-06-04 Способ осуществления безопасных коммуникаций в компьютерных сетях (варианты)

Country Status (1)

Country Link
WO (1) WO2013184016A1 (ru)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111200815A (zh) * 2019-12-31 2020-05-26 北京指掌易科技有限公司 基于移动应用的信息传输方法及装置
CN112069555A (zh) * 2020-08-13 2020-12-11 中国电子科技集团公司第三十研究所 一种基于双硬盘冷切换运行的安全计算机架构

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2276466C1 (ru) * 2004-11-10 2006-05-10 Общество с ограниченной ответственностью Фирма "Анкад" Способ создания защищенных виртуальных сетей
US20100272031A1 (en) * 2009-04-27 2010-10-28 Mark Grayson System and method for providing intelligent gateway selection in a network environment
RU114217U1 (ru) * 2011-09-12 2012-03-10 Андрей Владимирович Стариков Съемный носитель информации и устройство для воспроизведения информации с него

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2276466C1 (ru) * 2004-11-10 2006-05-10 Общество с ограниченной ответственностью Фирма "Анкад" Способ создания защищенных виртуальных сетей
US20100272031A1 (en) * 2009-04-27 2010-10-28 Mark Grayson System and method for providing intelligent gateway selection in a network environment
RU114217U1 (ru) * 2011-09-12 2012-03-10 Андрей Владимирович Стариков Съемный носитель информации и устройство для воспроизведения информации с него

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KONYAVSKII V.: "Organizatsiya bezopasnogo DBO na osnove SODS ''MARSH!''.", NATSIONALNYI BANKOVSKII ZHURNAL N°9(88) SENTIABR, 2011, pages 84 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111200815A (zh) * 2019-12-31 2020-05-26 北京指掌易科技有限公司 基于移动应用的信息传输方法及装置
CN112069555A (zh) * 2020-08-13 2020-12-11 中国电子科技集团公司第三十研究所 一种基于双硬盘冷切换运行的安全计算机架构
CN112069555B (zh) * 2020-08-13 2022-03-18 中国电子科技集团公司第三十研究所 一种基于双硬盘冷切换运行的安全计算机架构

Similar Documents

Publication Publication Date Title
KR101904177B1 (ko) 데이터 처리 방법 및 장치
Mannan et al. Using a personal device to strengthen password authentication from an untrusted computer
JP6105721B2 (ja) 企業トリガ式２ｃｈｋ関連付けの起動
US8261087B2 (en) Digipass for web-functional description
CN103067399B (zh) 无线发射/接收单元
WO2015180691A1 (zh) 验证信息的密钥协商方法及装置
CN109831311B (zh) 一种服务器验证方法、系统、用户终端及可读存储介质
JP2009117887A (ja) 電子認証装置、電子認証システム、電子認証方法およびこの方法のプログラム
CN109510802B (zh) 鉴权方法、装置及系统
JP2013516685A (ja) コンピューターポリシーを施行するためのシステムおよび方法
US20160261576A1 (en) Method, an apparatus, a computer program product and a server for secure access to an information management system
US20100257359A1 (en) Method of and apparatus for protecting private data entry within secure web sessions
WO2015180689A1 (zh) 验证信息的获取方法及装置
CN107566393A (zh) 一种基于受信任证书的动态权限验证系统及方法
KR101498120B1 (ko) 클라우드 공인인증 시스템 및 그 방법
WO2013184016A1 (ru) Способ осуществления безопасных коммуникаций в компьютерных сетях (варианты)
KR101619928B1 (ko) 이동단말기의 원격제어시스템
CN108900595B (zh) 访问云存储服务器数据的方法、装置、设备及计算介质
KR101858207B1 (ko) 국군 여가복지전용 보안망 시스템
US20220376933A1 (en) Cryptographic services for browser applications
KR100892609B1 (ko) 보안 통신 시스템, 방법, 및 상기 방법을 실행시키기 위한컴퓨터 프로그램을 기록한 매체
Breyha et al. Applied crypto hardening
KR101101190B1 (ko) 보안 통신 시스템, 방법, 및 상기 방법을 실행시키기 위한 컴퓨터 프로그램을 기록한 매체
US11824840B1 (en) System and method for web-browser based end-to-end encrypted messaging and for securely implementing cryptography using client-side scripting in a web browser
KR102086739B1 (ko) 보안 소켓 계층 복호화 장치에서 다양한 전자 서명 알고리즘을 지원하기 위한 전자 재서명 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12878514

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12878514

Country of ref document: EP

Kind code of ref document: A1