Key Management and Certificate Services
a) Key Management and Life Cycle
When public-key systems are attacked, the attacks usually target the key-management systems, not the public-key encryptions. Hence all key-management systems need to be well protected to ensure that attackers cannot access keys and use these keys to forge certificates. If this happens, al l trust relationships that exist will be compromised.
There are various stages in a key’s life. These stages are: generation, distribution, storage, backup and destruction and together they form the key life-cycle.
There are various systems to manage a key throughout its life cycle. This is referred to as encryption key management. It is important that all phases of a key’s life cycle are managed correctly to ensure that the security system is not compromised. There are two public key infrastructure (PKI) models that can be used to create and administer public keys:
Centralised key-management systems: places all authority used for key administration with total level entity such as CA or a trusted third party. In this model, the administrator is given system-wide control over all aspects of key management. This model can be implemented in instances where hierarchical or single-authority trust models are implemented such as when X.509 certificates are used.
Decentralised key-management systems: moves all responsibility to the user. All keys and certificates are stored locally on the user’s system or on another device and the user is in charge of all key management. This model provides less functionality than centralised system. For instance if a user loses or damages their private key, it can’t be recovered or encrypt the information. This model can be used in instances where the Web of Trust model is implemented; for instance when PGP certificates are used.
The type of model should be chosen on the size of the PKI. Decentralised key-management system can be used if the number of keys that users retain is small and if the users understand how to protect their private keys properly. But if there is a large organisation generating thousands of keys, centralised key-management systems can be used in which private-key security is managed and handled by trained administrators rather than users.
The key life-cycle management process consists of three main phases:
- Setup or initialisation
- Administration of issued keys and certificates
- Certificate cancellation and key history
There are four stages in the setup or initialisation phase:
i) Registration: in this phase, the user requests a certificate to CA. The CA then verifies the user’s identity and credentials. The verification process depends on the certificate practice statement, certificate policy and privileges associated with a given certificate.
ii) Key pair generation: this phase involves creating matching private and public keys using the e same passphrase but different algorithms. If keys are used for non-repudiation purposes, private key owners are entrusted with generating and storing such keys. Performance, usage, legalities and algorithm specifications are other factors that affect the choice of location. Multiple key pairs can be created for roles that support different services. A key pair can be restricted using policies so that certain roles are based on usage factors such as type, quantity, category, service and protocol.
iii) Certificate generation: this phase is done by the CA. Certificates are used to bind an entity’s unique distinguished name (DN) and other identifying attributes to its public key. The entity DN can be an individual, an organisation, an OU, or a resource such as a web server or site. All certificates are governed by certificate policies, and all public keys need to be securely transmitted to the CA if any other party has generated them.
iv) Certificate dissemination: this final phase involves ensuring the certificate information is secured and available to the requestor. It can be done using out-of band and in-band distribution, publication or centralised repositories with controlled access. Each method of dissemination depends on aspects such as client-side software, certificate usage, privacy, and operational considerations. There are also protocols that enable secure dissemination of certificates and revocation information.
Different domain types used different repositories. For example, enterprise domains often use LDAP repositories with appropriate security controls, along with in0band distribution through S/MIME based email.
The administration of issued keys and certificates involves:
i) Key storage: here all private keys are stored after they are created. Storing a key ensures that it is protected and cannot be lost, compromised or damaged. There are two key-storage methods:
Hardware storage: this method involves storing private keys on media such as a smart cards, memory sticks, USB devices or PCMCIA cards. Hardware storage provides easy transportation of keys and enables to enforce encryption. However, removable storage devices are vulnerable to being lost or stolen.
Software storage: involves storing private keys in a computer file on a hard drive. Each private key can be encrypted using a password or passphrase and then store the encrypted key in a restricted file. Auditing can also be enabled to track access to this file. The method of a key storage is no very reliable if the file is restored to a different medium such as a floppy disk or FAT drive as the encryption would be removed.
ii) Certificate retrieval and validation: involves accessing certificates for general signature verification and encryption purposes. To enable signature verification, a certificate containing the public key of a signed private key is retrieved and sent along with the signature or is made available on demand. Certificate retrieval is also necessary if the keys are to be encrypted and send them between sender and receiver.
Certificates are validated to ensure that they have been issued by a trusted CA and follow the correct policies and regulations. It can be done using client software before the certificates are actually used for encrypted purposes.
iii) Key backup or escrow: involves the two aspects:
Key archiving: involves the storage of keys and certificates, potentially over a long period of time. This method ensures that the users are able to recover lost keys and encrypted data. It also enables to use services such as time stamping and notarization to meet audit requirements and resolve disputes. Key archiving is performed by a company’s CA or a trusted third party. It may also be performed by the key owners but not ideal since the process is complex. All private current expired and revoked keys are backed up t an archival server, which requires strong physical security- at least the same level of security as the key-generating system.
Key escrow is a form of key archiving that enables a third party such as a law enforcement agency to access a key even without the owner’s permission. The keys are copied and are stored in an off-site repository called key escrow agency. Key escrow is no longer a government requirement. It can compromise privacy because it involves passing control of private keys to a third party.
iv) Key recovery: is the final process. The recovery of lost, damaged or archived keys enables to access and recovers encrypted data. Key recovery is handled automatically to reduce error and user intervention.
Some archive systems use the M of N Control to ensure that the recovery process cannot be abused. This access-control mechanism creates a PIN number during the archive process and splits the number into two or more parts, where N is the number of parts. Each part is given to a separate key-recovery agent – or person authorized to retrieve a user’s private key. The recovery system will reconstruct the PIN number only if M number of agents provides their individual PIN numbers. For M of N Control to work, N must be greater than 1 and M must be less than or equal to N.
Certificate cancellation and key history is the final phase of the key life-cycle management process. This phase includes the following stages:
i) Certificate expiration: each certificate has a fixed validity period. Certificate expiration occurs when a certificate’s validity period expires. After this occurs, the certificate can be renewed and used either with the same key – if remains valid and uncompromised – or with a new key that’s issued.
ii) Certificate renewal: A certificate can be renewed by using the old key to sign a request for a new certificate. To ensure that the renewal occurs smoothly, certificates should be renewed 30 days before they expire.
In some cases when CAs renews certificates, they sometimes simply place a new certificate with the old public key. Hence the user should ensure that a new key is received each time a certificate is renewed because keys become less secure overtime.
iii) Certificate revocation: if the certificate is revoked, it means the certificate has been cancelled before its expiration date. It occurs only if a company changes ISP or moves to a new address, a contact leaves the company, or a private key is compromised or damaged.
Certificate can be revoked in several ways, but the primary method is by using certificate revocation lists (CRLs). CRLs are data structure that identifies revoked certificates. They are signed to maintain integrity and authenticity. Other methods include CRL distribution points, certificate revocation trees (CRTs) and Redirect/Referral CRLs.
Instant-access methods can also be used that are available through Online Certificate Status Protocol (OSCP). Some of the factors that influence the choice of revocation mechanism are performance, timeliness and scalability.
iv) Certificate suspension: when a certificate is revoked, the system must be notified. On the instance of delay with the revocation requirement and subsequent notification, it is called revocation delay. Revocation delay must be clearly defined in the certificate policy because it determines how frequently or quickly the revocation information is broadcasted and used for verification.
In cases of certificates having very short lifetimes, revocation and notification may be unnecessary. This is because the accepted revocation delay might be longer than a certificate’s lifetime – hence the certificate will automatically expire rather than requiring revocation.
In case of single-entity approvals, certificate requests are always approved by a single entity and it might not be necessary t publish revocations separately.
In some cases, certificates are not required for a long period such as when its owner is away or a web site is taken offline. To prevent the certificate being revoked by a CA, the certificate can be suspended, which is similar to revoking it temporarily. This suspension can be published in a CRL or OCSP response with a status of “Certification Hold”. When the certificate is ready to be used again, the suspension can be removed.
v) Key destruction: is the final stage of certificate cancellation and key history. After a certificate expires or is revoked, it is generally destroyed. A key is also destroyed before a certificate server or key archival server is sold or recycled. While destroying a key, the key data is overwritten with zeros, the process is known as zeroization.
Setting up an enterprise PKI requires a lot of financial, human, hardware, time and software resources. It is also necessary to understand all aspects of the process including the aspects relating to:
- support for standards, protocols and third-party applications
- issues relating to cross-certification, trust models, and interoperability
- multiple key pairs and key-pair uses
- methods for PKI-enabling applications and client-side software availability
- impact to end user during key backup, key or certificate updates and nonrepudiation services
- performance, scalability and flexibility issues regarding key distribution, retrieval, and revocation systems
- physical access control to facilities.
b) Certificate Services Servers
PKI systems can be managed in a various ways using software such as VeriSign and Entrust. PKI management can also be handled by installing and configuring the Certificate Services component of Windows Server.
Microsoft’s Active Directory Certificate Services (ADCS) can be used to provide PKI services on the network. A computer that runs this service can perform one of four roles:
Certificate Authority: A computer running the CA service can operate either as a root or a subordinate CA. ADCS CAs can store data in AD or independently.
Certificate Authority Web Enrolment: A computer running the CA Web Enrolment service enables users to apply for and obtain certificates using their web browsers.
Online Responder: A computer running the Online Responder service handles status requests regarding certificates.
Network Device Enrolment Services: A computer running the Network Device Enrolment Service enables non-PC devices that don’t have accounts in AD to obtain certificates.
An enterprise CA can participate in and store data within AD. The CA can also use templates and publish certificates to AD and support the use of smart cards.
A standalone CA doesn’t require AD and cannot make use of any templates. All certificates will be suspended until they are issued by an administrator. Moreover, certificates created using a standalone CA also cannot be published to AD. Hence they must be distributed manually.
A root CA is at the top of a CA hierarchy. Subordinate CAs obtain their certificates from the root CA, but can issue certificates just like a root CA. A subordinate CA may be used for a division or subsidiary company.
User Certificates and Web Server Security
a) User Certificates and Key Recovery
A user certificate can be used to verify users for various purposes, like logon authentication and access to system resources. Certificates can also be issued to users for using encryption services –specifically Encryption File System (EFS) services. User and EFS certificates are enabled automatically with Enterprise CAs and are stored in AD.
Certificates can either be issued automatically or users can request them. Depending on the configurations chosen, user requests can be processed immediately marked as pending. In the pending state, a CA administrator must approve a certificate before it is issue to the user.
There could be instances where the certificate is required to be revoked. It could be either due to the user revealed their private key, consequently compromising the certificate or the most likely the user no longer works for the company or a new certificate has been issued that supersedes an older certificate.
CA console can be used to revoke certificates. It is required to specify a reason for the revocation during this process. Here are the types of reasons:
Key compromise: refers to the private key associated with a certificate has been exposed or cracked.
CA compromise: refers to the CA’s private key is exposed and all certificates that it has issued are also compromised.
Change of affiliation: refers to the user f computer has changed position or purposes which results in a certificate no longer being applied.
Superseded: refers to a certificate being no longer valid due to being superseded by a more recent certificate.
Cease of operation: applies to both users and computers. For instance when a computer is decommissioned or an employee leaves the company, associated certificates need to be revoked.
Certificate hold: refers to a temporary revocation, usually used to give the administrator time to decide whether to fully revoke or re-enable a certificate when its status is in the question.
Placing a certificate on hold is the only instance in which it is possible to un-revoke a revoked certificate. All other types of revocations are permanent and a new certificate must be issued.
There are two types of key recovery:
Key escrow: enables law enforcement agencies to obtain user’s encryption keys. In such cases, the keys are stored in a public database. Ideally, the database is secure and accessible only by authorized law enforcement agencies. Depending on the industry and applicable laws and regulations, user might be forced to escrow encryption keys in such a database.
Backup and recovery: is an internal means of preserving encryption keys which is necessary in case the keys are lost or damaged. A copy of the original key is required to access data encrypted with it.
It is not necessary to escrow or backup a user’s signing key. A primary requirement of a robust and trustworthy PKI is that user’s signing keys are unique and private. If a duplicate signing key exists even in a secure storage location, it is possible that the duplicate could be used to create false messages from the user.
Microsoft’s Certificate Services supports single-key certificates – one private key for both signing and encryption. The system provides a means to back up certificates and user’s associated private keys.
A key recovery agent is a person within an organisation who has the authority to recover a key or certificate on behalf of a user. To designate a key recovery agent, this person needs to be issued with a recovery agent certificate. Certificate service supports two types of recovery agent:
- Encrypting File System (EFS) recovery agent: can recover a user’s encrypting key and so decrypt that user’s files.
- Key recovery agent: can recover a user’s certificate. This enables the agent to decrypt the user’s files and also potentially to impersonate the user. Designating this type of recovery agent it rare as it posses the possible security risk.
There are 4 tasks involved in establishing an EFS recovery agent:
1. Enabling the EFS Recovery Agent template.
2. Enrolling for a recovery agent certificate
3. Enabling key archival
4. Re-enrolling all certificates
b) Web Server Security with PKI
Secure web servers use SSL to provide an encrypted communication channel between themselves and user’s web browsers. SSL provides both authentication and encryption.
To establish an SSL session, a party requests and then verifies the other party’s certificate. The recipient’s public key is used to encrypt a randomly chosen symmetric encryption key. The encrypted is sent to the recipient, who decrypts it with his/her private key. The symmetric key is then used by both parties to exchange encrypted information. When the session is over, the symmetric key is deleted and becomes invalid for future communication sessions.
To enable SSL, a server certificate is required to be requested and installed for the web server software being used. The Internet Information Services Manager console provides tools for requesting and installing certificates issued by commercial third-party providers or by your company’s own PKI infrastructure.
Commercial certificate providers such as VeriSign, GeoCenter, Thawte and GoDaddy offer various levels of SSL certificates. The process for buying a certificate from each of these CAs is generally the same. The process involves identity verification and that of the server vary as per the type of SSL certificate being purchased.
The general steps involved in buying a certificate from a commercial CA are as follows:
1. User creates a certificate request file, which creates a private/public key pair.
2. The request file is submitted to the CA.
3. The CA verifies the user’s identity and the identity of the server.
4. The CA issues a certificate in the form of a file.
5. The certificate is installed using web server management software, typically by uploading the certificate file and providing private key.
6. SSL connections are enabled base on the installed certificate to one or more addresses hosted by the web server.
When connecting to local computer using IIS and Internet Explorer, both a user certificate and a valid logon is to be provided for accessing the certificate server web site. Access from another computer or browser typically requires valid logon credentials only.
By default, Windows Server enables advanced security configuration for Internet Explorer. These security measures block various sites, including the user’s own computer.
An intranet certificate is issued by company’s PKI server. If Microsoft’s Certificate Services and IIS are being used, the process is almost automatic. In IIS Manager, when a domain certificate is requested, a certificate request file is created. Then the CA issues the certificate and sends it back to IIS and is installed automatically.
In some cases it is not enough to secure an account using a username and password. Hence a biometric device can be employed for securing the information. A biometric device uses a physical characteristic of a person to control access to resources. This characteristic can include:
- a fingerprint
- the hand geometry pattern
- the eye pattern
- the speech pattern
- a signature
- the DNA pattern
Fingerprint scanner: is one of the most common biometric devices in use. Here the user places a finger over a sensor window, which reads the fingerprint. The fingerprint is then compared to a database of usernames and passwords. If it matches the user is granted access to the resource.
Hand geometry scanner: is used to scan a user’s entire hand. Here the device measures the length and width of the fingers and hand. The scanned information is compared to data stored in a database.
Eye scanner: are of two types: retina and iris scanners. A retina scanner scans the surface of the retina create a map of blood vessel patterns found there. The map is then stored in a database. An iris scanner captures and compares the colour, shape and texture of a user’s iris. This includes the rings and furrows found in the iris, along with the variations in the colouring.
Voice verification: uses user’s speech pattern for authentication. A phrase is stated by the user, recorded and then archived in a database. The user’s notation, pitch and inflection are used to identify them to the system.
Signature verification: are being used from a long time in banks. Banks store signature cards in file cabinets and when user makes a transaction, compare signature card to the signature signed for the transaction.
DNA scan: is a promising biometric authentication method because each person has a unique DNA structure. A DNA sample taken from a user is analysed and stored in a database.
b) Physical Access Security
Apart from securing the access to the information on a network, it’s important to secure access to the facility that houses the network, requiring the use of physical access security measures. Physical access security measures may protect data, power sources, utility lines, equipment, employees and buildings.
Examples of physical access security include the use of security guards, ID badges, security cameras, lighting, fences, locks and other physical barriers. The level of physical access control depends on the importance of the information and assets being protected.
There are various physical access control methods such as:
- Physical tokens: are used to ensure that intruders cannot access computer. A physical token is also known as hardware token or a cryptographic token. Example: smart card and a card reader or a USB token. These tokens each contain a microcontroller and an operating system, a security application and a secured storage area. A physical token stores a cryptographic key, which might be a digital signature or a biometric data. Physical tokens can be used in single sign-on environments, where a user logs on only once to gain access to multiple systems rather than having to log on separately to each system.
- Locks: are the most common physical access control methods. Compared to other access control devices, it is also economical and offers a good first line of defence against break-ins, ensuring that an attacker needs the key or a set of lock picks to gain access. The commonly used lock is the preset lock, which is not very secure as the keys can be duplicated, lost or stolen and are easily picked. Cipher lock is more secure type of lock which is an electronic, programmable lock. These locks use either a keypad or a card reader. Some of the features that make cipher locks better options than preset locks include:
- Door delay: an alarm is triggered if the door is held open or propped open for longer than a preconfigured time.
- Key override: a special code can be set for use in emergencies or for management needs.
- Master key ring: enables management to change access codes or other features.
- Hostage alarm: if a user is being forced to enter their PIN into the cipher lock, a special code can be enter that notifies security or law enforcement of the attempted break-in.
- Man-traps: are a set of interlocking doors. It is usually configured as two doors at one entrance with a space between them. Once a person is in the man-trap, the second door will be opened only if the person is authorised to enter the facility.
- Fences: around a facility defines the boundary of the facility and is a good deterrent to casual entry.
- Lights: a well-lit area around a facility makes employees feel more secure and deter intruders. It is recommended that key areas have illumination at least 8 feet up and 2 feet out.
- Surveillance: is another important aspect of physical security. Examples of surveillance options include:
- Security guards: are a good deterrent to intruders. Guards might be stationed at a fixed location or might patrol around facility.
Guard dogs: are used along with security guards. A trained guard dogs knows how to take down an intruder and hold them until help arrives.
Cameras: are widely used. Surveillance cameras are connected to one or more monitors and record a visual feed for later review.
Motion detectors: are used to detect any movement. The various motion detectors are wave pattern infrared, passive audio and photoelectric detectors.
Logging: logs can be used to identify potential suspects when an incident occurs. They can also help in identifying potential threats if anomalies are noted. Logs can also be used to improve the physical security of a facility. Security guards are often required to keep an incident log during their time on duty.
c) Peripheral and Component Security
Information can easily fall into the wrong hands without an intruder needing to gain access to a network. Peripherals and other components are easy targets for thieves, who can use them to gain access to confidential information.
Peripherals and components that are most vulnerable to attack include:
- Removable storage devices
- Discarded devices
- Printed documents
Removable storage devices that are vulnerable to attack include:
- Universal Serial Bus (USB) flash drive
- Writable CDs and DVDs
- Removable hard drives
There are number of steps could be taken to ensure the privacy of information on peripherals. For instance, threats posed by the use of removable devices can be avoided by disabling USB support on the systems. It can be done either through the computer BIOS, Windows Registry Settings or local/domain Group Policy.
USB devices can be disabled through the Windows Registry by configuring the HKEY_LOCAL_MACHINESSYSTEMCurrentControlSetServicesusbhubUSBSTOR registry key. By default, this registry key is set to 3. Setting the value to 4 disables all USB ports, so no USB devices can be used.
Group Policy Object (GPO) can also be used to restrict access to CD or DVD drives. These settings are under Windows Settings – Security Settings – Local Policies – Security Options in the Local Group Policy Editor.
d) Storage Device Security
File encryption ensures information is not accessed by unauthorized users. It is possible to encrypt individual files or an entire disk. It scrambles the data in a file so that only those users with the correct key can unscramble and read it.
Apart from ensuring data confidentiality, file encryption prevents
- Alteration of data
- The file from being replaced with something else during storage or transmission
Encrypting File System is used in Windows to protect files. EFS are responsible for enhancing NTFS security permissions for files and folders. An intruder might gain access to the computer, but they won’t be able to open encrypted files and objects. EFS encryption is transparent where the user doesn’t have to decrypt the files before using them. Windows takes care of decrypting the files in the background. The files can be used like an unencrypted file.
EF is supported in most version of Windows Vista except for Windows Vista Start, Windows Vista Home Basic and Windows Vista Home Premium.
Within a network, self-contained computers are sometimes used for storage purposes by other network devices. These computers are called Network Attached Storage (NAS) devices.Some vendors provide native encryption on NAS devices. NAS devices typically use Network File System (NFS) on UNIX and Linux systems or Server Message Block (SMB) on Windows-based systems. It is also possible to use both protocols on most NAS devices. An encryption system compatible with NFS or SMB can be used to protect the data.
Windows Server 2008 and Windows Vista enable to encrypt the entire system drive using BitLocker Drive Encryption. BitLocker works only on the drive on which Windows is installed. For other drive, EFS is to be required. Files added to a drive having BitLocker enabled are automatically encrypted. If a file is copied from that drive to another, the files are decrypted. At boot time, if a potential security risk is detected by BitLocker, the drive is locked. A special BitLocker recovery password which is set when BitLocker was turned on for the first time is required to unlock the drive.
Following are the conditions at which BitLocker might lock the drive:
- Disk errors
- BIOS changes
- Startup file changes
BitLocker stores the key for encryption/decryption in a separate hardware device such as a USB flash drive or a Trusted Platform Module (TPM) chip. A TPM chip is a device that secures and protects information by storing the cryptographic keys used to encrypt and decrypt data.
BitLocker requires at least two partitions. The first partition needs to be the drive on which Windows is installed and is the partition that BitLocker encrypts. The second partition is the active partition which needs to be encrypted in order for the computer to start up. And the drive needs to be formatted as NTFS. The BIOS needs to support TPM or USB devices during startup.
In order to configure hard drive using BitLocker, the BitLocker Drive Preparation Tool is used. It can be downloaded from Microsoft site. Firstly the drive has to be formatted as a basic disk with simple volumes formatted as NTFS.
Depending on the hardware and the preferred security level, BitLocker users one of four different authentication modes in the boot sequence. These are:
- TPM without any additional authentication factors
- TPM with a PIN
- TPM with a USB startup key
- A USB startup key and no TPM
When the operating system starts up and BitLocker is enabled, the boot code goes through several steps. The exact steps in the process depend on the volume protections that were configured.
The BitLocker life cycle involves four stages:
Installation: Windows Vista Enterprise and Ultimate install BitLocker during the operating system installation. For Windows Server 2008, this is an optional feature.
Initialisation: If the computer contains a TPM, it must be initialised either through the TPM Initialisation Wizard, the BitLocker control panel or through a script. A member of the Administrators group must perform the BitLocker and TPM initialisation.
Daily use: For daily use, computers using only TPM authentication log on as normal to the Windows. If additional authentication factors are used, the user will need to enter a PIN or insert a USB startup key to start Windows.
Computer decommissioned and recycled or redeployed: when the computer is decommissioned or redeployed, the data can be left encrypted and remove the keys to reduce the risk of data being available on the computer afterwards. The keys can be removed by formatting the encrypted volume.
A recovery key is created when the disk is first encrypted with BitLocker. Actions that might required the recovery process include:
Moving the protected drive to a different computer
Installing a replacement motherboard containing a new TPM
Turning off or clearing the TPM
Boot component updates that cause integrity validation to fail
A forgotten PIN
Loss of the USB drive that holds the startup key
During BitLocker setup, a randomly generated password of 48 digits is created, which must be entered during recovery.
Domain administrators can create a group policy that automatically generates recovery passwords that are transparently backed up to an Active Directory domain server when BitLocker is enabled.
The administrator can also configure BitLocker to prevent it from encrypting a drive if the computer isn’t connected to the network and the Active Directory backup wasn’t successful.
A recovery key can also be created and saved to a USB flash drive during setup of BitLocker. During recovery, the user is prompted to insert the recovery key.
Recovery can also be used as an access control device when a computer is decommissioned or redeployed. The user needs to contact an administrator to get the BitLocker recover information needed to unlock the drive. During recovery, the volume master key is decrypted via a cryptographic key created from a recovery password or via a recovery key stored on a USB flash drive.
Apart from BitLocker, there are other third-party products used for whole-disk encryption. They are:
PGP Whole Disk Encryption product: is used in conjunction with PGP Universal Server. They are used for the management of policies, users, keys and configurations. It can also be used with other PGP encryption products to offer additional layers of security.
Whole disk encryption: is based in a hardware-based solution. The encryption and the associated key are maintained separately from the CPU, which prevents the computer’s memory from being a route for potential attacks.