Insecurities in API
Insecurities in API
Analysis
Many IoT devices have very constrained resources and operate within hostile heterogenous environments. This scenario results in more critical and delicate security implement considerations.
Power Consumption
Considering that many IoT devices are often battery operated or low powered, power consumption is very important when considering any security implementation. API security attacks could result in power drainage or not enough power to handle security implementations well. Bandyopadhyay and Bhattacharyya (2013) found that CoAP was more performant that MQTT in energy consumption and basic transfer over the UDP protocol. (Bandyopadhyay & Bhattacharyya, 2013). [fig] shows a comparison of packets send using both MQTT and CoAP illustrating energy consumption is less using CoAP. It should also be noted that unlike CoAP that closes connection after each request/response, MQTT and AMQP both leave channels open listening for messages from a centralize broker (Dizdarević, Carpio, Jukan, Masip-Bruin, 2019). This results in more power usage. Dizdarević, et al. notes that because of the relatively high power, processing, and memory consumption, AMQP is best suited for resources with higher processing power.

Computational expense
Securing APIs typically require some computation in the form of cryptography, hashing, and parsing. Of the security methods studied, it was found that CoAP over DTLS required more computation resources to implement. This is due to the CoAP using a specialized version of TLS which requires more computation in wrapping and unwrapping the UDP with the TLS security layers. This results in packet sizes being larger than the MQTT alternative which implicitly operates on UDP over TCP.
Memory requirements
CoAP is considered a lightweight protocol, as such, headers, methods and status codes are all binary encoded. This compression reduces the overall size of package which, in turn, uses less memory (Dizdarević, et al., 2019). CoAP also uses the less memory intensive UDP protocol. However, as noted above, securing UDP requires a special implementation of TLS which increases the memory footprint of CoAP.
Ease of use
MQTT and AMQP both use a subscriber/publisher model with a central broker directing message. This means that devices subscribe are always open and listening to messages. Device messages need to be passed with username/password along with the message. This method is not a familiar as the tradition request/response model used by HTTP and, notably, by CoAP. This makes using GET, POST and other HTTP request methods easier to implement using CoAP. DDS is language and operating system independent. This allows for easier implementation among a wider range of developers. DDS also has supports automatic discovery allowing for devices to subscribe and publish messages without the need for a broker (Foster, 2015).
User Security
MQTT is a subscriber/publisher protocol that employs a default plain text username/password security structure. This means that security is built in. This also means that it is easy to view the username and password for messages as they are passed across the network. For this, MQTT relies on TLS for securing transporting messages. This also means that security is more limited for MQTT. On the other hand, AMQP uses SASL mechanism that hands of security to manufacturers or companies. This results in far more flexibility in securing APIs. CoAP uses a request/reply method similar to the traditional HTTP model. This means that most HTTP method of security become applicable to CoAP, including OAuth, JWT, PSK, and RawPublicKey.
Quality of Service (QoS)
Quality of services is important to ensure data delivery. MQTT protocol supports TCP and provides three different types of reliability mechanism for ensuring packets delivery in the form of Quality of Service (QoS) (Dinculeană & Cheng, 2019). CoAP only offers two levels of QoS. CoAP uses UDP as its transport layer which is known for speed but less reliability in packet delivery. TCP, on the other hand, guarantees message delivery but is generally slower. DDS allows for multiple levels of QoS which are fine-tuned by the user in prioritizing data exchanges (Foster, 2015).
System security
MQTT relies on a broker for devices on the network to communicate. In a similar manner, CoAP relies on a centralized server through which requests and responses are communicated. This results in a single point of failure that could potentially compromise an IoT network. Although DDS uses a subscriber/publisher model, it does not rely on a broker. This decreases the probability for system failure because no single point of system of failure exists (Dizdarević, et al., 2019). By this measure, DDS decouples devices which allows for better overall network security.
Analysis of Protocols
Solutions | Criterion 1 | Criterion 2 | Criterion 3 |
Criterion Description | |||
Solutions | Criterion 1 scores | Criterion 2 scores | Criterion 3 scores |
Solution A | |||
Solution B | |||
Solution C |
Table 1: an example of the UnWeighted Decision Matrix (Ramdhani, S., & Jamari, 2018).
Table 1 above shows an example of an unweighted decision matrix which can be used to identify some of the best API solutions. The typical unweighted decision matrix is used to evaluate three categories of solutions while using a three pronged criteria. Nevertheless, the matrix can be expanded to include more options and criteria, especially through the additional of supplementary columns and rows. In this regard, the matrix is considerably suitable for evolving solutions that have changing demands and options. For each criterion, a solution allocated a score ranging from 1-5, where 1 is the lowest and 5 the highest score. After each solution is scored, it is necessary to calculate the aggregate score to enhance the necessary evaluation. The aggregate scores for each alternative can be calculated using following
as formulated in a 2018 article by Ramdhani and Jamari.
Where: is the aggregate score for each solution, n: the number of solution criterion,
: refers to the total weight of the cth criterion: and
is the specific score of xth solution in the cth criterion. Typically, the aggregate score determines the most favorable solution.
Solutions | Criterion 1 | Criterion 2 | Criterion 3 | Criterion 4 | Criterion 5 | Criterion 6 | Criterion 7 |
Criterion (cn) Description | Power Consumption | Computational Expense | Memory expense | Ease of use | User Security | QoS | System security |
Solutions (xn) | Criterion 1 Scores ( | Criterion 2 Scores ( | Criterion 3 Scores ( | Criterion 4 Scores ( | Criterion 5 Scores ( | Criterion 6 Scores ( | Criterion 7 Scores ( |
MQTT | 4 | 4 | 4 | 2 | 2 | 4 | 2 |
AMQP | 2 | 2 | 2 | 3 | 3 | 2 | 2 |
CoAP | 4 | 3 | 4 | 4 | 4 | 4 | 2 |
DDS | 5 | 5 | 5 | 5 | 5 | 5 | 5 |
15 | 14 | 15 | 14 | 14 | 15 | 11 |
Table 2: Unweighted decision matrix for API communication protocols
While using figures from the unweighted decision matrix illustrated in Table 2 above, the calculation of aggregate score for different API communication protocols is shown below:
MQTT (x1)
15*4) +14*4)+(15*4+(14*2)+(14*2)+(15*4)+(11*2)= 314
AMQP (x2)
15*2) +14*2)+(15*2)+(14*3)+(14*3+(15*2)+(11*2)= 224
CoAP (x3)
15*4) +14*3)+(15*4)+(14*4)+(14*4)+(15*4)+(11*2)= 356
DDS (x4)
15*5) +14*5)+(15*5)+(14*5)+(14*5)+(15*5)+(11*5)= 490
From the analysis alternatives, it is clear that DDS is the communication protocol for IoT designs. The alternative outdoes CoAP, which is the second best alternative with almost 150 points. AMQP and MQTT may be because the techniques possess significant scalability and security issues score the lowest aggregate points. In particular, AMQP has the lowest aggregate score of 224, which is less than half of that of DDS. Notably, CoAP and MQTT record almost the same aggregate scores. In this regard, while choosing between the two protocols, it is advisable to expand the criteria, hence acquire substantial insights about their performance.
Solutions
Untrusted Certificate Attacks
- Emergency Change of the certificate authorities That Issues Company’s Certifications
The certificates that a company has always used may be compromised or may not be trusted for any other reason. In this case, the company must be able to refer quickly to other certificate authorities to issue new and reliable certificates. Otherwise, the untrusted certificates and in fact, the company is considered untrusted. Users’ access to the website is reduced, and the company suffers enormous losses. Therefore, the company must be ready to shift digital keys and certificates immediately to other certificate authorities. However, few companies use an automation system to shift keys and certificates when needed. In light of NIST’s recommendation, “Preparing for Responding to Certification Authority Compromise and Fraudulent Certificate Issuances” is very important. So, companies need to know what certificates they use, where these certificates are purchased, and what other certificate authorities they switch to when needed.
When certificate authorities become untrusted, each company should remove that certificate authorities from its list of certificate exporters and replace other certificate authorities quickly. Devices of any company should be able to trust other certificate authorities and accept and install new certificates (Peters, 2015).
To avoid the untrusted certificate attacks all certificates should be validated and signed by a trusted Certificate Authority. This authority can be a reputable third-party Certificate authority or using public key infrastructure that exists within any related organization. “The latter would require the Certificate Authority root certificate to be installed on all connecting clients, which can be done through the modification of Windows Group Policy:
- Open the relevant Group Policy Object (GPO)
- In the console tree, click Trusted Root Certification Authorities: Policy Object Name/Computer Configuration/Windows Settings/Security Settings/Public Key Policies/Trusted Root Certification Authorities
- On the Action menu, point to All Tasks, then click Import to add the root certificate”.
Expired Certificates Attacks
- New Certificates are Agile Certificates
In the technology world, certificates expiration has a good that it makes certificates modern. In the past, it was possible to obtain certificates for 5 years or more. Today there is a 3-year limit for issuing certificates, and the world of industry is looking to limit this time to even less than 3 years. Shorter credentials make it easier to update security standards. “Last year the entire internet migrated to the new SHA-2 signature algorithm. It was a bit bumpy because of those old 5+ year certificates out there”.

Figure 4 SSL Validity Certificate Periods
From a policy perspective, long validity periods are not applicable. Since a new policy is issued, companies have to wait until their certification period ends, which can take up to 5 years. Once the validity periods are over, and certificates are upgraded and updated, it is possible to comply with the new policy. Uneven periods make it’s challenging to establish contingency between companies due to the lack of coordination in responding to the new policy. In many cases, users are forced to update their documents in the middle of the course.
“The CA/B Forum is an industry organization which sets best practices and standards for SSL certificate issuance. They are the ones ensuring that new certificates don’t continue to use old security measures. One of the goals the CA/B Forum has been working towards is shorter certificate validity. When SSL certificates expire more frequently, it makes it easier to improve security practices”.
When updating company’s SSL certificates, it must be ensured that all information in certificates correctly entered. Customers should be assured that the company is the rightful owner of certificates and that the certificates’ security measures are always up to date (Lynch, 2016). To avoid expired certificates attacks, certificates should be provided and maintained periodically. Ensure that the certificate re-validation process begins at least thirty days before the expiration date.
Weak Hashing Algorithm Attacks
- Security of Cryptographic Hash Functions (CHFs)
Three features of CHFs should be considered to meet the basic requirements for establishing a secure network. If these three features are taken into account, CHFs can be secured and applicable in many areas: pre-image resistance, collision resistance, and second pre-image resistance. Furthermore, other features should be considered when applying CHFs for different applications.
“pre-image resistance: CHFs are considered to be computationally non-invertible which means, if a hash code H(M) is generated for a message M, it is considered to be computationally infeasible for an adversary (A) to retrieve the original message (M) back” (Kishore & Kappor, 2016, p2).

Figure 5 pre-image resistance
“collision resistance: For a CHF to be weak collision resistant or second pre- image resistant, it should be computationally infeasible for an adversary (A) to find two different messages M and M” which can generate same hash values from that CHF. That is, to find M, M”; such that H(M) = H(M”) but M ≠ M” (Kishore & Kappor, 2016, p3).

Figure 6 Collision Resistance
“second pre-image resistance: For a CHF to be strong collision resistant, it should be computationally infeasible for an adversary (A) with given CHF H and message M to find another message M” where M≠M” and H(M) = H(M”)” (Kishore & Kappor, 2016, p3).

Figure 7 Second Pre-image Resistance
It is recommended to issue stronger hashing algorithms such as the SHA-2 family of hashing algorithms (SHA-224, SHA-256, SHA-384, and SHA-512). Weaker hashing algorithms, such as SHA-1 and MD5, should be replaced to make the attack less likely (Perspective Risk, 2019).
The NIST has published a family of cryptographic hash functions, the Secure Hash Algorithm, as a U.S. Federal Information Processing Standard (FIPS) that significantly guarantees the security of hash functions. This family of hash functions includes several algorithms that have been developed in recent years to ensure robust security requirements. Many of these functions have been combined with two components: a compression function and a domain extender.
In recent years, attack algorithms have become more efficient and inclusive. The new algorithms apply a kind of Hashing construction that works in multidimensional and multilevel systems. This view is based on the creation of a dependent chain of fast and sophisticated algorithms to prevent attacks from breaking (Kishore & Kappor, 2016).
Analysis of Alternatives
Solutions | Criterion 1 | Criterion 2 | Criterion 3 |
Criterion Description | Technology maturity | Integration risk | Manufacturing feasibility |
Emergency Change of the certificate authorities | 3 | 2 | 4 |
Agile Certificates | 4 | 5 | 5 |
Security of Cryptographic Hash Functions (CHFs) | 5 | 5 | 5 |
Table 1Critical Technology Elements (CTEs)Rating
The solutions to the problem of weaknesses of TLS that leads to insecurity in APIs were scored according to the defined criteria. The results are shown in the table no.1.
Technology Maturity: A technology is considered mature that has been in use for a long time so that the inherent flaws and problems of the technology are well known. The shortcomings of this technology have been fixed or minimized in advanced versions. Changing of the certificate authority’s capability in this area seems fairly poor as the mechanism of changing of the certificate authorities is still in its infancy. Companies active in this field are expanding. A more extensive advertising system is needed to inform all relevant companies.
Agile Certificate is increasing. Most companies try to familiarize employees with the basics of training of Agile Certificate. So, it has done better than emergency change of certificate authorities in the area of technology maturity. Security of Cryptographic Hash Functions (CHFs) has made fundamental changes in all areas of network security. Along with the rapid development and resources utilization, it has also helped to provide a robust security.
Integration Risk: Integration risk demonstrates the ability to integrate information technology into departments and organizations. Poor integration between the two technologies leads to problems in data integration and consequently functional failures in the process and operating systems. Emergency Change of the certificate authorities has not yet reached a stage that has been thoroughly discussed among the various departments. It seems that this solution still needs more time to be implemented seamlessly and comprehensively among the companies involved. So, it gets a lower score on this criterion.
“Agile certification increases adaptability in Agile technologies that will increase the team productivity and enhance the customer satisfaction. Agile certificate helps companies to learn practical techniques for planning, estimating the cost of the project in an Agile way” (Greycampus.com, 2019). So, this solution will help increase the exchange of information between different departments and increase security.
“One main use of hashing is to compare two files for equality. Without opening two document files to compare them word-for-word, the calculated hash values of these files will allow the owner to know immediately if they are different. Hashing is also used to verify the integrity of a file after it has been transferred from one place to another, typically in a file backup program like SyncBack. to ensure the transferred file is not corrupted, a user can compare the hash value of both files. If they are the same, then the transferred file is an identical copy” (Chung, 2019). For the purpose of security, this solution is considered to promote efficient integration.
Manufacturing Feasibility: This analysis determines three components: Is technology feasible? Is this feasibility in line with the projected costs? Is technology profitable? (Jain & Kuthe, 2013). A quick change to a new certificate authority usually brings costs. Cutting back on time before the deadline and switching to a new certificate authority during an emergency is often accompanied by unforeseen expenses. However, switching can be very cost-effective over time. So, this solution is relatively feasible.
Agile Certificates is a feasible solution because research shows that any short-term and long-term education investment is profitable for companies. Often the cost of training staff and managers, especially in the field of security, is far lower than the unforeseen expenses of lack of knowledge about security in APIs.
Security of Cryptographic Hash Functions (CHFs) is feasible because it does not require high costs for creation and application. The process of deploying security networks employs personnel who specialize in decrypting relevant files and can detect attacks. Investing to hire a team of professionals and create optimal conditions for them over time reduces the costs of attacking the security.
Solutions | Criterion 1 | Criterion 2 | Criterion 3 |
Criterion Description | Technology maturity | Integration risk | Manufacturing feasibility |
Emergency Change of the certificate authorities | 3 | 2 | 4 |
Agile Certificates | 4 | 5 | 5 |
Security of Cryptographic Hash Functions (CHFs) | 5 | 5 | 5 |
Table 3: the score of three API solutions on the unweighted decision matrix
While using score aggregating formula for unweighted decision matrix, which is given by ;
,
; in this regard, the most essential criterion of evaluating API solutions is manufacturing feasibility. Nevertheless, scores in other criteria are still relevant in the process of identifying the best solution.in this regard, it necessary to calculate the aggregate scores for each solution. For Emergency Change of the certificate authorities solution
,
,
, in this regard the aggregate score for this option is given by (12*3)+(12*2)+(14*4)= 116. For Agile Certificates
,
,
(12*4)+(12*5)+(14*5)=178; and finally for Security of Cryptographic Hash Functions (CHFs)
,
,
, hence the aggregate solution can be established by (12*5)+(12*5)+(14*5)=190. Therefore, the unweighted decision making matrix indicates that, when compared to Agile certificates and Emergency Change of the certificate authorities, Security of Cryptographic Hash Functions provide the best API solution security.
References
Arxiv.org. (2019). A Review of Man-in-the-Middle Attacks. [online] Available at: https://arxiv.org/pdf/1504.02115.pdf [Accessed 20 Nov. 2019].
Beal, V. (2019). What is API security?. [online] Redhat.com. Available at: https://www.redhat.com/en/topics/security/api-security [Accessed 21 Oct. 2019].
Bischoff, P. (2019). UDP vs TCP: What are they and how do they differ? | Comparitech. [online] Comparitech. Available at: https://www.comparitech.com/blog/vpn-privacy/udp-vs-tcp-ip/ [Accessed 20 Oct. 2019].
Brown, K. (2013). SANS Institute: Reading Room – Authentication. [online] Sans.org. Available at: https://www.sans.org/reading-room/whitepapers/authentication/dangers-weak-hashes-34412 [Accessed 22 Nov. 2019].
Chung, C. (2019). What is Hashing? Benefits, types and more. [online] 2brightsparks.com. Available at: https://www.2brightsparks.com/resources/articles/introduction-to-hashing-and-its-uses.html [Accessed 1 Dec. 2019].
Comodosslstore.com. (2019). Hazards of an Expired SSL certificate. [online] Available at: https://comodosslstore.com/blog/hazards-of-an-expired-ssl-certificate.html [Accessed 22 Nov. 2019].
Duncan, R. (2013). Netcraft | SSL: Intercepted today, decrypted tomorrow. [online] News.netcraft.com. Available at: https://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html [Accessed 21 Oct. 2019].
Greycampus.com. (2019). Greycampus. [online] Available at: https://www.greycampus.com/opencampus/agile-certified-practitioner/benefits-for-pmi-acp-certified-professional [Accessed 1 Dec. 2019].
Jain, P., & Kuthe, A. M. (2013). Feasibility study of manufacturing using rapid prototyping: FDM approach. Procedia Engineering, 63, 4-11.
Kishore, N., & Kapoor, B. (2016). Attacks on and advances in secure hash algorithms. IAENG International Journal of Computer Science, 43(3), 326-335.
Lynch, V. (2016). Why Do SSL Certificates Expire?. [online] Hashed Out by The SSL Store™. Available at: https://www.thesslstore.com/blog/ssl-certificates-expire/ [Accessed 23 Nov. 2019].
Perspective Risk. (2019). Reducing Your Risks: SSL and TLS Certificate Weaknesses. [online] Available at: https://www.perspectiverisk.com/multiple-ssl-tls-certificate-weaknesses/ [Accessed 6 Nov. 2019].
Peters, S. (2015). What You Should, But Don’t, Do About Untrusted Certs, CAs. [online] Dark Reading. Available at: https://www.darkreading.com/cloud/what-you-should-but-dont-do-about-untrusted-certs-cas-/d/d-id/1322111 [Accessed 23 Nov. 2019].
Slivker, A. (2019). What you really need to know about securing APIs with mutual certificates. [online] Nevatech.com. Available at: https://www.nevatech.com/blog/post/What-you-need-to-know-about-securing-APIs-with-mutual-certificates [Accessed 21 Oct. 2019].
Techopedia.com. (2019). What is Transport Layer Security (TLS)? – Definition from Techopedia. [online] Available at: https://www.techopedia.com/definition/4143/transport-layer-security-tls [Accessed 21 Oct. 2019].
Ramdhani, S., & Jamari, J. (2018). The Modeling Of A Conceptual Engineering Design System Using The Decision-Matrix Logic. In MATEC Web of Conferences (Vol. 159, p. 02022). EDP Sciences. References