I think you should go through disk perf sample first. That will give you a
clear idea of what disk level filter driver needs to implement, and what is
its general architecture. Once you have got hold of that, then if you have
any specific question, post it here.
-Kiran
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Amitrajit Banerjee.
Sent: Friday, June 10, 2005 7:10 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] disk encryption
hey all,
if i want to encrypt all content of a disk, sector wise, I believe i need to
write a driver that attaches itself to disk.sys.
Exactly which all IRPs I need to trap and monitor? Ofcourse, I need to
decrypt the disk also. Forget complexities regarding boot time decryptions.
Just tell me the IRPS I need to monitor.
amitr0
Note:-
- Spelling Mistakes and Grammatical Errors, If Any, Are Regretted.
- Kindly Acknowledge This Mail At The Earliest.
- This E-Mail Might contain Confidential information. If You Are Not
Entitled
To View it, Please Delete The Message Immediately And Inform Me.
Thanking You,
Amitrajit Banerjee.
http: — Questions? First
check the IFS FAQ at https://www.osronline.com/article.cfm?id=17 You are
currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’ To
unsubscribe send a blank email to xxxxx@lists.osr.com</http:>
IRP_MJ_READ and IRP_MJ_WRITE requests are what you will need to handle. If
you are actually changing other pieces of information such as disk size that
you want to ‘fake’, then you will need to intercept the Device control
requests. But for encryption/decryption just the read and write irps are all
you need.
Pete
Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Amitrajit Banerjee.
Sent: Friday, June 10, 2005 7:40 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] disk encryption
hey all,
if i want to encrypt all content of a disk, sector wise, I believe i need to
write a driver that attaches itself to disk.sys.
Exactly which all IRPs I need to trap and monitor? Ofcourse, I need to
decrypt the disk also. Forget complexities regarding boot time decryptions.
Just tell me the IRPS I need to monitor.
amitr0
Note:-
- Spelling Mistakes and Grammatical Errors, If Any, Are Regretted.
- Kindly Acknowledge This Mail At The Earliest.
- This E-Mail Might contain Confidential information. If You Are Not
Entitled
To View it, Please Delete The Message Immediately And Inform Me.
Thanking You,
Amitrajit Banerjee.
http: — Questions? First
check the IFS FAQ at https://www.osronline.com/article.cfm?id=17 You are
currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’ To
unsubscribe send a blank email to xxxxx@lists.osr.com</http:>
I would think that Device control must be handled, given that using pass-through on XP SP2, I can read and write anything that I want, on either SCSI or ATA/IDE interfaces, given that I am logged in as admin. On XP SP1 and below this might not be as critical since pass-through for ATA/IDE was more limited in scope than it is in Server 2003 or XP XP2. Basically it was “broken” in SP1 and fixed in SP2.
But this still will not deny access to the thief that can transfer the encrypted drive to another machine where they then can do what is needed to break the encryption. The hole in the plan to encrypt a drive using runtime software is that access can only be denied while that software is running. Run another OS, or disable the encrypting software, and whoever you were attempting to deny access to now has access. All that is needed is a bit of time and the proper tools.
–
The personal opinion of
Gary G. Little
“Peter Scott” wrote in message news:xxxxx@ntfsd…
IRP_MJ_READ and IRP_MJ_WRITE requests are what you will need to handle. If you are actually changing other pieces of information such as disk size that you want to ‘fake’, then you will need to intercept the Device control requests. But for encryption/decryption just the read and write irps are all you need.
Pete
Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
------------------------------------------------------------------------------
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Amitrajit Banerjee.
Sent: Friday, June 10, 2005 7:40 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] disk encryption
hey all,
if i want to encrypt all content of a disk, sector wise, I believe i need to write a driver that attaches itself to disk.sys.
Exactly which all IRPs I need to trap and monitor? Ofcourse, I need to decrypt the disk also. Forget complexities regarding boot time decryptions. Just tell me the IRPS I need to monitor.
amitr0
Note:-
1) Spelling Mistakes and Grammatical Errors, If Any, Are Regretted.
2) Kindly Acknowledge This Mail At The Earliest.
3) This E-Mail Might contain Confidential information. If You Are Not Entitled
To View it, Please Delete The Message Immediately And Inform Me.
Thanking You,
Amitrajit Banerjee.
— Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17 You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email to xxxxx@lists.osr.com
> But this still will not deny access to the thief that can transfer
the encrypted drive to another machine where they then can
do what is needed to break the encryption.
The hole in the plan to encrypt a drive using runtime software
is that access can only be denied while that software
I don’t understand this well - this is a problem of every
encryption, isn’t it ? Then the question is how strong
is the encryption method. Of course, you cannot deny
access to the physical drive on another computer,
but you’ll not be able to get the data (this is the goal).
Of course if you use a XOR encryption method, then the whole
work is worth nothing, but if the disk is encrypted e.g.
using AES ?
L.
XOR with the crypto-quality byte stream is also good (and fast). RC4 works this way.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Ladislav Zezula
To: Windows File Systems Devs Interest List
Sent: Monday, June 13, 2005 9:23 AM
Subject: Re: Re:[ntfsd] disk encryption
But this still will not deny access to the thief that can transfer
> the encrypted drive to another machine where they then can
> do what is needed to break the encryption.
> The hole in the plan to encrypt a drive using runtime software
> is that access can only be denied while that software
I don’t understand this well - this is a problem of every
encryption, isn’t it ? Then the question is how strong
is the encryption method. Of course, you cannot deny
access to the physical drive on another computer,
but you’ll not be able to get the data (this is the goal).
Of course if you use a XOR encryption method, then the whole
work is worth nothing, but if the disk is encrypted e.g.
using AES ?
L.
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
An encrypting drive takes security beyond the ability to simply move a drive to a different machine or disable the encrypting software. With an encrypting HDD the firmware on the drive does the encrypting, and unless the user provides the proper credentials, the drive will not even allow a read, or write to take place. What I am saying is that if you deny a nefarious user the ability to access a disc in any system, whether or not it has the proper software, you have thrown up another hurdle they have to clear before they can succeed in their nefarious task.
Also, if I am not mistaken, there was a vulnerability recently found in SHA-1 encryption.
–
The personal opinion of
Gary G. Little
“Maxim S. Shatskih” wrote in message news:xxxxx@ntfsd…
XOR with the crypto-quality byte stream is also good (and fast). RC4 works this way.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Ladislav Zezula
To: Windows File Systems Devs Interest List
Sent: Monday, June 13, 2005 9:23 AM
Subject: Re: Re:[ntfsd] disk encryption
> But this still will not deny access to the thief that can transfer
> the encrypted drive to another machine where they then can
> do what is needed to break the encryption.
> The hole in the plan to encrypt a drive using runtime software
> is that access can only be denied while that software
I don’t understand this well - this is a problem of every
encryption, isn’t it ? Then the question is how strong
is the encryption method. Of course, you cannot deny
access to the physical drive on another computer,
but you’ll not be able to get the data (this is the goal).
Of course if you use a XOR encryption method, then the whole
work is worth nothing, but if the disk is encrypted e.g.
using AES ?
L.
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
SHA-1 is not encryption. It is a digital signature method. MD4, MD5 and
SHA-1 have some instances of collisions. However it is unrealistic to
believe that you can take an infinite number of files and create a small
hash of them and never have a collision. SHA has the 512, 1024, and I think
a 2048 variation that have no discovered collisions thus far.
Doing the encryption closer to the platters is of course the best idea.
There is the communications between the cpu and the hard drive that is
vulnerable to interception with a bus analyzer or a device driver in the
storage stack.
“Gary G. Little” wrote in message news:xxxxx@ntfsd…
An encrypting drive takes security beyond the ability to simply move a drive
to a different machine or disable the encrypting software. With an
encrypting HDD the firmware on the drive does the encrypting, and unless the
user provides the proper credentials, the drive will not even allow a read,
or write to take place. What I am saying is that if you deny a nefarious
user the ability to access a disc in any system, whether or not it has the
proper software, you have thrown up another hurdle they have to clear before
they can succeed in their nefarious task.
Also, if I am not mistaken, there was a vulnerability recently found in
SHA-1 encryption.
–
The personal opinion of
Gary G. Little
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
XOR with the crypto-quality byte stream is also good (and fast). RC4
works this way.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Ladislav Zezula
To: Windows File Systems Devs Interest List
Sent: Monday, June 13, 2005 9:23 AM
Subject: Re: Re:[ntfsd] disk encryption
> But this still will not deny access to the thief that can transfer
> the encrypted drive to another machine where they then can
> do what is needed to break the encryption.
> The hole in the plan to encrypt a drive using runtime software
> is that access can only be denied while that software
I don’t understand this well - this is a problem of every
encryption, isn’t it ? Then the question is how strong
is the encryption method. Of course, you cannot deny
access to the physical drive on another computer,
but you’ll not be able to get the data (this is the goal).
Of course if you use a XOR encryption method, then the whole
work is worth nothing, but if the disk is encrypted e.g.
using AES ?
L.
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
> An encrypting drive takes security beyond the ability to simply move a
drive to a different machine or disable the encrypting software. With
an
A bit too much. According to basic encryption theories, the
encryption is the only hard to break part. It is only a matter of hours
before a generic reader for such firmware is made.
Also, if I am not mistaken, there was a vulnerability recently found
in SHA-1 encryption.
SHA-1 hash digest, yes.
–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Even if the digest is 2048-bit (256 byte), there’s a certainty a collision will
be found in all 256-byte file content combinations even - more than once probably.
The SHA-1 digest vulnerability, IIRC, referred to two similar contents having the
same digest - which is the real threat (a binary and text file having the same digest
aren’t a threat as much as the data is too different).
SHA-1 is not encryption. It is a digital signature method. MD4, MD5 and
SHA-1 have some instances of collisions. However it is unrealistic to
believe that you can take an infinite number of files and create a small
hash of them and never have a collision. SHA has the 512, 1024, and I think a 2048
variation that have no discovered collisions thus far.
–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
He may not get to the data, but if the bad guy is interested in other information, he may be able to acquire what he wants to the detremint of the legitimate disc owner. An HDD with secure firmware will not even allow access without the proper credentials, whether or not the disc has been removed from the computer.
–
Gary G. Little
“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> But this still will not deny access to the thief that can transfer
> the encrypted drive to another machine where they then can
> do what is needed to break the encryption.
> The hole in the plan to encrypt a drive using runtime software
> is that access can only be denied while that software
I don’t understand this well - this is a problem of every
encryption, isn’t it ? Then the question is how strong
is the encryption method. Of course, you cannot deny
access to the physical drive on another computer,
but you’ll not be able to get the data (this is the goal).
Of course if you use a XOR encryption method, then the whole
work is worth nothing, but if the disk is encrypted e.g.
using AES ?
L.