WO2019177207A1 - IoT 기반 건강 처방 보조 및 보안 시스템 그리고 방법 - Google Patents

IoT 기반 건강 처방 보조 및 보안 시스템 그리고 방법 Download PDF

Info

Publication number
WO2019177207A1
WO2019177207A1 PCT/KR2018/007896 KR2018007896W WO2019177207A1 WO 2019177207 A1 WO2019177207 A1 WO 2019177207A1 KR 2018007896 W KR2018007896 W KR 2018007896W WO 2019177207 A1 WO2019177207 A1 WO 2019177207A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
user terminal
iot
security
role
Prior art date
Application number
PCT/KR2018/007896
Other languages
English (en)
French (fr)
Inventor
곽경섭
Original Assignee
인하대학교 산학협력단
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 인하대학교 산학협력단 filed Critical 인하대학교 산학협력단
Publication of WO2019177207A1 publication Critical patent/WO2019177207A1/ko

Links

Images

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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/60—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to nutrition control, e.g. diets

Definitions

  • Embodiments of the present invention are based on a connection with IoT devices forming an IoT network in a Health Prescription Assistant system based on the Internet of Things (IoT). For example, pharmaceuticals, food, etc.), and to control and provide security for IoT devices.
  • IoT Internet of Things
  • the present invention was completed with the support of the following research projects.
  • the Internet of Thing includes a physical entity or entity that features an IP address for connecting to the Internet and communication that occurs between these pairs of things, other Internet-enabled devices, and frameworks. Means network.
  • the Internet of Things has many advantages, including improved connectivity that goes beyond scenarios between machines, enabling automation in almost any field.
  • One of the key functions of the IoT is to enable services that all networks of the World Wide Web (WWW) provide for their intended end users and / or things.
  • WWW World Wide Web
  • the IoT's capabilities enable remote support to deliver high-quality telemedicine and healthcare services to patients in a timely manner. For example, in the concept of telemedicine, a healthcare practitioner provides medical care to a patient over a distance to a patient in a remote location (country, ship or aircraft over the ocean).
  • IoT-based healthcare is a promising technology that provides easy and accurate action at the right time by providing many advantageous applications to reduce costs, improve quality of life and improve the efficiency of healthcare.
  • devices and applications must process important personal information, including personal medical data.
  • the application program is connected to a world wide information network that can be accessed anywhere, anytime, user terminal, such as a smart phone, tablet, PC.
  • user terminal such as a smart phone, tablet, PC.
  • personal data collected from wearable sensors with limited resources is vulnerable to privacy issues.
  • Korean Patent Laid-Open No. 10-2000-0066614 relates to a medical device specification management system and a control method thereof, and discloses a technology for providing medical device related information through user authentication.
  • JSON Javascript object notation
  • the present invention relates to a security technique for protecting a patient's medical records and unauthorized access to medically relevant IoT devices in providing an IoT based health prescription assistant (HPA).
  • HPA health prescription assistant
  • secure access control that provides user authentication for IoT-based Health Prescription Assistance (HPA) and ensures protected access to medical IoT devices connected to IoT networks, resources and services related to living IoT devices. It's about technology.
  • IoT Internet of Things
  • a registration control unit for registering in association with the provided identifier information of the corresponding user, an authentication control unit for authenticating the user based on the identifier information of the user terminal, and confirming the role of the corresponding user for the authenticated user, and confirming the identified role
  • a rights control unit for checking an access right granted to the corresponding user based on the above, and the medical service corresponding to the request received from the user terminal based on the identified access right may be provided to the logged in user. Can be.
  • the authority controller may determine whether a role corresponding to the user is a patient, a nurse, a doctor, or a security manager, and check the access authority specified according to a predefined policy with respect to the identified role. have.
  • the role may be determined based on the user's personal information and job experience information.
  • the right control unit may determine whether to allow or reject the request received from the user terminal based on a predetermined context constraint.
  • the authority controller may verify an access right corresponding to the request by verifying a security access token (SAT) received with the request from the user terminal.
  • SAT security access token
  • the security access token is generated by signing using information retrieved based on the policy, authority and context constraints corresponding to the role, to be provided to the user terminal Can be.
  • the authorization controller may forward the request to the corresponding IoT device as the security access token (SAT) is validated.
  • SAT security access token
  • IoT Internet of Things
  • providing identifier information for distinguishing users to be provided with the IoT-based health prescription assistance personal information of the user input from the user terminal Registering in association with the provided identifier information of the corresponding user, authenticating a user based on identifier information of the user terminal, and confirming a role of the authenticated user, and providing the corresponding user with the identified role.
  • a medical service corresponding to a request received from the user terminal may be provided to the logged-in user based on the confirmed access right.
  • HPA IoT-based health prescription assistant
  • SAT secure access token
  • HAP health prescription assistant
  • FIG. 2 is a diagram illustrating a detailed structure of a network for IoT based Health Prescription Assist (HAP) according to one embodiment of the present invention.
  • HAP Health Prescription Assist
  • HAP health prescription assistant
  • FIG. 4 is a diagram provided to explain a policy defined differently for each user's level according to one embodiment of the present invention.
  • FIG. 5 is a flowchart illustrating a connection control method for an IoT-based Health Prescription Assist (HAP) according to an embodiment of the present invention.
  • HAP Health Prescription Assist
  • FIG. 6 is a flowchart illustrating a connection control method when the health prescription assistant and security system are configured with an authentication server and an authorization server according to an embodiment of the present invention.
  • FIG. 7 is a diagram provided to explain a process of generating a secure access token (SAT) in an embodiment of the present invention.
  • FIGS. 8 to 10 are diagrams illustrating scripts related to SAT authentication according to an embodiment of the present invention.
  • FIG. 11 is a view provided to explain an operation of allowing a connection to a medical IoT device by checking a security access token (SAT) according to an embodiment of the present invention.
  • SAT security access token
  • Embodiments of the present invention relate to a technology for providing security in controlling IoT devices related to medical records and medical care of a user in supporting IoT-based u-Health (ie, patient / user health care).
  • IoT-based u-Health ie, patient / user health care.
  • Protected access to user authentication and resources and services eg IoT devices forming an IoT network
  • IoT-based Health Prescription Assistance (HPA) at the security layer for patient health management It is about the technology to ensure.
  • HPA Health Prescription Assistance
  • the present embodiments prevent unauthorized users from connecting to at least one medical IoT device that is forming an IoT network in the security layer, and only authorized users to authorized medical IoT devices according to their ratings.
  • the access control may be performed by one IoT device or may be performed by service.
  • connection control to the requested one IoT device may be performed, and when a connection to a specific medical service is requested, a request for a specific medical service is required.
  • Connection control to a plurality of IoT devices may be performed.
  • access control to a plurality of IoT devices predetermined for gastric cancer examination may be performed.
  • Non-Patent Document described above in order to in this embodiment the user authentication [2] D. Recordon, D. Reed, OpenID 2.0: A platform for user-centric identity management, in Proceedings of the second ACM workshop on Digital identity management, ACM, 2006, pp. 11-16.
  • the OpenID standard presented in can be used.
  • ABAC Attributedbased Access Control
  • DCCapBAC Delegated Context-ware Capability-based Access Control
  • DCCapBAC can delegate to smart gateways (eg, border routers) deployed with medical devices to offload resource-limited medical sensors and actuators from computationally intensive encryption tasks.
  • DCCapBAC can reduce communication and memory overhead associated with making authorization decisions for requests, allowing real-time updates of the patient's physical condition to be released to caregivers.
  • the medical sensor can be made to receive instructions from the caregiver.
  • DCCapBAC delegates validation to the gateway, which can intercept incoming requests and verify permissions to the medical device without communicating with the intermediary party to perform access authorization or denial.
  • an ID provider may represent a server of an ID provider
  • an IoT service provider may represent a server of an IoT service provider
  • the 'health prescription assistance and security system' may be expressed as 'u-Health support system'.
  • HAP health prescription assistant
  • the entire network may include a plurality of user terminals 110, a health prescription assistance and security system 120, and servers 130 of a plurality of identity providers.
  • Each of the user terminals 110 requests the user's authentication to the health prescription assistance and security system 120, and provides access to IoT devices, resources and services related to the IoT devices forming the IoT network, and the health prescription assistance and security. May request system 120. In addition, it is possible to access the desired IoT device according to whether the health prescription assistance and security system 120 is allowed to access.
  • the user terminal is an electronic device possessed by a user such as a patient, a doctor, a senior doctor, a pharmacist, a nurse, and may include a tablet, a PC, a smartphone, and the like.
  • Servers 130 of the plurality of ID providers are server devices networked with the health prescription assistant and security system 120 to authenticate the user based on the openID standard.
  • the user terminal can be authenticated based on this.
  • the ID provider's server is a server device used by many users (many subscribers), such as a server providing a social network service such as Facebook, Instagram, or a portal site such as Google or Yahoo. It may mean.
  • the health prescription assistance and security system 120 may check the resources and services requested by the user terminal, that is, the access right to the IoT device, and may grant access to the user terminal.
  • the health prescription assistant and security system 120 may be connected to the at least one medical IoT device and the IoT network so that the user terminal may access the at least one medical IoT device that is authorized to access.
  • FIG. 2 is a diagram illustrating a detailed structure of a network for IoT based Health Prescription Assist (HAP) according to one embodiment of the present invention.
  • HAP Health Prescription Assist
  • the HPA gateway 210 may play an important role in providing a service through an external connection for a health prescription assistant (HPA).
  • HPA Gateway 210 may monitor and control certified healthcare personnel and may identify certified healthcare professionals and patients.
  • the HPA Gateway 210 may then communicate with a security server 211 to ensure a protected connection to the patient's medical record.
  • the HPA gateway 210 may transmit information, such as a doctor's recommendation and suspected disease, to the computing server 212 based on hospital accessibility.
  • HPA gateway 210 may also record each activity. For example, opening a new session, prescribing medication, proposing a dietary requirement, or recording the wait time after a particular service is requested from a relevant medical staff with a relevant time stamp. Can be recorded.
  • the HPA Gateway 210 may perform an on-demand task arrangement (eg, terminating a particular connection in an emergency or receiving an appropriate command, etc.).
  • the HPA gateway 210 does not correspond to an existing network gateway device, and may correspond to a service application running on a virtual (eg, Amazon Elastic Compute Cloud) or a real system.
  • System specifications such as the number of CPUs, storage, memory, etc., can vary depending on the total number of clients and medical equipment associated with the HPA system.
  • HPA gateway 210 can upgrade specifications using on-demand resource expansion technology for load balancing.
  • the security server 211 may serve to ensure protected access to medical records, sensors, and actuators.
  • the security server 211 may be implemented in the form of providing three types of functions such as authentication, authorization, and auditing.
  • authentication is responsible for identity verification
  • authorization may correspond to a function for protecting medical records and devices from unauthorized access.
  • Auditing can record various interactions (authorization and non-certification) between components for Health Prescription Assistance (HPA). This log can then be analyzed to detect malicious activity.
  • reporting and alerting services such as Elastalert, 2 X-Pack3 can be integrated into the audit service for real-time notification of unauthorized access or intrusion detection.
  • the patient and the smart medication box are included in the smart home 220, where the patient has a body patch that includes different biosensors embedded with appropriate electrodes, and the biosensors can form a body part network.
  • Biochips implanted with body patch sensors can communicate with sensored drug packs using short-range communication technologies such as IPv6-based low-power wireless BAN (6LoWBAN), ZigBee or Bluetooth low energy (BLE).
  • the drug pack then works integrally with the smart pill coated with the sensor contained in the drug pack, but the drug pack sensor is just an RFID chip and the pill sensor may correspond to a special kind coated with a sensing material.
  • the medication pack may be in a specially designed smart medication box.
  • the central sensor inside the smart medication box can record the status of each medication pack and pill.
  • a patient opens a portion of a medication pack to take a particular pill
  • an operating condition that the medication pack has been opened is detected by a sensor attached to the medication pack, and the medication box for subsequent processing and reference. Can be reported to.
  • the data aggregated in the patient BAN can then be stored and later processed by the health cloud computing server as needed.
  • the health database 213 may include a stack of some representative DBs, including food and nutrition DBs, measured biobiomarker DBs, disease related tip DBs, and the like.
  • the food and nutrition DB can provide an extensive food inventory in which the nutritional component is expressed in a structured form.
  • the food and nutrition DB may provide the system with information about how a particular food affects the health of the patient. As such, the food and nutrition DB may facilitate a healthy diet choice.
  • the disease-related tip DB may store information about other patients' advice, achieved experience, and medication.
  • a disease-related tip DB may be provided from a third party that provides business-to-business (B2B) services. In this case, it is necessary to communicate with each other to establish compatibility between the DB service provider and the health prescription correction and security system, and for this communication, an operation to agree to a standard protocol may be performed in advance.
  • B2B business-to-business
  • Computing and control server 212 may be responsible for core computing and decision making that is frequently requested.
  • the aggregated data may be delivered to a health cloud computing and control server for storage, processing, analysis, and visualization, and the computing and control server 212 may correspond to a central hub of health prescription assistance and security systems.
  • the computing and control server 212 may monitor and control user terminals installed at various points, including all user terminals (ie, clients) possessed by doctors and patients.
  • events reported by various terminals eg, sensors, patients, health professionals, and DBs
  • corresponding to the ends of the health prescription assistant and security system may be aggregated and structured commands may be transmitted to the computing and control server 212. have.
  • Computing and control server 212 may analyze the received commands and send results to each end.
  • the smart home 220 may be used to provide the patient with more suitable and comfortable living conditions, including room temperature, proper lighting and proper humidity.
  • health prescription assistance and security systems may require special design of smart home elements.
  • a specially designed refrigerator may be needed to track preserved food items.
  • the refrigerator is composed of several chambers, and each chamber may have several cells.
  • the chamber and the cell may be equipped with a sensor, and the sensor may communicate with the main RFID of the refrigerator.
  • the main RFID may communicate with a server of the smart home 220 and may be connected to the Internet.
  • the smart gateway 230 may represent a resource-rich device that is disposed at the end of the network.
  • the smart gateway 230 may include four planes: a communication plane, an aggregation plane, a decision plane, and a security enforcement plane.
  • the communication plane enables interaction between the multi-protocol device and the network, and may enable communication between a smart object located in a smart home or a medical sensor attached to a patient.
  • the smart object and the wearable sensor may communicate with each other through the smart gateway 230.
  • Aggregation planes can comply with data from medical sensors and publish it to the cloud HPA service.
  • the decision plane can process sensor data, identify health conditions, and make local decisions.
  • Security application planes can be used to protect medical IoT devices from unauthorized access.
  • the plane of the smart gateway can be implemented using a 6LoWPAN border router.
  • HAP health prescription assistant
  • the 3 may include an ID provider 310, an IoT service provider 320, a user terminal 330, and a health prescription assistance and security system 340.
  • the ID provider 310 represents any one of the servers 130 of the plurality of ID providers of FIG. 1, and may interact with users (eg, patients, doctors, nurses) that interact with an IoT-based HPA (IHA). , Pharmacist, etc.) may be provided to the user terminal 330.
  • the user terminal 330 may provide information for identifying an ID of a user used to log in through Facebook, Twitter, and the like.
  • the IoT service provider 320 may provide two types of medical services. For example, an on-device medical service and a cloud medical service may be provided.
  • the medical service in the device may be provided by the medical IoT device and may correspond to a local IoT service.
  • a smart pulse oximeter attached to a patient's body may have a direct search of the oxygen saturation (O2) level in the patient's blood (eg, a doctor searching for and connecting to the device) or a remote search (eg, a cloud). Medical services).
  • the user eg, patient, caregiver, patient family, etc.
  • the smart pulse oximeter may periodically display O 2 levels.
  • Cloud medical services are hosted in the cloud and can allow remote access by medical services in the local device.
  • a cloud health service can maintain a device profile store, which contains a repository containing subscription information about health services within the device, which includes which users subscribe to which services and which configurations and settings are registered. It may include a repository.
  • the cloud medical service may provide an interface for creating and managing subscription and / or access rules for medical services in the device. For example, the user may set a rule to receive a notification when the O 2 level falls below a predetermined threshold.
  • the ID provider 310, the user terminal 330, the IoT service provider 320, and the health prescription assistant and security system 340 may be connected to each other via a wired or wireless network to exchange information with each other.
  • the health prescription assistant and security system 340 includes a registration authority 341 for registering information related to the user terminal for interaction with the user terminal 330, and an authentication authority 342 for authenticating the user terminal. ), And an authorization authority 343 for ensuring a protected connection to the IoT medical service.
  • the registration controller 341 may register information related to the user terminal 330 for interaction between the user terminal 330 and the health prescription assistance and security system 340, and store and manage the information in the user profile for each user. Can be. For example, the user's personal information (user name, gender, date of birth, user's phone number, mobile phone number, address information, etc.) contained in the hospital medical card is identified by the user's identification information (eg, medical card assigned to the user). IDs such as numbers, employee numbers, etc.) may be stored and managed in the user profile.
  • the registration controller 341 may operate in two modes, a direct mode and a relay mode.
  • the registration controller 341 may receive personal information such as name, date of birth, social security number, credit card information, address information, etc. from the user terminal 330.
  • the registration controller 341 may receive the personal information of the user input from the user terminal 330 through a web / mobile web of a third party such as Google and Twitter. Then, the received personal information can be registered in association with the user's identifier information (eg, an ID such as a medical card number and an employee number assigned to the user). If the registration is successfully completed, a user profile is generated, and the user's profile may be stored and maintained in the user profile database, and a unique user ID (User ID, UID) may be assigned to each user.
  • UID unique user ID
  • the authentication controller 342 may provide the user terminal 230 with a login service for authenticating the user terminal. For example, the authentication controller 342 may request input of login information to the user terminal 330.
  • the authentication controller 342 may transfer the login information received from the user terminal 330 to the ID provider 310 designated by the user terminal 330.
  • the login information may include a login ID (eg, an email address) and a password of the corresponding user subscribed to the website of the ID provider 310 designated by the user terminal.
  • a login ID eg, an email address
  • a password of the corresponding user subscribed to the website of the ID provider 310 designated by the user terminal For example, in order to deliver the login information to the ID provider 310 designated by the user terminal 330, each of the plurality of ID providers registered in the health prescription assistance and security system 340 may be included in the Identity Provider Repository. Identification information and link information for linking to the website of the corresponding ID provider may be matched and stored.
  • the authorization control unit 343 succeeds in authenticating the user terminal 330 based on the login information in the ID provider 310 through the authentication control unit 342, thereby providing a security access token to the authenticated user terminal 330.
  • Token, SAT can be issued.
  • the secure access token is one of the at least one medical IoT devices forming an IoT network, the authorizations corresponding to IoT devices authorized to the authenticated user, services and resources related to the authorized IoT devices ( privileges).
  • the secure access token (SAT) may be encrypted and protected for forgery detection, and the authorization controller 343 first checks the SAT before connecting the user terminal 330 to the medical IoT device, thereby protecting the protected access to the medical IoT. Can be guaranteed.
  • CCapBAC Context aware Capability Based Access Control
  • a nurse may issue only commands (GET, POST, etc.) to specific medical IoT devices such as temperature sensors (thermometers), blood pressure sensors, glucose sensors, insulin pumps, and the like. Only authorized devices can have access.
  • the doctor (grade 2) may have more access rights than the nurse.
  • Bob (Class 2) may have all the rights of Alice (Class 1) and additionally issue commands and access to sensitive medical IoT devices such as EEG, ECG, vision sensors, hearing sensors, etc.
  • You may have Charlie (Class 3) has all the rights that Bob (Class 2) has, but can have access to implanted IoT devices, such as an IoT-enabled pacemaker that is implanted in the body.
  • Charlie (grade 3) may have the authority to prescribe medicines in emergency or fatal situations by issuing orders in smart medicine boxes, such as Pill Bottles.
  • the user terminal may be checked through a process of checking a class according to a role of a user and checking whether an IoT device requested by the user terminal is an IoT device authorized to the user based on a policy set for each user class. Whether to permit access to the corresponding IoT device may be determined. This access control ensures a protected connection from IoT-based HPA to each medical IoT device.
  • the user 410 may represent a user terminal possessed by a consumer of local and cloud IoT services, an application mounted on the terminal, and the like. 4 is based on a context-aware function based access control (CCapBAC) model, each user can be assigned a unique ID.
  • CCapBAC context-aware function based access control
  • the user set SubS may be expressed as Equation 1 below.
  • roles define functions (that is, roles) of users, and whether a user corresponds to a role of a patient, a doctor, a nurse, a system administrator, or a security administrator may be assigned for each user. . Different access rights may be predefined for each role.
  • the role set Rset may be expressed as in Equation 2 below.
  • Operation may include GET, POST, DLETE, PUT, and the like.
  • GET GET request
  • DLETE DLETE
  • PUT PUT
  • a service may represent a service provided by a medical IoT device.
  • each service may be represented as a resource set (res) such as configuration files, sensor data, and the like arranged in a database or device memory.
  • a service according to a user request may be provided, and a privacy request may be confirmed by an access control logic (ACLogic) engine.
  • the service set (SS) and the resource set (Resource Set, RS) may be expressed by Equation 4 below.
  • Permission may represent a permission for a particular mode of work in connection with one or more medical services. Based on access rights, rights holders can perform some tasks on the system. For example, a nurse may be authorized to retrieve thermometer (ie, medical IoT device) readings, but not to order prescriptions (ie, medical IoT devices).
  • the permission set PS may be defined as shown in Equation 5 below based on the work assignment.
  • Attribute constraints can include various types of attributes such as user attributes, role attributes, and medical device attributes that can be used during policy assignment.
  • the attributes can be used for policy assignment, such as user assignment, permission assignment, and task assignment.
  • the user's age / occupational experience may be considered in the user assignment process.
  • the condition that a user (eg doctor) must have 15 years of experience in order to assign / assign a role (eg chief physician) can be pre-specified and based on the user's age, occupational experience, etc., based on these attribute constraints Role can be assigned to each user.
  • attributes of a role can be considered during the assignment of rights. For example, at least one person may be assigned to a senior doctor role, and constraints may be specified in advance such that two nurses may not have access to the same medical device of the patient.
  • device characteristics such as memory, communication interface or energy source (eg battery powered) may be used to determine the task assignment.
  • ROM read-only memory
  • Each element of the attribute set may indicate an attribute type (AT).
  • Attribute element (AE) is a three-dimensional It can be expressed as. For example, (device, memory, 16 MB) represents the capacity of the memory, (patient, age, 45) can represent the age of the patient, and the size of the group can be expressed as (role, size, 15).
  • Attribute constraints (AC) may be represented by a combination of attribute elements (AEs). The combination may be performed by combining, separating and negating the attribute elements AE. For example, assuming that there is a security rule such as "any doctor in cardiac medicine can check the condition of the cardiac pacemaker", the rule may be expressed as Equation 7 below.
  • Context constraints can be specified in advance for use in characterizing the situation of an entity.
  • the entity may include a person, a place, and an object that are considered to be related to the interaction between the user and the medical IoT service.
  • Various types of context can be used, such as time, space, object state, etc., to determine whether to allow / deny requests in the policy evaluation phase. For example, when a medical IoT service request from a user terminal occurs at a specific location, the request may be rejected. In addition, the request may be denied if the request was previously performed or issued after a certain time. In addition, the request may be rejected based on the current state of the medical IoT device (eg, an operation mode (eg, energy saving mode)).
  • the context set may be expressed as Equation 8 below.
  • Each element of the context set may indicate a context type (CT).
  • Each context element (CE) is three-dimensional It can be expressed as. For example, (device, mode, energy saving) may indicate the operating mode of the device, and (doctor, location, coordinates (33.5 °, 86.8 °)) may indicate the location context.
  • the context constraint can be expressed as Equation 9 below.
  • the user assignment represented by denotes a many-to-many mapping between a user and a role, and each user may be assigned a role. In this case, since one role may be assigned to various roles (eg, a patient, a doctor, a nurse, a patient, etc.), one user may belong to several groups.
  • the privilege assignment represented by denotes a multi-to-many mapping between privileges and roles, and specific roles may be assigned to each role in order to access resources.
  • the task assignment represented by denotes a many-to-many mapping between tasks and services, and each service can be assigned a certain number of tasks.
  • the role attribute assignment represents a many-to-many mapping between roles and attribute types, where each role can be assigned an attribute by a system administrator or security administrator.
  • the privilege attribute assignment represented by denotes a many-to-many relationship between a privilege and an attribute type. After the attribute set is first defined, the attribute may be assigned to the privilege by the security administrator.
  • the job attribute assignment represented by denotes a many-to-many relationship between a job and an attribute type, and a property set may be assigned / assigned to a job by a security administrator (ie, a user terminal possessed by the security administrator).
  • a policy is a determination of a user's capabilities, each policy including a subset of permission assignments and task assignments, and not user assignments. User information may not be included in the policy. Policies are defined for roles, and roles can be mapped to users. Accordingly, the user's ability may correspond to a policy defining a role, and the policy may be defined and stored in the policy database of the authorization service.
  • An access control policy encoded based on Extensible Access Control Markup Language (XACML) may be as shown in Table 1 below.
  • a secure access token (SAT) used for access to a medical IoT device may be generated and issued to a user based on a policy expressed as shown in Table 1.
  • the security access token of the above non-patent literature [3] T.
  • JSON Java Script Object Notation
  • JSON The javascript object notation ( JSON ) data interchange format, RFC 7159, http://tools.ietf.org/html/rfc7159.html, 2014 . .
  • the security access token SAT may be attached together with the request.
  • the SAT received from the terminal can be verified in the system or medical IoT device, the access rights of the requester can be confirmed through the SAT check.
  • Context constraints may be applied that allow or deny the request based on the confirmed access rights.
  • FIG. 5 is a flowchart illustrating a connection control method for an IoT-based Health Prescription Assist (HAP) according to an embodiment of the present invention.
  • HAP Health Prescription Assist
  • Each step (steps 510 to 550) in FIG. 5 may be performed by the registration control unit 341, the authentication control unit 342, and the authority control unit 343, which are components of the health prescription assistance and security system 340 of FIG. 3. Can be.
  • the registration controller 341 may provide identifier information for identifying users who wish to receive an IoT-based health prescription assistance (HPA) related medical service. For example, medical card numbers and the like can be provided.
  • HPA health prescription assistance
  • the registration controller 341 may register by storing the personal information of the user input from the user terminal in association with the identifier information of the user.
  • the authentication controller 342 may receive an authentication request of the user terminal 330 from the user terminal 330 that wants to connect to at least one medical IoT device forming the IoT network. .
  • a nurse or a doctor may request a login service to check a medical service related to a patient managed by the user terminal owned by the nurse or doctor.
  • the authentication controller 342 when operating in the relay mode, receives the identifier information of the ID provider specified by the user terminal 330 to authenticate the user terminal 330 using the open ID while receiving a login service request. It can be received together from the terminal 330.
  • the authentication control unit 342 may receive a medical card number, social security number, etc. from the user terminal 330 while receiving a login service request.
  • the authentication controller 342 may authenticate a user based on identifier information of the user terminal.
  • the authentication controller 342 may transmit an authentication request of the user terminal 330 to the corresponding ID provider 310 based on the identification information of the ID provider.
  • any one of a plurality of ID providers displayed on the screen of the user terminal 330 is selected, and the ID selected in the user terminal 330 as the confirmation button is clicked.
  • the login service including the identifier information of the provider 310 may be requested.
  • the ID provider 310 may request security credential information from the user terminal 330.
  • a login ID (email address, etc.) and password information for subscribing to the ID provider's website may be requested.
  • the ID provider 310 receives the security credential information from the user terminal 330 and checks whether the login ID and password information of the user terminal match the ID and password subscribed to the website of the ID provider 310,
  • the user terminal 330 may be authenticated.
  • the ID provider 210 may transmit a Secret Certificate (SCert) to the user terminal 330.
  • SCert Secret Certificate
  • the user terminal 330 receiving the secret certificate is a security that is an authority for access to the medical IoT device (resources related to IoT devices, services) that the user terminal 330 wants to access to the health prescription assistance and security system 240.
  • the creation of a connection token (SAT) may be requested.
  • the authentication controller 342 may receive a request for generating a security access token (SAT) from the user terminal 330.
  • the authentication control unit 342 may receive a secret certificate (SCert) provided by the user terminal 330 from the ID provider 310 together with the user terminal 330 while being requested to generate a security access token (SAT). .
  • the authentication controller 342 may check a grade indicating a role of the user based on the identifier information ID extracted based on the received secret certificate SCert.
  • the authority controller 343 may check the access authority granted to the user based on the confirmed role (that is, the grade).
  • the access right is confirmed for the authenticated user, a medical service corresponding to a request (eg, a request for access / control to the medical IoT device) received from the user terminal may be provided.
  • the authentication control unit 342 may check the received secret certificate (SCert) to extract the identifier information (ID) of the user terminal 330.
  • the authentication controller 342 may extract identifier information of the user terminal 330 from an identity provider repository based on a secret certificate SCert.
  • the authority controller 343 may generate a security access token SAT based on the extracted identifier information of the user terminal 330.
  • the authority controller 343 checks the grade (ie, role) of the user terminal 230 based on the identifier information of the user terminal 230, and confirms the grade (ie, of the identified user terminal 230).
  • Role and a security access token (SAT) representing a policy, a permission, and a context constraint.
  • the authorization controller 243 may issue the SAT by transmitting the generated security access token SAT to the user terminal 230.
  • the authorization controller 243 may determine the access permission by checking the received SAT of the user terminal 330.
  • the medical IoT device which is requested to access from the user terminal 330 may request the presentation of the security access token (SAT) to the user terminal 330 and receive the SAT from the user terminal 330.
  • the authorization controller 243 may transmit the request of the authenticated user terminal 300 to the corresponding IoT device. Then, the IoT device may perform the SAT presentation request and the SAT verification. As such, the access permission may be determined by checking the SAT of the user terminal 330, and the SAT may be encrypted and managed to prevent forgery.
  • FIG. 6 is a flowchart illustrating a connection control method when the health prescription assistant and security system are configured with an authentication server and an authorization server according to an embodiment of the present invention.
  • FIG. 5 illustrates that authentication and authority control are performed by one server
  • authentication and authority control may be performed by separate servers as shown in FIG. 6.
  • the authentication server and the authorization server may be connected to each other by a network.
  • the access control may be composed of two parts, an authentication process 610 and a secure access token (SAT) generation process 620.
  • the authentication process 610 may correspond to a process of allowing the user terminal to select an ID provider when the user terminal requests a login.
  • it may correspond to a series of processes for requesting user credentials such as an e-mail address, encryption, etc., verifying the user credentials, and issuing a secret certificate (SCert) to the user.
  • SCert secret certificate
  • the secure access token (SAT) generation process 620 provides the SCert to the authentication control unit 342 at the user terminal and requests the SAT, and the authentication control unit 342 examines the signature of the ID provider attached to the SCert to validate the SCert. You can check Thereafter, the authentication controller 342 may search for the UID of the user terminal, provide the authority controller 343 with the ID of the user terminal (ie, the UID), and request the user terminal to generate a new SAT. A detailed operation of generating the SAT will be described later with reference to FIG. 7.
  • FIG. 7 is a diagram provided to explain a process of generating a secure access token (SAT) in an embodiment of the present invention.
  • the authorization controller 343 may check whether the user terminal 330 requesting the SAT generation is included in the blacklist (revocation list). It may be 702.
  • the blacklist (revocation list) may include information (eg, ID of the terminal, etc.) associated with the user terminal has been terminated access to the IoT device.
  • the authentication controller 342 may check the received secret certificate (SCert) to extract the identifier information (ID) of the user terminal 330. 703. Then, the authority controller 343 may check whether the user terminal 330 is included in the blacklist based on the identifier information. In this case, as it is determined that the user terminal 330 is not included, the authority controller 343 refers to the role DB in which the corresponding level (ie, role) is stored in accordance with the identifier information of the user terminal, and the user terminal 330. The role of the user terminal 330 may be checked based on the identifier information of the reference numeral 704. That is, the grade corresponding to the role of the user terminal 330 may be checked.
  • the authority controller 343 may extract a policy corresponding to the identified level (ie, role) of the user terminal 330 from the policy DB (705). For example, if the user of the user terminal 330 is a nurse, a predetermined policy corresponding to a nurse may be extracted, and if a user is a doctor, a predetermined policy corresponding to a doctor may be extracted.
  • the authorization controller 343 extracts a permission corresponding to the user terminal 330 from a permission DB, and extracts a context context corresponding to the user terminal 330 from a context constraint DB. It may be done (706).
  • the authority controller 343 may generate a new security access token (SAT) for the user terminal 330 based on the extracted policy, permission, and context context ( 707).
  • SAT security access token
  • Table 2 the SAT generation algorithm shown in Table 2 below may be used. That is, a new secure access token (SAT) representing a policy, a permission, and a context constraint defined for the role of the new user terminal 330 may be generated.
  • the generated SAT is delivered to the user terminal, and the user terminal may need to present the SAT to the medical IoT device in order to access resources and medical services to be provided.
  • the medical IoT device may check the SAT received from the user terminal and grant an access right.
  • the authority controller 343 may digitally sign the generated security access token SAT to protect it from forgery.
  • a digitally signed secure access token (SAT) may be issued to the user terminal 330.
  • Table 3 below may show the SAT encoded in JASON format.
  • ID represents an identifier of the SAT, and a unique random number may be generated and assigned to the ID field.
  • Two SATs may not have the same ID. That is, different IDs may be assigned for each SAT.
  • Issue Instant (II) may indicate a time in UTC format when the SAT is issued, and an IS may indicate an identifier of the SAT issuing authority or an issuing authority domain name. .
  • the signature may represent the signature of the issuing authority.
  • the issuing authority may hash the SAT and sign it with its public key, and the signature may prevent counterfeiting of the issued SAT.
  • IPK public key
  • the resource RES may represent a universal resource identifier used to uniquely find a service and a resource provided by the medical IoT device.
  • An access right may represent a series of actions (ACT) assigned to a user by the issuing authority.
  • OB Duty
  • NB Not Before
  • NA Not After
  • a field of the context CT may define a context information set used as an input for checking a context constraint during the SAT evaluation process.
  • condition script length CSL represents the length (byte) of the condition script
  • condition script CS may be composed of a condition script and a set of conditions and context constraints are defined.
  • Conditional scripts are lists of instructions included with each SAT, which can be written in a scripting language such as Forth.
  • Forth is an essential stack-based computer programming language, not Turing-complete, and condition scripts written in that language can flexibly change the parameters needed to accept or reject incoming requests.
  • Medical IoT devices use a lightweight operating system, which may not support dynamic software updates because there is no security module needed to accept and integrate new code or libraries. Unlike programs written in C, C ++, Python, or Java, scripts written in the Forth language can be easily updated.
  • the secure access token (SAT) can be verified by a verification process called an ACLogic engine that executes the condition script included in the SAT.
  • the ACLogic engine can make allow or deny decisions based on the outcome of the execution.
  • the ACLogic engine can determine whether a request meets the constraints defined for the requestor, and can use a data structure called a stack.
  • a secure access token (SAT) can be valid if nothing fails in the condition script and the top stack entry is true (nonzero).
  • the stack has a very simple data structure that can be visualized as a stack of cards and can allow two operations, push and pop. Push may add an item on the stack, and pop may indicate removing the top item from the stack. When the script finishes executing, the stack may need to maintain a TRUE value.
  • the ACLogic engine can return an authorization decision if it finds a TRUE value on the stack; otherwise it can return a reject decision.
  • the script execution may be expressed as shown in Table 4 below.
  • Execution of the condition script as shown in Table 3 may be divided into three parts as shown in FIGS. 8 to 10.
  • the signature verification script may be the same as SIG SPK DECRYPT HASH EQUALVERIFY.
  • the value of the SIG field may be decrypted with the public key (SPK) of the issuing authority, and the private key of the issuing authority may correspond to the SSK.
  • the HASH operation can be used to generate a hash of a JASON envelope (SAT packet).
  • the hash value can match the decrypted SIG value.
  • SIG Encrypt SSK (Hash (SAT)).
  • FIG. 9 illustrates verification of an obligation field, and a script for verifying (ie, verifying) an obligation may correspond to NB TIME GRATER_THAN NA TIMELESS_THAN.
  • the ACLogic engine can check whether the current time (TIME) is greater than the value of the NB field (GRATER_THAN), and can check whether the value of the NA field is less than the current time (LESS_THAN).
  • the verification script may correspond to OPERATION_MODE FORALL BATTERY_STATUS FORWALL LOCATION FORALL .
  • the request may have to be provided regardless of the user's location as well as the operating mode of the medical IoT device and the battery state (FORALL).
  • the FORALL operation removes the corresponding element from the top of the stack, allowing you to override the values of operating mode, battery status, and position.
  • a TRUE value at the top of the stack indicates that all conditions and constraints in the script have been met.
  • the condition script successfully executes.
  • a value other than TRUE at the top of the stack has not met one or more conditions or constraints. It can represent sound.
  • SAT security access token
  • Verification of the secure access token may be performed by an ACLogic engine.
  • Delegation Approach can be used as an approach to verifying the SAT based on the AC logic engine.
  • the smart gateway located together with the personal area network may perform the SAT verification process in consideration of the medical IoT device.
  • the smart gateway may correspond to a resource-rich entity as compared to the IoT device.
  • Smart gateways are built into the ACLogic engine and can authenticate incoming service access requests in two steps. In the first step, the smart gateway validates the SAT attached to the access request, and in the second step, the SAT validation result (eg, accept or reject the request) goes to the requested medical device (ie, medical IoT device). The request can be rejected without forwarding the request or sending it to the requested IoT device.
  • This Delegation Approach can enable medical IoT devices to provide real-time requests. Smart gateways can be located closer to medical IoT devices when compared to cloud-certified servers used in distributed, semi-distributed and centralized approaches. . Accordingly, by delegating the SAT check operation to the smart gateway without delegating a task to the cloud, the processing speed for the request of the user terminal can be increased.
  • the method according to the embodiment may be embodied in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium.
  • the computer readable medium may include program instructions, data files, data structures, etc. alone or in combination.
  • the program instructions recorded on the media may be those specially designed and constructed for the purposes of the embodiments, or they may be of the kind well-known and available to those having skill in the computer software arts.
  • Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks.
  • Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Chemical & Material Sciences (AREA)
  • Medicinal Chemistry (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Nutrition Science (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

IoT 기반 건강 처방 보조 및 보안 시스템 그리고 방법이 개시된다. 사물 인터넷(IoT) 기반의 건강 처방 보조 및 보안 시스템에 있어서, 상기 사물 인터넷 기반의 건강 처방 보조를 제공받고자 하는 사용자들을 구분하기 위한 식별자 정보를 제공하고, 사용자 단말로부터 입력된 사용자의 개인 정보를 상기 제공된 해당 사용자의 식별자 정보와 연관하여 등록하는 등록 제어부, 상기 사용자 단말의 식별자 정보에 기초하여 사용자를 인증하는 인증 제어부, 및 인증된 상기 사용자를 대상으로, 해당 사용자의 역할을 확인하고, 확인된 역할을 기반으로 해당 사용자에게 부여된 액세스 권한을 확인하는 권한 제어부를 포함하고, 로그인한 상기 사용자를 대상으로, 확인된 상기 액세스 권한에 기초하여 상기 사용자 단말로부터 수신된 요청에 해당하는 의료 서비스가 제공될 수 있다.

Description

IoT 기반 건강 처방 보조 및 보안 시스템 그리고 방법
본 발명의 실시예들은 사물 인터넷(Internet of Things, IoT) 기반의 건강 처방 보조(Health Prescription Assistant) 시스템에서 IoT 네트워크를 형성하고 있는 IoT 기기들과의 접속을 기반으로 환자의 현재 상태에 적절한 처방전(예컨대, 의약품, 식품 등)을 추천하고, IoT 기기들을 제어하고 보안을 제공하는 기술에 관한 것이다.
본 발명은 아래 연구과제들의 지원을 받아 완성되었다.
[연구사업명] 중견연구
[연구과제명] [Ezbaro] 나노 인체영역네트워크 핵심기술 연구: 분자-전자파 나노통신 하이브리드 메카니즘 규명
[연구사업명] 정보통신기술인력양성(R＆D,정보화)
[연구과제명] 스마트한 주파수 이용을 위한 스펙트럼 및 전파기술
사물 인터넷(Internet of Thing, IoT)은 인터넷 연결을 위한 IP 주소와 이러한 사물 쌍(pair of things), 다른 인터넷 가능 장치 및 프레임 워크간에 발생하는 통신을 특징으로 하는 물리적 개체 또는 엔티티(entitiy)를 포함하는 네트워크를 의미한다. 사물 인터넷(IoT)은 기계 사이의 시나리오를 뛰어 넘는 향상된 연결성을 포함한 여러 가지 이점이 있어 거의 모든 분야에서 자동화가 가능하다. IoT의 주요 기능 중 하나는 월드 와이드 웹(WWW)의 모든 네트워크가 의도한 최종 사용자 및/또는 사물에 제공하는 서비스를 가능하게 하는 것이다. 이러한 IoT의 기능은 원격 지원을 통해 환자에게 고품질의 원격 진료 및 의료 서비스를 시기 적절하게 제공할 수 있게 한다. 예를 들어, 원격 진료의 개념에서, 먼 곳(시골, 대양 위의 배 또는 항공기)에 있는 환자에게 의료 종사자는 먼 거리에서 의료 서비스를 환자에게 제공한다.
이처럼, 원격 진료에 의한 의료 서비스 배포의 기회와 가능성은 IoT의 잠재력을 동원하여 가속화시키고, 원격 건강 모니터링을 포함하여 수많은 의학적 응용을 불러 일으킬 수 있다. 예를 들어, 아래의 비특허 문헌 [1]M . Hassanalieragh , A. Page, T. Soyata , G. Sharma, M. Aktas , G. Mateos , B. Kantarci , S. Andreescu, Health monitoring and management using Internetof -Things ( IoT ) sensing with cloud-based processing: Opportunities and challenges,in : IEEE International Conference on Services Computing, SCC, IEEE, 2015,pp.285-292.에 제시된 IoT 기반의 건강 모니터링 및 관리를 통해 의료 서비스 제공자는 환자의 건강 데이터를 기반으로 환자 상태에 대해 훨씬 더 나은 진단을 내릴 수 있으며 최선의 치료와 조기 개입을 추천 가능하다.
IoT 기반의 의료 서비스는 비용 절감, 삶의 질 향상, 의료 서비스의 효율성 향상을 위해 많은 유리한 어플리케이션을 제공함으로써 적절한 시간에 쉽고 정확한 조치를 제공하는 유망 기술이다. 그러나, 의료 시스템에서 장치 및 응용 프로그램은 개인 의료 데이터를 비롯한 중요한 개인 정보를 처리해야 한다. 또한, 상기 응용 프로그램은 탑재된 스마트폰, 태블릿, PC 등의 사용자 단말은 언제 어디서나 액세스 할 수 있는 월드 와이드 정보 네트워크에 연결된다. 리소스(resource)가 제한된 웨어러블 센서로부터 수집된 개인 데이터는 프라이버시 문제에 취약하다.
또한, 의료 기기에 대한 무단 접속은 환자의 삶을 위험에 빠뜨릴 수 있다. 따라서 의료 센서 및 액츄에이터(actuator)의 오용 또는 환자의 의료 기록과 관련된 사생활 침해는 사람들이 IoT 기반 의료 어플리케이션을 활용하는 것을 제한할 수 있다. 예컨대, 환자의 의료 기록이 무단 접속한 사용자에게 그대로 노출되거나, 인슐린 공급, 심박수 제어 등의 IoT 장치가 무단 접속한 사용자에 의해 제어되어 환자의 생명을 위협하는 위험성이 존재한다.
한국공개특허 제10-2000-0066614호는 의료기기 사양관리 시스템 및 그 제어방법에 관한 것으로서, 사용자 인증을 통해 의료기 관련 정보를 제공하는 기술을 개시하고 있다.
[선행기술문헌]
[비특허문헌]
[1]M. Hassanalieragh, A. Page, T. Soyata, G. Sharma, M. Aktas, G. Mateos, B. Kantarci, S. Andreescu, Health monitoring and management using Internetof-Things (IoT) sensing with cloud-based processing: Opportunities and challenges,in: IEEE International Conference on Services Computing, SCC, IEEE, 2015,pp.285-292.
[2]D. Recordon, D. Reed, OpenID 2.0: A platform for user-centric identity management, in Proceedings of the second ACM workshop on Digital identity management, ACM, 2006, pp. 11-16.
[3]T. Bray, The javascript object notation (JSON) data interchange format, RFC 7159, http://tools.ietf.org/html/rfc7159.html, 2014.
본 발명은 IoT 기반 건강 처방 보조(health prescription assistant, HPA)를 제공함에 있어서, 환자의 의료 기록 및 의료관련 IoT 장치들로의 무단 접속(access)을 보호하기 위한 보안 기술에 관한 것이다. 즉, IoT 기반의 건강 처방 보조(HPA)를 위하여 사용자 인증을 제공하고, IoT 네트워크로 연결된 의료용 IoT 장치들, 생활용 IoT 장치와 관련된 자원(resource) 및 서비스에 대해 보호된 접속을 보장하는 보안 접속 제어 기술에 관한 것이다.
사물 인터넷(IoT) 기반의 건강 처방 보조 및 보안 시스템에 있어서, 상기 사물 인터넷 기반의 건강 처방 보조를 제공받고자 하는 사용자들을 구분하기 위한 식별자 정보를 제공하고, 사용자 단말로부터 입력된 사용자의 개인 정보를 상기 제공된 해당 사용자의 식별자 정보와 연관하여 등록하는 등록 제어부, 상기 사용자 단말의 식별자 정보에 기초하여 사용자를 인증하는 인증 제어부, 및 인증된 상기 사용자를 대상으로, 해당 사용자의 역할을 확인하고, 확인된 역할을 기반으로 해당 사용자에게 부여된 액세스 권한을 확인하는 권한 제어부를 포함하고, 로그인한 상기 사용자를 대상으로, 확인된 상기 액세스 권한에 기초하여 상기 사용자 단말로부터 수신된 요청에 해당하는 의료 서비스가 제공될 수 있다.
일측면에 따르면, 상기 권한 제어부는, 상기 사용자에 해당하는 역할이 환자, 간호사, 의사, 보안 관리자인지 여부를 확인하고, 확인된 역할과 관련하여 미리 정의된 정책에 따라 지정된 상기 액세스 권한을 확인할 수 있다.
다른 측면에 따르면, 상기 역할은, 사용자의 개인 정보, 및 직업 경험 정보에 기초하여 결정될 수 있다.
또 다른 측면에 따르면, 상기 권한 제어부는, 미리 지정된 컨텍스트(context) 제약 조건에 기초하여 사용자 단말로부터 수신된 요청을 허용하거나 거부할지 여부를 결정할 수 있다.
또 다른 측면에 따르면, 상기 권한 제어부는, 상기 사용자 단말로부터 요청과 함께 수신된 보안 접속 토큰(security access token, SAT)을 검증함으로써, 상기 요청에 해당하는 접근 권한을 확인할 수 있다.
또 다른 측면에 따르면, 상기 보안 접속 토큰(security access token, SAT)은, 상기 역할에 해당하는 정책, 권한 및 컨텍스트 제약 조건에 기초하여 검색된 정보를 이용하여 서명함으로써 생성되고, 상기 사용자 단말로 제공될 수 있다.
또 다른 측면에 따르면, 상기 권한 제어부는, 상기 보안 접속 토큰(security access token, SAT)에 대한 유효성이 검증됨에 따라, 상기 요청을 해당 IoT 장치로 전달할 수 있다.
사물 인터넷(IoT) 기반의 건강 처방 보조 및 보안 방법에 있어서, 상기 사물 인터넷 기반의 건강 처방 보조를 제공받고자 하는 사용자들을 구분하기 위한 식별자 정보를 제공하는 단계, 사용자 단말로부터 입력된 사용자의 개인 정보를 상기 제공된 해당 사용자의 식별자 정보와 연관하여 등록하는 단계, 상기 사용자 단말의 식별자 정보에 기초하여 사용자를 인증하는 단계, 및 인증된 상기 사용자의 역할을 확인하고, 확인된 상기 역할을 기반으로 해당 사용자에게 부여된 액세스 권한을 확인하는 단계를 포함하고, 로그인된 상기 사용자를 대상으로, 확인된 상기 액세스 권한에 기초하여 상기 사용자 단말로부터 수신된 요청에 해당하는 의료 서비스가 제공될 수 있다.
본 발명은 IoT 기반 건강 처방 보조(health prescription assistant, HPA)를 제공함에 있어서, 보안 접속 토큰(Secret Access Token, SAT)을 기반으로 사용자의 역할 및 부여된 액세스 권한을 확인한 후 환자의 의료 기록 및 의료용 IoT 장치들의 제어가 가능하도록 함으로써, 환자의 의료 기록이 유출에 따른 사생활 침해 및 의료용 IoT 장치들로의 무단 액세스로 인한 사용자의 생명이 위험해지는 상황을 방지할 수 있다. 즉, IoT 기반의 건강 처방 보조(HPA)를 위하여 승인된 사용자에게 보안 접속 토큰(SAT)을 발행하고, 발행된 보안 접속 토큰(SAT)을 확인하는 과정을 통해 IoT 네트워크로 연결된 의료용 IoT 장치들, IoT 장치들과 관련된 자원 및 서비스에 대해 보호된 접속을 보장할 수 있다.
또한, 오픈ID(openID)를 이용하여 사용자 인증을 수행함으로써, 사용자 인증을 위한 편리성을 제공할 수 있다.
도 1은 본 발명의 일실시예에 있어서, IoT 기반의 건강 처방 보조(HAP)를 위한 전체 네트워크를 도시한 도면이다.
도 2는 본 발명의 일실시예에 있어서, IoT 기반의 건강 처방 보조(HAP)를 위한 네트워크의 세부 구조를 도시한 도면이다.
도 3는 본 발명의 일실시예에 있어서, IoT 기반의 건강 처방 보조(HAP)를 위한 건강 처방 보조 및 보안 시스템의 세부 구성을 도시한 도면이다.
도 4는 본 발명의 일실시예에 있어서, 사용자의 등급 별로 서로 다르게 정의되는 정책(policy)을 설명하기 위해 제공되는 도면이다.
도 5는 본 발명의 일실시예에 있어서, IoT 기반의 건강 처방 보조(HAP)를 위한 접속 제어 방법을 도시한 흐름도이다.
도 6은 본 발명의 일실시예에 있어서, 건강 처방 보조 및 보안 시스템이 인증 서버 및 권한 서버로 구성된 경우의 접속 제어 방법을 도시한 흐름도이다.
도 7은 본 발명의 일실시예에 있어서, 보안 접속 토큰(SAT)을 생성하는 과정을 설명하기 위해 제공되는 도면이다.
도 8 내지 도 10은 본 발명의 일실시예에 있어서, SAT 인증관련 스크립트(script)를 도시한 도면이다.
도 11은 본 발명의 일실시예에 있어서, 보안 접속 토큰(SAT)을 확인하여 의료용 IoT 장치로의 접속을 허가하는 동작을 설명하기 위해 제공되는 도면이다.
이하, 본 발명의 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.
본 실시예들은 IoT 기반의 u-Health(즉, 환자/사용자의 건강 관리)를 지원함에 있어서, 사용자의 의료 기록 및 의료와 관련된 IoT 장치들의 제어 시 보안을 제공하는 기술에 관한 것으로서, 특히, IoT 기반으로 환자의 건강 관리를 위해 보안 계층(security layer)에서 IoT 기반의 건강 처방 보조(HPA)를 위하여 사용자 인증 및 자원과 서비스(예컨대, IoT 네트워크를 형성하고 있는 IoT 장치들)에 대해 보호된 접속을 보장하는 기술에 관한 것이다. 특히, 본 실시예들은, 보안 계층 (security)에서 승인되지 않은 사용자가 IoT 네트워크를 형성하고 있는 적어도 하나의 의료용 IoT 장치로의 접속을 막고, 승인된 사용자만이 등급에 따라 허가된 의료용 IoT 장치로 접속하도록 접속을 제어하는 기술에 관한 것이다. 이때, 접속 제어는 하나의 IoT 장치 별로 수행될 수도 있고, 서비스 별로 수행될 수도 있다. 예컨대, 사용자로부터 특정한 하나의 IoT 장치로의 접속이 요청된 경우, 요청된 하나의 IoT 장치로의 접속 제어가 수행될 수 있으며, 특정 의료 서비스로의 접속이 요청된 경우, 특정 의료 서비스를 위해 요구되는 복수의 IoT 장치들로의 접속 제어가 수행될 수 있다. 예컨대, 위암 검사 서비스의 경우, 위암 검사를 위해 기지정된 복수의 IoT 장치들로의 접속 제어가 수행될 수 있다.
또한, 본 실시예들에서, 사용자 인증을 위해 위의 비특허 문헌 [2]D . Recordon, D. Reed, OpenID 2.0: A platform for user-centric identity management, in Proceedings of the second ACM workshop on Digital identity management, ACM, 2006, pp. 11-16.에 제시된 OpenID 표준이 이용될 수 있다. 그리고, 무단 액세스 관련 위험을 감소시키기 위해, 클라우드에 저장된 전자 의료 기록으로 액세스하는 것을 보호하기 위하여 속성 기반 액세스 제어(Attributedbased Access Control, ABAC) 모델이 이용되고, 네트워크의 말단에서 작동하는 의료 센서와 엑추에이터로의 액세스(access)를 보호하기 위하여 상황 인식 기능 기반 액세스(Delegated Context-ware Capability-based Access Control, DCCapBAC) 제어가 이용될 수 있다. DCCapBAC는 의료 기기와 함께 배치된 스마트 게이트웨이(예컨대, 경계 라우터)에 위임하여 계산 집약적인 암호화 작업에서 리소스 제한 의료 센서 및 액추에이터 부담을 덜어줄 수 있다. 또한, DCCapBAC는 요청에 대한 권한 결정을 내리는데 관련된 통신 및 메모리 오버 헤드를 감소시킴으로써, 환자의 신체 상태에 대한 실시간 업데이트가 간병인에게 공개되도록 할 수 있다. 그리고, 의료 센서가 간병인의 지시를 받을 수 있게 할 수 있다. 이처럼, DCCapBAC는 유효성 검사 작업을 게이트웨이(gateway)에 위임하고, 게이트웨이는 들어오는 요청을 가로채어 중간 당사자와 통신하지 않고 의료 기기에 대한 권한을 확인하여, 접속 허가 또는 거부를 수행할 수 있다.
본 명세서에서, ID 제공자는 ID 제공자의 서버를 나타내고, IoT 서비스 제공자는 IoT 서비스 공급자의 서버를 나타낼 수 있다.
본 실시예들에서, '건강 처방 보조 및 보안 시스템'은 'u-Health 지원 시스템'으로 표현될 수 있다.
도 1은 본 발명의 일실시예에 있어서, IoT 기반의 건강 처방 보조(HAP)를 위한 전체 네트워크를 도시한 도면이다.
전체 네트워크는 복수의 사용자 단말들(110), 건강 처방 보조 및 보안 시스템(120), 및 복수의 ID 제공자의 서버들(130)을 포함할 수 있다.
사용자 단말들(110) 각각은 사용자의 인증을 건강 처방 보조 및 보안 시스템(120)에 요청하고, IoT 네트워크를 형성하고 있는 IoT 장치들, IoT 장치 관련 자원 및 서비스로의 접속을 건강 처방 보조 및 보안 시스템(120)에 요청할 수 있다. 그리고, 건강 처방 보조 및 보안 시스템(120)의 접속 허가 여부에 따라 원하는 IoT 장치에 접속할 수 있다. 사용자 단말은, 환자, 의사, 수석 의사, 약사, 간호사 등의 사용자가 소지한 전자 기기로서, 태블릿(tablet), PC, 스마트폰(smartphone) 등을 포함할 수 있다.
복수의 ID 제공자의 서버들(130)은 오픈ID(openID) 표준을 기반으로 사용자를 인증하기 위해 건강 처방 보조 및 보안 시스템(120)과 네트워크 연결된 서버 장치로서, 사용자 단말의 로그인(login) 정보에 기초하여 사용자 단말을 인증할 수 있다. 예컨대, ID 제공자의 서버는 페이스북, 인스타그램 등과 같이 소셜 네트워크 서비스를 제공하는 서버, 구글, 야후 등의 포털 사이트의 서버와 같이 많은 사용자들이 이용하고(가입자 수가 많고), 신뢰할 수 있는 서버 장치를 의미할 수 있다.
건강 처방 보조 및 보안 시스템(120)은 사용자 단말에서 요청한 자원 및 서비스, 즉, IoT 장치로의 접속 권한을 확인하여 사용자 단말에 접속을 허가할 수 있다. 접속 허가된 적어도 하나의 의료용 IoT 장치로 사용자 단말이 접속할 수 있도록, 건강 처방 보조 및 보안 시스템(120)은 적어도 하나의 의료용 IoT 장치와 IoT 네트워크로 연결될 수 있다.
도 2는 본 발명의 일실시예에 있어서, IoT 기반의 건강 처방 보조(HAP)를 위한 네트워크의 세부 구조를 도시한 도면이다.
도 2를 참고하면, HPA 게이트웨이(210)는 건강 처방 보조(Health Prescription Assistant, HPA)를 위해 외부 접속을 통하여 서비스를 제공하는데 중요한 역할을 수행할 수 있다. 예컨대, HPA 게이트웨이(210)는 인증된 건강 관리 인력을 모니터링하고 제어할 수 있으며, 인증된 의료 전문가 및 환자를 식별할 수 있다. 그리고, HPA 게이트웨이(210)는 환자의 의료 기록에 대한 보호된 접속을 보장하기 위해 보안 서버(security server, 211)와 통신할 수 있다. HPA 게이트웨이(210)는 의사의 권장 사항, 의심되는 질병 등의 정보를 병원 접근성을 기반으로 컴퓨팅 서버(212)에 전달할 수 있다.
또한, HPA 게이트웨이(210)는 각각의 활동을 기록할 수 있다. 예를 들어 새로운 세션(session)을 열고, 약을 처방하며, 식이 요법에 대한 요구 사항을 제안하거나, 특정 서비스가 관련 타임 스탬프가 있는 관련 의료 인력에게 요청 된 후 대기 시간을 기록하는 등의 작업 등을 기록할 수 있다. HPA 게이트웨이(210)는 주문형 작업 배열(예컨대, 비상시 특정 연결 종료 또는 적절한 명령 수신 등)을 수행할 수 있다. HPA 게이트웨이(210)는 기존의 네트워크 게이트웨이 장치에 해당하지 않으며, 가상(예컨대, Amazon Elastic Compute Cloud) 또는 실제 시스템에서 실행되는 서비스 앱(application)에 해당할 수 있다. CPU 수, 저장소, 메모리 등과 같은 시스템 사양은 HPA 시스템과 관련된 클라이언트 및 의료 장비의 총 수에 따라 달라질 수 있다. 또한, HPA 게이트웨이(210)는 부하 분산을 위해 주문형 리소스 확장 기술을 사용하여 사양을 업그레이드 할 수 있다.
보안 서버(security server, 211)는 의료 기록, 센서 및 액추에이터에 대한 보호된 액세스를 보장하는 역할을 수행할 수 있다. 보안 서버(security server, 211)는 인증, 권한 부여 및 감사(auditing)라는 세 가지 유형의 기능을 제공하기 위한 형태로 구현될 수 있다. 이때, 인증은 신원 확인을 담당하는 것이고, 권한 부여는 권한이 없는 액세스로부터 의료 기록 및 장치를 보호하기 위한 기능에 해당할 수 있다. 감사(auditing)는 건강 처방 보조(HPA)를 위한 구성 요소간에 다양한 상호 작용(권한 부여 및 비인증)을 기록할 수 있다. 이후, 이러한 로그(기록)를 분석하여 악의적인 활동을 탐지할 수 있다. 또한, 무단 액세스 또는 침입 탐지에 대한 실시간 알림을 위해 Elastalert, 2 X-Pack3과 같은 보고 및 경고 서비스를 감사 서비스에 통합할 수 있다.
환자 및 스마트 약품 상자는 스마트 홈(220)에 포함되는 것으로서, 환자는 적절한 전극이 내재된 서로 다른 바이오 센서를 포함하는 신체 패치를 지니고 있으며, 상기 바이오 센서는 신체 부위 네트워크를 형성할 수 있다. 신체 패치 센서와 이식된 바이오칩은 IPv6 기반 저전력 무선 BAN(6LoWBAN), ZigBee 또는 Bluetooth low energy(BLE)와 같은 단거리 통신 기술을 사용하여 센서 부착 약품 팩과 통신할 수 있다. 그러면, 약품 팩은 약품 팩에 포함된 센서로 코팅되어 있는 스마트 알약과 일체로 작동하지만, 약품 팩 센서는 RFID 칩에 불과하며 알약 센서는 감지 능력이 있는 재료로 코팅된 특별한 종류에 해당할 수 있다. 약품 팩은 특별히 고안된 스마트 약품 상자에 들어 있을 수 있다. 스마트 약품 상자 안에 있는 중앙 센서는 각 약품 팩과 알약의 상태를 기록할 수 있다. 예를 들어, 환자가 특정 알약을 복용하기 위해 약품 팩의 일부를 오픈하면, 약품 팩이 오픈(open)되었다는 동작 상태가 약품 팩에 부착된 센서에 의해 감지되고, 후속 프로세싱 및 참고를 위해 약품 상자에 보고될 수 있다. 그러면, 환자 BAN에서 집계된 데이터는 저장되고 추후 필요에 따라 건강 클라우드 컴퓨팅 서버에서 처리될 수 있다.
건강 데이터베이스(213)는 식품 및 영양 DB, 측정된 생체 바이오마커 DB 및 질병 관련 팁 DB 등을 포함하여 일부 대표적인 DB의 스택을 포함할 수 있다. 예컨대, 식품 및 영양 DB는 영양 성분이 구조화된 형태로 표현된 광범위한 식품 목록을 제공할 수 있다. 그리고, 식품 및 영양 DB는 특정 음식이 환자의 건강에 어떤 영향을 미치는지에 대한 정보를 시스템에 제공할 수 있다. 이와 같이 식품 및 영양 DB는 건강한 식단 선택을 용이하게 할 수 있다. 그리고, 질병 관련 팁 DB는 다른 환자의 조언, 달성된 경험 및 약품에 대한 정보를 저장하고 있을 수 있다. 예컨대, 질병 관련 팁 DB는 B2B (business-to-business) 서비스를 제공하는 제3자로부터 제공될 수 있다. 이 경우, DB 서비스 제공자와 건강 처방 보정 및 보안 시스템 간의 호환성을 확립하기 위해 서로 통신해야 하는데, 이러한 통신을 위하여 표준 프로토콜에 동의하는 작업이 미리 수행될 수 있다.
컴퓨팅 및 제어 서버(212)는 수시로 요청되는 핵심 컴퓨팅 및 의사 결정을 담당할 수 있다. 예컨대, 집계된 데이터는 저장, 처리, 분석 및 시각화를 위해 건강 클라우드 컴퓨팅 및 제어 서버로 전달될 수 있으며, 컴퓨팅 및 제어 서버(212)는 건강 처방 보조 및 보안 시스템의 중앙 허브에 해당할 수 있다. 컴퓨팅 및 제어 서버(212)는 의사 및 환자가 소지한 모든 사용자 단말(즉, 클라이언트)를 포함하여 다양한 지점에 설치된 사용자 단말을 모니터링하고 제어할 수 있다. 그리고, 건강 처방 보조 및 보안 시스템의 말단에 해당하는 다양한 단말들(예컨대, 센서, 환자, 건강 전문가 및 DB)에 의해 보고된 이벤트를 집계하고 구조화된 명령을 컴퓨팅 및 제어 서버(212)로 전달할 수 있다. 컴퓨팅 및 제어 서버(212)는 수신된 명령을 분석하고 각 말단에 결과를 전송할 수 있다.
스마트 홈(220)은 환자에게 실내 온도, 적절한 조명 및 적절한 습도를 포함하여 보다 적합하고 편안한 생활 조건을 제공하기 위해 이용될 수 있다. 경우에 따라, 건강 처방 보조 및 보안 시스템은 스마트 홈 요소의 특수 설계를 필요로 할 수 있다. 예컨대, 보존 식품 품목을 추적하기 위해 특별히 고안된 냉장고가 필요할 수 있다. 그러면, 상기 냉장고는 여러 개의 챔버로 구성되며, 각 챔버에는 여러 개의 셀이 존재할 수 있다. 그리고, 챔버와 셀에는 센서가 장착될 수 있으며, 상기 센서는 냉장고의 메인 RFID와 통신할 수 있다. 이때, 메인 RFID는 스마트 홈(220)의 서버와 통신하고 인터넷에 연결될 수 있다.
스마트 게이트웨이(230)는 네트워크의 말단에 배치되는 리소스(resource)가 풍부한 장치를 나타낼 수 있다. 스마트 게이트웨이(230)는 통신 평면(plane), 집계 평면, 결정 평면 및 보안 적용 평면의 네 가지 평면을 포함할 수 있다. 통신 평면은 다중 프로토콜 장치와 네트워크 간의 상호 작용을 가능하게 하며, 스마트 홈에 위치하는 스마트 물체 또는 환자에게 부착된 의료 센서 사이의 통신을 가능하게 할 수 있다. 스마트 물체와 웨어러블 센서는 스마트 게이트웨이(230)를 통해 서로 통신할 수도 있다. 집계 평면은 의료 센서의 데이터를 준수하고 이를 클라우드 HPA 서비스에 게시할 수 있다. 결정 평면은 센서 데이터를 처리하고 건강 상태를 파악하며 로컬에서 의사 결정을 내릴 수 있다. 보안 적용 평면은 의료용 IoT 장치들을 무단 액세스로부터 보호하기 위해 이용될 수 있다. 스마트 게이트웨이의 평면은 6LoWPAN 경계 라우터를 사용하여 구현될 수 있다.
도 3는 본 발명의 일실시예에 있어서, IoT 기반의 건강 처방 보조(HAP)를 위한 건강 처방 보조 및 보안 시스템의 세부 구성을 도시한 도면이다.
도 3은 ID 제공자(310), IoT 서비스 제공자(320), 사용자 단말(330) 및 건강 처방 보조 및 보안 시스템(340)을 포함할 수 있다.
ID 제공자(310)는 도 1의 복수의 ID 제공자들의 서버(130) 중 어느 하나를 나타내며, IoT 기반의 HPA(IoT-based HPA, IHA)와 상호작용하는 사용자들(예컨대, 환자, 의사, 간호사, 약사 등)을 위한 식별자(Identifier) 정보를 사용자 단말(330)에 제공할 수 있다. 예컨대, 페이스북, 트위터 등을 통해 로그인 시 이용되는 사용자의 ID를 식별하기 위한 정보를 사용자 단말(330)로 제공할 수 있다.
IoT 서비스 공급자(320)는 두 가지 유형의 의료 서비스를 제공할 수 있다. 예컨대, 장치 내 의료 서비스와 클라우드(Cloud) 의료 서비스를 제공할 수 있다. 장치 내 의료 서비스는 의료용 IoT 장치에 의해 제공될 수 있으며, 로컬 IoT 서비스에 해당할 수 있다. 예를 들어, 환자의 신체에 부착된 스마트 펄스 옥시미터(oximeter)는 환자의 혈액내 산소 포화도(O2) 수준이 직접 검색(예컨대, 의사가 장치를 검색하여 연결)되거나 원격으로 검색(예컨대, 클라우드 의료 서비스)될 수 있다. 사용자(예컨대, 환자, 간병인, 환자 가족 등)는 알림 및/또는 이벤트 수신을 위해 서비스에 가입할 수 있다. 예를 들어, 스마트 펄스 옥시미터는 O2 수준을 주기적으로 화면에 표시할 수 있다.
클라우드 의료 서비스(CMS)는 클라우드에 호스팅되며 로컬 장치 내 의료 서비스에 의한 원격 액세스를 허용할 수 있다. 클라우드 의료 서비스(CMS)는 장치 프로파일 저장소를 유지 관리할 수 있으며, 장치 내 의료 서비스에 관한 가입 정보를 포함하는 저장소 즉, 어떤 사용자가 어떤 서비스에 가입하고 어떤 구성 및 설정으로 등록되어 있는지를 포함하는 저장소를 포함할 수 있다. 클라우드 의료 서비스(CMS)는 장치 내 의료 서비스에 대한 구독 및/또는 액세스 규칙을 만들고 관리할 수 있는 인터페이스를 제공할 수 있다. 예를 들어, 사용자는 O2 수준(level)이 미리 지정된 특정 임계 값 이하가 되면 알림을 수신하는 규칙을 설정할 수 있다.
ID 제공자(310), 사용자 단말(330), IoT 서비스 공급자(320) 및 건강 처방 보조 및 보안 시스템(340)은 유선 또는 무선 네트워크로 연결되어 상호 간에 정보를 주고받을 수 있다.
건강 처방 보조 및 보안 시스템(340)은 사용자 단말(330)과의 상호 작용을 위해 사용자 단말과 관련된 정보를 등록하는 등록 제어부(Registration Authority, 341), 사용자 단말을 인증하는 인증 제어부(Authentication Authority, 342), 및 IoT 의료 서비스에 대해 보호된 접속을 보장하는 권한 제어부(Authorization Authority, 343)를 포함할 수 있다.
등록 제어부(341)는 사용자 단말(330)과 건강 처방 보조 및 보안 시스템(340) 간의 상호 작용을 위해 사용자 단말(330)과 관련된 정보를 등록하여 사용자 별로 사용자 프로파일(user profile)에 저장 및 관리할 수 있다. 예를 들어, 병원 진료 카드에 수록되는 사용자의 개인 정보들(사용자 이름, 성별, 생년월일, 사용자의 전화번호, 휴대용 전화번호, 주소 정보 등)이 사용자의 식별정보(예컨대, 사용자에게 할당된 진료카드번호, 직원번호 등의 ID)와 매칭하여 사용자 프로파일에 저장 및 관리될 수 있다.
등록 제어부(341)는 직접 모드와 중계 모드의 두 가지 모드로 동작할 수 있다. 직접 모드로 동작하는 경우, 등록 제어부(341)는 이름, 생년월일, 사회 보장 번호, 신용카드 정보, 주소 정보 등의 개인 정보를 사용자 단말(330)로부터 수신할 수 있다. 중계 모드로 동작하는 경우, 등록 제어부(341)는 구글, 트위터 등의 제3자의 웹/모바일 웹을 통해 사용자 단말(330)로부터 입력된 상기 사용자의 개인 정보를 수신할 수 있다. 그러면, 수신된 개인 정보를 사용자의 식별자 정보(예컨대, 사용자에게 할당된 진료카드번호, 직원번호 등의 ID)와 함께 연관시켜 등록할 수 있다. 등록이 성공적으로 완료되면 사용자 프로파일이 생성되어, 사용자의 프로파일이 사용자 프로파일 데이터베이스에 저장 및 유지될 수 있으며, 각 사용자 별로 고유한 사용자 ID(User ID, UID)가 할당될 수 있다.
인증 제어부(342)는 사용자 단말의 인증을 위한 로그인 서비스를 사용자 단말(230)에 제공할 수 있다. 예컨대, 인증 제어부(342)는 사용자 단말(330)로 로그인 정보의 입력을 요청할 수 있다.
그러면, 사용자 단말(330)의 화면에 로그인 정보의 입력을 요청하는 웹페이지가 디스플레이될 수 있다. 인증 제어부(342)는 사용자 단말(330)로부터 수신된 로그인 정보를 사용자 단말(330)이 지정한 ID 제공자(310)에게 전달할 수 있다. 여기서, 로그인 정보는, 사용자 단말에서 지정한 ID 제공자(310)의 웹사이트에 가입된 해당 사용자의 로그인 ID(예컨대, 이메일(email address)) 및 패스워드를 포함할 수 있다. 예컨대, 사용자 단말(330)에서 지정한 ID 제공자(310)에게 로그인 정보를 전달하기 위해, ID 제공자의 저장소(Identity Provider Repository)에는 건강 처방 보조 및 보안 시스템(340)에 등록된 복수의 ID 제공자들 각각의 식별 정보 및 해당 ID 제공자의 웹사이트로의 연결을 위한 링크 정보가 매칭되어 저장될 수 있다.
권한 제어부(343)는 인증 제어부(342)를 통해 ID 제공자(310)에서 로그인 정보에 기초하여 사용자 단말(330)의 인증에 성공함에 따라, 인증된 사용자 단말(330)에게 보안 접속 토큰(Security Access Token, SAT)을 발행할 수 있다. 여기서, 보안 접속 토큰은 IoT 네트워크를 형성하고 있는 적어도 하나의 의료용(medical) IoT 장치들 중 상기 인증된 사용자에게 허가된 IoT 장치들, 허가된 IoT 장치들과 관련된 서비스 및 자원에 해당하는 권한들(privileges)을 포함할 수 있다. 보안 접속 토큰(SAT)은 위조 감지를 위해 암호화되어 보호될 수 있으며, 권한 제어부(343)는 사용자 단말(330)을 의료용 IoT 장치로 접속하기 이전에 SAT를 먼저 확인함으로써, 의료용 IoT로의 보호된 접속을 보장할 수 있다.
의료용 IoT 장치(자원 및 서비스 포함)로의 보호된 접속을 위해 상황인지 능력 기반의 접속 제어(Context aware Capability Based Access Control, CCapBAC) 모델이 이용될 수 있다. 즉, 사용자가 자원 또는 서비스와 관련된 IoT 장치에 접속하기 위한 권한은, 도 4와 같이 사용자의 역할(Role)에 따라 구분되는 사용자 등급 별로 정의된 정책(Policy)에 기초하여 할당될 수 있다.
예를 들어 Alice, Bob, Charlie가 각각 간호사, 의사, 선임 의사(senior physician)의 역할(Role)로 건강 처방 보조 및 보안 시스템(340)에 등록된 경우를 가정하여 설명하기로 한다. 여기서, 역할에 따라 사용자 등급이 나누어질 수 있다. 이에 따라, 간호사, 의사, 선임 의사 각각에 등급 1, 등급 2, 등급 3으로 분류될 수 있으며, 등급 1에 대한 접속 권한, 등급 2에 대한 접속 권한 및 등급 3에 대한 접속 권한을 나타내는 정책(policy)이 서로 다르게 설정될 수 있다. 규칙(Rule), 즉, 등급 별 권한 다음과 같이 정의될 수 있다. 예컨대, 간호사(등급 1)는 온도센서(체온계), 혈압 센서, 포도당(glucose) 센서, 인슐린(insulin) 펌프 등의 특정한 의료용IoT 장비들에 대한 명령들(GET, POST 등)만 발행하여 상기 명령이 발행된 장치들로만 접속할 수 있는 권한을 가질 수 있다. 그리고, 의사(등급 2)는 간호사보다 더 많은 접속 권한들을 가지고 있을 수 있다. 예컨대, Bob(등급 2)은 Alice(등급 1)가 가진 모든 권한을 가지고 있을 수 있고, 추가로 EEG, ECG, vision 센서, hearing 센서 등과 같은 민감한 의료용 IoT 장치들에게 명령을 발행하여 접속할 수 있는 권한을 가지고 있을 수 있다. Charlie(등급 3)는 Bob(등급 2)이 가진 모든 권한을 가지면서, 몸에 이식되는 IoT 가능한 패이스메이커(Pacemaker)와 같이 이식된 IoT 장치들에 대한 접속 권한을 가질 수 있다. 그리고, Charlie(등급 3)는 Pill Bottle과 같은 스마트 의약 상자 (smart Medicine Box)에 명령을 발행함으로써 응급 또는 치명적 상황에 의약품을 처방할 수 있는 권한을 가질 수 있다.
이처럼, 사용자의 역할에 따른 등급을 확인하고, 사용자 등급 별로 설정된 정책(policy)에 기초하여 사용자 단말에서 요청된 IoT 장치가 해당 사용자에게 권한이 부여된 IoT 장치가 맞는지 확인하는 과정을 통해 사용자 단말의 해당 IoT 장치로의 접속 허가 여부가 결정될 수 있다. 이러한 접속 제어를 통해 IoT 기반의 HPA에서 각 의료용 IoT 장치로의 보호된 접속이 보장될 수 있다.
다시 도 4를 참고하면, 사용자(410)는 로컬 및 클라우드 IoT 서비스의 소비자가 소지한 사용자 단말, 단말에 탑재된 어플리케이션 등을 나타낼 수 있다. 도 4는 상황 인식 기능 기반 액세스 제어(CCapBAC) 모델을 따르며, 각 사용자 별로 고유한 ID가 할당될 수 있다. 사용자 집합(SubS)은 아래의 수학식 1과 같이 표현될 수 있다.
[수학식 1]
Figure PCTKR2018007896-appb-I000001
도 4에서 역할(Role, R)은 사용자들의 기능(즉, 역할)을 정의한 것으로서, 사용자가 환자, 의사, 간호사, 시스템 관리자, 또는 보안 관리자 등의 역할에 해당하는지 여부가 사용자 별로 할당될 수 있다. 역할 별로 서로 다른 액세스 권한이 미리 지정될 수 있다. 역할 세트(Rset)는 아래의 수학식 2와 같이 표현될 수 있다.
[수학식 2]
Figure PCTKR2018007896-appb-I000002
연산작업(Operation)은 GET, POST, DLETE, PUT 등을 포함할 수 있다. 예컨대, 사용자 단말에서 GET 요청이 발생한 경우, 해당 의료 서비스에 대한 읽기 작업이 수행될 수 있다. 이러한 연산작업 세트는 아래의 수학식 3과 같이 표현될 수 있다.
[수학식 3]
Figure PCTKR2018007896-appb-I000003
서비스(service)는 의료용 IoT 장치에 의해 제공되는 서비스를 나타낼 수 있다. 예컨대, 각 서비스는 데이터베이스 또는 장치 메모리에서 정렬된 구성 파일, 센서 데이터 등의 리소스 세트(res)로 표현될 수 있다. 사용자 요청에 따른 서비스가 제공될 수 있으며, 사익 요청은 액세스 제어 로직(ACLogic) 엔진에 의해 확인될 수 있다. 서비스 세트(Service Set, SS)와 리소스 세트(Resource Set, RS)는 아래의 수학식 4와 같이 표현될 수 있다.
[수학식 4]
Figure PCTKR2018007896-appb-I000004
허가(Permission)는 하나 이상의 의료 서비스와 관련하여 특정 작업 모드에 대한 허가를 나타낼 수 있다. 액세스 권한을 기반으로 권한 보유자가 시스템에서 일부 작업을 수행할 수 있다. 예컨대, 간호사는 온도계(즉, 의료용 IoT 장치) 수치를 검색할 수 있는 권한이 있지만, 약병(즉, 의료용 IoT 장치) 에 처방 명령을 내릴수 있는 권한이 없다. 허가 세트(PS)는 작업 할당에 기초하여 아래의 수학식 5와 같이 정의될 수 있다.
[수학식 5]
Figure PCTKR2018007896-appb-I000005
속성 제약 조건(attribute constraint)은 정책 할당 중에 사용할 수 있는 사용자 속성, 역할 속성 및 의료 기기 속성과 같은 다양한 유형의 속성을 포함할 수 있다. 상기 속성들은 사용자 할당, 허가 할당 및 작업 할당 등의 정책 할당에 이용될 수 있다. 예컨대, 사용자 할당 과정에서 사용자의 나이/직업 경험이 고려될 수 있다. 사용자(예컨대, 의사)에게 역할(예컨대, 수석 의사)을 할당/배정되기 위하여 15년의 경험을 가져야 한다는 조건이 미리 지정될 수 있으며, 이러한 속성 제약 조건을 기반으로 사용자의 나이, 직업 경험 등에 기초하여 사용자 별로 역할이 할당될 수 있다.
마찬가지로, 그룹의 크기나 그룹의 기능과 같은 역할의 속성은 권한 할당 중에 고려될 수 있다. 예를 들어, 적어도 한 사람은 수석 의사 역할에 배정되어야 하며, 두 명의 간호사가 환자의 동일한 의료 기기에 접근할 수 없어야 한다 등의 제약 조건이 미리 지정될 수 있다. 이때, 메모리, 통신 인터페이스 또는 에너지 소스(예를 들어, 배터리 구동형)와 같은 장치 특성은 작업 할당을 결정하기 위해 이용될 수 있다. 예를 들어, 읽기 전용 메모리(ROM)가 있는 의료용 IoT 장치는 POST 액션을 위해 액세스되어서는 안되며, 속성 집합은 아래의 수학식 6과 같이 표현될 수 있다.
[수학식 6]
Figure PCTKR2018007896-appb-I000006
속성 세트의 각 요소는 속성 유형(Attribute Type, AT)를 나타낼 수 있다. 속성 요소(Attribute Element, AE)는 3차원
Figure PCTKR2018007896-appb-I000007
로 표현될 수 있다. 예를 들어, (장치, 메모리, 16MB)는 메모리의 용량을 나타내며, (환자, 나이, 45)는 환자의 나이를 나타낼 수 있으며, 그룹의 크기는 (역할, 크기, 15)로 표현될 수 있다. 속성 제약(Attribute Constraint, AC)는 속성 요소(AE)의 조합으로 표현될 수 있다. 상기 조합은 속성 요소(AE)의 결합, 분리 및 부정(negation) 작업으로 수행될 수 있다. 예컨대, "심장 내과의 모든 의사가 심장 박동기의 상태를 확인할 수 있습니다"와 같은 보안 규칙이 있다고 가정하면, 상기 규칙은 아래의 수학식 7과 같이 표현될 수 있다.
[수학식 7]
Figure PCTKR2018007896-appb-I000008
컨텍스트(context) 제약 조건은 엔티티(entity)의 상황을 특성화하는 데 사용하기 위해 미리 지정될 수 있다. 여기서, 엔티티(entity)는 사용자와 의료용 IoT 서비스 간의 상호 작용과 관련이 있다고 생각되는 사람, 장소, 객체를 포함할 수 있다. 정책 평가 단계에서 요청을 허용/거부할지 결정하기 위해 시간, 공간, 객체 상태 등과 같은 다양한 유형의 컨텍스트가 사용될 수 있다. 예를 들어, 사용자 단말로부터 의료용 IoT 서비스 요청이 특정 위치에서 발생한 경우, 상기 요청이 거부될 수 있다. 이외에, 요청이 이전에 수행되었거나 특정 시간 후에 발행된 경우 요청이 거부될 수도 있다. 또한, 의료용 IoT 장치의 현재 상태(예컨대 동작 모드(예를 들어, 에너지 절약 모드))에 기초하여 요청이 거부될 수 있다. 컨텍스트 세트는 아래의 수학식 8과 같이 표현될 수 있다.
[수학식 8]
Figure PCTKR2018007896-appb-I000009
컨텍스트 세트의 각 요소(element)는 컨텍스트 유형(context type, CT)을 나타낼 수 있다. 각 컨텍스트 요소(CE)는 3차원
Figure PCTKR2018007896-appb-I000010
로 표현될 수 있다. 예컨대, (장치, 모드, 에너지 절약)은 장치의 작동 모드를 나타내고, (의사, 위치, 좌표 (33.5°, 86.8°))는 위치 컨텍스트를 나타낼 수 있다. "하루 중 시간과 장치의 작동 모드에 관계없이 병원에서 발생하는 모든 요청을 제공해야 한다"와 같은 보안 규칙을 고려하는 경우, 컨텍스트 제약 조건은 아래의 수학식 9와 같이 표현될 수 있다.
[수학식 9]
Figure PCTKR2018007896-appb-I000011
사용자 할당(UA), 권한 할당(PA) 및 작업 할당(OA)에서,
Figure PCTKR2018007896-appb-I000012
로 표현되는 사용자 할당은 사용자와 역할 간의 다 대 다 매핑(mapping)을 나타내고, 각 사용자에게는 역할이 할당될 수 있다. 이때, 한 명의 사용자에게 여러 역할(예컨대, 환자이면서 의사, 간호사이면서 환자 등)이 할당될 수 있으므로, 한 명의 사용자는 여러 그룹에 속할 수 있다.
Figure PCTKR2018007896-appb-I000013
로 표현되는 권한 할당은 권한과 역할 간의 다(多) 대 다(多) 매핑(mapping)을 나타내는 것으로서, 리소스(resource)에 액세스하기 위하여 각 역할에 특정 권한이 할당될 수 있다.
Figure PCTKR2018007896-appb-I000014
로 표현되는 작업 할당은 작업과 서비스 간의 다 대 다 매핑을 나타내는 것으로서, 각 서비스에는 일정 수의 작업이 할당될 수 있다.
Figure PCTKR2018007896-appb-I000015
로 표현되는 역할 속성 할당은 역할과 속성 유형 간의 다 대 다 매핑을 나타내는 것으로서, 각 역할은 시스템 관리자 또는 보안 관리자에 의해 속성이 지정될 수 있다.
Figure PCTKR2018007896-appb-I000016
로 표현되는 권한 속성 할당은 권한과 속성 유형 사이의 다 대 다 관계를 나타내는 것으로서, 속성 집합이 먼저 정의된 이후, 보안 관리자에 의해 속성이 권한에 할당될 수 있다.
Figure PCTKR2018007896-appb-I000017
로 표현되는 작업 속성 할당은 작업과 속성 유형 사이의 다 대 다 관계를 나타내는 것으로서, 보안 관리자(즉, 보안 관리자가 소지한 사용자 단말)에 의해 작업에 속성 세트가 지정/할당될 수 있다.
정책(Policy)은 사용자의 능력을 결정하는 것으로서, 각 정책에는 권한 할당 및 작업 할당의 서브 세트가 포함되고, 사용자 할당은 포함되지 않을 수 있다. 사용자 정보는 정책에 포함되지 않을 수 있다. 정책은 역할(role)에 대해 정의되고, 역할은 사용자에 매핑될 수 있다. 이에 따라, 사용자의 능력은 역할을 정의하는 정책에 해당할 수 있으며, 정책은 권한 서비스의 정책 데이터베이스에 정의되어 저장될 수 있다. XACML(Extensible Access Control Markup Language)에 기초하여 인코딩된 액세스 제어 정책은 아래의 표 1과 같을 수 있다.
[규칙 제91조에 의한 정정 15.10.2018]　
[표1]
도면 12 참조
의료용 IoT 장치로의 접속 시 이용되는 보안 접속 토큰(SAT)은 표 1과 같이 표현되는 정책에 기초하여 생성되어 사용자에게 발급될 수 있다. 정책 인코딩과 달리, 보안 접속 토큰은 위의 비특허 문헌 [3]T . Bray, The javascript object notation ( JSON ) data interchange format, RFC 7159, http://tools.ietf.org/html/rfc7159.html, 2014.에 제시된 JSON(Java Script Object Notation)에 서명되고 인코딩될 수 있다. 사용자 단말에서 의료용 IoT 장치에 요청을 전송 시, 요청과 함께 상기 보안 접속 토큰(SAT)이 첨부될 수 있다. 그러면, 단말로부터 수신된 SAT는 시스템 또는 의료용 IoT 장치에서 검증될 수 있으며, SAT 확인을 통해 요청자의 액세스 권한이 확인될 수 있다. 확인된 액세스 권한을 기반으로 요청을 허용하거나 거부하는 컨텍스트 제약 조건이 적용될 수 있다.
도 5는 본 발명의 일실시예에 있어서, IoT 기반의 건강 처방 보조(HAP)를 위한 접속 제어 방법을 도시한 흐름도이다.
도 5에서 각 단계들(510 내지 550 단계)은 도 3의 건강 처방 보조 및 보안 시스템(340)의 구성요소인 등록 제어부(341), 인증 제어부(342) 및 권한 제어부(343)에 의해 수행될 수 있다.
510 단계에서, 등록 제어부(341)는 IoT 기반의 건강 처방 보조(HPA)관련 의료 서비스를 제공받고자 하는 사용자들을 구분하기 위한 식별자 정보를 제공할 수 있다. 예컨대, 진료카드 번호 등을 제공할 수 있다.
520 단계에서, 등록 제어부(341)는 사용자 단말로부터 입력된 사용자의 개인 정보를 사용자의 식별자 정보와 연관시켜 저장함으로써, 등록할 수 있다.
이처럼, 사용자가 등록된 이후, 인증 제어부(342)는 IoT 네트워크를 형성하고 있는 적어도 하나의 의료용 IoT 장치로의 접속을 원하는 사용자 단말(330)로부터 사용자 단말(330)의 인증 요청을 수신할 수 있다. 예를 들어, 간호사, 의사 등은 자신이 소지한 사용자 단말을 이용하여 자신이 관리하는 환자와 관련된 의료 서비스를 확인하기 위해, 로그인 서비스(login service)를 요청할 수 있다. 이때, 릴레이 모드로 동작하는 경우, 인증 제어부(342)는 로그인 서비스를 요청받으면서, open ID를 이용하여 사용자 단말(330)을 인증하기 위해, 사용자 단말(330)에서 지정한 ID 제공자의 식별자 정보를 사용자 단말(330)로부터 함께 수신할 수 있다. 다른 예로, 직접 모드로 동작하는 경우, 인증 제어부(342)는 로그인 서비스를 요청받으면서, 사용자 단말(330)로부터 진료카드 번호, 주민번호 등을 수신할 수 있다.
530 단계에서, 인증 제어부(342)는 사용자 단말의 식별자 정보에 기초하여 사용자를 인증할 수 있다. 릴레이 모드로 동작하는 경우, 인증 제어부(342)는 상기 ID 제공자의 식별 정보에 기초하여 해당 ID 제공자(310)에게 사용자 단말(330)의 인증 요청을 전달할 수 있다.
예를 들어, 사용자 단말(330)의 화면에 표시되는 복수의 ID 제공자들(페이스북, 구글 인스타그램 등) 중 어느 하나가 선택되고, 확인 버튼이 클릭됨에 따라 사용자 단말(330)에서 선택된 ID 제공자(310)의 식별자 정보를 포함하는 로그인 서비스가 요청될 수 있다. 그러면, ID 제공자(310)는 사용자 단말(330)로 보안 자격(credential) 정보를 요청할 수 있다. 예컨대, ID 제공자의 웹사이트에 가입한 로그인 ID(이메일 주소 등) 및 패스워드 정보가 요청될 수 있다. ID 제공자(310)는 사용자 단말(330)로부터 상기 보안 자격 정보를 수신하여 사용자 단말의 로그인 ID 및 패스워드 정보가 ID 제공자(310)의 웹사이트에 가입된 ID 및 패스워드와 일치하는지 여부를 확인함으로써, 상기 사용자 단말(330)을 인증할 수 있다.
사용자 단말(330)의 인증에 성공하는 경우, ID 제공자(210)는 사용자 단말(330)로 비밀인증서(Secret Certificate, SCert)를 전송할 수 있다. 그러면, 비밀인증서를 수신한 사용자 단말(330)은 건강 처방 보조 및 보안 시스템(240)에 사용자 단말(330)이 접속을 원하는 의료용 IoT 장치(IoT 장치 관련 자원, 서비스)로의 접속을 위한 권한인 보안 접속 토큰(SAT)의 생성을 요청할 수 있다. 그러면, 인증 제어부(342)는 사용자 단말(330)로부터 보안 접속 토큰(SAT)의 생성을 요청 받을 수 있다. 이때, 인증 제어부(342)는 보안 접속 토큰(SAT)의 생성을 요청받으면서 사용자 단말(330)이 ID 제공자(310)로부터 제공받은 비밀인증서(SCert)를 사용자 단말(330)로부터 함께 수신할 수 있다.
540 단계에서, 인증 제어부(342)는 수신된 비밀인증서(SCert)를 기반으로 추출된 식별자 정보(ID)에 기초하여 사용자의 역할(role)을 나타내는 등급을 확인할 수 있다.
550 단계에서, 권한 제어부(343)는 확인된 역할(즉, 등급)을 기반으로 사용자에게 부여된 액세스 권한을 확인할 수 있다. 이처럼 인증된 사용자를 대상으로 액세스 권한이 확인되면, 사용자 단말로부터 수신된 요청(예컨대, 의료용 IoT 장치로의 접속/제어 요청)에 해당하는 의료 서비스가 제공될 수 있다.
일례로, 인증 제어부(342)는 수신된 비밀인증서(SCert)를 확인하여 사용자 단말(330)의 식별자 정보(ID)를 추출할 수 있다. 예컨대, 인증 제어부(342)는 비밀인증서(SCert)에 기초하여 리포지토리(Identity Provider Repository)에서 사용자 단말(330)의 식별자 정보를 추출할 수 있다. 그러면, 권한 제어부(343)는 추출된 사용자 단말(330)의 식별자 정보에 기초하여 보안 접속 토큰(SAT)을 생성할 수 있다.
예를 들어, 권한 제어부(343)는 상기 사용자 단말(230)의 식별자 정보에 기초하여 사용자 단말(230)의 등급(즉, 역할)을 확인하고, 확인된 사용자 단말(230)의 등급(즉, 역할)에 해당하는 정책(Policy), 권한(permission) 및 컨텍스트 제약 조건(context constraint)를 나타내는 보안 접속 토큰(SAT)을 생성할 수 있다. 그리고, 권한 제어부(243)는 생성된 보안 접속 토큰(SAT)를 사용자 단말(230)에 전송함으로써 상기 SAT를 발행할 수 있다. 권한 제어부(243)는 수신된 사용자 단말(330)의 SAT를 확인하여 접속 허가를 결정할 수 있다. 이외에, 사용자 단말(330)로부터 접속을 요청받은 의료용 IoT 장치에서 보안 접속 토큰(SAT)의 제시를 사용자 단말(330)에 요청하여, 사용자 단말(330)로부터 상기 SAT를 수신할 수도 있다. 이를 위해, 권한 제어부(243)는 인증된 사용자 단말(300)의 상기 요청을 해당 IoT 장치로 전달할 수 있다. 그러면, IoT 장치에서 SAT 제시 요청 및 SAT 확인을 수행할 수도 있다. 이처럼, 사용자 단말(330)의 SAT를 확인하여 접속 허가가 결정될 수 있으며, SAT는 위변조를 방지하기 위해 암호화되어 관리될 수 있다.
도 6은 본 발명의 일실시예에 있어서, 건강 처방 보조 및 보안 시스템이 인증 서버 및 권한 서버로 구성된 경우의 접속 제어 방법을 도시한 흐름도이다.
도 5에서는 인증 및 권한 제어가 하나의 서버에서 수행되는 것으로 설명하였으나, 도 6과 같이 인증 및 권한 제어가 각각 별도의 서버에서 수행될 수 있다. 이때, 인증 서버와 권한 서버는 서로 네트워크로 연결될 수 있다
도 6을 참고하면, 액세스(access) 제어는 인증 과정(610) 및 보안 접속 토큰(SAT) 생성 과정(620)의 두 부분으로 구성될 수 있다. 인증 과정(610)은 사용자 단말이 로그인 요청을 하면, 사용자 단말에서 ID 제공자를 선택하도록 허용하는 과정에 해당할 수 있다. 그리고, 전자 메일 주소, 암호화 등의 사용자 자격 증명을 사용자에게 요청하고, 사용자의 자격 증명을 확인한 후 사용자에게 비밀 인증서(Secret Certificate, SCert)를 발급하는 일련의 과정에 해당할 수 있다.
보안 접속 토큰(SAT) 생성 과정(620)은 사용자 단말에서 SCert를 인증 제어부(342)에 제공하고 SAT를 요청하고, 인증 제어부(342)는 SCert에 첨부된 ID 제공자의 서명을 검사하여 SCert의 유효성을 검사할 수 있다. 그런 다음, 인증 제어부(342)는 사용자 단말의 UID를 검색할 수 있으며, 권한 제어부(343)에 사용자 단말의 ID(즉, UID)를 제공하고, 사용자 단말에 새로운 SAT를 생성하도록 요청할 수 있다. SAT를 생성하는 자세한 동작은 도 7을 참고하여 후술하기로 한다.
도 7은 본 발명의 일실시예에 있어서, 보안 접속 토큰(SAT)을 생성하는 과정을 설명하기 위해 제공되는 도면이다.
도 7을 참고하면, 사용자 단말(330)로부터 SAT 생성이 요청되면(701), 권한 제어부(343)는 SAT 생성을 요청한 사용자 단말(330)이 블랙리스트(revocation list)에 포함되어 있는지 여부를 확인할 수 있다(702). 예를 들어, 블랙리스트(revocation list)는 IoT 장치로 접속 권한이 해지된 사용자 단말과 관련된 정보(예컨대, 단말의 ID 등)를 포함할 수 있다.
예를 들어, 사용자 단말(330)로부터 SAT 생성이 요청되면(701), 인증 제어부(342)는 수신된 비밀인증서(SCert)를 확인하여 사용자 단말(330)의 식별자 정보(ID)를 추출할 수 있다(703). 그러면, 권한 제어부(343)는 식별자 정보에 기초하여 블랙리스트에 사용자 단말(330)이 포함되어 있는지 여부를 확인할 수 있다. 이때, 사용자 단말(330)이 포함되지 않는 것으로 확인됨에 따라, 권한 제어부(343)는 사용자 단말의 식별자 정보와 매칭하여 해당 등급(즉, 역할)이 저장된 역할 DB를 참조하여, 상기 사용자 단말(330)의 식별자 정보에 기초하여 사용자 단말(330)의 역할을 확인할 수 있다(704). 즉, 사용자 단말(330)의 역할에 해당하는 등급을 확인할 수 있다.
그리고, 권한 제어부(343)는 확인된 사용자 단말(330)의 등급(즉, 역할)에 해당하는 정책(Policy)을 정책 DB로부터 추출할 수 있다(705). 예컨대, 사용자 단말(330)의 사용자가 간호사인 경우, 간호사에 해당하는 기지정된 정책(Policy)이 추출되고, 의사인 경우, 의사에 해당하는 기지정된 정책이 추출될 수 있다. 권한 제어부(343)는 권한(permission) DB에서 사용자 단말(330)에 해당하는 권한(permission)을 추출하고, 컨텍스트 제약 조건 DB에서 사용자 단말(330)에 해당하는 컨텍스트 제약 조건(context context)을 추출할 수 있다(706).
이어, 권한 제어부(343)는 추출된 정책(Policy), 권한(permission), 및 상황제한(context context)에 기초하여 사용자 단말(330)을 위한 새로운 보안 접속 토큰(SAT)을 생성할 수 있다(707). 예컨대, 아래의 표 2와 같은 SAT 생성 알고리즘이 이용될 수 있다. 즉, 새로운 사용자 단말(330)의 역할에 대해 정의된 정책, 권한, 및 컨텍스트 제약 조건을 나타내는 새로운 보안 접속 토큰(SAT)이 생성될 수 있다. 생성된 SAT가 사용자 단말로 전달되고, 사용자 단말은 리소스 및 제공받고자 하는 의료 서비스에 액세스하기 위해 의료용 IoT 장치에 SAT를 제시해야 할 수 있다. 의료용 IoT 장치는 사용자 단말로부터 수신한 SAT를 확인하고 액세스 권한을 부여할 수 있다. 이때, 권한 제어부(343)는 생성된 보안 접속 토큰(SAT)을 디지털 서명하여 위변조로부터 보호할 수 있다. 그러면, 디지털 서명된 보안 접속 토큰(SAT)이 사용자 단말(330)에게 발행될 수 있다.
Figure PCTKR2018007896-appb-I000019
아래의 표 3은 JASON 형식으로 인코딩된 SAT를 나타낼 수 있다.
Figure PCTKR2018007896-appb-I000020
표 3에서, ID는 SAT의 식별자를 나타내는 것으로서, 고유한 난수(random number)가 생성되어 ID 필드에 할당될 수 있다. 두 개의 SAT는 동일한 ID를 가지지 않을 수 있다. 즉, SAT 별로 서로 다른 ID가 할당될 수 있다.Issue Instant (II)는 SAT가 발급된 UTC 형식의 시간을 나타내고, 발급 기관(IS)은 SAT 발급 기관의 식별자 또는 발급 기관 도메인 이름을 나타낼 수 있다.
서명(SIG)은 발급 기관의 서명을 나타낼 수 있다. 발급 기관은 SAT를 해시하고 공개 키로 서명할 수 있으며, 서명을 통해 발행된 SAT의 위조가 방지될 수 있다.
공개 키(IPK)는 발급 기관의 공개 키를 나타내는 것으로서, IPK는 SIG 필드를 확인하기 위해 이용될 수 있다.
리소스(RES)는 의료용 IoT 장치가 제공하는 서비스 및 리소스를 고유하게 찾는 데 사용되는 범용 리소스 식별자를 나타낼 수 있다.
액세스 권한(AR)은 발급 기관이 사용자에게 부여한 일련의 작업(ACT)을 나타낼 수 있다.
의무(OB)는 두 개의 필드를 포함하며, Not Before(NB)는 토큰을 받아들이지 않아야 하는 시간 이전을 나타내고, Not After(NA)는 토큰을 받아들이지 않아야 하는 시간 이후를 나타낼 수 있다.
컨텍스트(CT)의 필드에는 SAT 평가 프로세스 중에 컨텍스트 제약 조건을 확인하기 위한 입력으로 사용되는 컨텍스트 정보 세트가 정의될 수 있다.
조건 스크립트 길이(CSL)는 조건 스크립트의 길이(바이트)를 나타내고, 조건 스크립트(CS)는 조건과 컨텍스트 제약의 세트가 정의되고 조건 스크립트로 구성될 수 있다. 조건 스크립트는 각 SAT에 포함된 지침 목록으로서, 지침은 Forth와 같은 스크립팅(Forth-like scripting) 언어로 작성될 수 있다. Forth는 Turing-complete가 아닌, 필수적인 스택 기반 컴퓨터 프로그래밍 언어로서, 상기 언어로 작성된 조건 스크립트는 들어오는 요청을 수락하거나 거부하는데 필요한 파라미터를 유연하게 변경할 수 있다. 의료용 IoT 장치에서는 경량의 운영체제를 사용하는데, 경량의 운영 체제는 새로운 코드 또는 라이브러리를 받아들이고 통합하는데 필요한 보안 모듈이 없기 때문에 동적 소프트웨어 업데이트를 지원하지 않을 수 있다. 이때, C, C ++, Python 또는 Java로 작성된 프로그램과 달리, Forth 언어로 작성된 스크립트는 쉽게 업데이트 할 수 있다.
이하에서는 도 8 내지 도 10을 참고하여, SAT 인증 동작에 대해 설명하기로 한다.
보안 접속 토큰(SAT)은 SAT에 포함된 조건 스크립트를 실행하는 ACLogic 엔진이라는 확인 프로세스에 의해 확인될 수 있다. ACLogic 엔진은 실행 결과에 따라 허용 또는 거부 결정을 내릴 수 있다. ACLogic 엔진은 요청이 요청자에 대해 정의된 제약 조건을 충족하는지 여부를 확인할 수 있으며, 스택이라 불리우는 데이터 구조를 사용할 수 있다. 보안 접속 토큰(SAT)은 조건 스크립트에서 아무 것도 실패하지 않고 최상위 스택 항목이 참(0이 아닌)인 경우 유효할 수 있다. 스택은 카드의 스택으로 시각화될 수 있는 매우 간단한 데이터 구조를 가지며, 푸시와 팝의 두 가지 동작을 허용할 수 있다. 푸시(PUSH)는 스택 위에 항목을 추가하는 것이고, 팝(POP)은 스택에서 최상위 항목을 제거하는 것을 나타낼 수 있다. 스크립트 실행이 종료되면, 스택은 TRUE 값을 유지해야 할 수 있다. ACLogic 엔진은 스택에서 TRUE 값을 찾으면 허가 결정을 반환하고, 그렇지 않으면, 거부 결정을 반환할 수 있다. 예컨대, 스크립트 실행은 아래의 표 4와 같이 표현될 수 있다.
Figure PCTKR2018007896-appb-I000021
위의 표 3과 같은 조건 스크립트의 실행은 도 8 내지 도 10과 같이 세 부분으로 구분될 수 있다. 도 8은 서명을 확인하는 것으로서, 서명 확인 스크립트는 SIG SPK DECRYPT HASH EQUALVERIFY와 같을 수 있다. SIG 필드의 값은 발급 기관의 공개키(SPK)로 해독될 수 있으며, 발급 기관의 개인 키는 SSK에 해당할 수 있다. HASH 연산은 JASON envelope(SAT 패킷)의 해시를 생성하기 위해 이용될 수 있다. 해시 값은 해독된 SIG 값과 매칭될 수 있다. 여기서, SIG 값은 SIG=EncryptSSK(Hash(SAT))로 계산된 것으로 가정할 수 있다. 도 9는 의무 필드의 검증을 나타내는 것으로서, 의무를 검증(즉, 확인)하는 스크립트는 NB TIME GRATER_THAN NA TIMELESS_THAN에 해당할 수 있다. ACLogic 엔진은 현재 시간(TIME)이 NB 필드의 값(GRATER_THAN)보다 큰지 여부를 확인할 수 있으며, NA 필드의 값이 현재 시간(TIME)이 (LESS_THAN)보다 작은지 여부를 확인할 수 있다.
도 10은 컨텍스트 제약 조건의 검증을 나타내는 것으로서, 검증 스크립트는 OPERATION_MODE FORALL BATTERY_STATUS FORWALL LOCATION FORALL에 해당할 수 있다. 스크립트에 따르면, 요청은 사용자의 위치뿐만 아니라 의료용 IoT 장치의 작동 모드 및 배터리 상태(FORALL)에 관계없이 제공되어야 할 수 있다. FORALL 연산은 스택 최상위에서 해당 요소를 제거하여 작동 모드, 배터리 상태 및 위치의 값을 무시할 수 있다. 스택(stack) 상단에 TRUE 값이 있으면 스크립트의 모든 조건과 제약 조건이 충족되었음을 의미하는 조건 스크립트가 성공적으로 실행되고, 스택 상단에 존재하는 TRUE 이외의 값은 하나 이상의 조건 또는 제약 조건이 충족되지 않았음을 나타낼 수 있다.
이하에서는 도 11을 참고하여, 건강 처방 보조 및 보안 시스템(340)에서 생성되어 사용자 단말(330)에 발행된 보안 접속 토큰(SAT)을 확인하여 사용자 단말(330)이 의료용 IoT 장치로 접속 허가하는 동작에 대해 상세히 설명하기로 한다.
보안 접속 토큰(SAT)의 확인(Verification)은 AC로직(ACLogic) 엔진에 의해 수행될 수 있다. AC로직 엔진에 기반하여 SAT를 확인하는 접근 방법으로 위임 기반 접근법(Delegation Approach)이 이용될 수 있다.
도 11을 참고하면, 개인 영역 네트워크와 함께 위치하는 스마트 게이트웨이는 의료용 IoT 장치를 고려하여 SAT 검증 프로세스를 수행할 수 있다. 도 2에서 설명한 바와 같이 스마트 게이트웨이는 IoT 장치에 비해 리소스가 풍부한 엔티티(entity)에 해당할 수 있다. 스마트 게이트웨이는 ACLogic 엔진에 내장되어 있으며, 두 단계로 들어오는 서비스 액세스 요청을 인증 할 수 있다. 첫 번째 단계에서, 스마트 게이트웨이는 액세스 요청에 첨부된 SAT의 유효성을 검사하고, 두 번째 단계에서, SAT 검증 결과(예컨대, 요청 수락 또는 거절)에 따라 요청된 의료 장치(즉, 의료용 IoT 장치)로 요청을 전달하거나 요청된 IoT 장치로 전송하지 않고 요청을 거부할 수 있다. 이에 따라, 연산 집약적인 동작으로부터 리소스가 제한적인 장치의 부담을 덜어주고 관련된 암호화 하드웨어 또는 소프트웨어의 저장 및 메모리 요구가 감소될 수 있다. 이러한 위임 기반 접근법(Delegation Approach)은 의료용 IoT 장치가 실시간 요청을 제공 가능하도록 할 수 있다. 스마트 게이트웨이는 분산적 접근법(Distributed Approach), 반 분산적 접근법(semi-distributed approach)과 중앙집중적 접근법(Centralized Approach)에서 사용되는 클라우드 인증 서버와 비교할 때 의료용 IoT 장치에 상대적으로 더 가깝게 위치할 수 있다. 이에 따라, 클라우드에 작업을 위임하지 않고, 스마트 게이트웨이에 SAT 확인 작업을 위임함으로써, 사용자 단말의 요청에 대한 처리 속도가 빨라질 수 있다.
실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다.
이상과 같이 실시예들이 비록 한정된 실시예와 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.
그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

Claims (8)

  1. 사물 인터넷(IoT) 기반의 건강 처방 보조 및 보안 시스템에 있어서,
    상기 사물 인터넷 기반의 건강 처방 보조를 제공받고자 하는 사용자들을 구분하기 위한 식별자 정보를 제공하고, 사용자 단말로부터 입력된 사용자의 개인 정보를 상기 제공된 해당 사용자의 식별자 정보와 연관하여 등록하는 등록 제어부;
    상기 사용자 단말의 식별자 정보에 기초하여 사용자를 인증하는 인증 제어부; 및
    인증된 상기 사용자를 대상으로, 해당 사용자의 역할을 확인하고, 확인된 역할을 기반으로 해당 사용자에게 부여된 액세스 권한을 확인하는 권한 제어부
    를 포함하고,
    로그인한 상기 사용자를 대상으로, 확인된 상기 액세스 권한에 기초하여 상기 사용자 단말로부터 수신된 요청에 해당하는 의료 서비스가 제공되는 것
    을 특징으로 하는 건강 처방 보조 및 보안 시스템.
  2. 제1항에 있어서,
    상기 권한 제어부는,
    상기 사용자에 해당하는 역할이 환자, 간호사, 의사, 보안 관리자인지 여부를 확인하고, 확인된 역할과 관련하여 미리 정의된 정책에 따라 지정된 상기 액세스 권한을 확인하는 것
    을 특징으로 하는 건강 처방 보조 및 보안 시스템.
  3. 제1항에 있어서,
    상기 역할은, 사용자의 개인 정보, 및 직업 경험 정보에 기초하여 결정되는 것을 특징으로 하는 건강 처방 보조 및 보안 시스템.
  4. 제1항에 있어서,
    상기 권한 제어부는,
    미리 지정된 컨텍스트(context) 제약 조건에 기초하여 사용자 단말로부터 수신된 요청을 허용하거나 거부할지 여부를 결정하는 것
    을 특징으로 하는 건강 처방 보조 및 보안 시스템.
  5. 제1항에 있어서,
    상기 권한 제어부는,
    상기 사용자 단말로부터 요청과 함께 수신된 보안 접속 토큰(security access token, SAT)을 검증함으로써, 상기 요청에 해당하는 접근 권한을 확인하는 것
    을 특징으로 하는 건강 처방 보조 및 보안 시스템.
  6. 제5항에 있어서,
    상기 보안 접속 토큰(security access token, SAT)은, 상기 역할에 해당하는 정책, 권한 및 컨텍스트 제약 조건에 기초하여 검색된 정보를 이용하여 서명함으로써 생성되고, 상기 사용자 단말로 제공되는 것을 특징으로 하는 건강 처방 보조 및 보안 시스템.
  7. 제5항에 있어서,
    상기 권한 제어부는,
    상기 보안 접속 토큰(security access token, SAT)에 대한 유효성이 검증됨에 따라, 상기 요청을 해당 IoT 장치로 전달하는 것을 특징으로 하는 건강 처방 보조 및 보안 시스템.
  8. 사물 인터넷(IoT) 기반의 건강 처방 보조 및 보안 방법에 있어서,
    상기 사물 인터넷 기반의 건강 처방 보조를 제공받고자 하는 사용자들을 구분하기 위한 식별자 정보를 제공하는 단계;
    사용자 단말로부터 입력된 사용자의 개인 정보를 상기 제공된 해당 사용자의 식별자 정보와 연관하여 등록하는 단계;
    상기 사용자 단말의 식별자 정보에 기초하여 사용자를 인증하는 단계; 및
    인증된 상기 사용자의 역할을 확인하고, 확인된 상기 역할을 기반으로 해당 사용자에게 부여된 액세스 권한을 확인하는 단계
    를 포함하고,
    로그인된 상기 사용자를 대상으로, 확인된 상기 액세스 권한에 기초하여 상기 사용자 단말로부터 수신된 요청에 해당하는 의료 서비스가 제공되는 것
    을 특징으로 하는 건강 처방 보조 및 보안 방법.
PCT/KR2018/007896 2018-03-14 2018-07-12 IoT 기반 건강 처방 보조 및 보안 시스템 그리고 방법 WO2019177207A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20180029896 2018-03-14
KR10-2018-0029896 2018-03-14

Publications (1)

Publication Number Publication Date
WO2019177207A1 true WO2019177207A1 (ko) 2019-09-19

Family

ID=67907803

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/007896 WO2019177207A1 (ko) 2018-03-14 2018-07-12 IoT 기반 건강 처방 보조 및 보안 시스템 그리고 방법

Country Status (1)

Country Link
WO (1) WO2019177207A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022006825A1 (zh) * 2020-07-09 2022-01-13 Oppo广东移动通信有限公司 物联网中的设备接入方法、装置、计算机设备及存储介质
CN114598599A (zh) * 2020-11-20 2022-06-07 深圳Tcl新技术有限公司 物联网设备的配网方法、装置、物联网设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101603988B1 (ko) * 2014-12-17 2016-03-17 세림시스템즈 주식회사 상황인식 서비스 시스템
US20160112429A1 (en) * 2014-10-15 2016-04-21 Ayla Networks, Inc. Role based access control for connected consumer devices
KR101648521B1 (ko) * 2009-03-06 2016-08-16 제말토 에스에이 스마트 카드들로의 브라우저-기반의 액세스에 보안을 제공하는 시스템 및 방법
KR101659708B1 (ko) * 2016-05-09 2016-09-23 인하대학교 산학협력단 사물 인터넷 기반의 안전한 건강 처방 보조 기법 및 시스템
US20160379220A1 (en) * 2015-06-23 2016-12-29 NXT-ID, Inc. Multi-Instance Shared Authentication (MISA) Method and System Prior to Data Access

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101648521B1 (ko) * 2009-03-06 2016-08-16 제말토 에스에이 스마트 카드들로의 브라우저-기반의 액세스에 보안을 제공하는 시스템 및 방법
US20160112429A1 (en) * 2014-10-15 2016-04-21 Ayla Networks, Inc. Role based access control for connected consumer devices
KR101603988B1 (ko) * 2014-12-17 2016-03-17 세림시스템즈 주식회사 상황인식 서비스 시스템
US20160379220A1 (en) * 2015-06-23 2016-12-29 NXT-ID, Inc. Multi-Instance Shared Authentication (MISA) Method and System Prior to Data Access
KR101659708B1 (ko) * 2016-05-09 2016-09-23 인하대학교 산학협력단 사물 인터넷 기반의 안전한 건강 처방 보조 기법 및 시스템

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022006825A1 (zh) * 2020-07-09 2022-01-13 Oppo广东移动通信有限公司 物联网中的设备接入方法、装置、计算机设备及存储介质
CN114598599A (zh) * 2020-11-20 2022-06-07 深圳Tcl新技术有限公司 物联网设备的配网方法、装置、物联网设备及存储介质
CN114598599B (zh) * 2020-11-20 2024-01-19 深圳Tcl新技术有限公司 物联网设备的配网方法、装置、物联网设备及存储介质

Similar Documents

Publication Publication Date Title
Karunarathne et al. Security and privacy in IoT smart healthcare
Srivastava et al. The future of blockchain technology in healthcare internet of things security
Yaqoob et al. Security vulnerabilities, attacks, countermeasures, and regulations of networked medical devices—A review
Awotunde et al. Privacy and security concerns in IoT-based healthcare systems
Pal et al. Policy-based access control for constrained healthcare resources in the context of the Internet of Things
Sicari et al. A policy enforcement framework for Internet of Things applications in the smart health
US20210336956A1 (en) Electronic Health Data Access Control
Azbeg et al. Access control and privacy-preserving blockchain-based system for diseases management
Vithanwattana et al. Developing a comprehensive information security framework for mHealth: a detailed analysis
Ganiga et al. Security framework for cloud based electronic health record (EHR) system
KR101659708B1 (ko) 사물 인터넷 기반의 안전한 건강 처방 보조 기법 및 시스템
Albuquerque et al. Security in cloud-computing-based mobile health
Aski et al. Advances on networked ehealth information access and sharing: Status, challenges and prospects
WO2019177207A1 (ko) IoT 기반 건강 처방 보조 및 보안 시스템 그리고 방법
Jayabalan et al. A study on authentication factors in electronic health records
Islam et al. A conceptual framework for an IoT-based health assistant and its authorization model
Foo Kune et al. Toward a safe integrated clinical environment: a communication security perspective
Saxena et al. Internet of Medical Things (IoMT) security and privacy: A survey of recent advances and enabling technologies
Petkovic et al. Privacy and security in e-Health applications
Khan et al. Toward a synergy among discretionary, role-based and context-aware access control models in healthcare information technology
Riadi et al. Developing data integrity in an electronic health record system using blockchain and InterPlanetary file system (Case Study: COVID-19 data)
Bhardwaj et al. Review and analysis of security model in healthcare system
Makina et al. Survey on security and privacy in Internet of Things‐based eHealth applications: Challenges, architectures, and future directions
Wenhua et al. A lightweight security model for ensuring patient privacy and confidentiality in telehealth applications
Chang et al. A secured internet of robotic things (IoRT) for long-term care services in a smart building

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: 18909329

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: 18909329

Country of ref document: EP

Kind code of ref document: A1