Hardware based security solution. Review required!!!

Dear All,

I need to develop a hardware appliance that will be deployed in the
data path between clients and the storage device (for eg. harddisk).
This hardware box should be able to understand the native storage
protocol (eg. SCSI) over which it is travelling , get the data, perform

some operations on the data (eg. mangle the data) and send forward to
the harddisk.


So my query is:
1) How to get started for developing such hardware appliance ? Do we
need to program the logic for it in ASSEMBLY language and burn it into
the eeprom ? Or there are some alternative methods to achieve the same?



2) What are the possible tools available for such types of hardware
programming ?


3) Basically, I need to embedded the protocol specification into my
hardware. Is that practically feasible ? Or I am going in the wrong
direction. Please guide.


Any pointers, references, comments will be of great help.


Thanks and Regards,
Rohit Dhamija

rohit wrote:
Dear All,

I need to develop a hardware appliance that will be deployed in the
data path between clients and the storage device (for eg. harddisk).
This hardware box should be able to understand the native storage
protocol (eg. SCSI) over which it is travelling , get the data, perform

some operations on the data (eg. mangle the data) and send forward to
the harddisk.


So my query is:
1) How to get started for developing such hardware appliance ? Do we
need to program the logic for it in ASSEMBLY language and burn it into
the eeprom ? Or there are some alternative methods to achieve the same?



2) What are the possible tools available for such types of hardware
programming ?


3) Basically, I need to embedded the protocol specification into my
hardware. Is that practically feasible ? Or I am going in the wrong
direction. Please guide.


Any pointers, references, comments will be of great help.


Thanks and Regards,
Rohit Dhamija


I think what you're trying to develop here has already been done by
companies like NeoScale and Decru. Maybe there are some pointers for
you on their respective websites.

"rohit" wrote in message
ups.com...
Dear All,

I need to develop a hardware appliance that will be deployed in the
data path between clients and the storage device (for eg. harddisk).
This hardware box should be able to understand the native storage
protocol (eg. SCSI) over which it is travelling , get the data, perform

some operations on the data (eg. mangle the data) and send forward to
the harddisk.


Depending on the market you're developing for, you could use a general
purpose x86 board and look at some of the Linux iSCSI Target software out
there to handle the receiving of SCSI commands. If you're able to also add a
target-mode SCSI driver for a common SCSI HBA then you're in business. From
that point on you can do anything with the data you'd like.

If you really want to develop hardware then contact a SCSI chip vendor such
as QLogic. They have chipsets specifically designed for harddisks. Most of
the SCSI protocol can be offloaded to these chips, and you can use any
suitable processor behind them to mangle/encrypt your data. Encryption does
require a fair amount of CPU power, so look at higher-end embedded CPU's.
Something like an ARM processor core could do the trick..

Rob

Hi Rob,

Thanks for your valuable comments.

I have some idea in order to build a sample pilot project for the same,
please send your expert comments/suggestions on the same:

Step1) The entire logic will be burnt in the hardware. We shall have to
take the hardware with embedded OS pre installed in it - Embedded
Linux.

Step2) So now i can do the programming on a Linux machine and then
port (i.e. burn) the same program logic into the hardware.

Am I correct in this ? If yes, I intend to take 3 computer machine
having Linux installed on it.
1st computer - will act as a client
2nd computer - will act as myhardware appliance. 2nd computer will be
my devlopment machine. Initially it will contain logic to undersand
SCSI protocol only.
3rd computer - will act as Storage device.

Finally I will burn the logic into the hardware. Can you please tell if
there are such hardware available in the market.

Please send your useful comments suggestions.
Thanks and Regards,
Rohit
Rob Turk wrote:
"rohit" wrote in message
ups.com...
Dear All,

I need to develop a hardware appliance that will be deployed in the
data path between clients and the storage device (for eg. harddisk).
This hardware box should be able to understand the native storage
protocol (eg. SCSI) over which it is travelling , get the data, perform

some operations on the data (eg. mangle the data) and send forward to
the harddisk.


Depending on the market you're developing for, you could use a general
purpose x86 board and look at some of the Linux iSCSI Target software out
there to handle the receiving of SCSI commands. If you're able to also add a
target-mode SCSI driver for a common SCSI HBA then you're in business. From
that point on you can do anything with the data you'd like.

If you really want to develop hardware then contact a SCSI chip vendor such
as QLogic. They have chipsets specifically designed for harddisks. Most of
the SCSI protocol can be offloaded to these chips, and you can use any
suitable processor behind them to mangle/encrypt your data. Encryption does
require a fair amount of CPU power, so look at higher-end embedded CPU's.
Something like an ARM processor core could do the trick..

Rob

Hi Jon,

Yes, Decru and Neoscale are doing this job, but we are targetting for
future storage technologies and looking forward to make a single
unified storage security appliance.

Thanks,
Rohit

Jon Metzger wrote:
rohit wrote:
Dear All,

I need to develop a hardware appliance that will be deployed in the
data path between clients and the storage device (for eg. harddisk).
This hardware box should be able to understand the native storage
protocol (eg. SCSI) over which it is travelling , get the data, perform

some operations on the data (eg. mangle the data) and send forward to
the harddisk.


So my query is:
1) How to get started for developing such hardware appliance ? Do we
need to program the logic for it in ASSEMBLY language and burn it into
the eeprom ? Or there are some alternative methods to achieve the same?



2) What are the possible tools available for such types of hardware
programming ?


3) Basically, I need to embedded the protocol specification into my
hardware. Is that practically feasible ? Or I am going in the wrong
direction. Please guide.


Any pointers, references, comments will be of great help.


Thanks and Regards,
Rohit Dhamija


I think what you're trying to develop here has already been done by
companies like NeoScale and Decru. Maybe there are some pointers for
you on their respective websites.

"rohit" wrote in message
ups.com...
Hi Rob,

Thanks for your valuable comments.

I have some idea in order to build a sample pilot project for the same,
please send your expert comments/suggestions on the same:

Step1) The entire logic will be burnt in the hardware. We shall have to
take the hardware with embedded OS pre installed in it - Embedded
Linux.

Step2) So now i can do the programming on a Linux machine and then
port (i.e. burn) the same program logic into the hardware.

Am I correct in this ? If yes, I intend to take 3 computer machine
having Linux installed on it.
1st computer - will act as a client
2nd computer - will act as myhardware appliance. 2nd computer will be
my devlopment machine. Initially it will contain logic to undersand
SCSI protocol only.
3rd computer - will act as Storage device.

Finally I will burn the logic into the hardware. Can you please tell if
there are such hardware available in the market.

Please send your useful comments suggestions.
Thanks and Regards,
Rohit

If you intend to have a SCSI and/or Fibre inputs on your device then I think
you'll end up with a standard x86-based server and a decent programmable
SCSI and/or Fibre host adapter. Designing a custom board that has the target
controller chip of your choise on it, together with a properly specced CPU
and memory is expensive. If you're really off designing a commercially
viable solution then you'll need some serious design. System performance,
data path bandwidth etc. are usually pretty hard to design if you go all
custom. Buying off-the-shelf hardware for embedded systems usually ends up
being an x86 server, making the design easier and the required hardware
cheaper.

As much as I like Linux, I would use a Windows iSCSI initiator to test with
if you want to design for a broad market. Other than that, a Linux system to
develop on and a system acting as Virtual Storage device sounds OK.

Rob

Thanks Rob, I will probably go with the logic i mentioned to develop
the pilot. Please let me know incase have some other/more ideas...

regards,
rohit
Rob Turk wrote:
"rohit" wrote in message
ups.com...
Hi Rob,

Thanks for your valuable comments.

I have some idea in order to build a sample pilot project for the same,
please send your expert comments/suggestions on the same:

Step1) The entire logic will be burnt in the hardware. We shall have to
take the hardware with embedded OS pre installed in it - Embedded
Linux.

Step2) So now i can do the programming on a Linux machine and then
port (i.e. burn) the same program logic into the hardware.

Am I correct in this ? If yes, I intend to take 3 computer machine
having Linux installed on it.
1st computer - will act as a client
2nd computer - will act as myhardware appliance. 2nd computer will be
my devlopment machine. Initially it will contain logic to undersand
SCSI protocol only.
3rd computer - will act as Storage device.

Finally I will burn the logic into the hardware. Can you please tell if
there are such hardware available in the market.

Please send your useful comments suggestions.
Thanks and Regards,
Rohit

If you intend to have a SCSI and/or Fibre inputs on your device then I think
you'll end up with a standard x86-based server and a decent programmable
SCSI and/or Fibre host adapter. Designing a custom board that has the target
controller chip of your choise on it, together with a properly specced CPU
and memory is expensive. If you're really off designing a commercially
viable solution then you'll need some serious design. System performance,
data path bandwidth etc. are usually pretty hard to design if you go all
custom. Buying off-the-shelf hardware for embedded systems usually ends up
being an x86 server, making the design easier and the required hardware
cheaper.

As much as I like Linux, I would use a Windows iSCSI initiator to test with
if you want to design for a broad market. Other than that, a Linux system to
develop on and a system acting as Virtual Storage device sounds OK.

Rob

On 13 Sep 2006 09:54:50 -0700, "rohit"
wrote:

Rob is giving you good advice.

Modern SCSI chips such as from LSI, Qlogic, and Adaptec represent a
massive amount of accumulated intelligence. They are in highly
specialized programmable microprocessors with custom interface
circuitry. These companies only are sharing this hard won knowledge in
the form of silicon.

You almost certainly will spend a very large amount of time
(think many months) just implementing a rudimentary version of the
SCSI protocol. It won't be reliable and no one is going to share with
you the weird and special cases to test for to proof out your design.

Stand on the shoulders of giants and use your talents to add something
new.



Thanks Rob, I will probably go with the logic i mentioned to develop
the pilot. Please let me know incase have some other/more ideas...

regards,
rohit

If you intend to have a SCSI and/or Fibre inputs on your device then I think
you'll end up with a standard x86-based server and a decent programmable
SCSI and/or Fibre host adapter. Designing a custom board that has the target
controller chip of your choise on it, together with a properly specced CPU
and memory is expensive. If you're really off designing a commercially
viable solution then you'll need some serious design. System performance,
data path bandwidth etc. are usually pretty hard to design if you go all
custom. Buying off-the-shelf hardware for embedded systems usually ends up
being an x86 server, making the design easier and the required hardware
cheaper.

As much as I like Linux, I would use a Windows iSCSI initiator to test with
if you want to design for a broad market. Other than that, a Linux system to
develop on and a system acting as Virtual Storage device sounds OK.

Rob

Thanks Jake,

My ultimate idea is not to add only ScSI but to support protocols are
still evolving, like iFCP, iScSI, NetInfinity, etc... and make it
extensible to that future protocols should be added without any
issues..

Regards,
Rohit Dhamija
Jake Gittes wrote:
On 13 Sep 2006 09:54:50 -0700, "rohit"
wrote:

Rob is giving you good advice.

Modern SCSI chips such as from LSI, Qlogic, and Adaptec represent a
massive amount of accumulated intelligence. They are in highly
specialized programmable microprocessors with custom interface
circuitry. These companies only are sharing this hard won knowledge in
the form of silicon.

You almost certainly will spend a very large amount of time
(think many months) just implementing a rudimentary version of the
SCSI protocol. It won't be reliable and no one is going to share with
you the weird and special cases to test for to proof out your design.

Stand on the shoulders of giants and use your talents to add something
new.



Thanks Rob, I will probably go with the logic i mentioned to develop
the pilot. Please let me know incase have some other/more ideas...

regards,
rohit

If you intend to have a SCSI and/or Fibre inputs on your device then I think
you'll end up with a standard x86-based server and a decent programmable
SCSI and/or Fibre host adapter. Designing a custom board that has the target
controller chip of your choise on it, together with a properly specced CPU
and memory is expensive. If you're really off designing a commercially
viable solution then you'll need some serious design. System performance,
data path bandwidth etc. are usually pretty hard to design if you go all
custom. Buying off-the-shelf hardware for embedded systems usually ends up
being an x86 server, making the design easier and the required hardware
cheaper.

As much as I like Linux, I would use a Windows iSCSI initiator to test with
if you want to design for a broad market. Other than that, a Linux system to
develop on and a system acting as Virtual Storage device sounds OK.

Rob