Staying secure

Taken from Schneier on Security:

  1. Hide in the network. Implement hidden services. Use Tor to anonymize yourself. Yes, the NSA targets Tor users, but it’s work for them. The less obvious you are, the safer you are.
  2. Encrypt your communications. Use TLS. Use IPsec. Again, while it’s true that the NSA targets encrypted connections — and it may have explicit exploits against these protocols — you’re much better protected than if you communicate in the clear.
  3. Assume that while your computer can be compromised, it would take work and risk on the part of the NSA — so it probably isn’t. If you have something really important, use an air gap. Since I started working with the Snowden documents, I bought a new computer that has never been connected to the Internet. If I want to transfer a file, I encrypt the file on the secure computer and walk it over to my Internet computer, using a USB stick. To decrypt something, I reverse the process. This might not be bulletproof, but it’s pretty good.
  4. Be suspicious of commercial encryption software, especially from large vendors. My guess is that most encryption products from large US companies have NSA-friendly back doors, and many foreign ones probably do as well. It’s prudent to assume that foreign products also have foreign-installed backdoors. Closed-source software is easier for the NSA to backdoor than open-source software. Systems relying on master secrets are vulnerable to the NSA, through either legal or more clandestine means.
  5. Try to use public-domain encryption that has to be compatible with other implementations. For example, it’s harder for the NSA to backdoor TLS than BitLocker, because any vendor’s TLS has to be compatible with every other vendor’s TLS, while BitLocker only has to be compatible with itself, giving the NSA a lot more freedom to make changes. And because BitLocker is proprietary, it’s far less likely those changes will be discovered. Prefer symmetric cryptography over public-key cryptography. Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can.

If you haven’t already read the full post, you should.

New one, 3V8BB!

It is surprising how a simple piece of card can make one smile.

I arrived home from work this evening to find an envelope with a hand written address waiting for me.  On opening it, this was the card inside. The card confirms that on the 27th of September, 2008 at 13:06 UTC, Fex (the operator at the time) and I had a brief communication on the 14Mhz band using the Radioteletype (RTTY) data mode.  I don’t use RTTY often, so it must have been during a contest.

Why did it make me smile?  well this is my first EVER confirmed contact with another Amateur Radio station in Tunisia.

 

Ocean to City

Conor, EI4JN asked me a few weeks ago if I would help him out at the Ocean to City , as he was doing safety boat and could do with an extra pair of hands.

Last Saturday was a fabulous day on the water. I thoroughly enjoyed it, though I was quite envious of the kayakers, they all seemed to be enjoying themselves immensely.

After the last competing boat passed our location, we motored up to the city and I started taking a few pictures again.  This family passed us heading downriver, the parents looked to be getting the most enjoyment from the spin.

Ocean to City from Eila Marie

Fingers crossed that that was not the full extent of summer 2013 in Ireland!

Mirabox Kernel update

So the background is that I have a lovely little unit called a Mirabox but I need to update the kernel on it.   I spent a good bit of time looking at various forums and eventually managed to piece together enough information to get a 3.9 kernel to boot for me.

First, I installed a cross compiler, then I built a kernel, with default options, like so.


PATH="/home/build/smile/armv7-marvell-linux-gnueabi/bin:$PATH" make ARCH=arm CROSS_COMPILE=arm-marvell-linux-gnueabi- mvebu_defconfig

PATH="/home/build/smile/armv7-marvell-linux-gnueabi/bin:$PATH" make ARCH=arm CROSS_COMPILE=arm-marvell-linux-gnueabi- zImage

PATH="/home/build/smile/armv7-marvell-linux-gnueabi/bin:$PATH" make ARCH=arm CROSS_COMPILE=arm-marvell-linux-gnueabi- armada-370-mirabox.dtb

cp arch/arm/boot/zImage zImage-with-dtb

cat arch/arm/boot/dts/armada-370-mirabox.dtb >> zImage-with-dtb

./scripts/mkuboot.sh -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n 'Linux-marvell' -d zImage-with-dtb uImage

This kernel booted, but could not find a root filesystem. After a spending a bit of time looking, I could not find a NAND driver, so I opted for a filesystem on MicroSD instead.

Next, I replaced the kernel configuration with the one in this post, and rebuilt it. While that was building, I followed the instructions in this post, to create the filesystem on a MicroSD card.

Finally, I dropped the uImage created above onto a tftp server, loaded it with

tftpboot 0x6400000 10.4.50.166:uImage
set bootargs 'console=ttyS0,115200 root=/dev/sdb2 rootwait'
bootm

and the result is a working system.

root@dreamplug-debian:~# cat /proc/version
Linux version 3.9.0 (root@ubuntu-smile-build) (gcc version 4.2.0 20070413 (prerelease) (CodeSourcery 2007q1-10. Marvell 2009q3-11 20090730)) #2 Fri May 3 15:27:05 IST 2013
root@dreamplug-debian:~#

A very satisfying way to finish up before a long weekend!

My received phonesat packets.

I was travelling with work most of last week, but set up my machine to see if it could receive AX.25 packets from and of the phonesat satellites (which have since de-orbited).

I was surprised to find these in my log when I got home
April 23rd:

1200mk: fm KJ6KRW-1 to CQ via TCPIP ctl UI pid=F0(Text) len 110 12:32:18
ÿ63$uc!<bY5l^lc=VB@*=$UTF1II3[bsRN#Y.Z2gks%/P#/@QBB0i \
\N!'pVc!(#KBzzzzzzzz!,,q[Ci:G.Ec5e;FD,5.@
1200mk: fm KJ6KRW-2 to CQ via TELEM ctl UI pid=F0(Text) len 161 12:35:40
ÿ5qjuM1K$e67WJJ/!*;TU:f^CP+D(TR!0REaSH12S!"T&n/J
1200mk: fm KJ6KRW-2 to CQ via TELEM ctl UI pid=F0(Text) len 186 14:04:41
ÿ5qjuL1K$e67YUmC!*;TU:f^CP+F4"f!0REaSH12S!"T&nfik7HU`uM""9LgtKV/\_ \
_!NgZ0$$$p<58LU+2f&Q+]BUjfK"_<7)l?Oj6ucc='X_AIM[\gZV7P5:QXgtFnd^K( \
@hIncI$`3+b+i^`_j+=O*\2JF9D7m#Q&$_[lH,]=6OKd'.2ZD?iU0ÿ

April 24th:

1200mk: fm KJ6KRW-2 to CQ via TELEM ctl UI pid=F0(Text) len 186 13:53:42
ÿ5qjuO2H!+97YUmC!*;TU:f^CP+F4"f!3u\,SH12S!"T&nOZ8[tU7mMI!>GZg:^,JP \
&ERJ!qB!Z.L;3chrqR,S]j-(S?E1-&kr.HR&?@8hKNdAYW'Nh]9p3&70r4^@NHF?1pMGWXm)_8NI&WN-1?c"<<Q6Di"BmcYt0X$/a[h@NoQd!!!!ÿ

I was quite surprised to receive them as my set-up is not all that good on UHF.

Kenwood TH-D72, Duracell vs Lithium.

In keeping in the battery longevity theme here and here, recently, Don, AB1PH posted to the Yahoo TH-D72 group about some testing he did with primary cell batteries in the BT-15 AAA Holder.  Don compared Everready Ultimate Lithium (L92) batteries, to Duracell Alkaline batteries.

His TH-D72A was set-up to broadcast its location every 3 minutes. The Duracell’s lasted approx. 1h 40 minutes, with the Lithium batteries lasting approximately 7h. By any standard, approximately 4-5 hours is an appreciable difference, in fact that is almost equivalent to the run time of the original battery pack. Sure, they are more expensive, but, I know which I’ll keep spare.

Wardriving and D-STAR Digital Data

I’m slowly working towards doing some experiments with mesh networking (OLSR) and Icom ID-1 D-star Radios in Digital Data mode.  I’ve been wondering what coverage I would (should) see from a vehicle, back to one of the locations where I have an ID-1 in a fixed location (thanks EI3JB/EI8JA).

I got back from a trip today, grabbed an ID-1, an Omni Antenna, Laptop, a short bash script I wrote to ping and record replies along with a GPS position, and an old GPS-18 puck.   All the nodes have fixed IP addresses so the script is quite simple, ping host A, if A replies within 2 seconds, record the next position output from the GPS, try the same with host B, loop forever, nothing fancy or terribly accurate.

As I only have two nodes set-up, and without much preparation (shutting down chatty applications), I persuaded SWMBO to do a short (war)drive, while I kept an eye on the laptop.

This first picture below shows (the red dots) the coverage from Nicky, EI3JB’s place (roughly at the 8 in the R708 closest to the top). Note the few packets recorded in Tramore, shortly after I left my own place.

The second is obviously from my place, as it is much more centred on Tramore.

Nothing really ground-breaking in either picture, but useful to help visualise potential coverage nonetheless. There is a huge black-spot on the section of road just leaving Tramore, as far as Ballykinsella (L4061 on the map).  This is of no surprise, as it is a tough location  for 430Mhz signals to get out of. What was surprising though is the packets received from EI3JBs location out in Tramore.

Next steps are to get EI8JA up and running, and complete a more thorough survey.

Now though, it is time for a beer!