Schneier on Security

Clive Robinson • July 31, 2012 2:45 AM

@ Paul Suhler,

Has anyone here looked at the Open NFC…? Any comments on the quality of their security

Err your question is ambiguous at best…

Open-NFC is based on various standards most of which have no security implicit in their design. As such it covers the equivalent of the bottom few layers of the ISO OSI stack model (ie physical up)

If you look at the Open-NFC web site it says,

In addition, because of the implicit security provided by the short range, the user interaction is very simple…

There is no such thing as “implicit security” when it comes to a radiating EM field system be it near field or far field. This fact has been demonstrated so many times you should treat any such statment as being at best “hand waving fudge” to at worst “snake oil”.

However this is not Open-NFC’s fault it is the fault of the standards on which their work is built.

The physical layer of NFC is to use the 13MHz ISM band to transfer both energy (for passive devices) and communications using an approximation to an “air-core transformer” in practice it is actually two compact loop antennas designed with very small “cross sectional area compared to wavelength” to work with the magnetic field component optimised for power transfer in the reactive near field when the antennas are in a common axis (broad side of coils facing and overlapping).

Due to the requirment to power passive devices (just like RFIDs and other tags using contactless technology) the active “master” device puts out a very strong field which can be picked up from several meters [1] dependant not just on it’s radiating efficiency but also any objects in or near it’ near field (includes conductors and dielectrics).

The mode of communication is Amplitude Shift Keying (ASK) with a modulation depth of either 10% or 100% (active to active). The modulating data wave form is either Manchester or Miller encoded respectivly. Neither modulation method is secure from spoofing especialy as the devices (in general) don’t make field strength readings so bit by bit attacks are easily possible.

There is a broad (but incorrect) assumption that due to the physical alignment of the coil antennas a “Man In The Middle” attack is not possible [2]. This gave rise to ISO protocols that are often used that unfortunatly are open to “replay attacks”.

Unfortunatly as you work your way up the stack the ISO standards do not realy mitigate the security issues and thus they need to be done at the application layer. Whether the app level protocol designers will do this or not is an altogether different subject [3], it is however not Open-NFC’s issue ass they are providing a standards compliant stack.

[1] : The reactive near field of a “point source” antenna (which a small/compact loop antenna or large coil inductor resonant circuit forms) is aproximatly two wavelengths deep and the E&H fields make an orthagonal transition with repect to each other to the radiating near field. In the reactive near field the H field is predominat at very close range to the point source. As a very rough aproximation the “magnetic” H field drops intensity with volume and the E field drops intensity with the surface, with power droping to aproximatly 1/50th at two wavelengths where the E field predominates in the radiating near field and the fields now form a reasonable aproximation to a “plane wave” (in nearfield antenna measurments the rule of thumb is 3 wavelengths from the antenna aperture).

[2] : It is possible to make a “shim” device that will allow man in the middle attacks but their design is at best difficult for various reasons and it’s usually easier to open the box and put a device in between the reader head and the following electronics or to replace the reader head entirely.

[3] : As I frequently say unless security is built in before the specification is written then it will be an after thought (as seen in the ISO standards used for NFC). The problem with after thoughts is generaly they result in either a significant cludge or “next revision maybe” behaviour, either way the apps are likely to be significantly less (or not) secure than required and be very vulnerable.

Clive Robinson • August 3, 2012 5:06 AM

@ Wael,

So who’s drink should I be imbibing? Nick P’s Orange Book “Tang”? Or Clive Robinson’s “Warden Earl Grey Tea”?

May I suggest from the confines of my hospital bed, you try a reffeshing cocktail of cool Mint tea with a tangy citrus addition that includes the best of the ingredients available?

The reality is we are all coming at a very large and difficult problem from several direction and points on the computing stack. Between the pink squishy “organware” down to the vaguries of quantum mechanics and also trying to reach out from our limited perspective and assumptions of our tangible physicaly constrained view point, out to the intangible not physicaly constrained information view point which even fundemental physics has problems with (in theory it is not limited by forces or the speed of light which makes direct “physical” measurment a bit difficult at best).

As I’ve said before Nick P’s approch is pragmatic and bassed on what is currently available and in turn is based on much work that has gone befor it which is well thought out and solidly reasond within the constraints and practices of the times.

It has however a fundemental concept underneath it which is the “single CPU” architecture and whilst that will always remain a valid viewpoint it has major limitations and is at the very begining of the “what’s possible continuum”. Primarily that “the hardware can be made trustworthy and it can be maintained as trustworthy” by methods that go back centuries.

We know from mathmatical work done before the electric computer was invented that a generaly usable system of logic (later called a Turing engine) cannot verify it’s self. That is it has no way to detect it has not been modified in some way and that it is in effect lying to it’s self and reporting those lies onwards.

We do know that although similar issues exist with non general systems of logic we can design limited state machines that are hard coded and will either report truthfully or will make incomprehensable noise or easily detected contradictions. Thus we can from the report have much greater confidence in what they are reporting (ie clear truth or incomprehensable and contradictory nonsense). If such a state machine is used to check a general purpose logic system providing it has been designed correctly it’s reports will be more trustworthy than the general system could ever report (there are issues but they are probabilistic in nature which is a very important point to remember).

If you look at the requirments for A1 to ensure trustworthy hardware they are not realy practical these days (ie shipping with armed guards being just one of many extrodinarily costly and impractical requirments).

So we know the problems of the past were only realy considered in standalone single CPU architectures from the assumption of “trusted hardware” up the software stack untill you get to the squishy pink stuff. This is again problematical because we work in networked environments using and multi-distibuted-CPU systems. Which means the attack surface is in continuous flux and effectivly “unconstrained”.

If you are only dealing with “outsider attacks” then the old rules still work very well. But not so with insider attacks by software developers or from supply chain attacks.

Some of what I’ve been proposing involves ensuring that systems are not “trustworthy on delivery” but remain trustworthy in hostile environments and offer greater protection from insider attacks (intentional or unintentional) from developers and to a lesser extent from supply chain attacks.

So please don’t look at as it being Nick P -v- Clive Robinson it’s not. In a final system all of Nick P’s solutions remain valid from the users fingerprints downwards, I’m working further down the stack to augment the approach to trustworthy hardware. Robert T is working even further down the stack at the very bottom of the supply chain working upwards. So you could say I’m “piggy in the middle” 😉

The point behind the title of “Castles-v-Prisons” is in refrence to the hardware environment. A single CPU architecture with large memory spaces and usually only software attempting to enforce segregation is very much like the inside of a castle where the guests are usually trusted and given minimal constraint on movment. The system I’m proposing is to much much more control this internal space and is much more like the way a prison works where the inmates are not trusted their environment is kept small their communications heavily monitored and their environment subject to frequent searches.

Currently what Nick P proposes for the software end sits directly on what I’m doing, however below what I’m doing and above what Robert T is talking about/doing is a very very large chasam which I don’t think can be realisticaly filled but only bridged and this is an area which researchers published papers realy don’t cover or even consider currently.

So I’ve made a swinging and possibly incorrect assumption as a starting point of “It cannot currently be solved and thus only mittigated”. and this is where you start getting into the joy of “probabalistic security” in many respects you can at the high level think on it in the same way the A-bomb designers did during the second world war. They knew that the only way they were going to get results they needed was with probabalistic mathmatics and this gave rise to Monte Carlo methods.

My personal view is we never will have anything other than probabalistic security in practical and usable systems, so we may as well start work on them now to save considerable pain later.

However I’ve a bad habit of being 20-30years ahead of the academics when it comes to ideas. This is not because I’m some kind of “super genius” or “in the right place” it’s just that I refuse to be constrained by their out of date methods usually enforced by publishers and funders that make the researchers forward progress like trying to swim in cold treacle. I prefer to skip ahead across the surface and with light footsteps make the paths that other explorers will investigate with (I hope) considerable rigour.

Clive Robinson • August 6, 2012 7:03 PM

@ Wael, (Robert T, Nick P),

With regards,

If access was granted / achieved at any stage then you fundamentally need to step back and question what forms of information leakage are possible. Unfortunately, for the security professional, this will often take them outside of their area of expertise.

And way way beyond their comfort zones. Esentialy this is another way to look at part of ,

“…however below what I’m doing and above what Robert T is talking about/doing is a very very large chasam which I don’t think can be realisticaly filled but only bridged and this is an area which researchers published papers realy don’t cover or even consider currently.”

There are a couple of ways you can look at,

“… assumes that the attacker has never had access to the computing device. If access was granted / achieved at any stage than you fundamentally need to step back and question…

Firstly the type of access, which can be,

1, Software only.
2, Hardware only.
3, A combination.

They are fundementaly very very different and it is important to keep this in mind at all times.

However the traditional way of dealing with such access is covered by “541t or Bust”, that is you examine how you perceive information can escape and put a detector in place.

This is part of what Robert is talking about with,

“… what forms of information leakage are possible.”

If you do not perceive the mechanism/route of the information leaking then you won’t put a detector in place for it (except by accident or luck).

Thus when and if your detector trigers you examine what you think you see and then if you beleive its valid you assume you’ve been owned some how… You could call it the “Banging stable door system” in that you don’t check the horse only what’s stopping it moving out of the stable, and only if the door bangs hard enought to wake you up…

The other part of what Robert is refering to is “closing channels” but this likewise presupposes you know what the channels available actually are, and that you can actually close them down. For instance cache or I/O leaks are part and parcel of normal operation and thus cannot in reality be closed down…

Realisticaly these traditional aproaches can only be taken with strongly deliniated systems which have clearly identifiable tasks that can be easily segregated and fully monitorable at the perimeter of each stage. Which to be honest only applies at best to “single function” “single chip” “single CPU” type systems, unless you want to put more effort in than would justify the expense (Nick P can give you an idea of just how costly such segregated and heavily monitored these very limited function designs can be).

There is however a catch, monitoring is like continuous testing, in it’s self it’s a very significant back door with potentialy more leaking channels than the original system…

Although at first the problem looks insoluable it’s not. The solution is to reduce the complexity of each stage to a minimum and have the minimum of inter stage communication using very precisly and simply designed protocols. Oh and absloutly no feedback other than “fail hard”, “re-start from the begining”. There are other issues such as “stage transparency” but these can generaly be solved by carefully selected “clock the inputs clock the outputs” for time based channels.

Now if we go back to my points about malicious access being software / hardware / combination and look at just the software access.

Software needs memory to exist which is accessable both to the attacker and to the execution unit. If the memory is not actually available, or that available to the execution unit is not available to the attacker then a software based attack can in effect be stopped before it starts. However there is a fly in the ointment which I shall for simplicity call “Interprative issues”.

To be of use a computer acts as one of three things,

1, Data source.
2, Data sink.
2, Data modifier.

If designed correctly the data source and sink should not react to the data, that is they use out of band communication for control purposes that are unavailable to a potential attacker.

The data modifier is where interprative issues arise. I could go through each type but I won’t but put simply if the data modifier operation is uneffected by data (say a binary to grey code converter) nore is it’s operation effected by stored data (think a simple DSP action) then the interprative issues do not arise. If however either immediate source data or stored data effect or can effect the operation of the modifier then the modifer is “interperating” the data and can thus be covertly programed to a limited extent via the data.

Stopping “data interprettation” is not an easy task however many parallel programing algorithms actually work this way, which means there are known ways of reducing the effect.

Software is in effect a “down the stack” attack, whilst hardware attacks are in effect “up the stack”. I’ll let you have a think on how you would prevent up thee stack attacks from a higher level but as an indicator I’ll say “Voting protocols”.

I’m sure at this point however that both Nick and Robert will have other aspects to raise and no doubt some I won’t have covered in the past (the subject is just to darn big for even quite a few blog posts or even academic papers 😉

Clive Robinson • August 7, 2012 1:36 PM

@ Nick P, RobertT, Wael

I’ve just poped this link to an economist artical on a large Chinese Telco manufacture on the latest squid page.

http://www.economist.com/node/21559929

You might find it is interesting reading.

Clive Robinson • August 7, 2012 5:12 PM

@ Wael,

Don’t look at the individual skillset, look at the team’s. You need to consider a team of subject matter experts

In theory yes in practice no.

You need to have a think about team dynamics and scope of skill sets.

The scope of skill sets is an interesting problem that usually is not an issue in normal engineering practice. However when it comes to security it is a real problem.

Think of it as a variation on the “putting fruit or eggs in a box” problem. No matter how you arrange the fruit or eggs you will only get minimal touching and plenty of space in between. And it is this space where security holes happen because generaly there is little or no overlap of expertise.

The other issue is a mixture of “group think” and “dominant personality” issues.

One way to resolve this is to have two teams where members rotate through one group to the next and back again. One team is the “design” or blue team the other the “attack” or red team and you treat it as a “competitive event”.

The thing to avoid is it becoming a “code review” process where the “blind” stare aimlessly where they think the sighted preditors foot prints will be.

Clive Robinson • August 9, 2012 3:48 AM

@ Wael,

But RobertT and I are talking about trusting a human being with a task. You are talking about trust in systems based on previous behavior

And the difference is?

A human being that does a task for you is like anything else capable of doing a task such as an ox or donky used to turn a water pump, a homing pigeon used to carry a message or a dog or pony used for transportation of goods and people.

If you go back just a little over one hundred years the technology age was starting with standard parts from a catalogue to allow people to build and repair machines easily and Henry Ford and others started using humans as automata in a production machine.

Basicaly if you have a task you need doing that you are incapable of doing effectivly yourself you get some kind of tool to use as a “force multiplier” it could be as simple as a hammer and chisle that you use or you employ a craftsman to use because they are eitther more skilled at it or your time is more profitably employed else where.

You implicitly trust the hammer and chisel not to break but you do explicitly mitigate this by having a range of hammers and chisels with you and other tools etc to effect repairs at a later stage back at the workshop.

For the last millenia or so this is what happens a tool is used as a force multiplier it is implicitly trusted to do the job but it is usually explicitly mitigated by maintanence and repair or replacment as it wears or breaks.

A human is a tool, an animal is a tool, an enginee is a tool any kind of cutting edge is a tool and any kind of lever is a tool.

We know that the use of all tools is probablistic in nature, that is they are not perfect and they make errors or mistakes. Some causes are easy to see such as tool wear others not so. General the more complex the tool is the more complex the causes of it’s mistakes. When a tool gets to a sufficient complexity it is considered a living thing (for instance the yeast for our beer and bread) and other factors come into play, at further complexity tools become effectivly self aware and have more complex patterns of behaviour bassed on percevied and actual needs.

The same rules however apply,

1, Previous behaviour is not a reliable predictor of future behaviour.
2, Previous desired behaviour may with future knowledge be seen as undesirable behaviour
3, Undesired behaviour should be expected and monitoring put in place to detect / mitigate it.
4, Systems should be designed to still work with some undesired behaviour as part of normal operation.

Tthe development of software or hardware is a manufacturing process using tools some of which are human. We know mistakes are made at all levels and we have of recent years put in place quality control systems to mitigate undesired behaviour within the manufacturing process.

As I’ve repeatedly said “Security is a Quality Process” it might be considerably more complex than most quality processess and be subject to way way more “imperfect knowledge” but with a little fore thought mitigation is possible esspecialy when for just a little increased complexity you get a whole lot more mitigation and ease of control.

All processes use tools and as I’ve indicated the tools might range from simple levers and cutting tools through the energy sources of sinue and muscle to the unknown behaviour of the little lumps of pink and grey porridge that occupiess our craniums. All processes have errors and by and large we can design systems to mitigate those errors.

So seen from that perspective what is the difference between a tool that is a computer system and a human that is also being used as a computational tool all be it beyond what any man designed machine can currently do?

Clive Robinson • August 11, 2012 3:06 AM

@ Nick P, Robert T, Wael, [1]

… after a known hacker physically possessed the device…

Woa, there are two many assumptions in that little snipit.

The simple fact is no matter how you cut it or slice it anything outside of your 100% direct observation and full control has at some point been “owned” by somebody else.

It does not matter what systems they may have put in place as we know all systems can be tampered with when out of sight, thus it cannot be trusted.

The question then becomes one of “how do we test or mitigate this issue?”… after a certain quite small degree of complexity we know we cannot fully test every state etc. Therefore there is always the suspicion remaining that the system has been “backdoored” only we cann’t find it because we have “imperfect knowledge”.

As a real world example of trust and how it fails lets look at the bulk Gold or “bullion Market” supposadly people are trading the ownership of gold ingots that have been specialy tested for purity, uniquely serial numbered and put under secure lock and key in a repository of the bullion house. This is a very very expensive process which is why what is actually traded are “certificates” not ingots. Traders implicitly trust the certificates because the bullion houses are supposed to explicitly trust the ingots they have under lock and key because of the expensive process of getting an ingot into the bullion house repository.

However it’s now known the process has been subverted (how is unknown) as “faux gelt” has been found in some repositories (which is possibly one reason Venezuela repatriated most of it’s gold http://www.bloomberg.com/news/2012-01-31/venezuela-receives-last-shipment-of-repatriated-gold-bars-1-.html )

Thus the only way to explicitly know you are getting what you pay for is to go through the whole “destructive” refining testing and recasting process yourself alone in your own refinery atttached to your own bullion repossitory that only you can ever enter…

The mitigation process is simple however buy insurance against the loss, but… after the LLoyds LMX spiral where “stop loss insurance” failed can you trust that the insurance will actually pay out if you claim? And do the insurers actually know the re-insurance market they use to spread risk actuall have the reserves to actually pay out?

Such are the joys of “imperfect knowledge”.

Or how about the stratagie of wide diversification of investment, that seemed a “sure fire” mitigation stratagem prior to 2008 when the banks tanked and sucked the rest of the world into their deceitfullly greated financial black hole. Likewise Government bonds with Sovereign debt.In all cases somebody subverted the system for their own gain and effectivly got away with it. Because the reality was way to few institutions to give sufficient independance for diversification to work but the market in general was unaware of this so they had “imperfect knowledge”.

Thus trust is an illusion unless you have sole control of all stages of the process. What actually makes trust work in the real world is knowing the other party genuinely has more to lose than you do which is why “to big to fail” and “limited liability” are very dangerous notions.

From the security asspect what is needed is the leverage of “more to lose” and “genuine diversification” of risk. The problem with this is the “imperfect knowledge” of cheating and how you mitigate it.

The interesting thing about “cheating” is in our tangible physical world it’s “rewards process” is not a “step function” it has the constraint of time that limits it’s reward process.

We see this with physical security whereby we have a “detect and respond” philosophy rather than an impossible to implement “impregnable fortress” philosophy. Which makes “physical security” probabilistic not determanistic in nature.

Now the question arises does intangible information have a time element. Sadly the answer is no as I’ve indicated before. However the processing of information as knowledge currently requires us to encode it onto physical objects (atoms etc) and this immediatly constrains it by the speed of light and physical forces.

Thus we can with care use “detect and respond” systems to limit the reward process for attackers and we can move away from the impossible to defend “impregnable fortress” philosophy that the current EAL systems impose to no long term useful effect.

However we have to have reliable methods to discover “cheating” in very short time periods for this to work so the fortress mentality of the lower EAL levels can just as with A60 “fire resistant” safes buy us time.

And yes this is an intrinsic part of the C-v-P idea, and as Nick P has noted some other researchers are now thinking along these lines (if only in software).

But as I noted before “software” is a top down solution where as supply chain attacks are a bottom up attack which leaves this large gulf to be either filled in or bridged.

[1] Note to self must program a “short cut key” for this 😉

Clive Robinson • August 11, 2012 7:27 AM

@ Wael,

It is reputed that the English Bard William Shakespeare said of life,

To be, or not to be, that is the question

To update to the modern world it might be,

To trust or not to trust? that is the question

I’m of the opinion we do neither and go the way of the CIA’s

In God we trust (all others we check)

Which is actualy in line with physical securities probabilistic nature of “Detect and Respond” in theory the only part you need to trust is the “instrumentation of the detectors” and as I’ve indicated before this is best left to a fully determanistic state machine.

Which has certain charecteristics such as all states are known and tested and there is no feedback etc only hard coded state to state translation with the only data dependant action being to halt a running process and raise an exception to some kind of hypervisor.

Obviously you have to know in advance what you are going to “measure” in your detectors and what values are going to trigger the exception.

In essence this is the inverse of using a “matched filter” to pluck a signal out of the noise because any “noise” implies unknown / unexpected behaviour. This is a more advanced form of raising an exception on a “segmentation fault” and to do it requires that a process produces a clear signiture which in tern requires the process to have low complexity and be well defined.

Whilst this might at first appear to limit what can be done in practice it makes very little difference as has been shown by various “parallel progrmaing” methodologies.

The cost is many many small processes and a great deal more process to process communication.

In a single Complex Instruction Set Computer (CISC) context switching from process to process has a very high overhead. However using a Reduced Instruction Set Computer (RISC) and a stack based memory language task switching is as simple as pushing the CPU registers to stack and changing a single register to then load the registers with the next processes saved values and stack pointers. As efficient as this might be the use of a stack based language reduces the complexity of the CPU down to maybe 25-30 instructions and optomised register handling shrinks it even further which means that you could have a very large number of CPU cores when compared to a CISC system so process switching may not even be required for much of the operation and that that is required can be made very very efficient.

With such a system various new tricks can be performed, one of which is to have multiple CPU designs designed by different teams as macros in the chip design. This then allows voting protocols to be used alongg with dropping in “known test vectors” to check the CPU.

Trying to get beyond such near realtime detection methods would be very difficult and thus subverted hardware that gets triggered to rouge behaviour in some way has a very high probability of being detected very very quickly before much if any information is leaked.

Fianaly a parting thought William Shakespear wrote a lot of sonets etc which can be used as transportation for mems, one of which is “But soft what light through yonder window breaks…”

http://www.enotes.com/shakespeare-quotes/soft-what-light-through-yonder-window-breaks

Such use as mems was used in clasified adds during Victorian times along with simple codes and ciphers for Victorian Romeos and their Juliets to communicate supposadly secretly. Charles Babbage and friends used to break such codes etc and place faux replies such that the participants new they had been uncovered but without knowing by whom.

The use of such is virtualy non existant these days but would certainly still work as a low security way to transfer information through as a side channel on many web pages.

Clive Robinson • August 11, 2012 5:18 PM

@ Wael,

That’s how task switching happens on CISC as wel(short of the stack pointers). Unless I forgot!!

Broadly, the reality is usually a lot lot more bagage, the use of a stack based language provides a greater level of abstraction which reducess the baggage (if done correctly).

I presume you are referring to the the CPU. I presume you are referring to the instruction set being “stack based”

Yes. For example back in the 1980’s a version of Forth was implemented on a DSP chip as effectivly a Harvard architecture and IIRC only implemented twenty seven basic Forth words.

With regards,

“All cryptography is based on a secret. Regardless whether symmetric or asymmetric. Do you agree or disagree?

The answer is no if you believe “non secret” use algorithms such as hashes are cryptography. As hash functions can be made from either block or stream ciphers with a “known key” used as a public IV this extends to them as well. So if you are using crypto to keep secrets you need a secret so in this limited case the answer is yes.

Clive Robinson • August 12, 2012 2:43 AM

@ Wael,

Let me restate my question: all encryption / decryption schemes are based on a secret

As a general principle yes there is a “secret” or a “derived secret” at the base of most crypto systems used for maintaining confidentiality of information moved across an “open” or “insecure” channel.

However the “secret” may not be a “secret” it’s self. If you look at something like the “Rip van Winkle” idea the secret key has been sent in “plain text” at some point in the distant past along with many many others. Thus the “secret” moves from “the key” to knowing “which key”.

So I’m going to bite and say yes (happy now 😉

Clive Robinson • August 13, 2012 5:05 AM

Wael,

There are various investigations of “range” determination/limiting for detecting if a users credit card is directly in the EPOS machine or if somebody is inbetween (via a physical shim in the EPOS slot) to substitute a fake transaction etc.

It’s a complex problem and one Near Field Communications for “cash transactions” is potential going to turn into a blood bath for consumers and the most well oiled of gravy trains for the banks and criminals alike.

One idea that is a range limiter for such, is a form of spread spectrum where the receiving party starts transmitting a True Random Digital Noise modulated carrier (using phase reverse keying) the data transmitting party receives this signal and uses it to modulate it’s data with it.

The data receving party compares the TRDN phase difference (~=time) to determine the range. In this respect it works just like JPL ranging codes.

Two effects occure from the use of TRDN as opposed to PRDN importantly it cannot be predicted so it cannot be spoofed on range. So secondly to succeed the attacker has to be inside of the “range” to get a signal accepted, over very short distances that is very difficult to do.

The problem is it can fail to pre-recorded replies stored inside the range. The trick then is to use another protocol on top somewhat like a zero knowledge protocol.

And as RobertT has indicated adding one or more receivers can give a hard minimum range and position. It’s a bit like turning GPS on it’s head, which is something I’ve go on about from time to time whenever anyone talks about GPS receivers being spoofed 😉

However I should emphasise that this does not offer confidentiality just range limitation at the physical layer.

But it does give a low leve starting point on which to build 😉

Clive Robinson • August 18, 2012 8:07 AM

@ Wael,

Thanks! Interesting exercise. Will be thinking about this

How’s it going?

It’s a bit to hot in the UK to be wearing a “thinking cap” and I hear bits of the US close to the Politicos in DC have had “early global warming” and in effect it’s been hotter than a “snakes belly in a wagon wheel rut in Death Valley”. And worse yet for the majority had no power for their fridges, freezers etc, unlike the politicos…

Clive Robinson • August 20, 2012 9:44 AM

@ Wael,

just to add a bit to your…

Have a look at how a VOR beacon works.

It uses a pair of orthagonal antennas driven in such a way that the AM and PM are out of phase by the same amount you are around the beacon.

So if your display says 90degs then the beacon ist due east of you…

Then think how you could use such a system to send a secret message in one direction only…