Baby squid larvae are transparent after they hatch, so you can see the chromataphores (color control mechanisms) developing after a few days.
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
Petréa Mitchell • June 8, 2012 5:15 PM
SWATting is in the news again. This is the first case I’ve heard of where the motive is allegedly political.
Daniel • June 8, 2012 5:30 PM
A fascinating article written by a law professor entitled “The Perils of Social Reading”. From the abstract.
We are quite literally rewiring the public and private spheres for a new century. Choices we make now about the boundaries between our individual and social selves, between consumers and companies, between citizens and the state, will have unforeseeable ramifications for the societies our children and grandchildren inherit. We should make choices that preserve our intellectual privacy, not destroy it. This Article suggests practical ways to do just that.
Daniel • June 8, 2012 5:30 PM
Gah! Here is the link:
Clive Robinson • June 8, 2012 6:11 PM
OFF Topic:
It would appear that the US judiciary are getting to breaking point with “Patent-Spats” and being used by large commercial organisations as proxy business drivers.
The Judge overseaing the Apple-Google case has told them he’s minded to throw it out with prejudice…
So far both Apple & Google appear not to want to say anything, and are waiting for a formal ruling.
The judge has also made a very interesting blog comment on the state of the US patent system and the us in general (he starts with the point that it is realy only the fact that the USD is the international trading currency that is stoping the US being hosed).
http://gigaom.com/mobile/famous-judge-spikes-apple-google-case-calls-patent-system-dysfunctional/
Clive Robinson • June 8, 2012 6:31 PM
OFF Topic:
Something for the weekend?
Are you looking for an out of this world experiance to put the WoW factor back in your life?
Well have a look at these,
http://www.flickr.com/photos/nasa_jsc_photo/sets/72157629726792248/with/7257867240/
jamesbond • June 8, 2012 7:22 PM
Spook Number Station Monitoring
mailman (dot) qth (dot) net/pipermail/spooks/
growing tired of trying to post and smashing up against the comment blocked page! loosen up your filter!
beer in the fridge • June 8, 2012 7:58 PM
I bet this will post, instead of the post I was going to make…
Comment Blocked
Your comment was blocked from appearing on the site. This may have happened for one of the following reasons:
You posted without typing anything in the name field, or you simply typed "Anonymous." Please choose a name or handle to use on the blog and try again. Conversations among several people all called "Anonymous" get too confusing.
Your comment was a duplicate of another recent comment. If you double-posted accidentally, you don't need to do anything more -- the first copy of the comment will still be published.
You posted using the name of an administrative account, but the blog couldn't authenticate you. If you are an administrator, please log in and try again; otherwise, please choose a different name.
If none of these reasons apply, then your message was spam filtered and will be held for review by a human. We apologize for the inconvenience.
stupid shit filter
Pick N.ose • June 8, 2012 11:37 PM
Nick P – this coming from the same person who requested a certain informative post be DELETED under the pretense it was spam, when in fact it was not, and further went to the trouble of also saying to the effect “and remove this post requesting the removal” (re: examiner links to people with real implants in their body, highly controversial for TPTB who would prefer this information remain silent)
cowardice runs rampant on the web, so back atcha, pally.
Anon • June 9, 2012 6:19 AM
Bruce, your radio interview with Skeptically Speaking aired last night, and the podcast is available now.
http://skepticallyspeaking.ca/episodes/167-liars-and-outliers
Alan Kaminsky • June 9, 2012 11:26 AM
Flashlight Bombs Puzzle Phoenix Authorities
“Flick the switch on these flashlights and they don’t light up. They blow up.
“Three of these bombs have exploded within the last month in the Phoenix area, causing minor injuries to five people and raising fears of more serious ones.
“Police still have no idea who is behind them and have taken the unusual step of putting up 22 billboards across the sprawling metro area to warn residents about discarded flashlights. . . . In addition to the billboards, police are offering a $10,000 reward for tips that lead to an arrest or conviction.
“Police have received dozens of calls reporting possible flashlight bombs that either turned out to be false alarms or hoaxes, including one from a Goodwill store.”
Owen • June 9, 2012 11:43 AM
From the flashlight bomb article: Mangan said the agency has ruled out any connection to terrorism because the targets have been random and there have been no messages or demands.
How desperately sad. The govt/police have been so busy calling any murder/crime “terrorism” that when the real thing appears, they don’t recognize it anymore.
Daniel • June 9, 2012 11:48 AM
@Alan
Oh how silly. If the only damage done is a small abrasion to the forehead how can it be called a “bomb”. I’ve done worse damage (to myself) with a sparkler. Under that definition the police had better be on the alert for FIREWORKS. Hold a BlackCat in your hand and it will do more damage than one of those so-called bombs.
It reminds me of all the “terror” in Boston. What a load of crap.
Daniel • June 9, 2012 11:51 AM
I realized that I used the terms bomb, terror, and Boston in a single post. Come and get me NSA!!
Airplane.
Ronnie • June 9, 2012 12:33 PM
I was reading an article on hardening your passwords (because of the LinkedIn and eHarmony breeches)
http://www.informationweek.com/news/security/client/240001775
One of the recommendations was to use a password manager – with the caution that some had poorly implemented crypto.
http://www.informationweek.com/news/security/encryption/232602738
Interestingly, two of the iOS apps used Blowfish “for which password experts have spent less time developing cracking tools.”
Joe Loughry • June 9, 2012 12:48 PM
Clive,
The long-exposure photos taken on the space station are especially interesting if you look at the highest resolution and zoom in. Sensor damage and noise from high energy particles is clearly evident in the images. Permanent inhabitants of the space station exist in a high radiation environment. Incredible photos, though.
Wael • June 9, 2012 4:11 PM
@ Ronnie,
Checking in from area code 11221 …
Some say passwords are out of style
I recon passwords will remain for quiet a while
If you insist to say otherwise
Then for you I have this advise
Your forcast is but a crap pile
🙂
Figureitout • June 9, 2012 4:32 PM
@ Clive
Nice pics, I’m sure you’ve seen the video of the Aurora Australis from the ISS. Supernovae are my favorites.
@ Pick N.ose Re: Nick P
I’m not accusing, but it’s good that people’s comments are being scrutinized for “trolliness”, there are a billion other places to waste people’s time (facebook? twitter?). You can tell that Mr. NP takes great care in always using the least amount of words in his posts and links articles of high quality. What sucks is that you (typically) have to read said nonsense to determine if it’s f’in nonsense (like some “AlienReptilianLizard” guy a while back who POSTED stuff LIKE this, CAPITALIZING every OTHER word; it’s really annoying).
For gawt’s sake all you wannabe-spammers/trollers; have a little respect for people here who have likely done a little cryptanalysis and don’t need/want to sift thru anymore nonsense than is necessary to do their jobs…
Also, the articles were from the same source, Deborah Dupre and Suzanne LeBoeuf of Examiner. We need more sources, more evidence. The picture of the “implanted chip” was too small to see. What specific spectrum analyzer was used to detect the RF in Walbert’s back? I won’t entirely dismiss the possibility (look up “Elmer Allen”, how he was diagnosed with paranoid schizophrenia b/c he thought he was being experimented with, when in fact he was) but there were many mistakes in the articles, S.LeBoeuf’s articles were pretty worthless and only 1 of D.Dupre’s articles needed to be posted as they were part of a “series”. We should be worried when a majority of imbeciles willingly chip themselves to “get VIP access to a club” or maybe the “Kardashians” or “LiLo” is doing it, so it’s the “in” thing to do!
Anyways whew, my little funny story.
Upon a visit to a local hardware store and after making a small purchase and waiting for my change at a “self-checkout kiosk”, the oh-so-sophisticated, highly-technical procedure of kicking 3 times (3rd time’s the charm) the key-locked change-box below the check-out scanner made the P.O.Shyte work and give me my change.
Aside from making my day, and making me smile; it made me wonder what else would spit out money after being kicked….
Nick P • June 9, 2012 4:47 PM
@ figureitout
I appreciate your support. The reason i use few words is that trolls want attention and to make people waste time. So, i just say “hey mod… prolly a troll. clear it all up will ya?”
Of course, anyone citing the Examiner is always suspect… 😉
Jack • June 9, 2012 6:49 PM
@Clive Robinson – about the patent system in the US -> it’s worse than anyone says. 99% of all attacks against the patent system are about allowance errors. Typically, complaints are by someone who does not believe a patent should have been issued (uh…I could have thought of that), or even that patents are altogether bad (everything should be free man…free!). There are hundreds of blogs in which SW patents are attacked.
But far more destructive to the nation’s future are dis-allowance errors. These range from a result of examiners who do not understand what they’re looking at, to inventors and small companies eventually going broke pursuing their application. No one cares about dis-allowance errors, they’re rarely discussed beyond attorneys. Almost everyone thinks the patent examiners tend to allow all sorts of crap, so therefore, it’s unthinkable something really useful and novel would be dis-allowed. Nothing could be further from the truth. It happens all the time and it’s worse now than ever before. Most of the time someone else will just pick up a design from rejected or abandoned applications, then take it and go.
iab_jlr • June 9, 2012 8:34 PM
It seems stupid for the secret services to let everyone know about an improved MD5 collision attack “with practical implications” when there were already published attacks.
Reading the article, the timing was tighter than I recalled between the release of the free-for-all source and the attack, but more than enough to avoid using the improved version.
Is there any reason the known attack wouldn’t have worked?
Clive Robinson • June 10, 2012 4:29 AM
Nick P,
The world turns and somethings never change.
Back in the late 1970’s and early 1980’s I remember people geting all excited by the Russian Over The Horizon Radar that was nicknamed “woodpecker” because of the noise it made. All sorts of people were wheeled out to comment on it including a bunch who genuinely did talk about “soviet mind control” and what we now call “tinfoil hats”…. What also came up again were the “number stations” because at the time (hight of the Cold War) many were out of “Russian aligned” countries pointing at the West and had the anoying habit of interfering with legitimate broadcasts.
For some reason people were fascinated by number stations and thus like to scan the HF/shortwave “broadcast bands” and report their characteristics. There was (and may still be) a group called ENIGMA who did it fairly proffesionaly and produced annual reports.
However you may remember back to a post Bruce had about what once was the worlds most powerfull AM broadcast station “aspidistra” that was located in Crowborough UK and was run by BBC engineers for the UK DWS (Diplomatic Wirless Service then running out of Pounden and now out of Hanslop Park as far as I’m aware). Well the BBC/DWS ran a lot of HF broadcast stations around the world including some in Cyprus, which caused a bit of a political stink or two in their time. One number station “The Linconshire Poacher” supposadly run for MI6/SIS came from the main RAF base there (according to Cyprus TV who were activly “raising a stink” at the time). One thing that realy made me laugh was the BBC “light service” actually had a program in 2005 about people trying to track down the transmitters location (they could have just asked their “over seas” department who knew almost exactly where many number stations were located as it was part of their job to keep an eye on them). The “poacher” appeared to be aimed at the Middle East and went off air around four years ago but apparently a simillar/replacment station is now running out of Australia as “cherry pie” which North Korea keeps trying to jam much to the anoyance of South Korea who appear to be raising their own political stink for saber rattling purposes (If you believe the S.Korean media N.Korea is the third most dangerous “cyber-warfare nation after the US and Russia which makes me smile).
Are number stations broadcast messages to “agents in the field” using One Time Pads?, possibly, possibly not, who knows, nobody talks about them officialy (although there is documentation from the fallen parts of the “Iron Curtain” giving strong evidence that’s what the Russian alied ones were used for). But even if the operators of the stations did talk what are they going to say “a bloke in a small van turns up with a bunch of prerecorded tapes (or their modern equivalent) and we put them on air”. So it’s reasonable to say they could have a number of purposes including being the land equivalent of the “Submarine Fleet Broadcast Services”.
Aside from their mystique and usage speculation the number stations are however quite useful though as a quick and easy way to test you’ve set a broadband HF antenna up correctly for which ever way you want to work and check you’ve got the right “lift” to work into a place.
They come in a variety of forms including CW, voice, and even “music” nearly always AM and in the HF Broadcast bands. Which only needs the simplest of “travel pocket radios” to pick up. And it is this fact that is often used as an argument that the number stations are primarily for “agents”. This is plausible because as an agent you don’t want a load of “high tech” radio gear around effectivly it would be an Albatros hanging round your neck as you could not easily explain it away. But as always arguing from effect to cause is a fraut and very imprecise business.
However some of the number stations do transmitt much more complex signal formats including the likes of multi-tone FSK and fast morse and RTTY.
The DWS developed “Piccolo” back in the 1960’s ( http://ieeexplore.ieee.org/iel5/5247218/5251375/05251432.pdf ) which was used for diplomatic trafic which would have included messages for MI6/SiS “resident” officers. Originaly Piccolo used 32 tones (one for each TTY char) a later version used 6 tones sent as time seperated pairs (giving 36 pairs) with a small amount of AM to indicate which tone was the first of the pair. The tones are orthagonal and ten Hz apart and use a charecteristic of “orthagonal perfect quenched resonantors” to get exceptional discrimination and thus very very narrow bandwidth and very good performance. I was activly involved in designing a very low cost version of a Piccolo system ( http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA215692 ) to be much smaller and very much lighter than the then “Kaynard” LA1117 system from RACAL (sadly little or nothing of it remains now as it was a very clever design based around an 8bit processor and a handfull of other components).
The advantage of the more complex systems such as Piccolo is that they can be fully automated and used by “stay behind” teams and with more modern designs used by behind lines “bricks” of advanced/forward troops. This advantage is that they work very well with HF condittions and very very low RF power and fairly short transmission times, thus making them very very difficult to DF. I remember one series of tests pulled very reliable comms from a skywave using around 5 watts from the “brick” end which was around about a quater of the way around the world.
Getting back to the traditional number stations they are extreamly simple just a “plate modulated” class C output stage and a tape recorder will do. This is something a 14 year old can do, as it only requires the knowledge you can get from any one of several hundred “amateur radio” constructor books. And I do know that in the late 70’s a couple of tenagers did just that and set upt their own number station just to poke a bit of fun at the “number hunters”, when they weren’t using the transmitter for “Pirate Radio” at the weekends…
Any way it would appear that number stations are still up and running and perhaps surprisingly on the increase in recent times. Which if they are being used for “agents” might suggest that old school espionage is on the rise…
David • June 10, 2012 6:40 AM
@Clive Robinson…
in the late 70’s a couple of tenagers did just that and set up their own number station just to poke a bit of fun at the “number hunters”
so, who was the other teenager? ~grin~
Clive Robinson • June 10, 2012 12:56 PM
@ Joe Loughry,
I think they are realy nice photos, I might just blow one or two up to “poster” size and hang them on the walls.
With regards,
Permanent inhabitants of the space station exist in a high radiation environment.
This is my second post that is going to involve Chernobal… Up above I mention the Russian “Woodpecker” the transmitter and antenna array are in it’s “exclusion zone” but people still visit for the photos and to actually use the antenna…
The funny thing about the exclusion zone is contrary to expectations the wild life is healthy and thriving even though the backround radiation levels suggest they should have been effected considerably.
Likewise the “moon walkers” are doing better than you might expect on average.
So some are thinking perhaps radiation in it’s various ionizing forms at lower levels might actually be healthy as opossed to the original “dangerous at any level” thinking.
On another subject I note from your home page that Andrew Martin is your advisor. He and I have similar interests, which reminds me,
@ Wael, Nick P,
You might find the following of interest,
Wael • June 10, 2012 1:58 PM
@ Clive Robinson, Nick P
“http://www.cs.ox.ac.uk/files/1873/RR-08-11.PDF” Was of intrest to me at one point, and still is. I was a participating member in the TCPA steering committee, and later TCG. Stay tuned… Organizing and proof-reading my next post…
Wael • June 10, 2012 3:47 PM
@ Clive Robinson and Nick P,
This is why I was interested in the “castle-v-prison” model and discussion: Long post alert!
Quick background:
A few years ago, I was working on a definition of security. I did not like the Confidentiality / Integrity / Availability / (Accountability) definition. Was too abstract, and only partially applied to information security (don’t ask me why). It did not easily apply to general security. Still, that definition did not help quantify the security level of the object under investigation – That was my thinking then. My thinking now is “Security” is still a fuzzy term that cannot be quantified for a system (Algorithms are exempted). That is a different discussion, however…
Came up with this definition:
“Security” is “The painless ability to protect the asset through complete awareness and total assured control by the owner of the asset.”
I guess you can already see where the castle and prison may fit.
A brief explanation:
Painless: Users’ perspective: If it’s too painful, users will elect to bypass it. Other perspectives were skipped. Pain could also refer to the amount of money and resources spent to “Secure” an asset. It could also refer to “Usability”, which also implies Usability-v-Security tradeoff.
Ability: Is a successful defense against an attack (or all attacks) a necessary condition to claim a device to be “secure”? Ignore “sufficient” for now.
Example: A person is about to go on a trip to the jungle. He asks for someone to protect him from the dangers their. They tell him take this rifle with you, the only threats you will face are lions. He takes the gun and goes on the trip. The question is:
Does the lion have to attack that person and the person comes back unharmed after using the gun to claim security, or was it sufficient that he had the ability to protect himself? The assumption is that we know that guns are effective against lions. That’s why “Ability” was used.
Protect: Had a problem with this one – sounds like circular definition because “protect” is related to safety and “security”, it could even be a synonym in some languages – as some have indicated in previous posts. For the sake of the definition, protect means the dictionary definition or basically deflecting or defending against harm. Harm is any threat – independent of known or unknown – which will be covered in Awareness. Linearity and superposition at work here 😉
Asset: The object to be protected – Could be a physical device, an operating system, a keystroke, the whole network infrastructure, or just some information residing on a device.
Complete awareness: This is necessary. We cannot protect against some unknown threat. “Known unknowns”, or “Unknown unknowns” (that seems redundant to me, Mr. Robinson.) Obviously complete awareness is elusive, and we can only aspire to achieve that, but no one can claim they have exhausted enumerating all threats. In the example above, if the person going on a trip falls in quicksand and croaks. What was the reason? The rifle did not help him! It’s the lack of awareness (analogous to a 0-day vulnerability) that got him.
Total assured Control: Control, with feedback that the control mechanism has been applied successfully. Cryptography can be the method of assurance here (challenge response.). And after your last post, Clive, this implies “Trusted Computing”. “Assured” also implies accountability, logging mechanisms, etc.
Example: A mobile phone is lost, and a remote command is issued to it to erase data. We know the command was issued, but to be sure, we need to get some feedback from the device that the command was executed successfully. This feedback should be immune from various attacks (replay, cut and paste, DoS, etc. …). Otherwise we can only claim that a command has been issued, but we are not sure if it was executed, in which “security” degenerates to a “best effort” approach.
By the owner of the asset: To protect against “role misappropriation” type vulnerabilities. Who is the owner? There could be many owners for, say, a cell phone – with different and sometimes overlapping and / or conflicting concerns:
1- Manufacturer of the chip set: Concerns may include bad reputation or lawsuits
2- Content providers: Movies, eBooks, music, etc.… They want to be compensated for their product, and not lose revenue to piracy (DRM related)
3- Carriers: They don’t want to lose subsidization money, phone cloning, billing fraud, etc. …
4- OS providers: Overlapping concerns as chip manufacturers, more or less…
5- End users: The human beings that purchased the device, they care about privacy (private files, GPS privacy, browsing habits, call privacy, texting privacy, identity theft, billing fraud as well (900 numbers in the US for example), physical device security, etc. …
6- OEM: Reputation, law suites, bad relations with the other owners and lost business opportunities.
7- Enterprises: They want to be able to enforce IT policies.
8- Governments: Who knows what they want …
9- Enemies: are not an owner per se, but they have concerns (Subversion)
So why by the owner? The one who is most interested in the asset should protect it; the one who is legally liable should protect it. The one who actually owns the asset should take the responsibility of protecting the asset. The owner should not delegate the protection of an asset to someone else (non owner). This has caused some security breaches in the past. Examples omitted for the sake of brevity.
From the above definition, absolute security is not possible for two reasons:
1- No one has complete awareness of the threats
2- No one has total control (let alone assured) – subversion is a possibility as well here. (Nick P: hint-hint, wink-wink)
So this is where the Castle-v-prison comes to play!
For example, to mask the holes (known unknowns, or unknown unknowns) in an Operating system, one can put that OS on top of higher assurance Hypervisor or Micro-visor (OKL4, which claims to have proven to be 100% bug free, and achieved EAL7). The hypervisor gives the control (to compensate for the lack of awareness of the vulnerabilities of the OS). Hypervisors are smaller, and easier to evaluate that a full Operating system.
It’s no longer (in my opinion) a “castle-v-prison problem”, but a set of prisons within the castle. With different levels: Jails (Think FreeBSD style jails), prisons, and maximum Security cells (No quotation marks for security, because this is the real world “prison security level” nomenclature). These cells can be allocated to high value assets.
Prisons are a model of sandboxes, Virtual Machines, or Appliances (applications running directly on top of a hypervisor without an OS), or full applications / OSs running in a trusted world (Trust zone). The could be the “enclosure” or system that protects some assets. It could be modeled as the hardware and the mechanisms to protect against entry into the castle; Firewalls (moats), etc.…
Regarding Trust, it is also an overloaded term. Some use it interchangeably with “Secure”. Trust does not imply goodness (TCG point of view). Trust simply means that you have high confidence believing the reported state. Example: I trust that a doctor will help me (a psychiatrist for some spammers, a veterinarian for some trolls), as much as I trust that a thief will mug me – this is behavioral trust. So trusted booting has a completely different meaning than secure booting. All Trusted boot mechanisms are secure by default, but not all secure boots are trusted. Trusted means a device can attest or prove to a challenger that it is in a certain state. The challenger has the ability to (cryptographically) verify that state, and consequently trust it and act accordingly. Secure boot normally means that the boot image can not be tampered with (Immutable Boot block, Firmware, boot loader, etc. …); It can only be updated by the manufacturer, OEM, OS vendor (one of the identified owners). It also means that an end user cannot just boot any image they want (low level images, for example modem image on a cell phone). This implies digital signatures …
To evaluate the security of the device, you look at all those elements and judge.
During a design stage, one will keep the owners in mind, and make it easy for them to “secure” the device (or assets they care about). Simplicity is also good. Complexity and security are not a good mix – That is one reason I had some questions about what Clive meant by “security-v-efficiency”. Efficiency can also be an efficiency of design – but I guess we ironed that one out.
Is it evident from the Confidentiality/Integrity/Availability definition that 100% security is not achievable? That definition is adapted to help in Threat analysis, but not so much in design. AND the “castle-v-prison” does not jump out of the definition either ☺
That summarizes my interest in the model you guys came up with, although I maybe using your model from a different perspective ☺
I was tempted to talk more about who is in the Castle and their roles (IT guys are guards, security guards at the door (modeling authentication and sometimes authorization), Sharks and crocodiles swimming in the moat, and sometimes jumping to other castles’ moats to bite their counter parts (modeling attorneys),
Clive Robinson studying the composition of the castle bricks, and the electromagnetic properties of the building materials (CPUs, threads, RF bitflip mechanisms, …) Mr. Schneier sitting in a blimp up their watching the castles around the world, and giving them advise, and sometimes enjoying movies at “Security Theaters” near you ☺
Just for *hits and giggles, apply the above definition to the TSA:
Painless: Nope, extremely painful for some passengers. Some of them avoid air travel, because of the pain they have to go through. Also pain here means a lot of money is spent (wasted?)
Awareness? Nope! They (TSA) are only aware of security levels: Yellow, Orange, and Red. They, however, compensate for that impediment by being colorblind too ☺
Control? Trying to, but they do have a lot of control – I give them that!
Owner? Nope, the “real owners” delegate the task to a group of poorly trained consultants (TSA). “Owners” here is debatable.
Ability? Nope – News of many overlooked breaches (guns going through, etc.)
Assured? Nope
Secure? You tell me!
Appling the CIA (Confidentiality, Integrity, Availability) definition of security does not really help in the TSA example.
The definition move can be applied to all the layers of the system (HW, FW, Microcode, and up the stack(s) ), I would think …
Tag! You’re it 😉
Wael • June 10, 2012 4:22 PM
Never fails!
“as much as I trust that a thief will mug me – this is behavioral trust.”
should be:
as much as I trust that a thief will mug me – this is social trust.”, and TCG is about behavioral trust.
“The could be the “enclosure” or system that protects some assets.”
Should say:
” The castle could be the “enclosure” or system that protects some assets.
“The definition move can be applied to all the layers”
Should say:
“The definition above can be applied to all the layers”
“I was tempted to talk more about ..”
Actually slipped – was not supposed to be there blush
kashmarek • June 10, 2012 6:29 PM
More FUD from the duds:
http://hardware.slashdot.org/story/12/06/10/1838212/kinect-you-are-the-controlled
which is about serving ads based on emotion (and who has time to watch ads while using Kinect?)
PenTester • June 11, 2012 9:31 AM
@Clive Thank you for those really awesome ISS pictures.
I LOLed at the spy number database site. They have amazon adverts, first item on display: Tinfoil.
Another thing why those stations are still around and very active. Nothing is more suspicious and interesting as a station that suddenly starts transmitting out of the blue or changing its transmission habits, schedule, format, frequency, etc. Very likely, that most of them are just there for the fact that they are there and are just transmitting rubbish for the time being.
Nick P • June 11, 2012 1:56 PM
Interesting definitions and stuff. I’ll critique the parts that seem relevant. First, the TPM has to go or be changed.
I have real concerns about TPM’s. The link Clive posted mentioned three good counterarguments against them: vendor lock in, DRM & large number of configurations measured. The first is enough reason to avoid purchasing any TPM’enabled device. Major vendors, including big time TPM pushers like Microsoft, have a long track record trying to put obstacles between their customers and any competing product. It’s a form of centralized control of people’s devices that sends profit in the direction of the controllers.
Recently, Microsoft showed this again with Win8 ARM devices needed firmware-enabled signing ability. Customers options: trusted boot with MS-signed software or no trusted boot at all. And pay extra for their choice of OS. Missing 3rd option: set your own public signature verification key & boot what YOU (or your organization) trust. My designs allow for this. It should be the default. Not in TPM’s alliance interests.
Second counter is DRM. Both the methods employed for it & the uses for it show the industries promoting DRM are quite shady. In the past, we’ve seen these industries trying to force people into proprietary DRM-ed formats whereby they need to buy an extra copy to use the content on different devices. We see something similar in the siloization of the web. DRM locks things down & hampers innovation, much like patents. Let’s not give them better methods.
The third issue is more technical. The paper mentioned that a device’s configuration might have a huge number of possible measured values. This depends on is usage, patching strategy, & even customization by software. The TPM’s strategy doesn’t seem efficient for the job. In my designs, there’s a certain amount of abstraction so that each level in the system is responsible for updating, verifying or re-hashing its own layer’s components. Each layer is handled separately, as well. There’s other possible variations that beat out the TPM.
“This is necessary. We cannot protect against some unknown threat. ”
Not necessarily true. Compete mediation, good design & good security policy means anything subject to it can be compromised in an unlimited number of ways & still not break security policy. This is an explicit goal of systems heading toward EAL6/7. Every (or almost) non-covert channel application attack discovered since GEMSOS was certified A1 (eal7-equiv) in the 90’s would have failed to violate its main security policy. That was the point of using these methods. A number of modern approaches are explicitly designed to defeat 0-days in certain parts of the security.
“Control, with feedback that the control mechanism has been applied successfully. Cryptography can be the method of assurance here (challenge response.).”
Total assured control requires that the TCBs of the host & server are untampered with, that they’re implemented correctly, that their comms stacks can’t subvert the process, and that the protocol works as advertised against sophisticated attackers. Cryptography is usually only a tiny part of the security of any real system. In fact, I rarely think about it at all, even in crypto appliances. (Hint: total assured control of anything is all about ensuring correct information flows & transformations.)
Good thought on owner having responsibility to protect things. Problem comes with the fact that there are often people who compete to be in control of the information, with their own justifications. As in DRM example, there was the owner (copyright holder) using the obscure format to limit the song to the device & the user believing they should be allowed to play content they purchase on whatever device they’re carrying (standard up to that point). Who is right? It’s philosophy and law. However, enforcement is owner’s responsibility.
“So this is where the Castle-v-prison comes to play!
For example, to mask the holes (known unknowns, or unknown unknowns) in an Operating system, one can put that OS on top of higher assurance Hypervisor or Micro-visor (OKL4, which claims to have proven to be 100% bug free, and achieved EAL7). The hypervisor gives the control (to compensate for the lack of awareness of the vulnerabilities of the OS). Hypervisors are smaller, and easier to evaluate that a full Operating system.”
The funny thing is that they’re reinventing the old Orange Book security kernels. The point of a security kernel was that it could cover holes in all application & OS functionality. It would be the lowest software layer. It was also small enough to evaluate. (Sound familiar? 😉 That failed for a number of reasons in the general case & succeeded in other cases.. Btw, OKL4 isn’t EAL7 or bug free: the seL4/OKL4Verified version has EAL7+-equiv software correctness proofs (just one EAL7 requirement) and we never claim bug-free of anything.
I think it would have helped you if Clive explained his castle and prison analogy better. (or it be easier to understand for newcomers haha) You’re thinking of an actual prison cell & how it’s isolated. Clive uses it b/c of prison guars & the warden. His idea is that the system will have tons of very simple processing elements with limited hardware access. They can have program/data inserted in, turned on, run fine grained functions, & be suspended at any time to check for “signatures” of foul-play going on.
You were also thinking of an actual castle, whereas Clive mainly uses the term as “impenetrable fortress” or “weathers all conditions.” My castle approach is about prevention. It’s the previous standard in INFOSEC. (Current one is non-INFOSEC 8). The castle starts at its foundations. It’s built ground up to resist problems. Each layer has a rigorously analysed specification & an implementation that provably corresponds to it. Any safe implementation principles are applied where they can & pen testing is used. Upper layers use the functionality of lower ones via carefully constructed interfaces. Any looping between layers is nonexistent or minimized. Applications have minimal privileges & can only ask for things to be done. Like GEMSOS & Smith’s LOCK, it’s built with the best assurance techniques possible to achieve what it must achieve.
(Papers on LOCK are available at cryptosmith.com. For GEMSOS, look up Final evaluation report Gemini Trusted network processor. Focus on design and assurance sections for GEMSOS security kernel.)
Recently, as insecure COTS is inevitable, I’ve switched to a hybrid that’s similar to his approach, but castles up wherever appropriate. I try to lock in anything security critical into some small part of the system, then do any extra assurance there, ignoring or selectively monitoring the rest. So, if it fails, only availibility hurts.
I’ll let you rethink it in light of this information. The links I sent you before, maybe plus GEMSOS/LOCK, are critical in understanding discussions of truly secure systems. You might also want to Google Cygnacom’s Evaluated Assurance Levels description, focusing on what makes EAL5-7 different from the rest.
(Btw: I’d appreciate if you’d never use TSA in an analogy for security again. They are the most hated example of security theater in existence & a distraction from all things good.)
phred14 • June 11, 2012 3:06 PM
I traveled by air last week, and a few fun observations…
In Newark, NJ, if you go in through the A terminal, there is no full-body scanner. I presume there is one over at the C terminal. The A terminal is for “express jets” and the C terminal is for the big guys. There is a shuttle bus running between A and C terminals. I guess the people at each security line do look at your boarding pass, so it probably isn’t a simple as going to the A security line with your C boarding pass. But I’m sure it’s an exploitable hole.
Nothing major here, just a little amusement.
@Owen: Against what well accepted definition of terrorism do you make that claim?
Wael • June 12, 2012 1:52 AM
@ Nick P,
Thanks for the feedback. I don’t have the stamina tonight to talk about everything. What I can do is start with the easy things.
I propose we take it a step at a time, if you are okay with that rather than address everything in one post. What do you think? Hopefully Clive Robinson is not upset with me, and understands my sense of humor.
Speaking of TSA…
Just kidding 😉
Roel Spilker • June 12, 2012 8:19 AM
http://www.ted.com/talks/david_birch_identity_without_a_name.html
Nice talk about how identity and authorization should be decoupled:
“There is no earthly reason why your name is printed on your chip-and-PIN card.” … “The only people that benefit from having the name on the card are criminals. You know what your name is, right?”
Clive Robinson • June 12, 2012 10:05 AM
@ Wael,
What I can do i start with the easy things.
Sadly that’s the wrong place to start…
I know Nick P did not originaly agree with me but I think RobertT and myself have ground him down a bit.
The first thing you have to consider is “trust” and that it does not exist and more importantly why. If you don’t then you are “building your house on foundations of sand”…
Back in the 1930’s Kurt Godel can up with an unfortunate truth which along with Turings later work shows that what we regards as “trust” (ie that a system that has and currently does behave in a particular way will carry on doing so in the future) is a mear illusion.
The reasons for this are complex but without going into them a good starting point is,
1, No system can be trusted irespective of past behaviour.
There is however another outcome of Godel’s work, that can be put as,
2, No sufficiently complex locig system can prove it’s self.
Further there is a human issue, that few if any programers can actually write secure code at any level…
Getting back to “Castles-v-Prisons” from the outside they are both the same, that is they are a fortified or hardend structure designed not to be easily breached from the outside.
On the inside however they are very different. In a castle it is generally assumed tha “all insiders are trustworthy” but the oposit assuption applies to prisons.
This has further implications in that in a castle the command structure is also assumed to be trusted, however in a prison only the upper layers (Warden and warders) are trusted the low layers of “trustees” (prisoners who have earned privileges and limited authority over prisoners) are not trusted and continuously “measured”.
Now if you look at the silicon area on some modern CPU’s it’s vast, and the same area can hold upwards of 1000 very basic RISC style CPU’s
If you put an MMU between each CPU and the main busses going off to memory and I/O the CPU can be effectivly issolated. Now think what you can do by putting the MMU not under the control of the CPU but a hypervisor… You can then make the CPU effectivly blind as well.
One. asspect of this is that the CPU is also effectivly imprisoned. The hypervissor only gives it sufficient memory to carry out it’s execution thread and no more. Further it read/writes to buffers not memory or devices. It means that it actually does not require an operating system just a very very simple interface equivalent to a very striped down API all of which is unprivaledged and requires just a few bytes to implement (I’ve got one which is just a couple of hundred bytes and that’s still bloated). This API effectivly talks to the Hypervisor.
Now because you have so many CPU’s you could effectivly have each one running an independent thread of a task. The more you strip the fat of each thread the clearer a signiture it will have and the easier it is for a hypervisor to check.
As Nick mentioned above the CPU’s do not load their execution code into memor
$$$
Nick P • June 12, 2012 1:26 PM
@ wael
TPM specs. Yeah, well theres theory and practice. The main people pushing it are lockin loving vendors, pro DRM types, and the NSA, which has always undermined/restricted true secure systems in favor of vulnerable systems. Most likely, the group is doing a fait accompli strategy.
Say a group has an ominous plan to control anothers assets for their own selfish purposes. They cant just release version 1 of Total Govt and Corporate Control for x86. People resist, like Clipper. Fait accompli breaks main goal into pieces separated over time, each with a legit sounding and independent justification. After each passes.and chips widespread, protests are too late. Most likely whats going on. Theory! = practice.
Glad you are getting the castles and prisons thing but may i suggest u forget the castle analogy? Clives recent post shows its relevance is straining. Just go with ur mental model of what was in the links i gave u on security kernels, assurance techniques, etc. His prison analogy is fine for his stuff, though.
Re TSA dont take such statements too seriously formally whatever. Im not a Mod and pro free speech. The TSA is just such a clear example of security theater and beauracracy gone wrong that it has earned constant hate and ridicule here. The only way they tie into security is an example of doing it horribly wrong. You can say whatever u want it’s just that those letters can cause instant negativity among some.
And Clive definitely wont be offended by anything u say unless you’re trying to insult him. This blog’s readers are quite diverse but the regulars are laid back about things. We just come to share knowledge and have good discussions. We also shun Slashdot types 😉
Btw, one step at a time is fine. My post’s size or complexity is a habit from talking to Clive. He rubbed off on me or something haha.
Nick P • June 12, 2012 1:34 PM
@ Clive Robinson
I suggested Wael drop the castle part of ur analogy bc i think it’s straining to fit. For instance, the description you give might imply there is much trusted code inside in the sense people normally think about it. However, the security kernels and other high assurance systems were requirrd to be internally structured so that models and source-level analysis could show higher lvl layers cant abuse lower ones. Then there were integrity controls or capabilities (keykos).
So, this approach proved safe if the developers used correct layering and modeling. They got plenty good at that. The VAX Security Kernel Retrospective is a good read on those things. So, not quite as much POLA as yours, but the trustef aspects are quite restricted anyway.
If you really want prisons, its time you downloaded those TIARA and SAFE (or SAFER?) architecture papers. They aim to use taggef architectures to assure security at the word and function levels.
RobertT • June 12, 2012 9:49 PM
@wael
I don’t really have time for this right now, so I’ll be very brief.
Assurance must start at the most basic level (atomic / material physics) and build upon successive layers of trust, whenever that chain of trust is compromised there is a chance of a security compromise.
Clive is suggesting a Hypervisor overseeing 1000’s of cpu’s because these CPU’s can be kept so simple that their complete functional space can be effectively mapped. I’ve actually played around with a more complex version of Clive’s simple CPU with hypervisor model to add program encryption and data encryption (I’m assuming Harvard arch)
The Hypervisor controls the program decryption map which changes dynamically. I also devote certain CPU’s to the task of dynamically encrypting the programs for critical control and data calculation stream CPU’s. The reasons for this is to not only defeat any form of code injection but to also prevent any useful side channel information leakage, even assuming the attacker has physical possession of the system.
The way each hypervisor works and which cpu’s are assigned secure tasks is determined by a random number sequence generated at power-up.
This is intended to prevent someone modifying one or more critical CPU’s to extract information.
Upon this CPU beast one needs to build a model of trusted computing high assurance kernels, however this task is relatively simple if the CPU’s are not multitasking and largely operate completely within there own dedicated RAM space. All MMU external / shared memory accesses use encrypted data.
Part of the problem, that Nick P alludes to is that most interested parties don’t want high assurance computing released to the public, these concepts are not even remotely new, the last operational VAX that I saw was in 1988…..
Anyway, got to go
Wael • June 13, 2012 2:01 AM
@ RobertT
Thanks! That explains a lot. I still have some homework to do (links from Clive Robinson and Nick P) before I come back to this thread again.
Wael • June 13, 2012 2:07 AM
@ Clive Robinson and Nick P
I got immersed reading Kurt Godel’s work which I never heard of before. I am not comfortable reading his stuff, but still reading it.
I will leave TPM out for now, too many branches in this discussion…
Wael • June 13, 2012 2:21 AM
@ RobertT
Here is a suggestion for your random number generator:
int getTrueRandomNumber()
{
// This function returns a true random number
return 4; // the number 4 is random. It was
// found by throwing dice
}
This “program” was pinned on a previous collegue’s office door. I would like to give him credit but don’t want to reveal his name and invade his privacy.
Wael • June 13, 2012 4:00 AM
@ Clive Robinson
Quick question:
” Further it read/writes to buffers not memory or devices.”
What is “buffers” here if it is neither memory nor devices? CPU memory? Registers?
Clive Robinson • June 13, 2012 11:43 AM
@ Wael, Nick P, RobertT,
First of my appologies for being quiet, I’m not well yet again (no surprises there)
And if you don’t know UK hospitals, your choice of bed is “dictated” by nurses and thus you several times more likely to be by the door than the window, so very poor MobPhn signal 🙁 worse some hospitals have policies to force you to use the 10USD a day “personal entertainment” system which I refuse to do as the company that runs it not only sstings you for money they also sell your data on to other parties…
Wael, sorry I didn’t finish my previous post I had to “be seen” and got dragged into the very depth and guts of the building through doors marked “No Exit” which is always cheary not 😉
Any way RobertT provided a better finish than I did 🙂
With regards the buffers there are a couple of ways to do them one being hardware FIFO’s, another being a memory region controlled by the hypervisor such that it is either read or write and a pointer and indicator to indicate when full. You can likewise use a read only or write only stack. The point is it is one way. The CPU writes to it and the hypervisor or other CPU reads from it. To help reduce covert channels the size of the buffer is “changed” every so often asymetricaly to the two CPU’s.
I think I had better explain a little more about the Castle view. Most modern CPU’s are far from light weight and most are actually Harvard architectures for efficiency reasons with the two busses getting joined together shortly before leaving the CPU for the various “memory caches (ie after the seperate instruction and data caches) etc. Such designs have so many “step level” dependancies that they will be virtually impossible to analyse for security (for instance modern caches leak more information than most people can imagine over and above the well known “timing attacks”… Thus a modern CPU like the IAx86 family most ARM, PowerPC etc have way way to many little nooks&crannies to hide/pass/ communicate data that a hypervisor has absolutly no chance of recognising let alone mittigating… Thus they are like a castle in that most of those within have fairly free run of the place and don’t get heavily checked or supervised as it’s not possible to do so. So even with Nick P’s suggested ways of doing things there is still the odd “eye in the needle” that can pass not just a camels but an entire cities trade… BUT before I go further I will say that what Nick suggests is currently the only way to go unless you can cut your own sillicon and will get you 99.9999% of the way there, but each additional 9 is going to cost you very dear exponentialy. When you can cut your own silicon you can create lots of little prisons where there is no place or space to hide things and thus the hypervisor can check then in just a few CPU cycles.
As RobertT notes security starts with the physics and works upwards. However as long as you stick with a simple state machine where every state is known and dealt with appropriately, you can continue to assure your security. However as you get closer to a Turing Machine things become more and more problematic as the number of states rise to some power law of an exponential rise (simple logic with a single bit output rises at 2^(2^N) of inputs and any feedback or storage at the very least adds to N linearly but usually as some power… of the bits involved).
Put overly simply Kurt Godel showed that once a system of logic (not logic system 😉 gets beyond a very very simple state it cannot prove it’s self and when you work this over with the work of Turing you will realise that no single “Turing engine” can check it’s self to be secure…
Once you accept that as an idea it stops you chasing up a lot of blind alleys looking to find solutions that cannot actually exist.
So what to do…
Well when you accept the notion that you cannot get 100% or worse even 99% security without increasing cost and complexity (which always works in the attackers favour) you start thinking
Keep it, simple, keep it small, and look hard
Now the first two parts are relativly easy it’s the looking that’s hard to do. One of the first rules of secure hardware design is “segregation” that is you put individual functions in their own seperate hardware and then you heavily monitor the states and information on the inputs and the outputs.
One of the failings of nearly all modern software is it is so complex it is virtually impossible to debug, let alone check for security after the fact (it’s why I say security has to be built in before the product is even thought of which makes it kin of a qualitty process). Further as a percentage of the code cutters in the world the number who are truly engineers and can further design securely is so small as to be vanishingly small (even security experts often cannot code securely). They are certainly less than 1 in a Million. Further it’s not possible to train even a small fraction of code cutters to code securely in anything like a reasonable time.
So how to get secure software without the pain?
Well one way is to “follow the *nix prototyping path”. In shell programing the shell provides a simple framework into which you drop little tasklets that do specific jobs. You can very quickly build a working prototype of a program without cutting a single line of C or other “programing” language and usually it is fairly secure because of coding to the pipeline API. The disadvantage is it’s slow due to all the task switching.
Now imagine if you will that the shell has two parts, the first being the traditional shell programing interface, the second being a hypervisor. Each tasklet is written not only to be secure but also to interface with the hypervisor doing amongst other things signiture checking of the tasklet, and giving it the absolute minimum of resources to run.
A programer builds their “shell code” in the usual way and the tool chain then sets the security parameters for the tasklet for the hypervisor.
This sort of system alows software to still be written but at a much higher level from “know to be secure” tasklets. The secure control of resources stops being the code cutters responsibility and helps remove many side channels. Importantly the tool chain giving each tasklet it’s own CPU and only sufficient resources to do the job does not give malware any place to hide.
Further as the hypervisor loads each CPU it can be a full Harvard design and the tasks written such that they neither “evolve” or be “self calling” in an uncontroled way. Whilst making the code cutters life marginally more difficult it makes signiture analysis and memory checking very very much easier.
Now to introduce a heretical idea… systems need only be “occasionaly secure”. That is in a hardware segregated environment you don’t need to check the hardware inside a segregated unit is secure all the time only when it has produced an output or has failed to produce an output within a given period of time. As the task effectivly “blocks” at output, the hypervisor can scan it’s instruction and data memories for anomalies to look for attempts at subversion. As it’s the hypervisor doing this not the CPU it’s self there are no “dynamic issues” involved as the CPU is in effect or practice halted.
It’s important to note at this point that the hypervisor is running on a CPU of it’s own, and thus it is possible if incorrrectly programed for it to be effected by the data it sees. This should not be allowed to happen, that is it is written as a simple state machine that either OK’s each simple test or “fails hard” (and in turn it is “watched” by a more trusted hypervisor).
Now for the realy heretical idea “Probablistic Security”. From the above I indicated that the security of a tasklet CPU only needs be checked on error such as a time out or when it blocks on output. Two points arise unless it’s an error you don’t need to check every time the CPU blocks only a percentage of them. Secondly it is possible that rouge code in the CPU could in some way sync it’s activities to the blocked state and thus avoid detection (very very unlikely due to resource limitations but theoreticaly possible).
So let us say you only check 1% of the times the CPU blocks (on average as you should do the checkinng randomly) and occasionaly at random times you just halt the CPU and check the memory etc.
Thus malware “injected” from “outside” has virtualy no memory to be in, no time refrence to communicate by and has no idea when the hypervisor is going to look for it”. Thus it’s not impossible to do but way way way above the malware games we crrently see or are ever likely to see. Importantly the amount of checking from zero to 100% is adjustable not in the tasklets but in the hypervisor, thus the degree of checking is dynamicaly adjustable as required.
It needs to be said that so far this is only a defence from “malware” or modification of exisiting code, not from deliberate insider attacks during code development. To protect against this is more difficult and this is where the higher level tool chains that Nick P talks about come in.
That is the “prison” system enables a significant security gap between the “tool chain” and the “Castle” Single CPU to be closed.
That said will it ever be likely to be built in practice, probably not in an “off the shelf design” because there are to many vested interests in the “castle” approach. And as Nick P has noted the tool chains are reaching lower and the kernels are becoming lighter and easier to protect thus in effect alowing them to reach higher if the rest of the system is designed accordingly (but the won’t actually ever meet in a Castle design thus an exploitable gap will always exist with current architectures).
What you will see is more of what RobertT outlined, that is the prison idea will move into System on a Chip (Soc) designs as a mater of routine because the security advantages it offers in such environments is immense. And as you will realise that with a little thought the prison system can be split across a number of chips such that you can with carefull design actually use chips that might have been “backdoored” in some distant Fab by some “Chinese APT” agents.
Any way use the “prison” idea as a thinking tool, to generate more ideas with, because even if you never get the chance to use it for real just thinking about how you would will broaden the possabilities available to you and also hopefully stop you chasing yourself down dead end path ways.
Any way I’ve just heard the sounds of “dinner” being brought up (in trollies not by a patient that will be later 😉 so I must skulk back to my appointed “black hole” again lest I not get fed the delights of over cooked starch and cellulose…
One quick last thought hospital wards have a classic example of efficiency-v-security… Many years ago the more senior nurses and doctors had “rooms” where patients were not allowed where discussions could be held and records kept. In the name of “efficiency” these were all replaced with “open plan “central nursing stations” where patients and their relatives are expected to be to make requests and enquiries. Well patient information is thus freely on display to any one with working eyes and ears with multiple doctors and nurses making the best of limited space often with their backs to patients and their relatives when working at computers so “sholder surfing” data is easy. Finally the so called “Quality Care Commission” has woken up to this so the “patient data” has to be put out of sight…
But where… the offices don’t exist on modern wards they have been “designed out” to maximise ward space thus “efficiency”. Thus the result is actually in some cases to close “bays” on a ward or convert “therapy rooms” on the ward to “office space” no matter how inconvenient or (mentaly) unhealthy such places may be… I’ve even seen a room that used to hold supplies of dressings and other day to day items being converted to office space, but… as the only place to store the “drugs trolly” is in this room or at the nursing station I’ll leave you to imagine how bad a solution that is 😉
Nick P • June 13, 2012 2:18 PM
@ O W
I believe you’re quoting Wael, who I think was speculating on hypervisor-based security. If you’re interested in that, the better modern examples of that are INTEGRITY Padded Cell, LynxSecure, PikeOS & OKL4. The source of OKL4 3.0, Turaya, Nova microhypervisor and Fiasco.OC are available. To see what a high assurance hypervisor takes, google “Retrospective on VAX Security Kernel.” A modern, complex one on x86 would be MUCH harder to do right. Then, there’s weaknesses in the chip and firmware… (sighs)
@ Wael
I wouldn’t put TOO much into the Godel work. The current line of thought in mathematics can apply one day & totally not the next. There’s huge debate in the formal (mathematical) methods community over how to apply his work. The thing is that he might be right overall, technically, etc. However, they keep finding potential shortcuts, exceptions and just ways of applying their ideas successfully in spite of Godel’s proclamaition of doom. Peter Guttman’s pessimistic paper on formal methods was sadly much more realistic. Most of that’s overcome by doing it right with experienced people, with much exp. accumulated since the paper.
(Yet, if you look at A1/EAL7 systems, they’ve lived up to their security claims. The verified CompCert compiler did amazing in tests where competing compiler’s middle ends were buggy by comparison. INTEGRITY-178B RTOS, MULTOS smart card os & AAMP7G processor have similarly lived up to claims. Anyone listening to Godel or Guttman might have not tried.)
Wael • June 13, 2012 2:23 PM
@ Clive Robinson,
Hoping you will get better soon and get out of there. Your posts require a lot of thought to reply to. So if I take too long, its not because I lost intrest.
Nick P • June 13, 2012 3:04 PM
@ Clive Robinson
Ah, so now all of our work finally starts to intersect in cross-roads. It seems that things are getting interesting right as I was considering leaving INFOSEC for a field where I could get things done. 😉
“so many ‘step level’ dependancies…”
Never heard it put that way. I always say legacy. Nice way to put it, though. x86 might be the worst for this because, unlike ARM, many of its vestigial (there’s one!) parts have almost NO use due to being superceeded. The cache’s alone are very high bandwidth timing channels. I would say this stuff doesn’t matter but it might if we remove low hanging fruit: current malware model has sophisticated people devising the exploits, packaging them as kits, and selling them to less sophisticated. I figure we’d see timing channel kits, firmware subversion kits, etc.
Best recommendation for this, for now, is combining a verified processor like VAMP (or a simple one, at least) with a modern non-leaking cache, IOMMU, trusted boot, & firmware that uses non-writable boot ROM & writeable flash together. That should provide foundation to stop most software attacks. I agree with exponential increases in difficulty past a certain security margin w/out chip-based security.
“Now to introduce a heretical idea… systems need only be “occasionaly secure”. ”
It’s not so heretical. Different forms of it have been in security for a while. Examples include not doing permission stuff until an access, recovery base systems that wait 15 min b/f restores, and integrity-check/attestation during critical operation.
“It’s important to note at this point that the hypervisor is running on a CPU of it’s own, and thus it is possible if incorrrectly programed for it to be effected by the data it sees. This should not be allowed to happen, that is it is written as a simple state machine that either OK’s each simple test or “fails hard” (and in turn it is “watched” by a more trusted hypervisor).”
I’ve always had a problem with this. Your design is great for POLA & information flow control. The problem comes with the other big requirement: timing. Just mere context switches brought old systems to a crawl. Your design wouldn’t just require putting code/data into processing units & managing them. It would also require scheduling a large number of activities across a (likely) smaller number of processing units, possibly integrating their outputs at some point, managing hardware IO, and managing UI activities. How would you do all of this w/out your system comparing unfavorably to a 20Mhz IBM PC circa 1993? 😉
Btw, what I just wrote is sounding similar to the Cell processor. You might want to read Green Hill’s or other security analysis of it. Has some interesting features. It’s just too weird and expensive for me.
“Secondly it is possible that rouge code in the CPU could in some way sync it’s activities to the blocked state and thus avoid detection (very very unlikely due to resource limitations but theoreticaly possible).”
It would seem very hard. If it happened, I think the components would be relying on external input to clock the channel OR take advantage of the fact that many applications demand a response in a certain time range. The latter would make the former easier.
Btw, it might be easier to autogenerate the hardware for your prison approach from application requirements. i.e. application-specific TCB to run on ASIC or FPGA. The reason I thought about it was Tensillica’s Xtensa processor kits. Unlike FPGA acceleration, the Xtensa kit lets you design a processor, then the tools generate it and an entire toolchain to go with it. Honestly, I think that was the realistic version of the dream goal driving original interest into FPGA’s by software people. Really neat product idea.
http://www.tensilica.com/products/hw-sw-dev-tools/for-processor-designers.htm
“And as you will realise that with a little thought the prison system can be split across a number of chips such that you can with carefull design actually use chips that might have been “backdoored” in some distant Fab by some “Chinese APT” agents.”
I agree totally. I’ve done that in my designs that I worked on for the past year or so. No doubt inspired by increasing paranoia from discussions with you hardware guys on this blog. My basic model is to use more trustworthy, but maybe limited, chips for the critical code. Then, non-security-relevant functions like storage, networking, etc. are put on one or more boards that can be backdoored for all I care. It will only matter if I let it. 😉
“Well patient information is thus freely on display to any one with working eyes and ears with multiple doctors and nurses making the best of limited space often with their backs to patients and their relatives when working at computers so “sholder surfing” data is easy. ”
Tell me about it. I was in the doctor’s office yesterday for [hopefully] my final checkup on rotator cuff strain (thank God not ‘tear’!). Hopefully, back to the gym and martial arts soon! Getting ahead of myself. Anyway, I was concerned about all the personal info. Scheduling was done with name and birthdate. This was not optional… What disturbed me most is I could always tell if someone was about to see me by hearing them rummage through the papers outside the door. All this HIPPA, encryption, access control, monitoring, etc. & someone just has to walk up in scrubs and pick up my chart. Medical record security my (bleeeep!)…
Unrelated
The group behind the Flicker architecture keeps doing interesting work on minimal means to get low TCB execution on Intel/AMD using TPM’s and stuff. The paper below from Microsoft Research claims Flicker (at that time) had a TCB of 250 lines thanks to design. (They exclude hardware TCB, which is there anyway I guess.)
http://research.microsoft.com/pubs/165720/parno-cacm.pdf
Here’s other stuff from that group. I plan to read the Lockdown and CARMA papers later. Eventually: I just updated my stuff by downloading over a 100 papers from IEEE and ACM for mid-2011 to 2012. I’m glad I have no access to SpringerLink. It has some good abstracts and I already put way too much time into this stuff. 🙂
Clive Robinson • June 13, 2012 4:31 PM
@ Nick P,
and I already put way too much time into this stuff
And I predict you will continue to do so… untill that day you think, I’d better write this up as a paper/book etc, then and only then the reading and thinking looks easy 😉
With regards,
rotator cuff strain
I’m assuming it was semi self inflicted from a “sporting activity”. Sadly my sporting activities from yeas ago and doing such things as jumping off walls and out of second story windows etc with 50+ pounds of kit on my back because “Her Maj” was paying me to, have caught up with me in compressed spine, shot hips knees and ankles…
Whilst I can still get about there are days when it would be less painfull to hang upside down like a bat 😉
With regards the FPGA’s I can remember a time when you would “roll your own” state machines come CPU’s because the likes of the 68K were just not cutting the mustard for IO and other related high through put activities. Some where I have a copy of a paper from Charles Moore and others about turning a TI-DSP into a RISK CPU using a subset of Forth as the native code… People just don’t seem to be as inventive these days with digital chips up in the THz range…
And this lack of inventiveness actually hurts security because people are not encoraged to “think outside the box” just to get an ordinary days work done any more.
Any way you have given me some more reading to do, where is a nice hot cup of the brown stuff 🙂
Nick P • June 13, 2012 5:54 PM
@ Clive Robinson
Haha. I keep seeing old timers telling me about how their bodies suffer so much for all the activity they did as they were young. Is God sending me a warning? I wonder.
“People just don’t seem to be as inventive these days with digital chips up in the THz range…”
Yeah, most aren’t. You must give us credit though: designs are so complex these days that, even with great tools, it’s still hard to fully grasp & properly execute them. Also, most of the modern “hackers” aren’t throwing their best ideas at boring jobs at work: they channel that into their creative side projects, some of which end up being useful for work.
My personal experience with hacking stuff together like you describe is a bit scattered. Probably the best example was doing “Web 2.0” stuff on “Web 1.0” clients and servers. Back then, we called it “DHTML” (a la dynamicdrive.com) and scripting. My goal was to make the browser just a bit more like an application interactivity-wise and do most work in real applications written in real programming languages. (Sound familiar? 8)
And by real programming language, I mean Visual Basic 6.0. Haha. People hated on me for it, but I liked its RAD/GUI abilities so much I wrapped plenty of good C/C++ functionality in it & just did most one-off stuff in VB. I think I used Perl for much server side stuff, hacking scripts and administration. All of this was before I fully understood concepts like TCB, maintainable code & vendor neutrality. Still fun though.
Hope you enjoy the reading. The CARMA thing is directed at reducing hardware TCB in the face of very serious threats. Flicker has potential short-term. Some form of Tiara or SAFE(R) architectures might be desirable compromise between castle and prison for specific apps in the future. It’s all fun to read.
Clive Robinson • June 15, 2012 5:02 AM
@ Nick P,
I don’t know if you have seen the bruh har about PGP designer Phil Zimmerman, apparently he has linked up with a couple of Ex SEAL’s and the CEO/CTO of EnTrust to form a new company called Silent Circle, offering “no backdoors comms” for 20USD/Month.
Apparently they did some research over “friendly legislation” countries and of the top three Canada, Iceland & Switzerland they went for the one closest to the US…
However they appear to have designed things around mobile phones…
I wonder how they are going to deal with “end run” issues within the OS and hardware of such platforms…
Mrs. Robinson • June 15, 2012 10:53 AM
cell phone dildo for easy storage but not so deep that it requires a doctor to retrieve it. it should fit deep within my “silent circle”.
Nick P • June 15, 2012 12:47 PM
@ Clive Robinson on Zimmerman’s new products
Thanks for the link. Hate debunking someone like Zimmerman. Oh, we used SEAL’s so the software is better! They ‘shot holes through the bad ideas’ no pun intended (ok, my quote haha). BS detector at 90%. Anyway, let’s take a look at this.
First claim: “We have for very unique, elegant products. (email/phone/video/text)”
You mean we can now buy an encryption app for email, phone, video or text? That didn’t exist before? Usably?
Second claim: “With the level of defense Silent Circle provides, it meets Department of Defense and Federal Govt standards.”
Which are lower than ever before & segregated based on risk. FIPS 140-2 & EAL4 are almost certified insecure, yet they are standards. TS/SCI accreditation or Type 1 certification are (supposed to be) high robustness, yet I doubt the product will make that cut. Even Windows is pushed as Fed Govt certified.
Third claim: (Zimmerman) “Generally speaking, this is designed for hostile environments… traveling overseas in a hostile environment.”
BS meter is around 95% now. In hostile environment, people are likely to try to eavesdrop on you in a number of ways. Overseas, evil maid attacks are a real threat. There’s snatching & bugging your phone, bugging your room, getting a hotel next door & using a plastic cup on the wall. 😉 A mobile phone app is NOT suitable for a hostile environment. Usually.
Conclusion
Phil Zimmermann once was a forerunner in deploying solutions that work for the masses to stop govt intrusion into their lives. Back then, people also often said what a product couldn’t do. Today, Phil is in a company using SEAL’s as a publicity stunt to push products with bogus claims. It’s sad: I was once a big Zimmermann fan.
Honestly, if I faced off against Zimmermann on this, I would give Frank Rieger et. al. at Cryptophone credit for doing what Zimmerman claims to do. They have a good protocol, opened it & their code for review, hardened the OS, & test their supply chain periodically.
Rieger and I certainly had a nice little debate on this blog in 2007 regarding whether they could prove no subversion exists. However, I’ve always said that they’re doing things the right way. The only thing they needed to do is get their TCB in control, maybe using a microkernel. Well, OK Lab’s and their partners built that stuff, so if Cryptophone retargets to that on their own hardware, they’ll be as good as usable mobile security will get. Alternately, I hope Silent Circle finds a timely end in the marketplace.
Nick P • June 15, 2012 1:11 PM
Interesing developments for the Boeing Secure Network Server (SNS). Honestly don’t know what to make of it. SNS, previously MLS LAN, is one of the last two surviving A1-class systems of Orange Book days (Aesec’s GEMSOS is other). The NSA said, under RAtings Maintenance Program (RAMP), A1 vendors would only have to recertify what updates changed. Then, upon Common Criteria, they said all B3/A1 programs must re-certify under EAL schemes. Most couldn’t afford it, but Boeing is a big defense contractor.
So, first Boeing SNS was quickly certified to EAL4+. This means nothing in practice & was likely done so they could begin sales to federal govt. Everyone knew Boeing SNS would get certified higher than competing border security solutions, probably close to EAL7. The article stated EAL7 was their next target.
Source
http://www.boeing.com/news/releases/2007/q2/070621b_nr.html
A number of people CV’s and LinkedIn talked about building EAL7 evidence for Boeing SNS. Yet, I had to hit the Wayback Machine to pull up 2010 “In Evaluation” list to prove it for sure.
SNS going for EAL7
http://web.archive.org/web/20100103081527/http://www.niap-ccevs.org/in_evaluation/
I went to do my periodic check, as EAL7 border security is nice. Imagine how surprised I was to see it was successfully evaluated at… EAL5+. Same as more recent XTS-400. Dropped an entire assurance level, then another. 😉 Well, to be fair, the + = “augmented/extra” & it has a LOT of extra’s (see yourself).
Certified Products List
http://www.commoncriteriaportal.org/products/
So, I grabbed the validation report and security target. I had an old copy of both, which were targeted at EAL4+. Now, you guys might have to take my word for this, the Boeing SNS in EAL7 evaluation didn’t have a dedicated security target. I figure they would just swap EAL4+ for EAL7. Instead, the final reports have a target and completion at EAL5+, plenty lower than before. Although, admittedly, the TOE security is rated HIGH.
So, it seems that the last A1-class product going for evaluation failed to meet both EAL6 and EAL7, dropping to EAL5 Very Augmented. So, a major defense contracter can’t or won’t do an EAL7 guard. Is this truly the end of high robustness outside of smartcards and separation kernels? Stay tuned!
Nick P • June 15, 2012 1:32 PM
I’m thinking I should have read the validation report before posting. Too much coffee I guess. I stand by the previous post with these two amendments.
The validation report says:
“Boeing performed a search of all public domain sources for known vulnerabilities and performed a flaw hypothesis strategy to identify potential product vulnerabilities. No residual vulnerabilities remain in the product.”
I checked the glossay to see if there was a definition of “residual vulnerabilities” that might be different than mine. Not seeing one, this led me to believe they are saying no vulnerabilities remain in the product. Quite a claim for a product that didn’t make high assurance. Most high assurance projects in safety-critical industries don’t say there are “no flaws,” just unlikely to be any serious ones.
It’s getting kind of deep in Common Criteria circles, if you know what I mean. 😉
Section 12 “National and international interpretations and precedent decisions”
Well, I forgot what that meant & it’s irrelevant. “International” got me thinking: there’s a possibility they dropped to EAL5 to make international sales easier. They no doubt spent a ton of money on this thing & want to earn it back. I’ve said before B3/A1 systems had export controls & premably their equivalents EAL6/EAL7 do, too. A number of EAL5 products are available internationally. Maybe no export controls on them?
I don’t want to give them an out in the event that they just didn’t make the cut for EAL6-7. However, it’s possible that they targeted for EAL5, augmented with the most important EAL6-7 requirements, so that they could sell to US and allies unimpeded. Honestly, I was thinking about targeting any secure products I developed at EAL5 for same reason. (Maybe certifying the first at EAL6-7 to prove our process is that good.)
Just a thought…
Nick P • June 15, 2012 1:44 PM
I’m thinking I should have read the validation report before posting. Too much coffee I guess. I stand by the previous post with these two amendments.
The validation report says:
“Boeing performed a search of all public domain sources for known vulnerabilities and performed a flaw hypothesis strategy to identify potential product vulnerabilities. No residual vulnerabilities remain in the product.”
I checked the glossay to see if there was a definition of “residual vulnerabilities” that might be different than mine. Not seeing one, this led me to believe they are saying no vulnerabilities remain in the product. Quite a claim for a product that didn’t make high assurance. Most high assurance projects in safety-critical industries don’t say there are “no flaws,” just unlikely to be any serious ones.
It’s getting kind of deep in Common Criteria circles, if you know what I mean. 😉
Section 12 “National and international interpretations and precedent decisions”
Well, I forgot what that meant & it’s irrelevant. “International” got me thinking: there’s a possibility they dropped to EAL5 to make international sales easier. They no doubt spent a ton of money on this thing & want to earn it back. I’ve said before B3/A1 systems had export controls & premably their equivalents EAL6/EAL7 do, too. A number of EAL5 products are available internationally. Maybe no export controls on them?
I don’t want to give them an out in the event that they just didn’t make the cut for EAL6-7. However, it’s possible that they targeted for EAL5, augmented with the most important EAL6-7 requirements, so that they could sell to US and allies unimpeded. Honestly, I was thinking about targeting any secure products I developed at EAL4/5 for same reason. Just a thought…
Nick P • June 15, 2012 10:29 PM
@ OW
I appreciate it. Read the links I gave Wael (below) and you’ll be off to a nice start in INFOSEC defense. Of course, there’s developing the security mindset, learning how things are broken, reading up on Schneier, & reading both editions of Ross Anderson’s Security Engineering book (1st is free online).
http://www.schneier.com/blog/archives/2012/06/friday_squid_bl_329.html#c779145
Wael • June 16, 2012 12:25 AM
@ O W,
Whatever do you mean? 🙂
I am Stil here. Just thinking of nice words – thats all 😉 And last minute travel is not helping me …
Clive Robinson • June 17, 2012 12:30 AM
@ O W,
I’m still around and back at home “recovering” from my recent medical probs.
First and foremost in any study of things technical or scientific is the “Scientific Method” ( Bacon/Abbot not Aristotle). Which Francis Ellingwood Abbot’s described in 1885 with,
Now all the established truths which are formulated in the multifarious propositions of science have been won by the use of Scientific Method. This method consists in essentially three distinct steps,
The important thing to notice is “observation and experiment” on which all else rests.
To be able to “observe” you need some rational and testable method of measurment by which comparison can be made (sadly InfoSec lacks usable “measurands” currently).
To “experiment” you not only need measurands you also need a “testing rational” which is generaly derived from your hypothesis.
Thus you need to have a fundemental grip on “Testing Techniques” at numerous levels. Due to the lack of real measurands, InfoSec testing techniques lack any rational basis (and similar can also be said for software and other intangible information based fields of endevor).
Luckily most tangible engineering fields of endevor have a strong rational basis of measurands and thus mature testing techniques.
The field of endevor with good testing techniques that are well documented for the beginer and onwards which is clossest in rational to InfoSec is electronics.
A good understanding of testing techniques I would also say Should Be a prerequisite for anyone trying to write software that is maintainable or supportable and it is an absolute must for anyone trying to design high availability or high assurance systems.
Wael • June 17, 2012 8:12 AM
@ Clive Robinson, Nick P, O W,
Clive, I am now in your time zone now for the next few days. Looked at all the links you guys provided. One question I have is where is the root of trust in both your designs? Nick P, the link about the modern hypervisors, etc. is nothing new. And the link about TCB also came from people that previously worked on TPMs. I have met at least one of them in the past.
Also Clive, the description of the hypervisor in your design includes functionalities outside what hypervisors do today, such as breaking down a process into various simple threads and distributing them among some CPUs. You may want to give your “hypervisor” a different name, such as a “wardenvisor”. I have a lot more comments later once I get rid of the jet lag (forward in this case).
Execuse the lack of sleep, but I leave you with a comment from area code 11221
On thier discussion, Clive and Nick got stuck
With Guards and Wardens running amock
Serving within the castle are the two grunts
Pulling all kinds of “trusted” stunts
The grunts are overwhelmed and need help from another trusted schmuck
🙂
Wael • June 17, 2012 3:08 PM
@ Clive Robinson, Nick P,
I am often confronted with statements that seem conflicting when I read the posts. That is one reason I wanted to get some definitions out of the way, or reach an agreement on them.
You say: “No system can be trusted irespective of past behaviour.”
Then later you say:
“In a castle the command structure is also assumed to be trusted, however in a prison only the upper layers (Warden and warders) are trusted the low layers of “trustees” (prisoners who have earned privileges and limited authority over prisoners) are not trusted and continuously “measured”.”
“Earned privileges” imply “previous behavior” which conflicts with “No system can be trusted irespective of past behavior”
There are two ways I can reconcile these two statements in my mind, 1- That you are referring to the current state of security models, which you are improving on with your suggestion. 2- I have to give the word “assumed” in “assumed to be trusted” a higher precedence, and take the whole trust thing with a pound of salt – a grain of salt is not enough to enhance the taste here, but a pound still makes it difficult to swallow – if you know what I mean 😉
I have yet again some more questions:
1- What do you mean by “trust”? Nick P, please don’t send me links.
2- Who does the measurement? I am presuming the hypervisor as you mentioned previously
3- Is the hypervisor also measured? How often? Or is it immutable?
Suppose you have an application or a process running. According to your suggestion, the hypervisor will distribute it over 10’s or 1000’s of CPU’s – a simple thread each. Then the hypervisor will randomly stop some CPU’s and check their state for anomalies. According to RobertT, the hypervisor is running on a random CPU chosen during bootstrap:
Question and a suggestion:
First the question:
1- How would the hypervisor know what to look for? You suggested some heuristics, but are these sufficient to detect deviations by the CPU or the code that is running on it?
2- How would the hypervisor know what an anomaly looks like if it is not described in the “set of policies” that define what is outside the norm (unless you are implying “complete awareness” here)
3- Does not your scheme suggest that to verify what is running on a CPU, the hypervisor must also be able to run that exact thread on another CPU and compare the two states at any given time – time synchronization assumed.
Suggestion follows:
1- Define the target of the system (commercial, military grade, etc…) – For Nick P, CC and the EAL levels, etc. …
2- Describe the high level simplest system we can look at and analyze.
a. Hardware configuration
b. Boot strapping
c. Firmware and its relationship with the hypervisor
d. CPUs
e. The component responsible for dividing a process into simple threads and distributing them among the CPUs
f. The component that gathers the threads again and combines them into a meaningful output
g. The actual threat you are protecting against with this scheme
h. Characteristics of the OS
We can ignore manufacturing, deployment, upgrading, repurposing, maintenance, and decommissioning and relevant security implication for now…
Nick P • June 17, 2012 4:07 PM
@ Clive Robinson
I was wondering where you were going with that at first. With respect, I disagree. I know proving security can be likened to proving a negative, but I see it as a positive proof of information flow properties.
With regard to empirical, we certainly DO have measures to use in science. Fagan’s inspection process and the Cleanroom method were both proven via defect counts. Cleanroom is statistically certifiable, leading to it being warrantied by some firms.
Other methods focus on the process (e.g Common Criteria) or artifact attributes. For the former, we can track security defect rates of a process overtime to predict the likely No. of defects of future products. EAL5-7 or higher DO-178B typically produce WAY better stuff than others.
As for artifact attributes, we have indirect measures that give insights into security rating. Bernstein noted the benefits of reducing code, esp trusted code. We also know language and runtime design can provably eliminate certain issues. All confirmed by measurements at different points.
So, testing is important and all, but scientific measurements do exist to support the use of other methods.Ill personally say relying on those i could afford has worked as advertised.
Nick P • June 17, 2012 5:08 PM
@ Wael
It seems you’re mostly addressing Clive’s design, adding in stuff from RobertT and I. Ill address what I think might be relevant to my stuff.
The root of trust is the hardware. It has to be b/c security is ground up. I simplify by making it a simpler than x86 chip (if possible), integrated crypto a la VIA Padlock, two state at least, IOMMU, read-only boot memory, & flash for main boot stuff.
The first function is the immutable bootloader loading, doing basic tests, loading from the rewritable flash, verifying its signature, and passing control. This lets us modify core stuff in the future in a trustworthy fashion and helps defeat software subversion of firmware, BIOS, or core kernel code. Now it is trusted.
This layer initializes and runs checks of its own. This might be driver stuff, CPRNG’s, unique capabilities, verified transition of core state (e.g Production to Auditing), etc. This layer might have compinents for dynamic monitoring of applications/VMs, mandatory access, integrity checks, etc.
At app layer, things are decomposed a bit. The designs approach the sep. kernel vendors are pushing looks nice for the basics. However, it doesnt address things like provenance or assured pipelines well. So my stack might be modified at any of the lvl’s to accomplish this & xtra-trusted boot helps too.
Without a whole system EAL5-7 effort, I dont find the hypervisor, etc approaches to be as robust as vendors claim. Worse, theyre doing it on Intel’s overly.complex, legacy ridden, errata prone platform. This is why my recent designs over past year or two have bypassed the issue by turning logical into physical separation wherever possible. Example follows.
The SINA architecture is Germany’s answer to HAIPE and govt IPSEC. The mental model is red-black, with crypto/guard in middle. MicroSINA used decomposition & L4 kernel to essentially turn the system into three logical components: internal facing network (in VM or bare min); external networking; viaduct IPsec. The networking components were complex, but untrusted. The trusted Viaduct component’s TCB was tiny.
This is the kind of thing sep kernel vendors are pushing. Issue: plenty of shared hardware and firmware not factored into assurance and TCB claims. Also, Intel-like stuff better for untrusted stuff and robust SOC better for security critical stuff. Solution: divide system into components logically separated both within hardware and across hardware. Either COTS nonDMA IO or DMA IO into a sec-critical board with IOMMU.
Applied to MicroSINA. Cheap, high performance boards do networking on both sides. Maybe run robust in general OS like OpenBSD. DOS protection & initial filtering of malicious activity happens here very fast. Both connected to SOC with hardware design i mentioned paragraphs ago. It has a robust RTOS, fine-grained POLA, & designed to ensure correct flows. A coprocessor or separate board might be tied into memory buses to detect and act on privileged code modifications. Most assurance evidence and stuff is limited to one board and component.
Another proposal along these lines was using a PCI backplane for the system. Most safety-critical RTOSes and SOCs are targeted to PCI or VME boards anyway. Can pick cheap/fast boards for stuff like storage, networking, apps, etc. Can pick higher end boards for trusted apps or appliances. Maybe add secure traffic to backplane or backplane-level IOMMU on card interfaces.
Many, many types of systems and networks can be built on such an architecture with varying levels of security.
Wael • June 18, 2012 1:48 AM
@ Clive Robinson,
I need to retract this statement: “Earned privileges” imply “previous behavior” which conflicts with “No system can be trusted irespective of past behavior”
Upon rereading your post I realized that I missed that “prisoners are not trusted” and need to be measured. This still does not change the apparent conflict…
Wael • June 18, 2012 1:53 AM
@ Nick P,
“It seems you’re mostly addressing Clive’s design, …”
— Correct! Will talk about “your stuff” later 😉
Clive Robinson • June 18, 2012 6:14 AM
@ Wael,
One question I have is where is the root of trust in both your designs? N
Agh you’ve just fallen into the “my axioms don’t work” problem.
There are two issues with a “root of trust”,
1, It’s inherently hierarchical.
2, It implies an “overall trust”.
Both of which are very bad for security in any form.
Your first question should be,
A, Do I need to trust?
To which the answer is no. Further as Kurt Godel little theroms have shown ultimatly you can not trust. Further with a little thought you will realise that past behaviour is no indicator of future behaviour, afterall you have to kill someone first to become a murderer…
A second question is,
B, If I chose to trust does it have to be absolute?
Again to which the answer is no. Trust has multiple dimensions which are to numerous to relate so simplisticaly you can chose to trust in terms of time or function or both. As Bruce noted in his recent book he got a workman in to do a job did he trust him and if so what did he trust?
The simple answer was he acttually did not consider giving him any trust other than the mild trust he would be at a specific time and place and a larger trust to do a specific job. But did Bruce have to worry about the larger trust, well probably not many houeshold insurance policies have a section to do with “faulty work” as do some payment cards. That is Bruce had mittigation against his larger worry. Bruce might have had further trust wories in that the person might steal, abuse or assult him, Bruce could quite easily have mittigated these risks if he’d wished to.
And this is an important point about trust, you mittigate it where possible and when you think about it it is always possible to mittigate against, it becomes a question of resources. The way to minimise the mittigation resources is to minimise the requirment for mittigation by minimising the requirment for trust.
The problem with a hierarchical system is it concentrates trust in very few entities at the top of the hierarchie… Further the larger the hierarchie is the more powerfull the upper levels have to be so the more potential they have for creating breach of trust.
Now a specific example, a prisoner is by definition “untrusted” in one or more things. Thus a prison is dessigned to give the absolute minimum of resources to the prisoner to survive the confinment.
About the only thing a prisoner is initialy “trusted not to do” is “kill themselves” in inventive ways, because the normal ways have usually been mittigated against by the removal of anything that could be used as a weapon including, personal effects including matches, lighters jewelry, watches, specticals, etc. further anything they might conceivably use as a ligiture such as laces, belt, blankets sheets and even clothing. Further modern cells usuall have no points to which you can attach a ligiture to hang yourself from. And assuming you decided to chew through a vein or two they have CCTV cameras and regular patrols by trusties or guards. That being said some prisoners do manage to attempt to kill themselves and a few of those occasionally succeed.
Eventually prisoners are trusted to do work of some kind. However this is again mittigated against in that what they can do is strictly controlled and the minimum of resources provided to carry out a specific functtion are provided. That is they are provided with the minimum of tools and raw materials and the finished work is quality checked and the tools taken away when the work is finished. Also the prisoner is subject to randon searches etc.
Now if you are talking about non sentient devices such as CPU’s there are some things you can do.
The first is “black box” test it’s response to input stimuli to find out if it is capable of carrying out an individual task. What you cann’t do is ensure it is “reliably” functional because your test inputs cannot go through all possible states to ensure there are no “hidden” circuits to change functionanlity. Further even if it was sufficiently simple that all states could be checked, you do not have the abbility to test continuously. So an expired time timer may be in place which might trigger at some point in the future to await a trigger state.
How do you mittigate this well simply with supply chain diversity and voting protocols of one form or another that look for changes of behaviour.
However asside from “functional trust” there is communications trust. Let us assume we have mittigated against a CPU (group) trust breach by using say a 2 of 3 voting protocol. We need to ensure that collusion is not possible so we have to close down communications paths etc. This can be done in a number of ways but it gets complex to describe them. The simplest is to actually have say 5 CPU’s carrying out repetative tasks. What you do is randomly halt 2 of the 5 and use the remaining 3 to do this particular itteration and select the vote. The next itteration you randomly select another 2. This way no CPU getts to see all itterations and has no idea of where in the sequence of itterations it might be in. This makes collusion difficult at best. Likewise you can feed different CPU’s with different data where only part of the data is actually required the other parts of the data act as a canary that is you know in advance what the result should be and if it’s not right it “sings out” that the CPU in question is not behaving as expected.
You can go on with these mittigation techniques to your hearts content and at various degrees of testing. The point is they start from the position of assuming the individual CPUs are not to be trusted so play them off against each other in a way where when they “go bad” you have a very high probability of discovering it.
It’s not perfect and it uses a lot of resources, however the “extra resources” range from zero upwards. Where zero is where you do not have the need to mitigate or test.
The further trick is designing such a system that allows for variable “traitor checking” resources whilst aalso not having a hierarchical trust tessting/signaling system.
Nick P • June 18, 2012 11:44 AM
@ Wael and Clive Robinson
Wael: Thanks for clearing that up. Well, you already have an initial answer. Please save that description as it took 10+ minutes to type on a mobile phone. 😉
Clive: I’m actually interested in your answer to Wael’s question, if you have one. I’ve asked for specifics on your design in the past & you said you prototyped it a bit. Here’s what he asked for specifically:
“Question and a suggestion:
First the question:
1- How would the hypervisor know what to look for? You suggested some heuristics, but are these sufficient to detect deviations by the CPU or the code that is running on it?
2- How would the hypervisor know what an anomaly looks like if it is not described in the “set of policies” that define what is outside the norm (unless you are implying “complete awareness” here)
3- Does not your scheme suggest that to verify what is running on a CPU, the hypervisor must also be able to run that exact thread on another CPU and compare the two states at any given time – time synchronization assumed.
Suggestion follows:
1- Define the target of the system (commercial, military grade, etc…) – For Nick P, CC and the EAL levels, etc. …
2- Describe the high level simplest system we can look at and analyze.
a. Hardware configuration
b. Boot strapping
c. Firmware and its relationship with the hypervisor
d. CPUs
e. The component responsible for dividing a process into simple threads and distributing them among the CPUs
f. The component that gathers the threads again and combines them into a meaningful output
g. The actual threat you are protecting against with this scheme
h. Characteristics of the OS
We can ignore manufacturing, deployment, upgrading, repurposing, maintenance, and decommissioning and relevant security implication for now…”
The a-h parts, in particular, allow the system to be modeled, analyzed and tested in software.
Wael • June 20, 2012 4:00 AM
@ Nick P,
Time to talk ‘bout your stuff. Just the first relevant paragraph for now to keep the discussion contained.
The root of trust is the hardware. It has to be b/c security is ground up. I simplify by making it a simpler than x86 chip (if possible), integrated crypto a la VIA Padlock, two state at least, IOMMU, read-only boot memory, & flash for main boot stuff.
The first function is the immutable bootloader loading, doing basic tests, loading from the rewritable flash, verifying its signature, and passing control. This lets us modify core stuff in the future in a trustworthy fashion and helps defeat software subversion of firmware, BIOS, or core kernel code. Now it is trusted.
I will take two points from your paragraph:
The root of trust is the hardware. It has to be b/c security is ground up.
Hardware? So the root of trust is the Motherboard, CPU, Chipset, MMU, memory, monitor, keyboard, mouse, peripheral cards, printers, your wireless hotspot (?), the works …
Trust is a relation of sorts between two or more entities. When you say the root of trust is the hardware, there are two meanings:
1- You trust the hardware
2- Another machine; a server trusts the hardware (or the system as a whole)
#1 is subjective; I am ok with EAL4+ for my needs, and you want nothing less than EAL7, for example. And #2 you have not explicitly addressed.
The first function is the immutable boot loader loading, doing basic tests, loading from the rewritable flash, verifying its signature, and passing control. This lets us modify core stuff in the future in a trustworthy fashion and helps defeat software subversion of firmware, BIOS, or core kernel code. Now it is trusted.
How do you as a user, not as a designer, verify, and consequently “Trust” or “Believe” that:
1- The system has an immutable boot block
2- The chain of trust was followed in the bootstrapping process, meaning each stage “measured” the next stage before handing control to it, and flagged any signature mismatch.
The other part of the question:
How does a remote machine “Trust” or “believe” the current state of the your machine; same two questions above?
Let’s get this out of the way and then continue. We’ll give Clive time to consider whether he wants to share his IP with us.
@ Clive Robinson:
“Trust” here is about the current state of the machine, not about past or future states. Also “Trust” does not imply goodness in this context. Trust means you believe that the entity reported the honest state. That honest state may very well be something really bad (that is you “Trust the reporting”, but don’t necessarily like it) — then you can react accordingly. Or it can be something you like and believe with a certain degree of assurance.
Clive Robinson • June 20, 2012 6:16 AM
@ Nick P, O W, Wael,
The first trouble is finding time to reply as time is in short supply at the moment (don’t get ill you only get sicker by trying to catch up 🙁
OK a definition of trust is always a pain because it means different things to different people in different ways… It generaly has a tendancy to be nebulous to the extream and thuss “wooly” to the point of uselessness. In essence it always boils down to “don’t trust as you will be let down” or similar.
You should therefore ignore the all encompassing terms used by many (that only appear to make things more difficult to understand) land look at it in a more practical way,
You have a job that needs doing by an entity (human/computer/pet dog/whatever) what do you actutally expect to occurre?
Well the human race has been doing “business” longer than written records go back. Thus it’s a well trodden path, and the usuall “business driver” is “Compleated to Specification on Time and Budget” or,
1, The job get’s done.
2, It get’s done correctly.
3, It get’s done within a timeframe.
4, The costs are within norms.
A fail in any of these is generaly a breach of contract either express or implied and is thus also a breach of the “trust” the contract forms. But a contract can and often is also used to define various other terms of “trust” such as,
5, Non-Disclosure.
It’s why I prefer to think not in terms of “all encompassing trust” but interms of a “contract of behaviour” simply because it’s practical and fairly easy to identify fault. Further you can have a specific contract for a specific job which alows for variation as required.
Importantly “If it ain’t in the contract, it ain’t covered” which clearly indicates on who’s shoulders the responsability lies. As you draw up a contract you will identify each area that needs to be addressed and importantly how to test for breach etc. Obviously this contract goes on to form part of the initial and subsiquent specifications. As such it realy should be done before you even think about specific projects, products or processes, which means you need to think of the contract in terms of a standard or base methodology.
Importantly don’t get caught on the “specifics” at the higher levels as frequently they become “prescriptive” and quickly out of date it’s a fault you often see in legislation (“cabs for general hire should carry a bale of straw” etc).
Also remember “every rule has an exception” and you need to identify the “Who Where & Why”. Likewise identify other “edge cases” as these are where most “security issues” arise.
Wael • June 20, 2012 7:03 AM
@ Clive Robinson, O W, Nick P
Ok. As long as we agree on a definition. We can use “Trust” the way you defined it. Let’s see what Nick P has to say when he wakes up.
BTW,
“every rule has an exception” is a self contradicting statement — It’s a logical fallacy. But worry not, your message got across — “Trust” me 😉
Nick P • June 21, 2012 8:37 PM
@ Wael
“Hardware? So the root of trust is the Motherboard, CPU, Chipset, MMU, memory, monitor, keyboard, mouse, peripheral cards, printers, your wireless hotspot (?), the works … ”
I figured you’d know I meant the main chip: CPU or SOC. Most of that other stuff ties into it in a way where they can be shutdown on fail, ignored, or secured with additional layers on top of (or protocols alongside) a trusted core piece of hardware.
“1- You trust the hardware. 2- Another machine; a server trusts the hardware (or the system as a whole)”
Or the hardware is trustworthy in what is the generally accepted case. (People always forget “trustworthy”, maybe b/c many “trusted” systems aren’t. 😉 Similar to Clive’s definition, the hardware we’re focusing on should do what it’s supposed to do. At the least, the security-critical part should meet spec in practice. Since the spec covers many threats & situations, the system would be secure in spite of those.
“How do you as a user, not as a designer, verify, and consequently “Trust” or “Believe” that:”
The user often can’t. They can be lied to in so many ways. The user DOES NOT evaluate the security of the system in the general case. Typically, an independent assessment by experts with plenty of access to the system and time on their hands is used to verify the claims. As the assurance level goes up, the amount of verification and knowledge of internals does as well. Specs, code, implementation, compiler, configuration, distribution… this is all examined in a medium to high assurance CC evaluation.
The first trick is, “Do you trust the process?” So, the process must be correct to ensure it can catch the issues you need to worry about. Mine exceeds CC requirements in a number of ways to account for issues that have appeared since it was formed. It will be less than EAL7 in practice b/c of cost, time-to-market, usability & legacy issues. A protocol & design done at EAL7, followed by a robust implementation, is a good compromise. EAL5 is already better than 99% of the market & a market viable product of mine would be EAL5+ certified, with EAL6/7 pentesting & other additions.
Additionally, you need to trust the evaluator. First, they must have the competence to evaluate the product. The main evaluation labs for highly robust products are Cygnacom, SAIC, & NSA. They’re competent. Next, you need to know they won’t subvert the product. If it’s your product & you’re out of their jurisdiction, you just worry about your own employees & your hardware supply chain. (Use multiple competent bughunting groups, too.) If you’re a customer buying a certified product, you must be sure the producer & evaluater didn’t work together for subversion.
I’m in favor of trying to make the hardware layer manufacturer neutral & getting the rest validated by mutually distrusting national evaluators. The owner of the IP should be in a neutral country that respects IP laws & is friendly with the G8 type countries. To assist with SCM or compiler issues, I have a concept that I’ve promoted online before for an automated, decentralized, high assurance SCM that’s operated by mutually distrusting intelligence agencies. Everything could be continuously authenticated, tested, built, and distributed in a trustworthy fashion. Its trustworthiness could be bootstrapped overtime & implementations/configs could be done by local groups against a shared behavioral spec.
“2- The chain of trust was followed in the bootstrapping process, meaning each stage “measured” the next stage before handing control to it, and flagged any signature mismatch.”
“How does a remote machine “Trust” or “believe” the current state of the your machine; same two questions above?”
These are somewhat related, but not in my design. I’m not working on remote attestation b/c the use-cases I work on don’t require it. Additionally, remote attestation of non-TCB software can be layered on as an additional function done on top of the evaluated TCB. (Or the TCB could be modified in the future for it.)
The thing about my design is that it’s focused on risk mitigation. The design simply doesn’t allow incorrect firmware, OS components, etc. to be loaded. The flow control analysis, design & robust implementation strategies have stopped systems in the past from having TCB-level compromises or serious defects (see Praxis or B3/A1 vendors). Non-TCB compromise attempts can be dealt with at other layers via prevention, monitoring or regular recovery. An instance authentication mechanism, maybe with a trusted 3rd party for verification, could be used to show the system is running the robust environment & therefore probably not compromised.
” “every rule has an exception” is a self contradicting statement”
The statement is a rule of thumb, not a concrete law of reality. It would be more accurate to say that “most rules have at least one exception” or “every rule seems to have at least one exception.”
Clive Robinson • June 23, 2012 3:53 AM
@ Wael,
…. is a self contradicting statement — It’s a logical fallacy
Is it? we are dealing with humans here… 😉
The reality is looked at on mass we are actually quite bad at making rules usually because of underlying assumptions.
Just a few humans (scientists /engineers / etc) actually take the time to get to the bottom of things to produce the axioms and laws we can sometimes build on. As for the rest of humanity they wave there arms a little and say “You know what I mean”… hence as long as rules are made on unstated or faulty assumptions they are not laws or axioms, just rules with all the usual human failings.
Thus “Every rule has an exception” is a rule unless you know what I mean then it’s an axiom 😉
@ Nick P,
1- How would the hypervisor know what to look for? You suggested some heuristics, but are these sufficient to detect deviations by the CPU or the code that is running on it?
There’s a couple of questions there and I hope to answer both by only answering the first one.
But first just to make it clear to all who may read this, the whole point of the “Prison-v-Castle” idea is to try to plug the gap in the middle between the top down approach to security of the programers tool chain “formal methods” and the bottom up approach to security of making the underlying hardware trustworthy (which is another issue alltogether which will be discussed in another post on this page).
In practice it is this middle ground where the (supposadly) correct code is “executed” on the (supposadly) trustworthy hardware where the information (the security seeks to protect) is most vulnerable to an external attacker.
So back to your questions, the answer to the first is obviously the hypervisor can only look for what it is designed to look for, and that depends very much on,
A, The complexity of what is being observed.
B, The capabilities of the underlying sensors.
C, The capabilities of the hypervisor design [1].
The first issue (A) is the most crucial issue because at some point on the complexity curve there is a threshold where it is not possible to distinguish the signal from noise in real time (which is the point you raise in your second question). Below that point is another based on the capabilities of the hardware and a long way below that a point on what is practical to observe. Thus the primary issue of the design is to get the complexity of the observed tasks down below this point on the complexity curve whilst still being able to do usefull work [2].
So the essence of the design is to use a “divide and conquer” approach to reduce the complexity of monolithic programes into smaller less complex and well found [3] tasks (an almost identical requirment occurs in Parallel Programming). Thus reducing the complexity of a task that is being observed to a point where it is practical to do so.
This is the opposite of what was tried in the 1990’s to stop the various forms of Power Analysis that had proved so problematic for smart cards etc. Back then they added complexity to try to generate noise at a level where the task signiture was (partialy) masked. This did not work so the current aproach is the opposite, that is the idea is to make a given task produce a signiture that is not “data dependent” so that even if the signiture is visable to an attacker it leakes no information about the data. That is the signiture in effect becomes stable to the task not erratic due to data.
So the design links work in two different fields of endevor together to advance a third.
To give you an idea of the work involved for getting a task stable signiture, a simple task such as a loop has a very clear signiture in time provided the payload of the loop is likewise well found. However if the payload is complex and full of data dependent branches then it’s time signitures will appear erratic to the point of chaotic and likewise those of the loop. So data dependent times etc need to be either mitigated or moved up and out of the loop or individual task.
Thus the design of the payload should be such that timings should be as independent of the data as is reasonably possible. Doing this requires carefull thought, as in general usefull programs work on the data input to them. And worse programing is usually taught in a way (recursion et al) where data dependancies are increased not reduced.
I don’t propose to go into the methods to do this here as it’s very much a function of the task writer. As noted above it is a more generalised area that some Smart Card designers are working in to reduce the data leakage combined with that of parallel programing both of which will be in some published papers you’ve no doubt read.
So making a viable signiture with a simple or well found task is relativly easy to do as the inputs are few and the signitures very easily seen and stable.
This is effectivly the opposit approach of current practice where modern CISC CPU architectures with fast task switching and monolithic programs have signitures that becoming their own noise and thus very difficult to see.
So a RISC based ‘CPU lite’ has less places for things to hide and produces better time signitures than a CISC based ‘heavyweight CPU’. And as the hypervisor is on the same silicon as the CPU the signitures can be obtained directly from various points on the CPU as opposed to trying to “guess from the noise” on the power rail.
Further the simpler the task on a CPU the easier it is to check the signiture for exceptions, and the faster they can be found, the less potential harm can be done (in an ideal situation the hypervisor spots a problem before the injected code has been fully loaded).
Thus the main thrust of the design is to keep tasks to small size with well found behaviour. To do this you have to break down a typical monolithic design into well defined tasks thereby reducing the complexity in the execution environment greatly at the expense of shifting part of it up into the tool chain and part down onto the hardware where in both cases it can be better managed.
What the hypervisor is actually looking at in real time is either elapsed time or event counts from the sensor inputs. So if the task loop is not “running to time” then something is wrong. The hypervisor does not know what is wrong just that something is and thus it throws an exception and halts the task CPU.
What happens after this potential error is found is dependent on the hypervisor. It could simply flag it as a warning for the programers and dump the CPU core. Or it could examine the loop counter etc to see if it’s in range or examine the program memory for consistency. If all is in bounds it can simply “un-halt” the CPU. Such events do occur in programs normally when some kind of error occurs “down stream” or insufficcient data validation has occurred “up stream” simply because code cutters all to frequently don’t consider let alone address such issues when they code [4].
The response type/level is a function of what is observable by the hypervisor and what actions have been programed into it. In turn the hypervisor needs a usefull or well found signiture for the task to check against. As indicated above this is the hard part and needs to be built by those who know what they are doing. But if done properly it only needs to be done once.
In effect what you end up with is a library of. high(ish) level tasks that consist of a block of code and a signiture profile. The block of code has a very specific calling API that also provides information to the hypervisor to adjust the signiture profile appropriatly.
Provided the task API is defined correctly and likewise the code/signiture then an ordinary programer can use the task by just pluging in the numbers (or more correctly the tool chain does). The ordinary programmer does not need to know how to write low level “secure code” they simply pipline tasks together much like a shell script program.
Thus those very rare entities the “secure code writer” spreads their goodness across many many ordinary code cutters. In essence the secure programmers are like those experianced programmers who write (secure) operating systems they provide the less experianced coder with a safe environment.
It should be noted that this is designed to stop malware being injected into a correct task, not to stop coders writing code with potential malware in it. That task falls to the development tool chains you have previously mentioned and specification validators.
However there are some very usefull secondary effects in all of this.
One is that, as the complexity of the observed task is reduced, the resources required to carry out the task become reduced but more importantly more easily quatifiable and thus the required “program memory” can be rationed to do the specific task. In the process the ability to inject malware becomes considerably more difficult for an attacker (if not practicaly impossible). In practice this particular secondary effect actually gives the best bang for the buck (which I suspect is what RobertT found out for himself).
Another is that the process of making the well found tasks have their data independant signitures means that side channel leakage of data is also significantly reduced (though the tool chain still has work to do at a higher level).
And another occurrs as a side effect in the development process, the hypervisor is in effect a “debugging tool” [4] in hardware that cannot be turned off this forces the code cutters to up their game and deal with exceptions and input validation correctly.
[1] It is intended that the hypervisor be a state machine of reduced capabilities to that of a Turing engine so it is not “programed” in the normal sense of today.
[2] I’m ignoring “efficient” because it’s a marketing “red herring” these days. Long gone are the days where the cost of doubling a computer systems performance was significant in anything other than the very very short term. Further as can be seen with High Reliability/Availability systems having multiply redundant parts is a cost worth paying to achive the desired reliability / availability figures, the same applies to High Assurance systems.
[3] The term “well found” is not often seen these days as it goes back to the days of the building of sailing ships, you could substitute “well designed” but it misses the essence of being fully fit for purpose well found conveys. That is a well designed object may not be fit for a specific purpose for a number of reasons not least of which is a deficient specification.
[4] By far the largest set of exploitable weaknesses in modern programs are lazy or overworked programmers who don’t do proper input validation or proper exception handling. The reality of life is that the enjoyable part of coding which is “solving the problem of the business logic” follows the old 40/60 rule in that it should only be around 40% of the job the other 60% should be trapping and dealing with predictable exceptions and input errors.
Wael • June 25, 2012 1:02 PM
Is it? we are dealing with humans here… 😉
Is it? Yup!
Thus “Every rule has an exception” is a rule unless you know what I mean then it’s an axiom 😉
What is this double talk Clive?
“Every rule has an exception” is a Rule .
So, it must have an exception!
An exception could be:
“One rule has no exception”
which contradicts the original Rule .
And no! I don’t know what you mean, so it’s not an Axiom 🙂
One thing apparant from your “Castle-V-Prison” discussion is that you are
focusing on side channel attacks — Timings, caches, CPU architecture, etc …
You need to clearly identify the types of attacks you are protecting against.
You seem to imply — if not explicitly state — that all weaknesses are a result
of “Bad coding” or bad programmers. Can you enumerate where security weaknesses
come from? Let’s enumerate say a dozen. Then sniffle tell me which of them your proposal targets.
Wael • June 25, 2012 2:06 PM
@ Clive Robinson and Nick P
Clive,
“There’s a couple of questions there and I hope to answer both by only answering the first one.”
In the long response you posted, you have answered neither question!
Wael • June 26, 2012 1:01 PM
@ Clive Robinson, Nick P, O W
“Can you enumerate where security weaknesses come from? Let’s enumerate say a dozen. ”
And if you can fit these “weaknesses” in the Castle / Prison analogy – That would be super! 🙂
Wael • June 26, 2012 6:21 PM
@ Clive Robinson, Nick P, O W
“enumerate where security weaknesses come from? ” — Ok, here is a starter:
1- Faulty architecture (software – example would be no memory protection, no separation between user mode address space and kernel mode address space, and such)
2- Flawed Protocol (code implementation is perfect!, but protocol sucks)
3- Role misappropriation (giving the wrong task to the wrong person (owner, remember?)
4- Weak code — faulty code (not secure code)
5- User factors (device not idiot proof)
6- Too complex
7- Device lifetime mismanagement (manufacture, deployment,…,decommission) Basically womb-to-tomb device protection
8- Weak algorithms (Code faithfully implements the algorithm, code is bug free, but Algorithm sucks)
9- Weak hardware (leaks too much information, susceptible to various known attacks, can be put in debug mode by the user (JTAG for example))
10- Weak tool chain (compilers, debuggers, etc …)
…
Your Castle addresses these?
Clive Robinson • June 26, 2012 6:29 PM
@ Wael,
In the long response you posted, you have answered neither question
Hmm…
As I said,
“What the hypervisor is actually looking at in real time is either elapsed time or event counts from the sensor inputs”
That is the CPU it is watching, produces various “heart beats” via the sensors which should happen at known times for a known number of occurrences. Remember these watched CPU’s are always in “background” operation as they do not get interupts of any kind causing a state switch into “foreground” operation, thus their behaviour is very determanistic and easily measurable. Any deviation from the expected signal of heart beats is an indicator that ther is a problem. It does not matter if the problem is an exception or error in the program or an attempt to load malicious code into the execution space. The hypervisor halts the CPU and inspects it’s registers counters and execution space if all is not as expected then the hypervisor creates an exception.
How the exception is dealt with is another issue, for a higher level in the security stack to deal with.
The second question raised the question of “sufficiency”, this is one of these issues that is dependent of the complexity of an individual task. Beyond a certain point of complexity it is not realisticaly possible to have “reliable signitures” thus each task has to stay appreciably below that point.
If you then consider what malware has to do and how as a series of steps, the first is to cause a branch in the expected flow of execution. This branch will cause the timing of heart beats to change in time and this should be recognisable in a well found task, this should then trigger the hypervisor inspection of the CPU and it’s reduced environment. In most cases the malware will have corupted either the execution memory or program counter to gain control, the hypervisor should be able to see this as the execution code should not change in any way and the PC should be within an accepted range.
So the question falls to can a task be written in such a way that it produces the regular heart beat without it being effected by the data it’s processing? to which I believe the answer is yes.
Then the next question is can the heartbeat signiture be sufficient in of it’s self to indicate an attempt to branch the CPU away from it’s correct execution path? to which again I believe the answer is yes.
The next question is then can the CPU do sufficiently complex work either within one task or a series of tasks? to which again I believe the answer is yes.
My reason for beliving the answer is yes to the last question is the existance of “stack operated languages” such as Forth. They work by using simple tasks to build up complex tasks thus the working signiture of each simple task is what is being measured and observed by the hypervisor not the overal task which does have a complex signiture.
Does that answer the two question for You?
P.S. the comment about rules is a light harted way of saying humans are very bad at making “formal rules” that do fall within the bounds of logic. As Nick P indicated it’s a “rule of thumb” but in the general case due to the failability of ordinary human made rules actually need exceptions
Wael • June 26, 2012 6:45 PM
@ Clive Robinson, Nick P, O W
Clive, look! I loooove your castle and prison. I think it’s elegant, and that’s why I talk about it so much. It needs a lot of thought through though. Funny! The last three words of last sentence look weird together… Anyway, there is a lot to it. I am not trying to give you hard time, or prove you wrong. I just want to see this analogy go further.
Wael • June 27, 2012 3:10 AM
@ Clive Robinson
“Does that answer the two question for You?”
How rude of me! I forgot to mention that:
Yes, that answers my two questions. Thank you for putting up with me and for typing so much content on your virus infected smart phone 😉
Clive Robinson • June 27, 2012 3:43 AM
@ Wael,
and for typing so much content on your virus infected smart phone 😉
I’m not so certain it is a virus but a bug in the keyboard debounce and interupt generation. Basicaly like many smart phones it has way way to many buttons on it’s sides which makes holding it and two thumb typing on the midget keyboard an interesting problem esspecialy in a moving vehicle (which is where I do a lot of my typing 😉 Well the common denominator appears to be accidental preasure on the power button for a short period of time. I guess this is a known problem with Android phones as later ones have “raised guards” around the button or it’s sufficiently recessed to prevent accidental pressing whilst holding. As for re-flashing no it did not cure the problem. As it’s upgrade time in a few weeks I’m not sure spending further time on solving the problem is worth it.
Any way back to the more important stuff.
Clive Robinson • June 27, 2012 6:25 AM
@ Wael,
Can you enumerate where security weaknesse come from? Let’s enumerate say a dozen.
Hmm which “dirty dozen” to select.
Is the wrong place to start, the first thing to do is set the common and aaccepted back ground for the discussion.
So the initial thing is to realise that there are many areas where security issues arise. Very broadly at the 20,000ft overview level you have,
1, Hardware
2, Software
3, Specification
With their own major classes of attack, which have their own sub classes and so on down to actual instants of attack where the “dirty dozen” can be found.
The next realisation just to make it even more fun is to realise attacks come in two very basic forms,
A, Passive
B, Active
And also a combination of both where what are effectivly passive attacks can be stimulated by apparantly harmless actions. For instance timing attacks usually work by trying to synchronise an effect to a known refrence point. So if we assume you as an attacker want to enumerate the CPU clock drift you don’t want to be sending continous packets to get the TCP time stamp, you only want to send them slightly befor during and after the clock roll over period to catch it in the edge of the timestamp change.
The logical conciquence of this realisation is if you don’t know what an attacker is doing you can not always recognise you are being attacked because the stimuli may not be easily determanable from ordinary work. So in effect you only pick up “known knowns” some “unknown knowns” and no “unknown unknowns” except by chance (The Sony root kit, CarrierIQ being examples of type two adversary attacks, and Stuxnet and Flame being examples of type three adversary attacks oh and various malware being type one adversary attacks).
So lets first look at a “system host” consisting of hardware software and all derived from a specification as a unified whole as a “black box” (which is how an attacker sees it).
As a black box the host has inputs and outputs some of which are known and an unknown internal state. The internal state changes due to changes at the input and output and it also changes state due to internal operations which can be triggered non determanisticaly by an asynchronous event or determanisticaly by a function processing to a conclusion (such as a loop and it’s payload).
The aim of an attacker is to gain information sufficient to carry out a desired activity, this is usually called “target enumeration” a lot of which initialy involves just finding the desired host but is not realy part of this discussion. The second part of enumeration is having found the host identifing the host type ie hardware, OS, applications etc. So far much of this work can be done passivly by just observing traffic flows and types and other information. However unless the point of observation is very close to the host the types of information available by passive observation are (or should be) quite limited.
To get further information an attacker moves onto the third stage of providing stimulus to the inputs of the host and observing the various outputs. Again the closer the point of observation the better the quality of observed data and the less stimulation required. But in a reasonable host this will be limited to service banners and timebased information leakage. This usually means an attacker will move to the fourth stage of enumeration which is to use active attacks to get a toe hold on the host, to use either for observation, or a bridge head for further active attacks or a combination of both.
Obviously stopping the first type of enumeration is by conventional not IT security measures and sometimes means gaging the likes of the marketing and HR people who tend to give out to much information. For instance one organisation I’m aware of in a “puf piece” identified that they had taken on a Sun SPARC server to run a custom database of customer information and accounts and further indicated it was a break away from their traditional MS Server systems by saying they had taken on “fred smith” to administer it… Talk about giving an attacker a nice helpful sign post or three to find the system… Further a little look back in time showed rather detailed info in a job advert, and a hunt online gave “Fred Smith’s” CV full of other useful info which alowed other info to be googled for…
The second stage of enumeration is likewise difficult to stop without carefull thought. Almost invariably the information that gets out here is due to “Business goals”, and whilst IT solutions can partialy mitigate these problems, if there is a hole in your ICT perimeter through which data passess then people can see it to some degree (hence the idea behind “air gapping”).
At this point an attacker usually has a host systems location and a whole load of other info. If they are a type three adversary they have a whole host of possibilities open to them one of which is to get physical access to the machine or electrical connections to it which EmSec attacks might be carried out. Simillar applies to a knowledgable type two or one adversary who is also an insider.
But there are other significant holes by which air gaps are crossed, many of which are due to “crap software production” or an emphasis on “usability” over “security” (think USB issues).
As @ Nick P and myself have discussed in the distant past “code signing” is actualy in the main “security theater”. This is because all it actually does is attest to the fact that at some point somebody with access to the secret key has used it to sign a hash of a block of code.
Nothing more, that is it says nothing about the code or where it’s come from. Thus all that is needed is either access to the code upstream of signing, the private key or a way of finding colisons in hashes. Of the three a quick “black bag” or “insider theft” is all that is required to get code into the upstream side or a copy of the code signing key in the majority of cases.
Prior to Stuxnet Nick P was going through a thought process of how to improve this situation and as no dout he will admit it’s not an easy task.
Now we have Flame as well as Stuxnet, and people regularly getting into CA’s to make fake certificates indicating that all three methods of attack are fully viable attack vectors for even type one adversaries. Proving to some peoples horror that “information loves to be free” of constraint, thus security based on constraint of information is a very hard problem and not even amenable to audit unless you’ve 24×365.25 hard assed physical security (see A1 requirments) throughout the entire system life time.
Thus getting a toe hold can be done by the simple process of being at a point “upstream” of the host system’s security patch process…
Are there preventative measures, yes but only for some attacks and by amd large only to type two and three organisations who can use many access points to check the signed patches are genuine (as far as the code provider can tell… so not realy at all).
So one potential mittigation is to run an original CD copy of “old code” and don’t patch it or upgrade it on a properly “air gapped” system.
Does it sound practical in our modern world? No not realy although some of us still do have Win 3.1 / MSDOS 5 and code development systems from the 1980’s including a hand built C compiler and tool chain (have you ever seen a cross platform two pass assembler written in Apple Basic? 😉
Thus the assumption has to be these days that even type one attackers in the right place can effect general security greatly, whilst more targeted attacks are still in the relm of type two and three adversaries.
And the follow on from this is you cannot trust anything you don’t have 100% control over and even type three organisations have moved out of this relm due to COTS requirments.
Thus the only current solution to this is “voting protocols” on diversity sourced hardware to try and establish “trustworthiness” on a continual and ongoing basis.
Does this sound OK to you so far?
Wael • June 27, 2012 1:01 PM
@ Clive Robinson
“Hmm which “dirty dozen” to select
Is the wrong place to start, the first thing to do is set the common and aaccepted back ground for the discussion. .
I tried that twice already. And this is the second time you say “this is the wrong place to start”. When I first read Security-V-Efficiency post, I kept it in the back of my mind. I knew what you were talking about exactly. I only responded when I saw another post (The response to BitSplit and his new password idea) from you that seemed to negate your Security-Efficiency claims, then I asked you to clarify. That is how the discussion started with me. I quickly realized, as I have with others in the past, that the terminology we use is not consistent. Terms like “Security”, “Trust”, “Trustworthy”, “Efficiency”, and even “hypervisors” or “Virtual Machine Monitors”. So I decided to set a common plateau, so to speak, by posting something about what security means. I thought that would be the right place to start.
The next realisation just to make it even more fun is to realise attacks come in two very basic forms …,
Now you are talking about attacks and their classifications. It is accepted that there are 3 classes of attackers. Class I, II, and III.
Differences are more or less delineated (IBM classification).
And the follow on from this is you cannot trust anything you don’t have 100% control over and even type three organisations have moved out of this relm due to COTS requirments.
Thus the only current solution to this is “voting protocols” on diversity sourced hardware to try and establish “trustworthiness” on a continual and ongoing basis.
100% control over is a subset of Total assured control in the security definition I posted earlier.
Does this sound OK to you so far?
Sounds OK.
Nick P • June 28, 2012 2:37 PM
@ Wael on the security weaknesses & countermeasures
I’ll note that the Orange Book and Common Criteria requirements address a number of those. I don’t have an enumeration I go by. I think of it in terms of layers, system components, and interactions. That let’s me spot old things and new potential weaknesses. An example was when I avoided the “hyperthreading” feature for any MLS usage b/c I figured it was a glorified timing channel. Two decade old methods could prove this. Modern academics eventually did. (Not to say checklists, enumerations, etc. aren’t useful: they would be part of any commercial development I did in this area.)
First, though, I have to be clear who I’m defending against. Almost all the products on the market assume the administrator is trustworthy & the box isn’t in bad guy’s possession. There are tamper-resistant products that try to deal with these situations, but I’m currently focused on eliminating remote attacks. I say let’s deal with the 14 year old kiddies & state sponsered 0-day problem before we try to use technical solutions to stop insiders & physical attacks. (That said, I try to keep outside ports DMA-free & use tamper-resistance or 3rd party verification where useful.)
So, how do remote attacks happen? Generally, they will exploit a hardware/firmware bug, software bug, overprivileged piece of usable functionality, or misconfigured piece of privileged functionality. I’ll add special categories for attacks on protocols, attacks that use cross-platform portable OS’s (err, web browsers ;), and those that trick user into escalating privilges. If we deal with these, then we’ve knocked out the vast majority of options the attacker has.
Guess what? Much of it is doable with the right design or tools. Let’s start with how Orange Book B2-A1 (EAL5-7) systems handled things. They were required to use hardware features as much as possible: dedicated hardware optionally; rings to protect OS from apps & security kernel from OS parts; MMU; segments commonly acted as a less functional IOMMU. So far, the design ensures that security can be enforced at a granular level even if apps or certain OS functionality is compromised. The enforcer is also very small to allow top notch verification. Modern separation kernels follow suite, typically 10KLOC or less.
(Note: Capabilities have been the most popular primitive recently to use for access control purposes. From seL4 to the A1 LOCK design, they’ve matured overtime. They can be used to implement the conceptual ring models, access/integrity control, etc.)
The systems required other features. For one, a trusted path was required to let the user be absolutely sure they were talking to the system & not a hacker. Additionally, “trusted” window managers were demanded a la CMW to label/color various windows by security level & control how information was shared between them. TX is an older example. Modern Nitpicker GUI combines these concepts a bit to provide a way for applications to undisputedly prove the user input & output are on the right path, with very little code in TCB. Pitbull turns Solaris into a CMW, but with huge TCB & less assurance.
These two strategies, combined, would stop attacks that spring from a non-critical app to the system level or from non-trusted OS part to trusted component. The user couldn’t even authorize a browser- or app-based execution strain to access critical OS functionality. There goes most rootkits. I’ve added special update modes & unspoofable screens to the concept to allow that stuff to be safe. What’s next? Oh yeah, ensuring correct information flow & keeping software defects (possible vulnerabilities) low.
The early systems gave us ideas there. C was avoided for most privileged software in Multics & GEMSOS to make verification easier. Additionally, they used Parnas information hiding, modularization, strong module to spec correspondence, tons of tests, static analysis, & call-by-value where possible. This tells us to use safe languages, libraries, design strategies & coding patterns. It also tells us to do things in a way that our tools can analyze & catch problems. Lastly, it tells us to TOTALLY AVOID doing something whose effects we can’t predict, like tons of hyper-efficient pointer magic. Praxis’ Correct by Construction approach is a modern continuation of a subset of these principles.
The above paragraph mostly pertains to an individual piece of software. The best method so far for local systems is to define their behavior, model security, etc. by modeling each individual component, modeling interactions of components at well-defined interfaces, & analyzing these. So, both formal and informal methods can be used to see any influence a given component has over another component & to see information flows in the system. Illegal information flows can be detected & the design changed to minimize or remove them.
Now, connect something to a network & everything changes, eh? Well, this was the problem they had in an early A1 project, the BLACKER VPN. They noticed that a group of participating devices was essentially a system as well, just at higher granularity. So, they did the local level modeling to prove system level components, but also modeled interactions between systems (esp on any shared state). There are many variations on this to handle proving properties on networked systems, including decentralized. How they talk to each other is important, though. This leads us to protocols.
Personally, I hate protocols. They seem like they should be so easy to get right. Yet, years of brains thrown at certain conceptually simple protocols has yielded mistake after mistake after mistake. A number could have been avoided: poor implementation, models way to abstract to capture important details, etc. Yet, what do we do? Well, it depends on whether we’re talking comms protocols or security-critical protocols. For the former, just use Google’s Protocol Buffers or similar setup that automagically handles it. Try to get the logic right, handle problems gracefully, etc. For the other type, read on & bear with me.
I think we should just not trust protocols. In the past, I said we should have several ways of doing something that can be randomly chosen (or each explicitly avoided if weakness is found). Others contended that we do security protocols in app-level virtual machines or interpreters where they can include their definition with them, with us able to swap them out at will. Others promote formal proofs of design correctness, autogeneration of protocol handlers from specs, etc. My friends, I still don’t have an answer as I’m not a protocol wizard (and they screwed up enough). So, here’s what I’ve been doing in designs. 😉
I assume the protocol will be flawed. I include a protocol number field & tell the handler to have a plug-in approach to protocols, able to hand off the computation to whatever module is necessary. Then, have several protocols to rely on that each used whatever assurance techniques they wanted from above paragraph. The protocols should be fail-safe & SIMPLE (see XML-based tech for opposite). They should have minimal opportunities for info leakage, DOS, etc.
Examples include using JSON or certain ASN.1 instead of XML; UDT instead of TCP for reliable transmission; preloaded public key recognition instead of CA’s for authentication; encrypted messages encapsulated by proven crypto tech instead of whatever “new improved” crap they’re using. It’s really all just risk reduction principles, minimizing complexity, & shoehorning new functionality into existing protocols IF SENSIBLE (i.e. crypto example or UDT using UDP).
Almost an afterthought: firmware, peripherals, etc. I’ve found that many attacks on this kind of stuff requires privilged access. The methods above largely prevent that. This makes it a non-issue in many cases. This may be why it was ignored in the old days. Today, we have to consider it for clients, esp thanks to the likes of firewire & USB. I recommend a good IOMMU on all processors & trusted boot process that allows safe update of firmware, trusted OS components, & other software. USB HID needs to be revisited, as it can defeat many DLP software. (I just disable anything I can’t trust.) Processor errata can be reduced by verification technology (VAMP, AAMP7G) or using processors that are less complex than x86 (PPC, MIPS). VIA Padlock style onboard TRNG, crypto acceleration, etc. is a plus.
Browsers? Avoid them where possible. They were created to deal with the fact that cross-platform & networked applications weren’t happening very well. Today, we have numerous mature toolsets for doing that well. If the app itself can’t be made portable, then the way it interacts can & you can use whichever tool you want. The Apache Portable Runtime is nice on server side, while there are numerous cross-platform GUI toolkits. Interactive shell minimalism is also possible. However it is approached, privilges, complexity and TCB should be kept to a minimum.
Another side of it is handling security-critical functionality. Let’s say we have a trustworthy platform with many features I’ve described above. You can trust its key generation, crypto, storage, auditing, access control, etc. Wherever possible, the large risky applications should offload security-critical functionality to the OS or more trustworthy applications. This has been promoted by microkernel advocates for a while & the embedded virtualization vendors are targeting their products for it.
Additionally, the apps should offload privilges when possible, so a privileged launch != a privileged compromise. Multiple processes that communicate with each other can be used to emulate this, as DJB did in qmail. Using multiple, inexpensive devices together to segregate information & functionality can help as well. I did this in my transaction appliance posted on Schneier & Krebs blogs.
As I closed, multithreading and scalability come to mind. There’s been many formal methods (e.g. CSP), special languages (e.g. X10, Cilk), and entire books around to deal with the incredible issues that come from that. I recommend app developers using platforms or design approaches that minimize those issues whereever possible. One for scalable, correct multi(whatever) apps that’s I’ve come to like recently is ZeroMQ. It seems like a magic bullet for that stuff & makes it superbly easy in tons of languages. There’s similar languages/frameworks aiming to solve security problems in general in web development, like SIF & Opa. Time will tell.
Anything I miss? Comments? Criticisms? Massive amounts of funding? 😉
Wael • June 29, 2012 2:42 AM
@ Nick P
Good that you identified your threat domain. I will need some time to digest your post. For some reason, your comments and Clive Robinson’s take some time to understand.
Nick P • June 29, 2012 11:22 AM
@ Wael
Awesome. It’s natural for Clives posts to be a tad difficult to follow. As for mine, it must be that a certain amount of assumed knowledge comes with my posts. Assume reader knows a lot, my post is condensed with stuff they dont get. Assume too little, i have to drop small books. So, it’s prolly a sign im gradually figuring out your lvl of background knowledge.
Wael • June 29, 2012 11:52 AM
@ Nick P
The time consumed (not difficulty) arises from starting a thread and ending up discussing a branch of a branch of a branch of the original topic and its uncles. Now I am trying to go up the stack again, and bypass the ancillary branches that were traversed on the way down.
Wael • July 1, 2012 9:17 PM
@ Nick P
“Massive amounts of funding?”
Not yet Nick P! This is a massive amount of information. I am not sure where to start. Where is the prison model in this?
Clive Robinson • July 2, 2012 2:44 AM
@ Wael,
Massive amounts of funding?
I wish 🙂 everyone you speak to these days say’s “Money what money, we barely keep our noses above water”…
With regards,
Where is the prison model in this?
Like the dungeons of old it lurks way beneath the glitz and glamour where the traditional courtly activities visitors are treated to take place 🙂
If you take a look at the traditional single CPU multi-tasking OS “onion” model you have three main layers.
1, Hardware.
2, Kernel.
3, User software.
With each layer subsiquently broken down a little further into other segmented layers in subsiquently more detailed models.
In the kernel layer you see it traditionaly split into user (U) space and kernel (K) space for shared memory and generaly a very simple interface based around software interupts between the two.
This simple interface is actually a rather usefull “pinch point” which is where conceptualy the prison door goes where the “Uside” (User / Untrusted prison) “Kside” (Kernel / corridor) are actually running on different CPUs etc.
Provided the CPU MMU’s are correctly controled by the Hypervisor stack then any task on the Uside is kept locked up with all access to the outside world and other parts of the system controled by the Hypervisor stack.
This is also a place frequently chosen by OS designers for mult CPU multi-tasking hardware to split tasks up to put on seperate CPU’s (with one CPU delegated with also running the Kernel etc to simplify design).
So from the User / task side it all looks just like a typical *nix setup. And importantly it uses the same basic IPC API’s (with certain restrictions). So anybody used to doing typical “shell prototyping” on *nix where the shell provides the “pipes” would not see any real difference.
On the Kside it’s very different and has the Hypervisor stack mediating all activities. The IPC restrictions are to allow the Hypervisor and scheduling system to work effectivly. Whilst shared memory is possible this is considered very undesirable except in the previously described buffer processes (as shared memory opens all sorts of potential side channel issues). So IPC is treated in the same way as other communications streams. Unlike other multitasking systems with either few or one CPU where, when a task “blocks” a CPU performs a complex context switches into another task, each Prison CPU only has a single occupant task and thus just halts (allowing the hypervisor to sniff registers and memory etc). This actually allows for quite a simplification of the Kside design which further aids the security objective of reducing complexity.
Does that answer “where is it question”?
Wael • July 2, 2012 1:07 PM
@ Clive Robinson
“Does that answer “where is it question”?”
It does — thank you!
Sounds like:
Nick P’s model: Old school
Clive Robinson’s Model: Hypermodern
Nick P • July 3, 2012 11:45 AM
@ Wael
I can’t repeat enough that Clive labeled my model “castle’s” & it would be easier if you drop the whole analogy, instead focusing on the design description. Mine is a bottom-up design focusing on extensive prevention, info control, breach containment, & legacy reuse. His uses very-fine-grained decomposition, a special type of POLA, signature monitoring, & little to no legacy capabilities.
I’d love to try his but I still can’t see it being implemented in hardware. (I’m not a hardware guy either, so it’s hard to wrap my mind around practicality of a totally radical hardware approach.)
To see radical stuff that’s being built, see DARPA Clean Slate contestants below.
Preliminary design of SAFE platform
http://www.crash-safe.org/sites/default/files/plos11-submission.pdf
TIARA architecture
http://dspace.mit.edu/bitstream/handle/1721.1/37589/MIT-CSAIL-TR-2007-028.pdf?sequence=1
SAFE will be easier to build. There was a prototype of its concreteware by the time they published that paper. TCG types might like TIARA better, though. It has so many neat attributes. I suspect both of these, based on a “castle”-like approach, will be more practical than Clive’s prison approach. Also, designers that take my approach will have an easier time retargeting their systems to these platforms. Might also be able to port some legacy stuff to SAFE with auto-translation technologies (a la Semantic Designs Inc.).
Wael • July 3, 2012 11:52 AM
Nick P
Sorry – my bad …
You said previously.
” His is the Prison, mine was the Castle.”
Somehow it was reversed in my head…
Dropping analogy as you suggested …
Wael • July 11, 2012 3:11 PM
@ Clive Robinson, Nick P
I know my timing is off, I should be talking about the subject du jour, but I have to get this action item off my back …
Looking back at our discussions on C-v-P:
I see validity in both approaches. Nick P’s approach makes sense. Close all holes or entrances that have been known to cause problems (DMA, Browsers, …) then make sure the system has an immutable state that can be initialized to, if needed — an immutable bootblack / boot loader. I also see Clive Robinson’s approach as a valid one, and makes sense too. Although maybe harder to implement. The one thing I have not been able to grasp in his approach is the threat he protects against. Both approaches also push the limits of S-v-U — Security versus Usability.
My interest however was in the model. Or a combination of both approaches, since I see them as complimentary, and not necessarily orthogonal, or mutually exclusive. I just want to say, both approaches have their own charm. As for Clive Robinson’s “Don’t worry most people I know off who write C code I would not consider to be programmers but “Code Cutters”. Come on Clive! That’s just pure Bull S**t 😉 Listen to what they say!
We had a programer with a slight stutter
Who’s code had an overflow in the buffer
He saw some code on the ‘net
And copied some of’et
But claimed he ain’t no code cu-cu-cu-cutter
Hopefully I got the structure, meter, and rhyme close this time 🙂
Nick P • July 11, 2012 5:36 PM
@ Wael
Timing is fine. Or about darned time. Whichever. 😉
Yeah, they certainly push usability to the limit. No doubt about that. I was thinking about trying to secure appliance-type offerings first. As for general purpose stuff, thin clients are straightforward enough to take my approach. Matter of fact, Aesec has a thin client prototype/design for their A1/EAL7-class GEMSOS security kernel. More recent companies have been doing that. Then there’s VPN’s, web servers, app servers, databases, etc. You can also accomplish plenty in security in user-land (e.g. tripwire) & with middleware (e.g. message broker) if you can trust the underlying platform. As for a full GP computer, eh I see serious usability issues too. However, many roles don’t need those capabilities. Heck, many companies run DOS-like apps for their critical stuff. I’m sure even an ancient B3/A1 system could run those pretty fast, ya think? 😉
Re Clive on code cutters
I think there’s merit in what he says. The comment has some unstated premises though. In his previous statements and our discussions, the idea that software development and engineering (hardware or in general) are very different. There are engineering-style ways of producing quality software, but most developers don’t use them. Theirs is an art and, from a quality perspective, it sucks. Hence, his negative term “code cutters” for people throwing stuff together or to a lesser extent using low quality methods to produce software.
Ignoring radical full Agile methods, there are numerous software production methods that have empirically-measured higher success at achieving requirements, keeping defects low, etc. If you want to look them up, the Fagan Software Inspection Process and the Cleanroom process are two old ones still in use. Newer ones include Praxis Correct by Construction, PSP/TSP, and any that can meet a high security- or safety-critical certification. The latter vary, but the quality is consistently good.
Groups using some of these methods can statistically certify their defect rate & have been known to warranty software. Name a well-known application vendor that will warranty their product against failures. If you can’t, you might be sensing the difference between results of software ENGINEERING and development/coding. 😉
Note: High quality code can be made without such methods. It’s just harder to do & requires more skilled labor & effort. Also, requires time to pass to watch bug count, as typical development has less predictable bug count.
Wael • July 11, 2012 5:42 PM
@ Nick P
“Re Clive on code cutters, I think there’s merit in what he says. ”
I know, and I agree with Clive. I’s just my sense of humor 🙂
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
anonymous coward • June 8, 2012 4:45 PM
http://www.cwi.nl/news/2012/cwi-cryptanalist-discovers-new-cryptographic-attack-variant-in-flame-spy-malware
Cryptanalist Marc Stevens from the Centrum Wiskunde & Informatica (CWI) in Amsterdam, known for ‘breaking’ the MD5 hash function for https security in 2008, analyzed the recent Flame virus this week. He discovered that for this spy malware an as yet unknown cryptographic attack variant of his own MD5 attack is used. Stevens analyzed this with new forensic software that he developed. Initially, the researcher assumed that Flame used his own attack, which was made public in June 2009, but this was not the case. “Flame uses a completely new variant of a ‘chosen prefix collision attack’ to impersonate a legitimate security update from Microsoft. The design of this new variant required world-class cryptanalysis,” says Marc Stevens. “It is very important to invest in cryptographic research, to continue to be ahead of these developments in practice.”