JP7387570B2 - Device identification device, device identification method, and computer program - Google Patents

Description

The present invention relates to a device identification device, a device identification method, and a computer program.

2. Description of the Related Art Conventionally, for example, Patent Document 1 is known as a technique for identifying the type of home appliance connected to a communication network. Patent Document 1 discloses that in order to determine the type of electrical appliance, a definition file defined by at least two types of packets that are received by an electrical appliance is associated with each packet constituting the packet. Along with the score, each appliance information is stored to determine the type of appliance, and the packet received from the appliance is compared with the one packet to give a score for each definition file, and the definition file with the highest score is assigned a score. An information processing device is described in which the corresponding electrical appliance information is the electrical appliance information of an electrical appliance that has received the packet. In Patent Document 1, information on the MAC address (Media Access Control address) of the electrical appliance (the first 24-bit vendor identifier (vendor ID) and the middle 8-bit model identifier (model ID)) is used as the definition file. .

Patent No. 4855499

However, in the technology of Patent Document 1 mentioned above, information on the MAC address of the electrical appliance is used as a definition file, but since the MAC address is assigned to the network interface provided in the electrical appliance, the vendor ID of the MAC address is not necessarily the same as the vendor ID of the electrical appliance. does not necessarily indicate the device vendor. For this reason, the leading part of the MAC address may be the same even for electrical appliances from different device vendors, which may reduce the accuracy of identifying the type of electrical appliance.

The present invention has been made in consideration of such circumstances, and its purpose is to efficiently and accurately identify the type of device such as an IoT (Internet of Things) device connected to a communication network. The aim is to achieve this goal.

(1) One aspect of the present invention is an IPFIX data collection unit that collects IPFIX (IP Flow Information Export) data generated from device communication data, and a feature amount generation unit that generates a packet communication feature amount from the IPFIX data. and a device identification unit that identifies a device type from the feature amount of the device to be identified using a device type identification model generated by machine learning based on the feature amount , the feature amount generation unit generates the feature amounts separately for the first communication that the device automatically performs and the second communication that the device performs in response to the user's operation, and the device type identification model The device identification unit is a device identification device that uses a device type identification model for the first communication and a device type identification model for the second communication .
( 2 ) One aspect of the present invention is the device identification device according to ( 1 ) above, wherein the device is an IoT device.
( 3 ) In one aspect of the present invention, the device type identification model outputs a device type identification result and a confidence level of the identification result, and the device identification unit further outputs a confidence level of the past identification result. This is the device identification device according to (1) above, which identifies the device type based on the device type.

( 4 ) One aspect of the present invention includes an IPFIX data collection step of collecting IPFIX (IP Flow Information Export) data generated from device communication data, and a feature amount generation step of generating a packet communication feature amount from the IPFIX data. and a device identification step of identifying a device type from the feature amount of the device to be identified using a device type identification model generated by machine learning based on the feature amount , the feature amount generation step. In the step, the feature amounts are generated separately for a first communication that the device automatically performs and a second communication that the device performs in response to a user's operation, and the device type identification model is based on the first communication. and the second communication, and the device identification step uses the device type identification model of the first communication and the device type identification model of the second communication.

( 5 ) One aspect of the present invention includes an IPFIX data collection step in which a computer collects IPFIX (IP Flow Information Export) data generated from communication data of a device, and a feature amount of packet communication is generated from the IPFIX data. a step of generating a feature amount; and a device identification step of identifying a device type from the feature amount of the device to be identified using a device type identification model generated by machine learning based on the feature amount. In the computer program, the feature amount generation step generates the feature amounts separately for a first communication that the device automatically performs and a second communication that the device performs in response to a user's operation; The device type identification model is generated separately for the first communication and the second communication, and the device identification step includes a device type identification model for the first communication and a device type identification model for the second communication. It is a computer program used .

According to the present invention, it is possible to efficiently and accurately identify the type of device such as an IoT device connected to a communication network.

FIG. 1 is a block diagram illustrating an example configuration of a communication system and a device identification device according to an embodiment. FIG. 2 is an explanatory diagram of a method of generating IPFIX data. FIG. 2 is an explanatory diagram of a method of generating IPFIX data. FIG. 2 is an explanatory diagram of a method of generating IPFIX data. FIG. 2 is an explanatory diagram of a method of generating IPFIX data. FIG. 2 is an explanatory diagram of a method of generating IPFIX data. 3 is a chart showing an example of a service based on regular communication. It is a chart showing the characteristic amount of steady communication concerning one embodiment. 3 is a chart showing the correspondence between feature amounts and fields of IPFIX data according to an embodiment. FIG. 3 is a chart showing an example of a service based on communication during operation. FIG. It is a chart showing an example of a protocol related to communication during operation. 3 is a flowchart illustrating an example of a procedure of a device identification method according to an embodiment. FIG. 1 is an explanatory diagram showing Example 1 of a device identification device according to an embodiment. 3 is a chart showing an example of feature amount data according to an embodiment. FIG. 2 is an explanatory diagram illustrating an example of a device identification unit according to an embodiment. FIG. 3 is an explanatory diagram showing Example 2 of a device identification device according to an embodiment.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 is a block diagram illustrating a configuration example of a communication system and a device identification device according to an embodiment. In the communication system 1 shown in FIG. 1, the device identification device 10 is connected to a gateway (GW) of each home (home) 30-1, 30-2, 30-3, etc. via a communication network NW such as the Internet. Communicate with 31. Each home 30-1, 30-2, 30-3, . . . is provided with a gateway 31 and a device dev. Hereinafter, the platforms 30-1, 30-2, 30-3, . . . will be referred to as platforms 30 unless they are particularly distinguished. The home 30 according to the present embodiment is an example of a base (device communication base) with which the device dev communicates.

The device dev communicates with, for example, a server connected to the Internet via the gateway 31. The device dev is, for example, an IoT device. There are multiple types (device types) of the device dev. In FIG. 1, three device types "A type", "B type", and "C type" are illustrated as device types. For example, the device dev (type A) is a measurement sensor such as a power meter. For example, device dev (type B) is a web camera. For example, the device dev (C type) is a home appliance such as an air conditioner or a smart speaker.

The gateway 31 determines whether communication of the device dev is permitted or not, and controls the communication of the device dev according to the determination result. The gateway 31 includes an IPFIX (IP Flow Information Export) converter 32 .

The IPFIX conversion unit 32 generates IPFIX data regarding communication performed by the device dev under its own gateway 31. The IPFIX conversion unit 32 generates IPFIX data from the communication data of the device dev passing through its own gateway 31. IPFIX data is standardized by RFC (Request for Comments) 7011 of IETF (Internet Engineering Task Force). IPFIX data is data indicating the flow of packet communication.

[IPFIX data]
In this embodiment, IPFIX data is used to identify the device type of device dev. IPFIX data will be explained below.

(IPFIX data field)
There are approximately 500 types of records defined as IPFIX data. Examples of fields used in IPFIX data are described below.

The "sourceMacAddress/destinationMacAddress" field is a field indicating the MAC address of the transmission source and the transmission destination.
The "sourceIPv4Address/sourceIPv6Address/destinationIPv4Address/destinationIPv6Address" field is a field indicating the IP address of the source and destination.
The "octetTotalCount/packetTotalCount" field is a field indicating the data size and the number of packets in the communication direction.
The "reverseOctetTotalCount/reversePacketTotalCount" field is a field indicating the data size and number of packets in the reverse communication direction.
The "protocolIdentifier" field is a field indicating a protocol related to IP (Internet Protocol). The values of the "protocolIdentifier" field include "1: ICMP (IPv4)", "6: TCP", "17: UDP", "58: ICMP (IPv6)", etc., and these are generally used in IoT devices. Ru.
The "sourceTransportPort/destinationTransportPort" field is a field indicating information regarding the source and destination port numbers.
The "flowStartMilliseconds/flowEndMilliseconds/flowDurationMilliseconds" field is a field indicating the start time and end time of communication data summarized as IPFIX data. "DurationMilliseconds" is the value of "end time - start time".

(IPFIX data parameters)
IPFIX data is data that summarizes communication data for each session and for each fixed period of time. According to IPFIX data, the amount of data to be recorded can be significantly reduced compared to the case of recording packets. An example of a method for generating IPFIX data will be described with reference to FIGS. 2 to 6.

In the example of the IPFIX data generation method shown in FIG. 2, four pieces of communication data exchanged between node X and node Y are summarized and converted into one piece of IPFIX data (IPFIX record). There are two examples shown in FIGS. 3 and 4 as fields used for the target period of communication data summarization.

In the example of FIG. 3, the "active timeout" field determines the period for which communication data is summarized. The "active timeout" field is a field that indicates the time when the flow is forcibly considered to end. As illustrated in Figure 3, if the exchange of communication data exceeds the time indicated in the "active timeout" field, the flow is forcibly considered to have ended, and the exchange between node The communication data is summarized and converted into one piece of IPFIX data. Therefore, among the communication data exchanged between node X and node Y, communication data after the flow is forcibly determined to have ended is not converted to IPFIX data.

In the example of FIG. 4, the "idle timeout" field determines the period for which communication data is summarized. The "idle timeout" field is a field that indicates the time that is considered to be a timeout when communication data is interrupted. As illustrated in FIG. 4, if the time indicated in the "idle timeout" field has elapsed since the communication data exchange is interrupted, the flow is forcibly deemed to have ended, and by then, node X and node Y The communication data exchanged between them is summarized and converted into one piece of IPFIX data.

Note that in the case of a protocol that does not have a session, such as UDP (User Datagram Protocol), communication data can be summarized using the "idle timeout" field or "active timeout" field under certain conditions, as illustrated in Figure 5. The target period is determined.

The above is an explanation of IPFIX data.

The present inventor conceived the idea of using IPFIX data having the characteristics described above to identify the device type of a device such as an IoT device connected to a communication network. The reasons for this are that, according to IPFIX data, it is possible to reduce the amount of data indicating the flow of packet communication, and it is easy to obtain feature quantities useful for identifying device types as feature quantities of packet communication.

FIG. 6 is an explanatory diagram for explaining the feature amount of packet communication using IPFIX data according to this embodiment. Hereinafter, the feature amount of packet communication may be simply referred to as the feature amount.

In FIG. 6, "Communication 1" indicates communication that has a session and is regularly performed by a device. Furthermore, “Communication 2” indicates communication that has a session and is performed by a device in response to a user's operation. Furthermore, “Communication 3” indicates communication without a session, which is performed by a device in response to a user's operation.

As shown in FIG. 6, the IPFIX record is generated by summarizing communication packet information based on sessions and other rules, so the amount of data is reduced compared to communication packets.

In addition, as shown in FIG. 6, when using communication packets as they are to generate the feature amount of packet communication at each unit time t1, t2, ..., t10, in "Communication 2" and "Communication 3", , features are generated by cutting a session or a series of packets into pieces. In "Communication 2", communication packets are generated over unit times t1-t3 and t7-t10, but since the number of communication packets included in each unit time is different, the communication packets are used as they are to calculate the feature amount. When generated, fluctuations occur as a feature quantity. In "Communication 3", communication packets are generated over the unit time t1-t7, but even if these communication packets have the same communication content, the number of communication packets differs by the unit time t7, so the feature values are different. there is a possibility.

On the other hand, when generating the feature amount of packet communication using IPFIX data, in "Communication 2", one IPFIX record is generated from the communication packet of one session "Unit time t1-t3" in unit time t3. Also, one IPFIX record is generated from communication packets of one session "unit time t7-t10" in unit time t10. Since these IPFIX records for each unit time t3 and t10 of "Communication 2" are generated for each session, it is highly likely that similar feature amounts in the session of "Communication 2" can be obtained from each IPFIX record. Furthermore, in "Communication 3", one IPFIX record is generated in unit time t7 from communication packets of unit time t1-t7. The IPFIX record for the unit time t7 of "Communication 3" is generated from the information of the communication packets for the unit time t1-t7, so the feature values of "Communication 3" that are different from other communications can be obtained from the IPFIX record. There is a high possibility that

As described above, according to the IPFIX data, the amount of data indicating the flow of packet communication can be reduced, and the characteristic amount of each packet communication can be accurately obtained. By reducing the amount of data indicating the flow of packet communication, it is possible to efficiently acquire the characteristic amount of packet communication. Further, it can be said that the accurate feature amount of each packet communication is a feature amount useful for identifying the device type of the device that performs each packet communication. Therefore, in this embodiment, the device type of a device such as an IoT device connected to a communication network can be efficiently and accurately identified by generating the feature amount of packet communication using IPFIX data. We aim to

[Device identification device]
The device identification device 10 according to this embodiment will be explained. In FIG. 1, a device identification device 10 includes an IPFIX data collection section 11, a feature generation section 12, a model learning section 13, and a device identification section 14.

Each function of the device identification device 10 is realized by the device identification device 10 being equipped with computer hardware such as a CPU (Central Processing Unit) and memory, and the CPU executing a computer program stored in the memory. be done. Note that the device identification device 10 may be configured using a general-purpose computer device, or may be configured as a dedicated hardware device. For example, the device identification device 10 may be configured using a server computer connected to a communication network such as the Internet. Further, each function of the device identification device 10 may be realized by cloud computing. Further, the device identification device 10 may be realized by a single computer, or the functions of the device identification device 10 may be realized by distributing the functions to a plurality of computers.

The gateway 31 of each home 30 transmits the IPFIX data of each device dev under its own control generated by the IPFIX conversion unit 32 to the device identification device 10 . The IPFIX data collection unit 11 receives IPFIX data of each device dev from the gateway 31 of each home 30.

The IPFIX data collection unit 11 aggregates IPFIX data received from each home 30 for each MAC address. The MAC address is indicated in the "sourceMacAddress/destinationMacAddress" field of the IPFIX data. The IPFIX data collection unit 11 stores IPFIX data aggregated for each MAC address for a certain period of time.

The feature generation unit 12 receives IPFIX data aggregated for each MAC address from the IPFIX data collection unit 11. The feature amount generation unit 12 uses IPFIX data aggregated for each MAC address to generate feature amount data indicating the feature amount of packet communication.

[Feature value]
The characteristic amount of packet communication according to this embodiment will be explained. Broadly speaking, there are two types of communication performed by the device dev: communication performed by the device on a regular basis (regular communication), and communication performed by the device in response to a user's operation (communication during operation).

In steady communication, the device dev automatically communicates based on information set in, for example, firmware. Therefore, in regular communication, constant communication is performed regardless of whether or not the user operates the device dev.

The operation communication is communication that occurs when the user performs an operation on the device dev. Therefore, in operation communication, a situation may occur in which the content of the communication performed by the user's operation differs greatly depending on the device type.

Therefore, in this embodiment, we focused on the characteristics of the above-mentioned regular communication and operation communication, and set the regular communication and operation communication so that the differences in the behavior of each device type are reflected. Generate feature data separately for time and communication.

(Features of steady communication)
FIG. 7 shows a service that the device dev performs through regular communication. Each service "ICMP", "IGMP", "FTP", "Telnet", "DNS, mDNS", and "SSDP" is assigned a feature number (feature number). The service is determined by the value of "destinationTransportPort" in the "sourceTransportPort/destinationTransportPort" field of the IPFIX data. In the service shown in FIG. 7, communication behavior differs depending on the device type. Therefore, the feature generation unit 12 generates features for each service "ICMP", "IGMP", "FTP", "Telnet", "DNS, mDNS", and "SSDP" shown in FIG. , the information "IPFIX record number", "sent packet size", "received packet size", "sent packet number", "received packet number", and "session duration time" shown in FIG. 8 in unit time are converted into feature data. do. As shown in FIG. 8, the feature generation unit 12 generates variations of each information such as "total value,""minimumvalue,""maximumvalue,""averagevalue," and "median value" into feature data. include.

The feature value generation unit 12 converts "transmitted packet size", "received packet size", "number of transmitted packets", "number of received packets", and "session duration" among the information shown in FIG. 8 into IPFIX data. It is generated from the values of each field shown in 9. Regarding the "number of IPFIX records", the feature amount generation unit 12 counts the number of IPFIX records per unit time from the IPFIX data.

(Features of communication during operation)
FIG. 10 shows a service that the device dev performs through communication during operation. Each service "HTTP", "HTTPS", and "SMB" is assigned a feature number (feature number). In these services, the communication data generated by the device dev when the user operates the device dev varies greatly depending on the application running on the device dev. For this reason, the feature generation unit 12 generates the information "IPFIX record" shown in FIG. 8 in unit time for each service "HTTP", "HTTPS", and "SMB" shown in FIG. "Number of transmitted packets", "Sent packet size", "Received packet size", "Number of transmitted packets", "Number of received packets", and "Session duration time" are converted into feature data. As shown in FIG. 8, the feature generation unit 12 generates variations of each information such as "total value,""minimumvalue,""maximumvalue,""averagevalue," and "median value" into feature data. include.

Note that during operation communication, there are many communications to ports other than "well-known ports", and a specific range of destination port numbers is often used for each device type. For this reason, it is preferable to divide port numbers into specific ranges and use them as feature quantities even for ports other than "well-known ports."

Furthermore, in operation communication, there are differences in the protocols used depending on the device type. For example, TCP (Transmission Control Protocol) is used when sending instructions to home appliances such as a robot vacuum cleaner, but UDP is used when viewing images captured by a web camera. For this reason, the feature amount generation unit 12 further generates the features shown in FIG. 8 in unit time for each protocol "ICMP", "IGMP", "TCP", and "UDP" shown in FIG. The information "number of IPFIX records", "transmission packet size", "reception packet size", "transmission packet number", "reception packet number", and "session duration time" are converted into feature data. As shown in FIG. 8, the feature generation unit 12 generates variations of each information such as "total value," "minimum value," "maximum value," "average value," and "median value" into feature data. include. As shown in FIG. 11, each protocol "ICMP", "IGMP", "TCP", and "UDP" is given a feature number (feature number). The protocol is determined by the value of the "protocolIdentifier" field of the IPFIX data.

The above is the description of the feature amount of packet communication according to this embodiment.

The explanation returns to FIG. 1.
The model learning unit 13 uses the feature data generated by the feature generation unit 12 as learning data to perform machine learning on a machine learning model such as a neural network, thereby generating a device type identification model. . The device type identification model is a model for identifying the device type from the feature amount data of the device to be identified (device to be identified) dev. When the device type identification model receives the feature amount data of the device dev to be identified, it outputs the device type identification result and the confidence level of the identification result.

Note that the model learning unit 13 may generate device type identification models separately for steady communication and operation communication. The model learning unit 13 may generate a device type identification model for steady communication by performing machine learning on a machine learning model such as a neural network using the feature data of steady communication as learning data. good. In addition, the model learning unit 13 uses the feature data of the communication during operation as learning data to perform machine learning on a machine learning model such as a neural network, thereby developing a device type identification model for communication during operation. may be generated.

The device identification unit 14 uses the device type identification model generated by the model learning unit 13 to identify the device type from the feature data of the device dev to be identified. The device identification unit 14 obtains the device type identification result outputted from the device type identification model as a result of inputting the feature amount data of the identification target device dev into the device type identification model and the certainty factor of the identification result.

The device identification unit 14 determines the device type of the device dev to be identified based on the device type identification result and the certainty of the identification result. The device identification unit 14 determines that the device type identification result is the device type of the identification target device dev when the confidence level of the device type identification result is equal to or higher than a predetermined value.

On the other hand, when the confidence level of the device type identification result is less than a predetermined value, the device identification unit 14 does not adopt the device type identification result and determines that the device type of the identification target device dev is unknown. . In this case, the device identification unit 14 determines that the device type of the identification target device dev is a new device type that has not yet been reflected in the current device type identification model, and performs model learning to relearn the device type identification model. You may also instruct the section 13. In order to re-learn the device type identification model, the device identification unit 14 may notify the model learning unit 13 of information (eg, MAC address, etc.) of the device dev to be identified.

Note that when the model learning unit 13 generates device type identification models for regular communication and communication during operation, the device identification unit 14 separates the device type identification model for regular communication and the device type identification model for communication during operation. The device type is identified from the feature amount data of steady communication and the feature amount data of communication during operation of the device dev to be identified. The device identification unit 14 inputs the feature amount data of the steady communication of the device dev to be identified into the device type identification model of the steady communication, and the identification result and the device type in the steady communication output from the device type identification model. and obtain confidence in the results. Further, the device identification unit 14 inputs the feature amount data of the operation communication of the device dev to be identified into the device type identification model of the operation communication, and the device type in the operation communication output from the device type identification model. An identification result and a confidence level of the identification result are obtained. The device identification unit 14 identifies the device of the device dev to be identified based on the identification result of the device type in regular communication and the certainty of the identification result, and the identification result of the device type and the certainty of the identification result in operation communication. Determine the species. In this determination, the device type of the device dev to be identified is determined based on the device type identification result for which the degree of certainty is greater than or equal to a predetermined value. For example, the device type identification result for which the reliability is equal to or higher than a predetermined value and is the highest is determined to be the device type of the identification target device dev.

Next, the operation of the device identification apparatus 10 according to this embodiment will be explained with reference to FIG. 12. FIG. 12 is a flowchart illustrating an example of the procedure of the device identification method according to this embodiment. Here, the initial device type identification model has been generated by the model learning unit 13 in advance.

(Step S1) The IPFIX data collection unit 11 collects IPFIX data of each device dev from each home 30. Hereinafter, in order to simplify the explanation, one device dev (identification target device dev) will be explained.

(Step S2) The feature amount generation unit 12 uses the IPFIX data of the identification target device dev to generate feature amount data indicating the feature amount of packet communication.

(Step S3) The device identification unit 14 uses the device type identification model generated by the model learning unit 13 to identify the device type from the feature data of the device dev to be identified. The device identification unit 14 performs identification based on the device type identification result output from the device type identification model as a result of inputting the feature data of the device dev to be identified into the device type identification model and the confidence level of the identification result. Determine the device type of the target device dev.

(Step S4) As a result of the determination in step S3, if the certainty of the device type identification result is equal to or higher than the predetermined value (step S4, YES), the device type identification result is the device type of the device dev to be identified. It is determined that After this, the process of FIG. 12 ends.

On the other hand, as a result of the determination in step S3, if the reliability of the device type identification result is less than the predetermined value (step S4, NO), it is determined that the device type of the device dev to be identified is unknown. After this, the process advances to step S5.

(Step S5) The model learning unit 13 re-learns the device type identification model. In this re-learning of the device type identification model, the model learning unit 13 aggregates information on the identified device dev whose reliability of the device type identification result is less than a predetermined value based on the MAC address, for example. The device type identification model may be retrained using feature amount data generated from the IPFIX data.

[Example 1]
FIG. 13 is an explanatory diagram showing Example 1 of the device identification apparatus 10 according to the present embodiment. In FIG. 13, each IPFIX record (IPFIX record group) of IPFIX data collected by the IPFIX data collection unit 11 is output to the feature amount generation unit 12 for each unit time.

The feature amount generation unit 12 generates feature amount data indicating the feature amount of packet communication from a group of IPFIX records for each unit time. FIG. 14 shows an example of feature data. As shown in FIG. 14, feature data is generated for each feature number (feature number). In FIG. 14, feature amount No. The feature amount data of St-xx is feature amount data for each service related to steady communication shown in FIG. Also, feature quantity No. The feature amount data of Op-xx is feature amount data for each service related to communication during operation shown in FIG. Also, feature quantity No. The feature amount data of Pr-xx is feature amount data for each protocol related to communication during operation shown in FIG.

The device identification unit 14 inputs the feature amount data generated by the feature amount generation unit 12 into the device type identification model (discriminator), and the device type identification result outputted from the device type identification model (discriminator) and the corresponding Obtain the confidence level of the identification result. The device identification unit 14 determines the device type of the device dev to be identified based on the device type identification result and the certainty of the identification result.

In addition, when the model learning unit 13 generates device type identification models for regular communication and communication during operation, as shown in FIG. Using the device type identification model (discriminator for operation communication) 142 and the device type identification model (discriminator for operation communication) 142, the feature amount data of the steady communication of the device dev to be identified (feature amount No. St- The device type is identified from the feature amount data (feature amount data of feature amount No. xx) and the feature amount data of communication during operation (feature amount data of feature amount No. Op-xx and feature amount data of feature amount No. Pr-xx).

The device identification unit 14 inputs the feature amount data of the regular communication of the device dev to be identified (the feature amount data of the feature amount No. St-xx in FIG. 14) to the classifier 141 of the regular communication. The identification result of the device type in the output regular communication and the reliability of the identification result are obtained. Further, the device identification unit 14 converts the feature amount data (feature amount data of feature amount No. Op-xx and feature amount data of feature amount No. Pr-xx) of the operation communication of the device dev to be identified into the operation communication. As a result of the input to the discriminator 142, the identification result of the device type in the operation communication output from the discriminator 142 and the reliability of the identification result are obtained. The device identification unit 14 identifies the device of the device dev to be identified based on the identification result of the device type in regular communication and the certainty of the identification result, and the identification result of the device type and the certainty of the identification result in operation communication. Determine the species.

[Example 2]
FIG. 16 is an explanatory diagram showing Example 2 of the device identification apparatus 10 according to the present embodiment. In the second embodiment shown in FIG. 16, the device identification unit 14 further identifies the device type based on the reliability of past identification results. Specifically, the device identification unit 14 inputs the confidence of the past device type identification results output from the classifier into the classifier in addition to the feature amount data of the same identification target device dev in the next unit time. do. In the feature amount data shown in FIG. 14, for the same identification target device dev, the confidence record of the past device type identification result (the record of the confidence feature number) is changed to the feature amount data of the next unit time. will be added. This embodiment is the same as the first embodiment described above, except that the reliability of past device type identification results is used to identify the device type in the next unit time.

According to the second embodiment, by recursively adding the reliability of the device type identification result to the feature amount, it is possible to perform device type identification that is robust to the time series of packet communications.

According to the embodiment described above, by using IPFIX data, it is possible to reduce the amount of data indicating the flow of packet communication used to identify the device type. In addition, by using IPFIX data, it is possible to accurately obtain the feature values of each packet communication, so based on the feature values, it is possible to improve the accuracy of identifying the device type of the device that performs each packet communication. can. As described above, according to the present embodiment, by generating the feature amount of packet communication using IPFIX data, the device type of a device such as an IoT device connected to a communication network can be efficiently and accurately identified. The effect is that it can be done.

Also, since the IPFIX data does not include the payload of the packet, the privacy of the user of the device dev can be protected.

Furthermore, since the IPFIX data is converted from the communication data of the device dev, this embodiment is applicable to a wide variety of many devices dev.

Further, according to the embodiment described above, by focusing on the characteristics of steady communication and communication during operation, steady communication is By generating feature data separately for communication during operation and communication during operation, it is possible to further improve the accuracy of identifying the device type.

Furthermore, by recursively adding the confidence level of the device type identification result to the feature quantity, it is possible to perform device type identification that is robust to the time series of packet communications.

Note that in the above-described embodiment, a home is taken as an example of a device communication base, but the present invention is not limited to this. The device communication base may be, for example, a company office, an event venue, or a store.

Although the embodiment of the present invention has been described above in detail with reference to the drawings, the specific configuration is not limited to this embodiment, and design changes and the like may be made without departing from the gist of the present invention.

Further, a computer program for realizing the functions of each device described above may be recorded on a computer-readable recording medium, and the program recorded on the recording medium may be read into a computer system and executed. Note that the "computer system" here may include hardware such as an OS and peripheral devices.
Furthermore, "computer-readable recording media" refers to flexible disks, magneto-optical disks, ROMs, writable non-volatile memories such as flash memory, portable media such as DVDs (Digital Versatile Discs), and media built into computer systems. A storage device such as a hard disk.

Furthermore, "computer-readable recording medium" refers to volatile memory (for example, DRAM (Dynamic It also includes those that retain programs for a certain period of time, such as Random Access Memory).
Further, the program may be transmitted from a computer system storing the program in a storage device or the like to another computer system via a transmission medium or by a transmission wave in a transmission medium. Here, the "transmission medium" that transmits the program refers to a medium that has a function of transmitting information, such as a network (communication network) such as the Internet or a communication line (communication line) such as a telephone line.
Moreover, the above-mentioned program may be for realizing a part of the above-mentioned functions. Furthermore, it may be a so-called difference file (difference program) that can realize the above-described functions in combination with a program already recorded in the computer system.

DESCRIPTION OF SYMBOLS 1... Communication system, 10... Device identification device, 11... IPFIX data collection unit, 12... Feature value generation unit, 13... Model learning unit, 14... Device identification unit, 30... Home, 31... Gateway, 32... IPFIX conversion unit , dev...device, NW...communication network

Claims (5)

an IPFIX data collection unit that collects IPFIX (IP Flow Information Export) data generated from device communication data;
a feature amount generation unit that generates a feature amount of packet communication from the IPFIX data;
a device identification unit that identifies a device type from the feature amount of the device to be identified using a device type identification model generated by machine learning based on the feature amount;
Equipped with
The feature amount generation unit generates the feature amounts separately for a first communication that the device automatically performs and a second communication that the device performs in response to a user's operation,
The device type identification model is generated separately for first communication and second communication ,
The device identification unit uses a device type identification model for first communication and a device type identification model for second communication .
Device identification device. the device is an IoT device;
The device identification device according to claim 1 . The device type identification model outputs a device type identification result and a confidence level of the identification result,
The device identification unit further identifies the device type based on the reliability of past identification results.
The device identification device according to claim 1. an IPFIX data collection step of collecting IPFIX (IP Flow Information Export) data generated from device communication data;
a feature amount generation step of generating a feature amount of packet communication from the IPFIX data;
a device identification step of identifying a device type from the feature amount of the device to be identified using a device type identification model generated by machine learning based on the feature amount;
including;
The feature amount generating step generates the feature amounts separately for a first communication that the device automatically performs and a second communication that the device performs in response to a user's operation,
The device type identification model is generated separately for first communication and second communication,
The device identification step uses a device type identification model for the first communication and a device type identification model for the second communication.
Device identification method. to the computer,
an IPFIX data collection step of collecting IPFIX (IP Flow Information Export) data generated from device communication data;
a feature amount generation step of generating a feature amount of packet communication from the IPFIX data;
a device identification step of identifying a device type from the feature amount of the device to be identified using a device type identification model generated by machine learning based on the feature amount;
A computer program for executing
The feature amount generating step generates the feature amounts separately for a first communication that the device automatically performs and a second communication that the device performs in response to a user's operation,
The device type identification model is generated separately for first communication and second communication,
The device identification step uses a device type identification model for the first communication and a device type identification model for the second communication.
computer program.

Images