Digital Signature

2. Digital Signatures
Each individual generates his own key pair
[Public key known to everyone & Private key only to the owner]
Private Key – Used for making digital signature
Public Key – Used to verify the digital signature

3.  Digital Signature is Hash value of a message when encrypted with the
private key of a person is his digital signature on that e-Document Digital
Signature of a person therefore varies from document to document thus
ensuring authenticity of each word of that document. As the public key of
the signer is known, anybody can verify the message and the digital
signature
 Digital Signatures Each individual generates his own key pair [Public key
known to everyone & Private key only to the owner ] Private Key – Used
for making digital signature Public Key – Used to verify the digital
signature

4.  In the electronic environment basic legal functions of a signature are
performed by way of a method that identifies the originator of a data
message and confirms that the originator approved the content of data
message. This method uses the techniques of cryptography and encryption.
 Public key cryptography is an asymmetric scheme that uses a pair of pair
of keys for encryption. A public key, which encrypts data and a
corresponding private and secret key for decryption.

5.  Digital signatures are based on mathematical algorithm. These require the
signature holder to have two keys (one private and the public) for signing
and verification. A verifiable trustworthy entity called certification
authority creates and distributes signature. A digital signature is a
cryptographic means through which many of these may be verified. The
digital signature of a document is a piece of information based on both the
document and the sign is a private key. It is typically created through the
use of a hash function.
 If you are sending a sensitive document, you would want the recipient of
the document to know that it was from you and you would also want to
ensure that the document gets to the recipient in the very same state you
sent it in, without any alterations. The process of digitally signing your
document would go something like this:

6. Why Digital Signatures?
•To provide Authenticity, Integrity and Non-repudiation
to electronic documents
•To use the Internet as the safe and secure medium for e-
Commerce and e-Governance

8.  Digitally signed messages may be anything represent able as a bit string:
examples include electronic mail, contracts, or a message sent via some
other cryptographic protocol. A digital signature scheme typically consists
of three algorithms
 A key generation algorithm that selects a private key uniformly at random
from a set of possible private keys. The algorithm outputs the private key
and a corresponding public key.
 A signing algorithm that, given a message and a private key, produces a
signature.
 A signature verifying algorithm that, given a message, public key and a
signature, either accepts or rejects the messages claim to authenticity.• Two
main properties are required. First, a signature generated from a fixed
message and fixed private key should verify the authenticity of that
message by using the corresponding public key. Secondly, it should be
computationally infeasible to generate a valid signature for a party who
does not possess the private key.

9.  The following are the main benefits of using digital signatures:
 Speed: Businesses no longer have to wait for paper documents to be sent
by courier. Contracts are easily written, completed, and signed by all
concerned parties in a little amount of time no matter how far the parties
are geographically.
 Costs: Using postal or courier services for paper documents is much more
expensive compared to using digital signatures on electronic documents.
 Security: The use of digital signatures and electronic documents reduces
risks of documents being intercepted, read, destroyed, or altered while in
transit.

10.  Key Generation
 Random Numbers
 RSA Key Pair [Private/Public Key]
 Digital Signature
 Generate Message Digest [SHA1]
 Encrypting Digest using Private
Key [Signatures]
 Attaching the Signatures to the
message.
 Verification of Signatures
 Run the test for Authentication,
Integrity and Non repudiation.
 Digital Signature Certificate
 ITU X.509 v3

11. Signed
by using
CA’s
private
key
User
Name &
other
credentials
User’s
Public
key
User Certificate
Certificate
Database
Publish
Certificate
Request
User Name
User’s
Public Key
CA’s Name
Validity
Digital
Signature
of CA
Certificate
Class
User’s Email
Address
Serial No.
Key pair
Generation
Private
Public
Web site of CA
User 1 certificate
User 2 certificate
.
Public
License issued
by CCA

12.  The Private key generated is
to be protected and kept
secret. The responsibility of
the secrecy of the key lies
with the owner.
 The key is secured using
 PIN Protected soft token
 Smart Cards
 Hardware Tokens

13. Paper signatures v/s Digital Signatures
Parameter Paper Electronic
Authenticity May be forged Can not be copied
Integrity Signature
independent of
the document
Signature
depends on the
contents of the
document
Non-repudiation a. Handwriting
expert
needed
b. Error prone
a. Any
computer
user
b. Error free
V/s

14. Signed Messages
Message
+
Signature
Hash
Decrypt
Signature
With Sender’s
Public Key
SIGN hash
With Sender’s
Private key
Message
+
signature
COMPARE
Calculated
HashMessage
Sender Receiver
Hash
Sent thru’ Internet
if
OK
Signatures
verified

15.  Unit Testing
 Unit testing focuses efforts on the smallest unit of software design.
This is known as module testing. The modules are tested separately.
The test is carried out during programming stage itself. In this step,
each module is found to be working satisfactory as regards to the
expected output from the module.
 Integration Testing
 Data can be lost across an interface. One module can have an
adverse effect on another, sub functions, when combined, may not
be linked in desired manner in major functions. Integration testing
is a systematic approach for constructing the program structure,
while at the same time conducting test to uncover errors associated
within the interface. The objective is to take unit tested modules and
builds program structure. All the modules are combined and tested
as a whole.

16.  Validation Testing
 At the culmination of the integration testing, Software is completely
assembled as a package. Interfacing errors have been uncovered and
corrected and a final series of software test begin in validation testing.
Validation testing can be defined in many ways, but a simple definition is
that the validation succeeds when the software functions in a manner that
is expected by the customer. After validation test has been conducted, one
of the three possible conditions exists.
 The function or performance characteristics confirm to specification and
are accepted.
 A deviation from specification is uncovered and a deficiency lists is
created.
 Proposed system under consideration has been tested by using validation
test and found to be working

17.  Output Testing
 After performing the validation testing, the next step is output testing of
the proposed system, since no system could be useful if it does not produce
the required output in a specific format. The output format on the screen is
found to be correct. The format was designed in the system design time
according to the user needs. For the hard copy also; the output comes as
per the specified requirements by the user. Hence output testing did not
result in any correction for the system.
 User Acceptance Testing
 User acceptance of a system is the key factor for the success of any
system. The system under consideration is tested for the user acceptance
by constantly keeping in touch with the prospective system users at the
time of developing and making changes whenever required.
 This is done in regard to the following point:
 Input Screen Design
 Output Screen Design
 Format of reports and other outputs.

18.  Risk Identification: We analyzed that there were several types of risks
involved with our project like:
 Hardware Constraint Risks like the CPU is over burdened with
calculations and the system might hang.
 Data Loss Risk due to hardware malfunction or failure to save the changes
applied in the existing code.
 Development Environment Risks due to 1 members in the group, since the
modules are different, at the time of integration, more amount of time is
spent than the main module itself.

19.  Risks Quantification: The impact of the different risks mentioned above
was assessed as follows
 Environment Risks: Medium probability and High Impact. Thus it can be
seen as a medium risk.
 Hardware Constraint Risks: Very low probability and High Impact. Thus it
can be seen as a low risk.
 Deliverability Risks: Very High probability and Medium Impact. Thus it
can be seen as a high risk
 Data Loss Risks: Medium Probability and Very high impact. High Risk
 Development Environment Risks: Low Medium Probability and Medium
Impact. Thus it can be seen as a medium risk.

20.  Risk Response: There are basically four things which can be done about a
risk. It can be avoided, transferred, mitigated or accepted.
 Hardware Constraint Risks: It has a very low chance of occurring but if
encountered, can be avoided by CPU of good processing speed as well as
sufficient free disk space at the beginning when the simulation is started.
 Deliverability Risks: It has a good chance of happening and can be
mitigated
 Data Loss Risks : Has an average chance of occurring and can be
mitigated by pushing my code on the cloud from time to time
 Development Environment Risks: Nothing can be done to mitigate such
risks. They just need to be accepted.

21.  Risk Monitoring and Control
 Environment Risks: It can be controlled by properly initializing the light
variables carefully.
 Hardware Constraint Risks: It can be monitored by making sure of the
quality of the hardware and its performance stats.
 Development Environment Risks: It can be controlled by continuing with
the project and completing it as much as possible.

22.  Integrating Windows 7, Visual Studio 2010 and the toolkits over the top of
building our own class files, we encountered a good number of exceptions
which we made sure would never again occur by building an accurate and
time improvised property sheet for our project.
 We had to resolve several errors while making our own classes and
integrating them with the main program like external resolved linker error,
unidentified variable identifier, unhandled exception in importing libraries
and redefined functions.

23.  Debugging is a methodical process of finding and reducing the
number of bugs, or defects, in a computer program or a piece of
electronic hardware, thus making it behave as expected.
 Debugging tends to be harder when various subsystems are tightly
coupled, as changes in one may cause bugs to emerge in another.
 As the project is still in its development stage, debugging done was
alongside code writing. Most of the times due to a silly mistake
which resulted into a fatal error, the program often crashed when
tried to access some attributes of an object that were not initialized.
 When the models were being tested, a comparison had to be
formulated. This comparison was very difficult to narrow down
since the input parameters for each model are different.

24.  This system is provided with authentication without which no user can
pass. So only the legitimate users are allowed to use the application. If the
legitimate users share the authentication information then the system is
open to outsiders.

25.  Use Case Diagram
 Control Flow Diagram
 Activity Diagram

29.  Login
 Generate
 Add New User
 Converter
 Add New User
 Signing

35.  Small encryption exponent
 Small encryption exponent and small message
 Using the same key for encryption and signing
 Using a common modulus for different users
 Acting as an oracle

36.  Minimize the risk of dealing with imposter. Minimize the risk of
undetected message tampering and forgery. Retains a higher degree
of information security. Don't use the same RSA key for encryption
and signing. Always format your input before encrypting or signing.
When decrypting, check the format of the decrypted block. If it is
not as expected, return an error message, not the decrypted string.
Similarly, when verifying a signature, if there is any error
whatsoever, just respond with "Invalid Signature".

37. 0 5 10 15 20 25 30 35
RESEARCH
IDEA AND CONCEPT
STRUCTURE
INTERFACE DESIGN
BUILD WEBSITE
TESTING
NO.OF DAYS TO COMPLETE
START DATE