Explore chapters and articles related to this topic
Cryptography Threats
Published in Nicholas Kolokotronis, Stavros Shiaeles, Cyber-Security Threats, Actors, and Dynamic Mitigation, 2021
Konstantinos Limniotis, Nicholas Kolokotronis
To establish shared secret keys for an IPsec connection, the Internet key exchange (IKE) protocol has to be executed. This protocol is triggered to set up a pair of SAs. There are two different versions of IKE, namely IKEv1 (RFC 2409) and IKEv2 (RFC 4306—with subsequent modifications by new RFCs). Although IKEv2 officially obsoletes the previous version, they are both available in all implementations [36]. The two peers establish an IKE SA for identity authentication and key information exchange. Next, protected by the IKE SA, the peers negotiate a pair of IPsec SAs using either AH or ESP protocols: subsequently, data is encrypted (if ESP has been chosen, which is the typical case) and transmitted between the peers. To achieve entity authentication, the main options in IKEv2 are PSK authentication and RSA signature authentication (the latter necessitates a digital certificate issued by a CA). In IKEv1, two additional modes of authentication modes exist, namely the public key encryption-based authentication (in which authentication information of one party is being encrypted using the public key of the other party) and the revised public key encryption-based authentication (which is a simpler version of the previous one). In any case, a Diffie-Hellman key exchange protocol is being utilized (both in IKEv1 and IKEv2), so as to ensure perfect forward secrecy.
Security Capability Negotiation in SDP
Published in Radhika Ranjan Roy, Handbook of SDP for Multimedia Session Negotiations, 2018
However, a specification uses a self-signed certificate for authentication in the SIP/SDP framework. “Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)” (RFC 4572, see Section 16.3) (hereafter referred to as comedia-tls) specifies a method to exchange the fingerprint of a self-signed certificate to establish a TLS (RFC 5246) connection. This specification defines a mechanism by which self-signed certificates can be used securely, provided that the integrity of the SDP description is assured. Because a certificate itself is used for authentication not only in TLS but also in IKE, this mechanism will be applied to the establishment of an IPsec security association (SA) by extending the protocol identifier of SDP so that it can specify IKE.
Key Management and Protection for IP Multimedia
Published in Borko Furht, Darko Kirovski, Multimedia Security Handbook, 2004
Rolf Blom, Elisabetta Carrara, Fredrik Lindholm, Karl Norrman, Näslund Mats
The Transport Layer Security (TLS) protocol [8] is functioning both as a key management protocol and as a security protocol mostly for applications using the Transport Control Protocol (TCP) and may, for example, be used to secure signaling protocols like H.323 and the Session Initiation Protocol (SIP) [9]. The Internet Key Exchange (IKE) [10] is the key management protocol used for exchanging parameters for IPsec. H.323 exchanges the security parameters for securing the media session within the signaling protocol (already protected by TLS or IPsec). IETF has developed a few key management protocols for multicast and groups, among them is MIKEY, which is also adopted in the new version of H.235.
Integration of social and IoT technologies: architectural framework for digital transformation and cyber security challenges
Published in Enterprise Information Systems, 2021
Subodh Mendhurwar, Rajhans Mishra
Roman, Zhou and Lopez (2013) have outlined various types of IoT architectures like Centralised IoT, Collaborative IoT, Connected Intranets of Things and Distributed IoT. Recommended Security Architecture of IoT Application and Middleware Layer includes – Federated Identity Management, Encryption Mechanisms, Firewalls, Risk Assessment and Intrusion Detection (Farooq et al. 2015). Heer et al. (2011) while weighing the pros and cons of centralised versus distributed IoT architectures, discussed suitability of protocols like – Internet Key Exchange (IKEv2)/IPsec, Host Identity Protocol (HIP), Datagram-oriented Transport Layer Security (DTLS), Extensible Authentication Protocol (EAP), Protocol for Carrying Authentication for Network Access (PANA) as candidate solutions for 6LoWPAN; observing that since resource constraints hinder securing each individual OSI layer, cross-layer concepts should be considered for an IoT-driven redesign of Internet security protocols.
A mutual authentication and key update protocol in satellite communication network
Published in Automatika, 2020
Congyu Huang, Zijian Zhang, Meng Li, Liehuang Zhu, Zhengjia Zhu, Xiaoxian Yang
There are also several authentication protocols designed for authenticating entities in satellite communication networks. For example, Chang et al. [23] proposed an authentication and key agreement protocol in the satellite communication networks. This protocol aimed to authenticate between endpoints and satellites. Unfortunately, it is difficult to be practical for mutual authentication among satellites. Lee et al. [24] presented an entity authentication protocol which made use of static and dynamic identities in a verification table to lower computation cost. However, the proposed protocol was not secure when the verification table is leaked. Zhibo et al. [25] put forward an end-to-end authentication protocol in the satellite communication networks. This protocol was proposed on the Internet key exchange (IKE) protocol. However, the computation cost of the proposed protocol was heavier than that of the authentication protocols based on private key cryptography, since the fundamental IKE protocol applied public key cryptography.