Security Propositions on Digital Certificates and Cloud Storage

A digital certificate (DC) may be likened to an electronic business card that is attached to Internet transaction data in order to verify the identity of an entity such as a client or server. A DC is issued by a trusted party called a certificate authority (CA) such as VeriSign and Thawte. The DC serves two purposes: first, to verify the identity of the owner and second, to make the owner's public key available (IBM). To obtain a DC, an applicant sends a request to a CA and provides pertinent information such as distinguished name (DN), public key and signature. To note, a DN is a unique identifier for each host or user for which the applicant is applying for a certificate. In turn, the CA vouches for the identification of server or client, signifying assurance to anyone exchanging personal information such as name, credit card number, or medical records. Due to the relative ease through which websites may be created for the purpose of stealing personal information, DCs have been highly essential.

Due to the number of entities requiring DCs, it is understandable that many entities have sought to be a CA as obtaining a DC requires payment of a fee. The problem here is that CA businesses have proliferated worldwide and to date, there is no coherent set of standards, policies or best practices applicable to such businesses, overseen by a regulating body (Constantin). As a result, there have been incidences when websites of CAs themselves have had security breaches. For instance, a Google Chrome user discovered a validly-signed Google DC that did not actually belong to the company. This means to say that a user was attempting to attack against the user's secure communications intended for Google. The CA was subsequently identified as an "intermediate Certificate Authority that gained its authority from Turkish CA TURKTRUST" (Wisniewski). Hence, it may be said that DCs have started to be compromised by the proliferation of CA businesses world-wide especially considering the absence of standards and a regulating body that would set the standards for the industry to ensure that they are really able to provide the necessary protection to users. In relation to this, it is believed that cloud storage provides many benefits to users except that it is associated with persistent security issues.

The use of DCs is said to be beneficial for cloud storage providers. However, the recent attacks on CAs strongly imply that the certificates they issue are insecure after all, further exacerbating the security issues of cloud storage providers that depend upon DCs to address their problems. This paper discusses both the issues of CA businesses as well as cloud storage security and how these two phenomena are associated with one another.

Pros and Cons: Digital Certificates and Cloud Storage

In an increasingly digitalized and computerized world, DCs and cloud storage are becoming more useful. However, users need to beware that just as both of these provide numerous benefits, there could also be drawbacks to their usage.

Digital Certificates

With the ubiquity of computers, Internet use and electronic commerce, Public Key Infrastructures (PKI) have been growing in importance will remain as a crucial enterprise security investment. PKI enables parties to transact with one another and identify each other through the use of DCs; enables reliable business communications through confidentiality mechanisms namely encryption, authentication, data integrity as well as a basis for non-repudiation with the use of digital signatures (CICA). DC, as mentioned earlier, is just like an electronic business card or passport that proves one's identity. With a DC, a user can assure business associates, friends and other online services that the electronic information they receive from that user is authentic. A DC also proves right of access to online information and services.

DCs attach an identity to a pair of electronic keys that may be utilized for encryption and signing of digital data. Because a DC enables the verification of right to access through a certain key, it can help in preventing users from using phony keys. Combined with encryption, DCs are able to provide a more "complete security solution, assuring the identity of all parties involved in a transaction" (VeriSign). A DC is issued by a CA, which is signed with the latter's private key. Typically, a DC contains the public key of the owner; the name of the owner; public key expiration date; name of CA; serial number of the DC; and, digital signature of the CA. The most widely-used DC format is defined by the CCITT X.509 international standard, so that DCs may be written or read by applications that are compliant with X.509.

DCs provide many advantages and may be used for different electronic transactions such as e-mail, e-commerce, groupware as well as electronic fund transfers. For example, Netscape uses an Enterprise Server that requires a DC for every secure server. When a shopper purchases items from an online store running on Netscape's server software, that shopper may request for the DC of the server in order to authenticate the identity of the online store as well as content provided by the seller (VeriSign). If the server is not authenticated through a DC, then the shopper must not trust the online store or merchant with personal information such as a credit card number. Thus, it may be said that the DC is crucial in establishing a secure channel for transmitting sensitive information.

Aside from this, it must be noted that encryption alone is not sufficient because it does not provide proof of the identity of a sender of encrypted data. Therefore, without special protection in place, a user may be impersonated online if encryption alone is used. Another advantage of DC is that it uses an electronic method for verifying identity. Indeed, the combination of encryption and DCs provide users with a more thorough security solution by assuring the identities of entities involved within a transaction. In the same way, a secure server also requires its own DC to assure users that the server is really ran by an organization that it claims to be affiliated with and that the content is legitimate.

A third advantage is that there are three general types of DCs to choose from, such as those from VeriSign. A server certificate permits users to operate within a secure mode (and can be accessed by an IP address) by clearly identifying and authenticating the server, as well as by encrypting any information that is exchanged between the web browser and server (VeriSign). A developer certificate, used with Microsoft Authenticode technology, provides users with data and assurance whenever they are downloading software from the Internet. Lastly, personal DCs are used by people "when they exchange messages with other uses or online services" (VeriSign). Yet another advantage of DCs is that they contain digital signature of the CA. A digital signature enables a message recipient to verify (i) that the message comes from a user it is supposed to come from; and (ii) that the message has not been accidentally or intentionally modified after is has been signed. Digital signatures are a form of assurance that they are not forged. Aside from all these, multiple DCs may be associated with a singe account so that a user no longer has to hold several accounts in order to store different sets of attributes. Due to the fact that attributes may be stored in the DC, the appropriate attributes can be selected according to the DC that the user presents.

Nevertheless, it must be noted that DCs have disadvantages, too. For instance, DCs "have not had much success in authentication systems" (Windley, p. 56). Indeed, Microsoft and other companies have invested millions of dollars developing systems for "creating, administering, and using client-side certificates for authentication" (Windley).

The main problem here is that DCs are more complex for users to manage. To note, the concepts revolving around DCs are significantly more difficult to understand than, for instance, the use of ID and password mechanisms. A second disadvantage of DCs is that they cost money. They also have to be regularly renewed such that users tend to forget their access codes or entirely lose their certificates resulting in costly refreshes. These continual spending on DCs can discourage organizations from using DCs as their primary authentication mechanism. It is also notable that certain DCs have been discovered as being unable to "provide a significant increase in the security of the authentication process" (Windley). DCs are typically stored within the computer of the user and are password-protected. Passwords are subject to multiple disadvantages and impersonators that have access to the user's computer may be able to crack the password that serves as protection for the DC. These disadvantages do not mean to say that DCs are not generally effective. On the contrary, users simply have to be aware of these drawbacks and must understand why they are using DCs and then compare the benefits to be gained from this tool with other options.

Cloud Storage

Cloud storage enables the storing of data on multiple, virtual, off-site servers hosted by a third party instead of the traditional way of storing data on a computer's hard drive or other storage device. However, abstracting hardware into the cloud does not mean simply replacing servers with virtualization, but rather about replacing physical storage systems (Reese). There are hundreds of types of cloud storage systems. Some of them are very specific in focus, such as storing e-mail messages or digital pictures.

On the other hand, there are also large operations for cloud storage the equipment of which can fill up an entire warehouse and can service corporations. Facilities wherein cloud storage systems are housed are called data centers. Basically, a cloud storage system needs only a single data server that is connected to the Internet (Reese). The client simply sends files through the Internet to the data server and then retrieves the data when needed. Generally, data are broken into small chunks so that they may be stored in multiple servers. Using sophisticated "checksums" the data may then be retrieved rapidly.

The use of cloud storage, just like DCs, has advantages and disadvantages. The first benefit of cloud storage is related to costs. With cloud storage, clients receive managed hosting at low costs. Moreover, there is no need to buy additional hardware as space requirements increase (Conner). Aside from these, data in cloud storage always have backups and providers typically provide 24/7 support. Cloud storage also enables mobility so that users may access their data through their devices.

Meanwhile, the primary disadvantage with cloud storage is that Internet connection is required to retrieve or store data. However, the most distinct disadvantage of cloud storage pertains to data security, which are (i) confidentiality, or secrecy of information; (ii) integrity, such that data is not altered without permission; (iii) availability, such that data is accessible only to authorized users; (iv) utility, so that data may be processed only by authorized users; (v) authenticity so that data is validated as genuine; and (vi) possession, so that only authorized users have complete control over their data.

Digital Certificates Have Been Compromised

Among the most alarming security breaches to have recently taken place involve CAs themselves. In 2011, two prominent CAs, the American company RSA and Dutch company DigiNotar, both fell victim to hackers. As mentioned earlier, Google became vulnerable to a security breach as a result of a Turkish CA TURKTRUST intermediate CA. To note, an intermediate certificate is like a master key that can create DCs for any domain name.

These types of certificates may be used to impersonate websites to any browser without the end user being warned that anything is amiss. As a result of the Google Chrome incident, a spate of intermediate certificate revocations was triggered, led by Microsoft and Mozilla. Aside from these, Brazilian CA Comodo issued a DC to a banking Trojan distributor which applied for the DC by using a similar name to that of a Brazilian software vendor (Tung). Also in Brazil, it was discovered that a DC issued by a local CA contained malware that was connected to a sub-domain for a cloud storage company.

As seen here, security breaches involving CAs have been taking place in different parts of the world highlighting the fact that the CA business has already become global. Unfortunately, it seems as if the increase of CA businesses world-wide has intensified the need for a coherent, cohesive and clear set of standards, policies and best practices for the regulation of such businesses. Otherwise, DCs will continue to be compromised and the consequences of this occurrence is somewhat difficult to imagine due to its potential magnitude.

It has been said that the trust placed by clients and users on DCs is only as good as the CA that issues them. This observation emphasizes that digital certification by CAs is based on the Trust model which is the principal foundation of PKI. Indeed, User A needs to trust that the public key in the DC of User B actually belongs to User B. There are three PKI trust models that use a CA, namely, the hierarchical trust model, the distributed trust model and the bridge trust model. The hierarchical trust model assigns only one master CA called the root, which signs all DC authorities with a single key (Ciampa). IN this model, when the CA's private key is compromised, then all DCs will be rendered useless. A single CA also means that there could be considerable backlog. The distributed trust model uses multiple CAs to sign DCs. This approach limits the risks of becoming compromised and the workload for verifying and signing DCs may be delegated to intermediate CAs (Ciampa). On the other hand, with a bridge trust model, there is one CA that serves as facilitator to interconnect all other CAs. The facilitator does not issue DCs but acts as a hub between the two other models.

An attacker that breaches a CA in order to generate and obtain phony certificates does so in order to perpetrate further attacks against other organizations or persons. Attackers can also use phony DCs in order to authenticate as another system or individual or to forge digital signatures. Many organizations obtain their DCs from external CAs while there are also some who operate their own CAs. Almost every organization has users and systems that establish security through the DCs of other parties with whom they communicated. Because today's "applications are sold with installed trust anchors that users may not be aware of or exp[licitly trust," any one could actually be at risk if one of these CAs are compromised.

It is important to note that aside from the CA, there are three other PKI roles in the context of CA security incidents, namely, the registration authority (RA), subject and relying party. RAs serve as the intermediary between users and CAs, as they review and approve certificate requests. When an entity requests a DC, the RA does the validation of that entity's identity and assesses whether the name is appropriate for inclusion in the certificate. The RA also assesses whether a requester is authorized to seek certification for a system with the corresponding DNS. Certain CAs also serve as RAs.

Meanwhile, the subject is a "person, organization, system, application, or device to which a certificate is issued and whose identifier is provided in the certificate" (Turner, et al.). Examples of subject systems include web servers and routers. Majority of organizations have systems and individuals to which DCs are issues and therefore act as subject. On the other hand, the relying party pertains to an individual or system that electronically interacts or transacts with the subject and depend on the subject's DC in the process. Examples of relying parties are browsers connected to web servers, which in turn, serve as subjects with DCs, or servers connected to other servers. Typically, relying parties utilize locally "stored trust anchors to validate the signatures on subject certificates" (Turner, et al.).

Support for the Topic

In light of the evidence provided in the preceding section, it is apparent that DCs have been compromised due to the proliferation of CAs world-wide amidst the reality that there is no existing coherent global system to regulate the activities of such CAs. Indeed, there are four types of CA compromises, namely, impersonation, RA compromise, CA key theft and CA system compromise. With an impersonation attack, an attacker succeeds in impersonating someone else to the RA and is thus issued a DC with that other entity's name in it. For example, User A intends to send digitally signed authorizations to User B for money transfers and the latter uses a DC issued to User A to verify the authorizations. An impersonation attack on this transaction would entail the attacker convincing a CA that User B trusts that he or she is User A, and the CA issues a DC containing User A's name, but the attacker's public key. The attacker is now able to forge User A's signature on money transfer authorizations.

With an RA compromise, the attacker penetrates the RA and is able to authorize the issuance of one or more fraudulent DCs by the CA. On the other hand, a CA system compromise takes place if the attacker infiltrates the CA and is able to use that CA's issuance system in order to issue one or more fraudulent CDs. With this method, attacker does not obtain a copy of the CA private key, but is able to use that key to issue fraudulent certificates. Hence, the attacker is able to produce at least one signed phony DC revocation lists. Lastly, a CA signing key compromise takes place is the attacker succeeds in obtaining a copy of the CA's signing key and then uses it to sign phony DCs and revocation lists at will.

To obtain a copy of the CA signing key, an attacker may steal a copy or 'attack the key and algorithm to determine the key" through the use of factoring or brute-force attacks. However, realistically, it is more likely that an attacker obtain a copy of the CA instead of attacking key and algorithm. By virtue of these CA compromises, there is heightened need not only for entities to be vigilant, but also for CAs to form a body that will promote new security standards for CAs, policies as well as best practices. Currently, such an entity is being formed by certain CAs, and this is called the Certificate Authority Security Council (CASC). Its members include "Symantec, Trend Micro, Comodo, DigiCert, Entrust, GlobalSign and Go Daddy" (Constantin). However, this membership is hardly representative of all CAs operating across the globe. Hopefully, the CASC will continue to expand upon its member base.

Cloud Storage Providers Offer Poor Security and Privacy

Many believe that cloud storage is the way forward for many organizations. To note, it has been projected that cloud computing will have a value of $57 billion by the end of this year, and is expected to escalate to more than $157 billion by 2020. However, there seems to be consensus that providers themselves cannot provide the needed security for clients' data. Sensitive data, like for instance information regarding health care patients protected by HIPAA, is too vulnerable to be left in the management of cloud hosts. Therefore, analysts have recommended that cloud storage providers use DCs - particularly those that are X.509 compliant - to enhance security and privacy. However, it cannot be emphasized that at issue here is the way these DCs are insecure after all due to unregulated activities of CAs in different parts of the world.

Security and privacy issues pertaining to clients' data have been persistent as a result of the poor models used by cloud storage providers (Tan). Notably, some of these security and privacy models reflect the Trust models also used by CAs (Tan). These include:

1. The PKI Trust Model, which depends on a number of leader nodes so that the entire system is secured. The leaders' validity DCs are signed by CAs. Gilje, Gansen Zhao and Rong note that the PKI model may cause "uneven load or a single point of failure since it relies on leader nodes too much" (p. 71).

2. Network Topology Based Trust Model, which is built according to network topology. Each entity's trust is assessed according to its location in the system topology and typically uses "tree or graph traversal algorithm" (Gilje, et al. p. 71). The management of trust in this mechanism is quite simple; however, due to the complexity of network environments, trust values are usually inaccurate so that system security breaches can still take place.

3. Basic Behavior Based Trust Model, which harnesses history trade records in order to compute trust. The trust of a single entity is gained by treating both former trade experiences as well as other nodes' recommendation. Trust value is complete with this model but is not applicable for all cloud storage users or clients.

4. Domain Based Trust Model, divides the Grid environment into multiple trust domains and then makes a distinction between two types of trust. The first is the "in-domain trust relationship" and the second is the "inter-domain trust relationship" (Gilje, et al.). The Domain Based Trust Model then establishes corresponding strategies for them. The mechanism in this framework is reasonable considering that the nodes within the same domain are familiar with each other and thus have a higher trust degree. This algorithm is not complex in terms of computations but has been noted to be a compromise between the PKI and network topology models. Hence, just like the PKI, the Domain Based Trust Model may cause network bottleneck and a single point of failure.

5. Subjective Trust Model is vulnerable to two major security risks. First, user programs may contain :malicious codes that may endanger or weaken resources." Second, resources, once they are infected by network attacks, may damage user applications. Hence, this model divides trust into several subclasses, namely, "execution trust, code trust, authority trust, direct trust and recommendation trust," among others. The problem with this model is that it cannot integrate identity and behavior certification and its mechanism is complex.

There are also other models that aim to provide security and privacy to cloud storage clients but these are too simple to deal with complex environments such as in cloud computing. These include directory-based encryption, container-based encryption and manual encryption (Borgmann, et al.). There is a need to continue developing security protocols so that they can truly address the needs of the cloud computing environment.

Support for the Topic

For cloud storage providers, it seems as if security and privacy are merely afterthoughts (Gilje, et al.). There are providers that have historically had poor security mechanisms mainly because security and privacy tent to get in the way of their business model, which is convenience and affordability. There are several risks encountered with cloud storage providers, for which they use poor models as means of addressing the problems. In cloud storage, customer data may be exposed to security breach or incompetence of the cloud service provider.

Moreover, the client has no way of knowing whether the provider shares customer data with business partners, law enforcement agents, or governments (Matthew). Further, employees of the provider usually take unauthorized access to customer data for various reasons without the permission of the client. For instance, some providers' employees may access customer data in order to create backups or check for file extensions.

Meanwhile, there have been documented instances when the cloud storage provider blatantly lie about the level of security and privacy provided to clients in order to gain the latter's business. Just as importantly, there are efficient and effective cloud storage providers that depend on DCs in order to enhance security and privacy but recent incidences demonstrate that this type of trust upon CAs have become questionable. Therefore, regardless of how careful the client is in choosing a vendor, if reputable providers depend on DCs for security and privacy -believed to be among the most effective approaches - then client data can still be compromised. In short, clients should not fully depend on their providers for the security of their data. Instead, they must put in place security measures that would ascertain the integrity of the data transferred and the accuracy of the data received from the cloud storage providers. Having IT personnel who are knowledgeable in this aspect can help the company achieve this goal.

Conclusion

DCs and cloud storage provide multiple benefits for the entities that use them, including the lack of need to maintain hardware infrastructure to host data. This translates to cost savings for the companies availing of these technologies.

In spite of whatever drawbacks DCs and cloud storage may have, a series of security breaches that have taken place relatively recently highlight the vulnerability of these two tools to attackers. Essentially, DCs have been compromised by the increase in numbers of CA businesses worldwide and to further exacerbate matters, there is no coherent set of standards, policies or best practices applicable to such businesses, overseen by a regulating body. The absence of a regulating body and policies means that they are actually vulnerable to attacks or fraudulent acts. On the other hand, cloud storage is increasingly perceived as the way forward for many organisations, but many providers offer poor models in terms of security and privacy. There are security protocols in place but these are not enough to truly prevent attackers from damaging data transmitted through the Internet. The dilemma here is that many believe DCs to be one way of enhancing security and privacy of cloud storage providers. By virtue of the recently discovered insecurity of DCs, it is apparent that security and privacy will continue to be persistent issues for storage providers. Thus, there should be industry leaders to take the business into the next level; meaning, there should be continuing efforts by both the open source community and private enterprises to continue creating security software, programs or protocols that can be used by legitimate CA businesses. With this in place, cloud computing providers can make their businesses more secure.