| Subject | Re: [IB-Architect] IB licensing methods |
|---|---|
| Author | Jan Mikkelsen |
| Post date | 2000-04-12T08:30:53Z |
Ann Harrison <harrison@...> wrote:
product is trivially defeated. I suspect it would also be a waste of
developer time.
So, a protocol needs to be implemented which involves some code for which
the end user doesn't have the source code, and so can't easily rebuild the
executable.
A possible approach might be to use RSA. The client software has the
private key embedded, the server uses the public key as part of the license.
Licenses can be identified using a unique identifier (for example, an X.500
distinguished name).
When a client which requires a license connects to a server, it specifies a
(large) random number, along with a license identifier. The server encrypts
the random number using the public key value for the license, and sends this
to the client. The client can verify that the server knew the public key
value by decrypting the server provided value using the private key.
The server could attempt to enforce connection limits based on restrictions
associated with the license, but if we assume the entire server is open
source, it is trivially defeated. It might still be enough for some
applications.
The main feature of this approach is that assuming that the client
executable is not modified, the server must have some knowledge before the
client will proceed. Of course, changing the client isn't that difficult,
but it is harder than typing 'make'.
This scheme could also be implemented using a challenge/response UDF,
avoiding engine changes. Although you loose any pretence at connection
limits.
Jan Mikkelsen
janm@...
>As many of you are aware, some applications builtAny software based attempt to restrict usage in (only) an open source
>on Interbase rely on Interbase's licensing to control
>their own access. Needless to say, Interbase V6
>will have no licensing, leaving the developers of
>those applications in the lurch.
>
>I bring this problem to your attention, hoping
>to find a solution that is consistent with our
>open source license, open source philosophy, and
>a certain desire to provide real protection
>rather than obfuscation.
product is trivially defeated. I suspect it would also be a waste of
developer time.
So, a protocol needs to be implemented which involves some code for which
the end user doesn't have the source code, and so can't easily rebuild the
executable.
A possible approach might be to use RSA. The client software has the
private key embedded, the server uses the public key as part of the license.
Licenses can be identified using a unique identifier (for example, an X.500
distinguished name).
When a client which requires a license connects to a server, it specifies a
(large) random number, along with a license identifier. The server encrypts
the random number using the public key value for the license, and sends this
to the client. The client can verify that the server knew the public key
value by decrypting the server provided value using the private key.
The server could attempt to enforce connection limits based on restrictions
associated with the license, but if we assume the entire server is open
source, it is trivially defeated. It might still be enough for some
applications.
The main feature of this approach is that assuming that the client
executable is not modified, the server must have some knowledge before the
client will proceed. Of course, changing the client isn't that difficult,
but it is harder than typing 'make'.
This scheme could also be implemented using a challenge/response UDF,
avoiding engine changes. Although you loose any pretence at connection
limits.
Jan Mikkelsen
janm@...