|
|||
Encrypted == secure?
My interest in encryption is to protect the data when the machine is switched off and potentially lost/stolen.
|
|
|||
Chances are the person who comes into possession of a stolen laptop or desktop won't know what OpenBSD is at all ... but perhaps they'll be motivated to find out. encrypted /home /tmp and /swap should go a long way toward safeguarding data.
While the chances of losing a computer are small but significant. The chances someone with the skill to crack encrypted data (and not even on Windows) is quite an order of magnitude smaller. I've seen too much hardware go missing to think encryption is anything but necessary. |
|
|||
Encrypted data when stolen is as good as deleted.. there is no protection from that, it offers no physical security.. backups would be wise.
|
|
|||
I am separating out this second conversation into its own thread.
While other sites allow threads to meander in whatever direction anyone wants to go, this site has traditionally frowned on such a practice. This is known as hijacking discussion. The reason we politely ask members to respect this request is because new respondents, having different perspectives, questions, & needs frequently take discussion in a different direction as presented by the original poster. This helps provide continuity, it helps when searching is done after the fact (& there is a lot of searching done on this site...), & allows the original poster to continue discussion in whatever direction they originally intended. Original thread: http://www.daemonforums.org/showthread.php?t=5234 Anyone who wishes to contribute to this new thread is free (& encouraged...) to do so. |
|
||||
Thank you, Ocicat.
Let us start with definitions. Data protection: data cannot be deleted/changed, or can be recovered if deleted/changed. Examples: read/only media, archives, backups. Data at rest: Data sitting around on media. Data in motion: Data in use -- in RAM on a processor, being sent over a network, etc. Data encryption: obfuscation of data to make it meaningless to anyone but the originator and a recipient with the proper decryption tools and keys to remove the obfuscation. Keys: Used in combination with encryption / decryption tools to obfuscate or make the data clear. Keys vary in capability, usefulness, complexity of use, ad infinitum, ranging from simple passwords to complex key systems and certification technologies. Authentication: techniques used to identify users of data-at-rest, or senders and recipients of data-in-motion. Authorization: techniques used to permit access to data, or to encryption/decription keys. Key Management: The decisions made about who or what stores or has access to keys, can change keys, and all of the varied authentication systems for those keys, from personal possession or knowledge to certificate authorities and "trust" management. (In my opinion, this is often the most complicated and difficult to understand part of any encryption/decription system. And I further believe it is often the weakest link in any encryption/decryption decision system.) ------ Based on those simple definitions, it should be clear that any encrypted data at rest is not protected unless a protection regimen is instituted. One has nothing to do with the other. ------ There are times when data-in-motion is unencrypted: when the data is being processed by an application, or displayed, or retransmitted. Often, this is not well considered by a data architect. One example that comes to mind is the recent very vocal and noisy NFSv4 thread on misc@ that began here: http://marc.info/?l=openbsd-misc&m=128818996830209&w=2 -- one of the thread posters who kept it going was happy with his NFSv4 implementation because he thought his strong authentication technology secured his organization's medical data. He not only confused authentication with encryption, eventually he mentioned that he'd combined NFSv4 with CIFS retransmissions -- disclosing to the knowledgeable that his implementation was also retransmitting unencrypted data, or data-in-the-clear, to Windows workstations on his open networks. Last edited by jggimi; 2nd November 2010 at 12:36 PM. |
|
|||
Backups are even more important when encryption is being used on the data.
|
|
||||
That actually poses something I've often wondered, is there any operating system that can encrypt the contents of RAM, and decrypt on access? I bet the performance would blow hard but as a proof of concept it would be interesting!
To my knowledge once you turn off the power, whatever was in a PCs RAM fades away a short time later, and not everything in the world is obviously a PC. But during runtime, the only serious protection is trust in your operating systems correctness, which isn't always OpenBSD.
__________________
My Journal Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''. |
|
|||
All program code executes in RAM, obviously, so having it encrypted means that the decryption "on-the-fly" program would have to be in memory unencrypted.. and it would have the information necessary for decrypting other memory, DMA buffers for devices would have to be unencrypted.
On at least OpenBSD, the swap partition is encrypted.. only when a process is relocated back into RAM does it get decrypted. Really though, physical security means putting a lock on your door.. all bets are off if they break into your premises and steal your machine. |
|
|||
In short,
Encrypted != secure, Encrypted == obfuscate Quote:
He did this, as it was described to me, in the event someone of authority ever visiting his home. He could destroy the barcode, and not be able to log in to his computer, explaining that, "I do not know the password; it was randomly generated." Ironically, in a worst case scenario, his computer case also had a magnet on a platform inside. He could pull this platform out of the computer from the outside, and the magnet would fall on top of his hard drive, supposedly 'wiping' the contents of the drive. Ultimately security, as a whole, is an idea we create for ourselves. At least it was for my math professor. |
|
||||
Quote:
Some typical examples of ignorance of implication driving poor decision making (beyond the NFSv4 one I cited above):
|
|
||||
This just in from Bruce Schneier's blog, regarding a talk by Whitfield Diffie at a recent ACCU conference. Highlights mine.
Quote:
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Tool for cracking encrypted session data | J65nko | News | 0 | 9th June 2010 06:31 PM |
Google's encrypted search casts shadow on web analytics | J65nko | News | 6 | 26th May 2010 09:35 PM |
Encrypted Google Search Coming to a Browser near You | Android1 | News | 2 | 24th May 2010 04:47 PM |
how to secure my ftp? | milo974 | OpenBSD Security | 3 | 4th August 2009 03:47 PM |
Encrypted disk compatibility issue | TheLogicInverter | FreeBSD Security | 3 | 30th January 2009 02:59 PM |