WO2022081166A1

WO2022081166A1 - Devices protected from a direct memory access attack

Info

Publication number: WO2022081166A1
Application number: PCT/US2020/055932
Authority: WO
Inventors: Kang-Ning Feng; Chia-Hung Kuo; Tsue-Yi HUANG
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2020-10-16
Filing date: 2020-10-16
Publication date: 2022-04-21

Abstract

An example device includes a plurality of communication devices, internally installed, which operate according to direct memory access (DMA), a memory and a processor. The processor determines respective device information and respective device characteristics of the plurality of communication devices, the respective device information comprising a respective identifier or respective path data associated with a respective communication device. The processor applies a respective hash function to the respective device characteristics of the plurality of communication devices to generate respective hashed device characteristics. The processor generates a plurality of records corresponding to the plurality of communication devices, a respective record comprising: the respective device information; and the respective hashed device characteristics. The processor stores, at the memory, the plurality of records for later use in detection of the plurality of communication devices by the processor.

Description

Devices Protected From A Direct Memory Access Attack

BACKGROUND

[0001] Internal communication devices, which use direct memory access, are common in devices such as laptops and notebook computers. However, such devices may be subject to direct memory access attacks, for example when spoofed communication devices, and the like, are installed.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Reference will now be made, by way of example only, to the accompanying drawings in which:

[0003] Figure 1 is a block diagram of an example device to generate records for later use in detection of communication devices to protect from a direct memory attack.

[0004] Figure 2 is a block diagram of an example device protected from a direct memory attack.

[0005] Figure 3 is a front view of the example device of Figure 2.

[0006] Figure 4 is an example of records generated for later use in detection of communication devices to protect from a direct memory attack.

[0007] Figure 5 is a flow diagram of an example method to protect a device from a direct memory attack.

[0008] Figure 6 is a flow diagram of an example method to change between a device binding mode and a device detection mode.

[0009] Figure 7 is a flow diagram of an example method to generate records in a device binding mode.

[0010] Figure 8 is a flow diagram of a first portion of an example method to compare records of previously installed communication devices with information from currently-present communication devices to protect from a direct memory attack.

[0011] Figure 9 is a flow diagram of a further portion of the example method of Figure 8. [0012] Figure 10 is a flow diagram of a last portion of the example method of Figure 8 and Figure 9.

[0013] Figure 11 depicts the example device of Figure 2 generating an exception record.

[0014] Figure 12 depicts the example device of Figure 3 providing a notification of an exception record.

DETAILED DESCRIPTION

[0015] Internal communication devices, which use direct memory access (DMA), are common in devices such as laptops and notebook computers. Such communication devices may include radios, transceivers, and the like for communicating via a wide area network (WAN), a local area network (LAN), a wireless LAN (WLAN), a Wireless wide area network (WWAN), and the like. However, devices with a DMA-capable communication device installed may be subject to DMA attacks, for example when spoofed DMA-capable communication devices, and the like, are installed. In particular, a DMA attack may be understood as a type of side channel attack from malicious DMA- capable communication devices, which initiate a DMA transaction targeting a memory region outside a DMA buffer of a device in which the malicious DMA- capable communication devices are installed, for example to retrieve sensitive information in a system memory (e.g., such as passwords and the like) and transmit the sensitive information to a computing and/or communication device of a malicious entity (e.g., via communication functionality of a malicious DMA- capable communication device).

[0016] DMA-capable communication devices from a reliable vendor and/or source are understood not to include applications, and the like, for initiating a DMA attack. A spoofed DMA-capable communication device, and/or a DMA- capable communication device from a malicious entity, and the like, may be understood to include a communication device that has functionality of a DMA- capable communication device from a from a reliable vendor, but which includes an application for initiating a DMA attack; for example, such a spoofed communication device may include a field-programmable gate array (FPGA) and/or a complex programmable logic device (CPLD) which attempts to at least partially simulate a WAN/LAN/WLAN/WWAN communication device, for example by providing basic communication functionality. However, such spoofed communication devices may have device identifiers and/or device characteristics and/or a capability structure that is different from device identifiers and/or device characteristics and/or a capability structure of communication devices being spoofed. In particular, the terms “ spoof”, “spoofing”, “spoofed” and the like, may be understood to refer to disguising a communication device from an unknown and/or malicious source as being from a known and/or trusted source and/or vendor. Hence a spoofed communication device from a malicious source imitates a communication device from a known and/or trusted source and/or vendor.

[0017] A DMA-capable communication device from a malicious entity may be installed at a laptop, or another type of computing device, by a bad actor gaining access to the laptop and/or such a DMA-capable communication device may be unknowingly installed by a user of the laptop. In particular, a bad actor (and/or a user) may swap out a first DMA-capable communication device, from a reliable vendor and/or source, for a second DMA-capable communication device which spoofs the first DMA-capable device, but which initiates a DMA attack on the laptop, for example via an installed application, and the like. Alternatively, the bad actor and/or a user may install a new DMA-capable communication device which initiates a DMA attack on the laptop.

[0018] As such, provided herein, are devices, methods, and systems to protect devices from DMA attacks. In particular, in a device binding mode, for example initiated by an administrator and/or information technology (IT) personnel interacting with a device, records of installed DMA-capable communication devices are generated and stored at the device; the administrator may verify that the installed DMA-capable communication devices are from reliable vendors and/or sources, and/or are not spoofed, and operate the device to generate records corresponding to installed DMA-capable communication devices, a respective record comprising: respective device information (e.g., which may include a device and/or vendor identifier and/or path data and/or any other data which uniquely identifies the DMA-capable device within the device, and which maybe encrypted), and respective hashed device characteristics (e.g., which may include a portion of device characteristics store in respective read-only memories of the installed DMA-capable communication devices). A hash function for hashing the device characteristics may be randomly selected (e.g., from a plurality of hash functions stored at the device) and an identifier of the hash function used for hashing the device characteristics may also be stored in a respective record (e.g., and which may also be encrypted). In particular, such records may be for internally installed DMA-capable communication devices. After the records are generated, the device may be provided to a user for normal usage.

[0019] Upon startup, and/or periodically, the device may enter a device detection mode, query the currently-present internally-installed DMA-capable communication devices, and compare device information and hashed device characteristics of the currently-present internally-installed communication devices with the records. As will be described in more detail below, when anomalies are found, a notification device may be controlled to provide a notification thereof. Such anomalies may be indicative of a new and/or spoofed DMA-capable communication device being installed after the records were generated, for example unknown to the user of the device, and such a notification thereof may indicate to the user that the device is to be returned to the administrator and/or an IT department for inspection.

[0020] An aspect of the present specification provides a device comprising: a plurality of communication devices, internally installed, which operate according to direct memory access (DMA); a memory; and a processor connected to the plurality of communication devices and the memory, the processor to: determine respective device information and respective device characteristics of the plurality of communication devices, the respective device information comprising a respective identifier or respective path data associated with a respective communication device; apply a respective hash function to the respective device characteristics of the plurality of communication devices to generate respective hashed device characteristics; generate a plurality of records corresponding to the plurality of communication devices, a respective record comprising: the respective device information; and the respective hashed device characteristics; and store, at the memory, the plurality of records for later use in detection of the plurality of communication devices by the processor.

[0021] Another aspect of the present specification provides a method comprising: determining, at a processor of a device, device information and device characteristics of a communication device installed internal to the device; generating, at the processor, from the device characteristics and using a hash function, hashed device characteristics; comparing, at the processor, the device information or the hashed device characteristics with records of previously installed communication devices; generating, at the processor, an exception record in response to determining, at the processor, that: the device information does not correspond to respective device information of the records; the hashed device characteristics does not match respective hashed device characteristics of the records; or a given record does not include respective information corresponding to the device information; and controlling, via the processor, a notification device to provide a notification of the exception record.

[0022] Another aspect of the present specification provides a non-transitory computer-readable medium comprising instructions that, when executed by a processor of a device, causes the processor to: compare device information and hashed device characteristics of currently-present internally-installed communication devices, which operate according to direct memory access (DMA), with records of communication devices which were previously installed at the device; in response to determining that the device information of a currently- present internally-installed communication device is not found in the records, generate a first exception record; in response to determining that the device information of the currently-present internally-installed communication device is found in the records, but the hashed device characteristics thereof is not found in the records, generate a second exception record; and in response to determining that a given record does not include respective information corresponding to the device information of the currently-present internally-installed communication devices, generate a third exception record.

[0023] Referring to Figure 1 , a computing device 100 to generate records for later use in detection of communication devices to protect from a direct memory attack is provided.

[0024] The computing device 100 comprises: a plurality of communication devices 102-1 , 102-2. ,.102-N, internally installed, which operate according to direct memory access (DMA). The plurality of communication devices 102-1 , 102-2...102-N will be interchangeably referred to hereafter, collectively, as the communication devices 102 and, generically, as a communication device 102. This convention will be used elsewhere in the present specification.

[0025] The computing device 100 further comprises a memory 104 storing instructions 106; and a processor 108 connected to the plurality of communication devices 102 and the memory 104. The processor 108 is generally to execute the instructions 106 stored in the memory 104. The processor 108 is generally to (e.g., upon execution of the instructions 106 to further cause the processor 108 to): determine respective device information and respective device characteristics of the plurality of communication devices 102, the respective device information comprising a respective identifier or respective path data associated with a respective communication device 102; apply a respective hash function to the respective device characteristics of the plurality of communication devices 102 to generate respective hashed device characteristics; generate a plurality of records corresponding to the plurality of communication devices 102, a respective record comprising: the respective device information; and the respective hashed device characteristics; and store, at the memory 104, the plurality of records for later use in detection of the plurality of communication devices 102 by the processor 108.

[0026] For example, the computing device 100, interchangeably referred to hereafter as the device 100, may comprise a laptop computer and/or a notebook computer and/or a mobile computing device and/or a personal computer and the like. Such a list is understood not to be exhaustive, however and any suitable device into which communication devices, which operate according to DMA, may be internally installed is within the scope of the present specification.

[0027]The communication devices 102 may comprise any suitable communication devices which operate according to DMA and which may be internally installed at the device 100.

[0028]The communication devices 102 may comprise communication devices such as WiFi™ devices, Bluetooth™ devices, and the like, which, for example, may comprise respective communication interfaces and/or transceivers and/or radios, and the like, to communicate with any suitable combination of communication networks (e.g., the Internet, WANs, LANs, WLANs, WWANs, and the like).

[0029] Furthermore, as the communication devices 102 operate according to DMA and/or a DMA protocol, and the like, the communication devices 102 are generally understood to access a DMA buffer and/or a DMA memory, and the like (e.g., which may include, but is not limited to, a portion of the memory 104 dedicated to DMA) independent of the processor 108 and/or while the processor 108 performs other operations that may be unrelated to the communication devices 102.

[0030] As has already been mentioned, the communication devices 102 are generally understood to be internal to the device 100. For example, the communication devices 102 may be provided as cards which are inserted into internal slots and/or internal ports of the device 100 (e.g., as described in more detail below with respect to Figure 2). In a particular example, the communication devices 102 may comprise PCIe (peripheral component interconnect express) and/or PCI enabled devices, and may be provided as cards which are inserted into internal PCI and/or PCIe slots of the device 100; hence, an internal slot may include, but is not limited to, a PCI slot and/or a PCIe slot. In another particular example, an internal port may include, but it not limited to, a SATA (Serial Advanced Technology Attachment) port, and the like.

[0031] Furthermore, while an integer number of “N” communication devices 102 are depicted, the device 100 may include as few as one communication device 102 and/or any suitable number of communication devices 102. In a particular example, the device 100 may include a given number of internal slots and/or internal ports and/or internal PCI and/or PCIe slots, and the number of “N” communication devices 102 may be as few as one communication device 102 (e.g., N=1) and/or the number of “N” communication devices 102 may be as many as the number of internal slots and/or internal ports and/or internal PCIe slots (e.g., N=number of slots).

[0032] Hereafter, reference will be made to slots and/or internal slots, however such slots and/or internal slots are understood to include any suitable internal slot and/or internal port and/or internal PCI slots and/or internal PCIe slots and/or internal SATA ports, and the like.

[0033] While not depicted, the communication devices 102 are understood to include respective memories and/or registers which may store any suitable identifier and/or identifiers which may uniquely identify the communication devices 102 to the processor 108 within the device 100. Such an identifier may include, but is not limited to, a 16-bit Device Identifier (DID), a physical address and/or a Media Access Control (MAC) address, a serial number, and the like of a respective communication device 102. Alternatively, and/or in addition, such an identifier may include, but is not limited to, a vendor identifier and the like; such a vendor identifier may include, but is not limited to, a 16-bit Vendor Identifier (VID), a textual name and/or associated alphanumeric identifier, and the like, of a vendor and/or manufacturer, and the like, of a respective communication device 102. Such an identifier and/or identifiers may be stored in any suitable memory and/or register of a communication device 102.

[0034] It is further understood that the communication devices 102 are communicatively coupled to the processor 108 and that respective path data associated with a respective communication device 102 may be determined, for example by the processor 108. For example, such path data may include, but is not limited to, a hierarchy of identifiers and/or internal device addresses, and/or concatenated identifiers and/or internal device addresses, and the like, indicating a path of internal components of the device 100 that are between the processor 108 and/or a root device and a respective communication device 102 and/or a slot thereof. For example, such a root device may include, but is not limited to, a host bridge of the slots.

[0035] For examples, with reference to PCIe slots, a host bridge for the PCIe slots, a PCIe slot, and communication device 102 may be associated with respective DI Ds and/or VI Ds and/or any suitable identifier, and/or internal addresses, and the path data associated with a communication device 102 may include a combination of such identifiers and/or internal addresses which represent a path from the host bridge to the communication device 102. In a particular example, path data for a given communication device 102 may include text indicating “VID:103C/DID:8076/B0 D1 F0”, where “VID:103C” is a VID of a host bridge, “DID:8076” is a DID of a PCIe slot into which the communication device 102 is inserted, and “BO D1 F0” may include an internal address of the communication device 102 (e.g., used and/or assigned by the processor 108). Hence, such path data may include, but is not limited to, any suitable indication of a respective slot at which a respective communication device 102 is installed and/or any suitable indication of a location, within the device 100, at which the respective communication device 102 is internally installed. The path data for a given communication device 102 may be understood to be unique within the device 100 and may also be used as device information.

[0036] Hence, a respective identifier of respective device information for a respective communication device 102 may include, but is not limited to: respective device identifier or a respective vendor identifier. Similarly, respective path data of respective device information for a communication device 102 may include, but is not limited to: an indication of a respective slot at which the respective communication device 102 is installed.

[0037] Furthermore, the communication devices 102 are understood to include respective read-only memories (ROMs) which may store device characteristics in any suitable data structure. For example, such device characteristics may be according to a PCIe specification, such that communication devices 102 from reliable vendors and/or sources may store such device characteristics according to a well-defined data structure that may be difficult for a malicious entity to copy and/or use in a spoofed communication device.

[0038] Such device characteristics may specifically include device capability data and/or a subset thereof, stored in a ROM, for example as defined by a PCO and/or PCIe specification. Furthermore such device capability data is generally stored in a specific data structure. Such device capability data may include, but is not limited to data from PCI registers and/or PCI configuration space and/or PCIe extended configuration space. In particular, the device characteristics of a communication devices 102, as described herein, may include, for example, specific register data from the PCI registers and/or PCI configuration space and/or PCIe extended configuration space for a communication device 102, and/or a first given number of bytes of data from the PCI registers and/or PCI configuration space and/or PCIe extended configuration space, and/or given portions of bytes of data from the PCI registers and/or PCI configuration space and/or PCIe extended configuration space, and/or data from given memory locations and/or given registers and/or given blocks of the PCI registers and/or PCI configuration space and/or PCIe extended configuration space.

[0039] While the above referenced DI Ds and VI Ds may also be stored in PCI registers (e.g., in a ROM of a communication device 102), and hence the device identifiers which uniquely identify a communication device 102 to the processor 108 may be a portion of the device characteristics as described herein, the device characteristics are generally selected to be a larger portion of data stored in a ROM of a communication device 102 than the device identifiers.

[0040] In particular, in some examples, the device characteristics described herein may include all the data stored in a ROM of a communication device 102 and/or all the device capability data and/or an entire capability structure stored in a ROM of a communication device 102.

[0041] However, in some examples, vendors of devices, such as laptops, and the like, implementing methods described herein to protect such devices from DMA attacks, may define a proprietary portion of a capability structure of communication devices 102 to be used (e.g., hashed), as described below. In some specific examples, such a proprietary portion may be defined in agreement with reliable vendors of communication devices 102. Regardless, such a proprietary portion of a capability structure of communication devices 102 may be hence be difficult for a malicious entity to determine.

[0042] Regardless, while an identifier of a communication device 102 may be easy to spoof, specific capability data and, in particular, a specific data structure of the capability data (e.g., a capability structure) is difficult to spoof as such specific capability data and a corresponding capability structure, may be hardware dependent and may define functionality and/or function blocks (e.g., and/or inputs and/outputs of function blocks) to be implemented by the communication device 102.

[0043] Furthermore, the capability structure may be provided, and/or lined, in a specific order such that any slight offset will result in a change in a hash thereof. As such, a malicious entity, attempting to spoof the capability data in a spoofed communication device must also precisely spoof the capability structure and, as such capability data may be in a size of thousands of bytes, such spoofing is extremely difficult. Hence a hash of capability data from a communication device 102 from a reliable vendor may provide a good indication of the veracity of the communication device 102 when the same capability data from the communication device 102 is later retrieved therefrom and compared to an existing hash (e.g., as stored in records described herein).

[0044] Furthermore, for a spoofed communication device, implementing a capability structure (e.g., and related function blocks) may hugely consume resources in an FPGA/CPLD thereof attempting to otherwise mimic a communication device 102 from a reliable vendor. Hence, an attempt to mimic a capability structure may cause the spoofed communication device to exhaust (and/or almost exhaust) resources of an FPGA/CPLD thereof, which further deters the malicious entity from fully attempting to fully mimic a capability structure of a communication device 102 from a reliable vendor. Put another way, spoofed communication devices may have fewer processing resources available than a communication device 102 from a reliable vendor which may deter a malicious entity from fully enabling a spoofed communication device to mimic a capability structure of a communication device 102 from a reliable vendor.

[0045] Hence, respective device characteristics of a respective communication device 102 may include, but is not limited to, device capability data and/or a device capability structure and/or a portion thereof, stored in a respective readonly memory (ROM) of the respective communication device 102

[0046] The memory 104 is coupled to the processor 108 and includes a non- transitory machine-readable storage medium that may be any electronic, magnetic, optical, or other physical storage device. The non-transitory machine- readable storage medium of the memory 104 may include, for example, random access memory (RAM), electrically-erasable programmable read-only memory (EEPROM), flash memory, a storage drive, an optical disc, and the like. The memory 104 may also be encoded with executable instructions to operate the communication devices 102 and/or and other hardware in communication with the processor 108.

[0047] The memory 104 may also store an operating system that is executable by the processor 108 to provide general functionality to the device 100, for example, functionality to support various applications such as a user interface to access various features of the device 100. Examples of operating systems include a Real-Time Operating System (RTOS). Windows™, macOS™, iOS™, Android™, Linux™, and Unix™. The memory 104 may additionally store applications that are executable by the processor 108 to provide specific functionality to the device 100, such as those described in greater detail below and which may include the instructions 106.

[0048]The processor 108 may include a central processing unit (CPU), a microcontroller, a microprocessor, a processing core, a field-programmable gate array (FPGA), or similar. The processor 108 and memory 104 may cooperate to execute various instructions such as the instructions 106.

[0049] In some examples, the functionality of the device 100 may be provided in the form of engines. As used herein, the term “engine” refers to hardware (e.g., a processor, such the processor 108 and/or, a central processing unit (CPU) an integrated circuit or other circuitry) or a combination of hardware and software (e.g., programming such as machine- or processor-executable instructions, commands, or code such as firmware, a device driver, programming, object code, etc. as stored on hardware). Hardware includes a hardware element with no software elements such as an application specific integrated circuit (ASIC), a Field Programmable Gate Array (FPGA), etc. A combination of hardware and software includes software hosted at hardware (e.g., a software module that is stored at a processor-readable memory such as the memory 104, a random access memory (RAM), a hard-disk or solid-state drive, resistive memory, or optical media such as a digital versatile disc (DVD), and/or implemented or interpreted by a processor), or hardware and software hosted at hardware.

[0050] Hence, for example, the functionality of the device 100 may be provided in the form of such engines, including, but not limited to: a device data engine to determine respective device information and respective device characteristics of the plurality of communication devices 102, the respective device information comprising a respective identifier or respective path data associated with a respective communication device102; a hash engine to: apply a respective hash function to the respective device characteristics of the plurality of communication devices 102t o generate respective hashed device characteristics; a record generation engine to: generate a plurality of records corresponding to the plurality of communication devices, a respective record comprising: the respective device information; and the respective hashed device characteristics; and a record storage engine to: store, at a memory (such as the memory 104), the plurality of records for later use in detection of the plurality of communication devices 102 by the processor 108.

[0051] In particular, storage of the records at the memory 104 is understood to generate, at the memory 104, a data structure which may be used to later check for spoofed communication devices 102, missing communication devices 102, new communication devices 102 and the like, as described in more detail below. Indeed, each record is understood to include a respective data structure. Regardless, storage of the records at the memory 104 is understood to change a physical structure of at least the memory 104 to provide a data structure used to protect the device 100 against DMA attacks. An example structure of individual records generated at the device 100 is described below with respect to Figure 4.

[0052] While not depicted, in conjunction with storage of the records at the memory 104, the instructions 106 may further cause the processor 108 to provide a notification thereof at a display screen, and/or any other suitable notification device. Such a notification may be provided on record-by-record basis and/or after generation of the records for the communication devices 102 are completed.

[0053] The records may be generated via an administrator and/or IT personnel, and the like, interacting with the device 100 to install and/or add and/or remove communication devices 102 and/or further interacting with the device 100 to place the device 100 into a device binding mode. In particular, in such a device binding mode, records comprising respective device information and respective hashed device characteristics for installed communication devices 102 are generated and stored, for example, in a database at the memory 104. Such records may be later used by the device 100 in a device detection mode to compare with device information and hashed device characteristics for currently present communication devices 102 to check for spoofed communication devices 102, missing communication devices 102, new communication devices 102 and the like, as described in more detail below. Hence, such a mode is referred to as a device “binding” mode as generation and storage of the records generally “binds” a communication device 102 associated with a record to the device 100 and/or provides a record of a verified communication device 102. [0054] In some examples, the processor 108 may be further to (and/or the instructions 106 may be further to cause the processor 108 to): encrypt respective device information prior to including in respective record. As such, the memory 104 may further store a cryptographic algorithm and/or algorithms (e.g., in the instructions 106 and/or separate from the instructions 106) for encrypting, and later decrypting such device information.

[0055] As has been previously described, device characteristics of a communication device 102 are hashed prior to inclusion in a respective record. Hence, in some examples, the memory 104 may store one hash function (e.g., in the instructions 106 and/or separate from the instructions 106).

[0056] However, in other examples, the memory 104 may store a plurality of hash functions. Hence, in some examples, the processor 108 may be further to (and/or the instructions 106 may be further to cause the processor 108 to): randomly select a hash function from a plurality of hash functions, such that different respective hash functions are used to generate different respective hashed device characteristics for the plurality of communication devices 102. However, a hash function may be selected according to any suitable scheme which may be random or not random. [0057] In such examples, a respective record further comprises an indication of a respective hash function used to generate respective hashed device characteristics, for example stored as an identifier of the selected hash function, which may also be encrypted.

[0058] As will be next described, once the records are generated, the device 100 may be operated in a device detection mode to compare device information and hashed device characteristics of generated records with device information and hashed device characteristics for currently present communication devices 102 to check for spoofed communication devices 102, missing and/or removed communication devices 102, new communication devices 102 and the like. When such anomalies are determined an exception record may be stored at the device 100, and such an exception record may comprise data indicative of such an anomaly. Further a notification of exception records may be provided.

[0059] Hence, attention is next directed to Figure 2, which depicts a computing device 200, which is substantially similar to the device 100, with like components having like numbers, but in a “200” series” rather than a “100” series. The device 200 may represent the device 100 after records are generated, as described above, and after some time has passed.

[0060] In particular, the device 200 comprises: an “M” number of a plurality of communication devices 202-1 , 202-2, 202-M (e.g., communication devices 202 and/or a communication device 202), internally installed, which operate according to DMA; a memory 204 storing instructions 206; and a processor 208 connected to the plurality of communication devices 202 and the memory 204. The processor 208 may be to (e.g., upon execution of the instructions 206) to implement functionality as described herein which may include, but is not limited to, the previously described record generation in a device binding mode, as well as a device detection mode, as described below.

[0061] As such, as depicted, the memory 204 stores an “N” number of a plurality of communication device records 210-1 , 210-2...210-N (e.g., records 210 and/or a record 210) in a communication device record database 212. However, in other examples the records 210 may not be stored in a database. In particular, the database 212 includes one record 210 for each of a previously installed “N” number of communication devices 202.

[0062] However, as depicted, there are an integer number “M” of communication devices 202 and the number “M” may be the same as the number “N” or different from the number “N” (e.g., less than “N” or greater than “M”). Put another way, the number of communication devices 202 may have increased, decreased, or stayed the same since the records 210 were generated. Even if the number of communication devices 202 may have stayed the same since the records 210 were generated, a previously installed communication device 202 may have been swapped out for a spoofed communication device 202, for example by a malicious entity and/or by a user of the device 200 (e.g., without knowing that a new communication device 202 is a spoofed communication device 202, such as one ordered from a suspicious vendor via a website, and the lie). Similarly, a new communication device 202 may be a spoofed communication device, or a communication device 202 from a reliable vendor, that has not yet had a corresponding record 210 generated (e.g., as installed by a user of the device 200 and/or a malicious entity without approval by an administrator, an IT department and the like). Similarly, a removed communication device 202 may have been removed without approval by an administrator, an IT department and the like.

[0063] As depicted, the memory 204 further stores a cryptographic algorithm 214 (which may include one, or more than one, cryptographic algorithm) such as a symmetric and/or asymmetric cryptographic algorithm (e.g., including, but not limited to, a Data Encryption Standard (DES) algorithm, an RSA (Rivest- Shamir-Adleman) algorithm and the like, as well as any suitable cryptographic keys). In a particular example, when the device 200 is operated in a device binding mode to generate the records 210, a private key may be used to encrypt data of the records 210 which may not be stored at the device 200; however a corresponding public key may be stored with the cryptographic algorithm 214 to decrypt encrypted data from the records 210.

[0064] As depicted, the memory 204 further stores a plurality of hash functions 216-1 , 216-2. ,.216-P (e.g., hash functions 216 and/or a hash function 216), where “P” is any suitable integer number. Indeed, any suitable number of hash functions 216 may be stored and correspond to hash functions used to generate hashes of device characteristics store in the records 210. Such hash functions 216 may include, but are not limited to, universal hash function, non- cryptographic hash functions, keyed cryptographic hash functions, unkeyed cryptographic hash functions and the like. A specific example of such hash functions 216 may be secure hash algorithm (SHA) functions and the like. [0065] As previously mentioned, and as will be described below, exception records may be generated when the records 210 are compared to device information and hashed device characteristics of the communication devices 202. Hence, as depicted, the memory 204 further includes an exception record database 218 which, as depicted, is initially empty. In some examples, the memory 204 may not store the exception record database 218 until a first exception record is generated (e.g., the processor 208 may generate the exception record database 218 when a first exception record is generated). However, in other examples such exception records may not be stored in a database.

[0066] Attention is next directed to the communication devices 202 which store respective identifiers 220-1 , 220-2...220-M (e.g., identifiers 220 and/or an identifier 220), for example in RAM or a register, and further comprise respective ROMs 222-1 , 222-2. ,.222-M (e.g., ROMS 222 and/or a ROM 222) which store respective device characteristics 224-1 , 224-2. ,224-M (e.g., characteristics 224 and/or a set of characteristics 224). In some examples a identifiers 220 for a communication device 202 may also be stored in respective ROM 222.

[0067] As mentioned previously, an identifier 220 may comprise a DID and/or a VID, and the like. Device characteristics 224 may comprise any suitable combination of device capabilities information, a serial number, a unique identifier, physical address and the like. In a particular example, the device characteristics 224 may include PCI and/or PCIe device capabilities stored in a ROM 222. In some examples, the device characteristics 224 may include the identifiers 220. However, in general, it is understood that, when generating a record 210 for a communication device 202, the processor 208 retrieves respective device characteristics 224, and/or a predefined subset thereof, from a respective ROM 222, randomly selects a hash function 216 and hashes the retrieved device characteristics 224; then a record 210 is generated that includes: hashed device characteristics; device information such as respective identifiers 220 of the communication device 202 and/or path data e.g., as encrypted using the cryptographic algorithm 214); and an identifier of the hash function 216 used to produce the hashed device characteristics (e.g., as encrypted using the cryptographic algorithm 214).

[0068] However, a hash function 216 may be selected according to any suitable scheme which may be random or not random.

[0069] An identifier of a hash function 216 may include, for example, any suitable numeric and/or alphanumeric identifier of the hash function 216, such as an associated file name and/or an indexed number of the hash function 216. For example, identifiers of hash functions 216 may be stored in an index (not depicted) at the memory 204 that associates the identifiers with respective hash functions 216; a scheme as simple as integer number identifiers “1”, “2”...”P” stored in association with the respective hash function 216 may be used. For example “1” may identify the hash function 216-1 , “2” may identify the hash function 216-2, etc.

[0070] As mentioned previously, device information stored in the records 210 may include path data. For example, as depicted, the communication devices 202 are installed, internally, at respective internal slots 226-1 , 226-2. ,.226-M (e.g., slots 226 and/or a slot 226); as depicted, there is one communication device 202 installed at each slot 226, however, there may be fewer communication devices 202 installed than the number “M of the slots 226 and/or there may be more slots 226 than the number “M of depicted slots 226. The path data for a given communication deice 202 may hence depend on a respective identifier and/or address of a slot 226 at which the given communication deice 202 is installed.

[0071] As depicted, the device 200 further includes an external slot 228 (e.g., a USB (Universal Serial Bus) slot and/or port) at which an external communication device 230 (e.g., a USB device and/or fob, and the like) is inserted. As will be explained below, in the device detection mode, the device 200 ignores external communication devices.

[0072] As further depicted, the device 200 further includes a temporary memory provided in the form of a buffer 232, which may comprise volatile access memory of the memory 204 and/or the processor 208, and the like. Hence, while, for clarity, the buffer 232 is depicted as being separate from the memory 204 and/or the processor 208, it is understood that the buffer 232 may be a component of the memory 204 and/or the processor 208. Furthermore, the buffer 232 may include any suitable temporary memory and/or a volatile memory.

[0073] As further depicted, the device 200 further includes a notification device 234 and/or notification devices, such as a display screen, a speaker, and the like, as well as an input device 236 and/or input devices, such as a keyboard, a trackpad, and the like.

[0074] For example, attention is next directed to Figure 3 which depicts a front view of an example of the device 200 in a laptop format. It is understood that, as depicted, the external communication device 230 is inserted into the external slot 228 (not visible in Figure 3. It is understood that, as depicted, the notification device 234 is provided as a display screen, and the input device 236 is provided as a keyboard. However, Figure 3 merely shows one possible example of the device 200. In particular, the communication devices 202 are not visible in Figure 3 as the communication devices 202 are internal to the device 200. Put another way, present examples are directed to internal communication devices 202 as external communication devices 230 are subject to rapid changing in and out external slots 228 and hence changes there to may be easily visually detected by a user, whereas changes to internal communication devices 202 are harder for a user to visually detect.

[0075] Attention is next directed to Figure 4 which depicts an example of generation of the records 210. While not depicted, it understood that the processor 208 may perform the functionality described with respect to Figure 4. However, the processor 108 may alternatively perform the functionality described with respect to Figure 4

[0076] For example, depicted in Figure 4 is data 402 in an intermediate format that is used to generate a corresponding record 210. For example, the data 402 may be for a given communication device 202, and may be determined and/or retrieved by the processor 208 and temporarily stored in the buffer 232. As depicted, the data 402 comprises device information 416 associated with the given communication device 202, including, but not limited to, an associated identifier 220 (e.g., a DID and/or VID) retrieved from the given communication device 202, and/or path data (e.g., “PATH”) associated with given communication device 202 (e.g., which may be determined by the processor 208 based on a slot 226 at which the given communication device 202 is installed).

[0077] As depicted, the data 402 further comprises a hash function identifier 418 identifying a hash function 216 as randomly selected (e.g., and/or selected according to any suitable scheme) by the processor 208. For example, as depicted, the hash function identifier 418 comprises “1” which may be understood to identify the hash function 216-1.

[0078] As depicted, the data 402 further device characteristics 224 of the given communication device 202 as retrieved from a respective ROM 222. For example, as depicted, the device characteristics 224 comprises a “CAPABILITY STRUCTURE” of the given communication device 202 (and/or a portion thereof) as retrieved from a respective ROM 222 by the processor 208.

[0079] As depicted, the processor 208 may apply the cryptographic algorithm 214 and the selected hash function 216-1 to the data 402 (e.g., as represented by an arrow between the data 402 and the record 210). In particular, the processor 208 may apply the selected hash function 216-1 to produce hashed device characteristics 424. Similarly, the processor 208 may apply the cryptographic algorithm 214 to, respectively, the device information 416 and the hash function identifier 418 to, respectively generate encrypted device information 426 and an encrypted hash function identifier 428. The hashed device characteristics 424, the encrypted device information 426 and the encrypted hash function identifier 428 are stored in the depicted record 210 in any suitable order and/or format.

[0080] It is further understood that the records 210 of Figure 2 are generated in a similar manner as shown in Figure 4. For example, the processor 208 may generate one record 210 per communication device 202 that is installed at the device 200 when the device 200 is in the device binding mode.

[0081] Referring to Figure 5, a flowchart of an example method 500 to protect a device from a direct memory attack is depicted. In order to assist in the explanation of method 500, it will be assumed that the method 500 may be performed at least partially by the device 200, and/or the processor 208 thereof, implementing the method 500 for example by executing the instructions 206. Indeed, the method 500 may be one way in which the device 200 may be configured. Furthermore, the following discussion of method 500 may lead to a further understanding of the device 200, and its various components.

Furthermore, it is to be emphasized, that method 500 may not be performed in the exact sequence as shown, and various blocks may be performed in parallel rather than in sequence, or in a different sequence altogether.

[0082] It is further understood that, in the method 500, the records 210 are understood to have been previously generated and stored at the memory 204 and that the records 210 were generate from internal communication devices 102 which were previously installed at the device 200. However, currently- present internally-installed communication devices 202 may be different from the communication devices 202 which were previously installed at the device 200 and that were used to generate the records 210. Furthermore, the method 500 may represent a device detection mode in which the device 200 attempts to determine anomalies in current installed communication devices 202.

[0083] At a block 501 , the device 200 and/or the processor 208 determines device information and device characteristics of a communication device 202 installed internal to the device 200. For example, the processor 208 may query the communication devices 102 currently present at the device 200 to retrieve respective identifiers and device capability data therefrom, as described above. However, the processor 208 may further determine device information by determining path data of the communication devices 202. In some examples the path data may have been previously determined and stored (e.g., at the memory 204) and hence determining the path data may include, but is not limited, to retrieving such previously determined path data. However, the path data may alternatively be determined for the communication devices 102 (e.g., when the block 501 is implemented).

[0084] In some examples, in implementing the block 501 , the device 200 and/or the processor 208, as part of a general query process, may also determine device information and device characteristics of the external communication device 230, when present, but, as will be described below, such device information and device characteristics are generally ignored.

[0085] At a block 503, the device 200 and/or the processor 208 generates, from the device characteristics and using a hash function 216, hashed device characteristics.

[0086] At a block 505, the device 200 and/or the processor 208 compares the device information and/or the hashed device characteristics with the records 210 of previously installed communication devices 202.

[0087] At a block 507, the device 200 and/or the processor 208 generates an exception record in response to determining that: the device information does not correspond to respective device information of the records 210; the hashed device characteristics does not match respective hashed device characteristics of the records 210; and/or a given record does not include respective information corresponding to the device information. Any exception records generated may be stored at the database 218 and/or in any other suitable format at the memory 204.

[0088] At a block 509, the device 200 and/or the processor 208 controls a notification device to provide a notification of the exception record.

[0089] Some particular details of the method 500 are next described.

[0090] For example, when one given hash function 216 has been used to generate the records 210, the hashed device characteristics may be generated using the one given hash function 216 and the block 503 may be implemented prior to the block 505.

[0091] In other examples, when the records 210 have been generated using selected hash functions 216 (e.g., randomly selected), the block 503 and/or the block 505 may be performed in conjunction with each other, for example by first decrypting the encrypted device information 426 and the encrypted hash function identifiers 428 of the records 210 and comparing device information of a given communication device 202 with the decrypted device information 416 of the records 210 to determine a match.

[0092] Hence, when the device information of a given communication device 202 matches the decrypted device information 416 of a given record 210, the decrypted hash function identifier 418 is used to identify a corresponding hash function 216, which is used (e.g., at the block 503) to hash the device characteristics of the given communication device 202. Such hashed device characteristics of the given communication device 202 are compared to hashed device characteristics 424 the record 210 that matched the device identifier of the given communication device 202. When no match occurs, an exception record is generated (e.g., and stored at the database 218).

[0093] In particular, such an exception record may indicate that a currently- present internally-installed communication device 202 that has device information that matches a given record 210 has a different device capability structure than a previously installed communication device 202 from which the given record 210 was generated (e.g., but same device information) indicating that the currently-present internally-installed communication device 202 may be a spoofed communication device.

[0094] Similarly, an exception record is generated (e.g., and stored at the database 218) when a device identifier of a given communication device 202 does not match any device information 416 of the records 210. Such an exception record may indicate that a currently-present internally-installed communication device 202 that has device information that does not match any of the records 210 is newly installed as compared to the previously installed communication devices 202 from which the records 210 were generated.

[0095] Put another way, the processor 208 and/or the device 200 may compare device information or the hashed device characteristics of a given communication device 202 with the records 210 of the previously installed communication devices by: comparing device information of a given communication device 202 with the records 210 to determine whether the device information of the given communication device 202 corresponds to respective device information of the records 210; and in response to determining that the device information of the given communication device 202 does correspond to given device information of a given record 210, comparing the hashed device characteristics of the given communication device 202 with the respective hashed device characteristics of the given record 210, and wherein, in response to determining that the device information of the given communication device 202 does not correspond to the respective device information of any of the records 210, generating a respective exception record (e.g., which may be stored at the database 218).

[0096] Furthermore, the method 500 may further comprise: comparing, at the processor 208 and/or the device 200 (e.g., at the block 505 and the block 507) the device information of the given communication device 202 with the records 210 of the previously installed communication devices 202 prior to generating the hashed device characteristics of the given communication device 202; and in response to determining, at the processor 208 and/or the device 200, that the device information of the given communication device 202 does correspond to given device information of a given record 210: determining, at the processor 208 and/or the device 200, from the given record 210, the hash function (e.g., from the decrypted hash function identifier 418); and generating the hashed device characteristics of the given communication device 202 using the hash function (e.g., determined from the decrypted hash function identifier 418).

[0097] The processor 208 and/or the device 200 may compare the hashed device characteristics of the given communication device 202 with the respective hashed device characteristics of the given record 210; and the method 500 may further comprise: in response to determining that the hashed device characteristics of the given communication device 202 does not match the respective hashed device characteristics of the given record 210, generating, at the processor 208 and/or the device 200, a respective exception record (e.g., and stored at the database 218).

[0098] In some specific examples, the method 500 may further comprise the processor 208 and/or the device 200: loading the records 210 into the buffer 232; comparing associated device information of the plurality of communication devices 202 with the respective information of the records 210; deleting a loaded record 210 at the buffer 232 in response to the loaded record 210 including given information corresponding to a least the associated device information of one of the plurality of communication devices 202; and after the associated device information of all of the plurality of communication devices 202 has been compared with the respective information of the records 210, and a given record 210 remains at the buffer 232, such that the given record 210 does not include respective information corresponding to associated device information of the plurality of communication devices 202, generating a respective exception record (e.g., and storing at the database 218).

[0099] Hence, for example, the respective exception record indicates that the given record 210 remaining at the buffer 232 may represent a previously installed communication device 202 that is no longer present at the device 200 (e.g., the previously installed communication device 202 has been removed). [00100] With regards to the block 509, the processor 208 and/or the device 200 may control a notification device to provide a notification of an exception record by: controlling an internal notification device, such as the notification device 234, to provide the notification, for example as a pop-up window, and the like a display screen of the device 200.

[00101] However, alternatively, and/or in addition, the processor 208 and/or the device 200 may control a notification device to provide a notification of an exception record by: controlling an external notification device to provide the notification by transmitting the notification to the external notification device; for example, a notification of an exception record may be transmitted to a computing device and/or a communication device of an administrator and/or an IT department. Such transmission may occur via communication device 202 that has been verified against a corresponding record 210 (e.g., such a verification may include determining that the device information and hashed device characteristics of a communication device 202 match corresponding device information and hashed device characteristics of a record 210); when no communication devices 202 are verified, the processor 208 may provide a notification thereof at the notification device 234 which instructs a user to contact an administrator and/or an IT department.

[00102] Regardless a notification of an exception record may provide an alert of a possible unauthorized and/or unverified communication devices 202 being present at the device 200 and/or provide an alert of possible unauthorized changes to communication devices 202 at the device 200. Such a notification may cause a user of the device 200 to bring in the device 200 for servicing to check the communication devices 202, for example, to an IT department, and/or cause an IT department to contact the user to bring in the device 200 for servicing to check the communication devices 202. An administrator of the device 200 and/or IT personnel may remove and/or inspect the unverified communication devices 202. Once all communication devices 202 are again verified and/or swapped for verified communication devices 202, the device 200 may again be controlled to implement the device binding mode. Hence, such a notification may assist in preventing a DMA attack.

[00103] In some examples, however, the device 200 and/or the processor 208 may lock the device 200 (e.g., and which may be unlocked via an administrator password, and the like) and/or disable a communication device 202 associated with an exception record, for example by controlling an internal switch to cut off power to the communication device 202 and/or deny the communication device 202 access to memories of the device 200 to assist in preventing a DMA attack. [00104] As previously described the memory 204 is understood to include a non-transitory computer-readable medium comprising instructions 206 that, when executed by the processor 208 of the device 200, causes the processor 208 to perform functionality as described herein.

[00105] In particular, the instructions 206, when executed by the processor 208 of the device 200, may cause the processor 208 to: compare device information and hashed device characteristics of currently-present internally-installed communication devices 202, which operate according to direct memory access (DMA), with records 210 of communication devices 202 which were previously installed at the device 200. Exception records may be generated accordingly. [00106] For example, as mentioned above, at least three different conditions are contemplated herein that result in an exception record.

[00107] For example, in response to determining that the device information of a currently-present internally-installed communication device 202 is not found in the records 210, the device 200 may generate a first exception record, for example of a new communication device.

[00108] Furthermore, in response to determining that the device information of the currently-present internally-installed communication device 202 is found in the records 210, but the hashed device characteristics thereof is not found in the records 210, the device 200 may generate a second exception record, for example of a changed and/or spoofed communication device.

[00109] Furthermore, in response to determining that a given record 210 does not include respective information corresponding to the device information of the currently-present internally-installed communication devices 202, the device 200 may generate a third exception record, for example of a removed communication device.

[00110] As has already been described the instructions 206 may be further to cause the processor 208 to: select a hash function for generating the hashed device characteristics, using an indication of the hash function 216 (e.g., a hash function identifier 418 and/or an encrypted hash function identifier 428) as stored in a record 210 to which the hashed device characteristics are being compared.

[00111] As has also already been described the instructions 206 may be further to cause the processor 208 to: in response to determining that the device information of a currently-present internally-installed communication device 202 is found in a record 210, select a hash function 216 for generating the hashed device characteristics using an indication of the hash function 216 stored in the record 210; generate the hashed device characteristics using the hash function 216 as selected; and determine whether the hashed device characteristics is found in the record 210.

[00112] In some examples, as seen in Figure 2 and Figure 4, a non-transitory computer-readable medium provided herein, such as the memory 204, may further store the records 210. A record 210 for a previously installed communication device 202 may have a structure of: respective device information 416 stored in an encrypted state (e.g., device information 426); an indication of a respective hash function (e.g., a hash function identifier 418) stored in an encrypted state (e.g., an encrypted hash function identifier 428); and device characteristics 224 of the previously installed communication device 202, as stored in a ROM 222 thereof, stored in a hashed state using the respective hash function 216 (e.g., as the hashed device characteristics 424). [00113] In some examples, as seen in Figure 2 and Figure 4, a non-transitory computer-readable medium provided herein, such as the memory 204 may further store the records 210 and a record 210 may include respective hashed device characteristics 424 generated from capability information of the communication devices 202 which were previously installed.

[00114] Further details of a device binding mode and a device detection mode are now described with respect to Figure 6, Figure 7, Figure 8, Figure 9 and Figure 10 which depict methods which may be implemented by the device 200 and/or the processor 208 implementing the instructions 206. However the methods described hereafter may alternatively be implemented by the device 100 and/or the processor 108 implementing the instructions 106. Like the method 500, the methods described hereafter may not be performed in the exact sequence as shown, and various blocks may be performed in parallel rather than in sequence, or in a different sequence altogether. Furthermore, while the methods described hereafter are described with respect to the databases 212, 218, it is understood that the records 210 and/or exception records may not be stored in databases at the memory 204.

[00115] Attention is next directed to Figure 6 which depicts an example method to change between a device binding mode and a device detection mode.

[00116] The method 600 generally starts at a block 602, for example, when an application at the device 200 is launched upon startup and/or by a user, and/or an administrator, and the like, interacting with the input device 236 to launch the application (e.g., which may be in the form of the instructions 206).

[00117] At a block 604, the processor 208 determines whether to implement a device binding mode or a device detection mode, for example by receiving input from the input device 236. In particular, implementation of a device binding mode may require input of a password, and the like, at the input device 236, which may be known by an administrator and/or an IT department managing the device 200, but not a usual user of the device 200. As such, in some examples, the device binding mode may only be launched by persons knowing the password and who may then select launch of the device binding mode from a menu, and the like.

[00118] Presuming that the device binding mode is to be launched (e.g., a “YES” decision at the block 604), at the block 606 the processor 208 implements the device binding mode, described in more detail below with respect to Figure 7, to generate the records 210. Once the records 210 are generated, the method 600 may end at the block 608 and the device 200 may be provided to a usual user of the device 200. For example, such a user may be an employee of an organization and an IT department of the organization may manage devices, such as the device 200, for the organization; hence a user may be “usual” user and/or a “normal” user of the device 200 when such a user uses the device 200 to conduct the business of the organization.

[00119] Returning to the block 604, when the device binding mode is not to be launched (e.g., a “NO” decision at the block 604 which may occur, for example, when no password is received), at the block 610 the processor 208 determines whether the database 212 is empty and/or whether there are no records 210 stored at the memory 204 (e.g., the device binding mode may not have been executed). When the database 212 is empty and/or whether there are no records 210 stored at the memory 204 (e.g., a “YES” decision at the block 610), at a block 612 the processor 208 may provide a notification thereof (e.g., at the notification device 234 and/or transmitted to a communication device of an administrator and/or an IT department). Such a notification indicates that the device binding mode is yet to run and hence the device 200 may be open to DMA attacks from installed communication devices 202. In some examples, the processor 208 may lock the device 200 and the notification may also indicate that a user of the device 200 is bring the device 200 to an IT department, and the like, so that the device binding mode may be implemented. The method 600 may then end at the block 608.

[00120] Returning to the block 610, the processor 208 may determine that the database 212 is not empty and/or there are records 210 stored at the memory 204 (e.g., a “NO” decision at the block 610), and at a block 614 the processor 208 may change to a device detection mode as described with respect to the method 500, and further described below with respect to Figure 8, Figure 9 and Figure 10. The method 600 may then end at the block 608. Presuming no exception records are generated, the user of the device 200 may continue with normal operation of the device 200.

[00121] Attention is next directed to Figure 7 which depicts an example method 700 to generate records in a device binding mode.

[00122] At a block 702, the processor 208 may start the device binding mode (e.g., in response to a “YES” decision at the block 604 of the method 600). [00123] At a block 704, the processor 208 may delete any records 210 present in the database 212 for example to flush the database 212 and/or the memory 204 of any records generated a last time the device binding mode was implemented.

[00124] At a block 706, the processor 208 may search for internal communication devices 202 and external communication devices 230 (e.g., by querying the various slots 226, 228) and enumerate any currently present communication devices 202, 230 for example by temporarily storing indications of any currently present communication devices 202, 230 in a temporary device pool (e.g., a list of currently present communication devices 202, 230, in any suitable order, for example in an order in which they responded to queries) at the buffer 232.

[00125] At a block 708, the processor 208 selects a first communication device 202, 230 in the device pool and determines, at a block 710, whether the selected communication device 202, 230 is an internal communication device 202 or an external communication device 230, for example based on a slot 226, 228 at which the selected communication device 202, 230 is present.

[00126] In response to the selected communication device 202, 230 comprising an internal communication device 202 (e.g., a “YES” decision at the block 710), at a block 712, the processor 208 queries the selected internal communication device 202 for device information and device characteristics (e.g., device capabilities and/or a capability structure) as described above. Additionally, and/or alternatively to querying the device information, the processor 208 may determine device information at the block 712 by determining path data associated with the selected internal communication device 202.

[00127] At a block 714, the processor 208 places the device information and device characteristics associated with the selected internal communication device 202 into the buffer 232. In particular, it is understood that the device characteristics associated with the selected internal communication device 202 that is queried and placed the buffer 232 occurs to a given scheme, such as all of the device capabilities being queried and placed the buffer 232 and/or a given portion of the device capabilities being queried and placed the buffer 232. Similarly, it is understood that the device information associated with the selected internal communication device 202 that is queried and placed the buffer 232 also occurs to a respective given scheme, such as a DID and path data of with the selected internal communication device 202 being concatenated.

[00128] At a block 716 the processor 208 selects a hash function 216, randomly and/or according to any suitable scheme. At a block 718, the processor 208 hashes the device characteristics of the selected internal communication device 202 using the selected hash function 216 to produce hashed device characteristics 424.

[00129] At the block 718, the processor 208 encrypts the device information of the selected internal communication device 202 using the cryptographic algorithm 214, and encrypts a hash function identifier of the selected hash function 216 using the cryptographic algorithm 214 to respectively produce encrypted device information 426 and encrypted hash function identifier 428. [00130] At a block 720, the processor 208 combines the hashed device characteristics 424, the encrypted device information 426 and the encrypted hash function identifier 428 into a record 210 associated with the selected internal communication device 202 and stores the record 210 into the database 212.

[00131] At a block 722, the processor 208 uses the device pool to determine whether the selected internal communication device 202 is a last communication device in the device pool. If not (e.g., a “NO” decision at the block 722), at a block 724 the processor 208 selects a next communication device 202, 230 in the device pool at the buffer 232 and repeats the block 710. If a “YES” decision at the block 710, the blocks 712 to 722 are repeated until records 210 for all internal communication devices 202 are generated and stored at the database 212.

[00132] However, returning to the block 710, when a “NO” decision occurs at the block 710 and a selected communication device 202, 230 is an external communication device 230, the processor 208 determines, at the block 722, whether the external communication device 230 is last communication device 202, 230 in the device pool and, if not, proceeds to select a next communication device 202, 230 in the device pool at the block 724.

[00133] Otherwise, when a last communication device 202, 230 in the device pool is reached (e.g., a “YES” decision at the block 722), whether internal or external, the device binding mode ends at a block 728. Any information in the device pool may be flushed (e.g., deleted) from the buffer 232.

[00134] Attention is next directed to Figure 8, Figure 9 and Figure 10 which depicts an example method to compare records 210 of previously installed communication devices 202 with information from currently-present communication devices 202 to protect from a direct memory attack, for example in a device detection mode.

[00135] Beginning at Figure 8, at a block 802 the device 200 enters the device detection mode and at a block 804 the processor 208 copies the records 210 into the buffer 232. At a block 806, the processor 208 uses the cryptographic algorithm to decrypt the encrypted device information 426 and the encrypted hash function identifiers 428 of the records 210 to store the device information 416 and the hash function identifiers 418 of the records 210 in the buffer 232 in association with respective hashed device characteristics 224.

[00136] At a block 808, the processor 208 searches and enumerates currently present communication devices 202, 230 into a device pool in the buffer 232, similar to as described above with regards to the block 706.

[00137] At block 810, the processor 208 selects a first communication device 202, 230 in the device pool.

[00138] Attention is next directed to Figure 9 which continues the method 800, as indicated by “A” after the block 810 in Figure 8, and before a block 812 in Figure 9.

[00139] For example, after the block 810, at the block 812 the processor 208 determines whether a selected communication device 202, 230 is an internal or external communication device similar to as described above with respect to the block 710. When the selected communication device 202, 230 is an internal communication device 202 (e.g., a “YES” decision at the block 812), at a block 814, the processor 208 the selected internal communication device 202 for device information and device characteristics (e.g., device capabilities and/or a capability structure) as described above. Additionally, and/or alternatively to querying the device information, the processor 208 may determine device information at the block 814 by determining path data associated with the selected internal communication device 202. The device information determined for the selected internal communication device 202 is determined according to the same respective given scheme used to determine device information for the records 210 at the block 712.

[00140] At block 816, the processor 208 compares the device information of the selected internal communication device 202 with the device information 416 of the records 210 in the buffer 232. At a block 818, the processor 208 determines whether a matched record 210 is found; for example, a matched record 210 comprises a record 210 in the buffer 232 associated with device information 416 that matches device information of the selected internal communication device 202.

[00141] When a matched record 210 is found (e.g., a “YES” decision at the block 818), at block 820 the processor 208 places the device characteristics of the selected internal communication device 202 (e.g., and also the device information) into the buffer 232. The device capabilities of the selected internal communication device 202 that are queried and placed the buffer 232 are understood to be selected according to the same given scheme used to query and select the device capabilities at the block 712 when the records 210 are generated.

[00142] At a block 822, the processor 208 selects the hash function 216 identified by the hash function identifier 418 of the matched record 210 and, at a block 824, the processor 208 uses the selected hash function 216 to hash the device characteristics of the selected internal communication device 202 to produce hashed device characteristics of the selected internal communication device 202.

[00143] At the block 826, the processor 208 compares the hashed device characteristics of the selected internal communication device 202 with the hashed device characteristics 424 of the matched record 210.

[00144] At a block 828, the processor 208 determines whether a match occurs between the hashed device characteristics of the selected internal communication device 202 and the hashed device characteristics 424 of the matched record 210.

[00145] When no match occurs (e.g., a “NO” decision at the block 828), at a block 830, the processor 208 may generate and add an exception record of a communication device change to the database 218. For example, when the device information of a communication device 202 matches the device information of a record 210 (e.g., determined at the block 818), but their hashed device characteristics do not match, the communication device 202 may be a spoofed communication device, where a malicious entity has spoofed the device information of a communication device 202, but not the capability structure, and the like, and replaced the communication device 202 with the spoofed communication device (and/or a user of the device 200 may perform such a replacement having ordered what they mistakenly believed is a valid replacement communication device 202). Hence, the exception record generated at the block 830 may specifically indicate such a communication device change.

[00146] At a block 832, the processor 208 deletes the matched record 210 from the 232.

[00147] Alternatively, when a match occurs between the hashed device characteristics of the selected internal communication device 202 and the hashed device characteristics 424 of the matched record 210 (e.g., a “YES” decision at the block 828), the processor 208 again deletes the matched record at the block 832. In these examples, as both the device information and hashed device characteristics of the selected internal communication device 202 matches device information and hashed device characteristics of the matched record 210, no exception record is generated as the selected internal communication device 202 is understood not to be spoofed and/or it is understood that the selected internal communication device 202 is a verified communication device 202.

[00148] At block 834, the processor 208 determines whether the selected internal communication device 202 is a last communication device 202, 230 in the device pool and, if not (e.g., a “NO” decision at the block 834), at a block 836, the processor 208 selects a next communication device 202, 230 in the device pool and repeats the block 812.

[00149] Indeed, returning to the block 812, when a selected communication device 202, 230 in the device pool is an external communication device 230, the block 834 is repeated and the processor 208 determines whether the selected external communication device 230 is a last communication device 202, 230 in the device pool. If not, the blocks 836 etc. are repeated.

[00150] Returning to the block 818, when the processor 208 determines that no record 210 includes device information 416 that matches device information of a selected internal communication device 202, (e.g., a “NO” decision at the block 818), at a block 838, the processor 208 may generate and add an exception record of a new communication device to the database 218. For example, when no record 210 includes device information 220 that matches device information of a selected internal communication device 202, the selected internal communication device 202 may be a new spoofed communication device and/or a new communication device 202 (that may or may not be from a reliable vendor). For example, a malicious entity and/or a user of the device 200 may have installed a new communication device 202 for which a record 210 has not yet been generated. Hence, the exception record generated at the block 838 may specifically indicate such a new communication device.

[00151] In any event, it is understood that the blocks depicted in Figure 9 are repeated accordingly until a last communication device 202, 230 in the device pool is reached. As such, each internal communication device 202 currently present at the device 200 is evaluated to determine whether it is a changed or new communication device 202 (e.g., changed or new relative to when the records 210 were generated) and exception records are generated at the blocks 830, 838, accordingly. In some examples, no exception records may be generated however, for example, when device information and hashed device characteristics of all the internal communication devices 202 are successfully matched to both device information and hashed device characteristics of the records 210.

[00152] Furthermore, all the records 210 in the buffer 232 for which a matched or partially matched internal communication devices 202 was found (e.g., whether a match of device information only or match of both device information and hashed device characteristics), are deleted. However, some records 210 may remain, as described hereafter.

[00153] At block 834, when a last communication device 202, 230 in the device pool is reached (e.g., a “YES” decision at the block 834), the method 800 continues at a block 840 depicted in Figure 10.

[00154] Hence, attention is next directed to Figure 10 which continues the method 800, as indicated by “B” after the block 834 in Figure 9, and before the block 840 in Figure 10.

[00155] In particular, at the block 840, the processor 208 determines whether any records 210 remain in the buffer 232 and, when a record 210 remains in the buffer 232, at a block 842, an exception record may be generated, and stored in the database 218, for every record 210 which remains in the buffer 232. Such exception records generally indicate that a record 210 of a previously installed communication device 202 was not matched to any of the currently present communication device 202 and/or that such a previously installed communication device 202 was removed from the device 200 (e.g., and/or no longer functioning such that it cannot respond to queries from the processor 208).

[00156] After the block 842 and/or in response to a “NO” decision at the block 840 (e.g., there are no records 210 remaining in the buffer 232), at a block 844, the processor 208 controls a notification device to provide a notification of any exception records generated, as described above. At a block 846, the processor 208 may flush the buffer 232 (e.g., delete any of the information placed in the buffer 232 while implementing the method 800) and the device detection mode ends at a block 848. The method 800 may also include locking the device 200 in response to exception records being generated and/or disabling communication devices 202 associated with generated exception records.

[00157] The exception records may include, but are not limited to, identifiers of associated communication devices 202 (e.g., associated device information) and/or associated records 210 (e.g., associated device information encrypted or not encrypted) and/or whether a respective exception record is for a changed communication device, a new communication device or a removed communication device. As such, an administrator, and/or IT personnel examining the exception records may quickly determine an associated issue. [00158] Indeed, in some examples, the notification of exception records provided by a notification device may include information in the exception records and/or a notification transmitted to an external communication device may include the exception records.

[00159] Attention is next directed to Figure 11 , which is substantially similar to Figure 2, with like components having like numbers. In particular, in Figure 2, the processor 208 has loaded device information 1116 and hashed device characteristics 1124 of a selected internal communication device 202 into the buffer 232 and is comparing, at the buffer 232, the device information 1116 and hashed device characteristics 1124 with the records 210, as described above. As depicted, the processor 208 has determined that the hashed device information 1116 does not match any of the records 210 and a new device exception record 1110 is generated (e.g., at the block 838) and stored at the database 218. However, generation of the exception record 1110 is one example only and other exception records may be generated as described herein.

[00160] Attention is next directed to Figure 12, which is substantially similar to Figure 3, with like components having like numbers. In particular, in Figure 12, it is understood that the processor 208 is controlling the notification device 234 (e.g., a display screen) to provide a notification 1201 of the exception record 1110. The notification 1201 comprise text in a pop-up window warning that A “NEW COMMUNICATION DEVICE DETECTED THAT HAS NOT BEEN VERIFIED. DEVICE LOCKED: IT DEPARTMENT HAS BEEN NOTIFIED”. Hence it is further understood that the processor 208 has locked the device 200, and has further transmitted a notification to an IT department. It is understood that any transmitted notification are transmitted using communication devices 202 for which a corresponding records 210 has been found with matched device identifiers and matched hashed device characteristics; when no communication devices 202 have a corresponding record 210 with matched device identifiers and matched hashed device characteristics, the processor 208 may lock the device 200 and the notification 1201 may indicate that the IT department (and the like) must be contacted by a user of the device 200 (e.g., as no communication devices 202 that were previously verified in the device binding process are present at the device 200).

[00161] It should be recognized that features and aspects of the various examples provided above may be combined into further examples that also fall within the scope of the present disclosure.

Claims

1 . A device comprising: a plurality of communication devices, internally installed, which operate according to direct memory access (DMA); a memory; and a processor connected to the plurality of communication devices and the memory, the processor to: determine respective device information and respective device characteristics of the plurality of communication devices, the respective device information comprising a respective identifier or respective path data associated with a respective communication device; apply a respective hash function to the respective device characteristics of the plurality of communication devices to generate respective hashed device characteristics; generate a plurality of records corresponding to the plurality of communication devices, a respective record comprising: the respective device information; and the respective hashed device characteristics; and store, at the memory, the plurality of records for later use in detection of the plurality of communication devices by the processor.

2. The device of claim 1 , wherein the processor is further to: encrypt the respective device information prior to including in the respective record.

3. The device of claim 1 , wherein the processor is further to: randomly select the respective hash function from a plurality of hash functions, such that different respective hash functions are used to generate different respective hashed device characteristics for the plurality of communication devices, wherein the respective record further comprises an indication of the respective hash function used to generate the respective hashed device characteristics.

4. The device of claim 1 , wherein the respective device characteristics comprises device capabilities stored in a respective read-only memory (ROM) of the respective communication device.

5. The device of claim 1 , wherein the respective identifier of the respective device information comprises a respective device identifier or a respective vendor identifier, and the respective path data comprises an indication of a respective slot at which the respective communication device is installed.

6. A method comprising: determining, at a processor of a device, device information and device characteristics of a communication device installed internal to the device; generating, at the processor, from the device characteristics and using a hash function, hashed device characteristics; comparing, at the processor, the device information or the hashed device characteristics with records of previously installed communication devices; generating, at the processor, an exception record in response to determining, at the processor, that: the device information does not correspond to respective device information of the records; the hashed device characteristics does not match respective hashed device characteristics of the records; or a given record does not include respective information corresponding to the device information; and controlling, via the processor, a notification device to provide a notification of the exception record.

7. The method of claim 6, wherein the comparing the device information or the hashed device characteristics with the records of the previously installed communication devices comprises: comparing the device information with the records to determine whether the device information corresponds to the respective device information of the records; and in response to determining that the device information does correspond to given device information of a given record, comparing the hashed device characteristics with the respective hashed device characteristics of the given record, and wherein in response to determining that the device information does not correspond to the respective device information of any of the records, generating a respective exception record.

8. The method of claim 6, further comprising: comparing the device information with the records of the previously installed communication devices prior to generating the hashed device characteristics; in response to determining that the device information does correspond to given device information of a given record: determining, from the given record, the hash function; and generating the hashed device characteristics using the hash function; comparing the hashed device characteristics with the respective hashed device characteristics of the given record; and in response to determining that the hashed device characteristics does not match the respective hashed device characteristics of the given record, generating a respective exception record.

9. The method of claim 6, further comprising: loading the records into a buffer, including the given record; comparing associated device information of a plurality of communication devices with the respective information of the records; deleting a loaded record at the buffer in response to the loaded record including given information corresponding to the associated device information of one of the plurality of communication devices; and after the associated device information of all of the plurality of communication devices has been compared with the respective information of the records, and the given record remains at the buffer such that the given record does not include the respective information corresponding to the associated device information, generating a respective exception record.

10. The method of claim 6, wherein controlling the notification device to provide a notification of the exception record comprises: controlling an internal notification device to provide the notification; or controlling an external notification device to provide the notification by transmitting the notification to the external notification device.

11. A non-transitory computer-readable medium comprising instructions that, when executed by a processor of a device, causes the processor to: compare device information and hashed device characteristics of currently-present internally-installed communication devices, which operate according to direct memory access (DMA), with records of communication devices which were previously installed at the device; in response to determining that the device information of a currently- present internally-installed communication device is not found in the records, generate a first exception record; in response to determining that the device information of the currently- present internally-installed communication device is found in the records, but the hashed device characteristics thereof is not found in the records, generate a second exception record; and in response to determining that a given record does not include respective information corresponding to the device information of the currently- present internally-installed communication devices, generate a third exception record.

12. The non-transitory computer-readable medium of claim 11 , wherein the instructions are further to cause the processor to: select a hash function for generating the hashed device characteristics, using an indication of the hash function as stored in a record to which the hashed device characteristics are being compared.

13. The non-transitory computer-readable medium of claim 11 , wherein the instructions are further to cause the processor to: in response to determining that the device information of the currently- present internally-installed communication device is found in a record, select a hash function for generating the hashed device characteristics using an indication of the hash function stored in the record; generate the hashed device characteristics using the hash function as selected; and determine whether the hashed device characteristics is found in the record.

14. The non-transitory computer-readable medium of claim 11 , further storing the records, a record for a previously installed communication device having a structure of: respective device information stored in an encrypted state; an indication of a respective hash function stored in an encrypted state; and device characteristics of the previously installed communication device, as stored in a read-only-memory thereof, stored in a hashed state using the respective hash function.

15. The non-transitory computer-readable medium of claim 11 , further storing the records, wherein a record includes respective hashed device characteristics generated from capability information of the communication devices which were previously installed.