Skip to content

security.md

Latest commit

 

History

History
43 lines (36 loc) · 4.87 KB

security.md

File metadata and controls

43 lines (36 loc) · 4.87 KB

Security

Security is an especially important consideration when working with medical software and devices. We will introduce key security concepts at a high-level in lecture today.

Outline

  • Terminology
    • Encryption (plaintext, ciphertext)
    • Signing (verification)
    • Encryption vs. Signing
    • "Encryption at Rest" (AES, see pycrypto) (HIPPA)
    • "Encryption in Transit" (TLS/SSL) (HIPPA)
    • "End-to-end encryption" (E2EE)
  • Asymmetric encryption
    • "Pairs" of related keys are generated by Alice--one to be kept private, one to be shared publically. Learn more about how key pairs are generated.
    • Anyone can use Alice's public key to encrypt a message that can only be decrypted by Alice's private key.
    • Alice can use her private key to digitally "sign" a message that can be verified as authentic (actually sent by Alice) and unmodified by anyone who has her public key
    • Two parties, each with their own public/private key pair can share their public keys with each other, allowing those two parties to communicate back and forth securely (used on the internet a lot). Learn more.
    • This type of encryption underlies TLS/SSL, and is used for securely communicating with remote servers. This allows both the client and server to 1) establish and verify that communications are being sent/received from the actual party (and not an imposter) and 2) to have the communications only decipherable by the server and client involved (no eavesdropper can see what is being communicated).
  • TLS/SSL
    • Important to ensure communications between clients and servers are not observed by eavesdroppers
    • Also important to ensure that the client can verify the identity of the server (ensure that no malicious party is masquerading as the server).
    • Certificate Authorities (CAs) are responsible for "vouching" for the identity of a server.

Add TLS/SSL to your server

You can add TLS/SSL to your server pretty easily (and for free) these days because of certificate authorities like Let's Encrypt that make verification easy. Tools like ssl-proxy (disclaimer: this was built by @suyashkumar) make negotiating and serving a LetsEncrypt certificate as easy as running a single command. You may also acquire certificates using certbot and incoporate them manually into Flask.

Using ssl-proxy

  • Login to your Duke virtual machine.

  • Download the latest release of ssl-proxy to your virtual machine:

    wget -qO- https://github.com/suyashkumar/ssl-proxy/releases/download/v0.2.2/ssl-proxy-linux-amd64.tar.gz | tar xvz
sudo mv ssl-proxy-linux-amd64 /usr/local/bin/ssl-proxy # Move the command into your path, rename as ssl-proxy

  • Create a screen, and run your flask web server, ensure that you have 127.0.0.1 set as your host (only allowing incoming requests from the VM, preventing the outside world from sending requests to your server directly). This example assumes your port is :5000.

  • In another screen, run ssl-proxy as follows:

    sudo ssl-proxy -from 0.0.0.0:443 -to 127.0.0.1:5000 -domain $YOUR_VCM_DOMAIN_NAME_HERE

    This command will negotiate, fetch, and install an ssl certificate for you and serve that ssl certificate on port 443 (the default port for SSL, whenever you go to a website using https://). It will take all incoming web traffic served and negotiated using SSL/TLS, and then send it along to your web service listening for incoming requests at 127.0.0.1:5000. 👀 Notice that in this example we asked you to list the 127.0.0.1 loopback as your host because 127.0.0.1 will not allow external connections outside of your VCM to send requests to the flask server. Since the ssl-proxy program is running on your VM, it is allowed to send connections, but no one else can attempt to contact your flask server directly (they must all go through the ssl-proxy layer first).

  • You should now be able to visit your vcm at https://vcm-7295.vm.duke.edu (substitute for your vcm address) and see the little security lock in your browser. Clicking on it will let you inspect the certificate. If your server does not have a handler for a default route /, then be sure to navigate to your route. For example: https://vcm-7295.vm.duke.edu/hello