I'll admit that the people are broken. Social engineering or bribery is still the quickest/best way to break any security system. Still, having seen how many people have access to the entirety of the database information that banks, for instance, collect as a convienance, does not lend any assurance that this will not happen again in the future.
Secure systems are based upon the principle of least privilege and that especially includes your IT guys, not just your sales/account representitives. SA accounts should not be handed out like candy and you sure don't need it to backup or restore a database, yet I see time and time again every one and their sister, it seems, with an SA acount. Furthermore, fields should be default encrypted even to IT people unless they have a specific need, and that should be covered under a specific account. I could go on and on.
We'll see this happen again and again until everyone gets a clue what real security is about. That should happen about the time a certain place has a radical temperature drop.
Actually there is a cheap solution to the carrier battlegroup. The formal name is Thor which is nothing more than a cannister in space with a bunch of welding rolds with fins, some type of seeker head (I'd go with dual IR/millimeter wave radar, perhaps with an optical backup) dropped from orbit. A few hundred to a few thousand of those could ruin your whole day. You'd have to be shooting durn fast, and durn accruately, to get them all, and as I said they are cheap to make and deploy. Old tech.
In the future either you are totally stealthed, submerged, or dead. And this is from an ex-tincan sailor who still keeps up on this stuff.
Precisely; we are back to externalities again. When the bank, credit bureau, or other collector of information screws up, the externality here is the damage inflicted on the individual; it doesn't happen to the company that held the information. The only way to fix the problem is to reflect the external costs back on the institution or corporation. Unfortuately, I'm also pragmatic. Given how many legislators have been bought and sold by these institutions/corporations, we won't ever see a change in this situation.
"When buying and selling are controlled by legislation, the first things to be bought and sold are legislators." -- P. J. O'Rourke
Indeed, this can form the seed for a bit of viral advertising. [Thank you for your contribution;-).] One of the things I look for in a company are any contributions to communities, be if in the form of donations to non-profits, churches (even though I'm not a Christian), F/OSS, and the like. It doesn't cost the firms much, if anything at all if they have a few excess boxes at inventory time, and the return can be many times the expense, especially if they write it off their taxes as well.
Simple, good economic sense with a bit of altruism thrown if for good measure.
Unfortunate but true. Any transfer of information/energy outside the 'box' reveals information to an attacker; it really doesn't matter what the type of transfer is, just that it happens.
As an aside, that's why I laugh whenever I see such things as SpeedPass, wireless payments, etc. I don't care how secure you make it, eventually it will be cracked.
More than accurate enough. All aircraft in naval service are structurally reinforced, extremely in many cases. Over a third of my service in the US Navy was in the aviation side of the house and the specs on those birds is more than enough to handle 10 cm (4"). Still, it's interesting that this isn't quite a good as the AN/SPN-32 ACLS manages for the US Navy, before we de-tune it. [Otherwise it keeps planting the aircraft on exactly the same spot each time and wears a hole in the deck, I kid you not!].
I am also more than a bit concerned that the testing seems only to have been under ideal conditions to date. Landing a helicopter or VSTOL in adverse weather conditions is not fun and I have no idea how a computer would handle a corkscrewing ship in the worst conditions. Been there, done that, cleaned up the wreakage.
Last point, pilots will only use these systems if you point a gun at their head. It's harder than heck to get the SPN-32 tested. They hate ACLS. Pilots are worse control-freaks than geeks;-).
I hadn't noticed but you have a right to be proud. [I owned the 2049th A1000 made and still miss her!]
Yes, it doesn't matter the vector, we have a new (actually old really) class to defend against here. Any library that doesn't return the result in constant time will clues about the key given enough samples. Essentially you are running a statistical sampling to narrow down the population to one sample (a reverse t-test if you know statistics).
Surprising that no one has really thought of this before, or at least jumped up and down and screamed until the libraries were fixed. It isn't just HT, SMP, or any one technology, it's that you can derive enough information to spit out that key.
Actually switching to dual cores may not help at all for this class of problem if they share any level of cache at all and it has been pointed out elsewhere by C. Robinson that even DRAM level performance monitoring can still be leveraged in the presence of more than one core/CPU. This one is going to send a lot of people back to the drawing board not on both the software and hardware sides. Ouch!
The problem is *not* about a program (process) being able to read memory is should not be able to read. This is part and parcel of a whole class of problems with any hardware, software, or mixed system in which you are able to monitor the performance of the algorithm in either the energy or time dimensions. AES seems to be just as subject to this class of TEMPEST attack as is RSA. So long as timing (performance) monitoring can be achieved and the algorithm in that particular implementation is not executed in constant time, you can make a successful attack.
The problem here is that 'the objective field of all experiences' is inherently a contradictory phrase, at best, with no referent. Experience is subjective therefore it can not be ojbective. There is no intersection there. The further we research into the physical nature of the brain/mind itself, and into the quantum nature of the universe, the less there is that can be said about so-called objectivity. It doesn't exist, it has no referent in the very nature of reality.
Do you really think an EE proves every circuit he/she designs correct?! Often enough, he'll design a circuit a certain way because -*gasp*- it looks nicer to him! That's the art part of EE:-)
I don't know about any other EE's out there but this EE (& NE,ME,CE,SE,NE, and more:-) does. *Especially* when I'm working on any critical systems. Reactor meltdowns are sooo messy.
Perhaps that's why, to date, no one has ever found a bug in any of my software applications/suites that I've written over the last 30+ years, unlike the hacks written by software developers.
To return to the thread, if the system is mission critical then yes, this is certainly something that must be addressed. Where it must be addressed is the question. From the paper and the discussion threads, it's not a kernel problem per se, it's a problem with cyptrographic algorithm implemention hardware dependencies.
That would be a very plausible approach towards a solution which would not require hardware support. Curiously, back in the '80's the AmigaOS included the forbid() and permit() fuctions at the core of Exec which prevented any context switching. [This was to quickly handle certain interrupts in a safe manner.] My how the wheels turn;-).
My only problem with this is: how did you get that process going on that server!?? At I've said time and time again, if you give me access to your server, it's far, far too late. All you server belong to me, and I ain't joking. Once I have any kind of access to a machine, it's mine and it's only a matter of time. [The current record stands at, for the longest, 187 minutes.]
Thine argument is circular since you insert assertions into the previous statement that are not asserted by the original author. The point of injection is your assertion that reality "exists independent of the observer, that is to say exist [sic] ojbectively." I couldn't, and neither apparently can the original author, disagree with you more. And I would further assert that current bleeding edge studies into quantum cosmology would equally support my assertion that reality is subjective. Indeed, multiple realities, and which reality we are participants in at any given time, that is if time even exists in "reality" {tongue firmly in cheek}, may be self-selected.
If, as may be the case, all reality is subjective, then meatspace, and yes even (or especially!) cyberspace are equally subjective members of the set of realities. Not necessarily overlapping sets, although I think that may not be supportable either in the near future, and possibly present. I think I'll stop at this point.
I haven't looked in the C++ libs in quite a while but I would be rather surprised if the functionality were not in an existing library. I would, however, put serious thought into rolling your own. I'd offer to help but it's been far too long since I mucked with either C++ or rolling my own db code (25 years). Sadly, these days it's all SQL, XML, and web services, and that is about as interesting as watching paint dry, or grass grow {sigh}.
I couldn't agree more! I made precisely this same point in another venue (WSJ) in reference to the Newsweek fiasco. We expect scientists (and coders;-) to maintain certain standards and to provide documentary evidence for their assertions (articles). Yet, miraculously, for some mysterious reason, journalists are exampt from standards. I have been on the scene at far too many events around the world and not once has the media provided a report bearing any resemeblance to what actually occured, let alone the reasons for the events in question.
Now some would assert that I'm ignorant of the "facts" or not a trained observer. Sorry to disillusion them, but nothing could be further from the truth. At least I bothered to learn the local languages and live amongst the people where ever I went and I'll leave it at that.
Give us a modern news service, one that lives in the 21st century, not the 15th century. The techniques/technology really hasn't changed in that long in all actuality.
I can confirm that from experience. I set up the computer shop for our Naval Air Station and was the acknowledged expert when it came to repairing keyboards. Any of the colas will kill a keyboard dead by eating away the circuitry, corroding the contacts, and damaging even the epoxy (which I would never have believed until I saw it, repeatedly!). The only other thing that even came close to killing keyboards beyond ressurection was coffee or tea with cream and sugar. Generally I could rescue those, but never one that saw cola.
Hmmmm..., just conjecture, but I wonder if Jolt is even deadlier than Pepsi or Coke? Cola Keyboard Killing Face-Off anyone?
Guess I spend too much time reading security newsletters 'cause my brain first read that as: "Microsoft is planning to celebrate 25 years of Denial Of Service." Yeah, that seems about right, although with XP we are graduating to Distributed Denial of Service, right?
More seriously, as a so-called MS Partner (heck, they gave me that one day, I still don't know why folks!) I'm a bit mystified. I've looked high and low in my XP and Server 2003 systems, even those bits of Longhorn they let me play with and I don't see any DOS. Something of a DOS emulator, but nothing on point. Oh well.
Not that I want DOS anyway. Given my druthers, I'd shoot this machine if someone would give me mi Amigas back!
This was what the Hewlett Packard Interface Bus (HP-IB) was invented for and your instruments may already be equipped for it. As for what to do with the data stream from the instruments, you stuff it into an ISAM database. Why anyone would even think of using an RDBMS for this is beyond me. ISAM (Indexed Sequential Access Method) has been around forever, exists to take tons of sequential data and store it to the media of choice. From your description, retrieval is only going to be based on a few criteria anyway (instrument, time), so those indices are perfect in this instance.
On the coding end, there are numerous (hell, hundreds) of commercial, F/OSS, and books on ISAM libraries for you to use for the actual storage and retrieval. It may even be included in your existing libraries given how old the technique is now. I was doing this back in the '80s for the US Navy using a 24 bit, very slow, mini-computer, so any normal box should be able to handle it today!
We use these techniques in electronic instrument monitoring, logistical systems, systems engineering, you get the idea. You may want to mosey over to the HP developer web site to see if there is a drop in solution, as I imagine there is (sorry, haven't looked).
What we have in the internet, and the infrastructure we are building over it, is yet another example of "The Commons". What we have here in this specific case is yet another example of what we economists call "The Tragedy of the Commmons". So long as there are no cooperative players, we end up with messes like this. Perhaps it is time to implement blacklists for ISP's that do not use such ACL's. As an aside, my network here would dump such packets in about a microsecond. What about yours?
If y'all want the commons, y'all got to pay the price of being responsible citizens. All of you!
About damn time someone said this! I get approached a lot online and off by people asking about what system they buy, or I should build for them, and I couldn't give two cents about ideology when it comes to my recommendations. I'm an engineer. You know, those people who actually build real world things that solve real world problems? Well when someone is looking at getting a computer the first thing I do is identify whether they even need one [suprising how many people do not for what they need to do], what they actually want to accomplish with the dang thing, and what budget limitations exist. I also make damn sure that I get the truth about the apps part of the equation. People will lie through their teeth about gaming.
With all that in hand, then I go looking for the combination of hardware, operating system, and applications will fit the bill and not bust their piggy bank at the same time. I simply can't understand anyone that would foist a particular system off on someone simply due to their [misguided?] ideologies. It's about the person stupid. You don't sell a two-seat sports car to a soccer mom with five kids.
As an aside, frankly I can't see much use for 64-bit computing on the consumer front at all. For my high-end database work, yeah, that works. Ditto CAD/CAM, video editing, 3-D modeling and the like. Twiddling bits in the latest 3-D shoot-'em up, maybe [as if I wouild even play one given my eye-hand coordination deficit disorder!]. For your typical web and mail user? What would be the point? Heck, a 300 MHz Pentium II/III would handle most things for them anyway. Stupid.
What I'm seeing in the industry today is a lot like the horsepower games played by the automotive manufacturers. 75 extra horse power ain't gonna do squat for you if you can't do over 70 on the freeway. Well, it might make merging/passing safer, but that's about it.
If we are going to pick nits (grin), Plug-and-Play actually dates back to the Amiga. Mi Amiga 1000 had it in '85 when I bought it. It worked accurately and well, which is more than I can say for either the Mac or Windows versions that still give me fits. I still miss mi Amigas!
If you are that worried about your email privacy, get your own domain name, with associated IP address (unless you use something like DynDNS), set it up, and go from there. Frankly, I don't worry about it myself. As a result of prior government service and my agreements with various companies (MS just for starters), I simply assume that I'm being monitored at all times and subject to audit at any time. No paranoia involved, simply a fact in my life, which I knowingly agreed to each step of the way.
Now ss the technology improves, it will become a fact in all our lives, whether we agree to it or not. Get used to it. The trick, as Roger Zelazny and John D. MacDonald have pointed out in their books, is either to totally disappear from the system, leaving no traces, or to flood the system with so much random information it can't create valid relations. I leave this as an exercise to the student.
Well, MS has been promising for a long time [RSN, yeah right!) to use SQL Server as the back-end for Exchange but I don't see that happening anytime soon, if ever. It'll probably happen about the time WinFS becomes reality! However, I have a hard time understanding why no one else has tried it yet.
It wouldn't be that hard, now that native XML support in databases is becoming reality, to simply use pull technology in your server language of choice, tuck the email into the db in XML format (encrypted?) and provide various mechanisms to retrieve it, search it, etc. Full text search is a snap for almost every db I've seen and I've seen about every one in existence, ever. Toss in a web, POP3, IMAP, etc. front-end and you might even have an Exchange killer if it were scalable. However, even for individual use, it's a killer app. Lastly, use both local and server-side databases, and you can replicate/synchronize them to each machine, about perfect for mobile use when disconnected if you can do selective replication. Just a few random thoughts. [This is a small piece of something I've been working on for a while. I'll leave it to your imagination what else you could do with it.}
Until we get to the point where you have to explicitly authorize any new person contacting you, spam will continue to ruin email.
Actually a form of this already exists. I have a registered i-name already and when you click on the link you have to validate you are a human, much the same way/. does for some functions here, before an email is sent to my inbox. As a further filter, and backup mechanism as these are usually important, I have it pointed at my GMail inbox.
What is especially interesting is that the technology (SourceForge) is being extended to support SAML for Single Sign-On.
Slashdot Mirror
Secure systems are based upon the principle of least privilege and that especially includes your IT guys, not just your sales/account representitives. SA accounts should not be handed out like candy and you sure don't need it to backup or restore a database, yet I see time and time again every one and their sister, it seems, with an SA acount. Furthermore, fields should be default encrypted even to IT people unless they have a specific need, and that should be covered under a specific account. I could go on and on.
We'll see this happen again and again until everyone gets a clue what real security is about. That should happen about the time a certain place has a radical temperature drop.
In the future either you are totally stealthed, submerged, or dead. And this is from an ex-tincan sailor who still keeps up on this stuff.
"When buying and selling are controlled by legislation, the first things to be bought and sold are legislators." -- P. J. O'Rourke
Simple, good economic sense with a bit of altruism thrown if for good measure.
As an aside, that's why I laugh whenever I see such things as SpeedPass, wireless payments, etc. I don't care how secure you make it, eventually it will be cracked.
I am also more than a bit concerned that the testing seems only to have been under ideal conditions to date. Landing a helicopter or VSTOL in adverse weather conditions is not fun and I have no idea how a computer would handle a corkscrewing ship in the worst conditions. Been there, done that, cleaned up the wreakage.
Last point, pilots will only use these systems if you point a gun at their head. It's harder than heck to get the SPN-32 tested. They hate ACLS. Pilots are worse control-freaks than geeks ;-).
ex-ET1, USN
Yes, it doesn't matter the vector, we have a new (actually old really) class to defend against here. Any library that doesn't return the result in constant time will clues about the key given enough samples. Essentially you are running a statistical sampling to narrow down the population to one sample (a reverse t-test if you know statistics).
Surprising that no one has really thought of this before, or at least jumped up and down and screamed until the libraries were fixed. It isn't just HT, SMP, or any one technology, it's that you can derive enough information to spit out that key.
Actually switching to dual cores may not help at all for this class of problem if they share any level of cache at all and it has been pointed out elsewhere by C. Robinson that even DRAM level performance monitoring can still be leveraged in the presence of more than one core/CPU. This one is going to send a lot of people back to the drawing board not on both the software and hardware sides. Ouch!
The problem is *not* about a program (process) being able to read memory is should not be able to read. This is part and parcel of a whole class of problems with any hardware, software, or mixed system in which you are able to monitor the performance of the algorithm in either the energy or time dimensions. AES seems to be just as subject to this class of TEMPEST attack as is RSA. So long as timing (performance) monitoring can be achieved and the algorithm in that particular implementation is not executed in constant time, you can make a successful attack.
The problem here is that 'the objective field of all experiences' is inherently a contradictory phrase, at best, with no referent. Experience is subjective therefore it can not be ojbective. There is no intersection there. The further we research into the physical nature of the brain/mind itself, and into the quantum nature of the universe, the less there is that can be said about so-called objectivity. It doesn't exist, it has no referent in the very nature of reality.
I don't know about any other EE's out there but this EE (& NE,ME,CE,SE,NE, and more :-) does. *Especially* when I'm working on any critical systems. Reactor meltdowns are sooo messy.
Perhaps that's why, to date, no one has ever found a bug in any of my software applications/suites that I've written over the last 30+ years, unlike the hacks written by software developers.
To return to the thread, if the system is mission critical then yes, this is certainly something that must be addressed. Where it must be addressed is the question. From the paper and the discussion threads, it's not a kernel problem per se, it's a problem with cyptrographic algorithm implemention hardware dependencies.
My only problem with this is: how did you get that process going on that server!?? At I've said time and time again, if you give me access to your server, it's far, far too late. All you server belong to me, and I ain't joking. Once I have any kind of access to a machine, it's mine and it's only a matter of time. [The current record stands at, for the longest, 187 minutes.]
If, as may be the case, all reality is subjective, then meatspace, and yes even (or especially!) cyberspace are equally subjective members of the set of realities. Not necessarily overlapping sets, although I think that may not be supportable either in the near future, and possibly present. I think I'll stop at this point.
Ah! I feel much better now ;-P
I haven't looked in the C++ libs in quite a while but I would be rather surprised if the functionality were not in an existing library. I would, however, put serious thought into rolling your own. I'd offer to help but it's been far too long since I mucked with either C++ or rolling my own db code (25 years). Sadly, these days it's all SQL, XML, and web services, and that is about as interesting as watching paint dry, or grass grow {sigh}.
Now some would assert that I'm ignorant of the "facts" or not a trained observer. Sorry to disillusion them, but nothing could be further from the truth. At least I bothered to learn the local languages and live amongst the people where ever I went and I'll leave it at that.
Give us a modern news service, one that lives in the 21st century, not the 15th century. The techniques/technology really hasn't changed in that long in all actuality.
Hmmmm..., just conjecture, but I wonder if Jolt is even deadlier than Pepsi or Coke? Cola Keyboard Killing Face-Off anyone?
More seriously, as a so-called MS Partner (heck, they gave me that one day, I still don't know why folks!) I'm a bit mystified. I've looked high and low in my XP and Server 2003 systems, even those bits of Longhorn they let me play with and I don't see any DOS. Something of a DOS emulator, but nothing on point. Oh well.
Not that I want DOS anyway. Given my druthers, I'd shoot this machine if someone would give me mi Amigas back!
DOS, blech!
On the coding end, there are numerous (hell, hundreds) of commercial, F/OSS, and books on ISAM libraries for you to use for the actual storage and retrieval. It may even be included in your existing libraries given how old the technique is now. I was doing this back in the '80s for the US Navy using a 24 bit, very slow, mini-computer, so any normal box should be able to handle it today!
We use these techniques in electronic instrument monitoring, logistical systems, systems engineering, you get the idea. You may want to mosey over to the HP developer web site to see if there is a drop in solution, as I imagine there is (sorry, haven't looked).
I hope this helps.
If y'all want the commons, y'all got to pay the price of being responsible citizens. All of you!
About damn time someone said this! I get approached a lot online and off by people asking about what system they buy, or I should build for them, and I couldn't give two cents about ideology when it comes to my recommendations. I'm an engineer. You know, those people who actually build real world things that solve real world problems? Well when someone is looking at getting a computer the first thing I do is identify whether they even need one [suprising how many people do not for what they need to do], what they actually want to accomplish with the dang thing, and what budget limitations exist. I also make damn sure that I get the truth about the apps part of the equation. People will lie through their teeth about gaming. With all that in hand, then I go looking for the combination of hardware, operating system, and applications will fit the bill and not bust their piggy bank at the same time. I simply can't understand anyone that would foist a particular system off on someone simply due to their [misguided?] ideologies. It's about the person stupid. You don't sell a two-seat sports car to a soccer mom with five kids. As an aside, frankly I can't see much use for 64-bit computing on the consumer front at all. For my high-end database work, yeah, that works. Ditto CAD/CAM, video editing, 3-D modeling and the like. Twiddling bits in the latest 3-D shoot-'em up, maybe [as if I wouild even play one given my eye-hand coordination deficit disorder!]. For your typical web and mail user? What would be the point? Heck, a 300 MHz Pentium II/III would handle most things for them anyway. Stupid. What I'm seeing in the industry today is a lot like the horsepower games played by the automotive manufacturers. 75 extra horse power ain't gonna do squat for you if you can't do over 70 on the freeway. Well, it might make merging/passing safer, but that's about it.
Search on SF for XDI which will turn up both. At last check neither has any code out yet.
If we are going to pick nits (grin), Plug-and-Play actually dates back to the Amiga. Mi Amiga 1000 had it in '85 when I bought it. It worked accurately and well, which is more than I can say for either the Mac or Windows versions that still give me fits. I still miss mi Amigas!
Now ss the technology improves, it will become a fact in all our lives, whether we agree to it or not. Get used to it. The trick, as Roger Zelazny and John D. MacDonald have pointed out in their books, is either to totally disappear from the system, leaving no traces, or to flood the system with so much random information it can't create valid relations. I leave this as an exercise to the student.
It wouldn't be that hard, now that native XML support in databases is becoming reality, to simply use pull technology in your server language of choice, tuck the email into the db in XML format (encrypted?) and provide various mechanisms to retrieve it, search it, etc. Full text search is a snap for almost every db I've seen and I've seen about every one in existence, ever. Toss in a web, POP3, IMAP, etc. front-end and you might even have an Exchange killer if it were scalable. However, even for individual use, it's a killer app. Lastly, use both local and server-side databases, and you can replicate/synchronize them to each machine, about perfect for mobile use when disconnected if you can do selective replication. Just a few random thoughts. [This is a small piece of something I've been working on for a while. I'll leave it to your imagination what else you could do with it.}
Until we get to the point where you have to explicitly authorize any new person contacting you, spam will continue to ruin email. Actually a form of this already exists. I have a registered i-name already and when you click on the link you have to validate you are a human, much the same way /. does for some functions here, before an email is sent to my inbox. As a further filter, and backup mechanism as these are usually important, I have it pointed at my GMail inbox.
What is especially interesting is that the technology (SourceForge) is being extended to support SAML for Single Sign-On.