I have a fairly generic question, whose answer I couldn't find in the API references.
When I send a document to DocuSign (using either SOAP/REST), do the contents get encrypted before being transmitted?
I know that the document goes over a HTTPS connection, but I wanted to know if there is any encryption happening before the document goes over the wire?
Only the transport (HTTPS) is encrypted. You will be providing the raw PDF bytes in base64 encoding for either REST or SOAP. If you were to encrypt the PDF before sending to DS then they would need a way to decrypt it.
Related
I have a keystring which allows customer to have additional features.
Obviously I would like the software to check that this string is valid, and not modified.
Is the following idea feasible:
get the key string as encrypted value, and encode it in Base64
(my encrypted string is around 100 characters, for my purpose)
calculate the checksum (MD5) of course using a private salt.
weave the checksum into the encrypted data
In principle :
xxxxCxxxxxxCxxxxxxxxCxxxxxxxxxxCxxxxxxxxxxxxxCxxx
the places to weave into the encrypted data could be determined by first cher of the encrypted, creating up to 16 different patterns.
On checking the code validity I simply "unweave" the checksum, test if it's correct, and thereby know if the data has been modified.
Is my line of thoughts correct ?
The cryptographic feature you're thinking of is called "authentication," and there are many well-established approaches. You should strongly avoid inventing your own, particularly using a long-outdated hash like MD5. When an encryption system is authenticated, it can detect changes to the ciphertext.
Your best approach is to use an authenticated cipher mode, such as AES-GCM. Used correctly, that combines encryption an authentication in a single operation. While decrypting an authenticated scheme, the decryption will fail if the cipher text has been modified.
If you don't have access to AES-GCM, the next option is AES-CBC+HMAC, which uses the more ubiquitous AES-CBC with a random IV, and appends a type of encrypted hash (called an HMAC) to the end of the message to authenticate it. In order to authenticate, you need to remove the HMAC, use it to validate that the cipher text is unmodified, and then proceed to decrypt normally. This scheme is generally called "encrypt then MAC."
The implementation details will depend on your language and frameworks.
My understanding of HMAC is that it can help to verify the integrity of encrypted data before the data is processed i.e. it can be used to determine whether or not the data being sent to a decryption routine has been modified in any way.
That being the case, is there any advantage in incorporating it into an encryption scheme if the data is never transmitted outside of the application generating it? My use case is quite simple - a user submits data (in plaintext) to the scripts I've written to store customer details. My scripts then encrypt this data and save it to the database, and my scripts then provide a way for the user to retrieve the data and decrypt it based on the record ID they supply. There is no way for my users to send encrypted data directly to the decryption routine and I don't need to provide an external API.
Therefore, is it reasonable to assume that there is a chain of trust in the application by default because the same application is responsible for writing and retrieving the data? If I add HMAC to this scheme, is it redundant in this context or is it best practice to always implement HMAC regardless of the context? I'm intending to use the Defuse library but I'd like to understand what the benefit of HMAC is to my project.
Thanks in advance for any advice or input :)
First, you should understand that there are attacks that allow an attacker to modify encrypted data without decrypting it. See Is there an attack that can modify ciphertext while still allowing it to be decrypted? on Security.SE and Malleability attacks against encryption without authentication on Crypto.SE. If an attacker gets write access to the encrypted data -- even without any decryption keys -- they could cause significant havoc.
You say that the encrypted data is "never transmitted outside of the application generating it" but in the next two sentences you say that you "save it to the database" which appears (to me) to be something of a contradiction. Trusting the processing of encrypted data in memory is one thing, but trusting its serialization to disk, especially if done by another program (such as a database system) and/or on a separate physical machine (now or in the future, as the system evolves).
The significant question here is: would it ever be a possible for an attacker to modify or replace the encrypted data with alternate encrypted data, without access to the application and keys? If the attacker is an insider and runs the program as a normal user, then it's not generally possible to defend your data: anything the program allows the attacker to do is on the table. However, HMAC is relevant when write access to the data is possible for a non-user (or for a user in excess of their normal permissions). If the database is compromised, an attacker could possibly modify data with impunity, even without access to the application itself. Using HMAC verification severely limits the attacker's ability to modify the data usefully, even if they get write access.
My OCD usually dictates that implementing HMAC is always good practice, if for no other reason, to remove the warning from logs.
In your case I do not believe there is a defined upside to implementing HMAC other than ensuring the integrity of the plain text submission. Your script may encrypt the data but it would not be useful in the unlikely event that bad data is passed to it.
In an app, I Have a network server and clients.
After a handshake, let's say the client sends "userId sessionId SOME_COMMAND param param param".
I have already identified the client and the sessionId is checked on the server accordingly, so identity is no more an issue.
But I'd like to prevent a hacker to modify the message or create a false one, for example sending "userId sessionId SOME_COMMAND paramModified paramModified paramModified".
I thought about using a pair of private/public encryption keys, and send the hash of the message in the message itself. But since it's automated in the client program, I may have to send the public key during the handshake. So the hacker could simply retrieve it and generate the proper hash.
I could also use complex encryption seeds or algorithms, but my experience with hackers has shown me that they will decompile anything.
So the bottom line is: I can hide everything that runs on the server, but I can't hide anything on the client program. And I'd like to to forbid to modify the message that the client program is supposed to send.
I don't even know if it's possible. And I'm opened to any suggestion. And by the way, I'm using Java, although it should not be very relevant. Thanks.
Forget it. Use SSL like everybody else. There are complexities which you haven't even begun to address.
I have a csv file that required to be encrypted. I want to ask that is there any difference between encrypt the content and encrypt the file? Or they are the same? Because our client doesn't clearly specify what they want?
Thanks,
Encryption will always produce binary result, which can be "armored" (base64-encoded and wrapped) then in order to get the text. All implementations conformant to OpenPGP standard handle armored data by decoding it to binary automatically, so it doesn't really matter what mode you specify. One special case is when you plan to paste the result to some other text data (such as text document), then armoring is mandatory.
Usually when they say PGP encryption, they are talking about commercial programs that encrypt a file or files into one gpg file with their public, which they can decrypt with their private key.
The other way is encrypt it yourself line-by-line in code (there are libraries that do that using file streams; very easy).
Your client one way or another has to tell you how that expect to decrypt the data later on, which will tell you how you encrypt in the first place.
I have an application which stores data to the persistent store by setting the contents of the PersistentObject as a hashtable, e.g. saving preferences is done by entering strings as the keys and values of the hashtable and then setContents is called on the PersistentObject with the Hashtable passed as the parameter.
I understand that the data is saved unencrypted. If I enable content protection in the IT policy for the device will this implementation of persistent storage automatically start encrypting the data or do I have to change the implementation to use for example the ContentProtectedHashtable for saving the contents?
All the information I have found so far about content protection has been with regards to the BES IT policy and nothing about implementation in the application, which makes me think that the standard implementation (i.e. just commiting a Persistable object to PersistentObject object) is adapted automatically to encrypt the data??
Any ideas?? Thanks.
See the documentation for net.rim.device.api.util.ContentProtectedHashtable for one way to implement content protection.
Also see this document for a more in depth discussion of content protection.
I don't think it has something to do with IT policy, it's rather PersistentContent which has encryption/decryption functionality:
This API was designed to allow applications to protect data in a database if the user has enabled Content Protection/Compression in their device's security settings. It consists of two main methods (encode and decode), as well as a number of helper methods.
...
Note that encoding can be performed anytime, whether the device is locked or unlocked. However, an object that was encoded using encryption can only be decoded if the device is unlocked. This can pose a problem if the device locks while an application is performing a potentially long operation during which it requires the ability to decode encrypted data, such as sorting encrypted records. In this case, the application can obtain a ticket. So long as a strong reference to a ticket exists, decoding encrypted data is allowed. Thus, applications should release tickets as soon as possible to allow the device to reach a locked and secure state.
See riccomini - code blackberry persistent store for encryption implementation.