LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reading/writing/mounting/unmounting portable memory devices on classified test systems

This is a long post, if you want a "reader's-digest" version, read the last paragraph...

I'm soliciting a solution to something that currently plagues all players in U.S.-government or DoD defense-electronics manufacturing industries: moving small quantities of data on and off classified information-systems.  Background reading on performing "trusted downloads" of data to-and-from a classified test system and the restrictions of non-volatile memory devices inside any aspect of said test system, as outlined in the DSS's NISPOM document, chapter 8 can be found here.

Here's the problem domain:
There needs to be a way to store "small quantities" (several MB's) of data on a, portable, low-cost or disposable, re-writable, non-volatile medium, in a way that is quick, easy, and transparent to the operator of the system.  In addition, this particular data will be constantly updated and re-stored to this style of medium (perhaps the same medium itself) during testing on a daily basis over many years (it is cumulative data).   And because we are dealing with long-term military-program manufacturing which can last decades, it should use a storage technology and interface that is very entrenched, and shows a high promise of longevity and future applicability within the computer industry. Once written to, this storage "medium" must be easily removable from the test system, and stored in a DSS-approved, secure metal container under lock and key.  Data on this storage medium can only be extracted via a "trusted download" procedure before the data can be used outside of the classified computer system of origin, which is described in a bit more detail below.  Obviously, any wireless solutions cannot be considered.

Historically, this problem was first solved using 5" floppies, followed by 3.5" floppies, followed by 100 MB ZIP, then 1 GB JAZ drives.  Floppies are on their way out now, and ZIP and Jaz don't appear to be standing the test of time now that 1 GB USB memory sticks abound at reasonable prices.  In fact, using USB memory sticks to solve this problem appears to be an ideal solution, doesn't it?  CD-R's and CD-RW's meet most of the above requirements, but they require some human intervention to set up the files to write to the medium, and then some time to actually write them.   Using a generic card reader in the test-controller with compact-flash or SD (secure digital) or other similar medium might work, but when you get to the target system, will it have the interface for it?.  But since I'm inviting you into a brain-storming session, you are welcome to propose any other medium that you think best solves the problem domain.  Who's to say that the Apple IPod (or a similar miniature portable hard drive in widespread use, yet much cheaper) would be a better solution.

Migrating "small-quantities" of data off the test system must be done via something called a "trusted download", which consists of processing the data on this storage medium through a "dirty-word" search (sorry I cannot elaborate more on this).  Once found to be in compliance, it can be moved to any unclassified computer system.

So, if you made it down to this final paragraph, it appears that certain flash memory devices might offer a solution to this problem.  If so, what remains is a way to programatically read and write to the medium, which also implies that there is an easy way to programmatically (or automatically) mount and unmount the storage medium to the computer system as well.  USB flash memory sticks already have that covered, or so it seems.  Not sure if the same could be said for all flash-memory-based card readers.  But if that is the medium we choose, now there is the task of having all the provisions in an ATE program to search for the memory stick within the operating system before it writes to it, gracefully stop writing to it if it is removed in an "un-announced" fashion, and be able to perform flawlessly all the fopen (), fflush () and fclose () error-handling issues should the flash memory become erratic due to file-fragmentation or running out of free space to write to (which reminds me of my bad experiences with Jaz cartridges).  For those of you who have an entrepreneurial spirit, there is a market opportunity here to solve a problem that could be simple to produce, yet could become a de-facto standard across millions of computers in the U.S. DoD -related industries.
--
To whom it may concern: My alias is also my nickname, I've had it since I was a (very) skinny basketball-playing teen. OK, so I've got a 38 inch waist now, but my hometown friends haven't shaken that appellation for me. I trust that you will someday be OK with that alias, as I have been with that nickname.
0 Kudos
Message 1 of 1
(2,123 Views)