I would like your opinion on my outline for a software design concept aimed at security purposes.
The core principal is a timing logic to determine whether the client machine has used processor
time to maliciously analyze code abstractly sent to it. I will attempt to describe a logical server
barrier for the client without any coding examples. The idea is to isolate the client's ability to
resist server security. This means no hacking of the server is possible! Please feel free to
correct, suggest, or dispute any part of my proposal.
The client will encounter four distinct protocol sections labeled #1,2,3,4. I will list them in chronological
order while progressively describing their relation and design concepts.
Program #1: This program is the starting point for the client machine. The sole purpose of Program #1
is to download Masking Class #2 and call its method(s) abstractly. Program #1 will use the Method Class
to make an abstract call to Masking Class #2's method(s).
Masking Class #2: It is necessary to use a Masking Class #2 which gives the server the ability to assign
the address of where Abstract Class #3 is to be downloaded and subsequent communication passed.
The server will dynamically code Masking Class #2 with an address, send, and begin to track the
authentication attempt and subsequent client activity. Ideally, the communication at any point should only
be through the original address and port included in Masking Class #2. Masking Class #2 will download
and run Abstract Class #3. Masking Class #2 will use the Method Class to make an abstract call to
Abstract Class #3s method(s).
Abstract Class #3: This class completes the center of the proposal. The design relationship or reference of
subsequent implementations of Program #1, Masking Class #2, and Abstract Class #3 will be referred to as
the Security Concept from here on. Especially the implementation of the receiving and using of abstract code
in this configuration for execution time analysis. The Security Concept should be repeatedly implemented as
effectively desired at any point.
Abstract Class #3 will control the transfer of authenticating information to the server and will download Program #4.
Abstract Class #3 will be designed to satisfy a number of security criteria. Abstract Class #3 will be designed for
server monitoring of untimely delays of its execution once the client's machine has received it. The server will be able
to select from a number of Abstract Class #3 versions and send them to the client as many times as it takes to verify a
consistent timely response. A consistent timely response will ensure the client has not had time to analyze the code for
malicious purposes instead or before sending back the desired version's return protocol response.
The versions of Abstract Class #3 and the client's entire computer should be designed solely to ensure an accurate measure
of execution time. For private client computers, as much data and understanding of their software and hardware needs to
be obtained. The balance of effectively measuring execution time will be weighted with redundant security protocols. It is imperative to
consider and implement security protocols along side the design to accurately measure execution time.
Abstract Class #3 will have an ever-growing number of versions. A wide array of versions should
exist and new versions should be created as often as possible.
Client to Server Speed Test
Client to Server Ping and Latency
Abstract Class #3 will be extremely large and complex for security checks and to stress and measure the client's execution time.
A client who is presenting an unrealistic or security threatening latency or ability to download large files should be denied authentication.
Various methods of sending fragments and assembling Abstract Class #3 is ideal.
Complete Client Computer Hardware
Complete Client Computer Lowest to
Highest Level Software Used
Entire computers should be designed to help satisfy the Security Concept, especially the measure of execution time. The computer
designs should be managed and accounted for when issued to clients.
Tamper identifiers should be used on the hardware and software designs should safeguard against relinquishing any design information.
The machine designs should be checked for tampering regularly and new machine versions should be released periodically. Masking Class #2 and
Abstract Class #3 should have a secure database of ever-growing versions. Versions of Masking Class #2 and Abstract Class #3 and custom machines
should have a design cohesion to further ensure an accurate measure of execution time and secure communications. Hardware and software component
should be designed for measuring execution and maintaining security with efficient, staggering, or hindering design schemes.
Abstract Class #3 should have a similar protocol arrangements consisting of efficient, staggered, hindering code for security and
measuring execution. Abstract Class #3 should have pointless executions and masked security protocols. Such security protocols
would be manipulating various authenticating information within the schemes and repeatedly sending it to the server.
There are three methods of implementing custom client machines. Distributing one version to all clients. The server will be updated once and can
assume the client design for each authentication attempt. Secondly, distributing a mixture of versions to the clients. The server will
need to receive the design version upon each authentication attempt. Lastly a mixture of the prementioned. In any case, all updating of
server code dealing with custom machine designs, security designs, or any part of the programs should be done from a SECURE LAN.
Program #4: Abstract Class #3 will download Program #4. Program #4 will be a GUI connecting the client to the server controls. The Security Concept
should be used randomly and often to update core components of Program #4. The Security Concept should be used to verify every client's
communication to the server. After each communication the server receives, the client will be sent an acknowledgment and must
respond or measures will be taken. The acknowledgment should be time sensitive. Along with the user activated acknowledgment, random GUI
components should be changed to visual notify the client of a communication, even if the acknowledgment is never seen. The server
should keep track of every client's actions since Masking Class #2 and be able to undo as much as possible if needed.
It is worth noting the extended methods of dealing with privately designed computers will not be discussed but I am aware of their security challenges.
The reflecting server side code for this proposal is self explanatory. However, design of the entire server side LAN should be designed with the Security
Concept in mind. I would appreciate any suggestions on all security challenges.
Moderator Action: email address removed.
Message was edited by: 2a614dc0-adcc-402b-b338-8adfe88b1e6e
Message was edited by: 2a614dc0-adcc-402b-b338-8adfe88b1e6e
Message was edited by: rukbat Publicly viewable email addresses are harvested by spammers and identity thieves. You were advised to toggle public/private in your user profile (for example, in your biography section). That is the only appropriate place for such information. You chose to ignore that and you reinserted the email address. That is why this thread is now locked. Additionally, private communication outside the forums are actively discouraged. Such communications deprive everyone else the chance to learn on a topic. These are public user-to-user forums. Keep them that way.
Please edit your post and remove your email address. If you wish to make your email address public provide it in your forum profile.
You haven't posted the more important information that anyone needs to know to try to help you: what PROBLEM are you trying to solve.
It is rather pointless to even try to comment on anything you posted since it isn't known what problem, if any, you are even trying to address.
I have read this through 2.5 times (I got bored half way through the third read) and it seems to be either trying to solve a non-problem or, if it is a real problem, making simplistic assumptions about the technology being used by the client. It seems to erroneously assume that a program running on the client in non-privileged mode can determine what other programs, possibly privileged, are doing! Also, the statement "Please consider this proposal from a closed design scenario" is ridiculous since even if a reader understands the design ( I don't ) and finds a security flaw he can't suggest a design change to overcome that flaw!
A ridiculous thread.
> Please feel free to correct, suggest, or dispute any part of my proposal.
It won't work.
The the truth about code running on a client machine is that there is absolutely no way to insure that it is not susceptible to modification. Thus there are ONLY two solutions.
1. Architect\Design a system such that it doesn't matter if someone messes with it.
2. Don't run the code on the client machine, run it on a server.
Your design is making the assumption that you can in fact stop this and that it is simple to do so. The first is wrong and the ways that that a system can be attacked are varied and complex.
So best use of your time is to drop the design and very idea and instead go back to 1 and 2 above to make a system that is secure.
Edit : I have removed my comments on the OP's last post. I re-read the original post and decided I still do not understand what the OP is proposing but my experience suggests that it is nothing more than 'snake oil'. I doubt if any members of this forum are security experts so the 'peers' reviewing this are probably not security experts and before any real money is invested in this probable 'snake oil' I suggest a real security expert be consulted.
Message was edited by: sabre150