Ok, it’s not one of the two hardest problems in Computer Science, but adding authentication to your web-based application is non-trivial. In addition to the security concerns involved, you are also required to maintain account information, registration, and identity management, which most users are tired of. Nobody wants Yet Another Password To Remember (YAPTR).

Of course, most of you will point to OAuth and OpenID. You’ll correctly point out that we should leverage the users existing identities.

This is great, but what if you have a simple static site or download server that you want to protect? Should we build a full web-application just to integrate OAuth?

The easiest answer is, of course, simple .htaccess files to protect these sites — which brings us back to the identity management problem. Can’t anything be simple?

Of course it can! Enter the Authenticating Reverse Proxy and Keycloak. An authenticating reverse proxy sits in front of your site, and only allows traffic through if it has been authenticated.

Keycloak is an Open Source Identity and Access Management solution. Combing these two technologies gives you an easy mechanism to add authentication to any web-based application.

Keycloak

Keycloak is an open source Identity and Access Management solution. It makes it easy to secure applications and services with little to no code. Keycloak handles user identities, user federation, identity brokering and social login.

Users authenticate with Keycloak, rather than with individual services. This means that each service you provide doesn’t have to manage users. Once a user signs-on with Keycloak, they don’t need to authenticate again to access other services.

In addition to providing the infrastructure required for Single Sign-On (SSO), Keycloak also provides an advanced admin UI, so you can easily manage your users without complicated CLIs or manually editing configuration files.

Through identity brokering and social login, users can login to your Keycloak service with their existing identities (such as Google, Facebook, GitHub, etc…). Through user federation, Keycloack can be integrated with existing LDAP or Active Directory servers. You can even implement your own provider if you have an existing relational database, for example.

In addition to user management, Keycloak can also act as an authentication endpoint. Keycloak implements many standard protocols such as OAuth2 and OpenID Connect. Several client adapters are also available, so integrating your existing services (such as a local Jenkins instance), or a custom service (such as a Java application) is easy.

Finally, Keycloak supports UI theming, so you can easily roll out a highly customized authentication portal as unique as you are. If you need authentication in your application or organization, take a look at Keycloak.

Authenticating Reverse Proxy

A reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. The resources from these servers are returned to the client as if they originate from the Web server itself.

An authenticating reverse proxy is a reverse proxy that only retrieves the resources on behalf of a client if the client has been authenticated. If a client is not authenticated they can be redirected to a login page.

By structuring your system this way, you can put all your sensitive material on the internal web server, and protect everything through an authenticating reverse proxy. For even more security, the internal web server could be placed on a private Virtual Private Cloud, with absolutely no access from the outside, except through the proxy.

Lua-Resty-OpenIDC

To integrate Keycloak and an Authenticating Reverse Proxy, we used lua-resty-openidc.  Lua Resty OpenIDC is a library for OpenResty, a web-server based on Nginx. OpenResty describes itself as a web platform that integrates the standard Nginx core, LuaJIT and many Lua libraries and high-quality 3rd-party Nginx modules.

It is designed to help developers easily build scalable web applications, web services, and dynamic web gateways. Lua Resty OpenIDC implements the OpenID Connect Relying Party (RP) and the OAuth 2.0 Resource Server (RS) functionality.

To help you get started, I’ve created a simple Dockerfile that can be used to build a container with OpenResty, lua-resty-openidc and the required dependencies.

FROM openresty/openresty:alpine-fat

RUN mkdir /var/log/nginx

RUN apk add --no-cache openssl-dev
RUN apk add --no-cache git
RUN apk add --no-cache gcc
RUN luarocks install lua-resty-openidc

ENTRYPOINT ["/usr/local/openresty/nginx/sbin/nginx", "-g", "daemon off;"]

Build a docker container using this Dockerfile using:
docker build -t authproxy .
This will create a container called authproxy. You can start this proxy will an appropriate Nginx configuration. I used the following Nginx configuration file to configure lua-resty-openidc to integrate with Keycloak.

worker_processes auto;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
   lua_package_path '/usr/local/openresty/lualib/?.lua;;';
   resolver 8.8.8.8;
   include /etc/nginx/conf.d/*.conf;

   # cache for discovery metadata documents
   lua_shared_dict discovery 1m;
   # cache for JWKs
   lua_shared_dict jwks 1m;

   index   index.html index.htm;

   server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        root         /usr/share/nginx/html;

        access_by_lua '
          local opts = {
            redirect_uri_path = "/",
            discovery = "https://keycloak_server/auth/realms/master/.well-known/openid-configuration",
            client_id = "clientID",
            client_secret = "clientSecret",
            redirect_uri_scheme = "https",
            logout_path = "/logout",
            redirect_after_logout_uri = "https://keycloak_server/auth/realms/master/protocol/openid-connect/logout?redirect_uri=http%3A%2F%2Fianbull.com",
            redirect_after_logout_with_id_token_hint = false,
            session_contents = {id_token=true}
          }
          -- call introspect for OAuth 2.0 Bearer Access Token validation
          local res, err = require("resty.openidc").authenticate(opts)

          if err then
            ngx.status = 403
            ngx.say(err)
            ngx.exit(ngx.HTTP_FORBIDDEN)
          end
       ';

       # I disbled caching so the browser won't cache the site.
       expires           0;
       add_header        Cache-Control private;

       location / {
       }

       # redirect server error pages to the static page /40x.html
       #
       error_page 404 /404.html;
           location = /40x.html {
       }
       # redirect server error pages to the static page /50x.html
       #
       error_page 500 502 503 504 /50x.html;
           location = /50x.html {
       }
   }
}

You can now start your docker container, and volume mount the directory containing this configuration file. I put it in my current directory and used the following command to start the container. I also mounted the current directory under /usr/share/nginx/html so any html files in the current directory will be hosted behind the authenticating proxy. Finally, I mapped port 80 on the host to port 80 in the container.

docker run -d -it -p 80:80 -v $PWD/:/config -v /:/usr/share/nginx/html authproxy -c /config/nginx.conf

Conclusion

Protecting a site using an authenticating reverse proxy is very easy with Keycloak. Keycloak provides you with all the identity and access management tools you need, and the lua-resty-openidc library can be used to configure the proxy.

For more information about the tools and technologies we use internally at EclipseSource, follow me on twitter.

As more organizations migrate towards JavaScript on Mobile, JavaScript security is becoming a top priority. At EclipseSource, we have been building JavaScript based mobile apps for customers in the fields of health care and financial services. In this post, we will highlight some of the security concerns we uncovered when using JavaScript on Mobile and discuss how to mitigate them.

Repackaging Protection

One attack that is difficult to protect against involves someone taking your application, decompiling it, changing it, and re-publishing it to the app stores. The attacker then tries to get users to install their modified version instead of your official one. A well crafted app will still behave like the original so the user has no idea they are using a version that has been tampered with.

To protect against this, you can perform a check at runtime to see if the code you are executing matches your signing key. On Android, you can check the fingerprint of the signing certificate using activity.getPackageManager().getPackageInfo().signatures. Of course, if someone decompiled your source code, it will be trivial to change this logic. To address this, you can either compile this logic directly into your JavaScript engine, which as a native library will be harder to break; or you can embed this logic into your JavaScript, and ship encrypted & obfuscated JavaScript.

JavaScript Code Obfuscation & Encryption

Shipping JavaScript based mobile apps often means shipping your JavaScript in plain text to all your users. Even without decompiling your source code, an attacker can often find your JavaScript embedded directly in your packaged app. Anybody with simple editor can inspect your source code to get insights into your application and search for security vulnerabilities. Minified JavaScript can help a bit, but will only slow down an attacker. A better approach is to obfuscate your code using an AES key and use that same key at runtime to decrypt the JavaScript as it’s executed. The AES key can either be encrypted and embedded directly in the binary or it can be negotiated with a server and passed at runtime.

Of course, in the end, the code must be decrypted as it’s executed. If someone dumps the memory of your app while it’s running, they may find the JavaScript there. If you are going to obfuscate your code, you should still perform code signing & verification to make sure nobody has tampered with it.

JavaScript Code Signing & Verification

Code signing and verification is a mechanism used to ensure that the code being executed has not been tampered with. When code is authored, a fingerprint is computed and that fingerprint is signed with a private key. At execution time, the same fingerprint is computed and the matching public key is used to verify that the signature matches. If the signature matches, then the code can be executed, otherwise the code is rejected with a security exception.

Like the AES key, the public key can either be embedded in the application or negotiated at runtime. Public keys are considered safe to distribute, but if someone does have the public key, they could substitute it for their own. Obfuscating and embedding the key directly in the JavaScript engine makes this attack harder. Furthermore, if the APK itself has been signed, then an attacker won’t be able to simply change the binary.

We suggest performing JavaScript code signing & verification as a minimum for all JavaScript based apps. This means that you must sign and verify not only your own source code, but all your dependencies too.

Root Detection

Finally, most attack vectors require root access to a users device. With root access, an attacker can install alternate VMs or manipulate the Java code running on a Android device using reflection. By disabling the JavaScript engine from running on a rooted phone, these attacks become harder. This can be viewed as an extreme measure, but it helps protect highly sensitive data from being exposed in a potentially hostile environment.

However, disabling apps on rooted phones is also a double-edge sword. Some people root their phones to install security patches, and in some cases rooted phones may actually be more secure than stock installs. If you are going to perform root detection, think about your target audience and if this security measure actually makes sense for your app.

Summary

As JavaScript grows and starts to play a more prominent role in the financial and health services, security requirements are becoming a top priority. Because JavaScript is an interpreted language, the source code often ships in plain text to all your clients’ devices. However, there are several measures you can take to address the risks, such as re-packaging protection, code obfuscation & encryption, code signing & verification and root detection. Embedding these checks directly in the JavaScript engine, and halting all execution if those checks fail, can help mitigate the security risks associated with JavaScript on Mobile.

If you are interested in learning more about mobile security and to hear about how we manage this with Tabris.js and J2V8, please get in touch. For more information on J2V8 and JavaScript security, follow me on Twitter.

XHR and Fetch are two standards for retrieving data from a URL. With Tabris.js 1 you could only fetch text-based data through this API, but now you can fetch both text and binary data. The binary data is returned as an ArrayBuffer and can be manipulated in place. On Android, this means that the ArrayBuffer is shared between the underlying V8 instance and the Tabris.js runtime; so no excess data copying is performed.

For example, with binary fetch, you could fetch images from a remote URL and apply different filters before displaying them in an image view.

function loadData() {
  fetch('https://tabrisjs.com/assets/public-content/img/iphone-cropped-small.png')
    .then(response => checkStatus(response) && response.arrayBuffer())
    .then(buffer => {
       new PNG({ filterType:4 }).parse( buffer, function(error, data) {
         var options = {  colorType: 0 }
         var out = PNG.sync.write(data, options);
           let base64Encoded =  _arrayBufferToBase64(out);
           imageView.image = { src:'data:image/png;base64,' + base64Encoded};
       });
      return buffer;
    })
    .catch(err => console.error(err)); // Never forget the final catch!
}

In this example, we load a PNG as an array buffer, and process the buffer to make it greyscale. You of course could apply all sorts of filters. For those interested, I used pngjs to process the image.

The entire snippet is available here.

We are just putting the final touches on Tabris.js 2.0 and it will be publicly available on July 18th. Follow us on Twitter for all the latest Tabris.js news.

Tabris.js 2.0 – Top 10 Features

The binary fetch() is just one of the cool new additions to Tabris.js 2. Don’t forget to check out the other top 10 features in the rundown below.

1. TypeScript & JSX
2. Windows 10 Support
3. File system access
4. AlertDialog
5. Binary fetch()
6. Simplified event and properties API
7. StatusBar and NavigationBar
8. Tabris CLI
9. Security
10. NavigationView

Over the past year, I’ve had the opporuntity to focus on Tabris.js security related work such as certificate pinning, code signing, code obfuscation, and other security enhancements.

Certificate Pinning

When an SSL connection is first made, the server typically sends its certificate to the client. The client checks to ensure that the certificate is signed by an authority it trusts, and uses that to determine if it can trust the server. While this is typically safe, there have been exploits in the past where a false certificate were accepted, and the client ended up trusting an invalid host.

To mitigate this, most security experts advise the use of certificate pinning. With certificate pinning, the client stores the fingerprint of the certificate, and checks that the fingerprint matches before continuing with the secure communication. As an aside, this is how SSH works, and if someone tries to spoof the server, you’ll see this error.

For more information, checkout OWASP’s article about certificate pinning.

Tabris.js 2.0 now supports certificate pinning for XHR/Fetch, WebSockets, Image loading and App Patching. Use the app object and assigned a list of trusted certificates to the pinnedCertificates property.

const {app} = require('tabris');

app.pinnedCertificates = [{host: 'freegeoip.net', hash: 'sha256/+SVYjThgePRQxQ0e8bWTQDRtPYR/xBRufqyMoeaWteo=', algorithm: 'ECDSA256'}];

If an invalid certificate is used, any connection to the server (freegeoip.net in this case) will fail. Checkout out docs for more information on this API.

Enterprise Security Enhancements

In addition to certificate pinning, which is available directly in Tabris.js 2.0, we have also implemented several Tabris.js enterprise modules. Tabris.js has been used successfully to build high quality banking apps for Android and iOS. Due to the nature of these apps, a number of Tabris.js security add-ons have been developed. For example, certificate pinning is only effective if the fingerprint is secure. To enforce this, we have introduced Javascript code signing & fingerprint checking as well as Javascript code obfuscation & script encryption. These can be included as Tabris.js enterprise modules. We also have tools to protect against running Tabris.js apps on rooted phones and native re-packaging protection built right into our Javascript engine. Contact us for more information on how we can help you protect your mobile applications.

With an improved API, new widgets and more platforms, Tabris.js 2.0 will be the best Tabris.js release yet; and with the security features we’ve added, it will be the most secure. Make sure to check back next week as we continue our countdown, or follow us on Twitter.

Tabris.js 2.0 – Top 10 Features

The improved security is just one of the cool new additions to Tabris.js 2. Don’t forget to check out the other top 10 features in the rundown below.

1. TypeScript & JSX
2. Windows 10 Support
3. File system access
4. AlertDialog
5. Binary fetch()
6. Simplified event and properties API
7. StatusBar and NavigationBar
8. Tabris CLI
9. Security
10. NavigationView

The cryptographic keys used for AES are usually fixed-length (for example, 128 or 256bit keys). Because humans cannot easily remember long random strings, key stretching is performed to create a long, fixed-length key from a short, variable length password. Key stretching uses a key-derivation function. Command line OpenSSL uses a rather simplistic method for computing the cryptographic key from a password, which we will need to mimic using the C++ API. OpenSSL uses a hash of the password and a random 64bit salt. Only a single iteration is performed.

Encrypting: OpenSSL Command Line

To encrypt a plaintext using AES with OpenSSL, the enc command is used. The following command will prompt you for a password, encrypt a file called plaintext.txt and Base64 encode the output. The output will be written to standard out (the console). SHA1 will be used as the key-derivation function. We will use the password 12345 in this example.

$ openssl enc -aes-256-cbc -in plaintext.txt -base64 -md sha1

This will result in a different output each time it is run. This is because a different (random) salt is used. The Salt is written as part of the output, and we will read it back in the next section.

Decrypting: OpenSSL API

To decrypt the output of an AES encryption (aes-256-cbc) we will use the OpenSSL C++ API. Unlike the command line, each step must be explicitly performed with the API. There are four steps involved when decrypting: 1) Decoding the input (from Base64), 2) extracting the Salt, 3) creating the key (key-stretching) using the password and the Salt, and 4) performing the AES decryption.

Base64 Decoding

When the plaintext was encrypted, we specified -base64. This resulted in a Base64 encoding of the output which is important if you wish to process the cipher with a text editor or read it into a string. Before decryption can be performed, the output must be decoded from its Base64 representation. We use the same decoding algorithm that we used in our previous OpenSSL Tutorial:

size_t calcDecodeLength(char* b64input) {
  size_t len = strlen(b64input), padding = 0;

  if (b64input[len-1] == '=' && b64input[len-2] == '=') //last two chars are =
    padding = 2;
  else if (b64input[len-1] == '=') //last char is =
    padding = 1;
  return (len*3)/4 - padding;
}

void Base64Decode( char* b64message, unsigned char** buffer, size_t* length) {
  BIO *bio, *b64;

  int decodeLen = calcDecodeLength(b64message);
  *buffer = (unsigned char*)malloc(decodeLen + 1);
  (*buffer)[decodeLen] = '\0';

  bio = BIO_new_mem_buf(b64message, -1);
  b64 = BIO_new(BIO_f_base64());
  bio = BIO_push(b64, bio);

  *length = BIO_read(bio, *buffer, strlen(b64message));
  BIO_free_all(bio);
}

Again, special thanks to Barry Steyn for providing this.

Extracting the Salt

Once we have decoded the cipher, we can read the salt. The Salt is identified by the 8 byte header (Salted__), followed by the 8 byte salt. We start by ensuring the header exists, and then we extract the following 8 bytes:

unsigned char* ciphertext = ...; // Decoded cipher text
size_t cipher_len = ...; // Length of decoded cipher text, computed during Base64Decode
if (strncmp((const char*)ciphertext,"Salted__",8) == 0) {
  memcpy(salt,&ciphertext[8],8);
  ciphertext += 16;
  cipher_len -= 16;
}

We then move the ciphertext pointer 16 character into the string, and reduce the length of the cipher text by 16.

Computing the Key and Initialization Vector

Once we have extracted the salt, we can use the salt and password to generate the Key and Initialization Vector (IV). To determine the Key and IV from the password (and key-derivation function) use the EVP_BytesToKey function:

void initAES(const string& pass, unsigned char* salt, unsigned char* key, unsigned char* iv )
{
  bzero(key,sizeof(key));
  bzero(iv,sizeof(iv));
  EVP_BytesToKey(EVP_aes_256_cbc(), EVP_sha1(), salt, (unsigned char*)pass.c_str(), pass.length(), 1, key, iv);
}

This initially zeros out the Key and IV, and then uses the EVP_BytesToKey to populate these two data structures. In this case we are using Sha1 as the key-derivation function and the same password used when we encrypted the plaintext. We use a single iteration (the 6th parameter).

Decrypting the Cipher

With the Key and IV computed, and the cipher decoded from Base64, we are now ready to decrypt the message. To decrypt the message we need a buffer in which to store it. Since the cipher text is always greater (or equal to) the length of the plaintext, we can allocate a buffer with the same length as the ciphertext. OpenSSL will tell us exactly how much data it wrote to that buffer.

string decrypt(unsigned char *ciphertext, 
               int ciphertext_len, 
               unsigned char *key,
               unsigned char *iv ) {

  EVP_CIPHER_CTX *ctx;
  unsigned char *plaintexts;
  int len;
  int plaintext_len;
  unsigned char* plaintext = new unsigned char[ciphertext_len];
  bzero(plaintext,ciphertext_len);

  /* Create and initialise the context */
  if(!(ctx = EVP_CIPHER_CTX_new())) handleOpenSSLErrors();

  /* Initialise the decryption operation. IMPORTANT - ensure you use a key
   * and IV size appropriate for your cipher
   * In this example we are using 256 bit AES (i.e. a 256 bit key). The
   * IV size for *most* modes is the same as the block size. For AES this
   * is 128 bits */
  if(1 != EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv))
    handleOpenSSLErrors();

  EVP_CIPHER_CTX_set_key_length(ctx, EVP_MAX_KEY_LENGTH);

  /* Provide the message to be decrypted, and obtain the plaintext output.
   * EVP_DecryptUpdate can be called multiple times if necessary
   */
  if(1 != EVP_DecryptUpdate(ctx, plaintext, &len, ciphertext, ciphertext_len))
    handleOpenSSLErrors();

  plaintext_len = len;

  /* Finalize the decryption. Further plaintext bytes may be written at
   * this stage.
   */
  int pad_len;
  if(1 != EVP_DecryptFinal_ex(ctx, plaintext + len, &len)) handleOpenSSLErrors();
  plaintext_len += len;

  /* Add the null terminator */
  plaintext[plaintext_len] = 0;

  /* Clean up */
  EVP_CIPHER_CTX_free(ctx);
  string ret = (char*)plaintext;
  delete [] plaintext;
  return ret;
}

We begin by initializing the Decryption with the AES algorithm, Key and IV. We then pass the EVP_DecryptUpdate function the ciphertext, a buffer for the plaintext and a pointer to the length. This will perform the decryption and can be called several times if you wish to decrypt the cipher in blocks. Finally, calling EVP_DecryptFinal_ex will complete the decryption. We null terminate the plaintext buffer at the end of the input and return the result.

Conclusion

In this tutorial we demonstrated how to encrypt a message using the OpenSSL command line and then how to decrypt the message using the OpenSSL C++ API. The API required a bit more work as we had to manually decode the cipher, extract the salt, compute the Key and perform the decryption. A complete copy of the code for this tutorial can be found here.

While the tutorial explained how to create an RSA KeyPair, it didn’t mention anything about protecting the Keys; in particular, protecting the private key. If the private key is ever compromised, someone could change your source code and re-sign it. This would make it appear as though you authored the changes. A great tool for securing private keys is PIV-Compliant Smart Card such as the YubiKey 4 or YubiKey Neo. The YubiKey is often used as a Universal Second Factor Authentication Device (U2F), but these devices provide much more functionality. The PIV slot on the Yubikey is a Write-Only slot, meaning you can store a private key on the device but you cannot read it back. You can however use the PIV applet on the device to produce a digital signature using the stored key.

In this extended tutorial we will look at how to create a digital signature with a YubiKey 4 and verify it with OpenSSL.

By Yubico – Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=52063469

Introducing the YubiKey

A YubiKey is a small hardware device primarily intended to provide second factor authentication. It supports a number of two factor authentication protocols, including One-Time Passwords, Challenge-Response and FIDO-U2F — a new standard being jointly developed by Yubico, Google and several other members of the Fido Alliance. In addition to Two-Factory Authentication, the YubiKey has several other slots. The card can be used to store PGP Private Keys, emit a static password and even act as a personal identity verification (PIV) card.

PIV cards have a number of certificate slots, which can be used for a variety of tasks such as signing, encryption, decryption and verification (among other things). It is these slots, and in particular the Certificate for Digital Signatures, that can be used for code signing.

Configuring your YubiKey

RSA keys can be generated on the YubiKey or generated elsewhere and imported. The former is much more secure since the private key never needs to be stored on a computer and since the YubiKey is write-only it can never be exported. This means that the only way someone could access your private key is if they stole your physical device. The YubiKey can also be protected with a PIN, so even if someone stole your key, they still couldn’t use it (after 3 false PIN attempts, the card will lock itself).

Before you begin, there are a number of useful tools to help you manage the PIV functionality of your YubiKey.

• YubiKey-PIV-Tool
• YubiKey-PIV-Manager
• OpenSC

The first two downloads will help you manage the device itself (set the PIN, generate the keys, etc…). The first download is a command line tool while the second one provides the functionality via a graphical interface. The 3rd download (OpenSC) provides several tools for working with open smart card standards. These tools provide the signing / encryption functionality. In particular, these tools provide PCKS#11 and PCKS#15, a standard platform-independent API to cryptographic tokens.

You should begin by changing the default PIN and PUK. When you first launch the PIV-Manager it will prompt you to do this. Once configured, you can now generate a public / private key pair. We will generate the pair on slot 9c (Digital Signature).

You can now export the certificate and extract the public key or use the pkcs15-tool to directly dump the public key:

$ pkcs15-tool  --read-public-key 02
Using reader with a card: Yubico Yubikey 4 OTP+U2F+CCID
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmnqmPLS3XFlUXgxTAF2/
6GGO9rW9DzbMmqOvAXWsL9Mn66qRZOKX4xfm0jM2p6FBqyvfMvnJto8d6XPHyDz/
VhXBqd9940hnHhZQE4DTioA7nyx4E+EdpLjHbLF2jwZZh325JO1CPTIdQhLK7pIt
m1xCSX5Wvb/3JSfBz7B8baJio3tBD9+aLnqW9deKAiuJOsoFr+NcBEZ98JNXRav1
Xu1Ac6cG3hzOaOaNLM2yq1yDBEFBvz4GXjQIR5lvn8dOFCjsSZ2MYzD3EP85DOop
z45rAnUwJ1JKt7HNNQpyd8GwdlWygqfFmjJ/zl/7src720398Llb+3XzOfsj7NKR
1QIDAQAB
-----END PUBLIC KEY-----

Signing with the YubiKey

When signing documents, you typically sign a hash of the document. This is no different with a YubiKey. In fact, you must first produce the hash and then instruct the key to produce the signature. OpenSSL can be used to produce a hash a follows:

openssl dgst -sha256 -binary plaintext.txt  > plaintext.txt.sha256

This uses the SHA-256 hash function to produce a 256 bit value from the document. The YubiKey can now sign this value. Since the private key cannot be read from the card, an applet on the card performs the signing. The applet can be invoked with pkcs15-crypt. As an added layer of security, the card will prompt you for your PIN (If you enter the PIN incorrectly 3 times, the card will lock).

$ pkcs15-crypt -s -i plaintext.txt.sha256 -o signed.output -f openssl --sha-256 --pkcs1 -k 02
Using reader with a card: Yubico Yubikey 4 OTP+U2F+CCID
Enter PIN [PIV Card Holder pin]:

When the signing command finishes, the signature will be written to signed.output. The other arguments are used to specify the input (plaintext.txt.sha254), instruct the card to output the data in OpenSSL format, and that the SHA-256 hash function was used. Finally, -k 02 specifies slot 02 (also known as 9c, where the key was stored).

Verifying the Signature

To verify the signature, you only need the public key, signature and the original text, which we exported earlier. This is exactly the same as the previous tutorial. Since we used SHA-256 to produce the hash, we must specify that when verifying the signature.

$ openssl dgst -sha256 -verify mykey.pub  -signature signed.output plaintext.txt
Verified OK

Over the next few weeks I’ll be writing about other uses of the YubiKey, especially for cryptography. Follow me on Twitter for updates.

Tabris.js initially targeted Android and iOS devices. Earlier this year we announced our plans to support Windows 10, and we are happy to announce that this support is now here. This means that you can now build and deliver Tabris.js applications that target the Microsoft Surface, Windows Phone and even Windows 10 desktop devices, as well as iOS and Android. We have released our first application for all these platforms — the EclipseCon Europe 2016 Conference app. The application is now available in all three mobile stores.

Access to the Windows 10 build service will be rolled out over the next few months. If you would like to join our beta program, please sign-up below.

Code signing and verification works as follows. In addition to writing the code, the author executes a hash function with the code as the input, producing a digest. The digest is signed with the author’s private key, producing the signature. The code, signature and hash function are then delivered to the verifier. The verifier produces the digest from the code using the same hash function, and then uses the public key to decrypt the signature. If both digests match, then the verifier can be confident that the code has not been tampered with.

In this tutorial we will demonstrate how you can use OpenSSL to sign and verify a script. This tutorial will describe both the OpenSSL command line, and the C++ APIs.

Key Generation

Before you can begin the process of code signing and verification, you must first create a public/private key pair. The ssh-keygen -t rsa can be used to generate key pairs.

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/irbull/.ssh/id_rsa): ./example_rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in ./example_rsa.
Your public key has been saved in ./example_rsa.pub.
The key fingerprint is:
35:26:61:ae:23:11:6c:e1:88:39:31:c5:0f:06:f7:71 me@mymachine
The key randomart image is:
+--[ RSA 2048]----+
|++o.+.E o        |
| *++o+ o .       |
|+..++   o +      |
| .  .. . + .     |
|    . o S        |
|     . .         |
|                 |
|                 |
|                 |
+-----------------+

If you’re interested in what randomart is, checkout the answer on StackExchange.

Converting to PEM format

The standard file format for OpenSSL is the PEM format. The PEM format is intended to be readable in ASCII and safe for ASCII editors and text documents. The PEM format is a container format and can include public certificates, or certificate chains including the public key, private key and root certificate. PEM files can be recognized by the BEGIN and END headers. To export a public key in PEM format use the following OpenSSL command.

$ openssl rsa -in example_rsa -pubout -out public.key.pem

Code Signing

OpenSSL makes it relatively easy to compute the digest and signature from a plaintext using a single API. However, before you begin you must first create an RSA object from your private key:

RSA* createPrivateRSA(std::string key) {
  RSA *rsa = NULL;
  const char* c_string = key.c_str();
  BIO * keybio = BIO_new_mem_buf((void*)c_string, -1);
  if (keybio==NULL) {
      return 0;
  }
  rsa = PEM_read_bio_RSAPrivateKey(keybio, &rsa,NULL, NULL);
  return rsa;
}

With an RSA object and plaintext you can create the digest and digital signature:

bool RSASign( RSA* rsa, 
              const unsigned char* Msg, 
              size_t MsgLen,
              unsigned char** EncMsg, 
              size_t* MsgLenEnc) {
  EVP_MD_CTX* m_RSASignCtx = EVP_MD_CTX_create();
  EVP_PKEY* priKey  = EVP_PKEY_new();
  EVP_PKEY_assign_RSA(priKey, rsa);
  if (EVP_DigestSignInit(m_RSASignCtx,NULL, EVP_sha256(), NULL,priKey)<=0) {
      return false;
  }
  if (EVP_DigestSignUpdate(m_RSASignCtx, Msg, MsgLen) <= 0) {
      return false;
  }
  if (EVP_DigestSignFinal(m_RSASignCtx, NULL, MsgLenEnc) <=0) {
      return false;
  }
  *EncMsg = (unsigned char*)malloc(*MsgLenEnc);
  if (EVP_DigestSignFinal(m_RSASignCtx, *EncMsg, MsgLenEnc) <= 0) {
      return false;
  }
  EVP_MD_CTX_cleanup(m_RSASignCtx);
  return true;
}

This works by first creating a signing context, and then initializing the context with the hash function (SHA-256 in our case) and the private key. The message is then added to the context, and finally the signature length is computed. Space for the signature is then allocated and finally the signature (signed digest) computed. EncMsg will hold the signature and MsgLenEnc will hold the length of the signature. The signature should not be treated as a string.

If you need to print the signature or write it to non-binary file, you should Base64 encode it. OpenSSL provides an API to help with this. Barry Steyn has put together a simple example that shows how to use this API. Below is a slightly modified version of his code:

void Base64Encode( const unsigned char* buffer, 
                   size_t length, 
                   char** base64Text) { 
  BIO *bio, *b64;
  BUF_MEM *bufferPtr;

  b64 = BIO_new(BIO_f_base64());
  bio = BIO_new(BIO_s_mem());
  bio = BIO_push(b64, bio);

  BIO_write(bio, buffer, length);
  BIO_flush(bio);
  BIO_get_mem_ptr(bio, &bufferPtr);
  BIO_set_close(bio, BIO_NOCLOSE);
  BIO_free_all(bio);

  *base64Text=(*bufferPtr).data;
}

Putting this all together you can create a signed digest in a Base64 encoded string:

char* signMessage(std::string privateKey, std::string plainText) {
  RSA* privateRSA = createPrivateRSA(privateKey);
  unsigned char* encMessage;
  char* base64Text;
  size_t encMessageLength;
  RSASign(privateRSA, (unsigned char*) plainText.c_str(), plainText.length(), &encMessage, &encMessageLength);
  Base64Encode(encMessage, encMessageLength, &base64Text);
  free(encMessage);
  return base64Text;
}

The character array base64Text will hold the result.

OpenSSL Command Line

You can also create a digest and digital signature using the following OpenSSL commands. The first command will create the digest and signature. The signature will be written to sign.txt.sha256 as binary. The second command Base64 encodes the signature.

openssl dgst -sha256 -sign my_private.key -out sign.txt.sha256 codeToSign.txt
openssl enc -base64 -in sign.txt.sha256 -out sign.txt.sha256.base64

Signature Verification

Signature verification ensures that the signature matches the original code. If the code was altered at all (even the addition of a single newline character) then a different signature will be produced and the verification will fail.

Signature verification works in the opposite direction. In order to verify that the signature is correct, you must first compute the digest using the same algorithm as the author. Then, using the public key, you decrypt the author's signature and verify that the digests match.

Again, OpenSSL has an API for computing the digest and verifying the signature. Since we wrote the signature with a Base64 encoding, we must first decode it. Again, Barry Steyn has a detailed example of how to do this on his blog. A copy of his code can be found below.

size_t calcDecodeLength(const char* b64input) {
  size_t len = strlen(b64input), padding = 0;

  if (b64input[len-1] == '=' && b64input[len-2] == '=') //last two chars are =
    padding = 2;
  else if (b64input[len-1] == '=') //last char is =
    padding = 1;
  return (len*3)/4 - padding;
}

void Base64Decode(const char* b64message, unsigned char** buffer, size_t* length) {
  BIO *bio, *b64;

  int decodeLen = calcDecodeLength(b64message);
  *buffer = (unsigned char*)malloc(decodeLen + 1);
  (*buffer)[decodeLen] = '\0';

  bio = BIO_new_mem_buf(b64message, -1);
  b64 = BIO_new(BIO_f_base64());
  bio = BIO_push(b64, bio);

  *length = BIO_read(bio, *buffer, strlen(b64message));
  BIO_free_all(bio);
}

In addition to decoding the Base64 encoded signature, you must also create an RSA object from the public key. This is similar to how the RSA object was created from the private key when the signature was computed.

RSA* createPublicRSA(std::string key) {
  RSA *rsa = NULL;
  BIO *keybio;
  const char* c_string = key.c_str();
  keybio = BIO_new_mem_buf((void*)c_string, -1);
  if (keybio==NULL) {
      return 0;
  }
  rsa = PEM_read_bio_RSA_PUBKEY(keybio, &rsa,NULL, NULL);
  return rsa;
}

Finally, with the RSA object, original message and binary encoded signature, you can verify that the signature matches the plain text.

bool RSAVerifySignature( RSA* rsa, 
                         unsigned char* MsgHash, 
                         size_t MsgHashLen, 
                         const char* Msg, 
                         size_t MsgLen, 
                         bool* Authentic) {
  *Authentic = false;
  EVP_PKEY* pubKey  = EVP_PKEY_new();
  EVP_PKEY_assign_RSA(pubKey, rsa);
  EVP_MD_CTX* m_RSAVerifyCtx = EVP_MD_CTX_create();

  if (EVP_DigestVerifyInit(m_RSAVerifyCtx,NULL, EVP_sha256(),NULL,pubKey)<=0) {
    return false;
  }
  if (EVP_DigestVerifyUpdate(m_RSAVerifyCtx, Msg, MsgLen) <= 0) {
    return false;
  }
  int AuthStatus = EVP_DigestVerifyFinal(m_RSAVerifyCtx, MsgHash, MsgHashLen);
  if (AuthStatus==1) {
    *Authentic = true;
    EVP_MD_CTX_cleanup(m_RSAVerifyCtx);
    return true;
  } else if(AuthStatus==0){
    *Authentic = false;
    EVP_MD_CTX_cleanup(m_RSAVerifyCtx);
    return true;
  } else{
    *Authentic = false;
    EVP_MD_CTX_cleanup(m_RSAVerifyCtx);
    return false;
  }
}

The output variable Authentic holds the result of the verification. The verification works by first creating a verification context. The context is initialized with the hash function used (SHA-256 in our case) and the public key. The original message is then provided and finally the verification is performed.

Putting this all together, you can verify a signature given the original text, the signature and public key as follows:

bool verifySignature(std::string publicKey, std::string plainText, char* signatureBase64) {
  RSA* publicRSA = createPublicRSA(publicKey);
  unsigned char* encMessage;
  size_t encMessageLength;
  bool authentic;
  Base64Decode(signatureBase64, &encMessage, &encMessageLength);
  bool result = RSAVerifySignature(publicRSA, encMessage, encMessageLength, plainText.c_str(), plainText.length(), &authentic);
  return result & authentic;
}

OpenSSL Command Line

Finally, the OpenSSL command line tool can also be used to decode and verify a digital signature.

openssl enc -base64 -d -in sign.txt.sha256.base64 -out sign.txt.sha256 
openssl dgst -sha256 -verify public.key.pem -signature sign.txt.sha256 codeToSign.txt

Conclusion

So that's it, with either the OpenSSL API or the command line you can sign and verify a code fragment to ensure that it has not been altered since it was authored. You can even mix & match the command line tools with the API, so you can generate the signatures during a build and verify them during program execution. All the code for this example can be found on GitHub.

We will be including a code verification API in the upcoming version of J2V8. For more news about J2V8 and other things I find interesting, follow me on Twitter.

With Tabris.js, if you can take a picture, you can deploy a mobile app.

Really, it’s that simple:

1. Install the Tabris.js development app for your device (Android, iOS)
2. Head to the Tabris.js playground and hack on your app
3. Take a picture of the QR-Code with your device

That’s it! Your app is now running on your device. And if you make a change to your app, simply reload it to see the changes.

Tabris.js is a cross platform, mobile application platform. All the apps are developed in JavaScript and they run natively on your device. When you develop an app at tabrisjs.com we create a link to that app. When you scan the QR-Code with the development client, the app is downloaded to your device and executed. No cross compiling. No webviews. Native performance.

The real benefit of Tabris.js is not what we enabled, it’s what we eliminated:

• No registration
• No IDE installation
• No SDKs to deal with
• No need to write your app twice (JavaScript runs on both iOS and Android)
• No emulators
• No complicated deployments

And when you want to deploy your app to the stores, we have the tools to make this easy too.

Tabris.js is the easiest way to get started with mobile application development.

Bonus tip: also check out the Tabris.js Getting Started ebook, which will tell you everything you need to know to build your first app.

Keyboard broken. Write this Java code without using the letter 'f':

int bar(Object o) { if (o == null) return 0; else return 1;}

Anyone?

— Marc Khouzam (@marckhouzam) August 5, 2016

He added a clarifying note that said the ‘?’ was also broken.

For those of you who don’t know Marc, he is the co-lead of the Eclipse C/C++ Development Tools and all round good guy. I was pretty sure his keyboard wasn’t actually broken and he was basically asking: How can you write a branch statement in Java without an if.

My first thought was to use another branching construct, and the while loop was the first one to pop into my head:

<pre lang="java">
int bar(Object o) {
  while(o == null) {
    return 0;
  }
  return 1;
}
</pre>

However, since I couldn’t sleep I started thinking of other ways to solve this. Since it could be solved with a while, what about a do while.

<pre lang="java">
int bar(Object o) {
  int counter = 2;
  do {
    counter--;
  } while(o == null && counter > 0);
  return counter;
}
</pre>

You could likely solve it with a for loop too, but that would require an f.

A case statement is the next obvious branching construct. However, you cannot switch on a condition such as does n == null. But you can switch on integers, and the identityHashCode is good choice because the identityHashCode for null is 0:

<pre lang="java">
int bar(Object o) {
  int hash = System.identityHashCode(o);
  switch(hash) {
    case 0: return 0;
  }
  return 1;
}
</pre>

Another conditional construct is the catch block, since it only enters into the catch block if an exception is thrown. It’s pretty easy to raise an exception with a null reference:

<pre lang="java">
int bar(Object o) {
  try {
    o.equals(o);
    return 1;
  } catch(NullPointerException e) {
    return 0;
  }
}
</pre>

Finally, I took the original question literally and wrote the if statement without an f. This can be done by replacing the character with its unicode equivalent. I think this was a little cheeky and not really in the spirit of the question though:

<pre lang="java">
int bar(Object o) {
  i\u0066(o == null ) 
    return 0;
  else 
    return 1;
  }
}
</pre>

Does anyone else have other suggestions for how to solve this? Or maybe Marc should just take Jesper’s advice:

@irbull @marckhouzam If the ?-key is broken as well, he needs a new keyboard.

— Jesper Eskilson (@JesperEs) August 5, 2016