Encryption and Decryption Requirements v1.2

1.     Current situation

It is quite messy. Any junks could enter any personal PC or networks at any time including government’s PC and networks.

All OS and anti-virus software had embedded bugs years ago by those fuckers. Thus there was no security to any person as junks would do anything with our personal information stolen from our PC.

Many of junk and fucker’s PC and network as well as their software messages were encrypted that law enforcement couldn’t decrypt.

So, it’s like junks and fuckers have been controlling/snooping computers and networks. It wasn’t law enforcement as expected.

Most of those junks, insane, and fuckers are users of neural networks, i.e. deadly.

2.     Proposed solution

a.      PC should be better equipped, thus any unauthorized personnel couldn’t infiltrated. Basically nobody could enter unless users had installed malware that was not detected by an Internet Defender, Packet Analyzer, or antivirus software in that PC.

b.      Law enforcement should be able to

-         Seize a suspected PC or network for investigation during a period of time. This would give law enforcement a tool to investigate and stop criminals as needed. If there was an “implemented” gate for law enforcement to enter our PC or network at any time, those tools would be leaked to junks and fuckers one day. We’d face the same mess as of today.

-         Snooping would be a privilege of law enforcement authority. All encrypted messages must be able to be decrypted at designated terminals.

o   Decryption key must be a combination of software and specific hardware. Nobody could safeguard a master software key, i.e. leaked to junks and fuckers.

o   Any designated terminals above must be safeguarded by assigned personnel.

o   With snooping ability, law enforcement would require fewer cases to seize our PC or network, i.e. less interruption to our daily activity.

-         Law enforcement’s organization had rules to follow regarding snooping and seizing a computer, thus it doesn’t cause headaches as what insane, junks and fuckers did to our computers. Law enforcement would purge our PC data in their server, if we were not the criminals that they had thought.

c.      Currently law enforcement in many countries have cooperated in the fight against junks, fuckers, and insane using neural networks, thus they have been sharing a lot of information with each other.

-         The issue of sovereignty would come up when we have finished destroying neural networks.

-         Many targeted junks, insane, and fuckers would still be hiding around and waited to build another neural network or to spy on all of us.

The decryption terminals of each country should be within borders. However if an encrypted message crossed a border, then law enforcement of the sender’s massages would help the other law enforcement to decrypt that message.

3.     Variable encryption keys and channel hopping

a. Mobile telephony technology

In mobile telephony, there is an authentication algorithm involving SSD to authenticate a mobile phone terminal. The SSD is changing every time a mobile phone user made a call. This SSD was generated by a server and mobile phone based on some predetermined parameters each time. This is a dynamic authentication technology.

A mobile phone is communicated with a radio base station (RBS) in a designated voice channel. There are many (frequency) channels available for many mobile phones. By changing the channels from time to time during a call would make eave dropping harder. Of course, the mobile phone and RBS must know how to communicate correctly in this frequency hopping case.

Currently many encryption algorithms allow a master key to decrypt all messages. This is a weakness as nobody could safe guard a software or hardware master key in many years.

b. Messy situation

The current situation is messy, because hackers could hack any company or private computer at any time with holes embedded in operating systems, popular applications as well as malware spread over the Internet.

Why did they hack our personal computer even though we didn’t have anything sensitive or valuable? They have too much free time.

If we could make all company networks secured, hackers would be busy hacking all business for their financial statements, business plans, etc. They wanted that stuff for making money. Of course, personal computer would be safe and secured or ignored by hackers.

c. Deploying dynamic encryption and hoping frequency

By using dynamic authentication, SSD, as an encryption key to decrypt a message we could have dynamic encryption for our communications. The algorithm could use some unique IDs of the user and hardware, too.

SSD is generated by an algorithm, thus there could be several algorithms to generate SSD for both server and a terminal, i.e. a pool of algorithms to change occasionally or in each communication.

-         Communication could be changed with dynamic encryption and channel hopping technologies, i.e. computer for Internet, landline phone, cable (for Internet and VoIP phone).

-         Mobile phone protocols

-         Satellite, if it is used for communications. I guess, satellite TV is lower priority. The only concern would be GPS navigator, but it’s not easy to obtain a GPS’ ID of a user device.

-         TV broadcasting is at lower priority

-         All business networks must be secured with all relevant updates and bug fixes by software providers.

Government agencies have authority and tools to decrypt messages with “designated and controlled” terminals, thus they could monitor the Internet for malicious activities. They could enter those control rooms for Internet, cable, satellite, or mobile phone easily, btw.

4. Example for protocol of dynamic encryption
4.1 Setting up encryption sequence

Assuming that bank and user PC have a list of encryption algorithms available for communication. Because some encryption algorithms are not available on some PC or servers, there should be some overhead messages to exchange the list and order of encryption algorithms to be used.

In the above scenario, bank or a financial institution would order the sequence of encryption to be used in subsequence communication, i.e. encryption named E1, encryption named E2, and encryption named E3.

·        PC1 would acknowledge the request with Ack_OK if it has all 3 encryption algorithms suggested by the bank. Future communication would rely on all 3 encryption algorithms, i.e. E1, E2, and E3 in that order.

·        PC1 would reply with encryption named E1 and E3 to the bank, if it only has E1 and E3 stored in its PC. In this case, bank would reply with an accepted message. Future communication would rely on only 2 encryption algorithms, i.e. E1 and E3 in that order.

4.2 Communication with accepted order

The bank server could communicate with many PC users at the same time. The sequential order of algorithms to each PC users could be different. For example, PC2 would use the order E3, E1, and E2 suggested by the bank.

In each subsequence messages, the protocol would include the number of encryption to be used in decryption for each user. For example,

In the above message for PC1, the first message would use encryption E2, and the second message would use encryption E1.

If the same message above sent to PC2, the first message would use encryption E1, and the second message would use encryption E3.

4.3 Changing sequence of encryption algorithm periodically

The control server, e.g. bank, could order changing the sequence of encryption algorithms periodically with protocol described in the section 4.1.

If hacker eaves drop at the middle of a message, they wouldn’t be able to figure out the meaning of “1, 2, or 3”. Those numbers had been associated in encryption algorithms during initial set up.

Financial institutions, ecommerce, and government servers should order a sequence of encryption algorithms in communication. However, PC of a user should order the sequence of encryption algorithms in communication for communication with other servers.

In case of mobile telephony, an RBS should order the sequence of encryption algorithms to each mobile user.

Packet, Transaction, or Protocol Programming V1.7

1.     The main difference between traditional and packet/protocol programming

The protocol programming language like PLEX-C doesn’t offer function calls. A program module/block sends a SIGNAL with data to another block explicitly or all blocks that waits for this particular SIGNAL with expected data.

SIGNAL with data is like a PROCEDURE in traditional programming languages such as JAVA, C++. However the signal, when sent, is logged in the CPU processing queues and waited to be dispatched to destination blocks. Thus there is no looping at a block to wait for an expected function/procedure calls with data.

For example, at an Internet PORT’s interface, where a packet comes; we could dispatch the packet to correct programs by sending a SIGNAL with data; in order to do this, an application must register a SIGNAL at the interface, thus the module would dispatch the packet automatically to its destination as long as the conditions met. This SIGNAL could wake up an application in the form such as a process. Currently a program must be looping at a PORT indefinitely to catch a packet, i.e. using a lot of processing power of a PC.

2.     Sample of a packet analyzer and filter

Diagram 1. Examining incoming packets before delivering to a destination program

In the diagram above, all incoming packets would be dispatched to a relevant subsystem for processing in order to determine if the packet is legitimate. If the packet was harmful, it would be logged in database as well as triggering a report to attendance to take appropriate actions.

Basically the Packet Filter Manager would examine types of an incoming packet, and it sends a SIGNAL with relevant data to correct subsystem for validation. The same packet would also be sent to Unpacker module/block for unpacking in the form of a SIGNAL.

Of course programmer could implement

-         Dispatching Interface block to make their subsystem well defined and declared to other subsystem using OOD or API concepts.

-         Library with clear Dispatching Interface to share common functions.

The unpacker’s functionality should be a common task used by many of the subsystems in the diagram. Thus it could use a common library function.

3.     Dispatching interface for protocol programming languages

The entry would be a signal receiving interface with specified/required signal data, where the request would be dispatched to a specific block or module within its sub-system. However the returning data or result would be done by another signal or returning function via the same interface. How data would be communicated, users must refer to the protocol specification. Of course, the interface would also be documented with the meaning of each data in a signal. Developers may attempt to specify the possible returning signal(s) as there may be many possible outcomes for a request. Protocol specification would be a better option.

If an interface module is large, developer could introduce another interface module to access its sub-system.

The interface module should be updated to add more entries or returning signals for other sub-systems. However modifying an existing entry or returning signals to incorporate more data/results would require regression testing or updating of all existing functionality, i.e. lots of work and time as well as potential bugs.

This interface module could be used to be an interface to common functions. This is similar to building a library of functionality.

For PLEX-C, developers could add more new signal data at the end of a signal to carry new information; however modifying an existing signal data would require more investigation to exiting functionality or programming codes. The corresponding protocol specification and dispatching interface’s documentation must be updated for new message data.

4.     Sample program to receive an incoming packet

Assuming that the unpacker had removed all irrelevant headers of a packet before delivering to a program, the company XYZ had registered an expected SIGNAL at Registration Interface Manager as XYZReportingTask.

In a dormant process module, it could be programmed as (samples to demonstrate the structure or format of receiving and sending SIGNALs)

-------------------------------

RECEIVE XYZReportingTask OriginatingAddress,

                                                        NumberOfReport,

                                                        NameOfReport,

                                                        FieldData1,

                                                        FieldData2,

                                                        Etc;

GOTO ProcessingReport; ! redirect signal processing to a label called
                                                     ! ProcessingReport

                                                     ! by using label, programmers could place all expected

                                                     ! receiving SIGNALS and data at one place in a block. Just

                                                     ! for organizing and ease in debugging and reviewing a
                                                     ! programming block

ProcessingReport:    ! this is the label in this block to process data coming
                                       ! from the signal XYZReportingTask

-         Processing the report data or further unpacking in forms recognized by XYZ system.

-         Log data in database as needed

IF all data were as expected and acceptable

SEND TO PrinterBlock StartPrintingReport CompanyName, Address, PhoneNumber, InvoiceID, etc;

      ELSE  

SEND SpecialAnalyzer CompanyName, Address, PhoneNumber, InvoiceID, ErrorCode, etc;

      ENDIF;

EXIT;  ! Release the central processor for other processing tasks

-------------------------------

The XYZReportingTask, StartPrintingReport, and SpecialAnalyzer are SIGNAL names. All variables followed those SIGNALs are signal data. The program would process signal data with programming statements similar to any traditional programming languages including INSERT those in database.

The XYZReportingTask signal came from the central processor queue, which was originally inserted in by the Delivery Manager block. This program didn’t loop for an incoming message at an Internet PORT. The Delivery Manager must include the destination Block Name, Signal Name as well as signal data to this programming block.

This programing block sends the signal StartPrintingReport to the central processor queue, which would be delivering to the programming block PrinterBlock for printing a good report.

This programing block sends the signal SpecialAnalyzer to any programming block that expects this signal with data for analyzing errors.

All internal/block SIGNALS had been registered in the registration system at compilation, thus the central processor knows where or the block should receive a particular signal correctly.

5.     Central Processor

Basically the central processor has signal queues with associated data. The queue is FIFO rule. There are several priority queues to process data according to level of importance, e.g. system may insert their signals in Priority Queue A. Queue Priority B is for normal tasks. Priority Queue C is for lower level tasks such as printing.

The queued SIGNALs would be delivered to a particular programming block or be broadcast to many blocks waiting for the same signal with data.

There must be syntax for a packet/protocol programming language to specify a method to send or receive a SIGNAL.

6.     Tracing/debugging issues on live system and patching

Ericsson’s APZ (central processor) offers a packet programming language called PLEX-C. This language also uses a specific syntax for SIGNALs sending and receiving. I used to work over there, but I didn’t remember the syntax.

The system offered a tool called TEST SYSTEM. Testers could activate this tool to see signal names and signal data passing between programming blocks. By analyzing passing data in a signal, testers could determine if a block analyzed and passed data correctly or not.

By checking signal data at some particular points, testers could narrow down issues quickly and figure out a solution by writing assembly patches/codes to load on a live switch. Other testers could use these patches as a temporary solution to continue their testing activity. The permanent solution would be implemented by high level programming language such as PLEX-C, compiled into assembly codes, and then loaded on the central processor (APZ) later.

Usually the process to implement a solution in high level language would take more time and scheduled at a determined phase. Thus temporary patches were useful to keep testing activity going.

7.     Parallel processors

The Ericsson’s APZ has 2 main processors, which has many CPU in each processor. One of them is the executive processor and the other is standby processor.

The executive processor is the live node to handle real time data and processing. Data is also passed to the standby processor as a mirror database and backup. If the executive processor is faulty for a reason, the standby processor would take over as the executive processor.

In normal circumstances, new programming codes would be compiled into assembly languages and loaded on the standby processor. Technical support would trigger a process to transfer real-time data on the executive processor to new codes and database on the standby processor before an automatic switching processors happened, i.e. standby processor with new codes becomes a live node.

-         The old codes and database were still on the standby side. If the executive side was faulty for a reason, technical support would switch the standby side with previous codes back to executive side as a live node.

-         Both processors would be brought back to run in parallel later if everything was normal.

APZ is used in telecom switches, which couldn’t be down for more than 20 minutes (decade ago allowed time) a year. Thus the process to switch processors over was short and carried out in maintenance windows, e.g. 12AM to 5AM.

8.     Sample of tracing or verifying the SMTP subsystem in the diagram above

Tester could initiate TRACE of

-         Incoming signals to the Packet Filter Manager, i.e. incoming packets

-         Incoming signals to the interface block of SMTP Subsystem, i.e. delivered packets from the Packet Filter Manager

The SMTP Subsystem could log some data into database by a programming block, e.g. by block UpdateData.

-         Trace a variable in the block UpdateData, e.g. External_OPC variable, that would change value before committing data into database

-         Outgoing signals from the block UpdateData

-         Outgoing signals from the interface block of SMTP Subsystem, i.e. packets out from the SMTP Subsystem

-         Incoming signals to the interface block of Report Manager

-         Trace a variable in a block of Report Manager, e.g. ErrorCode, that would change value before committing data into database

-         Outgoing signals from the interface block of Delivery Manager

Use another PC connecting to this system using an Ethernet cable or WiFi in order to send packets.

There should be a tool for testers to assemble a file of packets in a proper protocol format. Testers could create many packets with different scenarios. Send a good/bad packet or a set of packets in a file with different errors.

Based on the packet sent and signal data collected in the above traces, testers should be able to determine if the overall SMTP Subsystem have been functioned correctly.

-         There should be signal descriptions associated with the system to interpret the meaning of each signal data in a signal to/from a block.

-         If the values of the traced variables above were set before or after a signal leaving/coming to a block as expected, this would mean the data had been committed to database at proper time. Verify database to ensure its value and format.

Testers could also initiate a TRACE on the Outgoing Packet Manager in case the PC request the originating node to resend an erroneous packet.

If errors or unexpected behaviors have been detected, testers could trace many blocks in the subsystem to figure out the location of bug(s). Of course, assembly patches could be implemented to load on the node to correct issues.

9.  Notes about trace tools Ericsson’s APZ or APY and a packet analyzer

-         Notes were written at https://peterboroughtechservices.blogspot.ca/p/signalstracing-on-apz-ericssonsapz-is.html

-         Couple with special commands, APY could be used to implement the packet analyzer above to track down illegitimate activity, to record, and to bring those nodes down. Notes at https://peterboroughtechservices.blogspot.ca/p/tracking-adevice-using-internet-a.html

The detailed syntax must be provided by the equipment provider.

10.     Packet Analyzer

I had developed the concept of packet analyzer or special firewall earlier. Notes could be found at https://peterboroughtechservices.blogspot.ca/p/my-special-firewall.html. There is a link in the notes to download my documents.

The packet analyzer could be implemented to protect a PC or network. It is a little bit different than the current antivirus programs in the market.  The concept was based on analyzing incoming and outgoing packets as well as the protocol specification for each Internet protocol and current activity within a PC or networks.

I like the unattended mode in my document as hackers had threatened to enter my PC when I was away from my PC, which was connected to the Internet while I walked away.

-         Basically the Packet Analyzer would detect if a PC or network had no user activity such as typing on a keyboard.

-         Current activity such as downloading files using http or ftp

-         If there was no activity or PC’s screen saver was activated, the Packet Analyzer could shutdown Internet connection, but allowing current [pre-defined] activity to continue until completed. After completion, the Internet was completely off. Some activity wouldn’t be allowed while users were away from their terminal, btw, as a pre-defined rule.

-         If user unlocked the screen again, the Packet Analyzer would restore Internet connection.

Personally I don’t want any software applications that I am using access or open a Port of the Internet communication, e.g.

-         Microsoft Office or Adobe’s PDF unless it is opened on a web browser. End users didn’t buy an Internet or server version of MS Word, thus all edits should be local.

-         Updates could be done periodically, but shouldn’t have a permanent connection to an Internet port. Perhaps at installation, user would accept the update feature, thus an Internet defender, e.g. Packet Analyzer, would let it open port sometimes for checking and downloading. Start of downloading updates should ask for user’s permission. We don’t want hackers faking a company to upload harmful software to our PC.

-         Having a Port open permanently would give hackers an opportunity to enter our PC.

-         Internet games, Internet applications, and Internet streaming applications are within another category.

Recently hackers had faked downloads from well-known companies to a user’s PC. The actually downloads contained harmful virus or Trojan Horses.

The Packet Analyzer concept is simple, but software product providers must analyze a protocol and legitimate activity in order to provide a best Internet defender. Antivirus companies could use this concept as well as their existing features such as detecting known hacking programs to enhance a PC security.

Law enforcement would be able to develop all features of a packet analyzer including special measures such as tracking and bringing down attackers.

Private packet analyzer for users would focus on the features to defend user’s PC or networks. It could log intruder’s data and reported to local authority later. Unless the private companies had permissions by law enforcement, they shouldn’t attempt to launch special measures against intruders as this may involve special rules and agreement among local law enforcement and many countries.

11.     Features should be included in a personal PC’s Internet Defender

The Internet Defender or Packet Analyzer should offer an interface for users to do the following simple things:

-         Block all Internet ports

-         Open http port

-         Start a program within the PC – of course an application that allows accessing Internet using http, e.g. a web based game or a web based chat room.

-         If the application worked fine. Only http port is needed.

-         If it didn’t work? The Internet Defender should know which port an external application is trying to open or communicate, i.e. check to see if the target server relayed answers or response to another port of this PC.

-         Internet Defender would prompt the user to open that port manually, if a request or outgoing TCP/IP packet had been detected earlier.

If the Internet Defender could also offer blocking an (troublesome) Internet protocol, it would be easier, too. In this case, users would block some protocols regardless of ports. If a user allowed a protocol regardless of ports, it may open many gates for intruders.

Note that some applications must be originated in a PC in order to get response from an external source, i.e. responses or messages came to a PC without a PC’s originating request would be illegitimated.

In contrast, some process could be started by an outsider such as incoming email or use of incoming SMTP.

12.     System Security

The Internet Defender or Packet Analyzer are screening and validating Internet messages at packet layer coupled with current activity in a PC or network. Thus the system is quite secure.

The only concern would be lower layers of an OS such as transmission layer. Those lower layers should only be accepting electrical signals to pack those into TCP/IP or UDP packets for processing OR unpacking a TCP/IP or UDP messages into electrical signals for transmission. No funny or hidden functionality should be implemented.

13. Register Interface Manager

The signal XYZReportingTask with data D1, D2, D3, …, D_n described in section 4 and diagram 1 will be delivered to its dormant process upon receiving by system thorough Internet communications. With this implementation, developers could avoid creating a forever loop to catch Internet data at an Internet port. The dormant process would be wakened up to handle data as needed, i.e. avoid wasting CPU processing power and RAM.

There would be several ways to implement and enforce dormant process to save processing power of a system, e.g.

·        For time slot applications such as collecting data in a predefined interval, e.g. 12 pm-1 pm, the processing application would be wakened up by an Internet signal via Register Interface Manager. It processes data between the allocated interval, and complete required tasks received until 1 pm. After processing the last signal, it would be back in sleep mode as coded by application developers.

·        Intermittent Internet process, i.e. processing Internet messages randomly, the application would be wakened up and processed data via a signal from Register Interface Manager. After processing data, it would be back to sleep mode, if idle for a couple of minutes as coded by application developers.

·        OS could determine any applications in idle mode for a predefined time interval; it will put those applications or processes in sleep mode.

Those suggested methods would help performance of a computer system.