Whitepaper Cubby: A secure solution. A technical overview of Cubby s secure, enterprise-grade infrastructure.

Transcription

1 Whitepaper A technical overview of Cubby s secure, enterprise-grade infrastructure.

2 Contents Introduction 3 We ve Got Your Back 3 Enycryption 3 Data center security 3 LogMeIn company security policies 4 Tools Under Your Control 4 Track your organization s data 4 Auditing, logging and reporting 4 View cubby contents 4 Data removal and lockout 4 Authentication and Identity 5 Authentication basics 5 Two-step verification 5 Provisioning 5 Additional authentication related security controls 6 Setting security policies 6 Controlling Cubby use via cubby.com 6 Using AppGuru to set Cubby policies 6 Additional features that protect data in cubbies 7 Compliance 7 HIPAA 7 PCI 7 FIPS 8 Other standards 8 Integration with Other LogMeIn Products 8 Conclusion 8 Appendix: A Closer Look at Cubby Cryptography 8 Encryption of data at rest 8 Encryption of data on computers 8 Encryption of data on mobile devices 9 Encryption of locked cubbies 9 Sharing data 9 Data in motion: Security of shared files 10

3 Introduction Cubby by LogMeIn was built as a secure, enterprisegrade solution for using the cloud in business. With Cubby, your organization can rest assured that all data is secure in transit, at rest or when being shared. Cubby gives you tools to track data, prevent data leakage and comply with security rules and standards. I. We ve Got Your Back LogMeIn is at work behind the scenes ensuring enterprise-grade security. Enycryption How is data encrypted? Who can access keys? Cubby uses SSL to protect data in transit. Data stored in the cloud is encrypted on disk in a state-of-the-art, secure data center in the USA. The servers and supporting infrastructure belong to LogMeIn and can only be accessed by a small team of system administrators, all of them LogMeIn employees. DirectSync transfers are secured using public/private key encryption on the pipe between computers. Each computer running the Cubby desktop application is assigned a private key that never leaves the computer. This guarantees that no one can see what s being transferred between your computers via Cubby. Tip: For extra assurance that nobody can see your sensitive files without authorization, try Cubby Locks, available with an enterprise or pro subscription. With Cubby Locks, not even LogMeIn can see unencrypted data, and only you have access to the keys. For a detailed technical discussion of Cubby encryption, see Appendix: A Closer Look at Cubby Cryptography. Data center security Where is the data center? How is it protected? Cubby data is stored at LogMeIn s proprietary data center in Ashburn, Virginia, United States that uses a highly redundant server infrastructure. The Ashburn site is SSAE SOC-1 Type II certified. SSAE SOC-1 Type II audits minimize the need for multiple sets of auditors to separately examine the same set of controls that govern a third party s services. SSAE Type II service-auditor reports include the same data as Type I reports (i.e., the service auditor s opinion on the fairness of the provider s description of its controls and how well they re designed to meet specified control objectives), as well as the auditor s opinion on the effectiveness of the controls during the period under review. The data center uses a wide variety of security equipment and procedures to control, monitor, and record access to the facility, including customer cage areas. Physical design features. Data centers use windowless exteriors for colocation and floor areas. Security systems have dedicated uninterruptible power supply systems and standby emergency power (generator) support. State of the art security monitoring. All areas of the center, including cages, are monitored and recorded using closed circuit television (CCTV) and access points are controlled. The alarm monitoring/intrusion detection subsystem monitors the status of various devices associated with the security system, such as alarm contacts, glass breakage detectors, motion detectors, and tamper switches. Systems to prevent intrusion. Cage security is provided through three levels of access control: hand geometry readers at the cage entrance, keyed locks at each cage, and if the cabinet is located in a sharedcage environment, the cabinet door includes a selfpowered, keypad-activated lock. Access histories can be downloaded through a data-port and are available to the customer for auditing purposes through SmartHands. Additional cyber security controls are in place. For example, analysts from LogMeIn s Network Operations Center team monitor data center logs for potential threats. Cubby network architecture is comprised of three security zones, with limited access between them. This ensures that only authorized personnel are able to transit or interact within each of the different network zones. These network zones consist of Public, Private, and ILO (Integrated Lights Out) network zones. ILO is connected to all servers through dedicated admin servers. Additional information about infrastructure security, redundant systems, monitoring and alerting mechanisms, physical access to data centers, troubleshooting, and failover is available under non-disclosure agreement. 3

4 LogMeIn company security policies Is data safe from LogMeIn employees? Both LogMeIn and the Cubby team are committed to maintaining the security of user information. International Privacy Protection. For personally identifiable information collected from users in the European Economic Area and Switzerland, LogMeIn adheres to the Safe Harbor Principles administered by the U.S. Department of Commerce. Information Sharing and Disclosure. LogMeIn does not transfer personal information to third parties, except when required to do so by law or in the good faith belief that such action is necessary to conform to the law, protect and defend LogMeIn s rights or property, act in urgent circumstances to protect employees or users or members of the public, or to effect a transaction/ restructuring/proceeding that transfers to a third party the assets or line of business to which the information pertains. Users may opt-out of receiving promotional materials at any time. Cubby Locks for extra assurance. Cubby Locks gives you extra assurance that nobody can see your sensitive files without authorization. For technical details, see Encryption of Locked Cubbies below. II. Tools Under Your Control We give you the tools you need to make Cubby as secure as you want it to be. Tracking your organization s data Auditing, logging and reporting The activity log provides insight into user activities and helps monitor data loss and leakage. Events captured in the log show what content is being shared, how, and with whom. If it s necessary to investigate specific policy breach or threat, administrators can filter events by employee, event type, or date. Tracked events include the following: When a cubby is shared Whether a share is accepted or declined When a cubby is deleted When content is permanently deleted from a cubby If archived versions of information are removed from a cubby When a user leaves a shared cubby When public links are created When a cubby is synced to a device When a wipe is initiated and completed When a device is removed from Cubby View cubby contents The team leader of an enterprise account can view the actual content of team members cubbies that have not been locked. Data removal and lockout Team leaders can wipe team members data in two ways: By suspending a user and wiping all data from their local devices, or by keeping the user active and wiping data from selected devices. Users themselves can wipe data from their own local devices. Device wipe revokes access to the Cubby application, removes stored passwords, and deletes files that have been saved locally. This functionality is useful if a user s laptop is either lost or stolen or the employee leaves the company. The Cubby application must be online to receive the wipe command. Once the wipe command has been received, synced files are deleted. When wiping a mobile device, a user s access to the Cubby app is revoked and all files saved for offline access are deleted. Although end users and IT administrators can both use device wipe, it s important to note that end users can only wipe their own devices and synced data, while administrators can wipe devices and synced data belonging to anyone in their organization. Under the Hood: Mobile device wipe Under normal circumstances, when users log into the Cubby service via the Cubby mobile app, that device gets a unique client ID. Mobile devices communicate with the Cubby.com website through API URLs. The client ID is always appended to the API call to identify caller devices. When a user invokes mobile device lockout, however, the client ID is invalidated. When the Cubby mobile app initiates an API call to the Cubby.com website, the mobile app detects that its client ID was removed from the system. In response, the mobile app resets its state and all Cubby files stored on the mobile device are deleted. 4

5 Authentication and Identity How do users authenticate? How are accounts protected? Authentication basics When a user creates a Cubby account they are utilizing the Common Login Service, LogMeIn s authentication service for most LogMeIn products, to create a LogMeIn ID (username and password combination). Users are required to create passwords that are between six and 255 characters in length. Administrators are also allowed to set up domain verification and let users log in with their enterprise credentials. Cubby allows four consecutive login attempts. If invalid login information is provided, the system will show an incorrect username and password message. Upon the fifth failed attempt, a CAPTCHA validation is required. If users forget their password, they can request a forgot password link which is valid for a 24-hour period. Requests for forgot password and change links can only be sent once per hour. For accounts with locked cubbies, users should reset their password by providing their unique Recovery Key, otherwise they lose all data in locked cubbies. Users can elect to remain logged in by selecting the keep me logged in option. Sessions will time out after 20 minutes. Two-step verification By enabling two-step verification, users can add extra security to their Cubby account. Without this functionality, anyone who knows a user s password can access their data. Once two-step verification is set up, the cubby.com login procedure changes: After entering their LogMeIn ID and password at cubby.com, users are also required to enter a one-time code that they get from either a paired mobile authenticator app or via . Users can turn off two-step verification at any time. Note: The Cubby/WebDAV integration does not support two-step verification. Active Directory Integration IT administrators can enforce domain credentials for users by configuring ADFS. By configuring ADFS for LogMeIn, Cubby, and join.me authentication, members of your organization will be able to log in to LogMeIn.com, cubby.com, and join.me using their corporate AD credentials. Users will not need to create a unique LogMeIn ID since their domain ID serves that purpose. Once configured, ADFS becomes the exclusive authentication method for your domain, which gives you complete control over who can access LogMeIn.com, cubby.com, and join.me. The result is a secure authentication methodology that simplifies and automates the sign-in process for your users. When a user enters an address with a valid domain, the LogMeIn Common Login Service recognizes the address and prompts the user to log in with their domain credentials (that is, the same and password they use to log on to your network). AppGuru and Active Directory Enterprise customers can also use AppGuru by LogMeIn to provision and manage Cubby access with Active Directory. By entering your domain admin credentials when prompted by the AppGuru Client, users, groups and organizational units from Active Directory will automatically populate AppGuru s cloud directory. Users, including specific groups and roles setup in Active Directory, can be easily provisioned and de-provisioned to Cubby when they leave the company. AppGuru also handles license management and shows how many cloud application licenses are currently in use by employees. The integration between AppGuru and Cubby has been architected to ensure that user information remains secure. User authentication for both AppGuru and Cubby is provided by the LogMeIn Common Login Service (CLS). Key points include the following: The CLS provides an internal API which verifies the identity of the logged in user. The API is only available to LogMeIn applications. API calls to the CLS are made over HTTPS. All HTTPS traffic uses 128-bit encryption. With every HTTPS call, the caller verifies the identity of the server. AppGuru provides a security token for every request. The Cubby API uses this token to identify users. 5

6 Additional authentication related security controls Once users are logged into Cubby, they can modify additional security controls which include: Changing their LogMeIn ID Changing their password Configuring who receives notifications about account changes Configuring which account changes will trigger a notification -- For example, upon failed login, upon successful login, or when notification settings change -- Note: Account owners are always notified if the or password associated with the account is changed Setting security policies How can the use of Cubby be controlled? Controlling Cubby use via cubby.com Using management features available on the cubby.com website, administrators can ensure that corporate security requirements are met, prevent accidental sharing of documents and files, and reduce the overall organizational risk associated with mobile and distributed teams. Through Cubby Enterprise, there are several Cubby policies that can be configured to prevent data leakage. For example, IT administrators can enable or disable: Access to Cubby on cubby.com and via mobile devices Access Cubby on a mobile device without a passcode The ability to sync and store data on devices Creation of cubbies Sharing cubbies and re-sharing cubbies Accepting shares from individuals outside the organization The ability to create public links and grant access to them outside the team Using AppGuru to set Cubby policies AppGuru allows an administrator to set policies for individuals, groups of users, or an entire organization. While the actual permissions are the same as on the web site, AppGuru gives a finer level of control when compared to the cubby.com management interface because AppGuru allows users to be arranged in policy groups. Invite others to a cubby they own Share with anyone or only with people within your own domain Invite others to a cubby owned by someone else Accept shared cubbies from people outside the organization Create Internet links that anyone with the link can access Create Internet links that can be accessed from within your domain 6

7 Additional features protecting data Cubby Locks Cubby Locks gives you extra assurance that nobody can see your sensitive files without authorization. Once a user locks an individual cubby, all content within the cubby is held encrypted and they need to enter their password to access or share it. They receive a special code called a Recovery Key. Should they forget their password, they must provide the Recovery Key to regain access to the locked cubbies. Please note that users are able to change their password without a Recovery Key; the Recovery Key is only required when resetting a lost or forgotten password. For a detailed technical discussion, see Encryption of Locked Cubbies in the appendix. Restore Deleted Files When a user syncs files with the cloud, all revisions are archived. Users can restore a file that they may have deleted from their local computer or mobile device. Mobile Passcode Mobile passcodes give an extra security layer in case a phone or tablet is lost or stolen. Mobile passcode is supported for ios and Android operating systems. This functionality enforces the use of a mobile passcode to unlock the phone; otherwise the system denies access to the Cubby application. It is important to note, however, that mobile passcodes do not prevent access to files that are saved on a mobile device if the passcode is bypassed or compromised. To prevent access to files, users can wipe their devices from the Cubby website, under the Devices tab. The next time the Cubby application is opened on the device and the device has an Internet connection, Cubby will recognize that it was removed from the devices list and all locally saved files and data will be deleted. To enable a mobile passcode, users enter a four digit number. The passcode is not stored in plain format. For ios, a derived value is saved in the keychain (secured storage of ios). For Android, a derived value is saved in the private preferences. Users can set parameters which determine what delay time is acceptable to skip the password window. If the Require immediately option is set, then the passcode must be entered whenever Cubby starts from the background. If the Require immediately option is turned off, the user only has to enter the passcode if the application was closed more than 15 seconds ago. At any time, Cubby users can change their mobile passcode or turn the functionality off (for enterprise users, only if allowed by an administrator). If users fail to enter their current passcode, an error message appears and a counter which shows how many failed attempts occurred in a row. This counter will only be reset when the user enters his or her passcode successfully. After five failed attempts, the user is logged out from the Cubby application and locally saved files, settings, and data are wiped out. III. Compliance HIPAA When used and configured properly, the technical security features employed by Cubby satisfy the technical and physical security safeguards required by HIPAA. As a result, Cubby users can confidently incorporate Cubby into their information-management system without affecting their HIPAA compliance. Providing a managed sync/share solution for your employees also helps ensure that data is not being sent to unauthorized tools that are not being monitored by IT. LogMeIn encourages Cubby users who plan on stating and sharing Protected Health Information through Cubby to review these security features and consider their specific use case to ensure they properly configure their Cubby in order to achieve compliance with applicable HIPAA-mandated administrative, technical and physical security safeguards. Also, make full use of the logging and monitoring features within Cubby to ensure it is being used properly to meet your compliance needs. PCI Cubby users can confidently incorporate Cubby into their information-management system without affecting their PCI compliance. Cubby servers protect all information transmitted with full, end-to-end 256-bit SSL encryption, the same encryption method endorsed by MasterCard, Visa and American Express. Cubby further supports PCI compliance efforts by providing centralized user management and two-factor authentication and by implementing strict information security policies as detailed herein. 7

8 FIPS Cubby servers utilize FIPS-validated cryptographic modules provided by Microsoft but do not force the use of cryptographic algorithms that are FIPS 140 compliant or in compliance with FIPS-approved modes of operation. LogMeIn does not provide cryptographic products or components; therefore LogMeIn itself cannot apply to receive a FIPS 140 security level rating or validation. Other standards Feel free to contact your LogMeIn representative for assistance with other standards or compliance concerns. IV. Integration with Other LogMeIn Products Cubby security for join.me customers LogMeIn s join.me online meetings and collaboration product is integrated with Cubby. This integration enables users to store meeting recordings in a cubby. In join.me, Cubby public links are visible and serve as the means for accessing meeting recordings. Security is handled using the Cubby infrastructure, encryption, and data processing. It s important to note the following: join.me uploads meeting recording to Cubby using the Cubby Web Distributed Authoring and Versioning (WebDAV) interface. WebDAV is an extension of the Hypertext Transfer Protocol (HTTP). In the context of join.me and Cubby, however, the WebDAV interface uses an HTTPS based secure channel. As information is uploaded and downloaded, it uses the same flow as WebDAV. This includes encryption, key management, authentication, and authorization. Cubby public links that appear in join.me are managed using a Cubby API. Users are authenticated when they log into join.me. When join.me users save meeting recordings in Cubby, the same single sign-on information is used. As a result, users do not have to enter their login credentials again in order to store meetings in Cubby. Cookies. The Cubby website uses cookies to track user traffic patterns. This information is used to determine the usefulness of the website information to users and to see how effective the navigational structure is in helping users reach that information. V. Conclusion LogMeIn and Cubby strive to prevent data leakage through a holistic, but flexible view of security. In addition to the benefits associated with Cubby s robust data center infrastructure, IT administrators and individual users have the flexibility to configure security policies that best meet their individual needs. The Cubby team has created safeguards at each stage of the data lifecycle to ensure that user information is secure. Appendix: A Closer Look at Cubby Cryptography Encryption of data at rest Cubbies are the way users store data at rest in the cloud. All data at Cubby data centers are stored in encrypted form, using an AES-256 symmetric algorithm. The key used in this context is the Cubby Data Key (CDK), which is a cryptographically strong and randomly generated for each new cubby. CDKs are stored in the database, along with other cubby properties. When a user logs into Cubby.com, a web application fetches the CDK from the database. The web application uses the CDK for encrypting and decrypting data when files are uploaded and downloaded from a cubby. A user can choose to provide an extra layer of security to their CDK by using a feature called Cubby Locks. Cubby Locks gives users extra assurance that no one, including LogMeIn employees and third parties with direct access to the Cubby data center, can view their sensitive files. Encryption of data on computers When a Cubby client application is installed, the computer generates an RSA key called the Host RSA Key (HRK) and a symmetric key called the Host Symmetric Key (HSK). HRK is stored in the crypto store / key chain, while the HSK is stored encrypted with the HRK in the Cubby host configuration. The RSA key is used to authenticate the computer to other Cubby computers when connecting through a peer-to-peer tunnel via DirectSync. The private part of the key never leaves the computer. The client application encrypts all files using CDK before uploading them to the cloud. All data downloaded from 8

9 the cloud by the Cubby client application are decrypted using the CDK before being written to local storage. CDK is deployed when a cubby is synced to a local computer. If the cubby in question is a standard (not locked) cubby, then CDK is simply read from the central database. If the cubby is locked, then the user must enter their LogMeIn ID password to decrypt the CDK from the central database. User password USK (User Symmetric Key) URK (User RSA Key) (private) CDK For both standard and locked cubbies, the CDK is then stored in the local computer s cubby.db, encrypted with HSK. When a user decides to stop syncing a cubby to a specific computer, the CDK is deleted from the cubby database file. Computer s user account protected crypto store / key chain HRK (private) HSK CDK Encryption of data on mobile devices Each mobile device is tied to one LogMeIn user account and assigned a DeviceID and Password at the time of the installation. A Cubby app can only be used to access content on the cloud or saved locally for offline access. The CDK is never sent to a mobile device: encryption/ decryption is performed by the web servers in the same way as when accessing the cloud from a browser. When accessing a locked cubby, a LogMeIn ID password must be entered, thus allowing the CDK to be decrypted and temporarily stored by the web servers. The decrypted CDK key remains available on the web servers for 20 minutes and is available to open a single locked cubby. In effect, this means that the user must enter their password once every 20 minutes for each locked cubby they want to access. User password USK URK (private) CDK The CDK is cleared from server memory when the web session is closed or times out. Encryption of locked cubbies Data in a locked cubby can only be decrypted with the user s LogMeIn ID password. This is one reason why Cubby users are prompted frequently for their password and why no one can read data in a cubby without knowing the user s password. It s also important to note that passwords aren t stored by Cubby or any other LogMeIn service. Cubby Locks are based on a cryptographic framework that provides confidentiality for user data stored in the Cubby cloud. Cubby Locks security relates exclusively to data at rest in the cloud and does not make data on devices more secure. Each user with a locked cubby, or who has accepted an invitation to a locked cubby, has a system-generated symmetric key called the User Symmetric Key (USK). The USK is encrypted with the user s password and is stored in AES-256 encrypted form in the database. A 4096-bit RSA key pair is generated called the User RSA Key (URK). The private part of the URK is AES-256 encrypted with the USK and stored. The public part of the URK is stored in plain text. Both the USK and URK are specific to and generated for the user account. The use of asymmetric encryption means that anything encrypted with the public key can only be decrypted with the private key and vice versa. When a cubby is locked, the system encrypts the CDK with the public part of the URK, stores it, and deletes the plain text CDK from the database. This means that every link in the encryption chain is stored in encrypted format in the Cubby database. User password USK URK CDK Access cubby data When a cubby owner locks a cubby, a Recovery Key (RK) is also generated. This is a cryptographically random, 32-character alphanumeric string. There is only one Recovery Key per user and this key must be used if a user forgets their password and resets it. When a Recovery Key is generated, the following occurs behind the scenes: The USK is also encrypted with the Recovery Key using AES-256. Two copies of the USK are stored in the database one that is encrypted with the password and one that is encrypted with the Recovery Key. When the cubby owner locks a second cubby, the system checks for an existing Recovery Key. If found, it is decrypted by the user s password. This is done so the user can be reminded of their existing Recovery Key. 9

10 When a user goes through the forget password process and enters their Recovery Key, the key is used to decrypt the USK, which is re-encrypted with the newly created password. Since the Recovery Key is stored in the database encrypted with the URK, it s only available to view on line after users enter their password. Recovery Key USK URK (private) CDK Access cubby data User password USK URK Recovery Key The required chain of encryption to access a locked cubby is: User password USK URK (private) CDK Access cubby data Sharing data When sharing a cubby with another user, the CDK must be transferred to the share recipient. If the cubby is unlocked, the CDK is stored as plain text in the database, so no action is required. When sharing a locked cubby, the owner enters the password that decrypts the CDK: User password USK.Inviter URK.Inviter (private) CDK If the invitee is an existing Cubby user, then the CDK is encrypted with the invitee s public key and stored in the database. CDK URK.Invitee (public) If the invitee is not a Cubby user, then a temporary key is generated that is sent to the invitee. This temporary key is also used as a key to encrypt the CDK. The hash of the temporary key is stored in the database. When Cubby Locks is turned on for a cubby, all related public links are deleted. Data in motion: Security of shared files File sharing is an essential part of collaboration whether sending files to a cloud-based repository or syncing files between computers. Data transferred between devices and the Cubby cloud is always transmitted over SSL/TLS with all cubbies even those that are not locked. Users can use DirectSync (peer-to-peer) to share information between their own devices or with others without the Cubby cloud. DirectSync relationships are forced between devices and Cubby accounts by turning off the cloud and then sharing a cubby. When using DirectSync, each computer must be powered on and running Cubby to stay in sync. Any computer that was off will start syncing when it is powered on. Cubby always establishes direct UDP connections between clients unless prevented by the firewall or NAT configuration, in which case data is relayed through Cubby data centers using a TCP based, E2E secure SSL tunnel. Computers on the same LAN most likely communicate directly using UDP socket. During DirectSync, SSL/TLS encryption is used and the private portion of the RSA key never leaves the client computer, and is stored in crypto store (keychain). åto prevent the injection of a malicious computer to a cubby, the existence of the proper CDK is validated upon peer handshake. A challenge-response handshake protocol takes place in the background that guarantees that both connecting parties have knowledge of the proper CDK. In the case of locked cubbies, the CDK cannot be obtained without the account password. CDK TemporaryKey When the new user registers, the Temporary Key from the invitation link is validated against the hash in the database, and then the temporarily encrypted CDK is deleted from the database and encrypted with the newly generated public key of the invitee. A USK will be generated in all cases when the user does not have a USK (for example, new users). 10

11 Figure 1: Overview of the key hierarchy Quick Reference: Cubby Security Keys TPDK (Temporary Password Derived Key) USK (User Symmetric Key) 256-bit AES key A symmetric key that is generated when a user first logs into Cubby[mz3] The USK is encrypted with the user s password and is stored in AES-256 encrypted form in the database URK (User RSA Key) A 4096-bit RSA key pair The private part is encrypted with the USK and stored The public part is stored in plain text Asymmetric encryption dictates that anything encrypted with the public key can only be decrypted with the private key and vice versa Not to be confused with RK (Recovery Key) described below CDK (Cubby Data Key) 256 bit AES key A key that is randomly generated for each new cubby Used for encrypting and decrypting data when files are uploaded to and downloaded from a Cubby RK (Recovery Key) 256 bit key Randomly generated key, used in case of forgotten password 11

12 Notations Notation E(K,m) D(K,c) A B m_k H(K,m) H(m) Kx Sx Nx X Definition Encryption of the m plain-text message using K key Decryption of c ciphertext message using K key Concatenation of operands A and B Encrypted version of m plain-text message, encrypted with K key Keyed hash of m plain-text message using K key Hash of m plain-text message Cryptographic key, assigned to the x entity Cryptographic salt, assigned to the x entity Cryptographic nonce, assigned to the x entity Value x is loaded from storage. +K Public Asymmetric Key -K Private Asymmetric Key K Symmetric Key KDF(m,p) Key Derivation Function, performed on the m message with p parameter tuple The Cubby Locks Engine handles encryption key generation, management and disposal. Key Generation. This is performed using standard software-based (OS/.Net API) random number generator algorithms. These have been designed to provide sufficient entropy for cryptographic purposes. Key Management. For key management, the Cubby Locks Engine uses symmetric ciphers to encrypt large amounts of data. Asymmetric cryptography is only used when working on cryptographic keys with a limited size. Key Disposal from memory. When locked cubbies are handled, no encryption keys are stored together with the encrypted material. During operation, certain keys have a limited lifetime within the memory and are disposed of as soon as possible. Keys are removed from memory using the services of the underlying operating system. Key Disposal from database. When stored keys are disposed of, database records are updated to reflect key removal. When a cubby is locked, the system encrypts the CDK with the public part of the URK, stores it, and deletes the plain text CDK from the database. All rights reserved, LogMeIn Summer Street, Boston, MA cubby.com