Category: Uncategorized

  • case bitcoin hardware wallet

    Part of the reason why I pre-ordered a case hardware wallet, was probably that there is no good wallet software on ubuntu phone. But the case is way more secure than a software wallet on a phone. Roughly the same size of the smallest feature phone you can buy, it contains an eInk display, a camera, a GSM chip, a fingerprint reader and wireless charging. For improved security it makes use of Bitcoin’s multisig feature. One key is on the device and one on the case servers. The third key is used only to restore funds in case the device is lost or stolen. You can either leave it with a third party or manage it yourself. Of course I chose to manage it myself, after all BitCoin is about empowering people instead of depending on third parties. The server part allows to implement spending limits and maybe other validity checks in the future. The fingerprint is used to authenticate against the server.

    When the presale started in early May, the projected shipping date was end of summer. It was later fixed to September 21st. Because they found a problem with the uptate mechanism, they postponed the delivery. Communication suffered during this period. Everybody understands that this kind of problem can happen with such an early limited batch of a new class of product. But weekly updates would be very valuable in this situation to keep customers happy.

    November 20th the box was finally delivered. The packaging is not as nice as with the trezor, but I don’t mind. The contents are much more important than the box. Build quality looks good. When I read that it is charged wirelessly and has no connector, I assumed it would be water proof. That is definitely not the case, but wouldn’t be too hard to achieve as it looks. It has tiny gaps around the fingerprint reader and the camera where water and dust can enter. The buttons are from the same film that covers the screen.

    The setup process looks simple. You scan a qrcode from the website and your xpub for the 3rd key. Then you register your fingerprint by swiping it ten times. I was warned that it had to be at the right speed and angle. My first two tries were misreads, but after that I had only two more in total. It is easy to get right. The bigger problems were the server error messages that I got ten times in a row. Maybe the server had too much load. When I tried it again after waiting for an hour, it succeeded the first time.

    Updating the firmware is a breeze, and worked like a charm the first time I tried.

    Sending and receiving BitCoins couldn’t be easier and works very well. The connection can take a moment sometimes, but I think they are working on improving this aspect. Although I can’t tell for sure, but I had the impression it improved already with the first firmware upgrade. Specifically, I could now see the bars of the GSM signal already while scanning the qrcode.

    What I miss is the current balance of the account.

    But what I miss even more is an option to set the transaction fees. MultiSig transactions are bigger than standard transactoin, and thus the transaction fee is naturally higher. But a standard transaction in electrum with the dynamic fees slider in the middle costs usually mBTC 0.05  ($ 0.02) @ 223 bytes. The three outgoing transactions I did so far with the case were not that much bigger at 372 bytes but carried a transaction fee of mBTC 4.43751 ($ 1.43). This is more than an order of magnitude too high, and there needs to be a way to adjust.
    Update: The fourth transaction with my case which I performed just an hour after writing this post, and the fifth the day after, had a regular transaction fee of mBTC 0.1 ($ 0.03).

    Of course the three keys of the multisig are not just three ordinary BitCoin addresses. On the transaction level they are, but they are part of three hierarchical deterministic wallets that are linked together just like multisig wallets in electrum. Thus I was releaved to see that it asked me for an xpub as my 3rd key, and I could happily use one from the Trezor. But so far I couldn’t figure out how to retrieve the xpub’s of the other two components. Once I get them I can setup a readonly multisig wallet in electrum to track the transactions and the current ballance. But even more importantly, I can then assign descriptions to the transaction in a familiar environment for my personal accounting.

    After the important issues above will be fixed, we can move to some wishes I would also have:

    It would be nice if I could use the case for a custom multisig scheme. With the xpub of a Trezor, a HW1 and the Case, I could set up a multisig wallet in electrum. With electrum I would construct the transaction, and partially sign it with the Trezor. Then I would display the partially signed tx with electrum on my computer screen. Case could scan it from there and add it’s signature to it. Then it would either display a qrcode with the signed transaction on its screen, or transmit it to the BitCoin network over GSM. Once this works, I could set up an electrum wallet with the same xpubs as used in normal case operation. This would give me peace of mind because it would allow me to access my funds even if case went out of business or decided to censor my payments for whatever reason.

    To improve privacy, it would be cool if I could run the server part on my own web server. This would require it to be open sourced, and a configuration option would have to be added to the firmware.

    Last but not least, an option to sweep paper wallets by scanning the private key would also be useful.

     

    case_bitcoin_hardware_wallet_box

  • let’s encrypt

    I never bought a commercial grade SSL certificate for my private website, but I used free ones before. Usually from startssl. While it worked, the process was cumbersome. And then when I wanted to renew, my browser showed a warning that their own certificate was out of order.

    When the letsencrypt initiative (supported by mozilla and the electronic frontier foundation) announced it’s goal to make website encryption easier available we all cheered. Last week I finally received an eMail stating my domain was readily white-listed in the beta program. So I took some time and followed their process. It was not always self explanatory, but the ncurses program offered some help. Within a couple of minutes, I had a certificate ready to use. The only thing I did not like, was that if the process transmitted my private key to the server, there was no way of noticing other than actually read the code. I don’t think it did, but I prefer to be certain about these things.

    To have my website protected, all I had to do was adding the file location that the utility program provided to the apache site configuration.

    Now the bigger work was moving everything to my new server and adapt all the URL’s. Moving the blog was already more work than I expected. It was not a simple export and import. First I had to get the wordpress importer plugin working. The media files are not included in the exported file, and have to be moved manually. Some older blog posts still referenced the old gallery which I wanted to replace with piwigo for a while. So in addition to moving the piwigo gallery, I also had to move lots of photos from the old gallery, and adjust the references in the blog.

    Some web apps are not moved yet and will follow. Finally I plan to redirect all http addresses to https.

    On the nice side, I could use the new certificate to secure my new email server. I can’t remember when was the first time, but about once every two years I attempted to set up my own email server in the past. Setting up a web server is much simpler. But with the mail servers there was always some problem left that left me not confident enough to really use it. But this time I found a good tutorial that actually worked. It’s geard towards a raspberrypi running raspbian, but worked just fine on my nuc running ubuntu.

  • an exact clock for a vintage car

    Since I drive my vintage XJS not too often, I disconnect the battery. This is to prevent if from going flat before I want to use it the next time. Of course it would be better to install a special charger for classic cars. But there is no outlet in the underground car park. The car starts when I want to use it, so one could say: mission accomplished. If only there was no clock in the dashboard.  It doesn’t run when the battery is disconnected. Having to adjust the clock every time is not the solution I was looking for.

    My first idea was to get a DFC77 radio clock with hands, and put it inside the case of the original dash clock. All the clocks that had hands were too big to fit into the case. So I ordered a small module with an LCD. The problem was that it had good reception at home, but not inside the car. The long waves seem to have a hard time penetrating the Faraday cage of the car body.

    The next option that delivers exact time over the air is GPS. So I ordered a cheap GPS receiver from China, and built a prototype with an AtMega microcontroller and a small OLED. The prototype kind of worked, but after the first drive, the GPS module failed completely. So I ordered a better one from an AdaFruit reseller in Switzerland. This module still works very well, but I found out the hard way that it needs a very clean power source. The next problem were random failures and reboots of the micro controller. This turned out to be caused by memory overruns. They are harder to detect on a micro controller  than on a regular computer. The display needs a framebuffer in RAM, and for the GPS I need enough space to store and parse the full NMEA sentences. I tried to reuse and re-initialize the same memory for every reading, but that didn’t work out. Neither didn’t I find a similar controller with more RAM. If I was going to produce a number of devices I would for sure use a better controller, but as it is a one off prototype, I just used two AtMegas. One for the display, and one for the GPS.

    GPS has no reception in tunnels and underground parking garages. So I planned to implement a simple counter that just increases the time when GPS reception was lost. But then I decided it was not important enough. Instead I wanted to proceed, and have the device ready in the car. But I couldn’t resist to display a leaper for when there is not reception.

    In a classic car, everything should be in original condition, so I didn’t want to destroy the original clock. Instead I was looking to buy a used clock that didn’t have to be in working condition. The ones I found in Switzerland were too pricey for only the case. So I found one on ebay for £22 that was shipped from the UK.

    The problem that remains is that the OLED sometimes initializes with a random dot pattern and stays that way until the next power cycle. It happened more when I had it connected directly to the main battery. But since I connected it the the dash back light, it never happened again. So maybe it is important how fast the voltage increases when power is switched on.

    As usual, the code is on github.

    image20150625_202655132 image20150625_201613328 IMG_2636 IMG_2638
  • the infinity mirror

    Lately while browsing through thinkgeek, I stumbled upon the infinite dungeon corridor. It looks cool, but they still have no affordable shipping options. That got me thinking that it should be possible to make an infinite mirror with the kids. It didn’t take long to find a recipe for how to go about it. Finding a mirror was easy, but regular window glass is a bit harder these days. The first try was with plexiglass that I had laying around. The effect was really bad, because it had a matt finish. When I asked for real glass, I got security glass. Trying to cut it to the right size, it disintegrated into a thousand tiny parts. So it was plexiglass again, this time with clear finish. I also was not sure about the window film. I bought the film that is used to taint the car windows. An LED stripe was readily available and waiting for a new purpose.

    The kids were involved in all construction steps. Cutting the wood for the case, drilling, screwing, sawing, cutting the mirror, tacking the LED stripe … But one thing was entirely up to them: Usually those infinite mirrors have the two windows relatively close. But to be in the style of the dungeon corridor, I created the case with some room where the kids could paint what should look like the walls of a castle.

    The effect is not as good as we would have liked it to be. I’m not sure if it is because of the plexiglass, the increased distance or the wrong type of window film. But it works, and was fun to construct. Most importantly the kids learned not just how to construct such a thing, but also about optical illusions, and how light behaves.

    IMG_2639 IMG_2647
  • Targeted advertising

    It was about two months ago when I first noticed an advertisement on some random web page that contained an image of a vintage Jaguar XJS. It was not exactly the same model as I have, but very close. Judging form the bumpers and trims it also seems to be a HE (High Efficiency), as the second series was called. But the wheels are different. The advertisement was for an online auction platform for cars. I immediately assumed it must me a targeted ad. I was impressed that they must be able to dynamically select the type of car they want to show. How many polished pictures would they have readily prepared?

    Last week, the same advertisement appeared in the printed edition of 20min, the largest free commuter newspaper in Switzerland. Now this could not be targeted any more…

    2015_09_20minRicardoXJSWerbung

  • ScroogeCoin

    After a long pause, I just started attending a MOOC again. It’s on Coursera, from Princeton and it’s about BitCoin. In one of the first lectures the teacher goes through some simple hypothetical digital coin concepts. I don’t know if the lectures are publicly available piecewise, but as a whole they are at youtube. Jump to minute 50 for scroogecoin.

    Name property problem
    GoofyCoin signed receipts double spend
    ScroogeCoin centralized blocks corruption
    BitCoin fully decentralized solved

     

    ScroogeCoin reminds me a lot of the blockchain projects a lot of big financial institutions announced over the last few months. They talk about permissioned blockchains. That sounds like exclusive access and centralized control. BitCoins inclusiveness is one of the important characteristics, and I hope enough people recognise it as such.

    BlockChain

  • When VISA doesn’t work

    I used to order stuff from dealextreme on a regular basis over the last few years. Like many other customers I asked them to accept BitCoin payments. But that didn’t happen so far. So we are left with the payment options from the last century for the time being. It used to work acceptably so far … until about a month ago, when my payments suddenly started being declined. The same VISA debit card used to work with dx before, and it remains working with other merchants. Of course I checked the balance. I dont keep much more on that account than I expect to need in the short term. But $250 should suffice for a $200 order, so the problem has to be somewhere else.

    Dx states it on their page unmistakeably that all payment problems are not their fault, and that people should consult with their issuing bank. So I contacted them first. They couldn’t find anything about the declines in their logs:

    There are no transaction attempts on your card for the merchant
    https://eud.dx.com, not on July 27th or after.
    In those days I can see transactions at merchants X, Y, Z - which all
    look like they are still pending and waiting to be completed
    (a few months ago we updated our payment processing system to
    adhere to settlement standards).
    
    For some reason it looks like the payment authorization never reached Us..
    When a payment takes place (when you use your card), what happens
    first is that the merchant informs Visa, Visa then informs our card
    issuer, and the card issuer informs us about a new transaction on
    your card. We then hold the corresponding funds from your wallet.
    Then a few days later, the merchant settles the transaction
    (ie. broadcasts to the network whether the transaction was
    completed or not), and we use that information to complete your
    transaction. What is strange is that the authorization for your
    purchase at https://eud.dx.com either never reached Us, or never
    left the merchant's system.
    
    Because you've been able to use your card in the past few days,
    I'll dare to say that there's nothing wrong with your card - rather
    it seems like a glitch with this particular merchant.
    
    

    So I asked the card processing intermediary. They had no means of secure communication. I found it hard to believe that a financial institution can only communicate with their customers over unencrypted cleartext eMail.  However, I got similar results:

    Please be informed that we could not find any decline on your card at our end,
    which means it could be an issue with merchant end.
    We request you to check with the merchant regarding this.

    Finally I went back to dx and got this answer:

    sorry for that.
    but our related staff told us your bank reject the payment.
    that is not our problem.

    From all I learned so far, it seems like VISA is the problem here. But I don’t have a contact or a direct relationship with VISA. It is routed over shady ways through an unknown number of intermediaries. The best explanation that I can come up with is that the transactions triggered some kind of fraud alert and were thus blocked. Is that how they deal with the lack of a secure system? They just randomly block transactions! With no way of recurse, such false positives are really annoying for their customers.

    So what do I learn from this? When there are too many intermediaries in the loop, there are more chances for errors and errors are harder to find, let alone fix. With BitCoin, there are no middlemen and a lot less things that could go wrong. I have been using BitCoin whenever possible for the last four years. Nothing alike ever happened with BitCoin, in fact this would be unimaginable with a peer to peer blockchain system. I’m really looking forward to leave all those ancient  payment methods behind…

    Ironically, I read this story the same day I got the last answer from dx.

  • Verifying downloads

    Last week I stumbled across a post from last year, where somebody described how it was impossible to download an important infrastructure program securely on Windows. My first reaction was of course to pity the poor souls that are still stuck with Windows. How easy is it to just type apt-get install and have all the downloading and validation and installation conveniently handled for you.

    Today I was going to set up my new server. First I downloaded the current iso file from ubuntu.com. Before installing it onto an USB stick, I thought about this blog post again. Actually I should validate this ISO! I knew before, but I usually didn’t bother. So I gave it a try. I had to search a bit for it on the download page. The easiest is if you manually pick a mirror. Then you will find the hash sum files in the index page. Some websites along the way were encrypted, others were not. The downloads themselves were not. But that didn’t matter since the hashes were GPG signed. I don’t have to do this all too often, so I  just followed the community howto. My downloaded iso file was valid, so I moved on installing it.

    The hardware is actually from computer-discount.ch. For quite some time I was searching for ways to buy computer equipment with BitCoin. The American big name tech companies that accept BitCoin either do it only outside of central Europe, or don’t deliver here. So I was quite excited to find this company from Ticino. The experience so far is very good.

  • How much luggage fits into a vintage grand tourer?

    Our camper has an engine problem, so we had to look for alternatives for this years summer holiday. We looked at last minute offers, but bringing all our own food to Greece didn’t seem like such a good plan. The kids wanted to sleep in a tent anyway, so we went to Tenero in the Italian speaking part of Switzerland. We were too hesitant to look for a camp in Italy after spending a night on a horribly disgusting camping in Porlezza a few years ago. With the camper, the space for luggage was never really a problem, but this time everything had to fit inside the Jag. I told my wive to pack only the most necessary things. Men and wimen have different standards as to what is important to bring on a holiday and so I ended up squeezing all this into the small car:

    • two adults and two children
    • a four person tent
    • a foldable camping table with seats
    • a foldable camping grill
    • sleeping bags and camping mattresses for all of us
    • a giant and a regular suitcase
    • four small backpacks and a regular sports bag
    • a small body surf board
    • a box with dishes and cutlery
    • ten liters of water and a bag with food
    →

    This was actually the first holiday in 13 years where I didn’t bring my paraglider. But  after the impressive list above, there was just no more room left in the car.

    The camping in Tenero was great. It was clean by my wive’s standard which is quite an accomplishment. The camping has a sandy beach to the lake which was also clean and had perfect temperature.

    Being so close to the famous hydroelectric dam where James Bond jumped from, we had to visit the Verzasca valley. The water and the stones were marvellous. But it was very hot for hiking.

  • connecting home securely

    It has been probably close to a decade that I run a small server at home. At first it was only because I could not find a web hosting company that would serve my fcgi libwt apps at an affordable price. Then I added this blog to it. In the meantime I added a lot of other stuff as well. One of the more important things became ssh. Not only for remote shell sessions, but also for securely copying files and tunneling. In fact I use ssh tunnels instead of a more traditional VPN.

    Discovery

    Static IP addresses are expensive in Switzerland. So I used dyndns from the start. At first the free offering, and then switched to a paid plan long before they discontinued the free offering. Just last week I received a note that they grabed the annual fee from my (scheduled to be deactivated) credit card. Generally I strongly dislike services that automatically grab money from my accounts. They didn’t even mention that the fee doubled. That’s one side of the story, the other is that dyndns is an American company. They could take my domain name hostage without even telling me.  So there has to be a better alternative. In fact there is one. It’s good technology wise, but not generally available to the unintroduced yet.

    DyName for namecoin

    I wrote about namecoin in a previous blog post. One of its main uses is a censorship resistant domain name registration. And the simple python script from DyName is to namecoin what dyndns and ddclient are to traditional domain names. Just prepare your registered name to include a dd entry, edit your config file, and call the script periodically from cron. That way you separate the private key where your name is registered from the hot wallet on the server. My provider used to reassign new ip addresses more frequently, now it’s about once every two months I would guess. The transition with namecoin was very smooth the last two times. I have a script that queries namecoin for the current ip address and then connects. There are dns resolvers and browser plugins or even public dns servers that would resolve namecoin domains. My experience with them was not as smooth as with the namecoin core itself. But I’m sure these parts will improve as well. So, with namecoin we have high confidence, that the ip address is correct that we are connecting to, but it can’t protect against man in the middle attacks. SSH has means to protect from that. The ssh client has a list of known ip addresses or host names and corresponding key fingerprints. But after an ip address change, there is no entry for the new destination, so ssh prints an error message and refuses to connect until you accept to add a new entry to your known_hosts file.

    ssh known hosts

    When you search for the error with your preferred search engine, you’ll find advices to delete offending lines in your known_hosts file. This of course is not what we need here. Just accepting to add a new entry the next time you connect would circumvent the protection against MITM that ssh provides. Since we already have the key fingerprint from the previous address, there is another more secure solution. If you have only one entry in your known_hosts file, you can skip the next few lines. Maybe you know which fingerprint is valid, for example because the file already contains a couple of lines with the same key fingerprint because the ip address changed a couple of times, and you just accepted it.

    If you are not sure, which fingerprint you need, ask the server what it provides:

    $ ssh-keyscan 85.3.164.135
    # 85.3.164.135 SSH-2.0-OpenSSH_6.7p1 Ubuntu-5ubuntu1
    85.3.164.135 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBE7WE5vtqSxUnQRX5CjOzEzUAdewqHRV5MXcSCQcylcKanpnDHRE4yVlEn770MFP6EfJ61ukdNYMDnSO9eoRiZY=

    Now search for this fingerprint in your known_hosts file, and copy the whole line. On the new line, you replace the first hash with the actual new ip address in clear text. You could leave it like that, but you can also hash it with the following command.

    $ ssh-keygen -H -f ~/.ssh/known_hosts

    After writing all this I started wondering if it would be possible to keep the host key on an external hardware device like a NitroKey or a YubiKey. I already keep my client key for authenticating to the ssh server on one of these.  That’s something to find out in a future post maybe.