WO2012014196A1 - Device and method for communicating with a storage device - Google Patents

Device and method for communicating with a storage device Download PDF

Info

Publication number
WO2012014196A1
WO2012014196A1 PCT/IL2011/000595 IL2011000595W WO2012014196A1 WO 2012014196 A1 WO2012014196 A1 WO 2012014196A1 IL 2011000595 W IL2011000595 W IL 2011000595W WO 2012014196 A1 WO2012014196 A1 WO 2012014196A1
Authority
WO
WIPO (PCT)
Prior art keywords
command
standard
file
write
read
Prior art date
Application number
PCT/IL2011/000595
Other languages
French (fr)
Inventor
Isaac Hadad
Doron Yaari
Zvi Gam
Abraham Dahan
Original Assignee
Walletex Microelectronics Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Walletex Microelectronics Ltd. filed Critical Walletex Microelectronics Ltd.
Publication of WO2012014196A1 publication Critical patent/WO2012014196A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0628Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0661Format or protocol conversion arrangements
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0602Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604Improving or facilitating administration, e.g. storage management
    • G06F3/0607Improving or facilitating administration, e.g. storage management by facilitating the process of upgrading existing storage systems, e.g. for improving compatibility between host and storage device
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0668Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671In-line storage system
    • G06F3/0673Single storage device
    • G06F3/0679Non-volatile semiconductor memory device, e.g. flash memory, one time programmable memory [OTP]

Definitions

  • the present invention generally relates to expanding the access to, and operations performance of a storage device, preferably a USB device, having processing capabilities over standard communication protocols.
  • the small computer system interface also known as SCSI
  • SCSI provides a communication bus and a command set for interfacing storage and peripheral devices in computerized systems.
  • the SCSI interface defines both a parallel I/O bus and a data protocol that can be used for connecting peripheral devices (disk drives, modems, printers, scanners, and the like) to a host computer.
  • peripheral devices disk drives, modems, printers, scanners, and the like
  • SCSI command set is widely used in computerized systems to communicate with devices over different buses.
  • Storage devices may be accessed for read and write operations by means of standard read and write commands available in almost any standard high level programming language (e.g., ANCI C) .
  • read and write commands typically comprise a header and a data payload which may be transferred over a variety of bus types.
  • Fig. 1 schematically illustrates conventional data flow between a personal computer (PC) 12 and a USB (Universal Serial Bus) storage device ⁇ 13 over data bus 14.
  • PC 12 personal computer
  • USB Universal Serial Bus
  • Any communication in this system is initiated by PC 12 which sends a command to the storage device 13, which then responds.
  • PC 12 which sends a command to the storage device 13, which then responds.
  • user mode driver 12d which transfers the r/w command to the appropriate operating system (OS, 12o) driver indicating to it. the needed operation and the target device.
  • OS operating system
  • the kernel driver issues a SCSI command using the SCSI protocol 12s, said command is then encapsulated by the USB protocol 12u and sent to the target device 13 via USB controller 12c over data bus 14.
  • USB controller 13c provided in target device 13 which decodes the SCSI command, which is then executed by means of microcontroller unit (MCU) 13m.
  • Memory 13r e.g., flash memory
  • LUNs - LUNO, LUNl, LUNn logical units
  • LUNs - LUNO, LUNl, LUNn L0, Ll, Ln
  • the r/w command should include indications concerning the LUN number, and a range of addresses in it to be accessed.
  • the target device After the execution of the r/w command the target device returns a status code byte over data bus 14 to indicate successful operation or any error which may have occurred.
  • a user mode drive 12d (custom driver) is utilized to access target device 13, but it may as well be a driverless device which can be accessed by means of the drivers of OS 12o.
  • Driverless devices have some advantages, such as better compatibility with the operating system and thus also better stability, however the operation of such devices must fall into the predefined USB device classes provided by the USB protocols, such as for example, the human interface devices (HID) class or the mass storage devices (MSD) class.
  • the HID class covers many types of devices and functions however it supports limited bandwidths which are often not acceptable for high speed devices. While the MSD class supports greater bandwidths it is also limited to certain types of devices and provide a limited set of commands .
  • USB device functionality requires functions not covered by the USB device classes
  • a custom driver is required. While user mode custom drivers can be designed to provide high data transfer speeds, they tend to be less stable and demand specific implementations tailored to suit the specific requirements of each operating system (e.g., Windows, Linux,- MAC) and so often also requirements of specific, distributions (e.g., Reahat, Mandrake, Slackware) and versions (e.g., WIN XP, vista, windows 7, windows server 2003/2008) of the operating systems.
  • Windows, Linux,- MAC e.g., Windows, Linux,- MAC
  • specific, distributions e.g., Reahat, Mandrake, Slackware
  • versions e.g., WIN XP, vista, windows 7, windows server 2003/2008
  • a major difficulty associated with such custom user mode drivers concerns the permissions which may be required by the operating system for their execution.
  • a user application wishing to gain access to a custom USB device over the MSD class interface is required to have administrator permissions. While this requirement is made in order to enhance the security, it complicates access permission policies and may eventually cause security hazards if administrator permissions are provided to regular users in order to allow them to access a certain hardware requiring a special USB driver.
  • the present invention provides method and apparatus for operating a USB device having processing capabilities utilizing the standard USB device classes with additional functionality and special commands which are not supported by the standard USB device classes.
  • the USB device of the invention may be operated utilizing the standard USB read and write commands provided in standard high level programming libraries (e.g., ANSI C) and which are compliant with any operating system (MAC, WONDO S, LINUX, UNIX,...) without requiring a special USB device driver and privileged permission, as often required for operating custom drivers.
  • the USB device is operated as a USB MSD class device.
  • the USB device of the invention may be a type of USB mass storage device comprising a main memory (e.g., FLASK memory) and a microcontroller unit (MCU) which is preferably adapted to provide additional functionality (e.g., encryption/decryption) not supported by the standard USB device classes.
  • the USB device of the invention may be connected to any USB host and provide access to its main memory, as performed with standard USB MSD devices.
  • the main memory in the USB device is preferably partitioned into a number of logical units (LUNs), wherein one of said LUNs is designated for adding the special commands supported by the USB device. While this designated LUN may be ordinarily accessed by user mode applications, whenever it is being accessed by a write command the MCU extracts and processes the header of the write command to determine if it should be processed as a regular write command or as a special command. Preferably, this is determined according to the memory locations addressed by the write command.
  • LUNs logical units
  • the designated LUN is configured to comprise files named "read” and "write” such that any write command which addresses the "write” file is processed by the MCU as a special write command, and similarly, any read command addressing the "read” file is processed as a special read command.
  • the USB device carries it out in the standard manner, as defined in the USB protocol. If it is determined that the issued command is a special command then the MCU writes the data section of the command into the memory locations defined by the issued command and then extracts and processes the data section to determined if the issued command includes a valid special command. More particularly, whenever said "write" file is accessed, the MCU analyzes the data written in the "write” file to extract and execute a special command embedded in it, and whenever the operation of such special command produces data to be transferred to the host computer said data is written by the MCU into the "read” file, thereby allowing the host computer to fetch the produced data by means of a read command.
  • the MCU If there is no valid special command in the data section of the issued write command, then the MCU issues an error indication, and if a valid special command is found, then it is executed by the MCU which issues a respective acknowledge upon successful execution.
  • the invention is thus directed to a method and device for transferring non-standard commands to an external device having storage and processing capabilities and that is capable of being linked to a host computer by means of standard, communication links (e.g., USB, serial/parallel UART, IrDA, Bluetooth, and the like) .
  • Non-standard commands are transferred to the device by means of a designated file stored in the device which may be accessed by standard write and read commands employing standard communication protocols (e.g., SCSI).
  • standard communication protocols e.g., SCSI
  • the device of the present invention is adapted to identify such standard write commands addressing the designated file and determine whether they incorporate a non-standard command in the data section of the standard write command.
  • the data section may be written to the designated file, as carried out in a standard write command, but if the device identifies a non-standard command in the data section of the standard write command the non-standard command is extracted and executed. Any data and/or indications produced by execution of the non-standard command are then stored in an additional designated file in the memory of the device which may be accessed by means of standard read commands . , or by means of another non-standard command, if so needed.
  • non-standard commands and special commands used herein relate to commands and operations that are not supported by the standard communication protocol or which are not supported by the standard set of commands available for operating a certain type of device class (e.g., USB MSD class) .
  • the standard USB MSD class does not support write operations to hidden sections of the MSD device, and it does not provide suitable commands for carrying out cryptographic tasks, and it is therefore not suitable for implementing devices of the type of information security devices.
  • standard command used herein relates tc commands supported by standard protocols or by standard device class used for operating the external device.
  • the present invention is directed to a method for operating and managing a storage device having processing capabilities and interfacing means suitable for linking it to a computer machine, the method comprising: creating a write file in a designated logical unit in the storage device; whenever the write file is being accessed by a standard write command extracting a special command embedded in the dar.a section of the standard write command; and executing the special command.
  • the method may comprise writing the data section of the standard write command into the write file.
  • the method may further comprise creating a read file and storing results and/or indications related to the executed special command in the read file.
  • the method may further comprise extracting a special command whenever the read file is being accessed by a read command from one or more fields of the read command, if needed, and transferring the results and/or indications stored in the read file over the data link.
  • the present invention is directed to a storage device having processing capabilities configured to operate in a standard mode or device class while allowing it to perform special commands not supported by said standard mode or device class
  • the storage device comprise processing means coupled to interfacing means suitable for establishing a data link with a computer machine, and . to one or more memory means provided the storage device, wherein the storage device is adapted to create a write file in a designated logical unit in the one or more memory means and execute special commands embedded in standard write commands addressing the writs file.
  • the storage device may be adapted to write the data section of the standard write command in the write file.
  • the storage device may further comprise a read file used for storing results and/or indications related to the execution of the special commands.
  • the storage device may be further adapted to execute special commands embedded in read commands addressing the read file, if needed, and to transfer the results and/or indications stored in the read file over the data link.
  • the invention relates to a method for transferring non ⁇ standard commands to a device having storage and processing capabilities and that is capable of being linked to a host computer the method comprising creating a designated file in said device, analyzing any standard write command attempting to access said designated file to determine whether it incorporates a non-standard command, and executing said non ⁇ standard command, if incorporated in said standard write command.
  • the invention further relates to a method for operating and managing a storage device having processing capabilities and interfacing means suitable for linking it to a computer machine, the method comprising: creating a write file in a designated logical unit in said storage device; whenever said write file is being accessed by a standard write command extracting a special command embedded therein and executing it.
  • the method further comprises creating a read file in the device and storing results and/or indications related to the execution of the special command in said read file.
  • the method further comprises whenever the read file is being accessed by a read command extracting a special command from one or more fields in said read command, if needed, and transferring the results and/or indications stored, in said read file over the data link.
  • the special command comprises a code for carrying out electronic signature.
  • the special command comprises a code for carrying out encryption/decryption of data .
  • the present invention relates to a device having storage and processing capabilities capable of being linked to a host computer comprising a designated file accessible for standard write commands, wherein said device is adapted to analyze any such standard write command attempting to access said designated file to determine whether it incorporates a non- standard command, and to execute said non-standard command if incorporated in said standard write command.
  • the present invention further relates to a storage device having processing capabilities configured to operate in a standard mode or device class while allowing it to perform special commands not supported by said standard mode or device class, comprising processing means coupled to interfacing means suitable for establishing a data link, and to one or more memory means provided therein, wherein said storage device is adapted to: create a write file in a designated logical unit in said one or more memory means and execute special commands embedded in standard write commands addressing said write file.
  • the storage device further comprises a read file in the designated logical unit in said storage device wherein said storage device is further adapted to store results and/or indications related to said the execution of the special commands .
  • the storage device is further adapted to transfer and execute special commands embedded in read commands addressing said read file, if needed, and to transfer data stored in the read file over the data link.
  • the storage device special command comprises a code for carrying out electronic signature.
  • the storage device special command comprises a code for carrying out encryption/decryption of data stored in the memory means or of data being received in the device.
  • Fig. 1 schematically illustrates the data flow in conventional USB storage device utilizing conventional user mode custom drivers
  • Fig. 2 schematically illustrates a preferred embodiment of the driverless device of the invention
  • Figs. 3A and 3B illustrate a method for adding special commands according to one preferred embodiment of the invention, wherein Fig. 3A illustrates a principal structure of a special command according to the present invention, and Fig. 3B is a flowchart illustrating a possible process for accessing a storage device having processing capabilities; and
  • Figs. 4A and 4B schematically illustrate possible structures of write and read commands used in one preferred embodiment of the invention, wherein Fig. 4A illustrates write and read commands used for carrying out log-in, and Fig. 4B illustrates write and read commands used for carrying out digital signature.
  • the present invention provides driverless storage devices having processing capabilities and which is capable of communicating in user, mode over USB in high speed data communication rates without requiring a custom Kernel mode driver and no administrator privileges for user mode driver, and a method for expanding the command set of such driverless storage devices.
  • the approach of the present invention may be employed to provide driverless information security devices supported by the USB MSD class and that, are capable of supporting various security tasks, and additional functionality not covered by the USB MSD class.
  • FIG. 2 schematically illustrates a USB data storage device 20 of the invention embodying the data communication scheme of the invention.
  • Storage device 20 may be implemented substantially similar to conventional mass storage devices comprising a memory device 20r (e.g., flash memory), MCU 20m, and USB controller 13c, however, as will be explained hereinbelow, storage device 20 is further adapted to implement the data communication scheme of the invention, and optionally additional security tasks, if needed.
  • memory device 20r is partitioned into a number of LUNs, L0, LI,..., Ln, which behave and operate as regular LUNs, as in storage device 13 (shown in Fig. 1) .
  • LUN L0 one of the LUNs
  • one of the LUNs is further employed for carrying out the data communication scheme of the invention, such that it may be accessed by user mode applications 12a by means of read and write commands available in standard programming libraries compliant with the operating system 12o.
  • data stored in LUN0 is further employed for adding special commands thereby allowing support of additional functionality of device 20, said additional functionality is not supported by the standard USB device classes in which device 20 is being operated.
  • LUN1, LUN2 , or LU n any other LUN in memory 20r (e.g., LUN1, LUN2 , or LU n) may be equally used in the same manner, and that the invention may be implemented similarly in other types of storage devices having processing capabilities. Additionally or alternatively, memory 20r may be configured to include a hidden LUN(s) reserved for carrying out the invention, and is such specific embodiments the hidden LUN(s) is reserved solely for carrying out the invention i.e., it is not recognized by the operating system and may not be accessed regularly by user mode applications 12a.
  • one of the LUNs of storage device 20 is further employed for adding special commands which are used to provide support for special functions of device 20, which are not supported by the USB class device standard in which device 20 is being operated.
  • the reserved LUN L0 ' comprises two data files which will be named herein for the purpose of this example "read” file 20d (rd) and "write” file 20w (wr) .
  • Fig. 3B illustrates a preferred method of the invention for supporting special commands of device 20 the standard USB MSD protocol.
  • a standard ANSI C write command is used to demonstrate the invention scheme, however write commands in other high level programming languages may be similarly used instead.
  • user mode application 12a issues a USB write command which is transferred over data bus 14 to device 20.
  • the write command is received in device 20 and processed by MCU 20m.
  • MCU 20m is adapted to identify any write commands addressing the logic device defined for carrying out the invention, in this . example LU 0, as illustrated in step 31. If the write command is not addressing LUN0, then in step 32 the. write command is executed as any regular write command issued by a user mode application 12a.
  • Fig. 3A illustrates structure of a special write command 24 according to the invention.
  • Write command 25 is a standard SCSI write command comprising a header 26 and a data section 27.
  • a special command 28 is embedded in the data section 27 of write command 25.
  • step 34 it is checked whether the write command is a special command according to the invention. According to one preferred embodiment of the invention in step 34 it is checked whether the write command addresses the file named "write" 20w (wr) in LUN0. If the write command addresses a different file location in LUN0, then in step 35 the write command is normally executed as a regular write command.
  • step 34 If it is determined in step 34 that the write command should be handled as a special command, then in step 36 the data section (27) of the write command (25) is written into the "write" file location 20w (wr) in LUN0 and a predetermined memory location, or a range of memory locations, in the "write" file 20w (wr) are then extracted to retrieve the special command (28) embedded in the write command.
  • step 37 the validity of the extracted command is checked. If it is found that the extracted special command section (28) does not comprise a valid special command code, then an error indication is issued in step 38 and the process is terminated.
  • special command 28 may comprise code for carrying out electronic signature (e.g., RSA signature), or encryption/decryption, of data provided in the data section (27) of the SCSI write command (25) , or of any other data stored in memory 20r, or alternatively, of data to be received in device 20.
  • electronic signature e.g., RSA signature
  • encryption/decryption of data provided in the data section (27) of the SCSI write command (25) , or of any other data stored in memory 20r, or alternatively, of data to be received in device 20.
  • Special commands (28) may comprise code for reading data stored in the "read” file 20d (rd) in LUNO by user mode application 12a, and in this case process steps 30 to 41 are performed in a similar fashion wherein the execution of step 41 comprise transferring the content of "read" file 20d (rd) over bus 14. It is however assumed that the data, required by such special read commands is already contained in "read" file 20d (rd) , for example following successful execution of a previous special command. Accordingly, the needed data may be fetched by means of a regular read command addressing the "read" file.
  • any standard write command addressing the write file and incorporating a non-standard command is followed by a standard read command addressing the read file, by means of which the device transfers the data obtained from the execution of the non-standard command and/or indications related to its execution .
  • MCU 20m includes a central processing unit (cpu - not shown) and memory means (e.g., ROM, EPROM, flash, and the like - not sown) used by it to store and execute software code, algorithms, and other data.
  • MCU 20m may further comprise encryption/decryption algorithms, data, keys, software and/or hardware means allowing it to carry data encryption, to digitally sign documents and other security tasks as may be needed.
  • confidential data may be securely stored by MCU 20m in an encrypted form in any of the accessible LUNS, Ll,..., Ln. While such encrypted privileged data may be accessible by any user mode application 12a operating in PC 12 via its kernel mode drivers, in case such data is read it will not be readable since it is stored concealed in an encryption form.
  • MCU 20m fetches the data from the respective LUN, decrypts it, and stores it in the "read" file 20d in LUN L0.
  • the data may be then read by user mode applications 12a by means of a special (or regular) command comprising instructions code for transferring the content of "read" file 20d (rd) over bus 14, as described hereinabove.
  • a data communication operation is performed in a similar manner, namely, the privileged data and the special command code are embedded in the data payload (27) of a write commands (25) and when received by MCU 20m they are stored in the "write" file 20w. MCU 20m may then encrypt the data in "write" file 20w and store it in one of the accessible LUNs, LI,..., Ln.
  • Fig. 4A illustrates write 41 and read 42 commands- used for carrying out log-in.
  • Write 41 and read 42 commands are preferably implemented by means of a standard high level programming language, such as, but not limited to, ANSI C.
  • the header 41h of write command 41 is modified to indicate to the MCU that it is a special command of the invention. While this may be achieved by simply addressing the "write" file in LUNO, further indications may be included in header 41h to indicate that it requires special processing.
  • the data section 41d of write command 41 is comprised of special command 41s, user name 41u and password 41p. After the special command 41s is processed by the MCU the user name 41u and password 41p fields are extracted by the MCU and user authentication is performed. The results (login successful or failure) of which may oe stored in the "read" file in LUNG.
  • Read command 42 may be followed for reading the content of the "read” file.
  • Read command 42 may be a regular read command addressing the "read” file in LUNO, or a type of special command which header 42h may also be modified to indicate it being a special command for fetching the results of the login operation.
  • the special command 42s is executed, if so needed, which instructs the MCU to transfer the content of the "read” file to the host computer.
  • the special login command described above may be used in storage device 20 to restrict the access to certain LUNs.
  • storage device 20 may be configured to permit the access to LUN3 only to authorized users, such that any attempt of the host computer to access LUN3 utilizing standard read/write commands will be denied.
  • the access to LUN3 by the host computer is permitted only after a successful special login command 41 is performed and the user is authenticated.
  • Fig. 4B illustrates write 45 and read 46 commands used for carrying out a possible digital signature.
  • Write 45 and. read 46 commands may be also implemented by means of a standard high level programming language, such as ANSI C, for example.
  • the header 45h of write command. 45 should address the "write" file in LUNO, and it may be further modified to indicate to the MCU that it is a special command of the invention.
  • the data section 45d of write command 45 is comprised of special command 45s and the data which needs to be electronically signed 45t. After the special command 45s is processed by the MCU the data to be electronically signed 45t is extracted by the MCU and a digital signature of tne same is performed. The digital signature is then stored in the "read" file in LUNO.
  • a read command 46 may be received after write command 45 for reading the content of the "read” file.
  • Read command 46 may be a regular read command addressing the "read” file in LUNO, or a special command which header 46h may also be modified to indicate it being a special command for fetching the digital signature generated by the MCU.
  • the special command 46s is executed, which instructs the MCU to transfer the content of the "read” file in LUNO to the host computer.
  • the present invention may advantageously employed in various type of devices having processing and storage means wherein there is a need to expand the standard set of commands available by the standard protocols or device class commands in which the device is operated.
  • the invention may be used to implement information security device having one or more hidden storage areas which may be accessed by a authorized user once successful authentication is performed. Data from the hidden storage areas may be transferred by means of the special commands of the invention embedded in standard write commands, wherein after such special command the needed data is written into the read file which may be then accessed by means of a standard write command addressing the read file.
  • the device of the invention is a USB storage device designed to operate in the MSD class, which provide high read and write speed, specially in 'user mode' and when accessing hidden storage areas.

Abstract

A method for transferring non-standard commands to a device having storage and processing capabilities and that is capable of being linked to a host computer, said method comprising creating a designated file in said device, analyzing any standard write command attempting to access said designated file to determine whether it incorporates a non-standard command, and executing said non-standard command if incorporated in said standard write command. A device for carrying out said method is also disclosed.

Description

DEVICE AND METHOD FOR COMMUNICATING WITH A STORAGE DEVICE
Field of the Invention
The present invention generally relates to expanding the access to, and operations performance of a storage device, preferably a USB device, having processing capabilities over standard communication protocols.
Background of the Invention
The small computer system interface (also known as SCSI) provides a communication bus and a command set for interfacing storage and peripheral devices in computerized systems. The SCSI interface defines both a parallel I/O bus and a data protocol that can be used for connecting peripheral devices (disk drives, modems, printers, scanners, and the like) to a host computer. Although the original parallel SCSI bus is rarely used nowadays, however, the SCSI command set is widely used in computerized systems to communicate with devices over different buses.
Storage devices may be accessed for read and write operations by means of standard read and write commands available in almost any standard high level programming language (e.g., ANCI C) . Such read and write commands typically comprise a header and a data payload which may be transferred over a variety of bus types.
Fig. 1 schematically illustrates conventional data flow between a personal computer (PC) 12 and a USB (Universal Serial Bus) storage device■ 13 over data bus 14. Any communication in this system is initiated by PC 12 which sends a command to the storage device 13, which then responds. For example, whenever user mode application 12a. requires r/w access to memory 13r of storage device 13 it is carried out by means of user mode driver 12d which transfers the r/w command to the appropriate operating system (OS, 12o) driver indicating to it. the needed operation and the target device. In the OS 12o the kernel driver issues a SCSI command using the SCSI protocol 12s, said command is then encapsulated by the USB protocol 12u and sent to the target device 13 via USB controller 12c over data bus 14.
The USB command is received by USB controller 13c provided in target device 13 which decodes the SCSI command, which is then executed by means of microcontroller unit (MCU) 13m. Memory 13r (e.g., flash memory) is typically partitioned into a number of logical units (also known as LUNs - LUNO, LUNl, LUNn) L0, Ll, Ln, and the r/w command should include indications concerning the LUN number, and a range of addresses in it to be accessed. After the execution of the r/w command the target device returns a status code byte over data bus 14 to indicate successful operation or any error which may have occurred.
In this example a user mode drive 12d (custom driver) is utilized to access target device 13, but it may as well be a driverless device which can be accessed by means of the drivers of OS 12o. Driverless devices have some advantages, such as better compatibility with the operating system and thus also better stability, however the operation of such devices must fall into the predefined USB device classes provided by the USB protocols, such as for example, the human interface devices (HID) class or the mass storage devices (MSD) class. The HID class covers many types of devices and functions however it supports limited bandwidths which are often not acceptable for high speed devices. While the MSD class supports greater bandwidths it is also limited to certain types of devices and provide a limited set of commands .
Accordingly, in most cases wherein the USB device functionality requires functions not covered by the USB device classes a custom driver is required. While user mode custom drivers can be designed to provide high data transfer speeds,, they tend to be less stable and demand specific implementations tailored to suit the specific requirements of each operating system (e.g., Windows, Linux,- MAC) and so often also requirements of specific, distributions (e.g., Reahat, Mandrake, Slackware) and versions (e.g., WIN XP, vista, windows 7, windows server 2003/2008) of the operating systems.
A major difficulty associated with such custom user mode drivers concerns the permissions which may be required by the operating system for their execution. For example, in NT/W2000 OS a user application wishing to gain access to a custom USB device over the MSD class interface is required to have administrator permissions. While this requirement is made in order to enhance the security, it complicates access permission policies and may eventually cause security hazards if administrator permissions are provided to regular users in order to allow them to access a certain hardware requiring a special USB driver.
It is therefore an object of the present invention to provide a driverless storage device having processing capabilities and a method of operating it in high speed communication rates while permitting the execution of special commands by it.
It is another object of the present invention to provide a driverless information security device capable of operating in high speed communication rates.
It is a further object of the present invention to provide a method for a driver-less USB high speed communication allowing execution of special commands over standard communication protocols without requiring administrator (super user) permissions.
Other objects and advantages of the invention will become apparent as the description proceeds.
Summary of the Invention
The present invention provides method and apparatus for operating a USB device having processing capabilities utilizing the standard USB device classes with additional functionality and special commands which are not supported by the standard USB device classes. In this way the USB device of the invention may be operated utilizing the standard USB read and write commands provided in standard high level programming libraries (e.g., ANSI C) and which are compliant with any operating system (MAC, WONDO S, LINUX, UNIX,...) without requiring a special USB device driver and privileged permission, as often required for operating custom drivers. In a preferred embodiment of the invention the USB device is operated as a USB MSD class device. In general, the USB device of the invention may be a type of USB mass storage device comprising a main memory (e.g., FLASK memory) and a microcontroller unit (MCU) which is preferably adapted to provide additional functionality (e.g., encryption/decryption) not supported by the standard USB device classes. The USB device of the invention may be connected to any USB host and provide access to its main memory, as performed with standard USB MSD devices.
The main memory in the USB device is preferably partitioned into a number of logical units (LUNs), wherein one of said LUNs is designated for adding the special commands supported by the USB device. While this designated LUN may be ordinarily accessed by user mode applications, whenever it is being accessed by a write command the MCU extracts and processes the header of the write command to determine if it should be processed as a regular write command or as a special command. Preferably, this is determined according to the memory locations addressed by the write command. Most preferably, the designated LUN is configured to comprise files named "read" and "write" such that any write command which addresses the "write" file is processed by the MCU as a special write command, and similarly, any read command addressing the "read" file is processed as a special read command.
If it is determined that the issued command is a regular command, then the USB device carries it out in the standard manner, as defined in the USB protocol. If it is determined that the issued command is a special command then the MCU writes the data section of the command into the memory locations defined by the issued command and then extracts and processes the data section to determined if the issued command includes a valid special command. More particularly, whenever said "write" file is accessed, the MCU analyzes the data written in the "write" file to extract and execute a special command embedded in it, and whenever the operation of such special command produces data to be transferred to the host computer said data is written by the MCU into the "read" file, thereby allowing the host computer to fetch the produced data by means of a read command.
If there is no valid special command in the data section of the issued write command, then the MCU issues an error indication, and if a valid special command is found, then it is executed by the MCU which issues a respective acknowledge upon successful execution.
In general, the invention is thus directed to a method and device for transferring non-standard commands to an external device having storage and processing capabilities and that is capable of being linked to a host computer by means of standard, communication links (e.g., USB, serial/parallel UART, IrDA, Bluetooth, and the like) . Non-standard commands are transferred to the device by means of a designated file stored in the device which may be accessed by standard write and read commands employing standard communication protocols (e.g., SCSI). Accordingly, the device of the present invention is adapted to identify such standard write commands addressing the designated file and determine whether they incorporate a non-standard command in the data section of the standard write command. The data section may be written to the designated file, as carried out in a standard write command, but if the device identifies a non-standard command in the data section of the standard write command the non-standard command is extracted and executed. Any data and/or indications produced by execution of the non-standard command are then stored in an additional designated file in the memory of the device which may be accessed by means of standard read commands., or by means of another non-standard command, if so needed.
The terms non-standard commands and special commands used herein relate to commands and operations that are not supported by the standard communication protocol or which are not supported by the standard set of commands available for operating a certain type of device class (e.g., USB MSD class) . For example, the standard USB MSD class does not support write operations to hidden sections of the MSD device, and it does not provide suitable commands for carrying out cryptographic tasks, and it is therefore not suitable for implementing devices of the type of information security devices. The term standard command used herein relates tc commands supported by standard protocols or by standard device class used for operating the external device.
In one aspect the present invention is directed to a method for operating and managing a storage device having processing capabilities and interfacing means suitable for linking it to a computer machine, the method comprising: creating a write file in a designated logical unit in the storage device; whenever the write file is being accessed by a standard write command extracting a special command embedded in the dar.a section of the standard write command; and executing the special command. The method may comprise writing the data section of the standard write command into the write file. The method may further comprise creating a read file and storing results and/or indications related to the executed special command in the read file. The method may further comprise extracting a special command whenever the read file is being accessed by a read command from one or more fields of the read command, if needed, and transferring the results and/or indications stored in the read file over the data link.
In another aspect the present invention is directed to a storage device having processing capabilities configured to operate in a standard mode or device class while allowing it to perform special commands not supported by said standard mode or device class, the storage device comprise processing means coupled to interfacing means suitable for establishing a data link with a computer machine, and . to one or more memory means provided the storage device, wherein the storage device is adapted to create a write file in a designated logical unit in the one or more memory means and execute special commands embedded in standard write commands addressing the writs file.. The storage device may be adapted to write the data section of the standard write command in the write file. The storage device may further comprise a read file used for storing results and/or indications related to the execution of the special commands. The storage device may be further adapted to execute special commands embedded in read commands addressing the read file, if needed, and to transfer the results and/or indications stored in the read file over the data link.
The invention relates to a method for transferring non¬ standard commands to a device having storage and processing capabilities and that is capable of being linked to a host computer the method comprising creating a designated file in said device, analyzing any standard write command attempting to access said designated file to determine whether it incorporates a non-standard command, and executing said non¬ standard command, if incorporated in said standard write command. The invention further relates to a method for operating and managing a storage device having processing capabilities and interfacing means suitable for linking it to a computer machine, the method comprising: creating a write file in a designated logical unit in said storage device; whenever said write file is being accessed by a standard write command extracting a special command embedded therein and executing it.
Preferably, the method further comprises creating a read file in the device and storing results and/or indications related to the execution of the special command in said read file.
Preferably, the method further comprises whenever the read file is being accessed by a read command extracting a special command from one or more fields in said read command, if needed, and transferring the results and/or indications stored, in said read file over the data link.
Preferably, according to the method, the special command comprises a code for carrying out electronic signature.
Preferably, according to the method, the special command comprises a code for carrying out encryption/decryption of data .
The present invention relates to a device having storage and processing capabilities capable of being linked to a host computer comprising a designated file accessible for standard write commands, wherein said device is adapted to analyze any such standard write command attempting to access said designated file to determine whether it incorporates a non- standard command, and to execute said non-standard command if incorporated in said standard write command.
The present invention further relates to a storage device having processing capabilities configured to operate in a standard mode or device class while allowing it to perform special commands not supported by said standard mode or device class, comprising processing means coupled to interfacing means suitable for establishing a data link, and to one or more memory means provided therein, wherein said storage device is adapted to: create a write file in a designated logical unit in said one or more memory means and execute special commands embedded in standard write commands addressing said write file.
Preferably, the storage device further comprises a read file in the designated logical unit in said storage device wherein said storage device is further adapted to store results and/or indications related to said the execution of the special commands .
Preferably, the storage device is further adapted to transfer and execute special commands embedded in read commands addressing said read file, if needed, and to transfer data stored in the read file over the data link.
Preferably, the storage device special command comprises a code for carrying out electronic signature.
Preferably, the storage device special command comprises a code for carrying out encryption/decryption of data stored in the memory means or of data being received in the device. Brief Description of the Drawings
The present invention is illustrated by way of example in the accompanying drawings, in which similar references consistently indicate similar elements and in which:
Fig. 1 schematically illustrates the data flow in conventional USB storage device utilizing conventional user mode custom drivers; and
Fig. 2 schematically illustrates a preferred embodiment of the driverless device of the invention;
Figs. 3A and 3B illustrate a method for adding special commands according to one preferred embodiment of the invention, wherein Fig. 3A illustrates a principal structure of a special command according to the present invention, and Fig. 3B is a flowchart illustrating a possible process for accessing a storage device having processing capabilities; and
Figs. 4A and 4B schematically illustrate possible structures of write and read commands used in one preferred embodiment of the invention, wherein Fig. 4A illustrates write and read commands used for carrying out log-in, and Fig. 4B illustrates write and read commands used for carrying out digital signature.
It is noted that the embodiments exemplified in the figures are not intended to be in scale and are in diagram form to facilitate ease of understanding and description.
Detailed Description of Preferred Embodiments The present invention provides driverless storage devices having processing capabilities and which is capable of communicating in user, mode over USB in high speed data communication rates without requiring a custom Kernel mode driver and no administrator privileges for user mode driver, and a method for expanding the command set of such driverless storage devices. The approach of the present invention may be employed to provide driverless information security devices supported by the USB MSD class and that, are capable of supporting various security tasks, and additional functionality not covered by the USB MSD class.
Fig. 2 schematically illustrates a USB data storage device 20 of the invention embodying the data communication scheme of the invention. Storage device 20 may be implemented substantially similar to conventional mass storage devices comprising a memory device 20r (e.g., flash memory), MCU 20m, and USB controller 13c, however, as will be explained hereinbelow, storage device 20 is further adapted to implement the data communication scheme of the invention, and optionally additional security tasks, if needed.
As seen, memory device 20r is partitioned into a number of LUNs, L0, LI,..., Ln, which behave and operate as regular LUNs, as in storage device 13 (shown in Fig. 1) . According to the data communication approach of the invention one of the LUNs (e.g., LUN L0) is further employed for carrying out the data communication scheme of the invention, such that it may be accessed by user mode applications 12a by means of read and write commands available in standard programming libraries compliant with the operating system 12o. As will be explained below data stored in LUN0 is further employed for adding special commands thereby allowing support of additional functionality of device 20, said additional functionality is not supported by the standard USB device classes in which device 20 is being operated.
In the following discussion adding new commands to a USB device operating as a MSD class device will be exemplified using LUNO as the target logical unit . It should be however clear that any other LUN in memory 20r (e.g., LUN1, LUN2 , or LU n) may be equally used in the same manner, and that the invention may be implemented similarly in other types of storage devices having processing capabilities. Additionally or alternatively, memory 20r may be configured to include a hidden LUN(s) reserved for carrying out the invention, and is such specific embodiments the hidden LUN(s) is reserved solely for carrying out the invention i.e., it is not recognized by the operating system and may not be accessed regularly by user mode applications 12a.
In one preferred embodiment of the invention one of the LUNs of storage device 20 is further employed for adding special commands which are used to provide support for special functions of device 20, which are not supported by the USB class device standard in which device 20 is being operated. In this example the reserved LUN L0 ' comprises two data files which will be named herein for the purpose of this example "read" file 20d (rd) and "write" file 20w (wr) .
Fig. 3B illustrates a preferred method of the invention for supporting special commands of device 20 the standard USB MSD protocol. In this example a standard ANSI C write command is used to demonstrate the invention scheme, however write commands in other high level programming languages may be similarly used instead. In step 30 user mode application 12a issues a USB write command which is transferred over data bus 14 to device 20. The write command is received in device 20 and processed by MCU 20m. MCU 20m is adapted to identify any write commands addressing the logic device defined for carrying out the invention, in this . example LU 0, as illustrated in step 31. If the write command is not addressing LUN0, then in step 32 the. write command is executed as any regular write command issued by a user mode application 12a.
Fig. 3A illustrates structure of a special write command 24 according to the invention. Write command 25 is a standard SCSI write command comprising a header 26 and a data section 27. In this example a special command 28 is embedded in the data section 27 of write command 25.
If it is found in step 31 that the write command (25) addresses LUN0 then in step 33 the header section (26) of the write command is extracted, and in step 34 it is checked whether the write command is a special command according to the invention. According to one preferred embodiment of the invention in step 34 it is checked whether the write command addresses the file named "write" 20w (wr) in LUN0. If the write command addresses a different file location in LUN0, then in step 35 the write command is normally executed as a regular write command.
If it is determined in step 34 that the write command should be handled as a special command, then in step 36 the data section (27) of the write command (25) is written into the "write" file location 20w (wr) in LUN0 and a predetermined memory location, or a range of memory locations, in the "write" file 20w (wr) are then extracted to retrieve the special command (28) embedded in the write command. Next, in step 37 the validity of the extracted command is checked. If it is found that the extracted special command section (28) does not comprise a valid special command code, then an error indication is issued in step 38 and the process is terminated.
If it is found that the extracted command (28) comprises a valid special command, then in steps 39, 40 and 41, the special command is executed utilizing any additional data provided in the data section (27) of the SCSI write command (25), if such data is needed. By way of example, special command 28 may comprise code for carrying out electronic signature (e.g., RSA signature), or encryption/decryption, of data provided in the data section (27) of the SCSI write command (25) , or of any other data stored in memory 20r, or alternatively, of data to be received in device 20.
Special commands (28) may comprise code for reading data stored in the "read" file 20d (rd) in LUNO by user mode application 12a, and in this case process steps 30 to 41 are performed in a similar fashion wherein the execution of step 41 comprise transferring the content of "read" file 20d (rd) over bus 14. It is however assumed that the data, required by such special read commands is already contained in "read" file 20d (rd) , for example following successful execution of a previous special command. Accordingly, the needed data may be fetched by means of a regular read command addressing the "read" file.
According to one preferred embodiment of the invention any standard write command addressing the write file and incorporating a non-standard command is followed by a standard read command addressing the read file, by means of which the device transfers the data obtained from the execution of the non-standard command and/or indications related to its execution .
Typically, MCU 20m includes a central processing unit (cpu - not shown) and memory means (e.g., ROM, EPROM, flash, and the like - not sown) used by it to store and execute software code, algorithms, and other data. In a specific preferred embodiment of the invention MCU 20m may further comprise encryption/decryption algorithms, data, keys, software and/or hardware means allowing it to carry data encryption, to digitally sign documents and other security tasks as may be needed. In this way confidential data may be securely stored by MCU 20m in an encrypted form in any of the accessible LUNS, Ll,..., Ln. While such encrypted privileged data may be accessible by any user mode application 12a operating in PC 12 via its kernel mode drivers, in case such data is read it will not be readable since it is stored concealed in an encryption form.
However, whenever access to such privileged data is required by an authorized user following execution of a suitable special command MCU 20m fetches the data from the respective LUN, decrypts it, and stores it in the "read" file 20d in LUN L0. The data may be then read by user mode applications 12a by means of a special (or regular) command comprising instructions code for transferring the content of "read" file 20d (rd) over bus 14, as described hereinabove.
Similarly, whenever a user mode application 12a that is adapted to transfer special command codes in the SCSI data payload needs to store privileged data in storage device 20, a data communication operation is performed in a similar manner, namely, the privileged data and the special command code are embedded in the data payload (27) of a write commands (25) and when received by MCU 20m they are stored in the "write" file 20w. MCU 20m may then encrypt the data in "write" file 20w and store it in one of the accessible LUNs, LI,..., Ln.
Fig. 4A illustrates write 41 and read 42 commands- used for carrying out log-in. Write 41 and read 42 commands are preferably implemented by means of a standard high level programming language, such as, but not limited to, ANSI C. The header 41h of write command 41 is modified to indicate to the MCU that it is a special command of the invention. While this may be achieved by simply addressing the "write" file in LUNO, further indications may be included in header 41h to indicate that it requires special processing. The data section 41d of write command 41 is comprised of special command 41s, user name 41u and password 41p. After the special command 41s is processed by the MCU the user name 41u and password 41p fields are extracted by the MCU and user authentication is performed. The results (login successful or failure) of which may oe stored in the "read" file in LUNG.
After write command 41 is performed a read command 42 may be followed for reading the content of the "read" file. Read command 42 may be a regular read command addressing the "read" file in LUNO, or a type of special command which header 42h may also be modified to indicate it being a special command for fetching the results of the login operation. After the MCU processes the data section 42d the special command 42s is executed, if so needed, which instructs the MCU to transfer the content of the "read" file to the host computer.
The special login command described above may be used in storage device 20 to restrict the access to certain LUNs. For example, storage device 20 may be configured to permit the access to LUN3 only to authorized users, such that any attempt of the host computer to access LUN3 utilizing standard read/write commands will be denied. In this specific embodiment of the invention the access to LUN3 by the host computer is permitted only after a successful special login command 41 is performed and the user is authenticated.
Fig. 4B illustrates write 45 and read 46 commands used for carrying out a possible digital signature. Write 45 and. read 46 commands may be also implemented by means of a standard high level programming language, such as ANSI C, for example. The header 45h of write command. 45 should address the "write" file in LUNO, and it may be further modified to indicate to the MCU that it is a special command of the invention. The data section 45d of write command 45 is comprised of special command 45s and the data which needs to be electronically signed 45t. After the special command 45s is processed by the MCU the data to be electronically signed 45t is extracted by the MCU and a digital signature of tne same is performed. The digital signature is then stored in the "read" file in LUNO.
A read command 46 may be received after write command 45 for reading the content of the "read" file. Read command 46 may be a regular read command addressing the "read" file in LUNO, or a special command which header 46h may also be modified to indicate it being a special command for fetching the digital signature generated by the MCU. After the MCU processes the data section 46d the special command 46s is executed, which instructs the MCU to transfer the content of the "read" file in LUNO to the host computer. The present invention may advantageously employed in various type of devices having processing and storage means wherein there is a need to expand the standard set of commands available by the standard protocols or device class commands in which the device is operated. For example, the invention may be used to implement information security device having one or more hidden storage areas which may be accessed by a authorized user once successful authentication is performed. Data from the hidden storage areas may be transferred by means of the special commands of the invention embedded in standard write commands, wherein after such special command the needed data is written into the read file which may be then accessed by means of a standard write command addressing the read file.
In one specific preferred embodiment of the invention the device of the invention is a USB storage device designed to operate in the MSD class, which provide high read and write speed, specially in 'user mode' and when accessing hidden storage areas.
The above examples and description have of course been provided only for the purpose of illustration, and are not intended to limit the invention in any way. As will be appreciated by the skilled person, the invention can be carried out in a great variety of ways, employing more than one technique from those described above, all without exceeding the scope of the invention.

Claims

1. A method for transferring non-standard commands to a device haying storage and processing capabilities and that is capable of being linked to a host computer, said method comprising creating a designated file in said device, analyzing any standard write command attempting to access said designated file to determine whether it incorporates a non-standard command, and executing said non-standard command if incorporated in said standard write command.
2. A method for operating and managing a storage device having processing capabilities and interfacing means suitable for linking it to a computer machine, the method comprising: creating a write file in a designated logical unit in said storage device; whenever said write file is being accessed by a standard write command extracting a special command embedded therein and executing it.
3. A method according to claim 2 further comprising creating a read file in the device and storing results and/or indications related to the execution of the special command in said read file.
4. A method according to claim 3 further comprising whenever the read file is being accessed by a read command extracting a special command from one or more fields in said read command, if needed, and transferring the results and/or indications stored in said read file over the data link.
5. A device having storage and processing capabilities capable of being linked to a host computer comprising a designated file accessible for standard write commands, wherein said device is adapted to analyze any such standard write command attempting to access said designated file to determine whether it incorporates a non-standard command, and to execute said non-standard command if incorporated in said standard write command .
6. A storage device having processing capabilities configured to operate in a standard mode or device class while allowing it to perform special commands not supported by said standard mode or device class, comprising processing means coupled to interfacing means suitable for establishing a data link, and to one or more memory means provided therein, wherein said storage device is adapted to: create a write file in a designated logical unit in said one or more memory means and execute special commands embedded in standard write commands addressing said write file.
7. The storage device according to claim 6 further comprising a read file in the designated logical unit in said storage device wherein said storage device is further adapted to store results and/or indications related to said the execution of the special commands.
8. A storage device according to claim 7 further adapted to transfer and execute special commands embedded in read commands addressing said read file, if needed, and to transfer data stored in the read file over the data link.
9. A storage device according to claim 6 wherein the special command comprises a code for carrying out electronic signature .
10. A storage device according to claim 6 wherein the special command comprises a code for carrying out encryption/decryption of data stored in the memory means or of data being received in the device.
11. A method according to claim 2 wherein the special command comprises a code for carrying out electronic signature.
12. A method according to claim 2 wherein the special command comprises a code for carrying out encryption/decryption of
PCT/IL2011/000595 2010-07-26 2011-07-24 Device and method for communicating with a storage device WO2012014196A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US36746710P 2010-07-26 2010-07-26
US61/367,467 2010-07-26

Publications (1)

Publication Number Publication Date
WO2012014196A1 true WO2012014196A1 (en) 2012-02-02

Family

ID=45529488

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IL2011/000595 WO2012014196A1 (en) 2010-07-26 2011-07-24 Device and method for communicating with a storage device

Country Status (1)

Country Link
WO (1) WO2012014196A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10802993B2 (en) * 2018-03-23 2020-10-13 Seagate Technology Llc Driverless device configuration

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050027889A1 (en) * 2003-07-31 2005-02-03 Francisc Sandulescu USB extender
US20050207253A1 (en) * 2004-03-18 2005-09-22 Hitachi Global Storage Technologies Netherlands B.V. Storage devices and method of transferring file between the devices
US20070136501A1 (en) * 2005-12-08 2007-06-14 Chang Robert C Media card command pass through methods

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050027889A1 (en) * 2003-07-31 2005-02-03 Francisc Sandulescu USB extender
US20050207253A1 (en) * 2004-03-18 2005-09-22 Hitachi Global Storage Technologies Netherlands B.V. Storage devices and method of transferring file between the devices
US20070136501A1 (en) * 2005-12-08 2007-06-14 Chang Robert C Media card command pass through methods

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10802993B2 (en) * 2018-03-23 2020-10-13 Seagate Technology Llc Driverless device configuration

Similar Documents

Publication Publication Date Title
US8590051B2 (en) Information processing apparatus and removable media management method
US9015848B2 (en) Method for virtualizing a personal working environment and device for the same
US8230207B2 (en) System and method of providing security to an external attachment device
JP4663572B2 (en) Universal serial bus data transmission method and device implementing the method
US8255930B2 (en) Method and system for dynamically switching between different device configurations
US10073988B2 (en) Chipset and host controller with capability of disk encryption
CN107832241B (en) Integrated circuit storage device or method capable of realizing automatic operation
US9026683B1 (en) Command portal for executing non-standard storage subsystem commands
US8745277B2 (en) Command portal for securely communicating and executing non-standard storage subsystem commands
US20120124380A1 (en) Usb composite device and method therefor
US20060253620A1 (en) Data structure of flash memory having system area with variable size in which data can be updated, USB memory device having the flash memory, and method of controlling the system area
US20060064577A1 (en) BIOS locking device, computer system with a BIOS locking device and control method thereof
US8745754B2 (en) Device for secure access to digital media contents, virtual multi-interface driver and system for secure access to digital media contents
US10747884B2 (en) Techniques for coordinating device boot security
JP2005266934A (en) Usb storage device and controller therefor
US20160234185A1 (en) Storage device, information processing system, authentication method, and non-transitory computer readable medium
JP2009187547A (en) Secure direct platter access
JP4767619B2 (en) External storage device and SBC control method
EP2483800B1 (en) Method and system for supporting portable desktop with enhanced functionality
WO2012014196A1 (en) Device and method for communicating with a storage device
CN110472443A (en) A kind of local device of data security methods and belt switch
CN101770431A (en) Storage device capable of certifying and data protection method
JP2007317053A (en) Command execution method, controller for usb storage device, and usb storage device mounted with controller
KR20090009649A (en) Method and system for securing usb keyboard input data
JP2006079422A (en) Information storage device

Legal Events

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

Ref document number: 11811930

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 12/07/2013)

122 Ep: pct application non-entry in european phase

Ref document number: 11811930

Country of ref document: EP

Kind code of ref document: A1