Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Re: Random access to an encrypted file

Reply
Thread Tools

Re: Random access to an encrypted file

 
 
Martin Gregorie
Guest
Posts: n/a
 
      04-26-2010
On Mon, 26 Apr 2010 10:41:36 -0500, Spud wrote:

> We've been told that we need to implement on-disk encryption of our data
> files. We currently write them using RandomAccessFile and read them
> using FileChannel.read(ByteBuffer).
>

Why not simply store the files in an encrypted disk partition?

The OS does all the grunt-work, including prompting for the password at
boot time, and the application(s) don't need to change. The encryption is
transparent to them because it takes place at a lower level.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
 
 
 
Mike Schilling
Guest
Posts: n/a
 
      04-26-2010
Martin Gregorie wrote:
> On Mon, 26 Apr 2010 10:41:36 -0500, Spud wrote:
>
>> We've been told that we need to implement on-disk encryption of our
>> data files. We currently write them using RandomAccessFile and read
>> them using FileChannel.read(ByteBuffer).
>>

> Why not simply store the files in an encrypted disk partition?
>
> The OS does all the grunt-work, including prompting for the password
> at boot time, and the application(s) don't need to change. The
> encryption is transparent to them because it takes place at a lower
> level.


Then any app that can gain access to open the file can read it as clear
text. Or am I missing something?


 
Reply With Quote
 
 
 
 
Martin Gregorie
Guest
Posts: n/a
 
      04-26-2010
On Mon, 26 Apr 2010 14:28:42 -0700, Mike Schilling wrote:

> Martin Gregorie wrote:
>> On Mon, 26 Apr 2010 10:41:36 -0500, Spud wrote:
>>
>>> We've been told that we need to implement on-disk encryption of our
>>> data files. We currently write them using RandomAccessFile and read
>>> them using FileChannel.read(ByteBuffer).
>>>

>> Why not simply store the files in an encrypted disk partition?
>>
>> The OS does all the grunt-work, including prompting for the password at
>> boot time, and the application(s) don't need to change. The encryption
>> is transparent to them because it takes place at a lower level.

>
> Then any app that can gain access to open the file can read it as clear
> text. Or am I missing something?


True enough. The OP didn't say anything about why they'd been told to
encrypt the files, so I merely offered the simplest solution to
implement. I also assumed that the OP would come back and tell us if disk
volume encryption was unsuitable and, hopefully, why.

Disk volume encryption is good enough to prevent data loss if the disks
are stolen. It will also do the job if the computer is stolen provided it
isn't a laptop that was suspended rather than shut down. I don't know
about a hibernating laptop, but would guess it is secure since
hibernation seems to be just a modified form of a cold boot.

In any case, since this is so simple to implement[*] it should be looked
at first and discarded if unsuitable. After that you can move on and look
at more complex solutions.
[*] Under Linux you just format an encrypted partition and set the
password when prompted by the formatter. Each time the partition is
mounted you get prompted for its password. Doubtless its about equally
simple to use under Windows and other OSen.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      04-27-2010
rossum wrote:
> On Mon, 26 Apr 2010 14:28:42 -0700, "Mike Schilling"
> <(E-Mail Removed)> wrote:
>
>> Martin Gregorie wrote:
>>> On Mon, 26 Apr 2010 10:41:36 -0500, Spud wrote:
>>>
>>>> We've been told that we need to implement on-disk encryption of our
>>>> data files. We currently write them using RandomAccessFile and read
>>>> them using FileChannel.read(ByteBuffer).
>>>>
>>> Why not simply store the files in an encrypted disk partition?
>>>
>>> The OS does all the grunt-work, including prompting for the password
>>> at boot time, and the application(s) don't need to change. The
>>> encryption is transparent to them because it takes place at a lower
>>> level.

>>
>> Then any app that can gain access to open the file can read it as
>> clear text. Or am I missing something?

> Any app that knows the password.


It sounds like in the implementation Martin was discussing it's the OS that
needs the password to mount the disk, not each application that uses that
disk.


 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      04-27-2010
Martin Gregorie wrote:
>[*] Under Linux you just format an encrypted partition and set the
> password when prompted by the formatter. Each time the partition is
> mounted you get prompted for its password.


So if the server goes down and back up (say, becasue of a powert glitch), it
can't reboot fully until a human is there to type the password?



 
Reply With Quote
 
Abu Yahya
Guest
Posts: n/a
 
      04-27-2010
Mike Schilling wrote:
> Martin Gregorie wrote:
>>[*] Under Linux you just format an encrypted partition and set the
>> password when prompted by the formatter. Each time the partition is
>> mounted you get prompted for its password.

>
> So if the server goes down and back up (say, becasue of a powert glitch), it
> can't reboot fully until a human is there to type the password?
>
>
>


Lenovo laptops, if I'm not mistaken, have this feature of disk
encryption (called the Hard Disk Password). If you (soft) reboot the
laptop, you don't have to enter the password. But you do have to enter
it if you shutdown and restart, or resume from hibernation.

For more regarding the Lenovo feature, see
http://www-307.ibm.com/pc/support/si...ST-3JXNTY.html.
 
Reply With Quote
 
RedGrittyBrick
Guest
Posts: n/a
 
      04-27-2010
On 27/04/2010 01:58, Mike Schilling wrote:
> Martin Gregorie wrote:
>>[*] Under Linux you just format an encrypted partition and set the
>> password when prompted by the formatter. Each time the partition is
>> mounted you get prompted for its password.

>
> So if the server


The OP didn't say if the computers in question were servers.

> goes down and back up (say, becasue of a powert glitch), it
> can't reboot fully until a human is there to type the password?


But don't most servers live in locked rooms with UPS support and are
therefore less vulnerable than personal PCs to theft or utility power
glitches?

If I had to use data encryption on a server I'd make the OS partition
unencrypted and have the OS fetch the decryption key for the protected
data partition from somewhere relatively safe - in the sense of being
unlikely to be stolen or disposed of in conjunction with the disk.

Whether that safer place was a human would depend on the risks/costs
analysis etc.

--
RGB
 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      04-27-2010
On Mon, 26 Apr 2010 17:58:23 -0700, Mike Schilling wrote:

> Martin Gregorie wrote:
>>[*] Under Linux you just format an encrypted partition and set the
>> password when prompted by the formatter. Each time the partition is
>> mounted you get prompted for its password.

>
> So if the server goes down and back up (say, becasue of a powert
> glitch), it can't reboot fully until a human is there to type the
> password?


Correct. As an experiment I added a small, encrypted partition to my
Linux server. This is used to store sensitive stuff such as web pages
containing account names, passwords, etc. which are made available via a
user name/password mechanism by an in-house Apache web server.

So far the need to input the encryption password if the server reboots is
the only gotcha. The mains is pretty reliable in these parts and the
server 'just runs', so as yet I haven't felt the need to add a UPS.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      04-27-2010
RedGrittyBrick wrote:
> Whether that safer place was a human would depend on the risks/costs
> analysis etc.


In the midst of all the hoopla about viruses and hack-attacks and phishing and
blah-blah-blah, the single greatest threat to anyone's resources, corporate or
personal, remains insider malfeasance. Most misdeeds originate inside the
firewall.

Despite this well-established and long-standing fact, many companies continue
to treat their employees, white- and blue-collar alike, as expendable cogs.
Policies grow more restrictive and ludicrous, until movies like /Office Space/
seem like straight-up documentaries, completely overlooking that it's the
people that make the organization function.

When the organization continues to strive to antagonize and lose the loyalty
of the people who have the inside knowledge, no system or encryption or
automated process will rescue them.

In a culture of loyalty, an evildoer will be spotted and ratted out much more
quickly.

These factors are difficult to quantify and uncomfortable to confront, so too
many organizations leave them out of the risk and cost-benefit analyses.

A software consultant called upon to improve computer security may well serve
their client best by a suggestion to throw monthly parties.

--
Lew
 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      04-27-2010
On 27-04-2010 18:54, Lew wrote:
> RedGrittyBrick wrote:
>> Whether that safer place was a human would depend on the risks/costs
>> analysis etc.

>
> In the midst of all the hoopla about viruses and hack-attacks and
> phishing and blah-blah-blah, the single greatest threat to anyone's
> resources, corporate or personal, remains insider malfeasance. Most
> misdeeds originate inside the firewall.
>
> Despite this well-established and long-standing fact, many companies
> continue to treat their employees, white- and blue-collar alike, as
> expendable cogs. Policies grow more restrictive and ludicrous, until
> movies like /Office Space/ seem like straight-up documentaries,
> completely overlooking that it's the people that make the organization
> function.
>
> When the organization continues to strive to antagonize and lose the
> loyalty of the people who have the inside knowledge, no system or
> encryption or automated process will rescue them.
>
> In a culture of loyalty, an evildoer will be spotted and ratted out much
> more quickly.
>
> These factors are difficult to quantify and uncomfortable to confront,
> so too many organizations leave them out of the risk and cost-benefit
> analyses.
>
> A software consultant called upon to improve computer security may well
> serve their client best by a suggestion to throw monthly parties.


Security should not rely on every employee being with the company.

That will never be the case for a big company with many employees no
matter how good it in general is.

Arne

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Math.random() and Math.round(Math.random()) and Math.floor(Math.random()*2) VK Javascript 15 05-02-2010 03:43 PM
Re: Random access to an encrypted file John B. Matthews Java 1 04-29-2010 08:33 AM
Re: Random access to an encrypted file Roedy Green Java 2 04-28-2010 03:53 AM
random.random(), random not defined!? globalrev Python 4 04-20-2008 08:12 AM
is Random Access File really "random access"? Kevin Java 19 02-13-2006 09:31 PM



Advertisments