Galileo leverages end-to-end encryption between senders and receivers of data as well as a secure architecture connecting the components of the application.  

Galileo Installation Security and Certifications 

Microsoft Code Signing Certificate

Hyperdyne, Inc. holds a Microsoft Inc. Code Signing Certificate. This certificate authenticates Hyperdyne, Inc. as the producer and publisher of your local version of Galileo every time it is downloaded and executed. This ensures receipt of the code developed at Hyperdyne, Inc., a business entity registered in the state of Delaware and an authorized Windows developer.

Apple Developer Program

Hyperdyne, Inc. is authorized for app development on Apple-branded products through Apple’s Custom App Distribution authorization. For the time being, Hyperdyne, Inc. distributes its authorized apps outside of the App Store and Apple Business Manager.  

Data Handling, Security & Privacy

Galileo is composed of three main parts:

  1. Front-end interface (GUI, CLI, API)
  2. Middleware daemon
  3. Back-end server hosted on Google Cloud

While the front-end and middleware are often run on the same machine, it is, in some cases, useful for them to run on different machines. For this reason, Hyperdyne, Inc. architected secure communication between these components with a mix of HTTPS (HTTP over TLS) and WSS (WebSockets over TLS). TLS, Transfer Layer Security, is a time-tested and industry standard cryptographic protocol, widely used for internet communications and online transactions, that provides end-to-end communications security over networks.  In this way, communications are rendered decipherable to the intended recipient alone.  The middleware communicates with the back-end through a combination of HTTPS and WSS, as well.

An explanation of secure communications between front-end and back-end is non applicable because they seldom communicate directly. If the front-end is non-graphical (CLI, API), then it may perform authentication directly with the back-end via HTTPS (secure as per the explanation above). Aside from this one instance, the front-end never communicates with the back-end. All communications with the back-end are hashed (256-bit SHA3) and signed (2048-bit RSA, RSASSA-PSS) to ensure message integrity and authenticity.

Three types of data transfer may occur between users: 

  1. Data Sets
  2. Jobs: instructions regarding where to execute code and what Data Set(s)
  3. Job Results: data & metadata generated after code execution

In all cases the information is encrypted end-to-end between sender and receiver via the following process:

  1. Sender middleware encrypts the data using AES-CTR (256-bit key, 128-bit unique counter block).
  2. Sender middleware sends the encrypted data to the server to await retrieval.
  3. Sender middleware sends an encrypted message containing the AES key to the server to await retrieval. This message is encrypted with the Double Ratchet Algorithm.
  4. Receiver middleware retrieves the encrypted message from the server and decrypts it to attain the AES key. This message is decrypted with the Double Ratchet Algorithm.
  5. Receiver middleware retrieves the encrypted data and decrypts it using the AES key.

Hyperdyne, Inc. uses the following implementations in its security stack:

Did this answer your question?