Abstract: A Field Programmable Gate Array (FPGA) based secure Universal Serial Bus (USB) mass storage device, comprising: a USB Mass Storage (MS) device controller unit (310) configured to receive data from an external USB host (100) through a USB 2.0 PHY chip (400) and perform a plurality of USB operations on the received data; a memory controller unit (330) configured to perform memory READ and WRITE operations from and to the non-volatile memory (500); a secure unit (350) in communication with the USB MS device controller unit (310) and the memory controller unit (330), the secure unit (350) configured to perform encryption and decryption of the data received from the USB MS device controller unit (310) and the memory controller unit (330) respectively.
DESC:TECHNICAL FIELD
[0001] The present disclosure relates to the field of data processing systems and programmable electronic devices. The disclosure, more particularly, relates to system for securely storing data communicated over USB using FPGA.
BACKGROUND
[0002] A Universal Serial Bus (USB) is typically used to connect one or more peripheral devices to a computer system. The USB provides an easy and reliable connection to the peripheral devices by using a standardized connector. USB employs NRZI (Non-Return to Zero Invert) data encoding when transmitting packets. To ensure adequate signal transitions, bit stuffing is employed by the transmitting device when sending a packet on USB. A zero is inserted after every six consecutive ones in the data stream before the data is NRZI encoded. Each USB packet is a block of information with a defined format.
[0003] Initially, when a USB device is connected to a USB host, the USB device works in full speed, even if it supports the high-speed mode. After communicating a CHIRP sequence with the USB host, the device enters high-speed mode. For the USB high speed mode, the USB device sends the CHIRP K after the bus RESET by the USB host and then enters to receive the CHIRP K-J pairs. Once the device receives CHIRP K-J pairs, it enters the high-speed mode else continues in the full speed mode. After the speed mode selection, the USB host starts enumerating the device.
[0004] USB specification supports four types of data transfers: control, bulk, isochronous and interrupt transfers. For any data transfer between the USB host and the USB device, the communication has to be initiated by the host only. Control transfers enable the host to learn about a device, set a device’s address, and select configuration and other settings. Control transfers can also send vendor specific requests that transfer data for any purpose. All USB devices must support the control transfers. A control transfer has two or three transactions viz. setup, data, and status. In the setup transaction, the host sends the request. In the data transaction, the host or device sends data. Some requests do not have a data transaction. In the status transaction, the receiver of data in the data transaction returns status information. Each transaction contains a token packet, a data packet, and a handshake packet. Each packet begins with a packet ID (PID). The token packet contains the device address and the endpoint number. The token packet’s PID identifies the packet as one of these types: SETUP, OUT, IN or SOF. The data packet contains any data that the host or device is sending in the transaction. The handshake packet is sent by the receiver of the data packet. The PID contains a code to indicate whether the data was received without error such as ACK, NACK or STALL.
[0005] In addition to the control transfers, USB mass storage devices support bulk transfers. In bulk transfers only or mass storage transfer/transport protocol, a successful communication has two or three phases: command transport, data transport and status transport. In command transport phase, the host sends a command block in a structure called command block wrapper (CBW). In data transport phase, the host or device sends the data. Some commands do not have a data transport phase. In the status transport phase, the device sends status information in as structure called a command status wrapper (CSW). When reading or writing blocks of data, the host identifies the locations to read or write to by specifying a logical block address (LBA).
[0006] WO2013/114398A2 titled ‘FPGA system for USB bridge implementation’ describes an FPGA based USB bridge implementation for communication of data between a USB host and a USB mass storage device, which overcomes drawbacks known in the art including lack of security due to software-based encryption implementation and driver and OS dependency.
[0007] US8135880B2 titled ‘USB mass storage locking’ describes a USB mass storage device comprising a USB interface, a locking function coupled to the USB interface wherein locking function is accessible via a USB device class other than a mass storage class, and a data mass storage memory coupled to the locking circuit. This invention used mass storage controller chip to implement USB bridge, locking function and memory accessing.
[0008] US9104384B2 titled ‘Portable mass storage device’ describes a new type of portable USB mass storage device which provides the user with upgradeable high speed mass storage and processing for use with portable computer appliances such as smart phones and tablets as well as standard desktop computers and laptops.
[0009] US20070239990A1 titled ‘Secure mass storage device’ describes a USB mass storage device including a memory, USB interface and USB mass storage controller chip. A biometric circuit provides biometric authentication, and a secure micro controller is operatively connected to the biometric circuit and the USB controller, and is operative in accordance as a trusted platform and having a command set to access security functions and trust authentication of a user using the biometric circuit.
[0010] WO2012/150267A1 titled ‘Data communication via USB mass storage interface’ describes a system for continuously transmitting data between a terminal and a computer. The system comprises the following: a USB bus; a terminal which continuously generates data during operation and which continuously makes said data available on a USB bus in accordance with the USB mass storage class standard; and a computer which is connected to the USB bus, which comprises a USB device driver that operates in accordance with the USB mass storage class standard, and which comprises an application program designed to receive the data that is continuously generated by the measuring device from the USB bus using the device driver.
[0011] However, the implementation of USB mass storage device in FPGA based designs has following constrains: requirement of separate USB mass storage controller chips, which increases the cost and area of the design; complex and custom encryption algorithms which are difficult to implement in USB mass storage controller chips, resulting in weakness of encryption algorithms; when combined with authentication with the USB host, robust and custom authentication modules/units are difficult to implement in USB
[0012] Therefore, there is still a need for a system/device for securely storing data communicated over USB using FPGA.
SUMMARY
[0013] This summary is provided to introduce concepts of the invention related to a FPGA based secure USB mass storage device, as disclosed herein. This summary is neither intended to identify essential features of the invention as per the present invention nor is it intended for use in determining or limiting the scope of the invention as per the present invention.
[0014] In accordance with an embodiment of the present invention, there is provided a Field Programmable Gate Array (FPGA) based secure Universal Serial Bus (USB) mass storage device. The device comprises a USB Mass Storage (MS) device controller unit configured to receive data from an external USB host through a USB 2.0 PHY chip and perform a plurality of USB operations on the received data; a memory controller unit in communication with a non-volatile memory, the memory controller unit configured to perform memory READ and WRITE operations from and to the non-volatile memory; a secure unit in communication with the USB MS device controller unit and the memory controller unit, the secure unit configured to perform encryption and decryption of the data received from the USB MS device controller unit and the memory controller unit respectively.
[0015] In an aspect, the FPGA based secure USB mass storage device comprises a RESET unit configured to initialize the USB Mass Storage (MS) device controller unit; a RX unit configured to receive the data from the external USB host and perform a plurality of operations on the received data, selected from SYNC detection, NRZI decoding, bit stuff removal, End of Packet (EOP) detection and byte formation; a RX PKT Handler in communication with the RX unit and configured to perform Cyclic Redundancy Check (CRC)- 5 or CRC-16 verification on the data received from the RX unit; a TRANSACTION Handler in communication with the RX PKT Handler and configured to perform transaction processing on data received from the RX PKT Handler; a control transfer Handler in communication with the TRANSACTION Handler and configured to decode data received from the TRANSACTION Handler and in response transmit control data of the device to the TRANSACTION Handler; a BULK/MS Transfer Handler in communication with the TRANSACTION Handler and configured to decode data received from the TRANSACTION Handler and in response transmit storage data of the device to the TRANSACTION Handler; a TX PKT Handler in communication with the TRANSACTION Handler and configured to perform the CRC-5 and CRC-16 verification on the data received from the TRANSACTION Handler; and a TX unit in communication with the TX PKT Handler and configured to perform a plurality of operations on the received data, selected from SYNC addition, bit stuffing, NRZI encoding and byte to bit conversion.
[0016] In an aspect, the RX PKT Handler is configured to perform Cyclic Redundancy Check (CRC)-5 or CRC-16 based on the type of data received from the RX unit; forward data to the TRANSACTION handler if CRC is verified; or discard data if CRC value is not verified.
[0017] In an aspect, the TRANSACTION handler is configured to perform the transaction processing if the CRC is verified.
[0018] In an aspect, the TRANSACTION handler is configured to wait until a timeout value is reached for receiving the control data from the Control Transfer Handler or storage data from the BULK/MS transfer handler.
[0019] In an aspect, the memory controller unit is configured to operate in an initialization mode and a data transfer mode. The memory controller unit comprises a clock generation unit configured to generate a low frequency clock in the initialization mode and a high frequency clock in the data transfer mode; a device identification unit in communication with the clock generation unit and configured to perform the initialization and identification of the non-volatile memory and setting of the operation modes; a command handler unit in communication with the device identification unit and configured to perform CRC generation, CRC verification, transmission and reception of the control data to and from the non-volatile memory, based on the operation mode set by the device identification unit; a data handler unit in communication with the clock generation unit and the command handler unit and configured to receive data from the BULK/MS Transfer Handler through the secure unit to perform Bulk data WRITE and READ operations to and from the non-volatile memory; a TX CMD unit in communication with the command handler unit and configured to receive control data from the command handler unit, perform parallel data to serial data conversion on the received control data, and transmit the control data to the non-volatile memory, a RX CMD unit in communication with the command handler unit and configured to receive data from the non-volatile memory in response to the transmitted control data, perform serial data to parallel data conversion on the received data, and transmit the received data to the command handler unit for CRC verification, a CMD INOUT unit in communication with TX CMD unit and the RX CMD unit and configured to transmit and receive the data to and from the non-volatile memory; a TX DATA unit in communication with the data handler unit and configured to receive the data from the data handler unit, perform the CRC generation and append start and stop bits to the received data from the data handler unit, and transmit the data to the non-volatile memory, a RX DATA unit in communication with the data handler unit and configured to receive the data from the non-volatile memory, perform CRC verification on the received data from the non-volatile memory, and forward the data to the data handler unit if CRC verification is successful; a DATA INOUT unit in communication with TX DATA unit and the RX DATA unit and configured to transmit and receive the data to and from the non-volatile memory.
[0020] In an aspect, the data handler unit is configured to receive a READ request from the BULK/MS transfer handler; send the READ request to the non-volatile memory through the command handler unit; and read data from the non-volatile memory through the DATA INOUT unit and the RXDATA unit, if a READ ready response is received from the non-volatile memory.
[0021] In an aspect, the data handler unit is configured to receive a WRITE request from the BULK/MS transfer handler; send the WRITE request to the non-volatile memory through the command handler unit; and write data to the non-volatile memory through the DATA INOUT unit and the TX data unit, if a WRITE ready response is received from the non-volatile memory.
[0022] In an aspect, a plurality of USB operations includes PHY operations and the USB Full speed (12Mbps) and Low speed (1.5Mbps) PHY operations are implemented in FPGA and without the USB 2.0 PHY chip and wherein, the USB Mass Storage (MS) device controller unit receives data from an external USB host directly.
[0023] In an aspect, after the FPGA booting, the FPGA based secure USB mass storage device is disconnected and reconnected by sending '0' on a USB_D+ and '0' on a USB_D- for 500ms and thereafter sending '1' on the USB_D+ and '0' on the USB_D-.
[0024] In accordance with another embodiment of the present invention, there is provided a method for storing data communicated over USB using FPGA. The method comprises: a USB Mass Storage (MS) device controller unit in communication with a secure unit; a memory controller unit in communication with a non-volatile memory, and the secure unit, the method comprising: receiving, by the USB Mass Storage (MS) device controller unit, data from an external USB host, performing, by the USB Mass Storage (MS) device controller unit, a plurality of USB operations on the received data, performing, by the memory controller unit, READ and WRITE operations from and to a non-volatile memory, and performing, by the secure unit, encryption and decryption of the data received from the USB MS device controller unit and the memory controller unit respectively.
BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS
[0025] The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and modules/units.
[0026] Figure 1 illustrates a block diagram of an FPGA based secure USB mass storage device, supporting USB high speed, full speed and low speed modes, according to an exemplary implementation of the present invention.
[0027] Figure 2 illustrates a block diagram an FPGA based secure USB mass storage device, supporting USB full speed and low speed modes without requiring USB PHY chip, in accordance with an exemplary implementation of the present invention.
[0028] Figure 3 illustrates a block diagram of a USB mass storage device controller unit performing USB PHY functionalities/operations, packet formation & CRC verification, enumeration and bulk/mass storage transfer processing, in accordance with an exemplary implementation of the present invention.
[0029] Figure 4 illustrates a block diagram of a memory controller performing memory identification, logical block address processing, and data write and read operations, in accordance with an exemplary implementation of the present invention.
[0030] Figure 5 illustrates a media structure module/unit with single partitioning, in accordance with an exemplary implementation of the present invention.
[0031] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative methods embodying the principles of the present invention. Similarly, it will be appreciated that any flow charts, flow diagrams, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.
DETAILED DESCRIPTION
[0032] The various embodiments of the present disclosure describe about an FPGA based USB mass storage device. The embodiments, more particularly, describe implementation of USB mass storage device in an FPGA, implementation of complex and custom encryption and decryption techniques by use of programmable logic in the FPGA, implementation of robust authentication techniques in the FPGA, and implementation of USB full speed (12Mbps) PHY functionality in the FPGA without using any external USB PHY chip.
[0033] In the following description, for purpose of explanation, specific details are set forth in order to provide an understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these details. One skilled in the art will recognize that embodiments of the present invention, some of which are described below, may be incorporated into a number of systems.
[0034] However, the systems and methods are not limited to the specific embodiments described herein. Further, structures and devices shown in the figures are illustrative of exemplary embodiments of the present invention and are meant to avoid obscuring of the present invention.
[0035] It should be noted that the description merely illustrates the principles of the present invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described herein, embody the principles of the present invention. Furthermore, all examples recited herein are principally intended expressly to be only for explanatory purposes to help the reader in understanding the principles of the invention and the concepts contributed by the inventor to furthering the art and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass equivalents thereof.
[0036] Typically, FPGA based designs have multiple interfaces/functionalities including, but not limited to, data processing, signal processing, protocol implementations etc. The present invention is related to the USB mass storage device implementation, and therefore for the sake of brevity other functionalities/interfaces are excluded from the accompanying drawings.
[0037] A Field Programmable Gate Array (FPGA) based secure USB mass storage device described in the present invention provides a novel approach for implementation of USB mass storage device in FPGA. The FPGA based hardware design comprises an FPGA, a USB 2.0 PHY chip, and a non-volatile memory (eMMC flash). The FPGA based USB mass storage device connects to external USB host (PC) through a standard USB connector.
[0038] The external USB host device (100) send the enumeration requests to the FPGA device to decode what type of device is connected. Further, the FPGA device decodes the enumeration requests and sends the reply to the host device (100). USB host device enumerates the memory capacity of the non-volatile memory (500) connected to the FPGA device. After this, file operations are started.
[0039] The FPGA device comprises a USB mass storage (MS) device controller module/unit, a memory controller module/unit, a secure module/unit, and a media structure module/unit. The USB MS device controller unit handles all the USB related functionalities/operations such as PHY functionalities/operations, USB reset, packet formation, CRC generation & verification, device enumeration, bulk only/mass storage command processing and transmits/receives data to/from the secure unit.
[0040] The secure unit performs encryption on data received from the USB MS device controller unit and transmits the encrypted data to the memory controller unit and performs decryption on the data received from the memory controller unit and transmits the decrypted data to the USB MS device controller unit.
[0041] The memory controller unit performs memory initialization, device identification, logical block address processing and memory write and read operations. The memory controller unit receives data from a BULK/MS transfer handler through the secure unit and writes data to a non-volatile memory. The memory controller transmits the read data from the non-volatile memory to the BULK/MS transfer handler through the secure unit. In addition, the memory controller performs media structure write operation to the memory during factory-programming.
[0042] In an embodiment, the USB mass storage (MS) device controller unit comprises a RESET module/unit that performs USB high speed initialization and handles the reset sequence; an RX module/unit that performs SYNC detection, NRZI decoding, bit stuff removal, end-of-packet (EOP) detection and byte formation; an RX PKT handler that performs 5 bit CRC and 16 bit CRC verification; a Transaction handler that performs the transaction processing and responds to the USB host; a control transfer handler that handles the device control information; a bulk/MS transfer handler that performs the bulk only/mass storage operations; a TX PKT handler that performs the 5 bit CRC and 16 bit CRC generation; and a TX module/unit that performs SYNC addition, bit stuffing and NRZI encoding and byte to bit conversion.
[0043] In an embodiment, the memory controller comprises a clock generation module/unit that generates clock based on an operating mode; a device identification module/unit that performs initialization of the memory and setting of the operation mode(s); a command handler module/unit that performs CRC generation, CRC verification, frame formation and decoding of response frames from the memory; and a data handler module/unit that performs bulk data write and read operations to and from the memory.
[0044] In an embodiment, USB full speed (12Mbps) and low speed (1.5Mbps) PHY functionalities/operations are implemented in the FPGA without requiring any external USB PHY chip.
[0045] In an embodiment, after the FPGA booting, the device is disconnected and reconnected by sending ‘0’ on USB_D+ and ‘0’ on USB_D- for 500ms and then ‘1’ on USB_D+ and ‘0’ on USB_D- to eliminate the larger FPGA booting time issues.
[0046] In an embodiment, data stored in the memory is encrypted to avoid memory tampering, applicable when the authentication is enabled in the USB mass storage device.
[0047] Figure 1 illustrates a block diagram of an FPGA based secure USB mass storage device configured to support USB high speed, full speed, and low speed modes, according to an exemplary implementation of the present invention. The FPGA based secure USB mass storage device (200) comprises an FPGA (300), a USB 2.0 PHY chip (400), and a non-volatile memory (eMMC flash) (500). The FPGA based USB mass storage device (200) is connected to an external USB host (PC) (100) through a standard USB connector. The FPGA (300) comprises a USB mass storage (MS) device controller module/unit (310), a memory controller module/unit (330), a secure module/unit (350) and a media structure module/unit (370). The USB MS device controller unit (310) is configured to handle all the USB related functionalities/operations such as USB PHY functionalities/operations, USB reset, data packet formation, CRC generation and CRC verification, device enumeration, and mass storage SCSI command processing.
[0048] Further, the USB MS device controller unit (310) is in communication with the secure unit (350) and can transmit or receive the data to or from the secure unit (350). The secure unit (350) is in communication with the memory controller unit (330) and is configured to perform encryption on the data received from the USB MS device controller unit (310) and transmit the encrypted data to the memory controller unit (330). Furthermore, the secure unit (350) is configured to perform decryption on the data received from the memory controller unit (330) and transmit the decrypted data to the USB MS device controller unit (310). In an example, when a WRITE operation is requested from the external USB host (PC) (100), the secure unit (350) receives the data from the USB MS device controller unit (310), performs encryption on the received data and transmits the encrypted data to the memory controller unit (330). The encrypted data is then written to the non-volatile memory (500). In another example, when a READ operation is requested from the external USB host (PC) (100), the secure unit (350) receives the data from the non-volatile memory (500) through the memory controller unit (330), performs decryption on the received data and transmits the decrypted data to the USB MS device controller unit (310).
[0049] The memory controller unit (330) performs memory initialization, device identification, logical block address processing and memory WRITE and READ operations. In an example, the memory controller unit (330) identifies the type of non-volatile memory (500) connected to the FPGA device. In another example, the memory controller unit (330) uses logical block address processing to specify the location of blocks of data stored on the non-volatile memory (500).
[0050] Furthermore, a media structure unit (370) is in communication with the memory controller unit (330) and is configured to partition the non-volatile memory (500) into a logical file format. For example, the media structure unit splits the non-volatile memory (500) into several logical regions, so that they can be managed separately like separate storage devices.
[0051] Figure 2 illustrates a block diagram of an FPGA based secure USB mass storage device, supporting USB full speed and low speed modes without requiring any external USB PHY chip, in accordance with another exemplary implementation of the present invention. The FPGA based secure USB mass storage device (200) comprises an FPGA (300) and a non-volatile memory (eMMC flash) (500). The FPGA based USB mass storage device (200) is connected to an external USB host (PC) (100) through a standard USB connector and comprises a USB mass storage (MS) device controller module/unit (310), a memory controller module/unit (330), a secure module/unit (350) and a media structure module/unit (370). Further, the FPGA based secure USB mass storage device (200) for USB full speed and low speed modes does not require any external USB PHY chip, as USB PHY functionalities/operations are implemented within the FPGA (300). This implementation of PHY in the FPGA (300) saves the area and cost.
[0052] Figure 3 illustrates a USB MS device controller unit (310) in accordance with an exemplary implementation of the present invention. The USB MS device controller unit (310) comprises a RESET module/unit (311), a RX module/unit (312), a TX module/unit (318), an RX PKT Handler (313), a TX PKT Handler (317), a Transaction Handler (314), a Control transfer handler (315), and a BULK/MS transfer handler (316). The RESET unit (311) is configured to initialize the USB MS device controller unit (310). In an example, the RESET unit (311) is configured to handle all the initialization and resetting of sub-units present in the USB MS device controller unit (310).
[0053] In addition to this, for FPGA based designs, the time required to boot the FPGA depends on the type of booting mode used such as active booting or passive booting. When the board is powered on with the USB cable connected to the USB host (PC) (100), due to pull up resistor on USB_D+ line of the device, the USB host tries to enumerate the device. Since the FPGA booting is still not completed, the device will not respond, and the USB host keep on trying till the timeout occurs. For large FPGA bit streams and for passive booting modes, the booting time will be more than the USB host timeout value, so the device enumeration fails. To avoid this problem, once the FPGA booting is completed, the RESET unit (311) drives '0' on USB_D+ line for 500ms and release to its actual value '1'. Driving '0' and then '1' on USB_D+ line is the case similar to USB disconnected and reconnected and the USB host starts to enumerate the device again and the device responds to the USB host queries. For the USB High speed mode, the RESET unit (311) sends the CHIRP K after the bus RESET by the USB host and then enters to receive the CHIRP K-J pairs. Once the device receives CHIRP K-J pairs, it enters the high-speed mode else continues in the full speed mode. For the Figure 2, the RESET unit does not initiate the CHIRP K and continues to be in full speed mode.
[0054] The RX unit (312) is configured to receive data from an external USB host (PC) (100) and perform one or more operations on the received data. In an example, the RX unit (312) receives data in bits from the external USB host (PC) (100) and performs SYNC detection, NRZI (Non-return-to-zero decoding, bit stuff removal, end-of-packet (EOP) detection and byte formation on the received data bits. Further, the RX unit (312) which is in communication with the RX PKT handler (313) outputs the data in bytes on DATAOUT bus with the RXACTIVE, RXVALID and RXERROR signals. In an example, the RXACTIVE signal indicates that the SYNC pattern is detected, and the bit reception has started. In another example, the RXVALID signal indicates that the byte present on RXDATA bus is valid. In yet another example, the RXERROR indicates error (SYNC error, bit stuff error and byte error) present on the received data from the RX unit (312) and the RXSTATUS signals indicates the status or result of the CRC verification.
[0055] The RX PKT handler (313) is in communication with the RX unit (312) to receive data in bytes from the RX unit (312) and compute the cyclic redundancy check CRC (5 bit or 16 bit) on the received data (i.e., data bytes) depending on the type of data packet received. In an example, the RX PKT handler (313) may receive data as token packets such as from the RX unit (312) and may perform 5-bit CRC verification to check the integrity of the received token packets. In another example, the RX PKT handler (313) may receive data/packets from the RX unit (312) and may perform 16-bit CRC verification to check the integrity of the received data packets.
[0056] Further, the RX PKT handler (313) forwards the data to the Transaction handler (314), if the CRC verification is successful else the data is discarded. For example, If the RX PKT handler (313) receives a RXERROR signal from the RX unit (312), then the data/ packet is discarded by the RX PKT handler (313) else the data is forwarded to the Transaction handler (314) for further transaction processing.
[0057] Further, the RX PKT handler (313) outputs RXDATA bus with RXACTIVE, RXVALID and RXSTATUS signals. The RXSTATUS signal indicates the status of the CRC verification.
[0058] The TX PKT handler (317) is in communication with a TX unit (318) and a Transaction handler (314) to receive data from the Transaction handler (314) and performs CRC verification on the received data. After CRC verification, the TX PKT handler (317) outputs the data in data bytes on TXDATA bus to the TX unit (318) and sends an indication to the TX unit (318) with a TXACTIVE signal. The TX unit (318) receives the data byte along with the TXACTIVE signal and then requests the TX PKT handler (317) for the next data byte by sending TXREADY signal to the TX PKT handler (317).
[0059] The TX unit (318) in communication with the external USB host (PC) (100) performs one or more operations on the data received from the TX PKT handler (317). For example, the TX unit (318) may receive data in data bytes from the TX PKT handler (317) and may perform SYNC addition, bit stuffing, NRZI encoding and byte to bit conversion. The TX unit (318) receives the data on TXDATA bus along with TXACTIVE signal and request for the next byte by sending TXREADY signal to the TX PKT handler (317).
[0060] The Transaction handler (314) receives the data from the RX PKT handler (313) and processes only if RXSTATUS signal received from the RX PKT handler (313) is high. The Transaction handler (314) can generate transactions based on the token packets such as SET UP, OUT, and IN received from the external USB host (PC) (100) and transmits Acknowledgement (ACK) or Negative-acknowledgement (NACK) signals to the external USB host (PC) (100). In an example, if the Transaction handler (314) receives a SETUP token from the external USB host (PC) (100), then the Transaction handler (314) transmits data to a control transfer handler (315). The SETUP token starts the control transfer, and the control transfer handler (315) sends ACK or NACK signal to the external USB host (PC) (100) depending on whether data is received or not by the control transfer handler (315).
[0061] In yet another example, if the Transaction handler (314) receives an OUT token from the external USB host (PC) (100), then the Transaction handler (314) transmits the data either to the control transfer handler (315) or the BULK/MS transfer handler (316) and sends ACK to the external USB host (PC) (100). The ‘OUT’ token packet notifies the FPGA based secure USB mass storage device (200) that the external USB host (PC) (100) wants to perform a WRITE operation.
[0062] The control transfer handler (315) in communication with a Transaction handler (314) receives the data from the Transaction handler (314), when a WRITE operation is performed by the external USB host (PC) (100). The control transfer handler (315) decodes the request and transmits the device specific control information/data such as device description, configuration description, endpoint description and mass storage device information to the external USB host (PC) (100).
[0063] In another example, if the Transaction handler (314) receives an IN token from the external USB host (PC) (100), then the Transaction handler (314) waits for the control data from the control transfer handler (315) or storage data from a BULK/MS transfer handler (316) until a timeout value is reached. The ‘IN’ token packet notifies the FPGA based secure USB mass storage device (200) that the external host device (PC) (100) wants to perform a READ operation. Once all device specific control information is received by the USB host, it requests for the mass storage related SCSI commands.
[0064] The BULK/MS transfer handler (316) handles all the BULK only/mass storage related information such as type of mass storage device, capacity of mass storage device, number of blocks supported, sector size, logical block address (LBA) supported and the media structure information. The BULK/MS transfer handler (316) receives data from the Transaction handler (314) in a structure called command block. The bulk/MS transfer handler (316) decodes the command block using a command block wrapper (CBW). A command data wrapper (CDW) responds with the specific storage information or data requested to the USB host or receives the data from the USB host. The device completes the specific mass storage request in the status transport phase using a command status wrapper (CSW). If any WRITE or READ request is received from the USB host, the CBW decodes the LBA requested and sends the decoded LBA to the memory controller (330) along with WRITE or READ operation.
[0065] Figure 4 illustrates a Memory controller unit (330) in accordance with an exemplary implementation of the present invention. The Memory controller unit (330) performs the memory identification & initialization, logical block address processing, data WRITE and READ operations. The Memory controller unit (330) comprises a device identification module/unit (332), a data handler module/unit (337), a command handler module/unit (333), a TX DATA module/unit (338), an RX DATA module/unit (339), and DATA INOUT module/unit (340), a TX CMD module/unit (334), an RX CMD module/unit (335), a CMD INOUT module/unit (336) and a clock generation module/unit (330).
[0066] The Memory controller unit (330) is in communication with a non-volatile memory (500) and is configured to perform READ and WRITE operations from and to the non-volatile memory (500). In an example, the memory controller unit (330) receives data from the BULK/MS transfer handler (316) through the secure unit (350) and writes data to the non-volatile memory (500). In another example, the memory controller unit (330) transmits the READ data from the non-volatile memory (500) to the BULK/MS transfer handler (316) through the secure unit (350).
[0067] Further, the memory controller unit (330) is configured to operate in an initialization mode and a data transfer mode. The clock generation unit (331) generates a low frequency clock in the initialization mode and a high frequency clock in the data transfer mode.
[0068] The device identification unit (332) is in communication with the clock generation unit (331) and is configured to perform the initialization and identification of the non-volatile memory (500) and setting of the operation modes of the non-volatile memory (500).
[0069] The device identification unit (332) initially operates in a low frequency mode and after setting the timing selection register, enters a high frequency mode. The device identification unit (332) reads the device identification number, sets the relative device address to the memory, and reads the device specific data. After this it enables the high frequency mode, sets the power class, and selects the bus width and enters the data transfer mode. The clock generation unit (331) generates a high frequency clock after the device identification is completed and the non-volatile memory (500) switches to the high-speed mode.
[0070] The command handler unit (333) reads the memory address register to READ or WRITE from the device identification unit (332) and calculates the CRC and appends the start and end bit and transmits to the TX CMD unit (334). The TX CMD unit (334) converts the parallel data to serial data and a CMD INOUT unit (336) transmits the data to the non-volatile memory (500). When the non-volatile memory (500) replies with the command response, the CMD INOUT unit (336) receives the data and forwards the data to the RXCMD unit (335), which performs the serial to parallel conversion and transmits the parallel data to the command handler unit (333). The CMD INOUT unit (336) is a tri-state buffer controlled by the command handler unit (333).
[0071] The command handler unit (333) performs the CRC verification and forwards the response to the device identification unit (332). After the completion of device identification and initialization, the device identification unit (332) enters the data transfer mode and initiates a data handler unit (337).
[0072] The data handler unit (337) in communication with the command handler unit (333) performs memory READ and WRITE operations from the requests received from the BULK/MS transfer handler (316). When a READ request is received, the data handler unit (337) sends a READ request command through the command handler unit (333). The non-volatile memory (500) sends a reply with a READ ready response after which the data handler unit (337) reads the data from the non-volatile memory (500) through the DATA INOUT unit (340) and the RXDATA unit (339). The RXDATA unit (339) performs the CRC verification and if the CRC value is validated, then the RXDATA unit (339) forwards the data to the data handler unit (337). The received data is then forwarded to the BULK/MS transfer handler (316) through the secure unit (350).
[0073] Similarly, when a WRITE request along with the data is received from the BULK/MS transfer handler (316), the data handler unit (337) sends a WRITE request command through the command handler unit (333). The data handler unit (337) sends the data to the TXDATA unit (338) after it gets a WRITE READY response from the non-volatile memory (500).
[0074] The TXDATA unit (338) performs the CRC verification and appends the start, stop bits along with the CRC value to the data received from the data handler unit (337) and transmits the data to the non-volatile memory (500) through the DATA INOUT unit (340). The data handler unit (337) may send busy signal to the BULK/MS transfer handler (316) during the non-volatile memory (500) programming/writing or reading operation to indicate that the busy operation in the non-volatile memory (500).
[0075] Figure 5 illustrates a media structure unit (370) configured to partition the non-volatile memory (500) into a logical file format. The partitioning of the non-volatile memory (500) into the logical blocks is required by the USB host operating system (OS) to represent a particular file system. Figure 5 represents the FAT32 file system memory splitting. The first sector, a master boot record (371) contains the information about the partition or volume. The present invention uses a single partition or volume of the non-volatile memory (500). The volume begins with a boot sector (372) that contains information specific to the volumes file system. It expands to multiple sectors. The volume then contains a FAT32 (373) region that holds the record of sectors used by files and then a FAT32 copy (374) to hold the copy of FAT32. And the volume contains a plurality of data clusters (375) that stores the file & directory data region and the data clusters. The media structure unit (370) writes this data to the non-volatile memory (500) using the memory controller unit (330) at the time of factory programming.
[0076] Since the implementation of encryption is in the FPGA, very complex and custom encryption engines can be developed easily. Also, when authentication is enabled, the FPGA based mass storage devices attach with the authenticated USB hosts only. This will solve the problem of memory tampering since the data is encrypted and stored in the flash memory.
[0077] Thus, at least some of the technical advantages provided by the FPGA based USB mass storage device in accordance with the present invention include: support to USB hi-speed (480Mbps), USB full speed (12Mbps) and USB low speed (1.5Mbps) modes, implementation of USB full speed and low speed physical layer functionalities in the FPGA, thus eliminating the external USB PHY chip; providing security to data stored in the USB mass storage device; and implementation of the complex encryption and authentication techniques in the FPGA without degrading the USB performance.
[0078] The foregoing description has been set merely to illustrate the invention and is not intended to be limiting. Since modifications of the disclosed embodiments incorporating the substance of the invention may occur to person skilled in the art, the invention should be construed to include everything within the scope of the invention.
,CLAIMS:
1. A Field Programmable Gate Array (FPGA) based secure Universal Serial Bus (USB) mass storage device, the device comprising:
a USB Mass Storage (MS) device controller unit (310) configured to receive data from an external USB host (100) through a USB 2.0 PHY chip (400) and perform a plurality of USB operations on the received data;
a memory controller unit (330) in communication with a non-volatile memory (500), the memory controller unit (330) configured to perform memory READ and WRITE operations from and to the non-volatile memory (500);
a secure unit (350) in communication with the USB MS device controller unit (310) and the memory controller unit (330), the secure unit (350) configured to perform encryption and decryption of the data received from the USB MS device controller unit (310) and the memory controller unit (330) respectively.
2. The FPGA based secure USB mass storage device as claimed in claim 1, wherein the USB MS device controller unit (310) comprises:
a RESET unit (311) configured to initialize the USB Mass Storage (MS) device controller unit (310);
a RX unit (312) configured to receive the data from the external USB host (100) and perform a plurality of operations on the received data, selected from SYNC detection, NRZI decoding, bit stuff removal, End of Packet (EOP) detection and byte formation;
a RX PKT Handler (313) in communication with the RX unit (312) and configured to perform Cyclic Redundancy Check (CRC)- 5 or CRC 16 verification on the data received from the RX unit (312);
a TRANSACTION Handler (314) in communication with the RX PKT Handler (313) and configured to perform transaction processing on data received from the RX PKT Handler (313);
a control transfer Handler (315) in communication with the TRANSACTION Handler (314) and configured to decode data received from the TRANSACTION Handler (314) and in response transmit control data of the device (300) to the TRANSACTION Handler (314);
a BULK/MS Transfer Handler (316) in communication with the TRANSACTION Handler (314) and configured to decode data received from the TRANSACTION Handler (314) and in response transmit storage data of the device (300) to the TRANSACTION Handler (314);
a TX PKT Handler (317) in communication with the TRANSACTION Handler (314) and configured to perform the CRC-5 and CRC-16 verification on the data received from the TRANSACTION Handler (314); and
a TX unit (318) in communication with the TX PKT Handler (317) and configured to perform a plurality of operations on the received data, selected from SYNC addition, bit stuffing, NRZI encoding and byte to bit conversion.
3. The FPGA based secure USB mass storage device as claimed in claim 1 or 2, wherein the RX PKT Handler (313) is configured to:
perform Cyclic Redundancy Check (CRC) 5 or CRC 16 based on the type of data received from the RX unit (312);
forward data to the TRANSACTION handler (314) if CRC is verified; or discard data if CRC value is not verified.
4. The FPGA based secure USB mass storage device as claimed any one of claims 1 to 3, wherein the TRANSACTION handler (314) is configured to perform the transaction processing if the CRC is verified.
5. The FPGA based secure USB mass storage device as claimed in claim 2, wherein the TRANSACTION handler (314) is configured to wait until a timeout value is reached for receiving the control data from the Control Transfer Handler (315) or storage data from the BULK/MS transfer handler (316).
6. The FPGA based secure USB mass storage device as claimed in claim 1 or 2, wherein the memory controller unit (330) is configured to operate in an initialization mode and a data transfer mode, the memory controller unit (330) comprises:
a clock generation unit (331) configured to generate a low frequency clock in the initialization mode and a high frequency clock in the data transfer mode;
a device identification unit (332) in communication with the clock generation unit (331) and configured to perform the initialization and identification of the non-volatile memory (500) and setting of the operation modes;
a command handler unit (333) in communication with the device identification unit (332) and configured to perform CRC generation, CRC verification, transmission and reception of the control data to and from the non-volatile memory (500), based on the operation mode set by the device identification unit (332);
a data handler unit (337) in communication with the clock generation unit (331) and the command handler unit (333) and configured to receive data from the BULK/MS Transfer Handler (316) through the secure unit (350) to perform Bulk data WRITE and READ operations to and from the non-volatile memory (500);
a TX CMD unit (334) in communication with the command handler unit (333) and configured to:
receive control data from the command handler unit (333),
perform parallel data to serial data conversion on the received control data, and
transmit the control data to the non-volatile memory (500),
a RX CMD unit (335) in communication with the command handler unit (333) and configured to:
receive data from the non-volatile memory (500) in response to the transmitted control data,
perform serial data to parallel data conversion on the received data, and
transmit the received data to the command handler unit (333) for CRC verification,
a CMD INOUT unit (336) in communication with TX CMD unit (334) and the RX CMD unit (335) and configured to transmit and receive the data to and from the non-volatile memory (500);
a TX DATA unit (338) in communication with the data handler unit (337) and configured to:
receive the data from the data handler unit (337),
perform the CRC generation and append start and stop bits to the received data from the data handler unit (337), and
transmit the data to the non-volatile memory (500),
a RX DATA unit (339) in communication with the data handler unit (337) and configured to:
receive the data from the non-volatile memory (500),
perform CRC verification on the received data from the non-volatile memory (500), and
forward the data to the data handler unit (337) if CRC verification is successful;
a DATA INOUT unit (340) in communication with TX DATA unit (338) and the RX DATA unit (339) and configured to transmit and receive the data to and from the non-volatile memory (500).
7. The Field Programmable Gate Array (FPGA) based secure Universal Serial Bus (USB) mass storage device as claimed in claim 6, wherein the data handler unit (337) is configured to:
receive a READ request from the BULK/MS transfer handler (316);
send the READ request to the non-volatile memory (500) through the command handler unit (333); and
read data from the non-volatile memory (500) through the DATA INOUT unit (340) and the RXDATA unit (339), if a READ ready response is received from the non-volatile memory (500).
8. The Field Programmable Gate Array (FPGA) based secure Universal Serial Bus (USB) mass storage device as claimed in claim 6, wherein the data handler unit (337) is configured to:
receive a WRITE request from the BULK/MS transfer handler (316);
send the WRITE request to the non-volatile memory (500) through the command handler unit (333); and
write data to the non-volatile memory (500) through the DATA INOUT unit (340) and the TX data unit (338), if a WRITE ready response is received from the non-volatile memory (500).
9. The FPGA based secure USB mass storage device as claimed in claim 1, wherein a plurality of USB operations includes PHY operations and the USB Full speed (12Mbps) and Low speed (1.5Mbps) PHY operations are implemented in FPGA and without the USB 2.0 PHY chip (400) and wherein, the USB Mass Storage (MS) device controller unit (310) receives data from an external USB host (100) directly.
10. The FPGA based secure USB mass storage device as claimed in claim 1 or 2, wherein after the FPGA booting, the FPGA based secure USB mass storage device is disconnected and reconnected by sending '0' on a USB_D+ and '0' on a USB_D- for 500ms and thereafter sending '1' on the USB_D+ and '0' on the USB_D-.
11. A method for storing data communicated over USB using FPGA, wherein the FPGA comprises:
a USB Mass Storage (MS) device controller unit (310) in communication with a secure unit (350);
a memory controller unit (330) in communication with a non-volatile memory (500), and the secure unit (350), the method comprising:
receiving, by the USB Mass Storage (MS) device controller unit (310), data from an external USB host (100),
performing, by the USB Mass Storage (MS) device controller unit (310), a plurality of USB operations on the received data,
performing, by the memory controller unit (330), READ and WRITE operations from and to a non-volatile memory, and
performing, by the secure unit (350), encryption and decryption of the data received from the USB MS device controller unit (310) and the memory controller unit (330) respectively.
| # | Name | Date |
|---|---|---|
| 1 | 202141014222-PROVISIONAL SPECIFICATION [30-03-2021(online)].pdf | 2021-03-30 |
| 2 | 202141014222-FORM 1 [30-03-2021(online)].pdf | 2021-03-30 |
| 3 | 202141014222-DRAWINGS [30-03-2021(online)].pdf | 2021-03-30 |
| 4 | 202141014222-FORM-26 [15-07-2021(online)].pdf | 2021-07-15 |
| 5 | 202141014222-Proof of Right [06-09-2021(online)].pdf | 2021-09-06 |
| 6 | 202141014222-Correspondence, Form-1_17-09-2021.pdf | 2021-09-17 |
| 7 | 202141014222-FORM 3 [23-03-2022(online)].pdf | 2022-03-23 |
| 8 | 202141014222-ENDORSEMENT BY INVENTORS [23-03-2022(online)].pdf | 2022-03-23 |
| 9 | 202141014222-DRAWING [23-03-2022(online)].pdf | 2022-03-23 |
| 10 | 202141014222-COMPLETE SPECIFICATION [23-03-2022(online)].pdf | 2022-03-23 |
| 11 | 202141014222-FORM 18 [27-06-2022(online)].pdf | 2022-06-27 |
| 12 | 202141014222-FER.pdf | 2023-07-31 |
| 13 | 202141014222-FER_SER_REPLY [17-01-2024(online)].pdf | 2024-01-17 |
| 14 | 202141014222-DRAWING [17-01-2024(online)].pdf | 2024-01-17 |
| 15 | 202141014222-COMPLETE SPECIFICATION [17-01-2024(online)].pdf | 2024-01-17 |
| 16 | 202141014222-CLAIMS [17-01-2024(online)].pdf | 2024-01-17 |
| 17 | 202141014222-POA [07-10-2024(online)].pdf | 2024-10-07 |
| 18 | 202141014222-FORM 13 [07-10-2024(online)].pdf | 2024-10-07 |
| 19 | 202141014222-AMENDED DOCUMENTS [07-10-2024(online)].pdf | 2024-10-07 |
| 20 | 202141014222-Response to office action [01-11-2024(online)].pdf | 2024-11-01 |
| 21 | 202141014222-Response to office action [25-06-2025(online)].pdf | 2025-06-25 |
| 1 | 202141014222SearchstdE_25-07-2023.pdf |
| 2 | 202141014222patlastumlstE_31-03-2023.pdf |