Schneier on Security

Clive Robinson • July 6, 2012 5:36 PM

OFF Topic:

Bruce,

I don_ know if you have seen this site,

http://safeman.org.uk/

But it contains a history of safes and safe breaking in the UK. It also has an attached site,

http://peterman.org.uk/

Which has a potted history of UK “petermen” who were safe crackers who ended up using explosives of various types.

Clive Robinson • July 7, 2012 3:35 AM

ON Topic,

Having seen Bruce’s,

This was suprisingly interesting

I thought I’ll give it a read in the morning. So there I am munching my breakfast with one hand and scrolling down the article on the mobile with the other.

No worries I thought I’ve “dissected” a few squid “for the cooking pot” in my time so I’m not going to read about anything I’ve not actually seen and in some cases enjoyably eaten (lightly battered and deep fried is nice, or slowly stewed and then baked in a loaf of bread etc 🙂

Then I got to the bit about licking the pus of the back of a cockroach… and for some reason my breakfast, that upto that point I’d been enjoying, suddenly became distinctly unappetizing…

Clive Robinson • July 7, 2012 2:55 PM

@ Wael,

I did not think equipment would freeze at the depth squids live at!

In this respect “freeze” has a couple of meanings, the first being the litteral temprature “freeze” as in water going solid. The second simply meaning “to stop” moving/working from the mechanical terminology which if I remember correctly derived from that of biological meaning as in “frozen to the spot/rigid”, which in turn was derived from the. firsst meaning where a side effecto of water freezing is it stops moving in the usual way…

You also need to remember that ~32ft of water is the equivalent of one atmosphere of preasure, so it mounts up quite quickly as you descend into the depths. And with respect to this the second thing to remember is explosives have been and still are used to generate preasure waves to “cold weld” metals together and if you get the preasure right soot turns to diamonds (with a little extra thermal help).

Thus one problem with all underwater equipment used at reasonable depth is how to operate it from/at what is effectivly a low preasure point.

Whilst a hollow ball of steel with sufficient thicknesss will not crush in most depths the minute you make a hole in it for a camera to look out of you start getting problems unless your optical material has simmilar properties to the steel or you take other precautions. Likewise drilling holes to take electrical or mechanical signals in and out to operate the equipment. Then there is the issue of maintanence hatches etc…

Then ontop of that there are thermal issues of working at depth, for instance batteries realy do not like the cold their capacity can quickly drop below 20% of that at room temprature when below some technology dependant figure (ni-cads and lithium battery packs used in high quality “TV Cameras” for instance are down to about 30% at tempratures of arctic autumn aand spring as wildlife documentors have found out.

Then the electronics it’s self can be very tempreture sensitive, for instance “voltage refrence” sources used for A-D converters can easily be susceptible to tempratures even a few degrees outside of their operating design (0-40C for the majority of consumer grade equipment). Remember that a few years ago hackers found that various “secure electronics” features could be bypassed by putting the electronics in a domestic freezer (aprox -18C) overnight. Something the original designers had not considered.

Outside of consumer grade equipment are the “industrial” and “military” temprature grades but equipment in these temprature brackets are either custom built or inordinately expensive (have a look at the price of ordinary civil UHF 2 way radios and then those that are Mil temprature spec it will make your eyes water).

Having designed equipment for Mil, Oil/ Chemical industry and Fast Moving Consumer Electronics (FMCE) I can assure you the price differential is in many cases justified.

As an example, in FMCE it is not unusual to see the base bias on a transistor being “current bias” as this saves the PCB space/costs of a resistor and improves battery life. However for “outdoor use” in winter the circuit will not work because current bias is way to temprature sensitive, so you have to have the extra resistor and much higher current of “voltage bias”. Likewise the choice of capacitors in oscillator circuits. If you look at the basic “inverter circuit” oscillator for quartz crystals at 32Khz, you will actually find that the capacitors and resistors are usually selected to make the inverter an RC oscillator close to or at 32KHz. The reason for this is so they actually start up and thus excite the crystal sufficiently close to it’s desired resonant frequency such that it “pulls-in” and then the significant change in the quartz crystal impedence in the circuit causes the quartz resonantor to become the frequency selective component not the RC time constant. If the capacitors are to temprature sensitive then the RC oscillator frequency may not get close enough to the quarts crystal frequency for the impedence change to happen… Similar issues apply to other oscilator circuits and tuned amplifier circuits. Likewise some “spring coil” inductors. A good circuit design is such that any change in charecteristics with temprature are known and the appropriate temprature coefficient cappacitors are used in a way such that the resonant frequency remains as constant as possible over the desired temprature range. Even things like “bees wax” used to reduce “microphonics” in inductors has physical temprature coefficients that can change the electrical charecteristics of a circuit…

Clive Robinson • July 7, 2012 4:59 PM

@ Moderator,

Blundering about like a bull in a china shop apparently

Err no, and I’m sorry if that’s the impression I gave.

I’ve sometimes been asked why I don’t have my own blog and my answer has fairly consistantly been,

1, There is a lot of work involved with getting original content together.
2, Keeping ontop of the related admin functions including those related to security is also a major issue (that gets worse the more visability/popularity a site has).

So no I don’t envy the task nor would I condem anyone who works hard to provide such resourcess to others.

Also I’ve been caught out a number of times with functionality changes on software upgrades etc so I’m aware that “smooth running” carries a significant overhead in testing of things that don’t make into the manual, release note or upgrade/patch info. Some I’ve even brought onto myself by making a Maintanence Upgrade of software I had written myself some years previously (one particularly embarising one was ‘=’ instead of ‘==’ in a section of code that did low level memory managment as part of garbage collection).

Further I had the misfortune to once work for a company that had an online product that had so many conflicting configuration options that changed almost weekly that even the “programmers” could not tell you from day to day what might be effected. It was so bad that the “customers” were not alowed to change things, it was a job for the Tech Support Staff who received no training or support from the programmers. The programmers also had an attitude that “testing was for wimps”, needless to say it was not a happy place and the company appears to have reorganised it’s self virtualy out of existance…

Clive Robinson • July 8, 2012 9:54 AM

@ Ronnie,

TrustChip (by KoolSpan)…

What worries me is the lack of information to decode what,

Apps can then route calls and messages via the chip and its 32-bit encryption processor.

Means in reality.

There is also the point that this device is not using the smartphone in the way intended and as such I can think of a number of attack vectors.

For instance how does the app ensure a secure channel exists between the microphone and the SD card and from the SD card to the earpiece/speaker. From what I can tell of the current leading phone OS’s this is not going to be easy unless you have “root privileges” which you can only get by “jail breaking” the phone…

Also how does the app stop the phone supplier from downloading an I/O Device driver “shim” that effectivly puts a “T-Piece in the pipe work” thus copying the sensitive data on to some other hidden app or other hidden comms channel that is either “real time” or “store and forward” such as the CarrierIQ software did with keypress and other data…

So untill a lot of other detailed technical information on the design is released by Koolspan on which a sensible evaluation can be performed I for one will treat the product as “unknown” at best which in turn means I won’t be using it any time soon (if ever)…

Clive Robinson • July 8, 2012 8:48 PM

@ Wael,

I am a HW engineer by education… …been stuck with software and firmware since then…

Yup me to but I moved on from “software engineering” because the bosses wanted the software equvivalent of “junk food tastless pap” and I wanted to make “healthy enjoyable food”. And when it came to the choice of “taking the money and run” or the “ethical approach”… well lets just say I walked… into a different career (which I’m probably going to do again soon).

[Imagine if you can a conversation between me and an MD of a fairly large organisation, he was bemoning the deficiencies of Micro$haft products and how it was costing the company $X, I (somewhat peved as he had button holed me at a social function that was not work related) simply said “What do you expect, they are simply doing to you as their customer, what you are doing to your customers” lets just say it was not career enhancing].

Any way the issue with preasure is mainly two fold, the first is the effects of static preasure and the second significant changes in preasure. For instance a JEDEC TO-33 style package with glass base seals on the likes of many 1-5W transistors, will fail at quite moderate static preasure when compared to that which mil subs fairly routinely have on their preasure hulls. But if you look at the likes of the cables they change in preassure causes them to expand and compress and has similar life shortening effects to bending (as well as changing their charecteristic impeadence sufficiently to cause return loss issues). And obviously the changes in cable diameter due to preasure directly effect the use and design of sealing glands into equipment housings.

Thus external sensors on submersible are effectivly special/custom designs and in some cases it’s a custom package that is machined to take a standard part, ie some low cost ROV motors are internaly actually the same as some bilge pumps just in different housings, and many cameras are low light security style cameras in specialised casings whilst feedback systems on actuators are often custom designs including such extras as water ingress detectors.

The reliability of ROV style submersibles has a strong corelation not just to depth of operation but also the number of decents / ascents and is why some systems you can only rent and come with a compleat set of spares,tools and technicians along with the operators. When I was working in the Oil / Chemical industry I did some design on top side, head end equipment and dabled in the electronics side öooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooothe guys doing the design for the ROV etc were a fatalistic morose lot who worked on the asumption it was all going to go horribly horribly wrong the minute you went to sea. For them success was measured in sleep time (or the lack there of) when off shore. I suspect that things have improved a bit in the past twenty years or so due to improvments in materials science etc but a look at job adds for ROV / submersible technicians tells a few stories if you can read between the lines.

Clive Robinson • July 14, 2012 9:24 PM

@ Wael, David, Nick P,

I’m still alive and have returned today from lodging with the medical profession once again. You know you are “not well” when you are not only on first name terms with Drs, Nurses and Porters at your local hospital but also their children and in some cases grand children from having said hello to their parents in the street (the nice thing is they don’t ask “how are you feeling”).

@ Nick P,

or make some smart dude look uneductated

Ouch… I look on it more as “broadening their outlook with a different view point”. For one thing I’m certain there are a lot brighter people than me around, I just appears that “I’ve got around” a bit more than they have, so like “any old dog” I’ve learnt a few tricks in my time 😉

I know you are occasionaly amused / dismayed by Journalists and their antics when it comes to security. But whilst we tend to think of it academicaly or in a detached sort of way sometimes their lack of ITSec genuinely costs lives,

http://www.cjr.org/feature/the_spy_who_came_in_from_the_c.php?page=all

And to be honest, I don’t think I’m up to totaly locking down a consumer grade laptop computer / mobile phone beyond the capabilities of a type three opponent if it can even be done (which I doubt). I even doubt many type three agencies are capable of it either unless they have a significant “in” with the manufacturers involved.

I’m also well enough aware that such a device if found on you (and it very probably will be) is going to attract rather more attention than you would want. Likewise specialised harware that is potentially secure is going to raise an even bigger stink than ripe Brie in the full heat/glare of the midday Mediterranean summer sun.

Back in the old days of “fieldcraft training” they used to advise you “to keep yourself clean and unfragrant” so that your “back story / cover” would not be compromised or the “officers” of the opposition “smell you out”. Thus you kept hard technology to a minimum, and instead relied on what was “in your head” and where required additional field support personnel via appropriate cut outs and dead letter boxes etc.

Modern journalists don’t have the luxuries of resources time or support today, and the modern TV Hard News requirments make it a lot worse than it used to be.

In this particular case of the filming a few simple precautions would have gone a long way, such as head scarfs etc to hide identity before recording video, using an “anonymous room” to film in and not voice recording interviwees voices onto digital media but old fasioned analog tape, then burning the tape after transcribing word for word so it could be “voiced in” by an actor at the production stage. Whilst the first bits are fairly easily done the issues of recording/transcribing the voices of the journalist and the interviewed person need time resources and skill that are not “field available” these days in 24Hour News.

One advantage for these forign level three agencies is that the countries for whom they work have “jumped over POTS” and gone straight to fully digital mobile phone technology which makes intercepting and recording data almost trivial and alows statistical analysis of call paterns etc sufficiently easy that use of digital phone technology should be considered “suicidal” at almost any level no matter what precautions you take (a point that was not lost on OBL, and even he paid the price of insufficient communications security in the end).

It’s a hard problem and is getting harder by the day as new tracking technology becomes rapidly available (at a very profitable price) to level three agencies the world over and it is not helped by the likes of Chinese and Israeli telecoms hardware provider companies building in the tracking facilities from the silicon upwards.

Clive Robinson • July 15, 2012 7:22 PM

@ Nick P,

The main risk is the modified app will be on the filesystem. A very easy countermeasure is comparing its hash to a known legit copy

Hence the reason you have to write the original version so the hash is valid.

It is however based on the assumption that even level three adversaries don’t have the capabilities to check each and every app/game in existance. And even if they do check the most popular 0.1% by then having it on your phone does not make you a spy just a slightly suspect “game player”.

Thus it’s the same as having an “in” with the hardware manufacturer only cheeper and possibly much easier to hide (after all how do you background check what appears too be a paranoid games writer secretly working on the next “big thing” in their back bedroom?).

Mind you if I was to try to do such a thing I would try to place myself or my code writter in with the app writers at the OS organisation and get it in the standard release as nicely “signed code” [1] and thus above “gold standard”…

With respect to,

So, perhaps defender-supporting organizations should try to map out their capabilities & change the advice to fit the likely risks

This is a catch 22 problem 😉

To get the money to do the enumeration, you need to have paying custommers, and they are most likely to be the very people you are enumerating…

It’s similar to the “Security workaround / patch problem” as an attacker being the first to get your hands on a patch alows you to work it backwords to find the vulnerability so you can exploit it for either a short window for those who patch often or much longer for those who don’t patch for a long time or at all (the majority).

@ Wael,

And spread spectrum is almost the perfect implementation of steganography. Will look like noise to Mr. Fourier if he is not aware of the channels and randomness ala CDMA type spreading

Yes and no Spread Spectrum for “Low Probability of Detection” (LPD-SS) be it Direct Sequence (DS) or Frequency Hopping (FH) works on “code gain” that is the spread bandwidth is X times the data bandwidth and thus you have a coding gain of ~X. If the SS transmitter is sufficiently far from the intercept ECM / Surveillance receiver then it will appear to be below the thermal / atmospheric noise floor. However this is rarely the case even with the likes of the US GPS Military signal or other satelllite signals. If your intercept station has sufficient gain in it’s antenna and knows where to point it then the SS signal is nolonger below the thermal / atmospheric noise floor. On a spectrum analyser it’s basic charecteristics (type, chip rate, coded bandwidth) are usually fairly obvious to the practiced eye. Worse for DS-SS the spreading code usually has to be linear and it has been shown that you only need to know 2M bits of the code to work out the entire linear sequence. As such DS-SS is going out of fashion for LPD these days, it’s more frequent use being CDMA and shared bandwidth/service especially in the likes of the ISM bands and analog TV bands.

Even when the spread signal is below the noise floor there is another issue with LPD-SS systems, which is “receiver sync / lock up”. That is the receiver has to have some way of syncing the deconvolution code with the convolution code at the transmitter or it will not receive anything. For various reasons (drift, doppler) accurate clocks don’t work very well nor do third party transmitted refrences.

There are a couple of practical methods used to obtain initial lock, one is to use a higher energy beacon signal with a short M-Sequence code [2] and or low chip rate, another is to use a burst signal that acts as a lead in pilot. The choice is generaly dependent on if transmission is continuous or short duration such as in two way PTT systems used for voice comms. Either way the beacon acts like a “flashlight in the dark” and can be fairly easily found with modern high bandwidth IQ receivers and backend DSP as used in high end military ECM / Surveillance receivers. Further it’s not just FFT’s or FWT’s that are used in such receivers these days there are more complex mathmatical systems used to find the charecteristics of the signals and dig them out from the noise or other interferance. The point being is once a part of the transmitted signal has been recognised it can be used as a sync signal and even the use of simple averaging on the IQ memory will bring up more charecteristics and bit by bit the original signal reconstructed and analysed. For instance take FH-SS the charecteristics of each transmited envelop charecteristics for each frequency hop are almost identical and this can be used to tell them apart from other signals in the area. This can be improved by using two or more directional antennas and with modern electronicaly steared / synthersized antennas this can be done almost in real time.

Early PTT SS systems actually used SAW matched filters to provide a sync pulse that had an ERP of many times the coding gain, and in some cases 10db up on the equivalent non spread ERP channel. The more modern version is to use high speed A-D converters and DSP matched filters at the receiver as this can be programed like a SelCall system.

The overal point being that although the chip sequence may not be deducable and thus the data not recoverable by the surveillance receiver the beacon signal indicates both that a transmission is happening and from what direction, and in some cases even the range.

In the intel game you don’t need to know what has been said to hang a person just that they have talked to another suspect. Which is why anti-traffic analysis technology is perhaps more important than data security technology such as encryption these days (TOR developers please take note).

[1] and people wonder why I have no faith in signed code or code reviews etc etc 😉

[2] There are a large number of M-Sequence codes that can be used, the earliest were “Gold Codes” and “JPL Ranging Codes” even simple PN-Sequences, with the more esoteric Walsh-Hammerad, Kasami and even Barker codes being used for other functions within SS systems. To be a good contender for SS use a sequence does not have to actually be an M-Sequence it actually needs few charecteristics other than strong auto-corelation, and for DS-SS it generaly has to be linear to be balanced to avoid offsets in the receiver. Thus you could use the output of a modern crypto function such as a stream generator or block cipher in CTR mode for FH-SS as long as you have some method to sync the receiver with the transmitter ( http://www.netlab.tkk.fi/opetus/s38220/reports_97/kettunen.pdf ).

Clive Robinson • July 15, 2012 10:33 PM

@ Wael,

With regards the level of adversaries it’s changed with time a little since The IBM / Ross J Anderson definition as evidenced by the likes of Stuxnet DuQu and Flame. But losely,

Level 1, is an individual or small team that are constrained by very limited resources and have no knowledge of the systems other than that which is available to any other external entity.

Level 2, is an individual, team or organisation that is limited in resources but have access to an increased level of knowledge over that which is available to any other external entity.

Level3, is an organisation or agency that is not limited by resources and has access to any information that is available to the system developers and access to related information that is effectively the result of classified research.

It is important to note that the above definitions are (unlike the IBM / RJA definitions,) based on a three dimensional graph.

The dimensions being,

A, The number of skilled human resources.
B, The avaialability of resources that are not human and not target system related information.
C, The level of target system related information available.

In reality the three levels should be further sub-clasified. That is I don’t expect the Government intel agencies of some countries to be on par with that of other countries, and in fact I actually expect some private research organisations to be better than many Government intel agencies, likewise some criminal enterprises.

What has become clear in this modern world is effectivly unlimited bureaucratic budjets don’t buy “smarts” capable of doing cutting edge research. Likewise they don’t buy the sorts of information criminals generaly have little trouble obtaining via simple theft or breaking, entering and taking away etc.

That is “free enterprise” gets results that reliable incomes and pensions don’t. Which is why we hear about “exploit brokers” and the likes getting government work / contracts / money.

However until some industry luminary comes up with a more up to date set of generaly accepted catagories I’m stuck with other peoples aproximations hence I still try and squeeze the multidimensional model into three levels 🙁

Clive Robinson • July 22, 2012 4:16 AM

@ Wael,

Please don’t post large, rude or otherwise poetry lymerics or songs etc. Because as Nick P will confirm our host has told one or two of us off before for such behaviour (myself included). Which as it’s his blog, I’m mindful to follow the rules.

Anyway back to the security question of C-v-P or whatever those discussing wish to call it.

Firstly please do not make the mistake of thinking very few people read the comments… Many “non-comenters” read this blog and as we know one or two peoples past comments have been cited in published papers etc. Further if you read academic papers you will find that many opinions expressed in them have come into line over the years with the thinking of people first expressed on this blog.

One of the reasons I post here is that not only many others can and do read here but, if people don’t agree they can say so without fear of consequences that other more academic processes would stifle. Likewise they can also ask questions and give other viewpoints and in return for this freedom I say feel free to use the ideas etc I post, and if you do, cite me as a politness, Oh and if you ever meet me or Bruce buy us a drink (even if it’s only a cup of tea) to say thanks.

Oh and with regards “blocking the blog” I generaly wait for the “on topic” thread traffic to die down or stop if the comment is effectivly becoming “off topic” and that way cause minimal disruption.

As for EMail one reason I don’t use it in a more general way is that I have in the past (the old hotmail account amongst others), and I tend to end up having revolving EMail addresses due not to spam but people who for various reasons wish to activly hunt me out (I like my peace and quiet to think, oh and have family time etc…).

But now back to the subject proper. There is a reason why I treat C-v-P more as an ideas/talking point rather than a hard model, it’s simply that it may well never make it as a long term model due to changes in the underlying technologies. To see why this might be ask yourself,

What will happen when we hit the buffers on the effective “doubling up” of system power every software revision cycle [1]?”….

$$$

Clive Robinson • July 22, 2012 7:09 AM

@ Wael,

As far as I’m aware the at symbol has no real significance other than it makes a reasonable visual sign post if you are skiming through a large post etc, and I think it originated befor (Ctrl-F etc) text searching became commonly used in browsers.

It also helps if people use it where they don’t “cut-n-past” a persons name or it is done imperfectly by the browser for some reason (accented charecters and non ISO Latin charecters can cause this but shoulden’t these days, the browser I use has that anoying habit of translating some charecters to their percentage number equivalent when cutting-n-pasting part URLs).

Clive Robinson • June 23, 2014 7:32 AM

@ Figureitout,

First off, you are not going to produce a secure computer first time out the gate. That’s not to say it won’t be a lot more secure than other things around, it probably will, but even the best of engineers usually have a make measure and refine cycle that goes around a few times befor certifing engineers don’t find problems that are of concerne.

As an example, you have an output line, you need to de-couple and bandwidth limit and then re constitute as a digital signal. There are various ways to do this the simplest way is an opto coupler followed by a lowpass or bandpass filter, followed by a circuit to sharpen up the edges and adjust the levels again. So far so good, only the filter gives rise to time delays which with analog components change with all sorts of circuit conditions including the power supply state, earth currents and a few others as well that can cause information to leak through the digital signal restoration circuit. So you not only need to change the circuit away from being a simple level detection with hysterisis but a window comparator with more complex than usual state change, you need to reclock with a biphase signal and shift register to remove information from the edge of the transitioning signal…

In amongst this you will need independant power supplies with their own filters, and electrical shielding to prevent cross coupling by capacitive or inductive means as well as ensuring signals don’t get leaked by ground current faults etc etc…

It’s a fun game with a learning curve steeper than a fast logic rise time, however people do achive the objective given a few turns of the cycle.

Clive Robinson • June 24, 2014 2:24 AM

@ Wael,

First though I will have to convince everybody else that my shade of puce is the same as his shade of deep and meaningful rose red 😉

It shouldn’t be that hard it just takes a little time….

As I’ve said here once –or twice– befor, if N people view an event there will be N+1 realities, where the +1 is what realy happened but nobody could see due to their limited view point. Which is why you can slowly talk the N people around to a new reality that did not actually happen but in their minds matches their memories of the event, that you have slowly changed 😉

Clive Robinson • November 29, 2015 10:38 PM

@ Wael,

Some things you left of the list, that are easy to add,

2+ Least Resources.
8+ Fail Long.
12+Least Complexity for security.

However there are also more general things to consider, lots of them…

For starters the fundemental viewpoint on which the models are built upon… From some of your unrelated comments I’m guessing you have done some electronic system design and thus modeling of unknown “black box” and “two port” systems.

The important idea is that you find all the system ports be they nominally input or output but IMPORTANTLY consider them not just bi-directional but ALSO assuming all ports are “coupled” in some way and thus having an effect on all other ports unless specificaly issolated in some way (such as a circulator and dump load etc in RF design). Further that all parts of the model are also “generators” / “radiators” of information normaly treated as “noise” “loss” etc, but which have security implications.

All of these have their analogs in digital systems hardware and software, something that rarely if ever gets taught to “CompSci” students or even mentioned in passing in “testing” or “security” course module classes.

It might be that the realisation that most basic computer instructions are atleast “five port” and each port is also two Shannon channels is thought to be either “beyond the average student” or “to advanced / specialized for the course” (which is odd considering most physics and electronics graduates understand it implicitly or with minor prodding).

But we also need to consider time in a broader sense of not just “What is deemed secure today is not tomorrow” but also why. In part it’s because “Technology Advances” as well as “Knowledge Advances”. Whilst “knowledge” advances in unpredictably odd ways “technology” tends to be more predictable due to a number of reasons not least being “realisation time” and the fundemental laws of physics etc.

Thus do we set our models and reasoning in what is concreate today or what is foreseeable. It’s an asspect of CvP that gets overlooked. Right from day one I stated the opinion that the future was parallel and that was implicit in my reasoning. Current systems are slowly becoming multi-core but the designers try their best to make the system “look and feel” single core for programmers who have trouble thinking in terms of more than one thread of execution at a time. Thus Castles are “current” to limited future single core context switching paradigm whilst Prison systems started as “future” massively multiple core non context switching designed to be fully scalable in a parallel architecture.

Whilst it is possible to emulate a prison system in a castle system you don’t get “sweet spot” advantages.

For examole somebody mentioned a potential “Russian OS” to replace MS-OSs the other day. One of that OS’s stated functions is in effect to implement a version of the prison idea using what the designer called “objects” –and I call tasklets– where the sole security idea mentioned was to not use pointers outside of the objects –I use MMUs and “letter box” buffers to stop memory access issues–.

An interim technology advance @Nick P mentions is “tagging”. It’s actually been around for longer than the IAx86 architecture and it’s a technology that almost always gets sidelined. The reason is not hard to find and it’s in effect political not technical. Put simply, it offers no “normal” performance advantage for an increased cost in technology, that few will ever use. Thus it never gets past the marketing department, who figure it has no buyer premium thus is a bottom line cost without benifit.

But also marketing and managment know it’s going to be a “productivity nightmare” in the application development industry. Thus it will be “turned off” by default, and the reason that the OS and applications if they build in the ability to enable it will “see a performance hit”… So a “tough sell” at best even in these more “security conscious” times.

In general I’ve nothing against tagging, it can be built into the “cell” on chip local memory without issue and the MMU can be easily augmented to deal with core system memory. Thus on chip it’s a “real-estate issue” which due to other considerations such as “heat-death” the extra space it takes up would probably be not used anyway (it’s why we are seeing on chip memory growing very quickly).

The problems with tagging start when you “go off chip” with extra pins and memory columns or segregation to support it. The problem with tagging is three fold granularity and basic container types, effecting the actual implementation choice and thus the side effects.

Currently we have tagging information in “page tables” for read write and execute function limitation and the real system core memory remains untagged. Which leaves open a security hole in that it’s possible to change a page table contents due to over complexity in the IAx86 design giving unexpected “Turing completeness” in the interaction between state machines. The first logical step to close this sort of hole means tagging the actuall memory not it’s self on either a region or word basis. This means you need to add additional tagging bits to the memory either in the address decode logic or attached to each memory word by adding tag columns thus widening the memory. But using region tagging has issues but mainly lacks fine granularity, needed for complex data types.

Both methods might be fine for a very limited range of data containers –types with access metadata– but can rapidly get out of hand and cause problems. Worse they both have another potential security hole, based on tag interpretation. Whilst access metadata –read write execute etc– is generaly a below CPU level issue, data types are a CPU and above CPU issue and impinge well into the software layers. Thus in effect you have to have “data types” “baked in” or subject to software interpretation on a case by case basis. That is when not baked in, tag 0xB9 might mean one data type to one application and another data type to a different application. This effectivly opens another security hole via page table tricks.

But on the assumption you do “bake in” you then get into “complex data type” issues that reach up through the tool chain right up to the medium-high level program level. That is if you have a complex data type how do you tag the constituent parts and check their consistancy overall?

A simple example is a very long integer, if it’s unsigned all the component word types can be unsigned int no mater how long the compound type is in words. The same is not true for signed ints where you need to differentiate the Most Significant Word from the other words. This has a knock on effect in how the likes of shifting takes place etc… Similar issues with floats and complex numbers apply.

Basically any compound word type beyond an unsigned int has side effects and due to the likes of endien-ness, word size and boundry alignment reaches up the tool chain often violating the “Principle of least surprise” to programmers and also has all sorts of side channel issues”.

The only way around this is to split your programmers into two types those who work at sufficiently high level that they are above the issue, and those who are sufficiently knowledgable to work in the issue area layers. It’s just one of the reasons the Prison model advocates “scripting” applications from pre-writen tasklets -v- “secure programing” of the tasklets and below in high-level or below languages.

The advantages of scripting tasklets together is it is very much faster to produce an application –it’s a well understood RAD process– but the application is not in general efficient, –which from a security persprctive is good– which overall means “faster to market” beter “code reuse” which managment want to hear, but not good on “specmanship” scales, which marketing might not want to hear. However “specmanship” is becoming less and less relevant these days where users can and do find response times too short under certain circumstances these days and more than adequate under most other circumstances.

There is quite a bit more to add especialy with the idea of tasklets being designed to work under the security hypervisor that arbitrates what resources the “cell” has and what the tasklet can see or do in the way of communicating to other tasklets including the OS.

As you note it’s easily enough for a book.

Least Resources
The prison is designed to give any task/object the most minimal environment to do it’s job in. This means that malware does not have “room to hide”.

Fail Long
The thing about “side channels” is you can not prevent them, they exist whenever you communicate information in any form in any way. The way to deal with them is to stop down their bandwidth such that their ability to transmit data is as small as you can make it. The reciprocal of bandwidth is time, thus on detecting an error “fail long” this makes the bandwidth drop to as close to zero as you can get at the time. In addition you want this long time to be unpredictable so it needs to be actualy “fail long + random time” where the random is say 1-2 times long.

Least Complexity for Security
This is a conciquence of the number of relations between parts of a system and it sounds simple but is actually quite complex. Beyond trivial operations (base Arithmetic and Logic) you need a minimal number of combined operations to accomplish any given task. The question is how many and how you arange them to give minimal complexity for security. Operations tend to cluster in function or communication. Thus you can see minimal tasks that communicate and what you want to stop down is what goes on in the way of communication. Not just in “wanted connections” and “unwanted connections” but also in “both directions”. That is you are looking for segregation/seperation functional units with minimal communication that is monitored IN BOTH DIRECTIONS, that is not just wanted information flow but errots and exceptions as well.

Error/Exception channels
One thing most programers do is think about how things go right not how they go wrong. That is they do minimal error and exception handling at best. The result is easy side channels for atackers to “reach back into the system” due to “transparancy”.

Efficiency-v-Security
This is something many people either “do not get” or “ignore” for a variety of reasons. As a rule of thumb the more efficient a system is the more useful the side channels are to an attacker. That is the system becomes “transparent” in both directions. Often in secure systems “transparency” is only considered in the “left to right” or forwards direction thus “reachback” or “reverse transparency” attacks happen as a sub class of “injection” or “susceptibility” attacks.

Clive Robinson • December 1, 2015 2:27 AM

@ Figureitout,

… and I think SW/firmware people are forced to cover up some of the inadequacies of HW designs…but no the HW designs are nearly “perfect” in your mind apparently.

Err no I know the exact opposite, ALL and I do mean all hardware designs are imperfect. Further that in many cases a large part of the hardware design is “shaking the bugs out”.

you look back you will see I’ve mentioned “meta-stability” and how it can not be “designed out” you have to mitigate it instead.

Part of C-v-P not mentioned here is the mitigation techniques. In the past I mentioned that you could not build castles in the traditional way on shifting sand, but you could use other techniques to build a raft onto which you could build fortifications which is how you end up with “Man-o-War” sailing vessels and modern battle ships.

I also mentioned the acient Greek story of how to deal with two guarded doors, where one guard who always lies and one who always tells the truth and how it gave rise to “voting protocols” and how they could be used to mitigate failing hardware.

So say you are a SoC designer and you use third party macro libraries. And you suspect one may be deliberatly back doored. You use severel CPU core macros from independent libraries say MIPS ARM SPARK etc and put them on the same chip. You add voting logic and simultaniously present the same question to three different architecture cores. If one is lying, you not only know when it starts lying but which one it is.

The only problem is if the attacker has got to the three independent libraries or the chip foundry some how replaces the macros you use with backdoored macros or modifies the voting logic. There are however ways to deal with this based on the “Trusting Trust” issue with compilers.

Clive Robinson • December 1, 2015 5:30 AM

@ Figureitout,

And I don’t trust this method, I don’t think it actually defeats the attack; where did the clean compiler come from?

Well in my case I have my own tool chains I’ve developed in the past.

You could have a read of appendix A.6 of “Compilers : Principles, Techniques and Tools” by Alfred V.Aho, Ravi Sethi and Jeffrey D.Ullman the copy I have handy has ISBN 0-201-10088-6 which is out of print and around 100USD second hand, however there are newer paperback versions for students.

Basically the advice is write your own stack based calculator that is BNF and add a “context free grammar” to it and build the rules up bit by bit adding the symantic, sytax and lexical layers in turn.

From experience I know that you want to make your own lowlevel abstract machine interpteter to start with. Using the bare minimum of common maths and logic functions branching and jumping (test and skip over jump is logicaly simpler than branches but like BNF it can be hard on the mind). As you are only using it as a first step to porting and improving the simpler it is the better. Thus this interpreter can fairly easily be written in most assemblers you are ever going to come across so acts like a striped down P-code or J-code machine.

Of all the interpreters to port a basic Forth is light on the computer which is one of the resons I suggested it to you in the past.

You can write a very simple tool chain with it, with the advantage you can “walk the assembler code” it also gets around a whole bunch of relocation and linker loder issues as well.

Thus you have a “toe hold” to build up “good code” including pascal or C compilers. Ok they will be “Small C” vintage but you can build better with them. If you can bare digging through the Byte Site you will find the articles they did on what became Small C and if you are lucky you might get a second hand copy of the Small C book. There are also various C compilers for 8bit micros you can get the source and development documents.

There is even a home brew CPU where the hardware developer has done all of this including porting an OS.

Once you get the hang of doing this sort of port&build you can get a new CPU up and running in about a week plus however long it takes you to learn sufficient of the base assembler to be able to hand check the ROM code etc to do the first few steps to get the interpreter up and running using cross platform tools.

The last time I did this was for a MicroChip PIC chip, the reason, although the chip was solid the then suggested tools were both expensive and buggy, and the third party tool developer was I thought “tardy in their responses” and “not very reliable in fixing problems”. Something I think you have experienced in the past with development kits… (Oh and MicroChip for subsequent chips did their own C compiler by porting GCC which makes me feel they felt their customers pain with the third party developer).

Now I know the “optomisation / resource efficiency” question is going to be in the back of some peoples minds. Personaly my response is forget about it, get the code working, if you find you are running short of memory or it’s to sluggish, the go by a bigger/faster chip, unless you are going to go into FMCE scale production.

Clive Robinson • December 3, 2015 8:14 AM

@ Figureitout,

Yeah but it wasn’t entirely “from scratch” b/c it’s way too much work and essentially impossible for an individual.

Im not quite sure what you mean “from scratch” the first homebrew 6502 system I built I had to program with switches and buttons, having first written out the code long hand and then converted to hex then binary. I would have used a Z80 but the early ones had a minimum clock speed so you could not switch-n-button program them.

A Little later I used a Z80 system to develop code using a subset of it’s instructions that allowed easy conversion to compatable 6502 instructions as it was faster but a big chunk was still done by hand.

When I got my hands on the Apple ][ I used their assembler to develope code, but I still had to hand cut it at hex level including calculating checksums to make ROM images to run on other 6502 systems which ment every byte went under my eyeball…

That is how things happened in the 70s/80s so I was not some kind of abnormal nut or super human, it’s just the way it was due to the likes of “proffesional kit” easily costing three times an engineers annual take home. Oddly for these days you can still find books from the likes of Newness that have “PIC PCB’s” in the back along with a MicroChip CDROM so you can build your own programer so there are still some very poor enthusiasts out there still.

Thus I had to build my own tool chains, and yes they were very rough to start out with (but when every problem was a nail…). But the tools got smother with use and time. Importantly though I realised it was important to always use a limited “common core” subset of all assembler instructions in the tools to make cross-CPU porting much easier.

And I don’t like Forth, not fun for me whatsoever to program in.

No it’s not but you have to get from human norms like ‘infix’ with all it’s problems to something easy for the CPU, which is context-free BNF postfix on stacks, if you want flexability. Humans are lazy and ambiguous with all sorts of hidden assumptions, and infix fits in well with that. It’s why the first compilers had between 15-25 man years on the lexical analysis, before people started to wake up it is easer for humans to think like conputers than it is to make computers aproximate how humans think (a task that arguably after tens of thousands of man years work still has not happened).

The thing with C is although it’s a arguably a high level platform independent assembler, it’s realy nothing more than a quite poor code converter (try writing a large number maths library in it to see why). Further aside from recmpiling the compiler, changing the way it produces low level (asm) output is not easily possible. An interpreter that can self interpret like Forth is easier to tweak or make changes on the fly. It’s also fairly easy to embed space and code execution efficiently in other programs. So there is quite a lot going for it as a core tool, rather more so than the likes of tcl, Perl, Python etc.

As you note C is not what C once was, it’s turned into an unwieldy monster that bites the unwary handler savagely. It’s also very inefficient for low level work and getting more so with people trying to make it “easy to use” for people who realy should use other much higher level languages that are type safe, lack pointers and have worthwhile automatic memory allocation and Garbage Collection.

The other issue is the standard libraries, that “are all things to all people” and don’t realy work well. The input/output stdio is stuck in a past that was a known bad way to go before the idea of the library was even thought of.

Personaly I prefer to give C a miss working either “at the metal” in a good macro assembler or in a more task appropriate higher level language where code cutters don’t have to “work above their pay grade” with pointers, hand built data types and memory managment, should they be called on to upgrade/maintain the code. Oh and turn the dam optimization off if you are working on the lower end MCU’s, with a little practice you will be able to write more efficient asm. However before that when debugging optimized C can leave you with a mental state close to that tortures want to induce before asking you questions. As for the likes of high end CPU’s, spend the money and get the chip manufactures own compiler, whilst GCC has it’s advantages, it can not be all things to all CPUs, especially when the chip manufacture wants to keep some things undisclosed.

Which brings us to,

But I am worried about the fuse burning under my a$$ as computers keep getting worse from marketing-led features and essentially corrupted CPU’s

Yup Intel are one of the worst for CPU corruption, some can not startup correctly unless you load a bunch of microcode corrections at boot time, not as they say “confidence building”. Much of the problems are down to trying to squeeze the code to try and get around the on-chip / off-chip memory bottle neck. It’s one of the reasons I say the old CISC large core memory model has hit a brick wall, there’s only so far you can go with compressing instructions by making them not just more complex but vastly more numerous. The human mind can not keep up, thus you have to use the chip manufactures compiler to stand a chance.

And if you are going to do that go for the highest level language you can, and give C/C++ et al the old heave ho over the side to oblivion.

Which is another aspect of “the future is parallel” reasoning. Humans are “serial thinkers” when it comes to task decomposition. The problem is that they are also badly scope limited as well. It’s why you see in house programing guides that say “program blocks no bigger than 100 lines” and similar such as “do not nest more than four levels”.

What humans need to do is “sweat the small stuff” and “overall function” and let the tools sweat the big stuff inbetween that way the human can think big within the limitations of their scope and think serial within managable small tasks (threads/objects) and let the tools take care of optomising for memory and parallel CPU issues and all the messy signals etc. Yes there are people who can not just think that way but also securely, but they are rarer than “hens teeth” and how do I put it tactfully, kind of unaware of most things others consider important (like ironing clothes, colour coordinating clothes, selecting the right clothes for gatherings, remembering to eat from one day to the next, oh and the one you mention getting sleep overnight). I’ve been known to suffer from one or two of these issues as well (if you believe “she who must be obeyed” 😉 But I have not gone down the Einstein route of seven identical sets of clothes and have stoped eating pot noodles out of my tea mug and forgeting I have before making a cupper in it… Giving some interesting flavor combinations, which can take a while to notice when you are busy thinking 😉

Clive Robinson • December 6, 2015 7:34 AM

@ Figureitout,

By scratch I mean discrete components at least, completely. Not programming a chip (though that’s what I’m going to be doing for awhile, b/c it’s fast, flexible and most fun…).

If you mean at the ‘transistor’ level, then you will have to make it a ‘Serial CPU’ and the clock will be at best in the low MHz range. Thus you would be looking at best at a four to twelve bit equivalent RISC design, which you would then have to agument with a lot of memory to get a usefull instruction set decoder.

Using TTL chips is a nice idea but you just can not get the ALU and Register File chips these days. Whilst you can fake a four bit “bit slice” using a fast 8bit ROM chip for a much greater speed and a,lot less money, the hidden problem is the Register File. I don’t know what you know about “Dual Port RAM” but most memory chips you can get hold of are single port, and that means extra steps in the Register Transfer Language, which can mean having extra clock cycles for every register transfer. And as usually the case on simple micros the program counter gets updated by the ALU as a register, every instruction is going to be slowed down by as much as 50%. The solution most CPU’s these days have an independant “adder” for the PC as this adds a whole load of tricks including a “poor man’s MMU” or “segmented” memory access model, and fits in with “pipelining” the CPU design.

It’s why I started looking at “voting protocols” and still available single chip CPU’s. But you will find that even these old chips are starting to become scarce as they are droping lower than ten for the dollar at auction and the gold content of these old devices pays a lot better than that, if you crush-furnace-refine. So you end up back at single CPU microcontrolers that are around a dollar each new, and with carefull shopping PALs like the 22v10 and some other “registered” PALs for the voting “glue logic”. You can of course use a very fast (100MHz clock) micro controler to do the voting protocol, and use the “on chip” memory of the other microcontrolers as “local” memory to implement your “interpreter” and make it as “high level” as you can, which brings you around to the Prison concept…

The simple fact of life these days is “use what’s mainstream in the DigiKey Catalog”, even if you buy it else where. Because, things go wrong not just during development but in the future thus you will want your own collection of “spare parts” “On Your Shelf”.

So you also need to think about “moving up the stack” software wise. That is don’t think of writing “application code” in low level languages like C or many others, but use the “Rapid Development shell scripting” idea. That is instead of individual ASM instructions or C lines of code, think in Subroutiens, Threads, Objects or Tasks and how you would make them more general purpose “MiniApps” running on the voting CPUs, such that you only need to vote on results not intermediate steps. Likewise consider your System Core Memory as “IPC” only for passing results in the “shell script” pipe line.

Obviously you will have to write at the ASM or C level to come up with the general purpose MiniApps, but you have an advantage here in that you can leverage most of the *nix apps and libraries.

To get a good idea of what MiniApps would be most usefull get into basic “parallel computing” books to see what experiance has taught others.

Oh one thing, pass all IPC data between MiniApps / objects / tasks as human readable “Formated 7bit ASCII Strings”, although slower for many things, it will make the development model easier, the voting easier and any other additional “choke point” security easier, therefor faster to develop and more secure in implementation.

If you have a think about it, it’s a bit further down the line from your,

I’ve learned real quick compared to couple years ago, don’t try to hit it out the park from the get-go; slow it down, basic functionality, then slowly add.

Provided everybody “follows the rules” then when it comes to,

… just confronted w/ some massive “thing” and don’t know where to start tearing it down.

You can “check the choke points” and use simple “divide and conquer” debugging to issolate the fault. It took me a number of years to understand the unsaid things behind “The faults leaving here OK”. There are to many people who know enough to be truly dangerous due to their Dunning-Kruger limitations and that managment[1] “only see lines of code written” or “speed to sign off” not the hours spent maintaining and correcting the crap produced[2].

If you want one of the secrets to getting towards the “robust code” and reuse and all the other “good stuff” managment realy want but don’t know how to ask for it’s actually not that difficult to find (as @Nick P has shown the information is out there and findable). Like many things the secret is ruthless simplisity and common sense rules that have been time tested.

One was is based on the following which is almost self evident in the first steps,

Firstly well defined “fool proof human readable message passing” APIs acting as the “choke point” connections into a well found framework. The individual frameworks should have no more than “a depth of three” to keep things within “normal human abilities”. You should never have more than two people working on any given “plug-in” in a framework preferably in a “Captain-Crew” role, where the captain deals with the external interfacing and the crew does the internal plug-in work to meet the interfacing (think of the plug-in as a tasklet or object). Obviously a captain can have more than one crew member working under him but there should only be one person incharge of the individual framework. Importantly the captain and above need to be absolutly ruthless about the specification for the APIs, to keep the as well defined, robust and as simple as provides effective use, idealy using existing standards or a clearly defind subset of them.

Secondly you decompose problems into a nested series of frameworks and you ruthlessly stick to “chains and trees” and avoid both feedback and feedforward wherever posible. However you likewise make sure that errors and exceptions can be passed right back to the begining, no matter what happens down stream as it’s the only way to ensure data does not get lost or corrupt the system so it crashes and burns.

Many application programmers think they don’t need to follow the rules because they are somehow better in some way, or the application is a toy or just for personal fun. It’s a trait you tend to see a lot less of in the generaly better qualified engineers. The reason appart from better training where it counts is the “dangerous machines” reasoning. Most people know you don’t walk up to a machine you have no idea how it works and either “play with it” or “hope for the best” it’s why we say “Your playing with fire” when people do it. Further engineers know that once something is made, in general somebody with Dunning-Kruger will, despite all the warnings come along and play with it or repurpose it. Thus they tend to be taught and follow certain rules about the likes of “least suprise” and following “Established Design Rules” and “Standards”, not least because they are taught the consequences of “Consequential Product Liability” on their personal finances and futures. Application Programmers however have for years lived in a rarefied atmosphere where “Liability” of all forms can be “waved away with a licence”. To late some are waking upto the fact that legislators and judges don’t see that a piece of paper –if it even exists– can wave away basic torts and criminal activity or for that matter basic contractual rights with regards copyright.

Moving on 😉 I can appreciate that you don’t like Forth, but the fact remains it has many advantages when writing the interpreters that ultimately form how CPU’s work (look up RTL and microcode). Getting to grips with BNF and stacks is something you will have to do if you want to design your own CPU and Forth is one way into that thinking. But Forth has other advantages, for instance you don’t have the issues of code relocation that OS’s try to hide behind MMU physical to logical remaping. Something you will have to get to grips with if you want to have your system to be more than single tasking or having overly complicated linkers and loaders in your tool chain. Further Forth has an advantage over most other languages it’s threaded implementation makes it not just memory efficient but minimises information transfer and often execution speed, which gives you one heck of a lot more bang for your buck. You don’t need to go Forth to get these advantages, but you would be hard pushed to find them all together else where and developing your own solution with them all quite an uphill effort. You could for instance have a look at some P-Code or J-Code interpreters, but you probably won’t find the MMU less operation in a multitasking environment supported.

What ever you do the one thing you will find most usefull is that an interpreter for all it’s supposed failings does give you independance from the underlying instruction set of the CPU, which makes a whole load of problems disappear just like magic. In the past I’ve written a simplified interpreter in the BIOS giving me a uniform interface onto which I added a micro-OS, which ment I could port embedded systems with little effort when profit or client dictated a move from one microcontroller family to another.

Speaking of porting on microcontrollers, it usually requires turning off optomisations so you can actually see what is going on at the CPU level. Which is just one reason why I mentioned it, thus reading,

It’s highly recommended not to for ATtiny, or even AVR’s, and I don’t know why.

Makes me think there is something wrong at the CPU level the manufacturer is covering up for some reason. It might be perfectly valid, but to know that you have to get to the bottom of it and that could be very wasteful of your time. Thus consideration should be given to finding another platform.

Finally,

OT question/idea: Have you ever taken say a SoC or larger MCU and blown out a bunch of pins you don’t need?

I did experiment, but it’s got many disadvantages for the few advantages you get. A better path is wire cutters / Dremel the unwanted pin right back so it’s flush with the packaging, then use “quartz / ceramic loaded” epoxy and encapsulate it.

The problem with blowing out the pins is that you don’t know where it’s going to “fuse open circuit” or what it’s going to do to the life time of the chip. After all at the very least when a fuse melts O/C the metal has to go somewhere … There is also the consideration that a manufacturer is relying on the pin being there for some reason such as electrical stability or heatsinking, both of which have been true in the past for “RF parts”.

But you further need to consider, an attacker who can get through drill resistant loaded epoxy, can just as easily “de-cap” the chip and probe out the connection the other side of the open circuit.

Tamper resistance is a major subject in it’s own right and usually the best way to go is using a certified Hardware Security Module.

I know @Thoth has just posted on this and would probably give you some “current product” advice and other thoughts and reasoning he has on the subject.

[1]http://ralphbarbagallo.com/2013/05/01/how-to-know-if-you-are-suffering-from-dunning-kruger/

[2] However if you see it in either programmers or engineers without good reason, then defenestration is possibly the best way to go with them. The more socialy acceptable way is by “correct training”, but you need to consider a couple of things. Firstly the persons ego/self belief can be insurmountable, secondly the four levels of the “Hierarchy of Competence”, climbing that mountain requires skill, time and dedication from them otherwise they will fail to summit and the cost of their journey will have been entirely wasted. I’ve seen this happen in Universities where self funding students are given advice more based on keeping them paying the faculty rather than with any hope they will get good grades etc. Look at it this way five years to get a 2:2 which is at best the equivalent of a qualification that can be done in a year and costs 2/3rds or less than one year of the degree course, is quite a financial difference…

Clive Robinson • December 8, 2015 8:09 AM

@ Figureitout,

making a compiler using C seems like cheating lol.

Do you mean “using C” as “using C’s compiler” or “using the C source code”?

There is a lot of wrigle room on the line between the two, and that is quite important.

Just using the compiler without any other steps is the least secure end of that line and what the thoughts on trusting trust was all about.

At the other end of the line, is using the C source code, simplifining it to one expression per line and then using that as the comments, hand write the ASM hex codes along side. Then using cut and paste etc break out the hex code on it’s own and hand move it into 16 byte lines add the addresses and checksums by hand to make a ROM in Motorola format or COM image then if all is well you have a quite basic but trust worthy C compiler you can then use to recompile it’s self with the next level up. Rinse and wash a few times then low and behold you have a fully standards compliant C compiler.

You can go to various points along the tool chain for your start point. For instance you could use an existing compiler pre-processor and lexical analyser, to pop out an ASM list built with the original C source code along side. You could then do your hand coding from that point.

But the point about the reflections on trusting trust was it was a high level in the tool chain attack, that relied on the compiler recognising certain function calls etc. So you could write your own asembler in the C compiler tool chain and limited loader (no linking to dodgy code 😉

So I would argue that using the C source code as an example to build your own secure compiler sufficiently low down in the tool chain is quite an acceptable way to go.

As the old saying goes “Rome was not built in a day” with the rider that somebody had to hand make the first bricks to build the first brick works, that made the better bricks to build a better brick factory… This “pull yourself up by your bootstraps” method was what gave us Science, Engineering and the Idustrial Revoloution, long before Babbage and Ada Lovelace had their intellectual meeting of minds –that supposedly– laid out the plans for the computer revolution of the later half of the twentieth century.

As Newton remarked “He stood on the shoulders of giants” [1] which many others have done both before and afterwards and you can join them.

[1] supposadly this comment was an acknowledgment of those that had gone before, not a sarcastic comment at those who he felt had held him back by not making their experimental results available to him for years (which alas appears more likely).