Howto: Install GPG on Jolla Sailfish OS

July 29, 2015 Davi Ottenheimer Leave a comment

A Finnish start-up, Jolla, announced at the end of 2013 that it was producing a free and open source Sailfish OS, with an open hardware smart phone.

Here is a quick three-step guide to getting GPG installed.

STEP 1) install pinentry

You have three options:

compile from source
install pinentry-0.8.3-1.armv7hl.rpm
use warehouse app to search for “pinentry” in OpenRepos, add “veskuh” repository and install gnupg-pinentry

STEP 2) open the terminal and install the GnuPG software

[nemo@Jolla ~]$ pkcon install gnupg2

Currently this installs version 2.0.4 with a home of ~/.gnupg

Supported algorithms:

STEP 3) use the terminal to create a key

[nemo@Jolla ~]$ gpg2 –gen-key

Please select what kind of key you want:
   (1) DSA and Elgamal (default)
   (2) DSA (sign only)
   (5) RSA (sign only)
Your selection? [Enter]
DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) [Enter]
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) [Enter]
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the 
user ID from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) "
Real name: Davi Ottenheimer
Email address: davi@flyingpenguin.com
Comment:[Enter]
You selected this USER-ID:
    "Davi Ottenheimer davi@flyingpenguin.com"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x Enter passphrase                            x
x                                             x
x                                             x
x Passphrase _***********_____________________x
x                                             x
x       OK           Cancel                   x
lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

gpg: key XXXXXXXX marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub 1024D/XXXXXXXX 2015-07-29
Key fingerprint = XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
uid Davi Ottenheimer davi@flyingpenguin.com
sub 2048g/YYYYYYYY 2015-07-29

STEP 3.5) verify key

[nemo@Jolla ~]$ gpg2 -k

/home/nemo/.gnupg/pubring.gpg
-----------------------------
pub 1024D/XXXXXXXX 2015-07-29
uid Davi Ottenheimer davi@flyingpenguin.com
sub 2048g/YYYYYYYY 2015-07-29

NOTE: you may want to move and keep your secret key on a removable storage card

History, Security

We Need a Digital Right to Repair

July 27, 2015 Davi Ottenheimer 1 Comment

Dan Lyke asked me a good question today, in response to my Jeep of Death blog post and tweets about patching:

So yay for sharing, but we shouldn’t normalize getting your car patches from random Internet users.

On the one hand it would be easy to agree with Dan’s point. Randomness sounds scary and untrustworthy.

On the other hand, reality says doing safe business with random people might be a reasonable and normal state of affairs. I mean imagine getting a car chip update from a random vendor, or a part to fix your suspension or brakes. Imagine getting fuel from a random vendor.

Can trust or standards of care be established to allow randomness? Yes, obviously. Hello FTC.

My response to Dan was more brief than that response, because, well, Twitter:

why not? we get other “after market” fixes for cars all the time

This does not convince Dan, unfortunately. He asks an even scarier question:

would you run random executables emailed to you by internet strangers? On your car?

I try to explain again what I said before, that we enjoy a market full of randomness that our cars execute already (e.g. gasoline, diesel…steam, vegetable oil). And that is a good thing.

YES. because i have a digital right to repair, i would. i have been doing this on my diesel chip and motorcycles for a decade.

As far as I can tell Ducati was the first to allow after-market software patches on their engines, more than fifteen years ago. I owned a 2001 motorcycle that certainly allowed for it as I patched the ECU about every year, always after-market and sometimes with a random mechanic.

The idea that we should allow any patching process to be wholly controlled by vendors and not at all by consumers or independent mechanics sounds to me like a very dangerous imbalance.

Allow me to explain in more than 140 characters:

Having the right to repair is actually an ancient fight. Anyone familiar with American political history knows horror stories about Standard Oil, Ma’ Bell, let alone GM and Ford; monopolies that have tried to shut-down innovators. Or maybe I should invoke the angry Bill Gate’s hate letter to hobbyists?

Lessons learned from history can be plenty relevant to today’s dilemmas. Consider for example the Right to Repair legislation, that that I last blogged about in 2005, pushed by the late great Senator Wellstone.

The argument made in 2001 by Senator Wellstone was manufacturers established “unfair monopoly” by locking away essential repair information, which prohibited independent mechanics from working on cars.

Wellstone’s ‘Motor Vehicle Owners’ Right to Repair Act’ Gives Vehicle Owners the Right to Choose Where, How and by Whom To Have Repairs and Parts of Their Choice. […] This legislation allows the vehicle owners — and not the car manufacturers — to own the repair and parts information on their personal property, this time their vehicles. It simply allows motoring consumers to have the ability to choose where, how and by whom to have their vehicles repaired and to choose the replacement parts of their choice — even to work on their own vehicles if they choose.

Opposition to the legislation was not only from the big companies that would have to share information with customers. Some outside the companies also argued against transparency and self (or at least independent) services. Believe it or not, for years statements were being made about protecting “high-tech” car security (e.g. passive anti-theft devices such as smart-key and engine immobilizer) with obfuscation.

Of course we know obfuscation to be a weak argument in information security, right? Put recent news about electronic key thieves in perspective of ConsumerReports arguing in the mid 2000s that obfuscation of key technology would better protect consumers from threats…

Well the fight against consumer right to repair cars dragged on and on until Massachusetts politicians broke through the nonsense in 2012 and passed H. 4362, a Right to Repair, which was seen as a compromise that car manufacturers could swallow.

Nearly thirteen years after Wellstone introduced his bill, an important federal step was taken towards normalizing random patches.

The long fight over “right to repair” seems to be nearing an end.

For more than a decade, independent car repair chains such as Jiffy Lube and parts retailers such as AutoZone have been lobbying for laws that would give them standardized access to the diagnostic tools that automakers give their franchised dealers.

Automakers have resisted, citing the cost of software changes required to make the information more accessible.

It was because of a mostly external benefit (consumers), with mostly internal cost (automakers), that regulators had to step in to balance the economics of repair information access. Wellstone was wise to recognize consumer safety from access to information, lower-cost and faster repairs to things they own, could be more beneficial to the auto industry than higher margins.

I attempted to translate this political theory into today’s terms by Tweeting at people for a Digital Right to Repair on Android phones.

Perhaps I see the parallels today because I ran security programs at Yahoo! for mobile a decade ago and noticed parallels back then.

Phone manufacturers were slow to push security updates. Consumers were slow to pull updates. It seemed, from a cost-effective risk management view, that allowing Right to Repair to hundreds of millions of consumers we essentially would grease the wheels of progress and improvements. We anticipated patches would roll sooner and where innovation was available, because knowledge.

In other words rules that prevented understanding internals of devices also stalled understanding how to repair. To me that is a very serious security calculation.

What industry needs to discuss specifically is whether the rules to prevent understanding will unreasonably prevent safety protections from forming. Withholding information may push consumers unwittingly into an expensive and dangerous risk scenario that easily could have been avoided. Who should be held responsible when that happens?

Looking forward, the economics of IoT patching (i.e. trillions of devices needing triage) begs why not enhance sharing to leverage local resources for partnership and innovations in self-defense. As we move towards more devices needing repair, I certainly hope we do not lose sight of Wellstone’s legacy and the lessons his Act has taught us.

Security

Jeep WordPress Edition

July 25, 2015 Davi Ottenheimer Leave a comment

Jeep unveils WordPress Edition for DevOps market segment “ready for Internet adventure”

The 2015 Jeep WordPress exemplifies Jeep on-line capability with a distinctive, aggressive shell, backed up by Jeep Internet Rated software, resulting in the most capable mid-size thing in the new you-have-to-be-crazy-to-connect-to-a-network devops automobile segment. The Jeep WordPress includes aggressive service and connectivity options, complements of the unique clear-text lua scripts, one-time factory install, Jeep on-line single-user unlocked file system, logs disabled and signature open USB ports. The unlocked file system is easily configurable with no integrity, but will apply access controls automatically when in certain modes, such as “OMFG,” to maximize on-line on-road threat interactions for the devop that can handle it. Comes with “Freedom isn’t DOM” sticker.

So much cyber. Patching cyber instructions for this cyber truck cyber already cyber are cyber available.

Security

Jeep Software Patching: You and UConnect

July 25, 2015 Davi Ottenheimer 3 Comments

Lately I have heard people complaining about their friends and family who can not or will not patch the Jeep software.

I suspect the more people that look at the process for patching Jeeps the more the process will improve and increase the likelihood of patching. So here are a few quick steps that might be helpful.

First

You need a Vehicle Identification Number (VIN). You can ask your friends or family for their VIN. You can walk into a parking lot, especially a Jeep dealer’s, and look at the VIN. Or you can search craigslist for a VIN. I used the SF bay area site but you can search anywhere using a simple URL modification:

https://sfbay.craigslist.org/search/cta?sort=rel&min_auto_year=2014&query=jeep

Mine brought up a good candidate to check almost immediately, and you can see the VIN (1C4RJFJT9EC145897) right at the top:

Second

Copy the VIN number and enter it into the Uconnect Software Update page. If the vehicle with the VIN you found needs an update, you will see the success window:

Speaking of vulnerabilities and missing patches, you probably will have to use IE. Chrome errors out and UConnect is up front about the fact it does not support Firefox after version 37 (current Firefox is 39).

You also should note that attempting to use HTTPS reveals UConnect has an horribly insecure setup — a mis-configured service far behind on critical fixes.

I believe I was the first person to point the UConnect flaws out but again this whole process really should be something many people are assessing on a frequent basis. POODLE vulnerability shouldn’t have to be “discovered” by me months after it was announced.

Anyone else find a big red F for car manufacturer site safety less than confidence inspiring? I really should insert a graphic here of a crash-test-dummy flying out the window…

Third

Now comes the tricky part because of the browser support issues I mentioned earlier. UConnect tries to force you into using a convoluted and slow graphical process to reach the update file.

UConnect seems to want to make some sort of case to install Akamai software before you can download the patch. Someone must have thought that is a good way to deal with a rush by 1 million owners suddenly trying to grab a 380MB file. In reality that is nothing compared to the number of people downloading larger files (e.g. movies) all the time through caching services invisible and compatible with any browser.

The Akamai client really doesn’t make any sense and just slows down the process so I avoided it by downloading from Microsoft a virtual machine running IE (e.g. Windows7 with IE 10 is a 3.5GB VM) and clicking through the UConnect “Tutorial” pages quickly until I was able to get to the end. That is where a direct download link finally appeared.

When I tried first with Chrome I was greeted with this warning:

IMPORTANT: The Akamai NetSession Interface is not compatible with your current browser. You can download software updates by clicking the direct download link for each available update.

And then, instead of any direct download link at the end of a bunch of clicks, Chrome fails with this warning:

An unexpected error has occurred. Please try refreshing your browser and entering your VIN again. If the issue persists, please contact UConnect customer care center at 1-877-855-8400, and press # to reach a customer support technical specialist. Canadian residents , call 1-800-465-2001 (English) or 1-800-387-9983 (French).

It probably would save a lot of time if UConnect just said at the start IE is the only supported browser; because really the UConnect site is designed only to work with old insecure versions of IE.

I was basically wasting time trying to get safer and newer browsers to work with the interface. Chrome stalls out at the end and Firefox doesn’t even get off the ground. If you try curl/wget…LOL

Anyway, back to trying to actually get a patch, IE reveals a fancy button graphic as well as an actual link to an actual file.

Fourth

After all that wasted time trying to get through the UConnect web interface quagmire, I finally clicked on a link. Notice at the bottom left of the page a tiny URL reveals a token has been generated:

http://rsur.download.chrysler.com/1152/MY13_MY14_RA3_15_26_1.exe?__gda__=
1437511101_4a9001e63d28e5ce6214cf728ab5fbf7&filext=.exe

This URL can be copied from IE into Firefox or Chrome and the download works fine. And the token seems to expire so you can’t use the same one I generated. I would have to post the file for you to download from a file sharing site instead of just giving you the authoritative source.

It all really begs the question of why there is so much fluff, obfuscation, client software and tutorials instead of a simple download link via an invisible caching service compatible with everything.

Fifth

Once the 390MB “MY13_MY14_RA3_15_26_1.exe” file is downloaded you may notice it is just a 7zip self-extracting archive. So use 7zip to unpack the archive and you have a 580MB “swdl.iso” file. Simply use 7zip again to extract the iso. This results in a manifest file from June 23, 2015 and four folders:

At this point you’re in the position to post the ISO to a file sharing site and invite people on a Jeep owners forum to install it from your source. Apparently that is already happening, which is easy to understand given how painful it is for owners to go through the above process.

Or you can read the files and learn more about how to help your friends and family stay safe.

For example, use a text editor to open the manifest file and scroll to the bottom. Here you should see options that indicate you can set the patch to autoupdate (no human intervention):

reset = “bolo”, — what type of reset is required
autoupdate = false, — automatically invoke the update (no HMI needed)

As another example, navigate to the usr/share/SKINS/ directory and you can find the “swf” (flash) themes available:

Abarth, AlfaRomeo, Chrysler, Dodge, Ferrari, Fiat, Jeep, Lancia, Maserati, Ram, SRT, Viper

Or move deeper into usr/share/SKINS/fontSwfs and read the file called “EVALUATION USE LICENSE AGREEMENT.doc”

1. You may install and use the bitmap fonts contained within the Evaluation Font (“Fonts”) internally for the sole purpose of evaluating the functionality of MONOTYPE products.
2. You may not rent, lease, distribute or sublicense the Fonts without first obtaining a written license from Monotype Corporation.

We have to assume a written license was obtained, while leaving the evaluation license anyway. Maybe Monotype requires the eval license to ship with the fonts? Still I feel like I have opened the hood of a car and found foam packing material that was meant to be removed.

Have a look into /usr/share where you will find “install.sh” with some interesting commands and comments

# File must be less than 2K bytes for security reasons!

What happens if the file grows larger?

I found a few network scripts yet none that offered firewall or service port options. “STATIC_IP=192.168.57.99” shows up in a template while “STATIC_IP=192.168.6.1” is in a shell script.

And I found a spelling error. This is Line 13 of network.sh:

echo “mouting desktop…..”

A peek into /usr/share/scripts/update/installer will bring you to a compiled “system_module_check.lua” file that the car trusts to help prevent the wrong update being used.

It’s trivial to decompile lua and look closer. Grab the latest unluac.jar file and run it against the file you want to read. For example:

java -jar unluac_2015_06_13.jar system_module_check.lua > decompiled.lua

With this you can read the error levels and checks in the new decompiled.lua file

L8_9 = “Model Year Not set in ISO”

Also have a look into /usr/share/MMC_IFS_EXTENSION/bin because this is where you find more scripts and binaries of interest. Here is the check_temperature.lua:

require "service" resp,err = service.invoke("com.harman.service.OmapTempService", "getOmapTemperature", {} ) if (err == nil) and (resp.omapTemp ~= nil) then -- print("Temperature is ", resp.omapTemp) if(resp.omapTemp > -20) then
os.exit(0) — temperature is acceptable
else
os.exit(-1) — temperature is NOT acceptable
end
end

Temperature “NOT acceptable” level seems like something that should not be easily modified. The obvious question I have with these files:

Is Chrysler ok with people editing/improving the files and delivering their own patch to the Jeep community (as already may be happening), to encourage after-market service and support options? Could we reasonably expect independent auto mechanics to also fix code?

Conclusion

I found this five-step process of getting a patch unnecessarily complicated. A download link should not be so obscure to find and incompatible with the latest/safest browsers. ~~Also I found the patch strangely lacking integrity protections.~~ And so you may want to consider the details of this patching process and have a closer look in order to help friends and family update their software and stay safe.

Updated to Note: Good news! Earlier one of my big questions, as I had wondered aloud, was whether an algorithmic method was used to verify the ISO file. I found the answer is yes, by looking in /usr/share/scripts/update/isochk.lua

openssl rsautl -verify -inkey /etc/keys/swdl.pub -in /tmp/a -pubin -out /tmp/b
hashFile sha256 /fs/usb0/swdl.iso /tmp/c

a blog about the poetry of information security, since 1995