Schneier on Security
A blog covering security and security technology.
« Hacking TSA PreCheck |
| Sony Playstation 3 Master Key Leaked »
October 26, 2012
Friday Squid Blogging: Squid from the Power Ranger Universe
Posted on October 26, 2012 at 4:26 PM
• 40 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
Here's your first election-related security story involving actual ballots: In Palm Beach County, a mixture of two different versions of absentee ballots were printed up and sent out. The problem is that the optical-scan reader can only be programmed to recognize one version as the correct one (probably a good thing on the whole). So the solution is to hand-copy returned ballots on the wrong form to the right one. The security angle is how to ensure no one takes advantage of the process to introduce changes to the results.
Here's a more detailed description of the problem, and a description of the procedure established for copying the ballots.
"Give social networks fake details, advises Whitehall web security official"
"Andy Smith, an internet security chief at the Cabinet Office, said people should only give accurate details to trusted sites such as government ones."
Ms Goodman, shadow culture minister, told BBC News: "This is the kind of behaviour that, in the end, promotes crime.
"It is exactly what we don't want. We want more security online. It's anonymity which facilitates cyber-bullying, the abuse of children.
"I was genuinely shocked that a public official could say such a thing."
This really needs your weigh-in and advice to people online, Bruce :(
Have you seen this story? http://www.dailykos.com/story/2012/10/26/1150485/...
Two questions: analysis of how such fraud could be accomplished (and whether it could be detected in a voting system audit)? Does the story ring true, i.e. does it seem that there is an actual case of election fraud going on, or is this just the boy who cried wolf? How to tell the difference?
a mathematician found out that the key size that many companies use for DomainKeys Identified Mail (DKIM) was too short.
Whilst I was aware of the key size issue as part of the more general case, I was not aware of the "Test Key Flag" issue where client side MTA's treated a test key as a valid key, that is nasty.
Though thinking about it, it is the logical action for the user side MTA's (20-20 hindsight is a wonderfull thing :-)
Another thing it highlights is Bruce's general comment about "attacks only get better", if 512 bits was acceptable 15 years ago and the implication of Moore's law is "one extra bit to the key length every two years" then 1024 bits would still be considered nice and strong.
But these days people are talking as though 1024 bits "might be crackable for the NSA" with the implication you should consider it to be the case if you are generating a new PK.
The downside of using a key of 1024 or more bits is the increased load it puts on busy MTA's, which currently could be the difference between working acceptably to being over loaded and thus "flaky / non functional".
I heard about the Barns and Noble Book Shop EPos Card readers / Pin Pads being bugged a few days ago but the details were very scarce.
However since then a few more details have come out in the press.
Of interest is that it's only one Card Reader per store bugged and only a limited number of stores that have been targeted. This sugests unlike an earlier attack on a UK Supermarket this was not a supply chain poisoning attack carried out from a foreign country, but more likely organised crime actually doing some form of "black bag job" on each of the effected stores.
What is not known is how long this has been going on for but it certainly sounds like all the info to clone a Mag Stripe Card (Prevelent in the US) and then use it (ie the pin as well) has been collected for a few months or so atleast.
So if any of you out there have used a Barns and Noble store in the last year have a very carefull look at your bank and credit card statments.
You can read more on the story at,
Now I fully expect to see a lot more of this happen from now onwards because it's a logical progression from attacking ATM's. Also as it is now becoming increasingly difficult to attack ATMs EPos Terminals are now technicaly the low "hanging fruit".
I should also say at this time that actually "bugging" these US Card Readers is childs play compared to the European Chip-n-Pin card readers. Usually all that is required is to unplug the 5pin DIN connector from the EPOs Terminal and insert a small device that looks like a "barrel connector" used in gender changers (ie two female sockets) that contains the bug.
The bug can be a modified blue tooth headset or low power FM bug as in essence all it needs to do is use the serial data on the card reader TX pin to modulate an audio signal.
The choice is yours years ago it would have been the FM bug with a nearby FM receiver with a "squelch gate" turning a tape recorder on and off to record the tones that are the serial data. These days you can buy very small very cheap Bluetooth headsets for mobile phones etc for about the same price it would cost to build a small FM bug transmitter and because of other advantages it would be the "modern" prefered way to go.
More sophisticated "store-n-forward" devices using a surface mount 8pin microcontroler (out of say the PIC family) and a bluetooth headset could easily store several days of transactions. Such a "store-n-forward" device could then be bluetooth paired with a mobile phone mounted inside a "wall wart" style case pluged in under the desk or at some other handy point that acts as a bridging relay and it could be setup to either dial out (harder and more risky) or accept dial in and could thus be accessed from any where in the world.
I've built serial keyboard loggers for clients that work just this way before and you can get all the components from most local shopping centers/malls for less than 100USD. The hard part once you've mastered basic soldering techniques is getting the PIC chip program to work reliably if it gets unexpected calls etc. It's certainly the sort of thing I would expect a first year undergrad studying physics or electronics to be able to do with only the information I've provided, as the rest of the info is easily findable on the web.
There is still a lot of talk about APT and the ways it happens. However a lot ot the arguments are based on gut feelings not actual knowledge.
Well a couple of researchers decided to look into the whole thing based on engineering data from 11million PCs they had available to them.
And they discovered 18 Zero-day attacks had been used 11 of which were unknown to the AV commuity and that the attackers had between 0.6-30months use with the average at just over 10months (312days). Which is not good news for the majority of people.
You can read more at,
Of further interest might be,
Whilst monitoring is a step in the right direction, it's success is very dependent on what you chose to monitor and how. That is it is limited by your choices and your ability to analyse what the results might be telling you.
Unfortunatly many fall into the "follow my leader" type behaviour which is very similar to blindly following "best practice".
You need to remember that in many cases "best practice" is a form of "magic thinking" because it has no scientific underpining for the methods used and the results are frequently not actually accurate for various reasons or in many cases amenable to scientific analysis as the measurands are not qualative in nature.
"Meanwhile, a lawsuit over the no-fly list gets to go ahead and be heard in district court..."
...until the plaintiffs are put on the "can not sue" list.
There's been a few stories in the news lately about 3D printing parts of guns.
Previously, regulations could rely on the fact that the equipment required to fabricate certain parts of firearms was out of reach of the average entity wishing to bypass gun control laws.
Now that 3D printing is on the scene, everyone's got their knickers in a twist over the veritable tsunami of home-printed guns that are obviosly about to hit the streets.
Silent Circle Dangerous to Cryptography Software Development
Update: Silent Circle just tweeted that they will “make their code available for audit and inspection”, but have not specified whether (or when) it will be available to the general public or under what license.
--Security theater, the article was really alarmist and just wrong (maybe they didn't read paper). Much code (and good times) is still needed; and the false positives w/ a system like this would be many. The paper presented a "knowledge infrastructure" which was of a dude pulling a garbage bag. I took a peek at the Scone Project website, http://www.cs.cmu.edu/~sef/scone/ and got a little creepy bit though:
We are also looking at techniques such as those developed by the Open Mind Project and the creators of the Peekaboom game, which entice large numbers of untrained Internet users to enter new knowledge by turning the process into a game.
State CISO's feeling the weight of the data breach problem.
Might be time for them to adopt some unconventional methods as force multipliers. We've discussed some on this blog. I think these groups could benefit from pooling expertise for the specific systems, software configuration, product selection, etc.
There is a book called Spy TV that talks about retraining users with the data collected for DVRs (Tivo was the one noted at that time). By using your viewing profile, they would determine what to force feed to you to change you.
--Ha, want to know what's funny? My dad played a role in developing DirecTV, and I remember Tivo w/ it too (I still have one of those Tivo-stuffed animals); it was nice never having to watch commercials and you could always tell when a storm was coming :). But, yeah, we cancelled that s$%t years ago, we only receive what's free and if they charge for that then we won't receive anything, not worth it.
I remember we had a bit of a debate on Cryptocat a while back. The 2.0 version was a major overhaul of the code. I thought it would be a decent solution for non-technical people wanting a quick private chat & who aren't facing a sophisticated attack targeting them personally. Well, I finally got to test it.
My review is they've done an outstanding job on it. I'm not saying the technical merit of its security engineering: the use case means it just has to be good, not perfect. The guy behind the project is trying hard & has had some qualified help. I can say it's probably too difficult for most script kiddies & lay people to crack, which is 80-95% of the enemies.
It's usability is its greatest strength. Once you install the plugin, helpfully located on the homepage, you just... open the plugin. Ok, a few extra steps: type in a unique chatroom name, type your nickname, & hit connect. A minute-long key generation phase happened, then it seemed to hang/freeze (only usability glitch, imho), & then I was in the chat room.
As the roomname is also essentially a password, I randomized it & sent it to my friend out of band. The other person testing it with me was able to follow my instructions, install it, & get in the room within minutes. I forgot how the protocol worked and didn't care to read a spec. I asked if he could see my older "test" messages. Yes. Then, the server was storing messages in some way, so I switched to "private" chat which my gut said should be end-to-end (esp considering the designers involved).
That was just a click away & the screen changed to remove messages that came before that. Nice. Intuition said clicking the name in the same way would go back. It did. Good UI design there, guessing how we would think it would happen. The private messages also have a background to their text that was a bit lighter than the main background. That's how I was originally sure it switched modes. They've also added a color-based authentication. Their work with visual cues is interesting & I look forward to seeing what's next.
One of my favorite things about the site was the retro gaming theme. The art and explanation video are made to be like some REALY old video games. Quite unique. The UI also makes a space invaders-like sound for the message notifications. After plenty of them, I clicked the log off button & was done. All in all, for what it's designed for. they've done an excellent job & created the most usable [free] crypto product I've ever used. And still with plenty of room for improvement at many levels.
Now, who wants to build the high assurance version of it? And who wants to pay for it? And who wants to market it to Cryptocat users? Well, all of you can have fun with that: there's alternatives for that level of security. Cryptocat should be fine for the needs of many users.
Note: the whole thing being GPLed does annoy me. Biggest gripe. That's no problem for the users, but the more permissive licenses have the greatest impact. They also allow integration with proprietary, highly robust platforms & technologies that refuse GPL. Of course, OK Labs & others have tricks for GPL bypass. It's all in the wording. ;)
Cryptocat Protocol 2
How does the key length affect the MTA? Email encryption is end-to-end (meaning the MTA just passes a blob of bytes and doesn't do any encryption processing), isn't it?
I was actually in the discussion in the first link you posted. I figured some readers might be interested in an experienced security veteran's usability review of the final product. That wasn't discussed here specifically. Getting OTR clients set up has always been MUCH more difficult and time consuming for people doing secure chat. This is at least twice as easy to setup and use.
(meaning the MTA just passes a blob of bytes and doesn't do any passes a blob of bytes and doesn't do any encryption processing), isn't it?
It depends on how you chose to set things up but if you are checking the headers you need to do the PK check and the longer the key the more work there has to be done, the more memory required etc.
--I think you were in the 2nd one too, unless you're saying someone's impersonating you. :( It does seem too easy though, but like you and their site says "Cryptocat is not yet ready to be used in extreme situations. We do not recomend relying on Cryptocat if your life is threatened"
Straight from site, it doesn't anonymize you and is still vulnerable to key loggers.
The colorprint authentication is interesting, even though I'd rather just ramble off the 40 chars.
What is noteworthy is the development of a market for crypto-products, as you have said many times, you see an economic solution.
Certainly, there are better options if your life is on the line. However, it's a good way to do encryption by default (think IRC replacement) and security is fine for plenty of users situations. I endorse it for them only.
As for key loggers, most software solutions assumephysical security. It's not a weakness in cryptocat. It just comes with using a standard input device. The network protection & ease of use are major pluses.
As for the market, it's been around for a while as both crypto, security and compliance. PGP and RSA are the most famous. Cryptocats strength is making the technology more accessible to average consumer. Last secure group chat protocol utterly failed to do this. If people hate it, they won't use it.
@ Nick P, Figureitout,
Last secure group chat protocol utterly failed to do this. If people hate it, they won't use it.
This is actually a major issue in security and it's one that is largely unresolveble because the issue is not technical but human.
For instance I'm an old time CLI person not a more modern screenfull of widgets type and because of this I still use some legacy code and hardware (Small-C on C/PM-86 and MesS-DrOS on 8088 no WinDoze ;)
Whilst the code is not secure (non ever is realy) it's attack surface is very small, to me and my old style Unix ethos the code is realy very usable. But to even modern programers who you would expect to have some CLI familiarity it is alien in touch and feel, and as for other users not a chance.
PGP suffered from the same problem, however it's saving grace was/is that you can write a fancy front end and then "shell out" to PGP as a backend on *nix with little difficult (MS OS's are somewhat harder but it's doable).
The downside to such front ends is generaly they are not written by security minded programers (unlike the back ends) and the linking of the two processes is usualy very far from secure for a whole variety of reasons.
I realy don't know what the solution is, what I do know is as a generalized case "usability" is not good news if you waant security (it's by no means impossible to do, it's just that few people even try let alone succeed).
What I have learnt over the years is that for security to have a chance you need well designed API's that properly support the functionality required at the level the interface is on in the software stack and not that of other levels, further it should do a few things well not many badly. Further the API's need a proper exception protocol that works, and no matter what level it's on in the stack a process must must must sanity check all of it's inputs and all of it's outputs and pass exceptions back correctly.
I can not tell you how much code I've seen that does not do this properly, but I can tell you how little does and it's next to zero.
One HCI ethos which is utterrly dependent on correctly designed and implemented API's is the "Principle of least surprise". If exceptions are not handled correctly users will always be surprised in unpleasent ways and security will as a consequence go straight out the window.
Cryptocats strength is making the technology more accessible to average consumer.
--Yeah, unless they become lazy and don't try to understand what's happening, but they do that anyway so there's no winning. I just think "encryption" has become more mainstream and popular than before.
Small-C on C/PM-86 and MesS-DrOS on 8088 no WinDoze ;)
--I usually have to look up the acronyms you post, and got the MesS-DrOS joke after a min. or so, but in the process found a site you may enjoy:) http://www.messdress-britishmilitaria.com/
My dad's hooked me up with a Velleman k8055, as well as an old test comp., another old comp, and maybe another old laptop that I can mess with, b/c I've bricked a comp. before messing around :( Hope to get maybe Ubuntu installed and finally branch out from Windoze. Hoping to get a PIR detector kit and make a little program to log "hits"; perhaps even talk w/ my neighborhood and log vehicles entering my neighborhood.
@ Nick P,
Oh have I been through these battles..
From figures collected on behalf of the UK Gov (and presumably also massaged by them to look better) it would appear that less than 15% of people with Aspergers get and maintain employment, and of those few ever move up the promotion ladder. For other froms of ASD the figures are at best similar at worst as close to 0% as makes no meaningful difference.
It is interesting to note that the author kept the rel issue to last Aspies unlike NT's don't "kiss arse".
Further what was not mentioned is they don't tend to "roll over" either and thus "dig their heals in".
All of which means they don't get on with those on the other side of the NTs, those "glad handing" "charmers and chancers" in managment who's only intention is to get up the ladder for their sole good and as such are at best antisocial and many psycopathic with a few with homicidal tendencies.
Of the two "non-NT" groups you have to ask which actually serves the majority NT population the best?
I suspect that after proper reflection most NTs would prefer the ASD to Psychopathic group.
So why do HR (Human remains) prefer to employ the Psycopathic group?
Well it has been observed that "Birds of a feather fly together" so it could be they are part of the same club/group, but for various personal defects actually cannot cut it outside of HR. One of those defects being they lack various things like intelligent insight, another being a lack of empathy, another... The list goes on and I'm sure there are many other failings that you and others could lay at their door.
[I suppose I should make a declaration of non impartiality with regards HR types, that is I've generaly found them to be at best compleatly ineffectual and at worst down right malicious so at either end of the HR spectrum and thus virtually all points in between I would suggest that outside of an extreamly limited scope the majority are a waste of resources.]
@ Nick P,
I was thinking of saving this for next Fridays Squid page but I think it will be of considerable interest to you and others,
In many ways it relfects my views that I've independently aquired and it indicates some soloutions that I've independently thought up and aired on this blog from time to time...
IN OTHER NEWS
Appears NYC datacenters' disaster planners didn't seen hurricanes coming. I wonder who did.
(There were also 26 nuclear plants in its path. Last I heard, none of them have been seriously affected.)
FBI now working 24/7 on tracking hackers. I assumed they were already doing that. Hmm.
MIT breakthrough CodedTCP uses algebra to boost wireless throughput rates. One speedup boosted from 0.5Mbps to 13.5Mbps. I think I'm about to push it further by making CodedUDT. ;)
--He (Neumann) had breakfast w/ Einstein?! Lucky..Anyways it seems like some of the ideas he has are common sense, but making it happen is so hard it hasn't been done yet. What a luxury it must have been, to live in a time where security in tech. wasn't a big deal; now it's like a neurotic obsession. I saw some prototype of what he's working on, but I can't find any more details; I really want to see the hardware they're coming up with. He doesn't see a business solution, but research still takes money; unless a unique type of nonprofit can be set up. I envision a person having a bunch of devices that serve a single or a few purposes, not like now where one device can have many purposes. I want all the interconnectivity taken out (no Bluetooth in cars!!), not automatically put in; you can have a single device to "get your fix" and connect to the world (and get infected). It'll be a pain, but maybe it'll take an epic hack to convince people.
--Your 3rd link was a repeat. Maybe the FBI is tracking you and is trying to make a point :) I wonder to what extent their taking their "tracking 24/7" boloney and I hope they aren't making it obvious...
Final report released regarding DigiNotar Dutch CA hack. Turns out they also stored logs on the serversthat were hacked, meaning they're useless as evidence. Some were falsified.
Tks for telling me about the broken link. Anyone looking into the wireless breakthrough just needs togoogle Coded TCP from MIT.
About three Squids ago there was a chat on Random number generation that talked about TRNG / CS-PRNG and COTS hardware, and somebody (figeritout IIRC) asked for circuit schematics and other info.
At the time I was trying to remember where I had seen a web site that had done a literature search on early random number generation papers (ie past 1950's RAND book). Well I finaly remembered when somebody sent me a link to something entirely unrelated that mentioned the persons name (Terry Ritter) He moved his page a while ago (but google came to the rescue in the usual way) and you can see it here,
If you go down into the literature searches on random numbers you will find some "ASCII Art" circuit diagrams of zenner and reverse biased PN junction noise generators.
It's funny you should find a site of British Mil Mess Dress, Because up in the attic I have my old Mess Dress jacket trousers&kilt which sadly demonstrates (by the way I can no longer get into it) that I'm nolonger the "fine figure of a man" I once might have been  having increased and spread my mass around my approximate center of gravity ;-)
"Hope to get maybe Ubuntu installed and finally branch out from Windoze."
I would recomend it to anybody who want's to get ahead in ICT. Not because of the "flame wars" style "my OS is better than your OS" but because it gives you a different view of how to go about things. And seeing different viewpoints is always educational as it alows you to abstract out fundementals and core functionality an OS needs to provide from different implementation speciffics. The implementation specifics usually arise due to dealing with some kind of "reesource limitation" that then becomes de facto due to the need for backwards compatability and changing this becomes a truely major excercise. An example of this many people remember was Y2K, it was known back in 1950s/60s that encoding the year of the date into a single unsigned byte or byte wide Binary Coded Decimal or even pair of ASCII chars was a bad idea. But due to the cost of storage (around 1USD / byte on what passed for mass sttorage back then) it was a pragmatic thing to do. However it became engrained with legacy code and as the Y2K epoch approached it became exponentialy expensive to resolve and in 1999 Cobal proogramers daily rate was in some cases well over what they would have earned in a month a year or so before that. Come Jan 1st 2000 the accountants had their "night of the long knives" and it was payback time with many programers finding themselves jobless. However the very high sums demanded were not just due to Y2K in 1998 the first steps of the Dot Com boom started where investors via venture capatalists were throwing trillions of dollars at three or four page business plans. What had been a non existant market segment two years befor had become close to 10% of the US Stockmarket value. Many of the Y2K big earners simply jumped into DotCom companies.
Unfortunatly many of the Y2K jobless had not actually been earning the big bucks and had stayed working on their modest salaries but nether the less they became casualties of the budgetary cuts and many did not get back into jobs even in DotComs. Then in march 2000 the Dot Com Bust kicked in and the whole sale slaughter of programers jobs got going with real vengeance. So much so that many unemployed programers started retraining as accountants finacial advisors and real estate vendors. Just as some got to their feet again 9/11 happened and shortly there after the stock market slumped and the jobless programers were starting to turn up packing bags at shopping checkouts if they were lucky. Some however were doing well as finacial advisors / real estate sellers as people moved their savings from stocks to property the stock market realy turned down and some programers found work designing automated trading systems, the stock market developed faux markets and everything started to look good untill 2008 when the faux property and trading markets were revealed as what they were and came tumbling down like so many houses of cards in a hurricane. And those ex programers who had become finacial advisors and realestate sellers discovered yet again that in fact they were realy sacrificial goats and yet again became ex-employees.
Now during all this bruhar those with ICT experiance were winowed out to be replaced by much cheaper youngsters on little more than minimum wage saleries. And as a side effect of this the experiance was lost and issues with ICT Security has consiquently risen almost exponentialy...
Which brings us to our current state of affairs, you might have noticed that various people such as Nick P, RobertT and a few others on this blog have been banging on about what a mess current ICT Sec is and how all the issues had been seen before and solutions found back before the 1970's. You might have followed Nick P and myself's extended conversations about Castles-v-Prisons and also prior to Stuxnet the issues to do with bridging air gap security and why code signing fails and likewise the invisible problem of supply chain poisoning. And going back further EmSec (TEMPEST) time based side channels and my almost perennial warnings of Efficiency-v-Security. Some of the current attacks we have seen coming from a long way off simply because we have seen similar attacks in the past. Sometimes however our inventive and inquiring minds have got us their first by a very very long way. Both RobertT and myself have thought about and investigated what are still novel fault injection attacks on hardware years ago. For instance back in the 1980's I realised you could upset microprocessor based systems with RF fields and realised that by Amplitude Modulation (AM) you could carry attack waveforms into the heart of a system without having to take the cover off and in some cases from very considerable distances. That is you chose an RF frequency that resonates with a particular track or circuit trace in the system you wish to attack and the effective diode of a semiconductor on the end of the line envelop detects (rectifies) the AM signal back to a low frequency voltage on the trace line. As far as I'm aware it's only in the past couple of years that the academic community has actually done an experiment on this and published the results.
The place where this happened is the UK Cambridge Labs where the colaborative project you are looking for is based. If you go to www.lightbluetouchpaper.org and look for Robert N. M. Watson's posts and home page, you will find information on CHERI and BERI systems with SRI colaboration as well as TESLA and the Capsicum work he has done on BSD which is available for OpenBSD and FreeBSD, he sits on the board of directors for FreeBSD.
If you look at CHERI ( http://www.cl.cam.ac.uk/research/security/ctsrd/... ) and replace the sandbox with prison and the various security/capability tagging with signatures you will see that the work is a subset of what Nick P, RobertT and I have discussed with Castel-v-Prison in the past.
However their aim is still "software sandboxes" whilst I'm looking at "hardware prisons". This is because it is cleaner and less likely to cause security issues.
As Watson and Neumann have identified in their paper ( http://www.cl.cam.ac.uk/research/security/ctsrd/... ) one key element to security is the Memory Managment Unit (MMU). This is because it provides the demarkation between the CPU and linear system memory. Now by far the majority of security issues occurr because rouge processes get access that they should not to the system memory. One way to reduce the impact of rouge processes is by maintaining strict segregation between program and data memory which is fundemental to all Harvard CPU's (which the majority of modern CPUs are internaly). However whilst the strict Harvard architecture is fine for many embeded systems it does not work for single CPU general computing platforms such as PC's and Servers simply because you have to have the ability to load program code into memory under user direction (through the OS).
They have chosen to stick with the Single CPU "Castle" idea for backwards compatability. However this leaves a significant vulnerability in that rouge code in a process running on the single CPU can in theory and practice get at the MMU and thus circumvent the security benifit it can bring. To prevent this they then have a considerable overhead of "capabilities tagging" which will take up not just a lot of CPU real estate but also need aditional memory to store the tags securly, which if not done correctly could actually increase the attack surface.
I chose instead to go for a multiple CPU solution where one of the CPUs acts as a hypervisor to the other CPUs that provide the "prison" hardware. The hypervisor would control the MMUs of all the other CPUs and this prevents rouge code running on a prison CPU from being able to control the MMU of it or other CPUs.
I further chose to not do hardware based tagging as it only provides a subset of what can be achived by other less real estate hungery methods. It also alows you to real design RISC CPUs that are tiny but very powerfull thus having quite many in a very small real estate area. Further you can strip out all the other real estate using junk you need for I/O by dedicating it to another Comms CPU under direct control of the hypervisor CPU. It further alows you to strip down the OS requirments on the prison CPUs by having all comms done as "streams" using "letter box" buffers controled by the MMU which is under the control of the hypervisor.
After further thought you can strip further wasted real estate by actually making an application into a lot of piplined micro-processes each running on a prison CPU. This means that the actual memory needed by a prison CPU is realy quite small and as such does not give rouge code a place to hide. Further it strips out the majority of the complexity at that level making signiture analysis fairly simple.
Further you can also eassily decouple the CPU from not just memory but any kind of external refrence, thus you can safely halt a CPU such that the hypervisor can examin it's memory and registers. This does not need to be done only on some kind of exception it can be done at any time thus rouge code injected from outside the system can be readily detected, which is something a subverted capability tag cannot do.
Any way which ever system you think is best for various reasons both are quite a significant step forward from current systems in common use.
 There are various debates amongst some of the women folk who were in the same regiment as I as to if I actually had a "fine figure" or not some cruely say "sack o'shite tied lasely in thar middle" others more kindly remeber "broad sholders" and "nice legs/bum" and "baby soft hair". What is commonly agreed however is that I was "a big bugger who could lift two full kegs of beer onto my shoulders" and looked not so much "like a brick out house" but as though I "had just knocked one down" .
 This "Demolition man" view came from a minor incident when I had been away doing FIBUA (Fighting In Built Up/Urban Areas) training, where the buildings they used were not quite as sturdy as they might other wise have been. During some fairly hectic action where the "enemy" were trying to retake a building I was in I ran into one of the attackers at full tilt as the passed a doorway and effectivly rugby tackeled him quite firmly and in the process slamed into a first floor wall so hard the pair of us ended up going through the wall and ended up on the ground outside a floor below. Unfortunatly necesitating a report as to why a SLR (rifle) was damaged beyond repair and why we both got carted off to hospital with various injuries and the unfortunate attacker being RTU'd (returned to unit) because of a bust ankle, whilst I was considered ok to finish the training with a couple of broken fingers.
If you've not already seen this I think you might like it.
Gary McGraw, (author of blackhat and white hat books) has produced a well written piece about why the various Cyber First Strike ideas are actually a bad idea and likewise why much of our current Cyber Defence is so bad,
The piece refutes the almost seductive Cyber Offensive argument of "Proactive Defence" being put forward by the likes of CrowdStrike's co-founder and CTO Dimitri Alperovitch, who is encoraging such action and changes in legislation to make it easier and thus make the services of his company in this area more available,
Oh and in a related article Howard Schmidt actual indicates that what we name things as (ie "Cyber crime/war) actually effects the way we deal with them...
--Thank you thank you for the ritter site, what a resource! Bloody bollocks mate, stop talking like "oh what I used to be.." and I most definitely don't want to hear about your bum. :p You see Neumann?-He's 80 and still going strong. Both of my grandfathers were gone when I was 4, so I don't remember much (I really wanted to talk to one about WWII, but nope couldn't). He was a radio officer, and when I first heard that was like "Aw, that's not cool", but in fact they were targeted more than other troops by snipers, b/c w/o comms your chances of survival just went way down. My other grandpa was an electrician who built his own home (still standing), and has many antiques (like real indian arrowheads and carved broomsticks) and cool homemade tools. He wasn't really a fan of the military.
I on the other hand, was known to keep a clean soccer uniform (even in the mud fields of Belgium:), position myself (by recognizing patterns), and not be a dirty player. However my nickname went from "gentle giant" to "bodysnatcher" as repeated calls for me to "get stuck in" more often eventually took hold and broken bones, red/yellow cards, and ambulance sirens became more frequent. :/
Now during all this bruhar..
--Think some went the criminal route?
I'm going to look into the FIA w/ AM more I think; I've got plenty on my plate now though.
However their aim is still "software sandboxes" whilst I'm looking at "hardware prisons".
--I personally like to work w/ hardware more b/c yes it is much cleaner. A fundamental problem w/ software is human typos IMO, I find them everywhere (even in the ctsrd paper, "FGPA" instead of "FPGA"), even after I write something, my eyes deceive and I spot a typo later.
However, top o' the mornin' to ya & cheers from the colonies. Got (too) much to do. I've always been a late-bloomer and I'm trying to teach myself a lot of this.
I thought you'd like this piece by a (UK) Metro police officer, wherein he called out airport security on the worthlessness of their search procedure; hilarity ensued (for the reader):
At least (I assume) he does not have to do the fourth type which is approach an "assumed dead" body and then very intimately search it inside and out for intel.
Oh and you need to remember that it's probably more likely to be boby trapped body or a suicide jocky waiting to let go the grenade or push the IED button than have anything usefull in the way of intel on or in it... Trust me when I say it's better to be modern bomb disposal your chance of having clean under crackers at the end of the day is higher...
Obviously the sensible thing would be to stay a safe distance away and put one through the head just to make sure it's a corpse before you get in close (which is what they tended to do during WWII, Korean and Vietnam wars. But with the norm being "policing actions" the rules of engagment preclude this especialy if as is getting quite normal these dyas to have a dopy git with a camera in the area.
What you are supposed to do (and I kid you not) after first having a dam good look for IED's and snipers and other similar threats is jump on the prone body as hard as you can so you are lying prone on top of it, then grab the body by the sholders and roll it up over you. Hopefully if it's boby trapped then the body will shield you from the blast and shrapnel of a grenade or other small device (but if it's a fritzed anti tank mine or bouncing betty just make sure you're squad is far enough back with a plastic bag to take you home in).
Then you start the search which basicaly means striping the corpse which is where there are other issues after just a few hours in a warm climate the body is not at all nice, and getting the kit off is not easy this also alows for other types of boby traps that go off should the preasure of a belt or other item of clothing decrease (you can put a claymore mine or grenade in a slit in the body cavity, with a loop of thread or wire through the shirt and attached to a coat etc), boots being a real problem (chop most of the foot off and put a small hand grenade in there with the pin pulled), so you need to be carefull.
Then whilst somebody goes through the cloths you get to do the cavity search and other areas mentioned in the article including checking between toes up the nose down the throat in the mouth etc even checking the stomach in case they swallowed anything and the other "smuggler cavities". Please remember that these days it's actualy possible to make a small hole in the scrotum put a small usb key with 32GByte of info in there and put a small stich in to close and cover it with a sticking plaster (apparently this has been used by some child abusers to bring the pictures home). Likewise under muscles and other places...
If you think about it you might realise why OBL went over the side at sea... Depending on where they did a full corpse search the body might well have looked like it had been organ harvested.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.