Re: [Discuss] NAS: encryption
From: Discuss [mailto:discuss-bounces+blu=nedharvey@blu.org] On Behalf Of Tom Metro You seem to think there's an obstacle which isn't really real - Encryption is very cheap computationally, so cheap indeed it can be done by the disks themselves. Yes, disk that have hardware acceleration for that purpose. Yes, aka self encrypting drives. Which are very common and readily available. If you don't have a self-encrypting drive, then obviously the encryption must be done on your CPU. Some appliances have support for self-encrypting drives. The appliance only needs to store the encryption key somehow (exercise left to reader) and in BIOS, tell the drives to encrypt themselves. I know how Microsoft securely stores the encryption keys in TPM - I can't speak to any other OSes or appliances that use the TPM or other techniques. While we are certainly heading in the direction where the CPU overhead for encryption can be ignored, even in low-end embedded devices, we are not there yet. We are certainly there, *except* in situations with puny cpu's and no hardware acceleration. On a CPU that has AES-NI (the AES New Instruction set, which was new around 6-7 years ago), you can max out your SATA bus and it will utilize around 3-4% CPU time of a single core. This compares to around 30-40% if you don't have AES-NI. But admittedly - this is an x86 laptop processor, which is going to be much more powerful than a little ARM or similar. So even if you lack the hardware acceleration, you don't get CPU performance limited; you just burn some unnecessary CPU power. Doing AES-256 CBC 1024, the Pi is about 10x slower than an i5 per the Agreed. It is not going to work well, to run encryption on an ARM processor without AES hardware acceleration. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
Edward Ned Harvey (blu) wrote: Tom Metro wrote: I imagine it would be challenging to pull off encryption well with appliance hardware. The first problem is getting the software to do it. (Plus all the automation you've previously discussed to set up the keys on boot.) The second challenge is having the horsepower to perform the encryption. Not impossible if they chose their embedded CPU well, but unlikely to be optimized for that. You seem to think there's an obstacle which isn't really real - Encryption is very cheap computationally, so cheap indeed it can be done by the disks themselves. Yes, disk that have hardware acceleration for that purpose. While we are certainly heading in the direction where the CPU overhead for encryption can be ignored, even in low-end embedded devices, we are not there yet. As a point of reference, the SoC in the Raspberry Pi is similar to what is used in some of the NAS appliances. Here are some benchmarks showing how the Raspberry Pi SoC, which lacks AES hardware acceleration, handles encryption: https://inkofpark.wordpress.com/2013/03/30/raspberry-pi-truecrypt-benchmark/ http://www.finnie.org/2015/02/21/raspberry-pi-2-ubuntu-raspbian-benchmarks/ http://stackoverflow.com/questions/31306425/ridiculous-performance-with-openssl-aes-gcm-on-raspberry-pi-2 Doing AES-256 CBC 1024, the Pi is about 10x slower than an i5 per the 2nd link. 30 times slower than a Macbook per the 3rd link. And achieved 2.1 MB/s using TrueCrypt with AES per the (updated) benchmarks linked from the first posting. (Unfortunately the author didn't include the raw disk I/O rate for comparison.) -Tom -- Tom Metro The Perl Shop, Newton, MA, USA Predictable On-demand Perl Consulting. http://www.theperlshop.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On Thu, Jul 09, 2015 at 10:05:14PM -0400, Derek Atkins wrote: It pulls up to 250W so it will cost a little more to power so somewhere around $4000 the first year and $1600/year to operate. WOW!!! Your electricity is EX..PEN...SIVE! Assuming my math is right, 250W is 1kWh every 4 hours, that that means 6kWh/day * 365 days/year == 2190 kWh/year. To cost $1600 to operate you're paying $0.73/kWh!?! I... don't think so. So either your math is wrong or mine is. By my math at 15c/kWh (which is MUCH more that I pay here in Georgia over the course of the year), this would cost $328.50/year to operate. $0.73/kWh does sound high, but in Massachusetts $0.15/kWh only covers the supply charges (as opposed to distribution etc.). However, people paying the $0.15/kWh default rate for their supply charges should look at one of the competitive suppliers. Years ago when I looked the alternatives here mostly served commercial and industrial companies. Yet I enrolled this week with a new supplier and had a couple reasonable choices. I believe the regulation in MA requires utility consolidated billing meaning that you'd still only have to deal with one billing entity, so it should be relatively painless to get a better rate on the supply portion of your bill. I got a somewhat better rate even asking for renewable energy (or so it was labeled at least). Also MA has net metering and I think some loan or build incentives if you can do solar, though there's some kind of cap coming into play on the net metering. (There's a petition about that around for those interested.) What puzzles me is what people are doing at home to use up all that disk space. But that's probably not a productive direction for discussion. Like in the bloated firefox thread, I guess different people have different ways of using their computers. Disclosure: unlike my last two marketing posts, this time I do have a connection to at least one of the companies you could choose, at least for a little bit longer. The place I work writes software for these competitive supppliers and one of our customers is one of your options. But the rates do really look lower, particularly if you can commit to a long term contract. -- Mike Small sma...@sdf.org SDF Public Access UNIX System - http://sdf.org ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
What puzzles me is what people are doing at home to use up all that disk space. My music collection is about 150GB. I like to keep 3 copies of everything so there’s 450GB. I don’t keep a copy offsite in the cloud just because of it’s size. I keep one copy on a USB drive in a fire proof safe. Cheaper and more easily accessible than the cloud, at least for me. Bittorrent Sync keeps my boxes synchronized. I think for video and audio, local storage makes more sense for the technically savvy. I’ve never lost a significant amount of data. - Eric C The one who’s just a simple rsync user, no home NAS here. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On 7/9/2015 10:05 PM, Derek Atkins wrote: Does this $2239 price include the 8 drives? Yes: with 8x3TB. The empty chassis is about $1K. WOW!!! Your electricity is EX..PEN...SIVE! Assuming my math is right, The $1600/year figure includes ISP cost. Yeah, I worded that poorly. Actual electricity is on the order of $35/mo at ~$0.16/kWh. Which in hindsight is too low; that's only the generation charge. Actual electric costs are 40%-50% higher than what I've listed so far so are around $35 for the 4-disk microserver and about $65 for the 8-bay NAS. These are estimates based on full power load 24x7. In reality, processors will downclock and disks will spin down so actual power consumption will be lower. How much lower depends on usage. FWIW, I'm on Natick's fixed rate which at the moment is higher than Eversource but that will change next year when the rates go up again... because mine won't. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
Jack Coats j...@coats.org wrote: Rich, your post reminded me of this sticker I saw: (There is no cloud, it's just someone else's computer) ;-) Amusing but not quite a precise description of the dominant industry trend happening to data centers. The cloud is actually software-defined and software-implemented replacements -- coupled with automated provisioning APIs -- for (almost) all of the hardware I used to buy from the likes of Dell, Cisco, F5, Isilon, and so forth. Cloud security breaches that I've seen so far are different from those at data centers, which provide separate out-of-band management subnets. I've seen script-kiddies who grep through github and other sites for carelessly-posted API keys, and then crank up as many compute instances as the vendor allows, to run whatever rogue software they're seeking to run (probably Bitcoin-mining, though maybe less of that now that it's gotten harder). A more-sophisticated hacker could do a lot more harm than simply racking up a big compute bill. So my point about fighting last year's war is that for most of us who do more or less the same job of infra management as we did 10 years ago, the products we were familiar with back then are utterly irrelevant in 2015. Those are the products you still see on most cert-compliance approved-product lists. The cloud is different in nature, different enough that despite my decades in the industry, I couldn't have predicted how these APIs would come to be defined, and how complex they've gotten to be. Apparently few others foresaw this either; one company managed to get about a 7-year head start on all the others, who are still begging customer prospects to revisit their discounted compute-instance price list. The Cloud, properly defined, is a software-defined model of resources needed to replace EVERY component you'd ever want in a private physical data center. That's been achieved by only one vendor. I think I'm digressing from original topic by a substantial margin, but eventually those of us who fancy bigger NAS boxes for our homes will turn our attention to cloud-based equivalents. Those potential rival cloud vendors are going to have to wake up from a standing stop, toss out OpenStack and all the other cruft, and develop a simpler, faster, cheaper solution to entice us home and small-biz users. -rich ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On 7/9/2015 9:55 AM, Derek Atkins wrote: However. (and this is the big gotcha)... the certification does not talk about HOW the crypto is used! For example, if you're running disk encryption the *crypto* can be fully FIPS compliant, but it could still do something stupid with the FIPS-certified crypto. For example, it could be using ECB mode instead of some chaining mode. Or it could somehow store the keys in an unprotected mode. Yup. There is huge misunderstanding about FIPS and CC. There is the assumption that if it is certified then it is good. That's not what the certifications mean. They mean that a product works as documented when used as documented. If the security profile says it should be using CBC mode and it is in fact using ECB mode then it will not pass and it will not be certified. If the security profile says it should be using ECB mode and it does use ECB mode then it /will/ pass or at least it will not fail on this point because the product conforms to the security profile in this regard. If the security profile does not specify then it might pass anyway. Or it might not depending on the testing level. [...] this is how it works; my understanding was that if the disk is encrypted then it wont give you any data without keys. I.e., you cannot verify the encryption is correct. That's not how SEDs work. Self-encrypting drives are always encrypted using the media encryption key (MEK) stored in the firmware. The MEK is itself encrypted using the key encryption key (KEK). When shipped, the KEK on a self-encrypting drive is null allowing unfettered access to the MEK. When you lock a SED you enter a password or phrase. This is hashed and stored on a small shadow volume on the drive and the MEK is encrypted using the KEK. When the drive is activated in the locked state the host sees only the shadow volume which tells the host that an unlock code is required. You enter the KEK, the firmware compares the hash with the stored hash, and if it matches then the drive decrypts the MEK and tucks it away in volatile memory deep inside the controller. Then the host is told to rescan the drive and voila! it sees the full disk. Verifying the encryption entails replacing the controller with a non-encrypting controller. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
Richard Pieri richard.pi...@gmail.com writes: On 7/8/2015 10:23 AM, ma...@mohawksoft.com wrote: The problem with internal drive encryption is getting any level of disclosure and accountability. This is simply not true. FIPS security profiles are public record. Here's the security profile for the cryptographic module used in several of Seagate's enterprise SEDs: The problem with FIPS certification (and I know this first hand, having been involved in multiple FIPS certifications over the past year) is that all the cert tells you is yes, the AES algorithm is implemented correctly and yes, the FIPS core performs correctly. However. (and this is the big gotcha)... the certification does not talk about HOW the crypto is used! For example, if you're running disk encryption the *crypto* can be fully FIPS compliant, but it could still do something stupid with the FIPS-certified crypto. For example, it could be using ECB mode instead of some chaining mode. Or it could somehow store the keys in an unprotected mode. Basically, FIPS only talks about what's inside the FIPS boundary, but the system as a whole is always much larger than just the FIPS boundary. As I said before, when using the disk's onboard encryption it is unlikely that you could externally verify that the disk is actually encrypting the data properly, unless the disk actually gives you the encrypted content when the crypto is not initialized. I have no idea if this is how it works; my understanding was that if the disk is encrypted then it wont give you any data without keys. I.e., you cannot verify the encryption is correct. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
Rich, On Thu, July 9, 2015 7:50 pm, Richard Pieri wrote: If you want to step up to something a little more enterprise-y, a Synology DS1815+ with 8x3TB is currently $2239 on Amazon right now. Does this $2239 price include the 8 drives? It pulls up to 250W so it will cost a little more to power so somewhere around $4000 the first year and $1600/year to operate. WOW!!! Your electricity is EX..PEN...SIVE! Assuming my math is right, 250W is 1kWh every 4 hours, that that means 6kWh/day * 365 days/year == 2190 kWh/year. To cost $1600 to operate you're paying $0.73/kWh!?! I... don't think so. So either your math is wrong or mine is. By my math at 15c/kWh (which is MUCH more that I pay here in Georgia over the course of the year), this would cost $328.50/year to operate. Rich P. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
Yay, I started a flame war. :-D (Sorry). Anyway, if anybody cares, I'm not a cryptographer but I am a pro crypto developer. The difference is you're a mathematician who understands how to design a good s-box, versus you're a software developer who understands the correct usage of all the crypto components. I'm the latter. If somebody wants my opinion on something, please call my attention to it - I didn't see anything I wanted to respond to, but maybe it was just buried in the noise. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On 7/9/2015 10:47 AM, Rich Braun wrote: I think I'm digressing from original topic by a substantial margin, but eventually those of us who fancy bigger NAS boxes for our homes will turn our attention to cloud-based equivalents. I don't think so. As capacity (or desire for capacity) grows, the need for bandwidth to utilize that capacity grows. Getting that bandwidth from The Cloud is prohibitively (IMO) expensive. My loaded microserver with 4TB of redundant storage cost about $900 for the chassis and drives. I spent around $50 on a good switch and some long cables. Actually running it costs me on the order of $25/mo. My Verizon bill is about $100/mo. So about $2500 for the first year and $1500 per year after that for power and ISP. Meanwhile, 4TB of storage from AWS is ~$100/mo if I did the math right. Getting up to 500MB/s service, the closest to GigE speeds available, from Verizon is $275/mo. So, $3300/year every year. If you want to step up to something a little more enterprise-y, a Synology DS1815+ with 8x3TB is currently $2239 on Amazon right now. It pulls up to 250W so it will cost a little more to power so somewhere around $4000 the first year and $1600/year to operate. Meanwhile, 12TB of storage from AWS is ~$300/mo. The Verizon rate doesn't change. So, $6900/year every year. I really don't see how The Cloud is at all a cost effective replacement for the in-home NAS. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
From: Discuss [mailto:discuss-bounces+blu=nedharvey@blu.org] On Behalf Of Derek Martin The difference is, the software most of us rely on is open source, and is known to have been inspected by some very smart 3rd parties who Au contraire. How did I know this was going to turn into an open source is more secure myth? It's a myth. First of all, no matter what you do, you're putting blind trust into *some* third party. When you download binaries of an open source project, compiled by themselves, you're blindly trusting that they didn't backdoor it when they built it. Sure you could download and build yourself - but then you're placing blind trust in *yourself*. Did you really truly read all the code and understand it all? Of course not. When you get open source code from Red Hat and Debian, you're just shifting your blind trust to a different group of people - who also patch the code with their own patches - which you equally did not read. When Red Hat and Debian download source code from all the 3rd parties, do you really think they read it, much less understand it? They don't do that any more than *you* would, if you were the person downloading and building those packages from source. So you shouldn't place blind trust in them any more than you would in yourself. As evidenced by Shellshock. Second of all, as evidenced by the whole linux kernel RDRAND fiasco 2-3 years ago, even when people *do* read the open source code, flaws get maliciously introduced anyway. And the community can even notice, and get up in arms and throw public temper tantrums and get media involvement - and sometimes the open source software producer will *still* cram the backdoor down your throats. And Red Hat and Debian and everybody else will swallow it and redistribute it. The characteristics that determines whether or not accidental or intentional sabotage is introduced - are the skill and character of the people submitting code. There is no characteristic of open source vs closed source code that fundamentally attract or repel people of good skill or character. Open source and Closed source code have an *equal* proportion of people with good or bad skill and character. But most of all, evidenced by Heartbleed, POODLEv1, POODLEv2, and ShellShock - Nobody's reading the open source code. Since I became a crypto developer a few years ago, I spend my time now reading open source stuff, and observing the behavior of closed source stuff. It is my opinion that both are about equal in terms of crypto correctness. And it is my opinion that both are about equally responsive to submissions, when I report security flaws to them - Both open source and closed source, *sometimes* act on reported flaws, and sometimes don't. But the primitives - block ciphers, hashing functions - are all solid. The weaknesses get introduced in how they're linked together, how they're used, and how the keys are generated and stored/communicated. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On 7/7/2015 6:26 PM, Derek Martin wrote: The difference is, the software most of us rely on is open source, and is known to have been inspected by some very smart 3rd parties who Some very smart 3rd parties? Can you actually name any of them? I mean, can you name the specific people at Red Hat and SuSE and Debian who have done this? I doubt it. Red Hat and SuSE paid atsec for their EAL and FIPS testings and the associated source code examinations. Microsoft also paid atsec for some of their EAL and FIPS testings. As have Samsung, Apple and many others. iSECPartners, who performed the phase 2 audit of the TrueCrpyt source code, have also performed security audits and consulting for Apple and Microsoft. The very smart 3rd parties who have actually examined the open source code are the same very smart 3rd parties that have done so with the closed source code. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
From: John Abreau [mailto:abre...@gmail.com] Edward Ned Harvey (blu) b...@nedharvey.com writes: You seem to think there's an obstacle which isn't really real - Encryption is very cheap computationally, so cheap indeed it can be done by the disks themselves. Â On Tue, Jul 7, 2015 at 1:14 PM, Derek Atkins warl...@mit.edu wrote: I don't trust my disks to do the encryption, mostly because there's really no way to verify that it's doing it correctly, and the key management gets a lot harder. The way I read it, the message wasn't that you should trust the disk to do the encryption; it's that encryption has very low overhead today, and the reference to disk-based encryption was merely to illustrate that point. It seems silly not to trust the disk to do encryption, when you'd trust some software that you equally haven't decompiled and inspected. The difference is that with open source software, specifically the crypto library in openssl, because that's how people get FIPS certified, many people do audit the code. Maybe not you, but many, and the fact that we have so many CVE notices means that people are. Did *you* verify the crypto had no holes? That the random number generator had enough entropy? That the proper key length was used, and so on. No, you didn't, but many people have, and most importantly, have the ability to inspect this. The problem with internal drive encryption is getting any level of disclosure and accountability. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On Wed, Jul 08, 2015 at 10:49:40AM -0400, Richard Pieri wrote: On 7/8/2015 10:23 AM, ma...@mohawksoft.com wrote: The problem with internal drive encryption is getting any level of disclosure and accountability. This is simply not true. FIPS security profiles are public record. Here's the security profile for the cryptographic module used in several of Seagate's enterprise SEDs: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1299.pdf The process of obtaining the certificate is accountability in and of itself. The device or software is tested by an accredited test lab to ensure that it works as described in the security profile. If anything fails to work as documented then the device or software is sent back to the vendor to correct the fault or update the security profile. I think this whole discussion revolves around choice. With open source, I have a choice to audit the code if I so desire, or to hire someone to do so on my behalf. With internal drive encryption, I have (almost) no choice but to trust someone else's judgement about the implementation, whether that be the manufacturer or the government or some industry body or nonprofit. Their incentives and my incentives may not always be aligned. I say almost no choice, because I guess I could reverse engineer the device. But this is much harder to do than if I had the source code in the first place. Isn't that one of the major selling points of open source software? Even if I do not exercise my choice to audit the code, the mere fact that anyone can chooose to do so at any time can be a deterrent to trying to pull a fast one and hide malicious code in there. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On 7/8/2015 10:23 AM, ma...@mohawksoft.com wrote: The problem with internal drive encryption is getting any level of disclosure and accountability. This is simply not true. FIPS security profiles are public record. Here's the security profile for the cryptographic module used in several of Seagate's enterprise SEDs: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1299.pdf The process of obtaining the certificate is accountability in and of itself. The device or software is tested by an accredited test lab to ensure that it works as described in the security profile. If anything fails to work as documented then the device or software is sent back to the vendor to correct the fault or update the security profile. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On 7/8/2015 11:06 AM, Chuck Anderson wrote: I think this whole discussion revolves around choice. With open source, I have a choice to audit the code if I so desire, or to hire someone to do so on my behalf. With internal drive encryption, I have (almost) no choice but to trust someone else's judgement about the implementation, whether that be the manufacturer or the government or some industry body or nonprofit. Their incentives and my incentives may not always be aligned. You are not qualified to perform a security audit. Neither am I. Only a handful of people in the world have those chops and most of them work for the NSA and GQHQ and maybe the FSB. The rest charge a great deal of money for their time and expertise, money that you as an individual probably don't have. You only have the illusion of choice. I say almost no choice, because I guess I could reverse engineer the device. But this is much harder to do than if I had the source code in the first place. Isn't that one of the major selling points of open source software? If you are not qualified to audit the thing then you are not qualified to reimplement it. The license is irrelevant. Even if I do not exercise my choice to audit the code, the mere fact that anyone can chooose to do so at any time can be a deterrent to trying to pull a fast one and hide malicious code in there. It didn't stop the NSA from compromising Dual_EC_DRBG. It didn't stop Intel from compromising RdRand (likely at the NSA's prompting). It didn't prevent the ProFTPD sources from being compromised. It didn't prevent the OpenSSH sources from being compromised. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On Wed, Jul 08, 2015 at 10:15:02AM -0400, Richard Pieri wrote: On 7/7/2015 6:26 PM, Derek Martin wrote: The difference is, the software most of us rely on is open source, and is known to have been inspected by some very smart 3rd parties who Some very smart 3rd parties? Can you actually name any of them? Yes, in fact. I can name some of the people who do that where I work, though I will not do so, as it is not my place to disclose that information. I can also identify, for instance, Robert Swiecki at Google, because he was involved in some of the recent OpenSSL vunlerabilities. I believe I could, without too terrible an effort, identify numerous other people who do that, because their names are all over various vulnerability reports, and it's just not that hard to get that information. Some of these people, I actually know or have corresponded with. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On 7/8/2015 11:47 AM, Derek Martin wrote: Yes, in fact. I can name some of the people who do that where I work, though I will not do so, as it is not my place to disclose that information. I can also identify, for instance, Robert Swiecki at Google, because he was involved in some of the recent OpenSSL vunlerabilities. I believe I could, without too terrible an effort, identify numerous other people who do that, because their names are all over various vulnerability reports, and it's just not that hard to get that information. Some of these people, I actually know or have corresponded with. Do you understand that you are doing the same thing that you accuse proprietary software of doing? -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On Wed, Jul 08, 2015 at 12:08:13PM -0400, Richard Pieri wrote: On 7/8/2015 11:47 AM, Derek Martin wrote: Do you understand that you are doing the same thing that you accuse proprietary software of doing? The world is full of proprieties--I am subject to some of them the same as any of us are. But it does not matter; you asked if I know any such people; you did not ask me to prove it. Moreover, MY trust depends neither on my ability nor my willingness to prove my trust TO YOU. Besides, I did give you one specific example. I pointed out how you can find plenty more. The source is available to everyone. Those people who do this for a living all check each other's work, and it is, by and large, in their interest to be as dilligent and as straightforward as possible. Their reputations depend on it; their reputations are what they trade on. Is that not obvious? The community is generally a very open one; you can insert yourself into it with relative ease, if you care to. The notion that open source affords only an illusion of more assurance than closed source is nonsense. It is still not perfect, as surely no human endeavor is. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On 7/8/2015 3:19 PM, Chuck Anderson wrote: Sorry, I call BS. My point was that having access to source code is a prerequisite. If you don't have access to the source code, it becomes MUCH harder to audit because you are limited in the techniques you can use, such as black box testing. If you have source code, you can read the code and try to understand what it is doing. This is why I say you don't have the qualifications. Access to the source code isn't worth nearly as much as you seem to think it is. There are classes of vulnerabilities like insecure compiler optimizations that are impossible to detect by examining the source code even when you do understand what the code is supposed to do. On the other hand, no-source techniques like black box testing work whether or not you have the source. This is why my answer to your next question is... And do you think we would know about those instances if the code/standards were closed? ... yes, we would. Everyone, step back and think about encryption. There are a lot of moving parts. Take for instance, the AES encryption algorithm. This is a known quantity and you can trust that it works when given any two independent implementations of it can encrypt/decrypt. That's just the beginning. The next step is your key value. Is your key sufficiently random to really get the benefits of the encryption? How do you know? Does your key generation use /dev/urandom, /dev/random, some neat hardware entropy generation? If your key is not sufficiently unpredictable, then no matter how good the encryption algorithm is, it will break if the attacker knows about your key vulnerability. Next, how safe is your private key? Why use brute force when the key can be had by bad programming? trusting that a closed system like encrypted hard disks is probably OK, but if you are paranoid, it isn't. We should all be paranoid. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On Wed, Jul 08, 2015 at 04:47:19PM -0400, ma...@mohawksoft.com wrote: trusting that a closed system like encrypted hard disks is probably OK, but if you are paranoid, it isn't. We should all be paranoid. Always remember: trusted system means that you have to trust it, not that you have proven that it's worthy of trusting. -dsr- ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
Rich Pieri wrote: Paranoia is an irrational fear. We should not be paranoid. We should be rational about security. On this flogged-to-death topic, I finally spotted a statement that I can agree with (the other) Rich on! Brought a smile to my face. A lot of the statements in this heated discussion aren't necessarily mutually exclusive. Open-source definitely has its place, but so do proprietary solutions. One example I worked on last year was Vormetric's whole-disk solution which is overpriced but fills a niche that none of the open-source projects do. Comments about FIPS-140-2 certification are beside the point. If you're relying on that cert, you're still fighting last year's (or last decade's) war against intruders who are upping their game much faster than any compliance-monitoring company can manage. Google for the fips-140-2 certified-products list and you'll find almost nothing cloud-related yet, at a time when data centers are migrating to the Cloud at warp speed. It's an arms race between white-hats and black-hats, plain and simple. It's currently escalating, and at some point even AES itself will be compromised. For now, most security revolves around tight management of ldap/authentication-directory servers, improvements in key-store systems, multi-factor auth, and disk encryption schemes. Security is hard because if you make it too inconvenient, our enfeebled human brains will come up with a backdoor around most any IT manager's policies. It still chills me to think that most anyone with a calm voice and a copy of a stock-brokerage statement can social-engineer their way into my accounts by merely hijacking my email and then threatening to stop doing business with the firm unless the call-center flunky turns off multi factor auth, issues a password-reset email, and let me into my own darned account. I'm not at all convinced many large enterprises knows how to deal with those exceptions properly without royally pissing off legitimate customers, given the primitive state of security technology currently available. There's a lot left to do in the security software biz. I suspect today's undergrads can pursue PhDs and then a full career in it, and still not get bored half a century from now. -rich ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
Rich, your post reminded me of this sticker I saw: ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On July 8, 2015, Richard Pieri wrote: All of us... well, most of us anyway, myself included, were blinded by the illusion [that open source affords more assurance than closed source]. We believed if there were problems then some smart people would have noticed them and fixed them because that's what open source is all about. That didn't happen and we got another critical security flag day for the year. Oh, please. Nobody actually believes that open source scrutiny will find *every* security problem. The empirical evidence is that apt-get regularly brings me security fixes, so people clearly are looking and fixing security bugs. Some of them will get missed for a long time, perhaps forever, but that's life because bug detection is provably undecidable. Dan ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On 7/8/2015 4:47 PM, ma...@mohawksoft.com wrote: There are a lot of moving parts. Take for instance, the AES encryption algorithm. This is a known quantity and you can trust that it works when given any two independent implementations of it can encrypt/decrypt. Yes. And this is one of the ways that FIPS 140-2 certification is useful. It means that a test lab accredited by NIST has verified that, among other things, a given implementation of AES is correct. Or at the very least correct per the security profile and the security level being tested against. Likewise key generation and key management if these are part of the security profile. Next, how safe is your private key? Why use brute force when the key can be had by bad programming? This is where problems like compiler optimizations can bite you really, really hard. Private keys can be exposed even with the best code if it's compiled incorrectly. OWASP has a simple example here: https://www.owasp.org/index.php/Insecure_Compiler_Optimization That's assuming the compiler generates good object code. All bets are off if the compiler is broken: http://lkml.iu.edu/hypermail/linux/kernel/1407.3/00650.html trusting that a closed system like encrypted hard disks is probably OK, but if you are paranoid, it isn't. There is an attack against software-based encryption like dm-crypt that most of you probably have not considered, an attack that has nothing to do with code or compilers or key management but with drives themselves. The attack is possible because of logical block addressing (LBA). One of the features of LBA drives is a self-repair mechanism. All LBA drives ship with a reserve of unused blocks. When the failure of an allocated block is detected by the controller a reserve block is allocated, the contents of the original block are copied to the reserve block, the new block is mapped over the original block, and the original block is deallocated. This is automatic and transparent. Normally it is not possible to access these deallocated blocks but replacing the controller with a recovery controller will grant access to the entire medium. If self-repair happens to blocks encrypted by the OS then you will have multiple identical blocks on the medium. If a new block is changed then you have an information disclosure similar to changing the contents of an encrypted container stored on a copy-on-write file system. If an attacker can identify the nature of the change then he may be able to parley that into a known plain text attack against the affected blocks. Self-encrypting drives should be resistant to attacks against data remnants if the encryption is implemented below the self-repair mechanism. Encryption is always on (the lock/unlock mechanism controls access, not encryption) so even unlocked SEDs should be resistant. We should all be paranoid. I'm going to flat out disagree with this last assertion. Paranoia is an irrational fear. We should not be paranoid. We should be rational about security. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On 7/8/2015 9:32 PM, Daniel Barrett wrote: Oh, please. Nobody actually believes that open source scrutiny will find *every* security problem. You know what? I honestly thought that there was no way that anything as ubiquitous as BASH could have bugs more severe than edge case inconveniences. Burn my ass once, etc., etc. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On 7/8/2015 3:19 PM, Chuck Anderson wrote: Sorry, I call BS. My point was that having access to source code is a prerequisite. If you don't have access to the source code, it becomes MUCH harder to audit because you are limited in the techniques you can use, such as black box testing. If you have source code, you can read the code and try to understand what it is doing. This is why I say you don't have the qualifications. Access to the source code isn't worth nearly as much as you seem to think it is. There are classes of vulnerabilities like insecure compiler optimizations that are impossible to detect by examining the source code even when you do understand what the code is supposed to do. On the other hand, no-source techniques like black box testing work whether or not you have the source. This is why my answer to your next question is... And do you think we would know about those instances if the code/standards were closed? ... yes, we would. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On 7/8/2015 1:18 PM, Derek Martin wrote: But it does not matter; you asked if I know any such people; you did not ask me to prove it. Moreover, MY trust depends neither on my ability nor my willingness to prove my trust TO YOU. My willingness to trust you does. Your claim is that open source is good because some smart people who you are unwilling or unable to name say it is. And then you provide one cherry-picked (as far as I can tell) example to specifically name, totally missing the irony of that person's job being identifying where open source security fails. And then you tell me to figure out the rest for myself. The appropriate response in polite conversation would be something like I flip you the bird and walk away. The notion that open source affords only an illusion of more assurance than closed source is nonsense. It is still not perfect, as surely no human endeavor is. The notion is not nonsense. It's reality. It's why Bashdoor went publicly undetected for 25 years. Many eyes looked at it but none of them, not even those of the vaunted unnameables, not even yours, spotted it or twigged to the severity. All of us... well, most of us anyway, myself included, were blinded by the illusion. We believed if there were problems then some smart people would have noticed them and fixed them because that's what open source is all about. That didn't happen and we got another critical security flag day for the year. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On Wed, Jul 08, 2015 at 11:53:35AM -0400, Richard Pieri wrote: On 7/8/2015 11:06 AM, Chuck Anderson wrote: I think this whole discussion revolves around choice. With open source, I have a choice to audit the code if I so desire, or to hire someone to do so on my behalf. With internal drive encryption, I have (almost) no choice but to trust someone else's judgement about the implementation, whether that be the manufacturer or the government or some industry body or nonprofit. Their incentives and my incentives may not always be aligned. You are not qualified to perform a security audit. You have no basis upon which to make such a statement. Neither am I. Only a handful of people in the world have those chops and most of them work for the NSA and GQHQ and maybe the FSB. The rest charge a great deal of money for their time and expertise, money that you as an individual probably don't have. You only have the illusion of choice. Sorry, I call BS. My point was that having access to source code is a prerequisite. If you don't have access to the source code, it becomes MUCH harder to audit because you are limited in the techniques you can use, such as black box testing. If you have source code, you can read the code and try to understand what it is doing. I say almost no choice, because I guess I could reverse engineer the device. But this is much harder to do than if I had the source code in the first place. Isn't that one of the major selling points of open source software? If you are not qualified to audit the thing then you are not qualified to reimplement it. The license is irrelevant. People can learn. Even if I do not exercise my choice to audit the code, the mere fact that anyone can chooose to do so at any time can be a deterrent to trying to pull a fast one and hide malicious code in there. It didn't stop the NSA from compromising Dual_EC_DRBG. It didn't stop Intel from compromising RdRand (likely at the NSA's prompting). It didn't prevent the ProFTPD sources from being compromised. It didn't prevent the OpenSSH sources from being compromised. And do you think we would know about those instances if the code/standards were closed? ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On 7/7/2015 1:14 PM, Derek Atkins wrote: I don't trust my disks to do the encryption, mostly because there's really no way to verify that it's doing it correctly, and the key management gets a lot harder. Yes, there is a way to verify that they doing it correctly. It's called FIPS certification. If the drive does it incorrectly then the drive doesn't get certified. OASIS KMIP addresses your key management and key handling issues. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
Edward Ned Harvey (blu) b...@nedharvey.com writes: From: Discuss [mailto:discuss-bounces+blu=nedharvey@blu.org] On Behalf Of Tom Metro I imagine it would be challenging to pull off encryption well with appliance hardware. The first problem is getting the software to do it. (Plus all the automation you've previously discussed to set up the keys on boot.) The second challenge is having the horsepower to perform the encryption. Not impossible if they chose their embedded CPU well, but unlikely to be optimized for that. You seem to think there's an obstacle which isn't really real - Encryption is very cheap computationally, so cheap indeed it can be done by the disks themselves. Yes, it's absolutely possible for appliances to utilize disk encryption, either by using its own CPU, or by offloading to the disks. I cannot speak to the specifics of any particular appliance actually doing it though, as I don't use any of them. I don't trust my disks to do the encryption, mostly because there's really no way to verify that it's doing it correctly, and the key management gets a lot harder. I'd rather use dm-crypt (or the equivalent). In either case you still need to figure out how your keys are going to get provided when the system boots. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
From: John Abreau [mailto:abre...@gmail.com] Edward Ned Harvey (blu) b...@nedharvey.com writes: You seem to think there's an obstacle which isn't really real - Encryption is very cheap computationally, so cheap indeed it can be done by the disks themselves. On Tue, Jul 7, 2015 at 1:14 PM, Derek Atkins warl...@mit.edu wrote: I don't trust my disks to do the encryption, mostly because there's really no way to verify that it's doing it correctly, and the key management gets a lot harder. The way I read it, the message wasn't that you should trust the disk to do the encryption; it's that encryption has very low overhead today, and the reference to disk-based encryption was merely to illustrate that point. It seems silly not to trust the disk to do encryption, when you'd trust some software that you equally haven't decompiled and inspected. I am saying both: Encryption has very low overhead today, and yes it's ok to do it in the disk hardware. Nowadays, you can download a dozen different AES libraries in any language - including javascript. Not that javascript is relevant in context, just to point out, AES is SOO ubiquitous that it's literally everywhere and in everything. The idea that the disk is going to have a broken implementation of AES is beyond far-fetched, into unbelievable land. And like I said - it isn't any less likely to be the case in the overriding software. Which I guarantee also has a working implementation of AES. The only thing you need to *actually* be concerned about is where do the keys come from, how do they get managed, and do they cause inconvenience. And I guess it wouldn't hurt to actually plug one of the disks into another system and confirm that encryption is *turned on*. But as long as it's turned on, and the keys are good and managed, yes I trust disk hardware to do the encryption just as much as I trust the application software. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
On Tue, Jul 07, 2015 at 09:22:19PM +, Edward Ned Harvey (blu) wrote: It seems silly not to trust the disk to do encryption, when you'd trust some software that you equally haven't decompiled and inspected. The difference is, the software most of us rely on is open source, and is known to have been inspected by some very smart 3rd parties who have their own incentives to make sure it's as good as the authors say it is. The process is far less transparent with the disk manufacturers. For all you know, they're actually using ROT13 (no not really, but you get my point). We're talking about people who essentially redefined the terms to measure the amount of storage they provide in their products, to suit their own priorities... =8^) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
From: Discuss [mailto:discuss-bounces+blu=nedharvey@blu.org] On Behalf Of Tom Metro I imagine it would be challenging to pull off encryption well with appliance hardware. The first problem is getting the software to do it. (Plus all the automation you've previously discussed to set up the keys on boot.) The second challenge is having the horsepower to perform the encryption. Not impossible if they chose their embedded CPU well, but unlikely to be optimized for that. You seem to think there's an obstacle which isn't really real - Encryption is very cheap computationally, so cheap indeed it can be done by the disks themselves. Yes, it's absolutely possible for appliances to utilize disk encryption, either by using its own CPU, or by offloading to the disks. I cannot speak to the specifics of any particular appliance actually doing it though, as I don't use any of them. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] NAS: encryption
Rich Braun wrote: I have two other requirements that at least until now have favored build rather than buy: encryption at rest... Good point. Thanks for the reminder. I imagine it would be challenging to pull off encryption well with appliance hardware. The first problem is getting the software to do it. (Plus all the automation you've previously discussed to set up the keys on boot.) The second challenge is having the horsepower to perform the encryption. Not impossible if they chose their embedded CPU well, but unlikely to be optimized for that. -Tom -- Tom Metro The Perl Shop, Newton, MA, USA Predictable On-demand Perl Consulting. http://www.theperlshop.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
