By The Lizard Farmer
Comms Hardware and Parts 1,2,3
Rural Defense Comms: The Hardware
We’re going to take a little break from terrain and touch on another topic – Communications or Comms. I’ll say it right up front – I know I’m going to catch a ton of shit over this little gem. Comms is about as hot a topic as different shades of Multicam and there’s as many arguments over the merits of what is and isn’t best in comms gear. But remember what the focus of this blog is: Rural Defense when SHTF. That SHTF could be in any number of forms – economic collapse, widespread civil unrest, Insurrection, a Zombie Apocalypse (I got an email asking why I don’t use that scenario since it’s such a “great catch-all surrogate” – Are you happy now?). This article isn’t geared for the Militia Unit in a tactical environment – there are better options for those folks. If you’ve read The Farmer at War you’ll remember the mention of their radio system: The Agric-Alert Radio system. This system allowed farms and ranches not only to alert security forces of attacks, but also to call for assistance from their neighbors. And just like those Marxist thugs that attacked those farmers you can bet that if you’re going to get hit the threat is going to take your phone and power out if it’s still on (those little green telecom boxes up and down the roadside don’t hold up to being run over – and please don’t ask me how I know this). In this entry we’ll look at some examples of comms solutions.
The first step of developing any system is examining the need. What do we need? Right off the bat I can think of three things that are critical: It needs to be cheap, reliable, and easy to power. Here’s what I came up with for a set of basic requirements:
1. A reliable, inexpensive, and readily available local communications system able to work throughout our entire AO. It has to use readily available power sources and should be capable of being mobile.
2. The ability to monitor official traffic and reports including LEO, EMS, and Weather as long as they are on-line and friendly.
3. The ability to communicate with the world outside of our AO. And not necessarily active communication which I’ll get into later on.
A fourth requirement that would be nice but just isn’t really feasible is a source of secure comms. Crypto gear isn’t cheap so I’ll rule that out. Now that we’ve identified three major requirements let’s look at our AO again.
Based on the old calibrated eyeball we need a local comms system that can reach at least 10kms (6 miles) in heavily wooded and hilly terrain. FRS and GMRS are neat and cheap but in our terrain (heavily wooded) and given that distance they don’t seem really practical. Handheld Amateur Radios (UHF/VHF) have gotten incredibly cheap lately. A quick check of fleabay shows tons of Chicom handheld dual-band handhelds for under $100. The drawback with these is that it takes some training to really use and program them. And not all of them take readily available batteries (for some stupid reason the cheaper ones normally use a proprietary rechargeable battery – not something I’m fond of). Another option is Citizen Band. CBs are cheap (Rat Shack has 7 watt handhelds that use AAs for $50), plentiful, and are almost idiot proof. Hell a lot of rural guys may already have a CB in their truck or tractor. The drawback is that if your AO is sited near a busy highway you may get a LOT of outside traffic and finding a clear channel might be a PITA. But I’m pretty sure if things go to hell most truckers are heading to the house to take care of their families. Now remember what I stated above – we’re not looking for a comms system to go on a long range patrol. We’re looking to get reliable comms between farmers, ranchers, and homesteaders. Given that this is how I rank the three options:
1. CBs (both handheld and base station)
2. Dual Band Base Amatuer Radios (HAMs, including handhelds)
3. FRS/GMRS
I skipped some systems like MURS, Business Bands, UPCS, and others because they just aren’t common enough, complicated to program, or too short range. So for the sake of time and space we’re going to talk CB. As I stated above handheld CBs capable of 7 watts can be had for around $50 new. With that price it’s pretty realistic to assume that every home would have at least one on hand. A good rule of life after SHTF would be that anyone out in the AO away from their point defense locaitons (remember – our homesteads) should be carrying one. The cool thing with CBs is there’s also other options. That mobile rig in the truck can come out and get hooked to a 12V car battery and run as a base station on a homebuilt antenna. (see the resources I list at the end of this article). I bought a couple of CBs at a yard sale right before last Christmas for $20. And anytime I run across them for that price in good working condition I usually snag them up, box ‘em up, and save them for a rainy day. Given the commonality of CBs and their ease of use IMHO for our purpose you can’t beat them.
So now we move on to our second requirement – Monitoring LEO, EMS, and Weather (at least for as long as they are broadcasting in the clear). The best (and pretty much only) option here is to have a scanner. True there are other systems and sources but using our criteria (cheap, reliable, easy to power) a scanner is the best choice. I’ve linked a site or two at the bottom that gives more information on scanners. Regular radio stations can give you some info but once shit goes critical I wouldn’t expect them to remain on the air with anything more than prerecorded EMS broadcast messages.
And we finally get to our third requirement: The ability to communicate with the world outside of our AO. For this purpose I firmly believe there is only one real solution – Amateur Radio or HAM. When the world has gone to shit, the living dead rise from their graves (that’s a freebie for you zombie nuts out there), and the British come for their back-taxes HAMs will still be on the air. The problem is HAM radios aren’t cheap. And the handhelds may not have the power to reach out and touch someone. Your best bet is to do some research (Links below), and shop around. A UHF or VHF radio is not something you can just unbox, plop down, plugin, and start using like an X-Box. It takes a little knowledge and understanding of science. Now if you get lucky and have a rag chewer in your AO (look for the antenna mast) you’ll be in luck. Otherwise someone is going to have to invest the time, money and effort into studying and buying a rig. And I know it won’t matter after the “rule of law” is gone but studying and getting that license now is a good idea. Practical experience before you need the skills goes a long way.
The final two solutions have one drawback – most of them require AC power. And that stuff don’t grow on trees. I’m not going to go into the zillion solutions to power your homestead after the juice goes out. Google will give you more info than you care to digest on that topic.
One thing I want to address: Whenever you pick up a radio be it whatever kind the first thing you do is listen. And with comms to the outside world that is critical. Don’t assume just because someone is on your freq. they are friendly. You’re not the only one reading this article and I’m not the only nitwit that has come up with this info. Practice OPSEC (that’s a subject for a later entry).
In the next entry I’ll go into some examples of comms procedures and we’ll look at what we can do to overcome the lack of Crypto.
Rural Defense Comms: TTPs Part I
First up: If you’ve served in any military or like environment and used tactical radios this is going to be all too simple for you. And that’s the point here – we’re going to try and make it simple for the non-trained to pick up and use. If it’s overly complicated chances are people will use bits and pieces and adapt the system to their own liking so let’s keep it simple and avoid any painful evolutions. The first thing you have to stress to everyone that will use a radio is that clear, concise communications are critical to effectiveness. If someone is screaming at the top of their lungs in a panic on the net it’s going to be a lot more painful than necessary to sort out what’s happening at their station. Hammer this consistently. Comms procedures are one area that has to be disciplined – hell even in regular forces comms discipline can be painful. Work it, be persistent, be tactful, be the example, but most of all be unwavering.
So we’ve identified our comms hardware and now is the time to put it to use. I’ve geared this to our local area radio system identified in the previous comms entry (in this case CBs) however it can easily be adapted to other systems as well. And to put it to use it has to be turned on and monitored. Folks should have their radios on and within earshot 24 hours a day. After all it would seriously suck to miss that spot report that 3 armed dirtbags have been spotted 200 meters south of your homestead because you were on the shitter. If you can’t be near the radio then someone in your point defense should be. There is another time folks should have a radio on them and have it tuned to either the admin or emergency channel. That’s when they are out away from their point defenses (homesteads). That way in case of contact or if they are needed as a response force they’ll be on the net. This is what makes those handheld radios so attractive.
So we’re going to identify some necessities that we need to develop and implement. Kicking it around I’ve come up with these necessities:
1. We have to identify what elements of communication are critical to everyone understanding so they can effectively communicate on the net.
2. Folks need to understand when to switch to the Emergency Net.
3. We need call signs.
4. We need to be able to spell out complex words by using a phonetic alphabet.
5. We need to use prowords.
6. We need to assign frequencies.
7. We need a Net Control Station (NCS).
8. We need a procedure to ensure everyone is able to transmit and receive on our nets.
The elements of communication we want everyone to clearly understand and apply should be something like this:
1. Always assume someone you don’t want monitoring the nets is listening. Practice OPSEC (OPSEC will be covered in depth later on).
2. At no time does anything that would be considered OPSEC be transmitted outside of an emergency situation.
3. Take a moment to mentally (or actually) compose the traffic you wish to send.
4. Keep messages as short as possible. Transmit no more than five continuous seconds. If the message is longer use the BREAK proword (explained below). This is to make it harder for direction finding equipment to pinpoint you accurately.
5. Always listen to make sure no one else is transmitting before you key your set.
6. Speak clearly, slowly, and in a normal tone.
7. Monitor the radio all the time.
The second necessity we identified is to have folks understand when to switch to the emergency channel. It should be SOP throughout the entire AO that anytime you aren’t talking on a routine traffic local channel or monitoring the administrative channel you should be monitoring the emergency channel (many CBs have a channel 9 scanner which works great for this purpose). It needs to be reinforced if you hear or see something out of the ordinary like gunfire, an explosion, or heavy vehicle movement to switch to the emergency channel automatically and monitor traffic. The administrative channel is kind of like the old country “party line”.
The third necessity we’ll cover is that every station on the net has a callsign (a.k.a. a name or handle). This can be something simple like the families last name, a commonly known nickname, physical location, etc. It must be something commonly known to everyone throughout the AO. Referring to the map from out terrain piece I’ll just use the family names of the homesteads on the map.
The fourth necessity to avoid confusion you should stress the use of the Phonetic Alphabet. Although this is standardized across the military and most LEO/EMS entities it doesn’t necessarily have to use that format. The substitution of other words that also clearly convey the letter intended will work as well. I.e. instead of “Zulu” the word “Zebra” could be used. As long as they are not complex words (advise them to stick to short and distinct words) they should work. Keep it simple and easy for the tribe.
The fifth necessity is Prowords. A Proword is a word that has been assigned a meaning and are used to expedite messages. IMHO I would only expect the most common Prowords to be used and then in simple fashion. These are the ones that will provide you the most bang for the buck. i.e.
ACTUAL – normally reserved for the family/homestead leader. It’s used in conjunction with the callsign, i.e. “Briggs Actual” would get you Mr. Briggs Sr.
BREAK – Indicates that the sender is going to take a temporary break in transmission for a few seconds.
FLASH – FLASH is used in regards to traffic priority with FLASH traffic being a higher priority than all other traffic. A Sender starts a message with FLASH FLASH FLASH (always 3 times) when a message contains traffic that is of an emergency nature. All other stations should stop transmitting and monitor the message.
I SPELL – Used immediately before phonetically spelling out a word.
OUT- The station is done transmitting and no further traffic should be expected.
OVER – The station is done transmitting and is awaiting a reply.
ROGER – The station understands/acknowledges the traffic sent.
SAY AGAIN/SEND AGAIN – This Proword is used instead of “Repeat”. When a station doesn’t understand or didn’t receive a portion of a message they will ask the sender to “Say Again” or “Send Again”.
WAIT OVER – The sending station must leave the net – not normally for more than a few minutes. Using this Proword gives the expectation the station will return briefly with information or to continue the conversation.
WAIT OUT – The sending station must leave the net for more than a few minutes and will return later to complete the conversation.
Prowords also bring up the topic of duress codes. A duress code is a single distinct word used when a station is being directly threatened (i.e. a dirtbag is standing over the sender with a pistol pointed at his head during a comms check or a conversation). A duress code must be memorized by everyone and should be easily inserted into normal conversation. The word “Peachy” is an example. A station under duress might answer a comms check with “All Peachy Out” instead of a simple “Roger out”. This alerts the other stations that station is under duress and needs assistance. At that point hopefully you’ve developed a TTP to deal with this. We’ll cover that later in active defense. Also note that duress codes SHOULD NEVER BE USED in normal conversation. If you want to get real fancy each family/homestead could have its own duress code but frankly IMHO for the sake of simplicity a single word throughout the tribe is better.
The big thing with prowords is that everyone understands what they mean. If I use “Tally-Ho” as a proword for the QRF to assemble and no one knows what it means then It’s useless.
The next necessity to avoid confusion is to assign frequencies. In our case using the Citizens Band we reserve some channels for their intended use. Channel 9 is the normal emergency channel. Channel 17 (for North/South Bound traffic) and 19 (for East/West Bound traffic) is normally used by Truckers. We will retain the use of Chanel 9 as our Emergency Traffic/Alert channel. We also need to assign channels for normal routine traffic that is common throughout the AO. This is an example of how to break it down.
CH. 1-8,11-16, and 18 are used for local inter-homestead traffic. 9 is the emergency (our version of the “Agric-Alert”) net, and 17 and 19 we retain for truckers. Now we block off 20-29 and 30-39 for our local admin net. This is the net we put routine information on and conduct comms checks on. The idea is that we use the channel that corresponds to the date with a fall back channel 10 steps higher. I.e. on the first, eleventh, twenty first, and thirty first we use channel 21 and if it’s jammed/being used by outside sources/ otherwise unavailable we’d switch up to 31. We use Channel 20 on the tenth, twentieth, and thirtieth with a fall back to Channel 30. Note that SSB is normally in the bands above 30, could possibly interfere with AM traffic, and is used for longer range comms so we’ll try and avoid it. Good to have in a pinch but we’re going to try and avoid advertising our existence. I would advise everyone routinely monitor the administrative net and if they need to communicate amongst each other contact that station and have them drop to another channel.
Next up is our seventh necessity. Here’s the fun part: We’ve almost got to assign a Net Control Station (NCS). The NCS acts as our Emergency Ops Center (EOC) – the central hub for our comms. It’s a good idea to collocate your scanner, Amateur radio, and a couple of CBs (monitoring the admin and emergency channels but if you have a radio that scans 9 you can get by with one) along with an FRS/GMRS scanning radio (there’s a good possibility any threat might be using them) in one central well protected location If you have a HAM enthusiast in your AO they would normally be the natural choice (most of the ones I know would like nothing better to live on their rigs). Here’s a downfall – comms should really be monitored 24 hours a day. So it might be a better idea to rotate the responsibilities for monitoring the emergency net throughout the AO. One critical asset of a good NCS is the ability to pull information out of a station on the net. If blabbering jack is on the end trying to tell everyone what is going on and he’s excited and transmitting a lot of gibberish and extraneous info it’s the NCSs job to calm them down, ask pointed and direct questions, and get as close to the real picture of what’s going on as possible. Basically when SHTF the NCS controls the emergency net.
Our Final necessity is to be able to ensure everyone is able to transmit and receive on our nets. We accomplish this by using Comms checks. Comms checks should be conducted at least twice daily – normally once in the morning and once in the evening. If feasible the morning check should be no later than 30 minutes before morning twilight and the evening check should be no later than thirty minutes before the end of the evening twilight (you can get those times from the good old Farmer’s Almanac or the web). Why? Historically these are the times that are most likely for an attack to occur hence our TTP of “Stand-To” which will be covered later on in active defense. Now this isn’t to say that you might not get hit at midnight but if you’ve done a comms check then chances are your rig still works. Another good TTP is for everyone to switch their radios to channel 9 prior to bedtime which brings up another point – the radios ideally should be in the bedroom. That puts it near and pretuned in case it’s needed and also allows for monitoring of traffic. If channel 9 goes blaring at 0130 about an attack on the Briggs homestead chances are it’s going to wake you up. Putting the radio in the bedroom with a handheld is no problem but with a base station it may be. Plan accordingly. Daily radio checks are initiated by the NCS and answered by each station in a manner similar to:
NCS initiates the comms check: “All stations this is Briggs radio check”
NCS calls first station: “Mann Briggs Over”
Station (in this instance “Mann”) responds: “Briggs Mann Roger Out”
And so on and so forth until all stations have acknowledged. If a stationed doesn’t respond after three calls you should move along and try them once more at the end. If they still do not respond then it’s time to send some folks over and check on them. The NCS normally closes the comms check out with something simple like “This is Briggs out”
For those so inclined the US Army Center for Lessons Learned RTO Handbook is an excellent source of additional and amplifying info. If you haven’t what figured it out by now what we are basically doing is building a Comms SOP from scratch pulling from several sources and simplifying it wherever possible. The KISS principle is still as relevant as ever.
In the next installment we’ll look at some examples of how to overcome our lack of crypto and examine OPSEC a bit more in detail as it relates to comms. Reports and other emergency procedures will be addressed in their respective articles.
Rural Defense Comms: TTPs Part II
In the last entry we discussed the basics of establishing our local area net. I’ve identified one huge shortfall in our scheme – the lack of secure comms. Continuing the comms theme in this entry I’m going to address that problem and begin to dig into some solutions. Before this goes any further we have to discuss radio security. A quick review of the first two basic radio operator guidelines are in order at this point:
1. Always assume someone you don’t want monitoring the nets is listening. Practice OPSEC.
2. At no time does anything that would be considered OPSEC be transmitted outside of an emergency situation.
OPSEC, OPSEC, OPSEC – because anything you say on an open unsecured net can be considered intelligence. OPSEC is formally defined as: The process that identifies critical information about our tribes intentions, capabilities, and vulnerabilities while employing steps or measures to deny this information to our threats.
So how do we identify that critical information? We establish what is called Essential Elements of Friendly Information (EEFI). EEFI is that info which we don’t want folks outside our AO to know. EEFI should include things like:
1. Anything to do with security.
2. The number of folks in the AO (your manpower).
3. Any defensive or offensive equipment on hand or shortages including arms, ammo, medical material, obstacle material, etc.
4. Any capabilities – including the time frame to assemble a QRF, their size, assembly area, medical or firefighting capabilities, etc.
5. Times and locations for any planned event (i.e. coordination meetings, church events, etc.)
6. Any current or future plans including things like when an obstacle is going to be emplaced, When a hardening party (more on that in passive defense) is going to happen, guard force information, etc.
7. Any information pertaining to food, fuel, first aid, or emergency reserves.
8. Any kind of tactical information outside of an emergency.
Leaping Lizards that a lot of stuff. Yup, and that’s a non-inclusive list. I’ll break it into one easy to follow concept for ya -
IF THERE’S ANOTHER WAY TO PASS THE INFORMATION OTHER THAN USING A RADIO DO SO. TRY TO KEEP ALL TRANSMISSIONS TO ESSENTIAL AND EMERGENCY COMMS ONLY.
Not super complicated is it? The concept that the best way to keep EEFI out of the wrong hands and practice OPSEC is radio “abstinence”. So once again you’ll have to delve into the area of Tribal Politics and convince the Tribe that the number of rolls of wire Mr. Jones has isn’t something that needs to be talked about on the radio. What about using phone lines? Folks, the ability to remotely monitor wire comms has existed for over half a century. It was a common practice in the Vietnam war to tap into the NVA and VC wire to get info. You’ll have to convince folks that lacking some really high tech gear (which we’re not going to have) anything you say outside of meatspace is being monitored by someone who is probably not friendly.
It’s going to take some fundamental changes in the way people think about information to effectively implement OPSEC in the tribe and AO. By adopting a “Need-to-know” attitude a lot of info will stay off the net. A Need-to-know attitude is simply restricting information to those that only have a clearly recognizable requirement to know something. It boils down to avoiding gossip or the old saying “loose lips sink ships”. Pose this to them: Before you say anything think – “How could this information endanger us? Does this person really need to know about this? Is there a better way to get the info to them?” Some folks will ask “Is it really that dangerous to talk about some of this stuff on the radio?” Here’s an example:
I’m eavesdropping and I hear Carla on the radio with her mother asking if she can go over and see Jimmy after her chores are done. Her mother gives her permission So she calls Jimmy and let’s him know she’ll be over. Jimmy tells her he can’t because he has a “prior commitment” until 1800 at “Kilo Four One” but she can pick him up there if she wants but to be careful of the tree in the road.
What did that tell us? Think about it. I know a minimum of two females and one male operate on this net. I can assume that two are members of the same family which draws the conclusion there is probably an unnamed older male as well. I know there’s a male (Jimmy) that is going to be tied up until 1800. Possibly a guard rotation at a location that he used a code name for. So I know that there is an encryption system for locations in this area. I also know that there are likely obstacles in their AO now as well. That’s a lot of info for such an innocent conversation. And that’s the point – The simplest information can be used to flesh out a picture. hence:
IF THERE’S ANOTHER WAY TO PASS THE INFORMATION OTHER THAN USING A RADIO DO SO. TRY TO KEEP ALL TRANSMISSIONS TO ESSENTIAL AND EMERGENCY COMMS ONLY.
If Carla had gotten offa her butt and talked to her mother face to face then rode over to Jimmy’s and done a face to face the info we gathered would not be in our hands now. Maybe Jimmy’s place was too far to go and the radio call was legit. We still wouldn’t have all of the info we gathered. If Jimmy had employed a little more OPSEC and not mentioned his “commitment” time frame, location, etc. but that he was going to be tied up for a few hours this afternoon or evening we’d still have less than what we’d like. Now people are going to take the path of least resistance or “the easy way” and wanna play GI Joe with the Kung-Fu grip on that mic. If you hear them doing it it’s probably a good idea to tactfully break into the conversation and remind them about OPSEC. Don’t be an ass because you’ll just piss people off.
So how can we use the radios without letting everyone know all of this info? Truth be told you’ll have what are called “spillages” (information leaked that shouldn’t be) – expect them. The damage done can be minimized by some conscious thought and following some common sense rules. Things like:
1. Thinking about what you’re going to say and the information you are going to pass before you key that mic.
2. Keeping information as generic as possible i.e. “being tied up” and “down the road” are good terms.
3. Never transmitting a list of anything. No rosters, shopping requirements, ammo on hand, nada. Lists are nothing but raw intelligence.
4. Minimize the transmission as much as possible.
5. Use prowords, callsigns, and any adopted encryption methods.
6. Employ a need-to-know attitude (keep gossip in check).
Yup, this is all fine and dandy but what about an emergency? That’s a whole different ballgame. You can contain spillage over the emergency net by having clear plans built and briefed in meatspace. I’m going to cover those types of emergencies in their respective areas (i.e. active defense). All of this leads to one theme: You want intel to be a one way street running in your direction.
Next up I’ll jump into some basic encryption methods to pass info and explain why they may or may not be such a good idea.
Rural Defense Comms: TTPs Part III
Alright Joe, here’s the part you’ve been waiting for. We’re going to touch on how to overcome that shortage of secure comms. First up I’m going to state my honest opinion on having non-regulars and untrained folks encrypting and decrypting messages. Unless it’s simple and idiot proof I’m not a huge fan of it. I would rather folks use sneakernet to pass messages but if time/space isn’t in your favor then it may very well be worth sitting some folks down and conducting a “train the trainer” session to get whatever techniques or technology you use spread amongst the tribe. For our purposes we’ll refer to our code as a “Cipher”.
Message encryption is ancient – literally. Ceaser used a basic encryption to encode his personal messages (Google Ceaser Cipher). There’s literally hundreds if not thousands of ways to encrypt. Book Encryption, drop code, etc. etc. Understand this right now: A cipher is only as good as the folks using it and how secure they keep it.
Joe Commented “Regarding crypto. Prepare a code manual. Five-letter meaningless groups. These are assigned arbitrary meanings. You need the code book to encode and decode messages. The code groups can be spelled out phonetically. Numbers will also work, and may be easier to transmit. Just read 5-digit groups with a pause between groups. The code book is arranged like a bilingual dictionary. Code groups in some order (alphabetic or numeric) with their assigned meanings on one part of the code book; assigned meanings arranged in some manner (alphabetic) with their code groups in the other part.” This is a viable technique as well.
When I was a young troop (and I’m going to give away my age here) we still used PRC-77s. Now light units in those days were “equipment challenged” so not every radio had a Vinson (Google it). In fact only our Company Commander had one. So we lacked secure comms between the Company and the Platoons. And the way we overcame that was through the use of the Company Tactical Standard Operating Procedures (TSOP or TACSOP – an SOP that dictates how a company operates in a tactical environment) and the Communications Electronics Operating Instructions (CEOI later called an SOI – a classified controlled small book normally carried in the chest pocket dummy corded to the carrier). the CEOI gave us the ability to encode messages and other information along with authenticating traffic. The Company TACSOP gave us a neat tool – The Brevity Matrix. I’m going to throw some example tools out inspired by these “low tech” solutions to get your gears grinding.
Remember: A cipher code is only as good as the people using it and how well it’s protected. So if you plan on using it prepare to conduct some really intensive training along with thorough practice sessions along with setting rules on handling your ciphers. And spotcheck both the operation and handling frequently.
Now before we get into the meat and potatoes we need to add a few Prowords (remember those?) to our vocabulary. So jot these down:
ALL AFTER – Used in conjunction with SEND it tells the message sender to resend everything after a certain part of the message. i.e. “SEND ALL AFTER VICTOR VICTOR OVER”
ALL BEFORE – Similar to ALL AFTER except it’s used to send the portion of the message that precedes the stated portion. i.e. “SEND ALL BEFORE VICTOR VICTOR OVER”
AUTHENTICATE – This Proword is used to make a sending station conduct authentication from the authentication matrix.
I AUTHENTICATE – These prowords are used to let the receiving station know the transmitting station is sending an authentication cipher in response to the proword AUTHENTICATE. DO NOT conduct automatic authentication (i.e. before being prompted the transmitting station sends the phrase “I authenticate Victor Victor Zulu”). It is a sloppy practice that can compromise a cipher.
PREPARE TO COPY – This tells the receiving station to prepare to copy a message.
SEND – This lets the sending station know the receiving station is ready to copy the message.
Good to go? Now here’s an interesting tidbit. There are over a thousand words in the English Language that consist of ten letters without a single repeated letter. So for this example I’m going to use my big ass list of ten letter non repeating words as a cipher.
The first thing we’ll go into is Authentication. Authentication is normally used in response to a request, demand, or command. Authentication allows the receiving or directed station to confirm that the sender is the real deal and not some dirtbag trying to pull some B/S. Remember: this is an example. Semper Gumby it.
For my purpose I want to have a 10×10 authentication matrix to make it easy on me (remember I’m working with ten letter words). So I grid out a 10×10 grid and use the words from my list to fill it in. The way I did this one is I started at the top and worked inward from the top and bottom – one from the top, one from the bottom, one from the top, etc.. scratching them off as I went. Once I had the grid filled I added another unused word above and to the right side of the matrix. So this is what I ended up with:
So how do ya use this thing? It’s simple. The station requesting the authentication selects a letter from the top (shaded) row first and then from the shaded side row. For example the station callsign Howell prompts the station callsign Briggs to authenticate:
“BRIGGS THIS IS HOWELL, AUTHENTICATE TANGO SIERRA OVER”
Briggs in turn would look those letters up in the same order Howell did and cross index them – resulting in the letter “R”. Briggs would then authenticate in this manner:
“HOWELL THIS IS BRIGGS, I AUTHENTICATE ROMEO OVER”.
If the authentication is successful then that Cipher shouldn’t be used again for that period (more on that below). If it’s not then Briggs may send another. After two failed authentications Howell would ignore all traffic from Briggs and report a failed authentication to the NCS – which may prompt the QRF to move out and check to see why Briggs had its head up its ass and returned an incorrect authentication – possibly from an expired table (we’ve got a fix for that below).
Another neat technique is the incorporation of duress codes into authentication. If a station is under duress and being forced to send demands, requests, etc. they could slip a predetermined code or technique into the mix. i.e. instead of just authenticating with Romeo they may authenticate with Romeo Tango (the letter below R). The receiving and monitoring stations realize that a dual letter authentication isn’t right and take action. One thing really important here : If a duress is used in conjunction with a cipher then that cipher has to be immediately considered compromised.
Easy, eh? Alrighty, next up is one of my favorites – the Brevity Matrix. We used the brevity matrix to encode messages and even locations to send across unsecured nets. It’s similar to the authentication table however instead of just letters it contains words or even phrases. Using my list of ten letter words (over a thousand of them – that is some fascinating shit) we’re going to create another 10×10 grid. This time we’ll fill it in with common words, orders, information, whatever you feel needs encryption. Once we have it filled in (and you don’t have to fill the entire thing in mind you as blank spots could be a great method of deception – and don’t forget to jumble ‘em up) once again we place one of our UNUSED ten letter words on top and the side like the Authentication table. So we end up with something similar to this:
Simple right – so let’s setup a message with it. Once again Briggs and Howell are on the net and Briggs is going to send Howell the message using what we’ve covered so far in comms techniques (including those breaks). Note how both stations use their callsigns – each message is started by the intended receiver followed by the transmitter. Now here’s a technique I recommend: Send brevity matrix codes in the same group size as any location types or other type encrypted info you send – it adds a layer of difficulty for the threat to determine what kind of information is being sent.
“BRIGGS, HOWELL, PREPARE TO COPY OVER”
“HOWELL, BRIGGS, SEND IT OVER”
“BRIGGS, HOWELL, I SEND ALPHA WHISKEY BRAVO, WHISKEY, ROMEO WHISKEY – BREAK” ..”UNIFORM WHISKEY PAPA, WHISKEY TANGO WHISKEY – BREAK”.. “INDIA WHISKEY OSCAR, WHISKEY, NOVEMBER WHISKEY – BREAK”.. “SIERRA WHISKEY ALPHA, OSCAR, OVER”
Now for SnG let’s say Briggs missed the last two sets. Here’s what should happen:
“HOWELL, BRIGGS, SEND ALL AFTER NOVEMBER WHISKEY OVER”
Howell would send:
“BRIGGS, HOWELL I SEND SIERRA WHISKEY ALPHA, OSCAR, OVER”
“HOWELL, BRIGGS, ROGER OUT”.
An “ALL BEFORE” request would be structured in the a very similar manner.
Now it’s not a good idea to throw messages in a straight line like I did – I got a bit lazy making that example and all those Whiskey lines would make breaking the cipher easier. If you scramble those words all over the matrix it’ll take the threat some serious time or a compromised cipher to figure it out. Also I didn’t invent the ten letter non-repeating Cipher technique – I’ve seen a lot of different forms of it over the years. I’m sure there are some other examples on the net as well
So how do we protect our cipher. My suggestion is to have one location (maybe the NCS) develop it daily and distribute it via sneakernet every day prior to the noon switchover with it going into effect at noon right along with the new freqs. To get the new one the old one has to be surrendered. It’s also a damn good idea to track how many go out, how many come in, and who lost their copy (it will happen).
Be creative and come up with your own systems. Remember it has to be simple enough for folks to use it or else they’ll get sloppy and evolve it creating one helluva comms mess. Take into consideration who you are working with in your AO, who needs the cipher, and who’s going to administer it. A cipher is not something you can just float along – if you let it get sloppy IT WILL be compromised.
More on Tribal EEFI and OPSEC
During the entries on comms we briefly touched on two critical concepts: Operational Security (OPSEC) and the Essential Elements of Friendly Information. Techniques to control Spillage was also covered. During this entry we’ll look at how EEFI should flow within our AO – whether by comms or other means. For a quick recap let’s hit the simplified definitions of those terms again:
EEFI – Information about us that we don’t want outsiders to know.
OPSEC- Measures we take to protect EEFI.
Spillage – a loss of OPSEC that allows EEFI to be revealed to outsiders.
Notice I didn’t use the term threat this time instead substituting it for the word outsiders? Why? In the simplest terms there are different levels of EEFI and there might often be information that we don’t want others that are not threat to know – more on that later.
Please take a moment to look at the diagram below as I’m going to refer to it frequently during this entry.
What I’ve done is identified four very basic levels of information awareness (who knows what). Those levels are Family, Tribe, Other Friendly Tribes (and other entities) and the Rest of the World. Those are pretty straightforward categories and you may have more. I’m going to work through these four categories and give some examples of what I consider information that should be held at which level.
I’ve arranged this little diagram from the center outwards to depict the level of information sharing with what I consider the most shared info at the center and the least at the outside. The critical concept I want to depict is that as a general rule any EEFI either generated or relevant information at any given level should never flow outwards – only inwards (there are instances where there’s probably going to have to be a few exceptions – as stated below). Not only that but the fidelity of the information might change as it drills down towards the center. Also note this diagram represents only the view for a single family. There should be multiple family boxes inside the tribe box and possibly multiple tribe boxes inside the friendly tribes box.
So what kind of info are we considering at any given level? Honestly that’s for you to decide. I feel it’s fairly dependent of how your family and tribe interacts. At a minimum I suggest you keep anything specifically relating to family and preparedness (food, fuel, stock, GnA, etc.) inside that family box. There’s going to be instances where you’ll probably have to share some of your family info with the Tribe – try to filter it if at all possible (that’s an exception to our general rule). As an example specifically at the tribe level if a family is suffering from a food shortage that information might have to be brought up to the tribe level of sharing. The fidelity and level of of that information is based wholly on your tribe dynamic (how you interact). Is there a requirement for everyone at the Tribe level to know that information? Probably not. It’s generally a good idea that once information flows outward it’s in a controlled as possible manner with as few folks knowing it as possible – and even then the fidelity of the information pertaining to the issue should be contained to those with a “need-to know”. This is an example of a necessary controlled spillage.
Referring back to our diagram there’s another point to be made – information sharing about the next outside level increases as you move outward on the diagram – i.e. as much possible information about the Rest of the World should probably be shared freely with Other Friendly Tribes and entities.
Now let’s focus down to the tribe level and complicate things a bit. Bonds between some families within your tribe will no doubt be stronger than others. It could be due to marriage (Bill’s son David married Joe’s daughter Gail), familiarity, proximity, etc. So it’s safe to assume a greater level of information sharing at a more intimate level between those families than they and other families within the Tribe.
On to addressing the substitution of “Threat” with “Outsiders”. IMHO at any given point after SHTF people and organizations as a group will evolve. For example – let’s say the tribe down the road is friendly one week after things go to hell. Two months later they are running out of food and you have plenty. If they are aware of it and hit your tribe up and you all decide not to assist then that group most likely will move into Threat status – a threat that will become greater as it becomes more desperate. Same thing with the authorities. Immediately after STHF they may be attempting to assist whomever they can. Then perhaps they get the order to begin resettlement ops. I dunno about you but that just moved them from outsider to threat in my view. As stated it’s all dependent on your Tribal dynamic. That’s why I recommend little to no information sharing with “outsiders” - pretty much common sense.
BUT like everything else there may be an exception to the “outsiders rule”. Maybe Bills daughter married and is a member of another Tribe (in this case you’re dealing with an entity and not the whole Tribe) we mentioned and struggling. Bill is probably going to help her. This is an instance where retaining EEFI at the family level is critical. Let Bill help her but as a Tribe should you and yours? Once again it’s all dependent on your Tribal dynamic.
Another point I would like to bring up is sharing information about other Tribes and entities. Once again your call but I would hesitate to discuss information about another tribe with an outsider. Don’t endanger their well being unless they are hostile to you – you very well may need their cooperation later and if you sold them down the river they’ll just laugh at ya.
Regarding the difference between the “Other Tribes and Entities” and the “rest of the World”. Whom/what goes where? That once again is up to you and based on your current situation. It may evolve and elements will probably move in and out of those two categories. Expect proximity and that elements efforts or intentions to dictate a lot of that movement.
So how do we manage this? These are the takeaways that might help you get everyone in the same mindset:
1. Information about the family should stay at the family level unless it’s an emergency.
2. We don’t talk about anything relating to the Tribe to outsiders.
3. All information about “Outsiders” and “The Rest of the World” is shared freely within the tribe.
4. Information about other tribes and entities doesn’t get shared outside of the tribe.
5. Information about the rest of the world gets shared freely.
These are an example of some simple rules that can help keep your EEFI out of the wrong hands. Adapt it, evolve it, make it yours. Just realize one critical concept:
FAILURE TO CONTROL EEFI SPILLAGE BY FAILING TO IMPLEMENT OPSEC PUTS YOUR TRIBE (AND FAMILY) AT RISK.
No comments:
Post a Comment