I'm developing a sgx application using sgx_dh API. The workflow can be summarized as follows (two roles here are dh_initiator, dh_i in short, and dh_responder, i.e., dh_r.):
step0: Initiate session in dh_i and dh_r side;
step1: dh_r generates msg1 contains g_a and sends msg1 to dh_i;
step2: dh_i processes msg1 and generates msg2 containing g_b, and sends msg2 to dh_r;
step3: dh_r processes msg2 and genertaes msg3 including affirm of the sharing key, and then sends msg3 to dh_i;
step4: dh_i processes msg3. DH key exchange has done.
In step3, the dh_r will output a sgx_dh_session_enclave_identity_t type variable, and so as to dh_i in step4 that outputs a variable in the same type. According to the SGX Developer Reference, the two variables are used in dh session establishment.
But I cannot figure out where they will BE USED since they are generated when the key exchange and enclave authentication has done.
Any suggestion or hint is appreciated, and if any misunderstanding here, please correct me kindly. Thanks so much~
These two variables are provided to explicit the values you should verify to ensure you're communicating with the correct enclaves (you may check how they are used in the LocalAttestation sample: https://github.com/intel/linux-sgx/blob/62b116c502b09b125db9acc965694d3ecff8e698/SampleCode/LocalAttestation/EnclaveInitiator/EnclaveMessageExchange.cpp#L133-L144).
They are not here to be passed to other functions of the dh exchange protocol provided by the sdk, you should process them "manually" and define your own acceptation policy before relying on the secure channel established.
Related
I'm trying to incorporate end to end encryption using Apache Pulsar. So far the examples I've seen look similar to http://pulsar.apache.org/docs/en/security-encryption/
I saw that the encryption key (public / private key) is fetched every 4 hours in the key rotation section. It seems to indicate that you can only have a single key to encrypt the messages you send.
I’d like to be able to use different encryption keys for different topics/tenants. Does pulsar support different encryption keys for different topics?
Basically my client will pull a different key depending on which tenant the data belongs to and encrypt any messages pertaining to that specific key using pulsar's end to end encryption.
How would this look?
Is it as simple as creating a new producer any time I want to use a different key for encryption?
Producer producer = pulsarClient.newProducer()
.topic("persistent://my-tenant/my-ns/my-topic")
.addEncryptionKey("myTenant1Key")
.cryptoKeyReader(new RawFileKeyReader("tenant1_pubkey.pem", "tenant1_privkey.pem"))
.create();
So far I've used the pulsar client to send encrypted messages using a local private/public key pair. Can I just switch out the key pair and instantiate a new producer anytime I want a message to be encrypted differently? I've tried asking around and can't find the right answer.
Absolutely, you are creating separate producers for different topic and can use different keys for each producer.
What is WSM Buffer in IBM DataPower's context?
As per my understanding, WSM Buffer is used to monitor incoming requests in DataPower. The statistics for all incoming requests such as 'completed records', 'pending records' etc are captured in 'WSM Agent Status' in DataPower.
Can you please provide a detailed description of WSM Buffer and how does it help in logging and monitoring?
A WSM buffer is relatively easy to configure setting in datapower XI52. You need to enable it like following:
Use the DataPower Web Interface
Navigate to Object > Device Management
Enable data retention in the WSM buffer
Select XML Management Interface
Check the WS-Management Endpoint checkbox
Click Apply
Choose to retain data when data collection is stopped
Select Web Services Management Agent
Select Buffering Mode = Buffer
Click Apply
Then you need to use products like ITCAM for SOA which have capability to read WSM buffer and make sense out of it. You need to configure ITCAM for SOA for it. Once done you can test your WSM buffer configuration like below:
Send four requests to your DataPower device
Check the WSM buffer
1.Choose Status > Web Service > WSM Agent Status
2. Status is 4 (for example) records seen, 4 (for example) complete records
Parameters have following meaning
a.) Records seen: total lost + complete
b.) Records lost: discarded when the buffer was full
c.) Complete records: ready for data collection
d.) Pending records: requests awaiting a server response
See if it helps you !
My company uses BizTalk for our EDI and AS2 communications. One periodic issue is that a VAN or similar partner we transmit with will want to know whether we received a file by it's ISA #. We currently do use the ISA # for routing within our ports, but I can't seem to find anywhere that this information is stored in BizTalk. Is there a way to look up an EDI message that BizTalk recieved by ISA#? Or perhaps someway I could get a hold of it and store it on my own?
If you're not explicitly using Business Activity Monitoring (BAM) to track this, you may be able to use message tracking.
If you have:
message tracking turned on for the message properties at a point in processing the messages when the ISA number is used, and
if the ISA number is promoted in a published schema (which I'm guessing it is, if you're using the out-of-the-box EDI stuff)
...then you could use the admin console to look for tracked messages with that schema and based on the particular field in the schema (e.g., EDI.ISA08 or EDI.ISA06). Of course, if you are mapping the ISA# to a particular party through your BizTalk configuration, then you would just need to search for Tracked Message Events where the Party Name equals the name you configured for that ISA#.
There is also built-in EDI tracking (see http://msdn.microsoft.com/en-us/library/bb226464(v=bts.10).aspx), with its own reports, but I'm not familiar with it enough to say whether or not it'll give you exactly what you need.
Otherwise, you will want to look at setting up BAM to save the ISA info that you need.
These fields are available inside the Biztalk message if you do EDI receive.
msgIn(EDI.ISASegment) contains all ISA segments. Then you can do substring on control numbers and then put it in your outgoing filename:
ctrlnum (variable) = msgIn(EDI.ISA13)
newfilename = FILE.ReceivedFileName + ctrlnum ;
This way each control number will show up in your filename and you don't even need to open the file or check tracked messages.
I'm working on creating small relay stations out of tiny embedded Linux boxes. They have some sensors connected to them and transport data back to a server via HTTP POST. Right now the server just accepts their message, along with a unique ID (the MAC address of eth0).
I want to expand this to include some type of security. I want to be able to deploy these little devices with minimal configuration. I'd like to copy a base firmware to the device, hook them up in the field, and they self-register. The first time they connect, I'd like the server and device to do some type of negotiation where I can store a fingerprint. Subsequent requests I could then authentication/verify the device using that fingerprint.
That way, once a device registers with its unique ID, I can be assured all data from that ID is from the same device. If a rouge device or set of devices does register, I'll just delete them (I store IPs to so I can delete by unknown ranges and block them).
My question is what's the best way to go about doing this? I think back to the idea of SSH fingerprints, where the first time you connect to a server you get a server fingerprint. If a future request yields a different fingerprint, you get a huge warning and have to manually delete the fingerprint out of your authorized_keys file if the server's keys have actually regenerated (e.g. you did a reinstall without saving your old SSH keys).
Is something like this possibly with HTTP, possibly avoiding having to use preshared keys?
If it matters, the clients are running Python2 and the server they connect to is written mostly in Scala on Tomcat.
Basically, all you need to do is tell the server the public key, and then sign all of your messages with it. If you don't want pre-shared keys, then the server cannot be assured that someone new who is registering is actually one of your devices. You can still validate that the message came from the same device that originally registered with that identifier, however.
The process basically goes like this:
Client generates a new key pair (e.g. an RSA public/private key pair).
Client registers with server, sending its public key. The server stores this public key.
When the client sends a message, it generates a signature of its message, which it attaches to the message. When the server receives the message, it validates the signature to ensure that the message was sent by someone holding the corresponding private key.
The code for this in PyCrypto goes something like this:
Generate key pair
from Crypto.PublicKey import RSA
key = RSA.generate(2048)
private_key = key.exportKey()
public_key = key.publickey().exportKey()
# private_key is a string suitable for storing on disk for retrieval later
# public_key is a string suitable for sending to the server
# The server should store this along with the client ID for verification
Generate signature
from Crypto.PublicKey import RSA
from Crypto.Hash import SHA
key = RSA.importKey(private_key)
# where private_key is read from wherever you stored it previously
digest = SHA.new(message).digest()
signature = key.sign(digest, None)
# attach signature to the message however you wish
The server should load the public key as it has previously stored, and use a "verify" method provided by the Scala/Java crypto API you use, and accept the message only if it succeeds.
It is important to understand the caveats of each approach, as various techniques only protect against certain types of attacks. For instance, the above approach does not protect against a "replay attack", in which an attacker records a message with a certain meaning and then re-transmits it to the server at a later time. One way of protecting against this would be to include a timestamp in the message which is hashed; another would be to use an appropriately encrypted transport (e.g. SSL/TLS).
EDIT
I'm still hoping for some advice on this, i tried to clarify my intentions...
When i came upon device pairing in my mobile communication framework i studied a lot of papers on this topic and and also got some input from previous questions here. But, i didn't find a ready to implement protocol solution - so i invented a derivate and as i'm no crypto geek i'm not sure about the security caveats of the final solution:
The main questions are
Is SHA256 sufficient as a commit function?
Is the addition of the shared secret as an authentication info in the commit string safe?
What is the overall security of the 1024 bit group DH
I assume at most 2^-24 bit probability of succesful MITM attack (because of 24 bit challenge). Is this plausible?
What may be the most promising attack (besides ripping the device out off my numb, cold hands)
This is the algorithm sketch
For first time pairing, a solution proposed in "Key agreement in peer-to-peer wireless networks" (DH-SC) is implemented. I based it on a commitment derived from:
A fix "UUID" for the communicating entity/role (128 bit, sent at protocol start, before commitment)
The public DH key (192 bit private key, based on the 1024 bit Oakley group)
A 24 bit random challenge
Commit is computed using SHA256
c = sha256( UUID || DH pub || Chall)
Both parties exchange this commitment, open and transfer the plain content of the above values.
Alice Bob
ca = commit()
-------^ ca
cb = commit()
cb ^-----------
open
---^ DH pub a, chall a
open
DH pub b, chall b ^---
The 24 bit random is displayed to the user for manual authentication
DH session key (128 bytes, see above) is computed
When the user opts for persistent pairing, the session key is stored with the remote UUID as a shared secret
Next time devices connect, commit is computed by additionally hashing the previous DH session key before the random challenge. For sure it is not transfered when opening.
c = sha256( UUID || DH pub || DH sess || Chall)
Now the user is not bothered authenticating when the local party can derive the same commitment using his own, stored previous DH session key. After succesful connection the new DH session key becomes the new shared secret.
As this does not exactly fit the protocols i found so far (and as such their security proofs), i'd be very interested to get an opinion from some more crypto enabled guys here. BTW. i did read about the "EKE" protocol, but i'm not sure what the extra security level is.
"Is SHA256 sufficient as a commit function?"
The use of SHA256 should be just fine. The only issue I have heard of is that it has a hash extension vulnerability. If you produce multiple hashes using the same data don't simply concat more data to the end of the data you already hashed. In your post have have the two hashes "sha256( UUID || DH pub || Chall)" and "sha256( UUID || DH pub || DH sess || Chall)". If that second one was "sha256( UUID || DH pub || Chall || DH sess)" then there would be a relation between the hash values if UUID, DH pub, and Chall were all the same values as before. You should either take care to avoid the hash extension issue or include a salt value into the data to be hashed, either by communicating the salt across the link or having differing vales for each code path.
On a side note: is it really necessary to transmit a Chall when you already have a previous session key saved and don't need to ask the user to manually confirm the challenge code?
"Is the addition of the shared secret as an authentication info in the commit string safe?"
I'm guessing you mean to ask "Is it safe to include secret information in a hash that is to be made public?" If the secret is something that is really hard to guess and would take a really long time to perform a bruteforce attack against, then yes it is safe. If the secret is something easy to guess or has only a few possible values, then no, it's not safe unless you, at the same time, include some hard to guess secret to force a potential eavesdropper to have to guess all such secrets simultaneously. For a large, effectively random number like a DH shared secret then it should be just fine.
"What is the overall security of the 1024 bit group DH"
I'm not sure if DH group 1024 is what you want to use. A key exchange that is considered to be close to being as effective as the SHA256 hash algorithm you're using would be 521 bit ECDH. The cryptographic strength of ECDH is considered to be 1/2, so if you want 256 bit security, you want 521 bit ECDH. Unfortunately, I'm not certain about the security of the many individual 521 bit ECDH groups that have been published.
"I assume at most 2^-24 bit probability of succesful MITM attack (because of 24 bit challenge). Is this plausible?"
There is more than one way perform a MITM attack. Eve will use every resource at her disposal to perform her attacks and if you are not careful she will exploit something you didn't think of. This is why peer review is necessary in cryptography.
Simply, if you make your own cryptographic solution, then it's weak.
for the little story, the VISA guys have to start again 4 times before it's became strong enough.
I'm not a security expert, but it was what my crypto teacher told us everytime.
I've come up with this possible attack, based on my understanding of the protocol, inspired by Lowe's Attack to Needham-Shroeder Public Key Protocol:
Alice wants to reconnect. Calculates its committment ca and sends to Bob. The message is captured by Mallory.
Mallory answers. She does not know the shared secret, so she invents one. Calculates cb and sends to Alice.
At this step, Alice cannot verify the shared secret yet. So she sends DHpubA and ChallA.
Mallory ignores the messages from Alice and disappears.
Now Mallory has a valid DHpubA, ChallA and the corresponding (valid) ca.
Mallory sends ca to Bob.
Bob answers with cb.
Mallory sends a valid set of DhpubA, ChallA
Bob sends his DhpubB and ChallB
Since Bob can validate Mallory's messages, she is authenticated as Alice. Obviously Mallory does not know DHprivA, se she cannot calculate the current session key, but nevertheless you have a security flaw since Bob thinks he's talking to Alice.
General advice: avoid implementing you own cryptographic solution and don't trust security reviews from anyone else than an established security firm.
If you feel that your security requirements are not satisfied by standard mainstream crypto, try stating your requirements and asking whether is there a security procotol that matches them.
That sounds OK. Not sure what you meant by "fix[ed] UUID"?
Could a rogue app access the UUID and session keys: are they stored system-wide or in a service? There is some text in the SDK that suggests that any keystore always waits for user confirmation before returning a key.