the present invention relates generally to memory systems and more specifically to a secure and scalable solid state disk system . the following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements . various modifications to the preferred embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art . thus , the present invention is not intended to be limited to the embodiments shown , but is to be accorded the widest scope consistent with the principles and features described herein . fig3 is a block diagram of a host system and a usb token interfacing with a sata based secure - and - scalable solid state disk ( sns - ssd ) system . the host system 30 , comprises a processor ( not shown ), memory ( not shown ), 10 ( not shown ), a usb interface ( not shown ), and a sata host controller 34 . it connects to a usb token 35 through a usb interface and works with the secure - and - scalable solid state disk ( sns - ssd ) system 31 through a sata host interface 321 . a usb token 35 serves as an independent agent to provide password authentication utility before the sns - ssd 31 can be accessed after host system 30 boots up . the utility can be a software utility residing on the usb token 35 or preferably a browser link to the web server on the usb token 35 . the browser link is preferable , as it is more universal and requires less system resources to work on cross platform devices . the secure - and - scalable solid state disk ( sns - ssd ) system 31 comprises a first - level secure virtual storage controller 32 and two second - level secure virtual storage controllers 33 , and eight third - level storage device sd cards 10 . the first level of the virtual storage controller 32 comprises a sata host interface 321 , a crypto - engine 323 and a multiple of sata device interfaces 322 . the host side storage interface in this case is a serial ata or sata . the storage host interface can be any type of i / o interface including sata , serial attached scsi ( sas ), pci express , pata , usb , bluetooth , uwb or wireless interface . a more detailed description of the virtual storage controller 32 is shown in secure virtual storage controller 40 in fig4 . the second - level of the virtual storage controller 33 comprises a sata host interface 331 , a crypto - engine 333 and a multiple of sd device interfaces 332 . instead of interfacing directly with the flash memory , the virtual storage controller 33 chooses to interface with the third level storage device , a sd card 10 . the sd card 10 can be replaced with any flash based card or drive , including cf card , mmc , usb drive or memory stick , as long as pin - count , cost , and performance justify . in this case , each sd card 10 has six signal pins . it requires a total of 24 signal pins for four sd components with two flash memory components on each sd card , instead of 120 signal pins for eight flash memory components in the conventional approach . it amounts to a great cost saving in controller chip fabrication and a better manufacturability and testability . even though the first - level secure virtual storage controller 32 and the second - level secure virtual storage controller 33 may have different type of device interfaces , their architectures are substantially identical . as long as the storage device interface 322 is compatible with the storage host interface 331 , first - level secure virtual storage controller 32 can be cascaded and expanded with the second - level secure virtual storage controller 33 . the expansion is therefore exponential in density and performance . in its simplest form of architecture of secure - and - scalable solid state disk ( sns - ssd ) system , the host system 30 can interface directly with one of the second level virtual storage controllers 33 . the minimal secure - and - scalable solid state disk ( sns - ssd ) system is therefore with a total two levels comprising the second level storage controller 33 and the third level storage devices 10 . the crypto - engine 323 in the first - level and crypto - engine 333 in the second - level can be enabled , disabled and configured independently , depending on the requirement . in most cases , only the top - level crypto - engine is required . all other crypto - engines in the subsequent levels are disabled . a more detailed description of the crypto - engine is shown in fig1 . on the host storage interface , a sata host interface 331 is used to interface with the first level of virtual storage controller 32 . the storage interface in this case is a serial ata or sata . a more detailed description of the virtual storage controller 33 is shown in secure virtual storage controller 40 in fig4 . as shown in fig4 , the secure virtual storage controller 40 comprises a storage host interface 41 , an interrupt processor 42 , a host command and data processor 43 , a cpu 44 , a program memory 45 , a ram and buffer 46 , a data write processor 401 , a data read processor 402 , a pass - through command processor 403 , a get status and attribute processor 404 , a local command processor 405 , a crypto - engine 406 , a virtual storage processor 407 , and a plurality of storage device interfaces 408 . the virtual storage controller architecture in the invention is cascadable and scalable as long as the storage interface is compatible . if more density is required , more second level virtual storage controllers can be added for expansion . accordingly , more third level storage devices can be added for density expansion . compared with the conventional approach , the secure - and - scalable solid state disk ( sns - ssd ) system offers better storage density expansion in exponential order . by using the standard flash card such as sd card 10 as the flash memory building block , it brings along several benefits compared with the conventional ssd approach . by using the standard flash card such as sd card 10 as the flash memory building block , it brings along several benefits compared with the conventional ssd approach : 1 . wear - leveling of flash memory is delegated locally to the sd card 10 . no grand scale wear - leveling across all flash components is required . 2 . manufacturability and testability are done at the storage device level on sd card . it is more manageable at the device level than at ssd system level . 3 . there is no time lag in supporting and taking advantage of new flash technology , as the design and development is delegated to the standard sd controller 12 inside sd card 10 . 4 . time to market is much shorter . as soon as the sd card 10 is available in cost , density and performance , the secure - and - scalable solid state disk ( sns - ssd ) system 31 can be deployed . 5 . cost saving from new flash technology again is brought along by the building block architecture of sd card 10 . 6 . the performance benefit is from the virtual storage processor 32 and 33 . it not only provides virtual storage density aggregation , but also provides on - demand performance aggregation . the theoretical performance can be as high as the number of sd cards times the native sd card performance in parallel operation . 7 . the security is handled by the hardware based crypto - engine 323 or 333 . the password authentication utility resides independently on a usb token 35 . the secure - and - scalable solid state disk ( sns - ssd ) system has better performance and is more secure . the storage host interface 41 is for interfacing with the upstream host system 30 or another upper - level of secure virtual storage controller . the storage device interface 408 is for interfacing with the downstream storage device 10 or another lower - level of secure virtual storage controller . another embodiment of the block diagram of the invention , secure - and - scalable solid state disk ( sns - ssd ) system 39 with pata interface , is shown in fig5 . the host system 50 , comprises a processor ( not shown ), memory ( not shown ), i / o ( not shown ), a usb interface ( not shown ), and a pata host controller 54 . it connects to a usb token 35 through a usb interface and works with the secure - and - scalable solid state disk ( sns - ssd ) system 39 with pata interface through a pata host interface 381 . the secure - and - scalable solid state disk ( sns - ssd ) system 39 with pata interface comprises a first - level secure virtual storage controller 38 , a second - level secure virtual storage controllers 32 , and two third - level secure virtual storage controllers 33 , and eight fourth - level storage device sd cards 10 . as described above , the architecture of the invention is expandable and cascadable in density and performance . as in fig4 , the program memory 45 stores the firmware and virtual storage controller information , while the ram and buffer 46 are used to store data packet and for caching operation . the data write processor 401 interfaces with the virtual storage processor 407 through the crypto - engine that is doing the hardware encryption on - the - fly . the data is transferred from the buffer , encrypted and passed to virtual storage processor 407 . the data read processor 402 interfaces with the virtual storage processor 407 through the crypto - engine that is doing the hardware decryption on - the - fly . the data is transferred from virtual storage processor 407 , decrypted and passed to the buffer . the pass - through command processor 403 handles those commands that do not require any local processing . the pass - through command is sent directly downstream without encryption or translation . the get status and attribute processor 404 returns proper status and / or attributes back to the upstream host system or the upper - level virtual storage controller . if the status or attribute require too much time for the local controller to return , it will normally assert busy status to the requesting upstream host system or the upper - level virtual storage controller . when the proper status or attribute is collected , the interrupt processor 42 and routine 70 are invoked . the interrupt processor 42 generates a soft reset 47 to cpu 44 to warm boot the secure virtual storage controller 40 . consequentially , it interrupts the upstream system for service to interrogate the secure virtual storage controller 40 again , and the correct status or attribute is returned . it is a mechanism to synchronize the host and device when they are running at different pace , and the device needs more time to settle after request . every secure virtual storage controller 40 can be identified with a unique id preprogrammed in the program memory 45 . fig6 is the flow chart for the initialization of the secure virtual storage controller . when the secure virtual storage controller 40 is first initialized 60 after power on , it is checked if virtual storage controller is ready , via step 61 . if yes , the host command processor starts , via step 62 . otherwise , the controller sends an identify command to the downstream storage device list , via step 63 . once the downstream storage devices 10 are identified , these physical storage devices 10 are tested , via step 64 . the crypto - engine is then initialized , via step 65 . the virtual storage controller is set ready , via step 66 . the interrupt processor is then activated , via step 67 . fig7 is the flow chart for the interrupt processor . first , it is checked if the interrupt request is from the downstream virtual storage controller , via step 71 . if yes , the service is granted , via step 74 . otherwise , an interrupt is generated , via step 72 , to the upstream host or an upper - level virtual storage controller for service to configure the secure virtual storage controller 40 again . a soft reset 47 is subsequently generated to the local cpu 44 to warm boot , via step 73 , the secure virtual storage controller 40 . it is a mechanism to synchronize the host and device when they are running at different pace , and the device needs more time to settle after power - on initialization . it concludes the initialization of the secure virtual storage controller 40 . the host command and data processor 43 queues up and buffers packet of command and data between the storage host interface 41 and crypto - engine 406 . the extracted command queue is turned over to host command processor routine 80 to process , in fig8 . fig8 is the flow chart for the host command processor . the host command and data processor 43 queues up and buffers packet of command and data between the storage host interface 41 and crypto - engine 406 . the extracted command queue is turned over to host command processor routine , via step 80 , to process . if it is a data write command , via step 83 , a data write processor 401 is called up . otherwise , if it is a data read command , via step 84 , a data read processor 402 is called up . otherwise , if it is a pass - through command , via step 82 , a pass - through command processor 403 is called up . otherwise , if it is a get status / attribute command , via step 85 , a get status / attribute processor 404 is called up . otherwise , a local command processor 405 is called up . the local command processor 405 deals with the local functions of crypto - engine 406 , virtual storage processor 407 and the local virtual storage controller 40 . as shown in fig9 , the local command list 90 includes : 1 . set password 941 2 . change password 942 3 . authenticate password 943 4 . set password hint 944 5 . get password hint 945 6 . get number of attempts 946 7 . init & amp ; partition request 947 7 . get virtual storage attributes 951 8 . init partition size 952 9 . format 953 b . get local status 92 c . factory provision command 93 10 . get virtual storage controller id 961 11 . set virtual storage mode ( jbod , raid , or others ) 962 12 . set crypto - mode 971 13 . enable crypto - engine 972 14 . get encrypted key 973 14 . set master password 981 15 . set maximum number of attempt 982 16 . set managed mode flag 983 17 . set default password 984 user provision command 91 is for use by the utility in the field application , including the password authentication utility in usb token 35 . it includes password utility commands 94 and storage partition commands 95 . factory provision command 93 is for use in the factory to configure the ssd . it includes virtual storage processor configuration 96 , crypto - engine configuration 97 , password attribute configuration 98 , and test - mode command 99 . get local status command 92 is to return the corresponding status on the virtual storage controller . get virtual storage controller id command 961 is to return the unique id stored in the program memory 45 . set virtual storage mode command 962 is to set the storage operation mode of jbod ( just a bunch of disks ), raid ( redundant arrays of independent disks ) or others , depending on the requirement of performance or power consumption . set crypto - mode command 971 is to set the encryption mode of the engine . enable crypto - engine command 972 is to enable the crypto - engine . set managed mode flag 983 is to allow or disallow provision of ssd in the field . if the flag is set as unmanaged mode , then the usb token is what is needed to do re - provision and initialization of the ssd . if the flag is set as managed mode , then the user has to connect back to the managing server while doing the re - provision and initialization of the ssd . the flag can only be set in the factory . test - mode command 99 is reserved for testing of ssd by the manufacturer . before the ssd is ready for use , it has to go through factory provision during the manufacturing process . the provision is done by connecting the secure - and - scalable solid state disk ( sns - ssd ) system 31 to a host system 30 with a proper sata host controller 34 and possibly with a usb token 35 , as shown in fig3 . fig1 is the flow chart for factory provision . it first waits for the secure virtual storage controller to be ready , via step 101 . once the controller is ready , the factory default settings are loaded , via step 102 . it starts configuring the virtual storage processor , via step 103 . afterwards , it starts configuring the crypto - engine , via step 104 . the crypto - engine is enabled , if it is necessary , via step 105 . fig1 is the flow chart for virtual storage processor configuration . as shown in fig1 , the virtual storage mode is set , via step 111 , through one of the local commands , set virtual storage mode 962 . the virtual storage operation mode is set as jbod , raid or others . accordingly , a virtual storage aggregation is done , via step 112 , based on the physical storage device list 64 ( see fig6 ). a virtual storage identification table is established . the virtual storage device list is established , via step 113 . a physical to logical address translation table is built up , via step 114 , by the virtual storage processor 407 ( see fig4 .). afterwards , the virtual storage provision ready status is set , via step 115 . fig1 is the flow chart for crypto - engine configuration . the crypto - engine is then ready for configuration through one of the local commands , set crypto - mode command 971 is issued , via step 121 . next , the set maximum number of attempts command 982 is issued , via step 122 . a get encrypted key command 973 is issued , via step 1220 . correspondingly , a random ley is generated ( not shown ) by the random number generator rng 134 , in the crypto - engine 406 . the random key is encrypted and returned to the get encrypted key command 973 , via step 1220 . if a master password is required , via step 1221 , a get master password command process is initiated , via step 1222 , and a set master password command 981 is issued . the flag of managed mode of ssd is checked , via step 123 . if yes , the encrypted key is stored , via step 124 , in the managing server , if necessary . if not , the encrypted key is stored , via step 125 , in the usb token 35 . the master password is then sent to the crypto - engine through set master password command 981 , via step 126 . consequentially , the encrypted master password is then stored in ssd , ( not shown ). a default password is also set through command 984 , via step 1260 . consequentially , the encrypted default password is then stored in ssd , ( not shown ). the crypto - engine can be disabled or enabled . if it is enabled , it can be set to run at a particular encryption mode based on the requirement , via step 127 . afterwards , the crypto - engine provision flag is set as ready , via step 128 . fig1 is a block diagram for the crypto - engine . the crypto - engine 406 includes a random number generator rng 134 , a hash function hash 131 , a first general encryption engine enc 2 132 , a second data encryption engine enc 3 133 , a storage upstream interface 135 and a storage downstream interface 136 . the detailed implementation of the crypto - engine can be found in the pending u . s . patent application ser . no . 11 / 643 , 101 . the host system 30 depends on the plugged in usb token 35 to conduct password authentication . referring to fig1 a , after host system 30 cold boots , via step 140 . the usb token 35 cold boots , via step 141 , as well . the usb token starts operation , via step 142 . referring to fig1 b , after the host system 30 shuts down , via step 143 , the ssd shuts down , via step 144 , accordingly . the encryption key in the ssd will be lost , via step 145 , due to power outage . the ssd will stay encrypted , via step 146 , as long as the encryption key is not restored through password authentication utility loaded in the usb token 35 . referring to fig1 d , after the host system 30 hibernates , via step 1403 , the ssd hibernates , via step 1404 , accordingly . the encryption key in the ssd will be lost , via step 1405 , due to power outage . the ssd will stay encrypted , via step 1406 , as long as the encryption key is not restored through password authentication utility loaded in the usb token 35 . referring to fig1 c , after host system 30 wakes up from hibernation , via step 1400 , the usb token 35 cold boots , via step 1401 , as well , as in fig1 a . the usb token starts operation , via step 1402 . fig1 is the flow chart for usb token boot - up . as shown in fig1 , once the usb token web server boots up , via step 151 , it waits for storage and crypto - engine provision to be ready , via step 152 . it then activates the password authentication utility , via step 153 . the detailed implementation of the password authentication utility can be found in pending u . s . patent application ser . no . 11 / 643 , 101 . if the init and partition request is generated by the user through command 947 , via step 154 . accordingly , the crypto - engine will get a new random key from the random number generator 134 ( not shown ). it is checked if the managed mode flag is on , via step 1541 . if not , the encrypted key is retrieved , via step 1543 , from the usb token 35 . otherwise , the encrypted key is retrieved from the managing server , via step 1542 . the encrypted key is sent to the crypto - engine through set encrypted key command 9471 , via step 1544 . the crypto - engine then decrypts and retrieves the key ( not shown ). the encrypted master password is retrieved and decrypted by the crypto - engine ( not shown ). a new random key is then generated from the random number generator rng 134 ( not shown ). the master password will be encrypted with the new key by the crypto - engine ( not shown ). the utility will then initiate a get encrypted new key command 9472 , via step 1545 . the encrypted new key is stored in the managing server or usb token 35 , if necessary via step 1546 and 1547 . the new user password is then requested from the user and configured , via step 1548 . both master and user password are hashed with the newly generated key through hash function 131 and stored on the ssd ( not shown ). the ssd partition is then configured , via step 1549 . if the request is not for init and partition , it is checked if an authenticate password request is generated , via step 155 . if so , password authentication starts , via step 1550 . otherwise , it is checked if a change password request is generated , via step 156 . if so , change password utility starts , via step 157 . otherwise , it loops back to check for new password utility request , via step 154 . fig1 is the flow chart for password authentication . first , it is checked if the password is authenticated , via step 161 . if so , the crypto - engine key is retrieved and loaded into the crypto - engine and the gate is turned on , via step 164 . afterwards , the usb token is dismounted , via step 165 . the ssd is then mounted , via step 166 . the control is then passed on to ssd , via step 167 . if the password is not authenticated , it is checked if the maximum number of attempts ( mnoa ) is exceeded , via step 162 . if so , the counter measure against brute - force attack is activated , via step 163 . otherwise , the number of attempts ( noa ) count is incremented , via step 168 . it then exits , via step 169 , back to the password utility loop 154 of fig1 . although the secure and scalable solid state disk system in accordance with the present invention will function with any of a secure digital ( sd ) card , multimedia card ( mmc ), compact flash ( cf ) card , universal serial bus ( usb ) device , memory stick ( ms ), expresscard , lba - nand , onfi , emmc , and esd ; one of ordinary skill in the art readily recognizes that the disk system would function with other similar memory devices and still be within the spirit and scope of the present invention . although the present invention has been described in accordance with the embodiments shown , one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention . accordingly , many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims .