The following idea is part of an RSA internal innovation contest. We are sharing these ideas to gather feedback from customers and help employees improve on their concepts. Please share your reactions to this idea by Voting and/or Commenting below. There are 8 total ideas to review now through Aug 23. You can find additional ideas here.
If you are interested in being a potential development partner on this or another idea, please use the comment button or send an email to firstname.lastname@example.org.
** REMINDER ** This is an internal RSA conceptONLY and has not been committed to development or product roadmap.
- RSA Labs
Implementation of an SHF would allow secure and transparent change of encryption algorithm and keys at any endpoint. This also preserves an endpoint’s ability to decrypt the original contents paving the way for post-quantum cryptography.
The SHF defines a common standard for prefixing data files with a meta-data block. This SHF may include such content as:
- Security details
- Crypto signature of metadata and file contents
- File checksum
- File MIME-type
- Description and ancillary details about the associated file
- File data content
- Non-encrypted key-words or tags
- File encryption algorithm (if used)
- Location of encryption key manager system
- Key manager type (KMIP, etc)
Potential use cases include:
- Allowing encrypted HIPAA protected health data to be transferred between recording devices and medical facilities upon approval from users (eg: Apple Watch to Hospital).
- SHF compliant applications can gain insight into file content and classification via metadata without decrypting and inspecting actual file contents.
- Secure and transparent exchange/replacement of encryption algorithms while preserving end-point crypto ability.
- 3rd party applications can verify file integrity and authenticity prior to opening the file and inspecting its contents.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.