The Ultimate Path to Absolute Digital Security

Operating System

An operating system can become a security role player without degrading performance, user convenience or reliability. The information in a SESR report exist as flags that an OS can expose through system calls. The SESR report provides information that may be checked by an OS and other programs to assess code operations. These code operations may involve the existence of device input simulations. A code operation may further involve omissions such as the absence of a SESR report check in an application that allows embedded code execution. The presence of a SESR report is crucial to making such validations for security. Therefore, a validation failure due to absence of a SESR report is an effective security feature. An operating system may add to status flags defined in the SESR report as deemed necessary. The corresponding set of system calls would be added or changed. This should cause relevant code translators to align operations that evaluate status flags.

A computing environment is managed by an operating system. Therefore, a resource should be properly managed at the instance of entry to such an environment. The efficient management of a resource requires an OS to define a specific point of entry. The transfer of a resource from an external network or device to a computing environment can best be managed at a single point of entry. This constraint facilitates the prevention of a malicious resource from causing damage. A Windows operating system has a Download folder that should be enforced as the sole storage location for inbound resources. The changes to a current OS implementation may involve diverting inbound transmissions to this storage point and checking a SESR report. A transfer to the intended destination would follow. This feature can lead to detection and control of a malicious resource in the following manner.

Operating System

An operating system should allow only launch and install operations on a resource stored in the sole point of entry. The following launch steps would be similar from any storage location. A launch operation first identifies the program that can read a resource. The resource could either be classified as data or code. The program would read a data resource as instructed in code. A code resource would be detected by the OS through a file that originated from a code translator. The program (through system calls) would check a SESR report associated with a code resource. A failed validation through the SESR report should block further launch actions. This implicit check of a SESR report applies to embedded or interpreted code. Any software that can execute embedded or interpreted code should always check the affiliated SESR report. An operating system would verify this behavior during the SESR report check that precedes installation of such software. The Code Translator section provides details.

An install operation is the crucial step that validates a code resource for permanent placement in an environment. An operating system should provide a system call that serves as a mandatory gateway for the placement of software. This system call would check for the existence of a file created by a code translator to mark a resource as code. This file should be placed at the root directory of a code resource (similar to a SESR report). The detection of this file would initiate a SESR report check before transfer of a program or code resource to a stable location. Any detected absence of this file should halt further action. This is an important security feature that prevents illegitimate software installation. A failed validation from checking the SESR report should block installation or transfer. The procedures that take place at such an intermediate storage point prevent surreptitious entry of resources into an environment. Any software that hosts inbound transmissions (e.g. a browser) would have been validated through SESR report checks or the Secure System Call protocol (to be discussed soon).

Operating System

An inbound transmission should be classified as originating from an external network or device. An interdevice transfer within the same network would be allowed. However, reliable encryption of a resource should occur before transfer to a portable storage device. A reliable encryption goes beyond the use of private or public keys since a breach that can undermine security is possible. An OS should decrypt resources from such a device before transfer to the single storage point. This step should always occur manually and never automatically. The secure transfer of resources from a computing environment to an external network will be discussed next.

A further proposed role of an operating system involves a Secure System Call. A Secure System Call (SSC) provides an entry point to any program (or operation) that is not part of the operating system. The prerequisite for a successful call would be to verify a caller has an available SESR report. The absence of a SESR report should cause a secure system call to fail. The target operations are manually validated through a protocol dictated by an OS vendor. Any operating system call made by such target operations would be justifiably considered safe. The target operations may reside in executable files or other forms of software. This validation provides a means for an OS to selectively authorize software for a specific purpose. Furthermore, an SSC allows different software to interoperate in a secure manner. The selective validation of software that perform specific operations in an environment is a vital security measure. A special identifier would be assigned to software that has been validated by an OS. This ID would be placed in code according to an OS vendor mandate. A code translator would check the ID during generation of a SESR report. A system call would be provided for the sole purpose of checking this ID. The reference ID may be stored on a server, encrypted by an OS or both.

Operating System

The SSC provides an effective means of identifying secure data during network (including internet) transmission. The process would involve creating a transient token that can be verified by an OS before sending data to a network interface card. The creation of this token would arise from a system call. The details of this process follow. A Secure System Call to a security provider (like APSCCS) is made by the host program that intends to transmit data. The data involved would have been previously encrypted through APSCCS. Therefore, the host program makes an SSC to an APSCCS routine that causes creation of a transient token in memory. The OS would store this token in an exclusive location.

The APSCCS routine first checks a data location to ensure protection remains intact. A system call is then made to the OS to create a token that expires within a reasonable time frame. This system call would require the number of bytes expected to be transferred from storage. The token would include this data size. A copy of this token is stored in a memory location designated by the host program through call parameters. The created token would precede data in a buffer for network transmission. This buffer is already a standard parameter in a system call named send(). The OS compares memory and storage token instances to verify that a data transmission is secure. Also, a data transfer size is restricted by the token. These operations would involve a relatively slight change in the TCP send() implementation.

The data produced by a security provider may need to be compressed into a Zip file. This scenario represents a legitimate change to secure data that an operating system may allow before transmission. A separate system call that generates a transient token from an existing (yet transient) one would be required. The legitimate change to secure data would be provided either by an OS or another program certified through an SSC protocol. The existing token must have been generated through a security provider.

Operating System

A data transmission classified as secure must be reliably encrypted to prevent execution in memory. A reliable encryption should not involve private or public keys. The secure data is always transmitted as a file. Therefore, entry into an environment should occur through the OS storage point mentioned earlier. The means of identifying secure data provided through an SSC warrants tagging within appropriate transmission headers. This would allow endpoint software (ports) to accept or reject inbound transmissions. An operating system would ensure this behavior through SESR report checks before software installation. Furthermore, the SESR report would reveal any unsafe code execution from an inbound resource not saved as a temporary file.

A summary of elements mentioned so far will now follow. These elements can guarantee code and data security when put in place. The protection against malicious code is twofold. First, any surreptitious code can be prevented from doing harm through reliable encryption. Any explicit program or software should also be prevented from doing harm to an environment. This is possible through an operating system applying the SSC protocol to restrict code activity. Furthermore, the presence of a SESR report for corresponding code allows an OS or other software to detect malicious activity. The appropriate contributions made by operating systems and other software role players can facilitate SESR report accuracy. An operating system can provide system calls that verify code security through a SESR report.

The operating system plays a crucial role in this proposed approach to digital security. An important feature of the SESR report is that it contains data that can be read easily by a computer program. These data exist as flags that depict the security states of code. The operating system may read these flags before proceeding with installation, reception or transfer of software. The option of checking for such flags could be added to OS configuration settings. An operating system may also check these flags completely rather than set their detection as options. The flag checking operations intrinsically have a negligible effect on performance.

Operating System

The SESR report provides several flags that can aid in analyses toward conclusion of a security state. However, the SSC protocol is effective for instant validation during network transmission. The following is a sample scenario. A file is attached to an email transmission. There are two options to generating the attached file. The first is through an SSC to a security provider. However, the file available for attachment may reside in a secure folder. This case leads to a second option of creating an attachment as a Zip file. The email software would not create this Zip file. The utility that zips this file would first generate a transient key through a security provider. This key would be available for a separate system call that generates the key passed during email transmission. The email software simply attaches the secure Zip file. A transient token created by the operating system would now be available. The email software then appends this token to an appropriate header (e.g. HTTP) during email or other data transmission.

A resource transmission scenario (such as FTP) may involve multiple files that should not be zipped. The kind of transmission involved in code deployment is an example. A code transmission should only be accepted from a tool with a SESR report. The transmission tool would generate a token in one step through a security provider.

Summary of Operating System role

Creates a protocol and a set of entities classified as a Secure System Call

Allows applications to interoperate in a secure manner
Provides a means of selectively authorizing applications for specific purposes
Provides validated software with an SSC ID

Add a system call that creates a transient token for secure transmissions
Enforce a single storage point for inbound files from an external network or portable device
Add a system call as mandatory gateway for installation or transfer of programs to a stable location

Checks special file that identifies resource as code

Add system calls for programs to verify code security through SESR report
Extends status flags defined in the SESR report as needed

Adds or updates corresponding system calls

Add operations that validate software through a SESR report (including checking for presence) before installing or transferring to a stable location
Always reliably encrypt data before transferring to a portable storage device (USB, etc.)

Previous Next