EP1846826A2 - Carte memoire securisee a phases de cycle de vie - Google Patents

Carte memoire securisee a phases de cycle de vie

Info

Publication number
EP1846826A2
EP1846826A2 EP06734304A EP06734304A EP1846826A2 EP 1846826 A2 EP1846826 A2 EP 1846826A2 EP 06734304 A EP06734304 A EP 06734304A EP 06734304 A EP06734304 A EP 06734304A EP 1846826 A2 EP1846826 A2 EP 1846826A2
Authority
EP
European Patent Office
Prior art keywords
card
state
testing
memory
secure
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06734304A
Other languages
German (de)
English (en)
Inventor
Michael Holtzman
Baruch Boris Cohen
Ron Barzilai
Hagai Bar-El
David Deitcher
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Discretix Technologies Ltd
SanDisk Technologies LLC
Original Assignee
DISCRETIX TECHNOLOGIES Ltd
SanDisk Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/317,862 external-priority patent/US8321686B2/en
Priority claimed from US11/317,390 external-priority patent/US8108691B2/en
Application filed by DISCRETIX TECHNOLOGIES Ltd, SanDisk Corp filed Critical DISCRETIX TECHNOLOGIES Ltd
Publication of EP1846826A2 publication Critical patent/EP1846826A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2273—Test methods
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory

Definitions

  • the invention generally relates to memory cards and encryption, and in particular relates to eliminating the access to secure data and keys through the testing mechanisms in the card.
  • Smart Card an intelligent memory card commonly referred to as the Smart Card was developed and gained acceptance in the marketplace as a form of identification and payment.
  • the Smart Card contains a small amount of memory for storing a user's identification data and for storing transactional related data.
  • the Smart Card is also often referred to as a chip card and is employed in Japan for various things such as the national identity card and in various places as a type of credit or debit card.
  • chip designs and encryption schemes have been employed in the cards and the systems that utilize the cards.
  • Another important aspect is cost.
  • Several different technologies such as nonvolatile memory, logic, and volatile memory, can be fabricated on a single integrated circuit die (chip).
  • chips integrated circuit die
  • mixing different technologies in one die significantly increases the cost of production.
  • cost is a major driving force
  • using multiple die may mean that sensitive information has to pass from one die to another in the final product. This is another potential weakness a hacker can exploit if appropriate precautions are not employed.
  • non volatile memory bits are expensive to mix with logic within the same die.
  • the Smart Card employs non-volatile memory for data storage purposes in the same die as the logic that runs the Smart Card, which is a way of maximizing security.
  • a memory card that benefits from the present invention must store very large music, photo, movie and other user files.
  • the present invention has numerous life cycle phases that are entered and passed through during the life of the card. Depending on the phase, logic in the card enables or disables the encryption engine, controls access to hardware (before and after wafer singulation and card assembly) and software testing mechanisms, and controls key generation. These phases not only allow both the hardware and software of the card to be thoroughly tested before and after manufacture (unlike in the Smart Card where the test pads are removed), but also make it virtually impossible to access the encrypted keys and thus the encrypted content when the card is in a secure phase, the operating phase that the card is in when it is shipped to the user. Therefore, the present invention provides for a memory card that can be well tested but is also resistant to unauthorized access to protected data within the card.
  • FIG. IA is a schematic diagram of system 10 according to an embodiment of the present invention.
  • FIG. IB is a schematic diagram of another embodiment of system 10.
  • FIG. 2A is a flowchart illustrating the various life cycle phases in an embodiment of the present invention.
  • FIG. 2B is a chart of the various life cycle phases.
  • FIG. 3 is a flow chart illustrating the boot up process and life cycle phases.
  • FIG. IA An example memory system in which the various aspects of the present invention may be implemented is illustrated by the block diagram of Fig. IA.
  • the memory system 10 includes a central processing unit (CPU) or controller 12, a buffer management unit (BMU) 14, a host interface module (HIM) 16, flash interface module (FIM) 18, a flash memory 20 and a peripheral access module 22.
  • Memory system 10 communicates with a host device 24 through a host interface bus 26 and port 26a.
  • the flash memory 20 which may be of the NAND type, provides data storage for the host device 24.
  • the software code for CPU 12 may also be stored in flash memory 20.
  • FIM 18 connects to the flash memory 20 through a flash interface bus 28 and in some instances a port, which is not shown, if the flash memory 20 is a removable component.
  • HIM 16 is suitable for connection to a host system like a digital camera, personal computer, personal digital assistant (PDA) and MP -3 players, cellular telephone or other digital devices.
  • the peripheral access module 22 selects the appropriate controller module such as FIM, HIM, and BMU for communication with the CPU 12.
  • all of the components of system 10 within the dotted line box may be enclosed in a single unit such as in memory card and preferably enclosed in the card.
  • the buffer management unit 14 comprises a host direct memory access unit (HDMA) 32, a flash direct memory access unit (FDMA) 34, an arbiter 36, a CPU bus arbiter 35, registers 33, buffer random access memory (BRAM) 38, and a crypto- engine 40 also referred to as encryption engine 40.
  • the arbiter 36 is a shared bus arbiter so that only one master or initiator (which can be HDMA 32, FDMA 34 or CPU 12) can be active at any time and the slave or target is BRAM 38.
  • the arbiter is responsible for channeling the appropriate initiator request to BRAM 38.
  • HDMA 32 and FDMA 34 are responsible for data transported between HIM 16, FIM 18 and BRAM 38 or the RAM 11.
  • the CPU bus arbiter 35 allows for direct data transfer from crypto-engine 40 and flash DMA 34 to RAM 11 via system bus 15, which is used in certain situations such as for example when it is desired to bypass the crypto- engine.
  • the operation of the HDMA 32 and of the FDMA 34 are conventional and need not be described in detail herein.
  • the BRAM 38 is used to store data passed between the host device 24 and flash memory 20.
  • the HDMA 32 and FDMA 34 are responsible for transferring the data between HIM 16/FIM 18 and BRAM 38 or the CPU RAM 12a and for indicating sector completion.
  • the data from memory 20 may be decrypted and encrypted again by crypto-engine 40 before it is sent to BRAM 38.
  • the encrypted data in BRAM 38 is then sent to host device 24 as before. This illustrates the data stream during a reading process.
  • a security system or secure operating system that is particularly useful when implemented in a memory card, such as the one described above, for example, has different phases or states. These phases are preferably entered sequentially, such that after progressing from one phase to the next, the previous phase cannot be re-entered. Therefore, they can be thought of as life cycle phases.
  • FIG. IB illustrates another embodiment of system 10. Only certain of the components of system 10 are illustrated in this figure for simplicity and clarity.
  • Memory system 10 comprises test pads also referred to as hardware test input/output (I/O) 54.
  • Hardware bus (HW bus) 56 is preferably connected to test pads 54. These test pads and HW bus 56 are connected to various hardware and circuitry (not shown) of system 10 and are used to test the hardware and circuitry of system 10.
  • JTAG bus 62 is connected the system bus 15 (seen in FIG. IA) and can be used to replace the controller firmware and drive hardware blocks from outside system 10. It is used for hardware testing that requires register read/write operations. Since JTAG bus 62 can access the RAM and ROM it is also used to test the firmware of system 10.
  • Host bus 26 is utilized to send diagnostic commands to system 10 and is used to test the firmware of the system.
  • NVM 50 of encryption engine 40 is also shown. Stored within NVM 50 are (values for) life cycle state 77 and secret key 99. NVM test port 58 is used to test the NVM within encryption engine 40.
  • the state indicator fuse 66 is used to indicate that the product is in NVM state 110 (described below) rather than relying on the NVM content. The reason is that the reliability of an initial value stored in NVM during fabrication cannot be guaranteed. Therefore another more reliable indicator such as a fuse is used. The system will determine that it is in state 110 if the fuse is set. If the system 10 is reset it will look at the NVM life cycle state 77 to determine the state.
  • FIG. 2A illustrates the various states and the order of transition between the states. Each state defines different behavior and capabilities of the card (or other system in which it is implemented), before and after the card is manufactured, as can be seen in the following table, which is also reproduced as FIG. 2B.
  • the state is preferably stored as a 32 bit value within the non volatile memory of the encryption engine.
  • the key value is also preferably stored as a 128 bit field in the non volatile memory of the encryption engine.
  • the key value is normally generated randomly by a seeded algorithm. Regeneration of the key is highly likely to change the value of the key, but this cannot be guaranteed because a (pseudo) random number generator may in fact generate the same value successively.
  • the terminology of changing the key is used interchangeably with that of regenerating the key in this application even though it is well understood the value of the key may not change during regeneration. Needless to say, the value of the key used to encrypt information is critical. The same key value must be used for both encryption and decryption.
  • Another security measure comprises limiting the availability of firmware and hardware test mechanisms.
  • the system comprises logic that will either enable or disable the mechanisms.
  • the previously described host bus is one of the mechanisms used to test the firmware of the card.
  • the host can issue diagnostic commands over the host bus to test the firmware.
  • the hardware may also be tested when these commands are executed.
  • the hardware is also directly tested over the hardware bus as well as the JTAG port, which provides direct access to various memories of the system. Note that in states 140 and 150 the NVM test mechanisms, HW test mechanisms, and FW test mechanisms are all disabled.
  • State 110 is referred to as the controller non-volatile memory (NVM) test.
  • NVM controller non-volatile memory
  • This state is the initial state after fabrication of the memory die, and is the state that is used to test non volatile memory of the controller die before the die is packaged and installed into the memory card. The testing that occurs in this state may be performed before singulation while the dice are still integral in wafer format, or may alternatively be performed on the individual die after singulation.
  • NVM controller non-volatile memory
  • its content using the NVM tester
  • fuse 66 is blown.
  • the encryption engine 40 is disabled. This state is only designed to be entered into once in the life cycle of the card and there is no method within the system for returning to this state.
  • this state is indicated by anything other than the 6 pre-assigned values of the many possible combinations of the 32 bit value used to define the life cycle state. If an illegal value is detected and the fuse is blown (not allowing NVM state 110 to be entered) the crypto-engine will never become ready and the system will not boot, or go beyond step 302 described below with regard to FIG. 3. Therefore, each time the card is powered up and is in this state, a new key will be randomly generated, and the previously encrypted data impossible to decrypt.
  • State 120 is referred to as the constant enabled state. In this state the encryption engine 40 is enabled. The key that the encryption engine will use is not generated by the random number generator, and is not stored in memory, but is hard wired to some external source and constant during this phase. The hardware and software testing mechanisms are available in this state. This state is entered by a hardware tester.
  • State 130 is referred to as the random enabled state. This state is similar to state 120, however, the secret key is randomly generated (once) when state 130 is entered instead of being constant and hard wired. This is the state used for final testing, characterization, and qualification of the memory card. Cryptographic operations including encryption and decryption are possible with the firmware using a secret key or a key derived from the secret key. This state is entered by code that is loaded into system 10 by host device 24 and then executed by system 10.
  • State 140 is referred to as the final key state.
  • the card uses the final secret key that will be shipped with the card.
  • the hardware and software test mechanisms are disabled by the card logic and cannot be accessed. This includes the hardware test bus and test pads, seen in FIG. IB.
  • This state is used to load the card with the final firmware and configuration data that needs to be protected with the key the product is shipped with. The product can be configured in this state, whereas in state 150 it cannot.
  • This state is entered by a host command.
  • the command may be contained in code that is downloaded from the host and executed by the card ("DLE code").
  • the command may alternatively be issued directly from the host. This is true any time the term DLE code is utilized below.
  • State 150 is referred to as the secure state. This is the state in which the card is shipped from the factory. The hardware and software test mechanisms are disabled by the card logic and cannot be accessed. This state is entered at the end of testing and configuration of the product on the manufacturing floor. The key is not regenerated and the value that was stored in memory during state 140 is utilized during state 150. While derivative keys may be utilized for various operations of the card, the key 99 will always be necessary to derive those keys and to encrypt and decrypt data. This key is meant to be utilized for the life of the secure card (while in the hands of the consumer as a secure card, not after). The firmware in the card cannot use the secret key for any operation. It is the hardware of the encryption engine that is responsible for performing all encryption and decryption within the card. This state is entered by DLE code.
  • State 160 is referred to as the returned merchandise authorization or RMA state.
  • This state is designed to allow testing of a card that has been returned by a consumer because it is not working properly. This is the state in which failure analysis of the card can be performed. The software and hardware test mechanisms are again available. It is important to note that this state is only accessible by the factory. Furthermore, after the RMA state is entered, the card can never again be used as a secure card. In other words, it can never again enter state 150 or otherwise be used to decrypt information resident on the card or to save encrypted information to the card. The secret key is regenerated when this mode is entered and during every chip reset performed while the card is in this state. Operation using the secret key for decryption is enabled only at boot time and the firmware cannot use the secret key for any operations. This state is entered by a ROM code that is the result of a host command.
  • State 170 is referred to as the disabled state.
  • the crypto- engine 40 In the disabled state, the crypto- engine 40 is in bypass mode with all of the cryptographic abilities disabled. Only non-secure algorithms are used within the card. Hardware and software test mechanisms are again enabled because without the encryption engine there is nothing worthy of being hacked or otherwise tampered with. Any encrypted information can no longer be decrypted and is rendered worthless. Also, no additional information may be encrypted and subsequently decrypted.
  • This state may be used to produce a non-secure or "regular" card. In this way, the same system can be used to produce both secure and non-secure memory cards. The difference is that in the non-secure card the security system of the card is in the disabled state, or the card can more generally be said to be in state 170.
  • the disabled state can also be used to re-ship a product that has been sent back to the factory for failure analysis, and has therefore been passed into RMA state 160.
  • RMA state 160 After a card enters into RMA state 160, it can never return to any of the previous states, and may never be sold again as a secure card.
  • a card that is functional or can be made functional again at the factory can be placed into disabled state 170 and re-sold as a non-secure card. In this way, the card can be salvaged and would for all intensive purposes be the same as a new non-secure or "regular" card. Both the salvaged non-secure card and a new non secure card will be running the same firmware in the same state.
  • Figure 3 illustrates the booting process for a memory card implementing the system described above.
  • Method 3 illustrates the booting process for a memory card implementing the system described above.
  • Method 3 illustrates the booting process for a memory card implementing the system described above.
  • step 302 the system checks if the cryptographic hardware, including crypto-engine 40 and other components, is ready. The system will wait to proceed until the hardware is ready. When the hardware is ready the system advances to step 304. In step 304 the system checks to see if the card is in state 170, the disabled state. If the card is in state 170, in step 306 the system will upload the boot loader ("BLR") which is a minimal amount of startup code, from flash memory 20 to RAM 11. Next, in step 308 the system checks to see if the BLR was properly uploaded. If so, in step 310 the system will upload the firmware necessary to run in non-secure mode (the standard firmware minus the cryptographic functionality). If the BLR was not properly uploaded in as determined in step 308, the system will advance to step 324 described below.
  • BLR boot loader
  • step 304 If in step 304 the system determined that the card was not in state 170, the system will clear the RAM contents in step 312. After that the system will again check to see what state the card is in step 314. If the card is in state 120, 130, or 140 the BLR will be uploaded in step 316. In step 318 the system will check to see if the BLR was properly uploaded. Next, in step 320 an integrity check of the BLR code will be performed. This integrity check is a hardware based check performed by calculating message authentication code (MAC) values and comparing them with reference values. The result of the integrity check is a simple flag stored in memory. In step 322 the firmware checks the flag to see if the integrity was verified or not.
  • MAC message authentication code
  • step 342 upload the firmware necessary to run in secure mode, which also of course allows for non secure data to be stored and retrieved. If the integrity is not OK as determined in step 322, the system will wait for a diagnostic command from the host to download and execute certain instructions from the host (DLE command), as is represented by step 324. If a DLE command is received, as seen in step 326, the system will proceed to load the DLE code into RAM in step 328. In step 330 the DLE code will be executed by the controller.
  • DLE command a diagnostic command from the host to download and execute certain instructions from the host
  • step 314 If in step 314 it was determined that the card was not in state 120, 130, or 140 the system will check in step 332 to see if the card is in state 150. If so, the system will then upload the BLR in step 334. This is done by the ROM code. If the BLR upload was OK, as determined in step 336, a hardware based integrity check, as described above in step 320, will be performed in step 338. After this hardware based integrity check, another integrity check, this time a software based integrity check will be performed in step 340. If the integrity is OK, the system will then in step 342 upload the firmware necessary to run in secure mode, which also of course allows for non secure data to be stored and retrieved.
  • step 332 If in step 332 it was determined that the card was not in state 150, the system will then check the state of card and if the card is in state 160 and if so it will wait for a diagnostic command as represented by step 348. If, however, in step 344 it is determined that the card was not in state 160, the system will wait for a command to go into RMA state 160, as seen in step 346.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Storage Device Security (AREA)
  • Credit Cards Or The Like (AREA)

Abstract

L'invention concerne une carte mémoire sécurisée à capacité de chiffrement comprenant divers états de cycle de vie permettant l'essai du matériel et du logiciel de la carte dans certains de ses états. Les mécanismes d'essai sont désactivés dans certains autres états, fermant ainsi les portes dérobées éventuelles afin de sécuriser les données et les clés cryptographiques. La disponibilité et la génération commandée des clés nécessaires au chiffrement et au déchiffrement des données font que, même si les portes dérobées sont accessibles, les données préalablement chiffrées sont impossibles à déchiffrer et donc sans valeur, y compris si une porte dérobée est trouvée et ouverte par malveillance.
EP06734304A 2005-02-07 2006-02-01 Carte memoire securisee a phases de cycle de vie Withdrawn EP1846826A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US65112805P 2005-02-07 2005-02-07
US11/317,862 US8321686B2 (en) 2005-02-07 2005-12-22 Secure memory card with life cycle phases
US11/317,390 US8108691B2 (en) 2005-02-07 2005-12-22 Methods used in a secure memory card with life cycle phases
PCT/US2006/003876 WO2006086232A2 (fr) 2005-02-07 2006-02-01 Carte memoire securisee a phases de cycle de vie

Publications (1)

Publication Number Publication Date
EP1846826A2 true EP1846826A2 (fr) 2007-10-24

Family

ID=36644859

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06734304A Withdrawn EP1846826A2 (fr) 2005-02-07 2006-02-01 Carte memoire securisee a phases de cycle de vie

Country Status (7)

Country Link
EP (1) EP1846826A2 (fr)
JP (1) JP4787273B2 (fr)
KR (1) KR100972540B1 (fr)
CN (1) CN101164048B (fr)
IL (1) IL184793A0 (fr)
TW (1) TWI402755B (fr)
WO (1) WO2006086232A2 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7748031B2 (en) 2005-07-08 2010-06-29 Sandisk Corporation Mass storage device with automated credentials loading
US8966284B2 (en) 2005-09-14 2015-02-24 Sandisk Technologies Inc. Hardware driver integrity check of memory card controller firmware
US8915447B2 (en) 2007-09-12 2014-12-23 Devicefidelity, Inc. Amplifying radio frequency signals
US8070057B2 (en) 2007-09-12 2011-12-06 Devicefidelity, Inc. Switching between internal and external antennas
US9304555B2 (en) 2007-09-12 2016-04-05 Devicefidelity, Inc. Magnetically coupling radio frequency antennas
US20090069049A1 (en) 2007-09-12 2009-03-12 Devicefidelity, Inc. Interfacing transaction cards with host devices
US9311766B2 (en) 2007-09-12 2016-04-12 Devicefidelity, Inc. Wireless communicating radio frequency signals
US9553721B2 (en) * 2015-01-30 2017-01-24 Qualcomm Incorporated Secure execution environment communication

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4243888A1 (de) * 1992-12-23 1994-06-30 Gao Ges Automation Org Datenträger und Verfahren zur Echtheitsprüfung eines Datenträgers
FR2716989B1 (fr) * 1994-03-04 1996-04-05 Gemplus Card Int Procédé de fonctionnement d'une carte à puce.
JP3461234B2 (ja) * 1996-01-22 2003-10-27 株式会社東芝 データ保護回路
EP1004992A3 (fr) * 1997-03-24 2001-12-05 Visa International Service Association Système et méthode pour une carte à puce multi-application permettant de télécharger une application sur la carte postérieurement à son émission
JPH11161549A (ja) * 1997-11-28 1999-06-18 Toshiba Corp 携帯情報機器における秘密情報管理方法ならびにシステム
EP1082710A1 (fr) * 1998-06-05 2001-03-14 Landis & Gyr Communications S.A. Carte a circuit integre prechargee et procede d'authentification d'une telle carte
EP0992809A1 (fr) * 1998-09-28 2000-04-12 Siemens Aktiengesellschaft Circuit avec trajet d'analyse désactivable
JP2000172821A (ja) * 1998-12-10 2000-06-23 Toshiba Corp 半導体装置、データ記憶メディア、データ記録装置、データ読出装置、および半導体装置の製造方法
US7023996B2 (en) * 2001-05-04 2006-04-04 The Boeing Company Encryption for asymmetric data links
DE10162306A1 (de) * 2001-12-19 2003-07-03 Philips Intellectual Property Verfahren und Anordnung zur Verifikation von NV-Fuses sowie ein entsprechendes Computerprogrammprodukt und ein entsprechendes computerlesbares Speichermedium
JP4350962B2 (ja) * 2002-03-13 2009-10-28 パナソニック株式会社 セキュアデバイス
US6912633B2 (en) * 2002-03-18 2005-06-28 Sun Microsystems, Inc. Enhanced memory management for portable devices
US6843423B2 (en) * 2003-03-13 2005-01-18 Stmicroelectronics, Inc. Smart card that can be configured for debugging and software development using secondary communication port
US6783078B1 (en) * 2003-05-09 2004-08-31 Stmicroelectronics, Inc. Universal serial bus (USB) smart card having read back testing features and related system, integrated circuit, and methods
TW200501281A (en) * 2003-06-27 2005-01-01 Kingpak Tech Inc Manufacturing method of small memory card having display
KR101199600B1 (ko) * 2003-07-17 2012-11-12 샌디스크 테크놀로지스, 인코포레이티드 융기 부분을 구비한 메모리 카드
TWI223974B (en) * 2003-11-20 2004-11-11 Advanced Semiconductor Eng Tiny memory card and method for manufacturing the same

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006086232A2 *

Also Published As

Publication number Publication date
IL184793A0 (en) 2008-01-20
JP2008530659A (ja) 2008-08-07
KR20070121642A (ko) 2007-12-27
JP4787273B2 (ja) 2011-10-05
CN101164048B (zh) 2010-06-16
TW200641696A (en) 2006-12-01
CN101164048A (zh) 2008-04-16
KR100972540B1 (ko) 2010-07-28
WO2006086232A3 (fr) 2007-10-11
WO2006086232A2 (fr) 2006-08-17
TWI402755B (zh) 2013-07-21

Similar Documents

Publication Publication Date Title
US8423788B2 (en) Secure memory card with life cycle phases
US8321686B2 (en) Secure memory card with life cycle phases
US8108691B2 (en) Methods used in a secure memory card with life cycle phases
TWI460604B (zh) 安全微控制器、硬體加密器及用於保全一微控制器內之內容之方法
US7461268B2 (en) E-fuses for storing security version data
US8572410B1 (en) Virtualized protected storage
EP1638033B1 (fr) Système de mémoire volatile avec autovérification et sécurisation et procédé de mémorisation
US11003781B2 (en) Root key processing method and associated device
EP1846826A2 (fr) Carte memoire securisee a phases de cycle de vie
US20080107275A1 (en) Method and system for encryption of information stored in an external nonvolatile memory
US8108941B2 (en) Processor, memory, computer system, system LSI, and method of authentication
US20070237325A1 (en) Method and apparatus to improve security of cryptographic systems
TW200832427A (en) Virtual secure on-chip one time programming
JP2011522469A (ja) 保護されたソフトウエアイメージを有する集積回路及びそのための方法
US20200065528A1 (en) Storage device and program
US20070243937A1 (en) Method for booting and using software for AWP and B type amusement gaming machines, and for C type casino machines
US11481523B2 (en) Secure element
JP2003521034A (ja) マイクロプロセッサシステムおよびそれを操作する方法
US10970232B2 (en) Virtual root of trust for data storage device
CN109583196B (zh) 一种密钥生成方法
CN104794373A (zh) 一种软件加密锁
JP2003233536A (ja) データ処理装置

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070803

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

R17D Deferred search report published (corrected)

Effective date: 20071011

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20120223

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: DISCRETIX TECHNOLOGIES LTD.

Owner name: SANDISK TECHNOLOGIES INC.

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20150316

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20150728