3D Robotics


Go Randy! (Japan Drones is a 3DR affiliate and Randy is the lead on the ArduCopter project)

From a press release from Guardtime today:

Guardtime Partners With Japan Drones Delivering Keyless Signature Infrastructure for Drone Security


Tokyo | Palo Alto – Mar 25, 2013 – Guardtime, the leading provider of Keyless Signature Infrastructure (KSI) technology for the authentication of electronic data, today announced it is partnering with Japan Drones, the leading developer of custom software for miniature Unmanned Aerial Vehicles (UAVs) selling into the Japanese market. Keyless Signatures provide proof of signing time, signing entity and data authentication while the verification of the signature can be done offline without reliance on keys, secrets, or the existence of a trusted third party.

Ensuring the absence of malware and confidence over the integrity and authenticity of software on UAVs is an absolute must. CEO Randy Mackay of Japan Drones said, “By using keyless signatures to sign source code stored in Github, but also access logs and compiled binaries, we have a completely mathematical and independent audit trail over the provenance of electronic data executing on our UAVs as well as the real time video and telemetry data that is being recorded.” “Guardtime’s KSI technology is completely unique in that there are no keys to be compromised, thereby vastly simplifying the cost and complexity relative to using key based cryptography,” added Mackay.

“The threat of malware is a huge issue for drone manufacturers and operators,” said Mike Gault, Guardtime CEO. “Being able to have mathematical certainty over the integrity and authenticity of executing software is a major step forward. With KSI it is possible to verify the provenance of the executable binaries independently from any human being.”

Ahto Buldas, Guardtime Chief Scientist, said: “Guardtime is thrilled to be partnering with Japan Drones and seeing KSI being used for such an important application. Recent events have shown that quantum computing is becoming a reality and the need for post-quantum cryptography such as KSI is clear.”

Most recently, Guardtime announced a partnership with the Estonian Government for securing records in select state registries. Guardtime also announced a partnership with the Philippines Government to validate physical document integrity and with China Telecom, the largest fixed line telecommunications service provider in the People’s Republic of China, establishing China Telecom as a Keyless Signature service provider via its Tianyi 3G platform.

About Japan Drones
Japan Drones (www.japandrones.com) specializes in custom software development for miniature UAVs primarily for the Japanese Market with applications including volcano research and surveying. Japan Drones CEO Randy Mackay is an executive board member of the Mini-Surveyor Consortium, which aims to complete development of a commercial use, safe and dependable multicopter platform for Japan within two years.

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • With Pat Hickey doing the same thing, it's obviously 1 part of UAV design which people can turn into a day job.

  • If anyone is interested, it is possible to implement truly secure encryption on even the weakest MCUs, (See http://ww1.microchip.com/downloads/en/AppNotes/00953a.pdf.) Although as the above example indicates, it is best undertaken by experts, and even then it sometimes goes wrong.

  • Maybe the one thing that Guardtime does actually provide is a third-party-verifiable timestamp, which is something that PKI lacks; although I can't imagine any possible application for timestamping that would be OK accepting the word of a black-box Estonian internet startup.

  • What a load of nonsense.  does no one with any sense read these stories before posting? 

  • MR60

    Agree with Jonathan. to say any encryption or PKI technology is "keyless" is like saying the ocean do not contain water. They cnofuse keyless with the fact the the private key needed to hash or encrypt the source code must not be transfered to a recipient who must validate this hash or encrypted source code. Either the recipient has the corresponding public key (which he can have because it is public), either a web service is used (the server of this web service should have a HSM to protect the private key, otherwise it is useless) to validate the hash.

    Further if they do not use a certificate authority (like a globalsign or a verisign for example) to have a verification of the identity (registration procedure) of the entity requesting a certificate, then a hacker might reproduce a perfectly valid modified source code with a valid corresponding hash and a valid OCSP/CRL response. He would just impersonate the original develop's identity.


    And further even more, if timestamp is used as a NTP server function, or a sync with an atomic clock, this is also useless. A true timestamp is a signed proof of a date/time by a certificate authority. And this timestamp must be integral part of the signature (because we do not care of the validity of a hash at the moment it is verified, we care about the validity of the source code at the moment it was released)


  • There is a misunderstanding in the article title. Guardtime does not (and does not claim to) provide encryption; it is a data hashing service.

    You'll notice I wrote data "hashing" and not data "signing", which is the word Guardtime uses.  I say 'hashing' because Guardtime does not provide any of the "signing" features that we've come to expect from tools such as RSA, SSL, and S/MIME, although Guardtime confusingly compares its service to these tools using the same terminology.

    With standard public/private key cryptography, the public key of a data sender is collected and stored by the data receiver. Since there is no danger in anyone knowing the public key, this transfer can happen using any available protocol and is usually completely automatic. This can be made even more secure by requiring that the public key be itself signed by some trusted authority, or that it only be transferred via USB, etc. Once the receiver has the public key of the sender, the receiver has everything inside of it to absolutely authenticate and/or decrypt everything the sender sends (network data, executable binaries, email, text messages, anything) without any outside help.

    What Guardtime does is generate SHA-256 hashes of documents and executables. If you've ever used MD5, you understand how this works. A given input produces a particular hash, and changing the input produces a different hash. Obviously, this does not provide any security at all, since an attacker may just create a new hash of their malicious data and present this new hash as genuine. Guardtime adds the additional step of sending the hash to their servers, where it is combined with their private key and a timestamp, and hashed again. This "salted" hash is then included with the data.

    To validate this data, the receiver calculates a new hash of the data and sends the two hashes to the Guardtime server, which confirms that the salted hash matches one that it would have generated from the same input.

    The resulting limitations are obvious:

    • Because every chunk of data requires two requests to the Guardtime servers (once to hash, once to verify) Guardtime is not suitable for streaming data or any service which does not tolerate latency. 
    • It is not possible for the receiver to validate a message without a connection to the Guardtime server. If the receiver cannot contact the Guardtime server it must either stop operating or naively trust any data sent to it.
    • Guardtime cannot validate the identity of any sender. Because of this, Guardtime cannot secure access to its own servers using its own protocol. To ensure that the Guardtime server you are using is actually a Guardtime server and not an imposter validating malicious data you must use standard public/private key cryptography (SSL) completely obviating the supposed simplicity of the Guardtime system.

    Finally, the fact that Guardtime is not up-front about any of this is simply unacceptable. Their PR copy is either maliciously or incompetently misleading, saying, for example, that their system is "keyless" when in fact it requires a private key on the server to generate the salted hashes.

    I would not be lauding this move.

This reply was deleted.