[bulug] Re: LUG Server: Purchased
- From: Alex Whittemore <alexwhittemore@xxxxxxxxx>
- To: bulug-list@xxxxxxxxxxxxx
- Date: Sat, 9 May 2009 00:53:13 -0400
I think you're confusing the key in memory as somehow only existing once.
The key is generated by a password. Yes, when the memory goes down, it's
lost, and the data is encrypted. But the data can still be unencrypted by
the same key. The key is generated by a password. Yes, an admin has to enter
that. I suppose you could work out a solution where the encryption key is
generated by two independent passwords, but let's be realistic, we're not
going to write our own encryption software. It's not going to happen. You
can, however, use a password combined with a keyfile. That might be just as
good. Give one admin control over the password, and one admin control over
the keyfile. Problem solved.
On Sat, May 9, 2009 at 12:42 AM, Jimmy C. Chau <jchau@xxxxxx> wrote:
> Alex Whittemore wrote:
> > The whole ramdisk thing is kind of a moot point for a few reasons.
> >
> > Your security concern:
> > -The data is sensitive, and if a person with physical access to the
> > machine yanked the drive, they'd have it.
> >
> > Your solution:
> > -put the data on a ramdisk so that it cant be easily grabbed
> >
> > Why that's impractical:
> > -if you're leaving ALL the data on a ramdisk, what if the server
> > crashes? you're screwed, and all the data is gone. The better solution
> > is to simply encrypt it, and leave the key in ram (which is how normal
> > encryption systems work).
> >
> Yes, this would be more practical. But still, in this case, the info
> would be lost anyway in case of a crash since the key would be lost.
> However, this information does *not* need to persist due to periodic
> updates by the client (unless the server is somehow shutdown during the
> theft, in which case, the server would be ineffective anyway). In fact,
> I think that losing this tracking information on shutdown may be a good
> thing since the information probably becomes out-of-date and can serve
> no purpose other than seeing where a laptop has been (and not for
> anti-theft purposes).
> > An important thing to consider is that most of this security relies on
> > the physical security of the machine in the first place. Failing that,
> > it's important to note that, with 3 storage drives in raid 5, the
> > criminal with physical access would have to steal at least two to have
> > all the data. Even assuming that, if it's encrypted, game over. The
> > only solution, which you recognize as possible, is a cold boot attack,
> > which is highly impractical for a number of reasons, not the least of
> > which is that the ram in question requires at minimum a desktop to
> > read. That is, to execute a successful cold boot, the criminal would
> > have to A. have physical access, B. have carried a desktop computer to
> > the location of the server, set it up, and prepped it, C, know HOW to
> > execute a cold boot attack, D. actually USE the key he discovered to
> > then decrypt the drives, which is no small feat.
> >
> What I mentioned was to make it more difficult for someone authorized to
> access the tracking information for every laptop to abuse this power
> without being detected: e.g., if admin Tom (someone who *does* have
> access to the system) decides to track user Jill when user Jill's
> computer is *not* being stolen. These measures are not to prevent the
> system from being destroyed or disabled, simply privacy safeguards.
> This safeguard was to prevent a privileged admin from temporarily
> shutting down the system, and reading this data directly from the hard
> drive without being logged. But storing the key to this data in RAM as
> you mentioned also prevents this (granted that the key is forever lost
> and not some password chosen by one admin).
> > Basically, it's possible, but you just don't need to worry about it.
> >
> > All in all, you might as well just store the data insecurely, but in a
> > truecrypt encrypted partition. The data is stored securely on the fly,
> > and as soon as the server loses power, it's locked.
> About encrypted drives... I don't think they cope well with power loss.
> An interrupted write may corrupt the encrypted data, preventing it from
> being decrypting.
> > Regardless of the solution you use, if you're encrypted, the real pain
> > is having an admin enter the password/key every boot of the system.
> Yes, this would be a pain. See my last email for a partial solution.
> But the admins will still need to authenticate every time this
> anti-theft system starts on the server to protect the end user.
>
> --
> -Jimmy C. Chau
> <jchau@xxxxxx>
> <chaujc@xxxxxxxxx>
> GPG key ID: 0x8C6AA349
> GPG key fingerprint: D889 2B2D E20F A07E 0D54 4280 9C14 D4F6 8C6A A349
> _________
> BU LUG: http://lug.bu.edu. To unsubscribe, email
> bulug-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field.
>
Other related posts:
