Schneier on Security

Clive Robinson • December 2, 2009 7:19 AM

Oh and whilst I remember,

Don’t think Microsoft knows what it is doing with encryption software.

Have a google for the X-Box and TEA cipher being used in the wrong way.

Any way the nurse has just put my lunch in front of me and for some reason the sight of it has set my recovery back a few days as I now feel quite ill again 8(

Clive Robinson • December 2, 2009 5:03 PM

@ Roger,

“The claim that overwritten data might be detectable through track misalignment has been often made and seems plausible, but so far as I know it has never been demonstrated publicly.”

It has but your beard would need to be a bit “badger” to remember it.

Back in times past “HD platters” came in packs about 16″ across, the operator used to press an “unload” button on a machine the size of a laudromat machine lift the lid, lift out the platter pack and drop in a new one close the lid etc etc. All for 20Mb of storage…

Like the floppy disks that followed ten years later the design of the system had a “servo mechanisum” that kept the head over the right place it was partly based on the drive mechanics and partly on the drive signal quality.

The result was that a platter pack from one drive would work in another drive but… the mechanical servo tracking could be half a track off and still work.

You used to be able to get hold of a funny looking device that looked just like those magnifers that you put ontop of a map with your eye to the lense. In the bottom was a thin glass cell (not unlike a calculatoe LCD display) that contained very small magneticaly sensitive particals that changed colour depending on the strength and direction of the magnetic field.

You could not only clearly see the tracks and half tracks but the actual data bits as well.

A very big chunk of the reason you cannot make sense of residual magnetic data easily these days is first of all the orientation of recording has changed and secondly it is heavily encoded with a large amount of inter symbol dependancy. That is an individual bit is effectivly encoded across five or more bit spaces on the actual platter giving multiple intensity levels not just a 1 or 0.

That being said if you put a hard drive plater into certain types of scanning electron microscopes then the magnetic domains and their intensity are very easy to see. The price of a second hand “Oxford Magnetics” SEM is quite low these days the question is would you be able to modify it (I suspect not).

Squeasing data onto drives has long past the MFM and RLL encoding of the late 1980’s. Vertical recording and complex trellise encoding are just some of the ways you increase the number of bits per square CM.

However a word of caution should be sounded. Many drives these days have their own on board CPU the program for which is stored in flash, it can be easily overwriten (if you know the magic codes). Thus it may be possible to upload a custom programe to get at the residual data etc.

Which brings me onto fault tolerance,

I’m glad you brought up #6 it needs to be said and often, some drives alow upto 30% dead space these days not just one or two cylinders hear or there, the cost of an extra head and platter are minimal by comparison to the advantages on high availability drives.

Again reflashing the F-ROM on drives makes all of this “hidden data” available to those that can do it.

It is not a question of can the data be got at but who has the keys to the kingdom via the flash rom etc etc.

Clive Robinson • December 3, 2009 12:52 AM

@ Nick P,

Howdy I hope life is well.

A couple of points to add that I bloged about oh way back that other implementers should think about.

Firstly if you are going for top end security don’t just staticaly store keys in memory, all physical devices including dynamic memory suffer from “burn in” so make the keys dynamic.

A simple (but not totaly secure) method is to have the key stored in two or more parts that are brought together to make the key.

Just for ease of explaining take the key and halve it’s value and store it in two locations A,B. To get the value back you add A and B. Every few milliseconds a non interuptable interupt process gets a random value adds to A and subs from B. Thus the two memory locations change atomicaly and very very often to prevent memory burn in.

Oh and the system needs to be realy fragile in some circumstances so an operators “dead man’s handle” is a must.

Keys can be quite safely stored in bits in multiple juresdictions. So for an international company the master keys can be held under a voting (n of m) system with pre-arranged duress codes.

Thus it can be demonstrated that you don’t and cannot possibly know the key and that you cannot get at it.

Oh and the key holding box has it’s own public key system where it only holds the private key and the key shares are sent to it with time dependant codes to prevent replay attacks etc etc.

As I said not 100% but it adds a couple of 9’s to the end.

Clive Robinson • December 4, 2009 9:08 AM

Nick P,

Sorry for not reponding earlier had to caution somebody about a Troll…

With regards,

“I think the solution to these erasable issues is red-black separation applied to memory and raw storage. What I mean is that everything in RAM or on the disk should be ciphertext. Onboard controllers/ASIC’s sitting in front of each medium should transparently encrypt/decrypt.”

It is the way to go other than the “crypto” needs to be inside the CPU chip.

You see this on some microcontrolers where the internal flash rom is encoded/ciphered to stop somebody flipping the lid off and Scanning Electron Microscoping (SEM) or IR Microscoping out the program code.

However it has security issues (doesn’t always).

The CPU is activly talking to memory, even if the memory is encrypted you can still get a very good idea as to what is going on simply by observing the memory addresses in use on a vector scope.

It becomes clear what areas of memory are code and those that are data, further the general types of data by the number of consecutive bytes read or the number of times a given location is read. And if the data is “constant” or variable, and if it is “global” or local and all sorts of other things.

When you know where the code is you can have a good idea what is OS and which is program also you can work out what OS calls are being used…

Thus without further measures other than just data encryption the program and some of it’s data can be enumerated 8(

Even if you also encrypt the ram address bus you will still get an idea of what is happening simply by observing what memory is used read only and that which is used as read and write. And in the case of “stack” or “heap” memory it becomes clear as well with time and usage.

Further you can cross corelate events with IO actions so you can see the code load etc.

One of the things with “in line” encryption it is usually transparent at some point and this has a side effect of opening up exploitable information channels to an observer.

For instance consider point to point encryption -v- end to end encryption.

Point to point encryption in a network effectivly hides routing information, but without further measures simple traffic flow will analysis will give you the likley start and end point of a communication in a network.

Even if you do take steps to use in communication random routing you will see just by how much data enters or leaves a node where traffic is likley to be heading.

The solution adopted by the military for years has been “constant trafffic flow” that is every node point sends and receives traffic at either the channel capacity or a fixed fraction there of.

To an outsider they have no indication as to which bytes in the comms stream are “data” or “fill” thus easy traffic flow analysis is prevented.

Now you have the issue I keep pointing out but still gets ignored 😉

Efficiency is on the other side of the slide to Security.

That is the more efficient an object is the more side channels it has.

So you “clock the outputs and the inputs” at a fixed rate irespective of what is going on. This makes a timing side channel difficult to implement and of very very small bandwidth.

So much for communications, how about storage?

Well… it has it’s own issues at various levels. Like observing the address lines on the CPU watching the head movment and write amps etc will tell you a lot over time.

Further there is the issue of time…

In comms data is in transit and time has little meaning overall (this is an over generalisation). For storage however it has significant issues.

One of which is in line encryption has no notion of time other than it passing. Data needs to be encrypted under different keys, in comms time is not an issue the data gets a new key each time etc. But on a hard drive the data is stored for an unknown period of time. Unless an inline encoder works at a higher level it has now way to implement time sensitive encryption which effectivly means all of the data has to be encrypted under the same key…

This makes it sensitive to other attacks that do not effect comms only storage.

Thus you need not just point to point (inline) encryption but end to end (time/file) encryption as well.

Lets say each step adds a 9 or two to the end of the 99.9… but It’s not 100%.

Clive Robinson • December 5, 2009 6:21 PM

@ Nick P,

Hmm this might take some time but first thoughts,

You say,

“The purpose of my setup is to defeat forensic attacks after erasure.”

Which is not what the system actualy does.

You have realised that “time” and “persistance” are two major issues and you are aiming specificaly at these by,

“The RAM and disk are only encrypted so that destroying the key leaves only ciphertext.”

That is the data is not destroyed it is mearly locked up in an “encryption safe”.

Thus the security of this is dependent on the ability to find the key to the safe.

As you say,

“If someone has physical access to system, they can use methods you describe. The goal of my system is that, once the zeroize function is activated, the forensic guys can search disks and burnt-in RAM all they want and find only useless ciphertext.”

Now you are arguing “security” after an event, on the assumption the key is unknown or cannot be recovered.

The key might actually be known due to EmSec and or “cache timing attacks” or other side channel attacks.

From what you say,

“In effect, my scheme makes it where only the key for RAM or HD is sensitive, it’s only in one place, and is easily (read: very reliably) destroyed.”
An attacker that is aware (for whatever reason) that your scheme is in use must target the key.

Which you apear to be aware of,

“The design is based on Kerchoff’s principle. The assurance of this scheme should be as strong as the crypto algorithm and implementation.”

So the weaknesses at this point are,

1, Data is not destroyed only encrypted.
2, The encryption key is stored within the system
3, An attacker is assumed to know that they will have to,

3.a, get the key by observation.
3.b get the key by applying preasure on the operators.
3c, recover the key from the hardware.
3d, using crypto analytic technigues to recover the key.
3e, prevent the key being zeroized.

Any problems with what I have said so far?

You appear to be aware of some of these issues when you say,

“Secondary goal, with less assurance, is for tamper-resistance to activate zeroize process if operator isn’t there to do it.”

Which may end up being the “low hanging fruit” of the final system.

So on to the details in the core of the system.

“… using a dedicated controller/card for crypto, with small RTOS to ensure predictable memory and wiping characteristics.”

Now the thought that occures is why an RTOS and what are it’s strengths / weaknesses / conectivity / etc.

“So, what I’m asking your review on is my high assurance goal: will seemless encryption of data, as in RAM cryptocontrollers or IME’s for HD’s, prevent recovery of all RAM and HD data if the key is zeroized”

The simple answer is no because the data is still there it is just encrypted.

The security under your assumptions rests on the inability of key recovery alone.

Extending the “zeroize” into all the RAM should be the next option. And also disguise where it has got to by writting random data not zeros.

Then there is the issue of the IO and other areas of mutable memory that is not the HD.

That is under a fault condition it is possible that at some point some or all the key or other critical plain text gets written to a place it can be recovered from.

Then there is the issue of the hard disk.

Inline encryption of the data needs to be thought about carefully.

At it’s simplest it is “code book” encryption that on a large hard drive is going to leave it subject to various well known attacks such as “chosen plaintext” or “known plaintext” attacks.

For instance a large part of MS Word files is “known plaintext” and under a simple “codebook” system the identical headers will tell you how many word documents are on the hard drive. Likewise with .exe files and many others. Also a large chunk of the OS is nearly always in the same place on a hard drive.

Thus your encryption system needs to take one master key and convert it to many sub keys and IV’s and chain encrypt each fixed block (ie a sector or sectors that go to make a logical block).

Further it needs to do “Russian Coupling” or equivalent on major features of the HD structure.

This has some quite serious implications because no longer is it simply acting as an “inline” encryptor it is going to have to cache blocks of data as well.

“With this model and countermeasure, my security claim is that if crypto works, they have to recover most or all of the key that was overwritten randomly several times in static RAM.”

That is true but as I said it has to be the right use of crypto. Dorthy Denning wrote a book in the 80’s on securing DBs and some of the pitfalls I would definatly have a read of it.

“Do you agree that it deserves high confidence or am I missing something?”

We always miss something 8(

Because we are all I hope human 😉

My main concern it the HD, the lower level it is encrypted at the more vulnerable it is to attacks (which is why I don’t assume inline encryption is enough). Thus it needs to encrypt multiple times at each level of the OS stack the more layers it works at the more likley it is to be secure.

HD encryption is a realy hard problem and few people get it right without considerable thought and experiance.

Idealy it needs to be built into the OS filesystem “proper” not bolted on which most solutions are.
Hope that helps a little?

Clive Robinson • December 6, 2009 4:55 AM

@ Nick P,

Ah I’ve learned a bit more about your way of thinking 8)

As I now know what you mean by zeroize I’ll stick with it.

Another point you say,

“operators don’t know the key, half was generated onboard by TRNG and erased by zeroize”

I’m not sure what you mean by this from the system design spec aspect.

Is this to allow for some degree of accidental system tripping or for some other unstated system aspect?

That is,

Do you mean that the operators have a master key that then encodes randomly selected sub keys?

Or do you mean internal keys are split into two parts one half known to the operator the other half truley unknown?

Or some other arangment?

Key Managment is another area like HD encryption is fraught with subtal gottchas.

Which ever case what is the design reasoning behind it?

One thing you may not be aware of is TRNG’s -v- CS PRNG’s.

There are issues with TRNG’s that people try to hide behind hashing under a mistaken beliefe the “one wayness” of the hash will sprinkle “magic pixie dust” on the output (this idea appears to have gained traction since Intel engineers put it into their chip based TRNG’s in the late 90’s).

It has been known for over a quater of a century that electronics (thus TRNG’s) can be influenced by external forces/energy at quite low levels.

But even though I have been saying it for that period of time the academic community have only just “openly published” on it.

Put simply some of the bods at the Cambridge Labs subjected a 32bit TRNG to EM radiation and found they could reduce the effective entropy down from 32bits to 8bits…. that is a 1 in 4billion down to a 1 in 256 series of outputs (I hear an Ouch being said 8)

Thus no matter how you hash each output individualy you effectivly end up with only around 250 individual outputs…

And this by the way was with a very very simple attack.

It is basicaly an EM “fault injection” attack and there are ways of making it much worse than a simple attack (trust me on this one I’ve been there and done it on plastic cased hand held devices where monetry value is involved back in the 1980’s).

And yes I have said things privately to researchers when Fault injection became known in the academic community and more publicaly since DPA poped up in the mid 90’s.

So just about any active attack on things such as smart cards are applicable to your TRNG.

The nice thing about “passive TEMPEST” defence is it works in both directions so if you use enough of it hopefully the operators will be aware of such an EM attack is inprogress when the paint starts to blister off of the wall unless their eyes explode first 😉

Clive Robinson • December 6, 2009 1:32 PM

@ Nick P,

One of the things about security systems is that the design process is very similar to safety system design which in turn has a lot in comman with old style project managment.

Basicaly it boils down to managing complexity and oddly the best way to do that is to add more complexity but in a highly controled fasion.

A quick explaination / example as to why,

An early automated OTP system suffered badly from timing side channels. That is you could tell which bits where changed and those that where not simply by observing the width of the output pulse. Thus it could only be used in “off line” mode.

It became quickly clear that trying to “control” the pulse width issue was neigh on impossible with highly reliable (GB) Post Office 600 relay technology.

The practical solution was to “double clock” the output. That is the output from the XOR function with the dodgy pulse width got put into a storage relay. The output of the storage relay was then clocked onto the line using the orthagonal clock.

That is by increasing the hardware complexity in a controled way an uncontroled aspect of the design was negated.

Hence the TEMPEST maxim about “clock the inputs and clock the outputs”. Thus timing side channels virtualy disapear from consideration. This is provided other error conditions are correctly dealt with which gives another maxim “on error start from the begining” thus the bandwidth available is oh so low (which indirectly gives rise to “on error abort”).

A similar system is used in hardware design (pipelining) but for different reasons (trade delay for clock speed).

So the best way to control complexity is to break the system down into the smallest distinct subsections you can whilst still retaining atomic behavior, and control the interfaces between them.

From what you have said I suspect you already do this the question is though do you do it to a fine enough level and within certain other constraints.

To decied this you analyse the states each subsection can be in.

The first rule is NO RECURSION ever.

The second is NO SHARED STATE ever.

Thirdly that ALL ACTIONS ARE ATOMIC (or fail safe).
Forthly, that an individual subsection can only be in one distinct state at any one time.

Fithly that (apart from under fault) the switch to the next state should be decided by, one input only and it should not be derived from more than one state back.

Sixth, feedback or feed forward should be avoided at all times.

So for each subsection, 1 state machine, with 1 stored state, back 1 state in time only and only 1 input and one output.

Which is in essence a Turing machine or simple finite state automaton.

Importantly it must have fault detection and each and every state must fail safe.

Where ever possible feed back must be avoided as this typicaly magnifies complexity and thus state uncertainty. Feedforward has other issues and likewise should be avoided.

Likewise the interfaces between subsections must be clear and fail safe under fault from either subsection.

Thus the design is in effect one or more “chains” where the state of all links (subsections) is known at all times and all faults stop the system in a fail safe mode.

It is possible to build the simple chain system into a “chain swap” system. That is a chain can have a selector switch in it that allows groups of links to be independently used of each other.

It sounds like a tough thing to do but surprisingly the result is usually better than all other methods.

The tough bit is either getting rid of feedback or sufficiently isolating it to keep the complexity managable.

But remember,

1, No recursion
2, All actions are atomic or to fail safe fault.
3, No shared state.
4, Interfaces are clocked.

Clive Robinson • December 7, 2009 6:54 AM

@ just say no to lizard handlers,

“Then where do you place your trust?”

Most users don’t put it anywhere, they don’t even have cause to think about it….

Although you are correct that MS is a major corp and supplies closed source OS and Apps and it’s patches are both closed and often excesive in size.

Does that make it inherantly untrustworthy?

Does it matter?

The simple question is in an unregulated highly competative market why would anybody trust any corp?

As for the supposed alternative “Open Source” in it’s various forms has many disadvantages as well.

For instance any moderatly complicated app is very dependent on the tool chain used to turn the source into executable code. Sadly some coders cut their cloth to the tool chain not the standards. Likewise to the OS. Thus taking the source and getting it to run on an OS can be fraught with complications.

Most users are not sufficiently technicaly minded to do a compile from source which is why Open Source is most often downloaded as a pre compiled binary.

Why should a user trust the package any more or less than one from a major corp?

When Open Source gets what the attackers regard as a significant level of usage I will expect them to concentrate on it as much as they do for high usage closed source code, and not much before that.

MS have improved their game, as can be seen by attackers going after applications from other organisations (Adobe etc). But from this it can be seen that they are still targeting the “big market” code which most users can be expected to have.

Info Sec is a funny (not so) old game, trust is not in the game play.

To the attackers it’s a numbers game. To code developers it’s always a game of catch up. To most users they care not what the OS is just the app they need to get a job done thus play the game. To geeks and gamers their hobby needs drive their desires and passions so it is a game of love. To observers and industry pundits the basic rules of the game should be obvious. So why do they behave like geeks in their outlook?

Beats me, I can see pros and cons in both camps.

But at the end of the day the majority of people want to get a job done with the minimum of pain and perhaps some pleasure. The attackers know this so that directs their activities not some other more esoteric reason.

Thus trust has little to do with the game.

Clive Robinson • December 7, 2009 11:51 PM

@ Nick P,

First off my comment about key space was in refrence to the brute force benchmark, not your system.

It highlights the point that comparing unlike methods is dificult at best and that an underlying asumption can get you a lot of trouble (I’m also aware that you are possibly not the only person to be reading this 😉

With regards “clock the inputs and outputs”, it’s one of the few ways to stop / choke side channels down.

On the vague assumption everything else is ok with any given system, side channels and data structure are your next two main enemies.

This is because modern encryption such as AES is from the “current publicaly known art” is impractical to break (add usual disclaimer 😉

Therefor they are the only practical ways to get a grip on observed encrypted information that has been sent down a shannon channel these days.

And if you think about it the HD is effectivly the gift of a recording of that traffic to the forensic people (but thankfully without time detail).

Also “clock the inputs and outputs” is a design maxim for keeping complexity down essentialy the breaking into small functional blocks with “strictly controled interfaces” prevents time based side channels between the blocks (a win win which is rare in design, which further sugests it’s a fundemental requirment 8)

If you do not keep time based channels under control then the system can not only leak information it’s self it can become transparant to leaks through it.

If you have a hunt around on the web Matt Blaze had a student that demonstrated this via modulating key press times which made it all the way through to the network and could be picked up by passive monitoring of network traffic…

Time based side channels occure as a side effect of either inherent or induced problems in the design.

This is irespective of if the system is under attack, be it pasively or actively.

Thus you have to assume that each block be it software or hardware is effectivly trying to get a time channel through subsiquent blocks in the chain (oh and it’s another reason to avoid feed back/forward).

Both inherent or induced channels are going to be there with abundance with COTS hardware and OS’s simply because they both lack segregation. And they are designed for “efficiency” (maximum performance for your buck).

One of my maxims is “efficiency -v- security” as a general rule of thumb the more efficient a system is the more likley it is to have time based side channels that can leak information (have a hunt on the web for key leak by cache hits).

So security has to be built in from the start and arguably is not possable on the likes of commodity PC’s which is why you should always use “crypto software” OFF LINE or via a suitable “air gap” etc. My prefrence is two seperate boxes as this limits potential “store and forward” attacks.

So if data is clocked between blocks the ability to use a time based channel is reduced below the clock rate.

That then only allows an attacker to have a channel based on the clock period by either having data to clock or not having data to clock. If your interface control picks this up and treats it as an error then you further choke down the bandwidth of a potential time based side channel.

Having got one domain (time) for side channels under control you then have other domains to worry about but that is an area that is not yet publicly under investigation as far as I’m aware.

However also stopping down the time based asspect has a curbing effect on the other domains (frequency, sequency, etc).

Clive Robinson • December 12, 2009 11:24 AM

@ Nick P,

“I guess I shall have no Ph.D., but I will have the satisfaction of making useful stuff.”

Yup and you’ll be in good company. I’m not realy sure what a Ph.D. Offers people these days (outside of Academia).

I guess it falls down to the old ‘Viva le Diff’ between engineers and scientists 😉

‘Scientists are people that look for problems by which to improve mankinds knowledge. Engineers are people that look for solutions by which to improve mankinds lot’.

Me I’m on the side of the engineers it’s more fun getting things done than it is to ‘publish or perish’.

“Personally, I’d like to see more medium to high assurance open-source projects”

Yup then people would start to see what properly writen code should look like. And hopefully stop chasing the wrong metrics…

A case in point – I once told a bunch of software engineers that I had to manage that there was a fixed pot of money for their Xmas bonus and it would be distributed based on three things only, to be eligable they had to meet their agreed time projections, then they would get points for each bug they posted they found in somebody elses code and lose double the points if a found bug was down to them and the pot would be split pro rata on points earned…

The bod that walked away with just under 60% of the pot (the team size was fifteen developers and two team leaders) was an old hardware engineer who used ‘Z’ and had previously only received a very small bonus because their previous manager counted lines/day written (and slurping up ego boosting).

For some strange reason my office door saw less traffic, and the high productivity code cutters (who got little bonus) left by March and where not missed by the team. Their deliverable times actualy dropped by around 15% with on target up by over 300% when I moved on the following August (I’m told their bonus pot went up by only 10% which was a shame they deserved better).

“esp. BSD license. Then, corporations would use it in their own code and we’d all benefit.”

I’m marginaly in favour of some of the other Open Source licences because I’m old fashioned and like “the body of knowledge” to improve under peer review as every bodies boat floats that little bit higher (it used to be normal in tangable engineering to do this).

However due to intangable “zero copy cost” I can understand why more traditional businesses would prefer the BSD licence. And there are some occasions it has other advantages (I’ve used it myself for “licence manager” systems).

As for your system, it sounds like you have a good idea of what you want to acheive (always good 😉 and importantly how to get there by an “engineering” aproach.

There may be other gotchers in there, then again there may not.

When they let me out of this hospital I’ll sit down with a large pot of tea and draw it out and have a proper look at it 8)

Clive Robinson • December 26, 2009 4:58 PM

@ gongcho,

“To be someone so knowledgable in some certain fields, your spelling abilities are absolutely appalling :o”

Unfortunatly I’m somewhat dsylexic which I’ve been told (over 40 years ago) is a side effect of something strange in the way my nervous system is not cross wired in the usual way. What the modern diagnosis would be I have no idea.

What I do know is that it got one heck of a sight worse when I was attacked on the way to work one morning back in 2000 and had my head karata kicked into a post supporting a road sign by a college student.

This resulted in amongst other injuries a full fracture of the lower jaw right on the point of the chin. I was told by the maxiofacial surgeon that it is the hardest bone in the body to be broken in that way and was extreamly rare on people who are still alive.

To add to the fun it developed significant complications and a serious infection resulting in repeated surgury, which on one occasion I woke up half way through (which is realy good for waking in a cold sweat every few days).

There has also been other damage resulting in all sorts of interesting physiological medical problems including difficulties with sleeping, migrain like head aches, memory loss and other symptoms similar to mini strokes, proneness to debilitating sinus and inner ear infections, loss of taste, teeth and properly working saliva systems, and most unfortunate of all occasional loss of conciousness on excertion for no redaly apparent medical reason.

All of which is a bit anoying at the best of times.

Unfortunatly due to this I spend a lot of time under the less than tender administrations of the UK’s National Health System. One way or another they have managed to give me a couple of DVT’s and PE’s with the result I now have to eat rat poison every day.

The other side effect is having to access the Internet through a little mobile phone when the nurses etc are not looking (otherwise in some NHS hospitals they take it off you as a “valuble” or “prohibited item” and lock it up untill you are discharged 8(

You can not use a laptop or note book because you are not allowed to plug it in to charge (officialy because it’s not been safety tested by a hospital electrician…)

However ypu can pay the equivlent of 5USD/day to use a bed side system where you pay the equivalent of 1USD/minute to make or receive phone calls. And the last time I tried some exhorbitant rate to access the Internet with full “kiddy lock” on which prevents access to this and most other blogs etc (and most Google searches).

Unfortunatly the mobile I have does not have a built in spell checker. I’m waiting for a reasonably good Android phone with a browser with built in spell checker to replace this out of contract phone.

When I do the spelling issue will go away and will probably be replaced by some other problem (such as effect/affect of/off etc 😉