Re: Random access to an encrypted file

Discussion in 'Java' started by Martin Gregorie, Apr 26, 2010.

  1. 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 |
    Martin Gregorie, Apr 26, 2010
    #1
    1. Advertising

  2. 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?
    Mike Schilling, Apr 26, 2010
    #2
    1. Advertising

  3. 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 |
    Martin Gregorie, Apr 27, 2010
    #3
  4. rossum wrote:
    > 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?

    > 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.
    Mike Schilling, Apr 27, 2010
    #4
  5. 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?
    Mike Schilling, Apr 27, 2010
    #5
  6. Martin Gregorie

    Abu Yahya Guest

    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/site.wss/YAST-3JXNTY.html.
    Abu Yahya, Apr 27, 2010
    #6
  7. 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
    RedGrittyBrick, Apr 27, 2010
    #7
  8. 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 |
    Martin Gregorie, Apr 27, 2010
    #8
  9. Martin Gregorie

    Lew Guest

    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
    Lew, Apr 27, 2010
    #9
  10. 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
    Arne Vajhøj, Apr 28, 2010
    #10
  11. Arne Vajhøj wrote:
    > 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
    >

    No, security should not rely on every employee being with the company,
    but the general point is still a good one. Consultants such as myself
    spend most of their time on client sites and so much of our
    disgruntlement (or gruntlement) stems from client behaviour, not from
    the actions of our own companies. If we've been with one client long
    enough we actually start feeling like we're with that client, and the
    feeling is mutual...provided that it's a good client. So Lew's arguments
    apply.

    AHS
    Arved Sandstrom, Apr 28, 2010
    #11
  12. Martin Gregorie

    The Frog Guest

    I find it amazing that everyone is throwing around encryption
    suggestions like pills for the common cold here. I have come to
    respect the contributors to thsi group greatly as the bredth and depth
    of knowledge in the Java environment is truly overwhelming. I am not
    able to say the same about the understanding of security and
    cryptography.

    Let me see if I can explain why:

    Firstly security and cryptography are two separate things. Security
    may use cryptography as a tool to get the job done but never the other
    way around. That means that cryptography by itself is not security. In
    short security is not a product, and algorithm, or a 'system', but in
    fact a method to achieve a goal. This method is rooted in risk
    analysis and the application of tools, designs and methods to mitigate
    those risks.

    The small encrypted partition that is mentioned in a previous post may
    provide some risk mitigation against a physical theft but may also not
    provide any risk mitigation against other forms of attack - such as IP
    based attacks. A simple example to be sure, but it makes the point
    quite clearly: Cryptography is not a cure all.

    If the OP is indeed wanting to mitigate riks for legal compliance or
    insurance complaince then the best thing they can do is to review
    their needs and situation with an experienced professional who
    understands how to correctly manage these risks. This is most probably
    not a trivial task, and from my experience in software development,
    inclusing inside the security industry, it often times requires a
    complete restructuring of the operational mechanisms of the program /
    application / network / system / trust model / cryptography in
    question. Unfortunately it is not realistic to slap on a security band-
    aid to cover up a risk and expect a secure outcome.

    I hope I dont upset anyone with this, however I felt it necessary to
    share the broader picture with the OP given the lack of context they
    have provided.

    Cheers

    The Frog
    The Frog, Apr 28, 2010
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kevin
    Replies:
    19
    Views:
    1,118
    Tris Orendorff
    Feb 13, 2006
  2. globalrev
    Replies:
    4
    Views:
    745
    Gabriel Genellina
    Apr 20, 2008
  3. John B. Matthews

    Re: Random access to an encrypted file

    John B. Matthews, Apr 27, 2010, in forum: Java
    Replies:
    1
    Views:
    383
    The Frog
    Apr 29, 2010
  4. Roedy Green
    Replies:
    2
    Views:
    620
    Mike Schilling
    Apr 28, 2010
  5. VK
    Replies:
    15
    Views:
    1,126
    Dr J R Stockton
    May 2, 2010
Loading...

Share This Page