Is there any way in which the messages that are send by COAP over UDP packets can be secured ? Any open source projects that I can implement. This message exchange is with a server and the client would be an embedded device. So the cryptographic algorithm must be able to run on it too. Also I came across cyassl. But the problem is that it uses TCP protocol rather than UDP ? Any ideas ?
Thanks
DTLS can be used to secure CoAP unicast messages, however, CoAP multicast messages are not protected by the existence DTLS protocol. Because efficient key distribution problem has not been solved yet. This means the header of multicast messages might be exposed to the sniffer tool, including the URI path.
Nowadays, there is a protocol called OSCoAP might help with this. It is still in implementation.
This is the latest draft IDTF document of OSCoAP: https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security-02
However, there are doubts about it. It mentions the OSCoAP will encrypt the URI path in section 4. Then key distribution still might be a problem in multicast. But it didn't mention any difficulties there. But someone who has interests in the security of CoAP messages can have a look at OSCoAP.
The way to secure CoAP is DTLS (TLS for Datagram)
The RFC is pretty clear on the subject:
https://datatracker.ietf.org/doc/rfc7252/?include_text=1
See section 9 for the details.
DTLS is simply the well-known TLS/SSL but adapted to run on UDP transport.
A nice and simple implementation for embedded device is tinydtls (http://trinydtls.sf.net)
For the server side you can use Californium and Scandium (http://eclipse.org/californium)
Encryption of data before sending lets you not bother about the transfer protocol (i.e. is it UDP, TCP etc). Of course you will need to decrypt the data on the server.
If you want transport-layer security, you should look for DTLS implementations. DTLS is a flavor of SSL/TLS designed to be run over UDP and similar transports. I am not sure if DTLS implementations exist for constrained devices, though.
Related
I have recently been trying to learn the basics of the TLS protocol, and I am unsure about how TCP packets containing TLS data can be differentiated from those that don't.
Can someone please provide an explanation?
TCP - the Transmission Control Protocol - is the underlying protocol of many higher level protocols; it doesn't specify what it transports. It turns a best effort packet protocol (IP) into a two way connection that can transport any stream of data.
TLS - the Transport Layer Protocol - provides security on top of a protocol such as TCP. It has a specific protocol description where the handshake records can easily be distinguished.
However, as indicated, TCP may transport any data. So if you have a protocol that is, say, one bit different from TLS then it won't be easy to detect this small change. However, tools such as WireShark are pretty capable of detecting protocols with high certainty.
Separate data records are harder to detect, as encrypted data packets don't contain much distinguishing features. Encrypted data itself looks like random data by definition. So if you just have a few packets then you have just some structure and otherwise random data. Now such random data is probably encrypted, but other than that it isn't much use for determining the protocol.
For learning purposes I'm implementing TCP (for now just RFC 793) but I have no
idea how to test it. Most TUN/TAP stuff on the internet are out of date (e.g.
Linux API calls no longer work) and just doesn't explain enough. In addition, I
feel like a creating a device and forwarding packages etc. are not the best way
for learning purposes. For example, I'd rather only override socket(),
listen(), connect(), accept(), send(), recv() etc. in a program rather
than forwarding all ethernet traffic to a device/program that does the
bookeeping for the whole system rather than for a single program.
I'm wondering if this is possible. If not, I'd like to know the simplest way to
test a TCP implementation on Linux.
Because I'm following RFC 793, it'd be great if I could have an IP (Internet
Protocol as mentioned in the RFC) API in my application. Is this possible or do
I have to mess with TUN/TAP stuff?
Thanks..
If we talk about research I strongly recommend you read Engineering with Logic: Rigorous Test-Oracle Specification and
Validation for TCP/IP and the Sockets API
It contains section about testing TCP/IP implementation:
"EXPERIMENTAL VALIDATION: TESTING INFRASTRUCTURE"
You could try setting up two peers, one using a RAW socket and the other a TCP socket.
If they can communicate and packets are really delivered/recovered the same way TCP does, you know that your custom implementation is successful.
C sockets
C RAW sockets
C TCP implementation
All you need is to intercept all tcp packets with bits (syn, ack, fin, etc.) your application has sent and to see if it works properly:
It could simply be done with wireshark or other sniffer. When testing you will see all tcp packets with bits you've sent.
In order you want to see linux system calls which your application are calling, you can use GDB or any other debugger.
Can anyone tell me which Communication Protocol is used by hyperterminal connecting via Tcp/Ip ?
Protocol here means UDP, Socket/Server, other(If any).
Actually, I need to design an application (in QT, Linux as OS) to communicate to a machine (basically a printer) via Ethernet. I need to send request to the printer as well as receive response, if any, from the printer.
It can be communicated via Hyperterminal using Tcp/IP.
So I wonder which protocol should i use for the communication. As Printer simply supports ethernet therefore I have no idea, if I can use Socket/Server for communication.
Need suggestion over this. All idea/suggestion are welcome.
Thanks in Advance
You need to get your terminology right. TCP/IP and UDP are transport layers. A protocol refers to the application data that is transmitted over a transport. A socket is a programming API that allows an application to gain access to a transport so it can send/receive protocol data.
Now, to answer your question - HyperTerminal typically uses the Telnet protocol over TCP/IP. Many protocols in existence are text-based, and Telnet is largely compatible with simple ASCII text, which makes it convenient for allowing users to use Telnet UI clients, like HyperTerminal, to manually send text commands to network-connected devices. However, most devices/protocols do not use the actual Telnet protocol. But if you can communicate with a device using HyperTerminal, you can code your app to send/receive the same text commands.
I'm developing a SIP mobile softphone, customer needs a complete hiding of SIP messages from softphones to SIP servers as VOIP calls are regionally prohibited, however using TLS connection was not sufficient since the message headers are easily recognized as a SIP message. What are the best common alternative?
what about openvpn, IPSec tunneling?
Transmitting SIP over TLS means the SIP headers will only be viewable if someone is able to compromise your TLS keys, i.e. it's highly unlikely unless some national security agency is on your case.
What you might be encountering is port 5061 being blocked since it's the default and therefore well known SIP TLS port. To get around that simply use a different port for your SIP TLS connection. As far as anyone viewing the traffic goes if it's not suing port 5061 they won't have any idea that SIP is being used in your TLS stream.
Of course you also need to consider the RTP traffic which is what will carry the audio part of the call once SIP has set it up. There are no standardised ports for RTP but some popular VoIP softswitches do use certain ranges by default. For example Asterisk uses UDP 10,000 to 20,000. To work around that you'd really need to use SRTP but that's going to be harder to set up since not that many SIP user agents and servers support it. It will also be easier to detect for someone watching your traffic since even without knowing the contents the profile of RTP packets would be detectable. Still it's likely to need a sophisticated entity monitoring your traffic to detect a VoIP call using SIP over TLS on a non-standard port and SRTP call amongst the general noise of internet traffic.
I'm looking for options for securing UDP traffic (mainly real-time video) on a wireless network (802.11). Any suggestions apart from Datagram Transport Layer Security (DTLS)?
Thanks.
You must be more clear about the attacks you are trying to defend against. For instance if your only concern is spoofing then you can use a Diffie–Hellman key exchange to transfer a secret between 2 parties. Then this secret can be used to generate an Message Authentication Code for each packet.
If you need any more protection I strongly recommend using DTLS. It should be noted that all TLS/SSL connections can be resumed so you can cut down on the number of handshakes. Also, certificates are free.
Are you trying to wrap an existing application or writing your own? What client server setup do you have? Do you want to prevent snooping or tampering?
I am assuming here that you
are developing an application
are trying to prevent snooping
have access to client and server.
The simple approach is to use any off the self strong encryption. To prevent tampering use any signing algorithm with a private/public key scheme. You can use the same key pair for encryption and authentication.
The drawback of this approach is that it is on layer 7 and you have to do most of the work on your own. On the other hand, DTLS is a viable option...
Have you considered IPSEC? This article provides some good guidance on when and when not to use it.
You can look into ssh with port forwarding. That comes at the cost of maintaining a TCP connection over which the UDP traffic can be secured.