I have a physical IOT device with an ePROM in it that contains a unique serial number (userID) and generated random password. it connects via sFTP and http services to our server, using these credentials.
I figure we can use Diffie-Hellman to protect ourselves from impostors who lack physical access to our devices, from sending false data and getting free service charged to someone else.
But because our devices are "in the wild" it might be easy for some one to get physical access to one our units and clone our ePROM.
My question is what is the best way to protect ourselves from such attacks.
I think you would need something like the TPM module in Lenovo laptops. It is a small hardware module that can store a private key, and you cannot get the key once it is written. This way you could write the private key to the TPM, then deploy it, and nobody would be able to impersonate. They would be able to change the private key, but then you would notice since the public key would not match.
Now, I am not sure how costly such a module is, and I am not sure about extra battery cost, but this would secure your device.
Related
I am developing a mobile application which sends some encrypted data to a Bluetooth device and this Bluetooth device sends the data to server. My question is that in this case how can I prevent replay attacks. Someone might use a fake Bluetooth device to get the signals and send them to the server.
The mobile application works in offline mode and has no connection to server. So using a synchronized nonce or counter doesn't help.
I can not also use time-stamp to narrow the attack window because mobile phone's time might not be correct (synchronized with a time server).
Communication between my mobile application and Bluetooth device is one-way and my mobile application can only send data to the device.
One way to do this would be to use a counter, but allow it to skip a large number of steps. For example if the last counter value you've seen from phone A is 123 and you get something with a counter value of 156 then you accept it, but anything outside the range of [124, 1000123] you discard (1000000 being completely arbitrary and dependent on your use case).
This would prevent a replay attack, but you do have to take care that the transmissions aren't malleable or it would be trivial to forge counter numbers. This could be accomplished by having a secret per device MAC key (which would only be possible if the server and phone communicate beforehand).
It's worth stating that it would be good for the transactions to be authenticated (only phone A has the capability to generate a message saying it's from phone A) or an attacker could move up the counter very quickly and do a denial of service on phone A. However, from the way you phrased the question it sounds like it's something you've already dealt with.
i have a simple question...
Using a PCI PTS 3.0 hardware that secures sensitive data with SRED procedure with DUKPT double lenght TDES keys. Is the resulted encrypted data SAFE ?
Let say would it be considered safe if you would send it over unsecured TCP? over unsecured routers? over internet via TCP? Posted on pastebin :) ?
Or is there a MUST for additional security on communication pathways? Does SSL still needs to be used ? Why ? where does it says so?
I really cannot find relevant info when using SRED is that itself ENOUGH and considered PCI DSS 3.0 safe?
Edited:
To simplify... Is TripleDed Dukpt encrypted track2 data transferred via tcp on local lan considered safe?
Thank you and best regards.
Over a network, 3DES/DUKPT can securely encrypt track 2 data. A passive attacker would not be able to decrypt the message and obtain the credit card numbers.
However, DUKPT does not protect against replay attacks. You should use additional encryption to ensure transaction message integrity.
An attacker could modify other transaction data without changing the encrypted track 2 data. For example, an attacker could intercept a transaction message and extract the encrypted track 2 data. The attacker could create a new transaction for a different amount with the same encrypted track 2 data. The attacker could then submit the modified transaction in place of the actual transaction.
I am pretty new in this kind of things.
I have a local area network, accessed by some users via cable some and via wifi others.
I have developed a local application in php which receives only some of the LAN clients as authentic users; they can be identified by the system with an algorithm of key exchange similar to Diffie–Hellman's, to estabilish a secret key. The client then asks to be identified throug such a channel.
The problem is, MITM attack is possible in this kind of situation. I read wikipedia about how such an attack is executed: somebody listens the messages of the two, and puts himself between them creating two different secret keys for the client and server.
This attack is reality, so it must be possible; but I do not understand how it happens in a LAN:
the attacker can listen to the messages, and inject message of his own, impersoning the two subjects of the communications by forging https' IP fields if necessary...
But he can't prevent the original unforged message to reach, concurrently (but also later, because of forging process taking the attacker computer some time) with his malevolent forged one, the recipient! Especially in a wifi connection, which cannot be cut off for a single user, for example cutting his cable.
So, client and server receive two different http requests from each other, a true and a forged one; isn't this a way for them to recognize that such an attack is in progress?
Maybe this question is newby-ous; as I said, I am pretty new at this.
I think that is a scenario where you would use a digital signature (which also uses the idea that asymmetric encryption/Diffie-Hellman uses, that is "public and private key") to sign your messages.
The MITM attacker can not forge a message with a bad "from" and then sign it with the private signature of the original sender. The recipient uses the public part of the signature/certificate to validate the message. So that way he will not only know he is being attacked but also which message is genuine.
I am hosting an app on Nodejitsu, and I want that app to turn pages to pdf with wkhtmltopdf, which is a binary. Alas I'm not on a big enough plan with Nodejitsu to get ssh access to install wkhtmltopdf.
What I want to do is host the pdf converter on AWS ec2. But I am unsure of a good way to connect the two node.js servers securely.
Also then when the two servers are connected, what would be the most efficient way to transfer files between these two servers.
Is there concrete design patterns for this?
It kind of depends what you need your security for, and how much you need. So I assume you have some data on your nodejitsu server and want to send that (as html) to Amazon, and receive it back (as pdf) from amazon to nodejitsu, and you want:
nobody to be able to read your document in between
nobody to tamper with your document in between
First, realise that anyone with the right access to nodejitsu or amazon (either an employee or a hacker) will be able to see your data anyways (and probably anyone with access to your database provider as well). The chances for a data leak somewhere there are imho massively larger than someone listening in / tampering on the connection in between (especially if you host both in the US, or (another) country whose government you trust (note that if the US government wants access to your data either the nodejitsu or the amazon servers are physically in the US, they will get it anyways). But, the thing is, barring some major internet disruption, the connection between nodejisu and amazon will not run through shady providers or open wifi networks.
Once you've decided you still want / need the extra layer of security (and complexity), I would say: choose the easy route. No https, no certificates, no asymmetric encryption. Just choose a shared secret (a random password, the longer the better), and just AES encrypt the data before sending it, and at the other end AES decrypt it (using the built in node crypt module). Just send your (encrypted) documents over http, and you're done. You don't even need any authorisation layer: anything received that doesn't encrypt to a valid document, can be discarded.
It is true that https would prevent some other attacks (chiefly that the shared secret probably is somewhere in your code, so also on your local machine (and github) and with asymmetric encryption you only need to store the public key in your code. But still, it will save you a lot of headaches!
I have a server (will be noted as 'A') that transmits multicast to some end stations.
I would like only those that are privileged to see the information, to actually see it.
There is a third party server ('B') that manages unicast communications with both 'A' and the end stations and SSL with both of them.
My goal is to implement a secured multicast:
Two necessary givens:
It has to be multicast.
I want the security in the Application level (not the Network or Transport)
Questions:
Are there such implementations? I've tried searching for "secured multicast" etc. and have come across only IP Multicast security. I want an applicative implementation. If so, Could you recommend some and how to use them?
I thought about generating a special symmetric key - during the communication of 'A' and 'B' and during the conversation of 'B' and end station = to pass it (over SSL) to the end stations.
a. Is that a good idea?
b. A problem I see is that revealing the key becomes easier because of the amount of stations. I thought about replacing the key every hour. I shall inform the stations the key has changed by sending multicast messages: (sequence_number, encrypted_message) - this way every time the key changes then sequence_number++.
What do you think of the implementation? Have better ideas?
I wrote an app called UFTP (http://uftp-multicast.sourceforge.net) that does exactly this.
In terms of key management, each multicast session performs a TLS-like key exchange between the sender and each receiver, then uses the negotiated key for each receiver to send out the group key which is used to encrypt the data. By doing key negotiation for each session, this eliminates complications related to re-keying mid session.
Authentication is done via key fingerprinting, with fingerprints being communicated out-of-band. This is simpler than a certificate based system and minimizes overhead. Each sender and receiver has an RSA or ECDHA key they are identified by.
What you describe is a simple application of PKI:
Each station creates an RSA keypair and sends its public key to the server.
The server generates a random symmetric key and encrypts the multicast message using this symmetric key. New symmetric key should be generated for each message but usually it's not a big deal.
The symmetric key is encrypted using each station's public RSA key. Products of all such encryptions (i.e. encrypted session keys) are merged with encrypted data and compose the multicast packet.
Unfortunately such scheme will cause a significant extra data load on the multicast message, but this is caused by length of keys and the length can't be reduced without sacrificing security.