Dartmouth Research Computing & Data (RCD) logo
  • Home 
  • HPC 
  • AI 
  • Services 
  • About Us 

  •   Search this site
  •  
  1.   Secure HPC
  1. Home
  2. Secure HPC
  3. Granite Technical Overview

Granite Technical Overview

On this page
Granite Security Overview   Software Layer Details   User System Login and Lockouts   Encrypted Drives   VM Anti-virus   Password Policies and Practice   Workstation Storage  

Granite Security Overview  

The Granite system is a secure computing environment, located at Dartmouth College, Hanover, NH, providing support for projects that require compliance with the controls in NIST 800-171 and 800-53 Moderate.

Granite is self-contained with a minimum of connections to other systems. All connections are rigorously controlled. Data is encrypted at rest and in transit and is processed inside isolated Secure Virtual Machines (SVM). Projects are configured to limit data export to authorized individuals responsible for compliance with project-specific requirements. Data stored within Granite is isolated from the end-user computing devices using the tiCrypt client, which provides remote desktop access to interact with SVMs.

Granite is designed to enable research for a multitude of secure, isolated projects, while keeping the confidentiality, integrity, and availability of information protected at the appropriate level. Configuration security also segregates project information to prevent unauthorized disclosure or sharing of information. Granite provides the necessary infrastructure to enable research partnerships with federal agencies and other organizations for which research projects, data, and technical processes must adhere to specific security guidelines per applicable regulations or contractual requirements. All research projects are completely segregated from other projects.

The environment involves the use of an encrypted (FIPS 140-2 compliant) storage, network, and processing infrastructure for all of the physical servers, virtual servers running on the physical servers, client virtual desktop infrastructure, as well as all of the databases for the information system. The client’s computer is not trusted to hold ePHI or other sensitive data. Users can access Granite only through a secure TLS network connection only after user authentication. All traffic will be carried encrypted to the Granite gateway system overall traversed networks. The gateway system provides further authentication through a secret key created for each user upon first use of the Granite system. The Granite gateway then establishes a secure, high-performance virtual desktop session. The system ensures that the researcher can use applications to analyze authorized data.

Granite is managed using the processes and procedures that meet or exceed the mandates of the FISMA acts of 2002 and 2014 for systems owned by and/or operated for the Federal Government:

  • Data processed by projects set up in Granite is classified following FIPS-199.
  • Granite is classified according to FIPS-200 to meet data requirements classified at the “moderate” impact level for Confidentiality, Integrity, and/or Availability.
  • Controls are implemented and maintained for Granite as specified in 800-53 Moderate and 800-171.
  • A system security plan (SSP) with Plan of Actions and Milestones (POAM) is maintained for Granite according to NIST 800-18.
  • Approval to operate is obtained by the system owner and operator from the appropriate university official.

Software Layer Details  

With tiCrypt being the software layer of the system, client machines connect to the Granite server system via an application called tiCrypt Connect. tiCrypt Connect helps establish secure VM connections and ensures that all traffic is authenticated, locking down sessions if unauthenticated. In addition, software within tiCrypt will secure the VM during the start-up and creation sequence by managing all account passwords and blocking any ports except for port 22 and ports used for licensing servers. For security reasons, virtual machines in tiCrypt cannot be accessed using any of the traditional methods. In particular, direct connections to the VM console, SSH logins, or other remote server technology are not allowed since these items can be controlled by the admins, and thus by hackers impersonating them. The only means of communication is through a secure channel that only the owner of the VM can establish via proxy within tiCrypt. When a VM starts, it gets the public key of the owner. During secure channel setup, the VM and the user co-authenticate each other using the respective public and private keys. A secret channel key is negotiated (Diffie-Helman protocol) and used to communicate. As a result, a secure VM has been created.

System permissions are assigned and managed via a system administrator in Research Computing, acting in coordination with, but independent of, the research team. Upon account creation, users are placed in “teams” by the system administrator. Teams are isolated groups of users. Only members in the same team can interact and share data with each other, and only within the Granite system. Users who wish to download files off the system (for instance, summary tables and graphs) must request that an authorized individual responsible for compliance with project-specific requirements, download the file for them.

User System Login and Lockouts  

The user first enters the password to decrypt the private key stored on their computer. The public-private key-pair used for crypto verification and secure sharing and login is created upon account registration. Next, the private key is used to sign a challenge generated by the server. Finally, the server checks the signature against the user’s public key on the server. If it is a match, the user has proven that they hold the private key and thus authenticated. The private key is never cached in the browser and requires to be added each time a user initiates a session in Granite.

The Granite system utilizes session locks. Every 5 minutes, the decrypted private key is wiped from memory. Once the key is wiped, any action results in a locked screen for the Granite session. As a result, the user will need to enter the correct password to re-decrypt the key whenever you take your next action in the system (ex: viewing a file, sharing a file, connecting to VM, etc.). After 15 min, the session becomes expired. This results in the invalidation of the user’s session so no requests to the backend can be made until the user successfully re-logins into the system.

Encrypted Drives  

In order for the VM to perform efficient computation, it needs access to fast, secure storage. This is provided in the form of encrypted drives. The drive encryption keys are generated and manipulated in the same manner as the file keys. The user-VM encrypted channel is used to transmit such keys to the VM during the start-up sequence.

The disk encryption happens inside the VM, under the control of the user who owns the VM, not the system administrators. The Controller utilizes widely available and tested disk encryption solutions, like BitLocker and LUKS, to handle the disk-level encryption.

VM Anti-virus  

Files are scanned by anti-virus software in the secure VMs when imported into the encrypted virtual drives and upon read or write by users. Anti-Virus definition file updates are made to Virtual Machine (VM) images on a monthly basis. Linux-level server storage is scanned daily to detect and eradicate malicious code. Malware discovered by scanners is deleted or quarantined, depending on the characteristics of the malware and the capability of the anti-virus software. Detection of malware is logged and reviewed monthly by the Research Computing staff. False-positive detections of malware are documented and tracked, with the ability to roll back malware definitions that create availability problems.

In addition, the VM images are immutable, meaning they boot each time from the frozen VM template each time. This ensures that any bad-actor modifications within the VM are never persistent.

Password Policies and Practice  

Granite password policy is based on the zxcvbn password library created by Dropbox to calculate the password’s strength. There are four levels of strength and Granite utilizes the highest level (4) for password security.

zxcvbn works in the following way:

  1. It provides a simple API that takes a password as input and returns a score from 0 to 4 as the output to indicate the strength of a password (0 - weakest, 4 - strongest).
  2. It estimates a realistic strength of the password, by detecting all the possible overlapping patterns and then matches it against several English dictionaries, common passwords, keyboard patterns and repetitions. This strength is represented in a metered bar for visualization. If the password does not meet the required strength, the user will have to pick a new password.

When logging into Granite, the user is allowed 5 failed attempts prior to lockout. After 5 failed attempts, the account’s status is set to inactive. Any attempt to login into a fixed account will fail until a Granite System Administrator unlocks the account by selecting the status to active.

Workstation Storage  

As noted above, user workstations are not trusted to hold sensitive data, and as such the Granite system prevents users from moving any files from Granite to the desktop, or vice versa. The exception is the person with the role of Data Manager, who has the ability to move data on and off Granite.

 Granite
Granite Policies 
On this page:
Granite Security Overview   Software Layer Details   User System Login and Lockouts   Encrypted Drives   VM Anti-virus   Password Policies and Practice   Workstation Storage  

     
Copyright © 2025 Dartmouth Research Computing & Data | Powered by Hinode.
Dartmouth Research Computing & Data (RCD)
Code copied to clipboard