Source: http://www.google.com/patents/US20090276474?dq=7,752,326
Timestamp: 2015-03-27 21:38:18
Document Index: 432904887

Matched Legal Cases: ['arty 210', 'arty 210', 'arty 210', 'arty 210', 'arty 210', 'arty 210', 'arty 210', 'arty 210', 'arty 210', 'arty 310', 'arty 310', 'arty 310', 'arty 310', 'arty 310', 'arty 510', 'arty 510', 'arty 310', 'arty 310', 'arty 310', 'arty 310', 'arty 310', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 720', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710', 'arty 710']

Patent US20090276474 - Method for copying protected data from one secured storage device to another ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA method is used by a third party to copy digital data from a source secured storage device to a destination secured storage device, the method including establishing, by the third party, a virtual secure channel between the source SSD and the destination SSD, over which the third party reads digital...http://www.google.com/patents/US20090276474?utm_source=gb-gplus-sharePatent US20090276474 - Method for copying protected data from one secured storage device to another via a third partyAdvanced Patent SearchPublication numberUS20090276474 A1Publication typeApplicationApplication numberUS 12/113,335Publication dateNov 5, 2009Filing dateMay 1, 2008Priority dateMay 1, 2008Publication number113335, 12113335, US 2009/0276474 A1, US 2009/276474 A1, US 20090276474 A1, US 20090276474A1, US 2009276474 A1, US 2009276474A1, US-A1-20090276474, US-A1-2009276474, US2009/0276474A1, US2009/276474A1, US20090276474 A1, US20090276474A1, US2009276474 A1, US2009276474A1InventorsRotem Sela, Aviad ZerOriginal AssigneeRotem Sela, Aviad ZerExport CitationBiBTeX, EndNote, RefManReferenced by (3), Classifications (8), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetMethod for copying protected data from one secured storage device to another via a third party
US 20090276474 A1Abstract
A method is used by a third party to copy digital data from a source secured storage device to a destination secured storage device, the method including establishing, by the third party, a virtual secure channel between the source SSD and the destination SSD, over which the third party reads digital data, including protected data, from the source SSD and writes the read digital data into the destination SSD after determining that each party satisfies eligibility prerequisites.
1. A method of copying digital data from a source secured storage device to a destination secured device via and by a third party, the method comprising:
a) determining by a source secured storage device whether a third party is eligible to receive therefrom digital data, the digital data including protected data that are stored in the source secured storage device and cannot be copied to ineligible devices; b) determining by the third party whether a destination secured storage device is eligible to receive the digital data; c) if each of the third party and the destination secured storage device is eligible to receive the digital data,
i. establishing via the third party a virtual secure channel between the source secured storage device and the destination secured storage device;
ii. copying, by and via the third party, the digital data from the source secured storage device to the destination secured storage device over the virtual secure channel; and
d) manipulating data stored in the source secured storage device in order to prevent future use of the protected data. 2. The method according to claim 1, wherein the virtual secure channel includes a first secure channel between the source secured storage device and the third party, and a second secure channel between the third party and the destination secured storage device.
3. The method according to claim 1, wherein step b) further includes the step of proving to the destination secured storage device that the third party is eligible to send the digital data to the destination secured storage device before the destination secured storage device receives the digital data.
4. The method according to claim 1, wherein establishing the virtual secure channel between the source secured storage device and the destination secured storage device includes using a predetermined content key that is available to the source secured storage device to encrypt the digital data and to the destination secure storage device to decrypt the encrypted digital data.
5. The method according to claim 4, wherein the content key is made available to the source secured storage device and to the destination secured storage device during their manufacturing.
6. The method according to claim 2, wherein establishing the first secure channel includes using a first session key that is available to the source secured storage device to encrypt the digital data and to the third party to decrypt the encrypted digital data, and wherein establishing the second secure channel includes using a second session key that is available to the third party to encrypt the digital data and to the destination secured storage device to decrypt the encrypted digital data.
7. The method according to claim 6, wherein the first session key and the second session key are generated randomly by the third party and by the respective secured storage device.
8. The method according to claim 1, wherein the step of copying the digital data to the destination secured storage device includes setting, by the third party, the configuration of the destination secured storage device to be the same as the configuration of the source secured storage device.
9. The method according to claim 1, wherein manipulating the data stored in the source secured storage device includes disabling security features in, or erasing authentication parameters from, the source secured storage device, which are associated with the protected data, so that no device can use the protected data.
10. The method according to claim 1, wherein manipulating the data stored in the source secured storage device occurs upon, or after, completion of transferring of the digital data from the source secured storage device to the third party, or from the third party to the destination secured storage device.
11. A method of copying digital data from a source secured storage device to a destination secured storage device by and via a third party, the method comprising:
a) determining, by a third party, whether a source secured storage device is eligible to transfer digital data to a destination secured storage device, the digital data including protected data that are stored in the source secured storage device and are not transferable to ineligible devices; and b) if the source secured storage device is eligible to transfer the digital data to the destination secured storage device, (i) commencing, by the third party, establishment of a first secure channel with the source secured storage device and (ii) receiving, by the third party, the digital data from the source secured storage device over the first secure channel. 12. The method according to claim 11, further comprising:
c) determining, by the third party, whether the destination secured storage device is eligible to receive the digital data from the source secured storage device; d) if the destination secured storage device is eligible to receive the digital data, (i) commencing, by the third party, establishment of a second secure channel with the destination secured storage device and (ii) transferring, by the third party, the digital data to the destination secured storage device over the second secure channel; and e) causing, by the third party, access to the protected data stored in the source secured storage device to be blocked. 13. The method according to claim 12, wherein blocking the access to the protected data stored is by manipulation of data stored in the source secured storage device.
14. The method according to claim 12, wherein blocking the access to the protected data stored is by sending a corresponding command to a controller of the source secured storage device.
15. The method according to claim 12, wherein establishing the first secure channel includes using a first session key that is available to the source secured storage device to encrypt the digital data and to the third party to decrypt the encrypted digital data, and wherein establishing the second secure channel includes using a second session key that is available to the third party to encrypt the digital data and to the destination secure storage to decrypt the encrypted digital data.
16. The method according to claim 15 wherein the first session key is generated randomly by the third party and source secured storage device, and wherein the second session key is generated randomly by the third party and destination secured storage device.
17. The method according to claim 12, wherein the step of transferring the digital data from the third party to the destination secured storage device includes setting the configuration of the destination secured storage device to be the same as the configuration of the source secured storage.
18. The method according to claim 12, wherein causing the source secured storage device to manipulate data stored therein includes causing the source secured storage device to disable security features which are associated with the protected data, such that the protected data become inaccessible to any device, including the source secured storage device.
19. The method according to claim 12, wherein causing the source secured storage device to manipulate data stored therein includes causing the source secured storage device to erase authentication parameters associated with the protected data, such that no device can use the protected data.
20. The method according to claim 12, wherein manipulating the data stored in the source secured storage device occurs upon, or after, completion of transferring of the digital data from the source secured storage device to the third party, or upon, or after, completion of copying of the digital data to the destination secured storage device.
21. A method of reading protected data from a source secured storage device in order to copy it to a destination secure device via a third party, the method comprising:
a) determining by a source secured storage device whether a third party is eligible to receive therefrom digital data, the digital data including protected data that and are not transferable to ineligible devices; and b) if the third party is eligible to receive the digital data, (i) establishing a first secure channel between the source secured storage device and the third party and (ii) transferring, by the source secured storage device, the digital data to the third party over the first secure channel. 22. The method according to claim 21, wherein establishing the first secure channel includes using a first session key that is available to the source secured storage device to encrypt the digital data and to the third party to decrypt the encrypted digital data.
23. The method according to claim 22 wherein the first session key is generated randomly by the source secured storage device and by the third party.
24. The method according to claim 21, wherein the first session key is provided to the source secured storage device and to the third party.
25. The method according to claim 21, wherein responsive to the source secured storage device receiving a command from the third party to prevent future use of the protected data,
c) manipulating, by the source secured storage device, data stored therein such that the protected data can no longer be used, where manipulating the data includes disabling security features or erasing authentication parameters. Description
The present invention generally relates to storage devices and more specifically to a method for copying secured digital data, such as Digital Rights Management (�DRM�) protected content (e.g., audio, movies, and games), from one secured storage device (�SSD�) to another via a third party.
There are several types of protection mechanisms that prevent unauthorized duplication of digital content. Some protection mechanisms are often loosely referred to, and thought of, as a type of digital rights management (�DRM). Considerable efforts have been made to stop duplication of digital content from one electronic device to another. For example, storage devices that are used with iPod devices include a protection mechanism that prohibits musical or audio-visual content from being transferred from one iPod device to another, in order to prevent unauthorized duplication of protected digital content.
Flash memory devices are an example SSDs. SIM (�Subscriber Identity Module�) cards, megaSIM cards, and Universal Serial Bus (�USB�) flash drives (�UFDs�) are exemplary flash memory devices. SIM cards securely store service-subscriber key data that are used to identify a subscriber. SIM cards allow users to change phones by simply removing the SIM card from one phone and inserting it into another phone.
Currently, digital content that are stored in flash storage devices are protected by a security technology known as �Trusted Flash�. �Trusted Flash� (TF) is a data storage technology that enables consumers to buy multimedia content such as music, movies, and games, on flash memory cards for use in mobile phones, laptop computers, PDAs and other compatible and supported devices. A storage device that utilizes a security technology such as the Trusted Flash is referred to herein as �secured storage device� (SSD). An SSD protects its sensitive and secured data by using an encryption engine or by placing (i.e., storing) the sensitive and secured data in a hidden or secured storage area within the SSD, and by using authentication scheme.
Music producers and movie studios, and other multimedia content originators and providers, are more willing to release multimedia content on trusted products (also referred to herein as �supported devices�) because TF technology provides the security and DRM solutions that are required by them. A DRM solution involves enforcing a DRM policy on the electronic device (e.g., cell phone, iPod). A DRM policy is a set of restrictions imposed on the electronic device, which �tell� the electronic device what operations it can do with what digital content. For example, one policy rule may allow the electronic device to play a particular song only n times, for example 3 times, another policy rule may prohibit copying of digital content; another policy rule may allow replaying a digital data stream only by a specific electronic device, and so on. Consumers will be able to download protected digital content using online digital music services, for example, through their cell phone or personal computer (�PC�).
FIG. 1A shows an exemplary secured storage device (SSD) 100. SSD 100 includes mass storage area 108, which may be of a NAND flash variety. SSD 100 also includes secure storage controller 140 that manages mass storage area 108 via data and control lines 106 and communicates with host device 150 via host interface 102. Secure storage controller 140 controls all of the data storage and data retrieval to/from mass storage area 108 and data transfer to/from host device 150 by controlling, for example, �read�, �write� and �erase� operations, wear leveling, and so on, and by controlling communication with host device 150.
User Storage Area 110 Data stored in user storage area 110 is publicly available, which means that the data stored in user storage area 110 is unconditionally available to a user of SSD 100 and to any external entity (e.g., host device 150), regardless of its identity. That is, the digital data stored in user storage area 110 may include data that can be read by, or copied to, a host device (e.g., to host device 150) from SSD 100 and used (e.g., played back by host device 150) as is, without the host device having to authenticate itself to SSD 100. User storage area 110 may hold, for example, multimedia content, audio-visual content, etc.
Restricted Storage Area 120 Restricted storage area 120 may hold restricted data (and optionally metadata and information) that represent, or are related, for example, to usage rights associated with digital data that is held in user storage area 110. Restricted data that are stored in restricted storage area 120 are accessible only to authorized devices. Data representing DRM rules are exemplary restricted data because they govern the usage of digital content and, as such, they are intended only for authorized devices.
�Protected data� refers to any data, file, application or routine, that is stored in an SSD but is accessible only internally (i.e., to the SSD's controller) or to external authorized devices. Such data, file, application or routine can either be restricted from being transferred to an external device such as host device 150, or it can be transferred or copied to another device and be useless without the device using proper means (e.g., decryption keys) to access or use it.
Security Management Storage Area 130 In general a security management storage area may contain authentication keys of devices that are entitled to access the restricted storage area of a storage device. Turning again to FIG. 1, data stored in security management storage area 130 (referred to herein after as �security data�) is available only to secure storage controller 140 for internal processes (e.g., authentication) but not to host device 150 or to the host device's user. The security data held in security management storage area 130 may include, for example, the system's firmware, any data type of operating parameter (e.g., encryption and decryption keys, digital authentication certificates attesting to the identity, capabilities and privileges of SSD 100 and external devices), and other data that is desirable to have safeguarded from unfettered access, which would be the case if they were stored in user storage area 110. Authentication certificates of devices (e.g., media players and cell phones) specify to the secure storage controller 140 the devices that are entitled to use data that is held in the restricted storage area 120, and encryption/decryption keys that are stored in security management storage area 130 can be utilized by secure storage controller 140 to encrypt and decrypt data that is stored in SSD 100. The security data held in security management storage area 130 typically is related to security applications or to security routines.
Secure storage controller 140 utilizes security routines and security-related data (e.g., encryption keys) to impart security capabilities to SSD 100, which means, for example, that SSD 100 prohibits illegal use of the protected digital content stored in SSD 100 and generation of illegal copies thereof. To accomplish this, secure storage controller 140 controls the access to content held in restricted storage area 120 based on security data (e.g., keys, authentication certificates, security routines, etc.) that are held in security management storage area 130. Authentication may be executed by using the Private Key Infrastructure (�PKI�), symmetric keys, password-based schemes, or any other authentication scheme.
�PKI� is a well known security paradigm. In cryptography, PKI is an arrangement that binds public keys with respective user identities by means of a certificate authority (CA). The user identity must be unique for each CA. The binding is established through the registration and issuance process, which, depending on the level of assurance the binding has, may be carried out by software at a CA, or under human supervision. For each user, the user identity, the public key, their binding, validity conditions and other attributes cannot be forged if they are in public key certificates issued by the CA.
In essence, security mechanisms aim to make it impossible to copy protected data from one SSD to another. This has the unfortunate result in some secured storage devices that even an authorized owner or licensee of the protected data cannot move it from one of his/her filled up secured storages to another. Therefore, if the user wants to record new multimedia content and still keep his/her already recorded multimedia content, s/he would have to keep two secured storage devices: the �old� SSD, which contains previously recorded multimedia content, and the new SSD, for recording new multimedia content.
The host device system may include a user interface, for example, a keypad or a touchscreen, to receive a user instruction, and the third party may be configured to commence a data copy process responsive to the user instruction. By �data copy process� is meant herein establishing communication between the third party and the source SSD and destination SSD, reading data from the source SSD and writing the data read from the source SSD into the destination SSD, all these operations are initiated by the third party, responsive to a user instruction or automatically, such as upon connecting the source SSD and the destination SSD to the host device system.
Either one of the source SSD and the destination SSD may be a flash memory that may be selected from the group consisting of Trusted Flash device, Secure Digital (�SD�), miniSD, microSD, Hard Drive (�HD�), Memory Stick (�MS�), USB device, Disk-on-Key (�DoK�), and iNAND.
According to the present disclosure secured multimedia content (also referred to herein as �protected digital content� and �protected data�) of a source SSD can be copied from a source SSD to a destination SSD via a third party. The third party is provided with authentication means, which may be authentication certificate and authentication keys, to identify itself to the source SSD and to the destination SSD, and for proving, the source SSD, its eligibility to receive therefrom protected data that is part of digital data that is stored in the source SSD. The third party is also provided with authentication certificates and authentication keys that allow the third party to identify SSDs, and, in addition, to know whether a source SSD is eligible to transfer protected data to a destination SSD and whether the destination SSD is eligible to receive the protected data of, or originating, from the source SSD.
The third party, which may be a trusted computer system or a trusted application, may be local or remote (at least from one SSD's point of view) and it may independently serve multiple local or remote SSDs. �Third party� refers to any computer system that transfers digital content from a source SSD to a destination SSD under stringent rules in order to protect confidentiality of the protected data and to impart to the destination SSD the security level originally enforced by the source SSD on its digital data.
Binding the digital content to the specific media player is done by the SSD binding usage rules (e.g., DRM policy rules) to the digital content and enforcing these rules. In order to prevent use of the digital content by any other device, the secure storage controller of the SSD does not allow any other device to access the usage rules and the security features that are stored in its restricted storage area and in its secured management storage area. �Usage rules� and �security features� are exemplary protected data. However, a corresponding certificate may be issued by a trusted certificate authority (�CA�) and provided to SSDs, which will �tell� the SSDs that there is an entity (i.e., the third party) that has permission or mandate to copy therefrom protected data.
After third party 210 proves to source SSD 250 of its eligibility to receive therefrom the digital data, and upon proving to third party 210 that source SSD 250 is eligible to transfer the digital data to destination SSD 260, third party 210 establishes a first secure channel 220 with source SSD 250, which is part of a virtual secure channel that is yet to be established, through third party 210, between source SSD 250 and destination SSD 260. By �secure channel� is meant a communication channel over which ciphered data is communicated. By �virtual secure channel� is meant a secure channel whose establishment is proactively commenced by and via a third party between a source SSD and a destination SSD, in a way that digital data are copied or transferred from a source SSD to a destination SSD without the source SSD and the destination SSD communicating with each other directly. The secure channel is �virtual� also because it includes two separate and independent secure channels (e.g., secure channels 220 and 225) that can be established by the third party at the same time, concurrently, or at different times.
As part of the trust the source SSD has in third party 210, no two legitimate copies of the digital can exist (i.e., one in the source SSD and the other in the destination SSD). To achieve that, third party 210 disables source SSD 250. By �disabling a source SSD� is meant herein causing, by the third party, protected data in the source SSD to be unusable or inaccessible to any device, including the SSD that originally holds the protected data. Disabling a source SSD is performed by causing the source SSD to manipulate data stored therein in order to prevent future use of the source SSD's protected data.
Host device system 205 may include additional multiple host devices, designated as �host device 3� (shown at 280) through �host device n� (shown at 290), to which third party 210 may be operatively connected. A host device may be located locally or remotely with respect to the third party 210. The communication between third party 210 and any of the host devices of host devices system 205 may be performed via any combination of a dedicated communication cable, a landline, a data network, the Internet, and wirelessly.
To commence the data copy session third party 310 logs on, over the first secure channel and via host device 320, into source SSD 350, for example by using a system Access Control Record (�ACR�) of source SSD 350. If third party 310 and source SSD 350 authenticate each other and third party 310 proves to source SSD 350 it eligibility to receive therefrom digital data, source SSD 350 allows third party 310 to read whatever data source SSD 350 holds in its mass storage area, including protected data, and, in general, each data that is requested by third party 310.
Each of user applications 570A and 570B may include two separate and independent procedures: a �reading procedure� and a �writing procedure�. The reading procedure allows a user to instruct a third party to read digital data from a source SSD, and the writing procedure allows the same user, or another user, to instruct the third party to write the read digital data to a destination SSD. The user may select, activate, or otherwise cause or trigger the execution of the proper procedure (i.e., reading procedure or writing procedure) according to the role of the SSD (i.e., source SSDA or destination SSD). Referring again to FIG. 5 a first user may select, activate, or otherwise cause or trigger (e.g., by using user interface 515A) the execution of the reading procedure to cause third party 510 to read digital data from source SSD 550. A second user may select, activate, or otherwise cause or trigger (e.g., by using user interface 515B) the execution of the writing procedure to cause third party 510 to write the read digital data to destination SSD 560.
Authentication manager 630 may log-on, via communication interface 620, into the system of source SSD 350 and destination SSD 360 by using the SSDs' Access Control Record (�ACR�). Briefly, �ACR� is an access control paradigm that can be viewed as a �super authority record� because an ACR contains information for indexing and it can be linked both to bibliographic records, relational databases, and to other related access control records. The ACR concept shifts from the traditional concept of �authority control� to �access control�.
It is essential that destination SSD 360 has the same configuration as source SSD 350 because it is function-wise imperative that, in addition to the copied multimedia content and related protected data, the data structure of source SSD 350 is also transferred to destination SSD 360, or else data will be stored in a wrong way or in a wrong storage area, for example, in the user storage area instead of in the restricted storage area, or in the restricted storage area instead of in the user storage area, and so on, which will render the copied multimedia content unusable. �Data structure� is a way of storing data in a computer so that it can be used efficiently. In particular, �data structure� refers to the arrangement of digital data inside an SSD, the type and meaning of each data item, the absolute and relative location of each data item in the SSD's memory, and so on. Data structure is defined as part of the SSD's configuration. Therefore, in order for destination SSD 360 to hold an exact copy of the digital data as stored in source SSD 350, third party 310 has to ensure that the configuration of destination SSD 360 matches that of source SSD 350 before third party 310 writes the source SSD's digital data into destination SSD 360, for example, by using read/write mechanism 660. In order to achieve that, authentication manager 630 inquires for, or requests from, source SSD 350 information about, or data representative of, its configuration, and source SSD 350 can comply with the inquiry or request by notifying third party 310 of its configuration. Source SSD 350 may notify third party 310 of its configuration, for example, by sending to third party 310 a configuration table. After being notified by source SSD 350 of its configuration, authentication manager 630 causes storage device configurator 640 to use the configuration information obtained from source SSD 350 to configure destination SSD 360 in the same way as source SSD 350. It may, therefore, be said that storage device configurator 640 imposes, or enforces, the configuration of source SSD 350 on destination SSD 360.
Responsive to a user instruction to commence a data copy process (for example by using a user application such as user application 370), third party 710 issues and sends a �Set-Certificate� command 731 to source SSD 720 to start a mutual authentication session.
Being the initiator third party 710 sends with Set-Certificate command 731 its authentication certificate (�i.e., �Third party Certificate� 711). In response to the Set-Certificate command 731 source SSD 720 utilizes �Third Party Root Certificate� 723 to verify (shown at 732) the authenticity of Third Party Certificate 711. If verification fails, source SSD 720 aborts the authentication process. If the authentication certificate of third party 710 (�i.e., �Third party Certificate� 711) is verified by source SSD 720 (shown at 732), source SSD 720 responds to command 733 (i.e., �Get-Certificate�) that third party 710 issues by sending to third party 710 its own authentication certificate (i.e., �Source SSD Certificate� 721).
Third party 710 receives the source SSD's authentication certificate (i.e., �Source SSD Certificate� 721) and verifies (shown at 734) the authenticity of �Device Certificate� 721 by using Source Device Root Certificate 713. If this verification is also successful both parties (third party 720 and source SSD 720) get each other's public key from the corresponding authentication certificate: third party 710 has the public key 735 of source SSD 720 by virtue of verified Source SSD Certificate 721, and source SSD 720 has the public key 736 of third party 710 by virtue of verified Third party Certificate 711. After completion of this phase the two parties move on to the next phase, which is the �Private Key Verification� phase. Third Party Root Certificate 723 is typically stored in the hidden storage restricted (hidden) storage area of the SSD.
A private key of an SSD or of the third party may be verified by using various cryptographic schemes, one of which is described hereinafter. Private Key Verification is accomplished by using a double-sided challenge-response mechanism where source SSD 720 challenges third party 710 by using command 741 (�Get_Challenge�), which source SSD 720 provides to third party 710 with a relatively long (e.g., 32-byte) challenging random number (shown at 742) that is generated by source SSD 720. Third party 710 responds to command 741 (�Get_Challenge�) by signing (shown at 743) the challenging random number by using Third Party Private Key 712, according to the RSA cryptographic scheme that is defined in PKCS#1 version 2.1, or according to any other suitable version that exists today or that may be devised in the future. Briefly, �RSA� (the initials of the surnames Rivest, Shamir and Adleman) is a cryptography algorithm used to sign and encrypt digital data. RSA involves using a public key that can be known to everyone and is used for encrypting messages, and a private key. Messages encrypted with the public key can only be decrypted by using a matching (i.e., an associated) private key.
Third party 710 utilizes a similar challenge-response mechanism to challenge source SSD 720. That is, third party 710 generates and sends a random number to source SSD 720 and checks whether the number retuned by source SSD 720 matches the generated random number. If the two numbers match, this indicates to third party 710 that source SSD 720 is who it says it is and that source SSD 720 is eligible to transfer its digital data to a destination SSD. If the numbers do not match, the authentication fails and third party 710 aborts the authentication process. After completion of this phase the two parties may move on to the next phase, which is the �Session Key Agreement� phase. The root certificate of the third party and the SSD's private key are usually stored in the restricted (hidden) storage area of the SSD.
As explained above a secure channel between a third party and a source SSD (referred to herein as the �first secure channel�) may be established by using a session key (referred to herein as the �first session key�) that may be available to third party 710 and source SSD 720 in several ways. That is, the session key can be generated by them (as demonstrated by FIG. 7) or provided to them from an external system.
Source SSD 720 generates random number 751 and sends it, after encryption (shown at 752) to third party 710, where it is decrypted (shown at 753). Third party 710 generates random number 761 and sends it, after encryption (shown at 762) to source SSD 720, where it is decrypted (shown at 763). The random number generated by each side may be 16-byte long and it may be encrypted according to the RSA cryptographic scheme as defined in PKCS#1 version 2.1. �XOR-ing� (performing �exclusive or� logical operation on) the two random numbers 751 and 761 at each party results in third party 710 and source SSD 720 having the same session key (respectively shown at 771 and 772). The session key would be the 16-byte of the binary value resulting from the XOR operation of the two random numbers.
After the session key is generated, source SSD 720 needs a proof that third party 710 has generated, and will be using, the same session key. As proof, third party 710 forwards (shown at 781) a �Start-Session� command that is AES (�Advanced Encryption Standard�) encrypted (shown at 791) with session key 771. Source SSD 720 decrypts the �Start Session� command with session key 772 and verifies that the �Start Session� command includes a message �Start Session�. If session keys 771 and 772 do not match, the authentication process fails and source SSD 720 aborts the login process. Otherwise, source SSD 720 utilizes session key 772 to encrypt and to send (shown at 782) �Authentication Complete� message 782 to third party 710. Third party 710 decrypts �Authentication Complete� message 782 with session key 771 and verifies that �Authentication Complete� message 782 contains the message �Authentication Complete�. This last step completes the session key agreement process and opens a secure channel over which commands and data (e.g., the digital data) can be exchanged between third party 710 and source SSD 720 in a secure manner (i.e., encrypted). The session key will be used by third party 710 and source SSD 720 during the entire communication session, which is the period until third party 710 reads out the entire digital data that is stored in source SSD 720. The authentication and session keys generation process exemplified in FIG. 7 can likewise be used, mutatis mutandis, for authenticating third party 710 to a destination SSD and vice versa. That is, in the latter case the word �source� should be replace with the word �destination�.
FIG. 9 shows an exemplary authentication certificates' hierarchy. PKI system Root CA (�CA� stands for �Certifying Authority�) 910 is trusted by secured storage devices and by service providers. Secured Storage Device's Root CA 920, which is the SSD's unique root CA, is contained in, or held by, a third party to allow the third party to authenticate an SSD. The third party may hold a list of SSD's root CAs for SSDs that are entitled to the data copy service rendered by the third party. Likewise, Third Part's Root CA 930, which is the third party's root CA, is contained in or held by an SSD. Each of Secured Storage CA Device's Root CA 920 and Third Part's Root CA 930 is signed by PKI system Root CA 910. Therefore, it may be said that a commonly trusted authority (i.e., PKI System Root CA 910) delegates trust to Secured Storage CA Device's Root CA 920 and to Third Part's Root CA 930. Secured Storage Device Certificate 940, which is the SSD's certificate, is contained in or held by the SSD and signed by Secured Storage Device's Root CA 920. Likewise, Third Party Certificate 950, which is the third party's certificate, is contained in or held by the SSD and signed by Third Party's Root CA 930.
FIG. 10 shows a method for copying digital data from a source SSD to a destination SSD by and via a third party according to an example embodiment of the present disclosure. A user inserts a source SSD into a host device and invokes, at step 1005, a user application (e.g., user application 370 of FIG. 3) on a host device to prompt a third party to execute a data copy process. At step 1010 the third party determines whether the source SSD is eligible to transfer digital data to a destination SSD, which includes protected data that are stored in the source SSD and are not transferable to ineligible devices. If the source SSD is not eligible to transfer the digital data to the destination SSD (shown as �N� at 1010), the authentication, and therefore, the entire data copy process, is aborted. If the source SSD is eligible to transfer the digital data to the destination SSD (shown as �Y� at 1010), the third party establishes, at step 1020, a first secure channel with the source SSD and receives (by causing the source SSD to transmit) the digital data from the source SSD over the first secure channel. At step 1030 the third party holds the digital data until it is time to transfer it to the destination SSD, or after a predetermined period of time (e.g., 2 days) elapses, after which the third party will delete its copy of the digital data. Nevertheless, the third party may ask the source SSD in question to resend to it the digital data, whether conditionally or not. At step 1040 the third party determines whether the destination SSD is eligible to receive the digital data from the source secured storage device. If the destination SSD is eligible to receive the digital data (shown as �N� at 1040), the third party establishes, at step 1050, a second secure channel with the destination SSD and transfers the digital data to the destination SSD over the second secure channel. At step 1060 the third party causes the source SSD to manipulate data stored in the source SSD in order to prevent future use of the protected data.
The third party may cause the data stored in the source SSD to be manipulated upon, or after, the third party completes transferring of the digital data from the source SSD to the third party, or upon, or after, the third party completes copying of the digital data to the destination secured storage device. The first secure channel and the second secure channel constitute a virtual secure channel between the source SSD and the destination SSD, as described above. Upon completion of transferring of the digital data to the destination SSD the user application may introduce to the user a corresponding message (e.g., �data copy completed�). It is noted that any source SSD and any destination SSD mentioned herein may be a flash memory device. The flash memory device may be selected from the group including (the list not being exhaustive) Trusted Flash device, Secure Digital (�SD�), miniSD, microSD, Hard Drive (�HD�), Memory Stick (�MS�), USB device, Disk-on-Key (�DoK�), iNAND, and the like. It is noted that the source SSD and/or the destination SSD may be a non-flash device.
Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8132045 *Jun 16, 2009Mar 6, 2012SanDisk Technologies, Inc.Program failure handling in nonvolatile memoryUS8307241Jun 16, 2009Nov 6, 2012Sandisk Technologies Inc.Data recovery in multi-level cell nonvolatile memoryUS8832353Jun 18, 2009Sep 9, 2014Sandisk Technologies Inc.Host stop-transmission handling* Cited by examinerClassifications U.S. Classification1/1, 707/999.204International ClassificationG06F17/30Cooperative ClassificationG06F21/10, G06F2221/0786, G06F17/30218European ClassificationG06F21/10, G06F17/30F8FLegal EventsDateCodeEventDescriptionMay 1, 2008ASAssignmentOwner name: SANDISK IL LTD., ISRAELFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SELA, ROTEM;ZER, AVIAD;REEL/FRAME:020885/0579Effective date: 20080423RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services