I plan to use the micro-ecc C code on my microcontroller-based end unit to create a uECC_secp256k1 public and private keys pair.
When connecting to a C# server, it will receive the server's raw 64-byte public key and send back to the server the end unit's raw 64 bytes public in order to reconstruct a common shared secret that will be used for AES256 encryption of messages while connected.
I want to send the keys in raw format since I do not want split IP packets. My communications protocol can handle raw binary data.
I tried using the C# BouncyCastle library but do not see how I can convert my 64 byte[] array into an ECPublicKeyParameters variable in order to reproduce the AES256 key.
Related
Question: Is there a technical explanation how client side code-signing can be used in enterprise enviroments with open source tools like signtool or openssl?
In my usecase, I want to create a hash of a code file and sent the hash on a seperate server. This server is just used for signing. On this server are also the certificates and private keys stored.
After the hash is signed, I want to transfer the signed hash back to the client and envelope the signed hash with the code file e.g. a .exe file.
In the "Mircosoft Code Signing Best Practices", it's also recommended to first create a hash of the data and then sign the hash value with a private key.
Unfortunately I can't find any further informations how to implement this with seperate steps, described as abow.
http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc
"In practice, using public-key algorithms to directly sign files is inefficient. Instead, typical code-signing procedures first create a cryptographic hash of the data in a file—also known as a digest—and then sign the hash value with a private key. The signed hash value is then used in the digital signature. The digital signature can be packaged with the data or transmitted separately. A separately transmitted digital signature is known as a detached signature."
At the moment I want to implement a method that stores certain data server-side only encrypted. For this procedure is provided that each authorized user receives a private key, with which he can store and read encrypted data. Now it is so that several authorized persons are allowed to look at the same encrypted content. This means that if person A stores data encrypted with his private key, person B (if authorized) can also read this data with his private key.
The idea of implementation:
For all authorized persons, a single symmetric key is generated on the server side. The key is used to encrypt and decrypt plain text data. Now, for each individual claimant, a key pair is generated (public and private). With the public key, the symmetric key is encrypted and stored for the user and there are several of these asymmetrically encrypted symmetric keys on the server. The private key is given to the user (as a file download, HTTPS), which later can be used to decrypt the encrypted symmetric key. Therefore He can upload his private key before writing or reading encrypted data, in a web application (client side) and send it to the server. The Server uses the private Key to encrypt the content of the user and save it, or decrypt older content and send it in plain text to the user.
My problem now is that the weak point is the server, where the private key of the user must first be sent to encrypt and decrypt. There might be someone with access this private key secretly intercept and save.
My question now: Is there an alternative to the approach or does one have to do so if he wants to implement such a procedure? It is important that the data is stored only encrypted. And also this must be implemented with a client web-application and a backend.
Scenario
A SOAP web service provides an interface for retrieving documents and data. Security is paramount.
WS-Security is used and both the client and server encrypt and sign the entire SOAP envelope.
Questions
Should the private key used for signing be compiled into the application and stored on the device or should it provided by the server using a key exchange protocol (perhaps after authentication of the user)?
Should the private key for decryption be stored on the device or provided by the server?
Is it realistic to have a unique key for each file that is to be decrypted by the server (if uploading from client) or decrypted by the client (if downloading from server)?
Just a couple suggestions:
-You should consider symmetric keys embedded into anything outside your server as public due to reverse engineering (i.e. don't bother even encrypting if the key is out in the wild).
-You should use a per-session symmetric key generated by a secure RNG on the client, and transmitted to the server encrypted with the global asymmetric public key. Private keys have a shelf-life.
-You can use the session key for all files/streams transferred in that session, but you should use a unique nonce to salt the symmetric-key encryption for each file. Depending on the encryption mode, using the same key/nonce with more than one stream can leave you vulnerable to XOR'ing the two streams and recovering a mashed-together but unencrypted result.
The entire concept of a private key is defeated if it has to be transmitted from one device to another. Each end of the communication channel must generate their own private keys. Note, that this doesn't mean compiling private keys into an executable, because then everyone with the executable shares a private key, which is obviously not what you want. Each individual device has to use a cryptographically secure source of random numbers to generate it's own public/private key pair. Then public keys can be exchanged in the clear, you can use them to exchange session keys (which can be unique for each and every file), private keys can sign, and everybody is happy.
But remember: Never, ever hard code private keys, and never, ever share them with anybody.
I'm working on a Single Sign On solution to allow my company to integrate with other vendors.
As I'm doing my research, one thing is constantly confusing me.
My understanding of Public/Private key is that data is always encrypted with the vendor's public key and they decrypt using their private key. So far so good.
However, to validate that the message is really coming from me, I will compute the hash of the message and encrypt the hash with my private key (this process is also known as signing). To verify that the message is coming from me, the vendor will use my public key to decrypt the Hash and compare it with the unencrypted hash. If they match, the vendor can be confident that it came from me.
So how come my private key is used to encrypt the message..and how can public key decrypt the message? I thought Asymmetric keys doesn't allow that..! i.e Public Key always encrypts and private key always decrypts. Any explanations will be greatly appreciated..!
Encryption and signature are two different systems. In some ways, they work in opposite directions.
With public-key encryption, anybody can encrypt data with the public key. Only the owner of the private key can decrypt encrypted messages to recover the data.
With signatures, only the owner of the private key can sign messages. Anybody can use the public key to verify the signature of a message.
My understanding of Public/Private key is that data is always encrypted with the vendor's public key and they decrypt using their private key.
That's correct. But it only covers public-key encryption, not other uses of public-key cryptography such as signatures.
However, to validate that the message is really coming from me, I will compute the hash of the message and encrypt the hash with my private key (this process is also known as signing).
Actually, this process should only be known as signing. Calling it “encrypting with my private key” is very misleading: that's not the way it actually works. There is one popular type of keys (RSA) which can be used for both signature and encryption, but even with RSA, the signature and decryption mechanisms are different.
To verify that the message is coming from me, the vendor will use my public key to decrypt the Hash and compare it with the unencrypted hash. If they match, the vendor can be confident that it came from me.
That's not quite correct. Many signature algorithms are not deterministic. Verifying a signature is not done by reversing the signature process, but by making some slightly different calculations involving the signature, the message and the key.
So how come my private key is used to encrypt the message..and how can public key decrypt the message? I thought Asymmetric keys doesn't allow that..! i.e Public Key always encrypts and private key always decrypts. Any explanations will be greatly appreciated..!
The private key is used to sign the message, not to encrypt it. The public key is used to verify the signed message, not to decrypt it.
i found this link very helpful :
http://www.nusphere.com/products/library/ssl.htm
Wayback Machine archive from 2007 of the above nusphere link.
HTH
Ohad
EDIT
after 2.5 years, I see that the link is broken. So this one is good as well.
And in case it will be broken again in 2.5 years from today, here is the summary:
The Public Key is what its name suggests - Public. It is made
available to everyone via a publicly accessible repository or
directory. On the other hand, the Private Key must remain confidential
to its respective owner.
Because the key pair is mathematically related, whatever is encrypted
with a Public Key may only be decrypted by its corresponding Private
Key and vice versa.
Public Key Cryptography can therefore achieve Confidentiality. However
another important aspect of Public Key Cryptography is its ability to
create a Digital Signature.
The difference between symmetric and asymmetric encryption is only the existence of private and public keys.
Nevertheless in the common algorithms you can use the private key to encrypt messages which can be decrypted with the public key and you can also decrypt messages which are encrypted with the public key. So it is possible in both directions.
I know almost nothing about cryptography, but I would like to figure out how to encrypt
an HTTP live stream and decrypt it on an iphone.
The apple docs for HTTP encryption read as follows:
Media files containing stream segments may be individually encrypted.
When encryption is employed, references to the corresponding key files
appear in the index file so that the client can retrieve the keys for
decryption.
When a key file is listed in the index file, the key file contains a
cipher key that must be used to decrypt subsequent media files listed
in the index file. Currently HTTP Live Streaming supports AES-128
encryption using 16-octet keys. The format of the key file is a packed
array of these 16 octets in binary format.
The media stream segmenter available from Apple provides encryption
and supports three modes for configuring encryption.
The first mode allows you to specify a path to an existing key file on
disk. In this mode the segmenter inserts the URL of the existing key
file in the index file. It encrypts all media files using this key.
The second mode instructs the segmenter to generate a random key file,
save it in a specified location, and reference it in the index file.
All media files are encrypted using this randomly generated key.
The third mode instructs the segmenter to generate a random key file,
save it in a specified location, reference it in the index file, and
then regenerate and reference a new key file every n files. This mode
is referred to as key rotation. Each group of n files is encrypted
using a different key.
You can serve key files using either HTTP or HTTPS. You may also
choose to protect the delivery of the key files using your own
session-based authentication scheme.
Using encryption method 1, this is what I think I need to do:
generate a key, using a cipher, and make key available to segmenter
segmenter inserts URL of key into index file
store this cipher in iphone (keychain?)
point movie player to URL of m3u8 playlist which references this index file
enter the cipher somehow to automatically decrypt stream?
Can anyone help lift the fog here?
This pretty much nails how to handle encrypted streaming:
http://developer.apple.com/iphone/library/qa/qa2009/qa1661.html
Also, the app should connect to the https domain before running the movie,
so that it can pass its credentials, and these credentials can be cached for
MPMoviePlayer.
The player supports digest authentication, but not SSL client authentication using
client certificates.