WO2014064451A1 - Système et procédé d'authentification de communications - Google Patents

Système et procédé d'authentification de communications Download PDF

Info

Publication number
WO2014064451A1
WO2014064451A1 PCT/GB2013/052779 GB2013052779W WO2014064451A1 WO 2014064451 A1 WO2014064451 A1 WO 2014064451A1 GB 2013052779 W GB2013052779 W GB 2013052779W WO 2014064451 A1 WO2014064451 A1 WO 2014064451A1
Authority
WO
WIPO (PCT)
Prior art keywords
rules
message
gotcha
image
digital
Prior art date
Application number
PCT/GB2013/052779
Other languages
English (en)
Inventor
Christopher Douglas Blair
Original Assignee
Christopher Douglas Blair
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB1219235.7A external-priority patent/GB2507315A/en
Application filed by Christopher Douglas Blair filed Critical Christopher Douglas Blair
Publication of WO2014064451A1 publication Critical patent/WO2014064451A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1483—Countermeasures against malicious traffic service impersonation, e.g. phishing, pharming or web spoofing

Definitions

  • the invention relates to a system and method whereby the source of a communication can be verified as the trusted sender it purports to be from or, conversely, identified as being from an imposter. Unlike standard encryption and digital signature schemes, this invention allows the human recipient readily to identify fraudulent messages by recognizing whether or not the digital token associated with the message complies with one or more pre-determined rules.
  • Email, text messaging and other forms of communication are incredibly useful, they are also susceptible to a form of fraud known as "phishing".
  • This entails sending messages that appear to be sent by a trusted source (such as one's bank) but are actually sent by criminals and which typically instruct the recipient to divulge their security credentials thereby gaining access to their account.
  • phishing a form of fraud known as "phishing”.
  • This entails sending messages that appear to be sent by a trusted source (such as one's bank) but are actually sent by criminals and which typically instruct the recipient to divulge their security credentials thereby gaining access to their account.
  • the problem is so widespread that it makes E-mail, in particular, almost unusable by genuine businesses - which are then forced to communicate with their customers through other, more cumbersome channels - such as when the customer logs in to their online account.
  • a separate but related problem is how to distinguish humans from computers - for example, in detecting and blocking automated attacks on websites.
  • a common approach uses CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") images. These contain text that is (just about) readable by a human but made deliberately difficult for a computer to interpret.
  • GOTCHAs is embedded within or linked to each message sent from an authorised originator to the intended recipient.
  • Each GOTCHA serves to authenticate the message as genuine by conforming to at least one rule known to the sending application and to the human recipient and/or an optional associated program (known as a "GOTCHA client") running on or accessible from the recipient's computer, mobile phone or other processing device.
  • GOTCHA client an optional associated program
  • Each valid GOTCHA is generated in accordance with at least one rule and can be confirmed to comply with said rule(s) by the human recipient and/or the GOTCHA client.
  • GOTCHAs differ from existing "comfort messages" or pre-selected images in as much as they are normally dynamic rather than fixed. Thus, intercepting a message containing a GOTCHA and repeating that same GOTCHA in a subsequent message will be unlikely to fool the recipient.
  • a method for authenticating a message by associating one or more digital tokens with said message wherein tokens are constructed according to a set of at least two rules known to the creator of said tokens to confirm the authenticity of said message and where compliance with at least one of the rules is readily recognisable by the intended human recipient even when the token is rendered without knowledge of or reference to said rules.
  • the rules may be agreed or negotiated with the recipient.
  • At least one digital token may consist of an ordered set of characters. At least one digital token may include at least one of a graphical image, an audio signal, a moving image, one or more movements or haptic gestures. At least one of the digital tokens may represent one or more odours. At least one of said digital tokens may describe and/or provide means of responding to one or more user interactions.
  • the rules may include spatial and/or temporal location of at least one digital token within said message.
  • the rules may include any of the order, number, sequence of characters, case of characters, presence or absence of whitespace or punctuation characters or relationships between characters.
  • the rules may relate to any of: the presence of, absence of, length of or order of valid words, anagrams, interleaved words, specific words or categories of words within said character sequence.
  • the rules may relate to the size, shape, resolution, aspect ratio, colour, pattern, texture, border, translucency of said image.
  • the rules may relate to any of: the presence of, absence of, number of, orientation of, size of, colour of, resolution of or sequence of specific or generic sub-image or sub-images.
  • the rules may relate to the representation of text within said image. For example, the rules may relate to the characters within, the words within, the position of, the colour of, the orientation of, the font of, the style of or the size of said text within said image.
  • the image may contain one or more obfuscated digital tokens.
  • the obfuscated digital token may take the form of a secondary image.
  • the obfuscated image may be described in the least significant bits of the colour values of some or all pixels.
  • the obfuscated image may be hidden by shifting concentric squares of pixels about an origin by pre-determined numbers of pixels.
  • the rules may relate to any of: the letters spoken, the words spoken, the background noise or noises, the way in which utterances are made, the order in which utterances are made; the speaker's gender, age or accent, the tune or notes playing; the relationship between utterances or other prosodic attributes.
  • the rules may relate to any of: the absolute, relative or sequential motion of objects, the presence, absence or concurrence of elements within the moving image or the relationship between audio and visual events.
  • the rules may relate an attribute of one type of said digital token to an attribute of a different type of digital token.
  • the rules may define a relationship between a sound and an action in a moving image.
  • the rules may relate to a sequence of actions and/or consequences of said actions.
  • At least one digital token may incorporate a number or representation of a number that changes from one message to the next.
  • the number or representation of a number may indicate the sequence number of said message within a specified set of messages.
  • the set of messages may be all messages sent across all authorized senders to said recipient.
  • the set of messages may be all messages sent from a specific sender to said recipient.
  • the digital tokens may be constructed in parts and combined together to form the overall digital token. Each part may be constructed by a system having knowledge of only a subset of the overall set of the rules known to the recipient.
  • the rules outside said proper subset of rules checked for by the recipient may be consistently applied to all such digital tokens. Some of the rules outside said proper subset of rules checked for by the recipient may be changed from the generation of one digital token to the next.
  • Digital tokens within successive messages may be combined to build a larger digital token.
  • the digital tokens may combine in the form of a jigsaw.
  • the larger digital token may be any of: a story, puzzle or trivia fact, a series of cartoon frames, a larger image, a voucher or token, a bar-code or Quick Response Code.
  • Automated checks may be made of one or more aspects of the said digital tokens.
  • the automated checks may include confirmation of precise alignment of transparent areas between abutting images. Representation of a number may be superimposed over an image. The image may be associated with the sender of said message.
  • the digital token may incorporate some element of the previous message sent from the same originator.
  • the element may be partially obfuscated.
  • the method may involve asking the recipient to distinguish between valid and invalid tokens generated according to a putative set of rules prior to the fixing of said rules.
  • At least one of the rules outside said proper subset of rules checked for by the recipient may be subsequently explicitly revealed to said recipient.
  • the image may be divided into a plurality of substantially constant areas such that in successive messages each such area is populated by a specific application.
  • One of the areas may be always populated according to the same set of rules, regardless of the originator of the message.
  • One of the areas may be populated according to a set of rules that is specific to the originator of the message.
  • the boundary between the areas may vary from one message to the next whilst retaining the general shape and size of each area.
  • the boundary between the areas may be determined by one or other of the parties responsible for populating said areas and communicated to the other party or parties. The precise alignment and/or overlap of transparent areas may be checked automatically.
  • Digital tokens sent in successive messages may be deliberately different from each other in at least a predetermined number of respects.
  • the digital tokens may conform to industry standard file formats.
  • file format may be at least one of: PNG, GIF, JPG, MPG, WAV, MP3, CSV, PDF file formats.
  • the digital tokens may be in a dedicated file format.
  • the dedicated file format may be associated with and hence trigger an associated application or program for rendering and analysing the digital token.
  • a method for authenticating a message by associating at least one digital token with the message, at least one of the digital tokens including at least one graphical image, wherein the at least one digital token is created according to a set of at least two rules known to the creator and the intended human recipient of the token to confirm the authenticity of the message and where compliance with the rules is readily recognisable by the intended human recipient.
  • the rules may relate to the look and/or feel of any aspect of the graphical image, for example a colour and/or shape of whole or part of the image and/or a background effect and/or an image of a specified article or indeed any aspect of the visual appearance.
  • a method for authenticating a message by associating at least one digital token with the message, wherein the at least one digital token is created according to a set of at least two rules known to the creator and the intended human recipient of the token to confirm the authenticity of the message, and at least one rule unknown to or unused by the intended human recipient, wherein compliance with the recipient rules is readily recognisable by the intended human recipient.
  • At least one of the digital tokens has a graphical image and/or a set of characters and/or an audio signal and/or a moving image and/or is representative of one or more movements or haptic gestures and/or one or more odours.
  • At least one of the digital tokens describes and/or provides means of responding to one or more user interactions.
  • the rules may include the spatial and/or temporal location of the said digital tokens within said message.
  • the rules may relate to at least one of the size, shape, resolution, aspect ratio, colour, pattern, texture, border, translucency of said image; presence of, absence of, number of, orientation of, size of, colour of, resolution of or sequence of specific or generic sub-image or sub-images, representation of text within said image, wherein for text the rules relate to the characters within, the words within, the position of, the colour of, the orientation of, the font of, the style of or the size of said text within said image.
  • At least one of the digital tokens may be partially or fully obfuscated.
  • the at least one digital token may comprise: a plurality of characters
  • the rules include at least one of: the order, number, sequence of characters, case of characters, presence or absence of whitespace or punctuation characters or relationships between characters, the presence of, absence of, length of or order of valid words, anagrams, interleaved words, specific words or categories of words within said character sequence, and/or an audio signal
  • the rules relate to at least one of: letters spoken, words spoken, background noise or noises, a way in which utterances are made, an order in which utterances are made, a gender of the speaker, age or accent, a tune or notes playing, a relationship between utterances or other prosodic attributes, and/or a moving image
  • the rules relate to at least one of: the absolute, relative or sequential motion of objects, the presence, absence or concurrence of elements within the moving image or the relationship between audio and visual events.
  • the rules may relate an attribute of one type of digital token to an attribute of a different type of digital token.
  • At least one digital token may incorporate a number or representation of a number that changes from one message to the next, for example the number or representation of a number indicates a sequence number of the message within a set of messages sent from all authorised senders or from a subset of authorised senders or from a specific sender.
  • Digital tokens within successive messages are combined to build a larger digital token, for example the larger digital token being any of: a jigsaw, a story, puzzle or trivia fact, a series of cartoon frames, a larger image, a voucher or token, a bar-code or Quick Response Code.
  • the digital token may incorporate an element of the previous message sent from the same originator.
  • the graphical image may be divided into a plurality of substantially constant areas such that in successive messages each such area is populated by a specific application, wherein at least one of the areas is always populated according to the same set of rules, regardless of the originator of the message and/or a set of rules that is specific to the originator of the message and/or the precise boundary between said areas varies from one message to the next whilst retaining the general shape and size of each area.
  • Digital tokens sent in successive messages may be different from each other.
  • a method for authenticating a message by associating at least one digital token with the message, wherein the at least one digital token is created according to a set of at least two rules known to the creator and the intended human recipient of the token to confirm the authenticity of the message, wherein at least one digital token incorporates a number or representation of a number that changes from one message to the next, wherein compliance with the recipient rules is readily recognisable by the intended human recipient.
  • the number or representation of the number indicates a sequence number of the message within a set of messages sent from all authorised senders or from a subset of authorised senders or from a specific sender.
  • a system for authenticating a message by associating at least one digital token with the message wherein the system is configured to create at least one digital token according to a set of at least two rules known to the creator and the intended human recipient of the token to confirm the authenticity of the message, wherein at least one digital token incorporates a number or representation of a number that changes from one message to the next, wherein compliance with the recipient rules is readily recognisable by the intended human recipient.
  • the number or representation of the number indicates a sequence number of the message within a set of messages sent from all authorised senders or from a subset of authorised senders or from a specific sender.
  • a method for selecting rules for generating a digital token that can be used to authenticate a message the method involving presenting a plurality of rules for creating a digital token to a user; receiving a user selection of two or more rules; generating valid digital tokens according to the selected rules and generating invalid digital tokens; presenting the valid and invalid tokens to the user; determining user recognition of the valid digital token.
  • the rule selection process may be repeated to try to improve user recognition.
  • the method is computer processor implemented, and the rules are presented on a display.
  • a system for selecting rules for generating a digital token that can be used to authenticate a message the system being configured to: present a plurality of rules for creating a digital token to a user; receive a user selection of two or more rules; generate valid digital tokens according to the selected rules and generating invalid digital tokens; present the valid and invalid tokens to the user; determine user recognition of the valid digital token.
  • the system is arranged to repeat the rule selection process to improve user recognition.
  • the system is computer processor implemented.
  • Figure 1 - shows a relatively simple GOTCHA presented within an email message.
  • Figure 2 - shows a typical signup process during which the rule or rules to be applied to the GOTCHAs are determined.
  • Figure 3 - shows a possible topology for the deployment of a sophisticated GOTCHA system in which part of the GOTCHA is generated by the sender of the message and part by a dedicated GOTCHA Administrator system.
  • the invention provides various methods and systems for authenticating messages between a sender and an intended recipient using a digital token.
  • the methods are computer processor implemented.
  • the digital tokens are generated and added to an electronic message for sending to a recipient electronically, for example an e-mail or SMS.
  • Any suitable computer processor based system and any suitable computer language may be used in practice.
  • each digital token is stored in a computer memory, for example in a database, usually in association with the message sent.
  • a GOTCHA consists of one or more data items, the rendering of which may, optionally, be ordered in time and/or space. The nature of the items is limited only by the transmission characteristics of the communication channel and the devices through which the message is being viewed, played or watched.
  • SMS Short Message Service
  • text messages can only support character-based GOTCHAs and, due to the severe constraints on message size, these are typically only a few words longs.
  • an audio GOTCHA can be used. This could be spoken characters (for example "A”,”F”,”T”); a few words (“A FT", "FATHOM”) , individual musical notes of specific pitch duration and interval; specific noises (a dentist's drill or an Ivory Billed Woodpecker's call) or a snippet of a song.
  • GOTCHAs can be much more sophisticated and include text, still or moving images, audio etc.
  • Figure 1 shows a relatively simple GOTCHA (1 ) presented as an image within an email message (2) such as might be received from one's bank.
  • Devices with haptic interfaces - such as mobile phones that can vibrate, Braille displays etc. - can also use specific movements, combinations of movements and sequences of such actions as a GOTCHA.
  • odour generators could release a specific smell or combination and/or sequence of smells as a GOTCHA.
  • the GOTCHAs described above can be interpreted by a human recipient reading, seeing and/or hearing them so long as that person knows the rule or rules that the GOTCHA should obey - and are therefore "Manual GOTCHAs". Although all forms of digital information must be processed into visual, audio, olfactory or haptic content, the rendering mechanism does not need to be aware of the rule in order to do so. It is the human that knows and can apply the rule to the rendered image, sound, feeling or smell.
  • Hybrid GOTCHAs are those in which the GOTCHA must first be processed by a computer algorithm that is aware of at least a part of the overall rule. For example, the least significant bit of the red colour value in each pixel may form a black and white image.
  • the rendering software has to know the watermarking technique being used in order to render that black and white image but only the human who then views that image needs to know how to tell a valid image from an invalid one.
  • Most practical GOTCHAs are made more secure and hence effective by being "Compound GOTCHAs”. These comply with more than one rule, each of which may be a manual, automated or hybrid type as described above. In all of these cases, the richness of the communication medium can be used to the full in defining the range of possible rules. It is not just what a GOTCHA contains but how the information is presented that matters.
  • a manual audio GOTCHA consisting of the two words "cat” and "drainpipe” spoken over a telephone line as part of a greeting may be recognized as valid if, and only if, the first word is spoken by a female and the second word by a male. In this case the actual words are irrelevant.
  • a text GOTCHA consisting of one or two words may have to conform to a rule such as: the third letter is always "F"; the second word is always a nonsense word; the first word always has a punctuation character inserted into it; the letters "C", "A” and "T” will always be present somewhere; there will always be a single uppercase letter in the middle of a word; the first word will always be mis-spelled; the second word will always be an anagram of "fishes”; the second word will always be two letters longer than the first; the first and last letters will always be adjacent in the alphabet; two words will be interleaved such that odd numbered characters form one word and even numbered characters form a second valid word - and so forth.
  • these rules can also be used where the GOTCHA is
  • Text-based GOTCHAs in addition to the above rules based on the characters shown, can be enhanced using all the tricks employed in a CAPTCHA. This not only makes it harder for a computer to determine what the text within them is, it also allows graphical rules to be used in combination with text rules.
  • an image GOTCHA may be required to comply with any of the following rules: a banana somewhere in the picture; an orange corner; a stripy background; a purple "T” present; an upside down “F” present; whatever is in the bottom right corner is upside-down; something yellow in the centre - and so forth.
  • How each character and/or word is presented can be significant and can include: which font is used; superscript or subscript; size; orientation; bold, italic, underlined, over-scored etc.; colour or even colour gradient (e.g. last letter always blue at the bottom changing to red at the top).
  • the overall "style" of the image in particular it's shape, size, aspect ratio, resolution, sharpness of focus, translucency and so on - also lend themselves to being used as very powerful rules. Without being told, a customer who normally receives a long thin oval GOTCHA will reject a small square GOTCHA.
  • the GOTCHA (1 ) in Figure 1 shows some basic monochrome features but it can be appreciated that a phisher would be challenged to figure out, even if he had access to this GOTCHA, whether the recipient is checking for any or all of: a dashed arc (6) in the top right; a vertically striped background (7); two words in a particular font (8); rounded corners on the inner frame (9) or a hashed outer frame (10).
  • this user is checking for an item of food in one word, a thick dashed arc that cuts off a different corner of the image each time - not to mention appropriate global (3) and bank specific (4) sequence numbers in the fonts shown with the latter (4) in italics and underlined.
  • each GOTCHA will appear to be conforming to a large number of rules, any or all of which may be significant.
  • the communication medium supports the inclusion, attachment or linkage to moving images
  • this allows for another set of rules to be applied - such as those associated with direction of movement, vibration, sequence of events, time between events and so forth. For example: there may always be something falling down the left side; always something shaking (but never the same thing twice) and so forth.
  • the GOTCHA can conform to an interaction rule - such as: if you click on the shoes they'll change colour; if you hover over the image of an animal it will make the appropriate noise; if you click on the candle first and then the person they'll blow it out and so forth.
  • an interaction rule - such as: if you click on the shoes they'll change colour; if you hover over the image of an animal it will make the appropriate noise; if you click on the candle first and then the person they'll blow it out and so forth.
  • the sender and recipient must both be aware of - and ideally agree on and confirm the understanding and application of - at least one rule with which the GOTCHA(s) will comply in messages that will be sent subsequently.
  • a process such as this can be implemented entirely automatically - such as via a web interaction or by conversing with the customer, for example on a telephone call.
  • the procedure typically requires that each party gains the trust of the other (1 1 ) by confirming details of the customer's account, the use of passwords, security questions etc. Should the authentication (12) fail, this should be noted (13) and suspicious activity investigated.
  • the GOTCHA system will typically generate a set of perhaps five or six potential rules (14).
  • these are chosen from a wide base of possible rule types, each of which typically has one or more parameters.
  • Each parameter can typically take one of many possible values - thus giving a very large number of distinct rules.
  • the nature of the rules varies widely. These might include, for example, one spelling or word-based rule; one musical rule; one image rule and one interaction rule.
  • the user can either select the required number of rules (which may be just one rule, at least on initial sign-up). Alternatively the user can ask for a fresh set of possible rules to be generated.
  • the system may optionally (18) choose a complementary set of rules which it will apply in addition to the one(s) agreed with the customer. For example, if the customer selects "A scalloped red border", the system may add "a wood textured background", "two words beginning with the same letter” and "a banana in any corner". Although these rules may not even explained to the customer, they will rapidly become part of what the customer expects to see.
  • the system then generates and displays several exemplary GOTCHAs following the customer selected and automatically added rules. Some of these follow the rules while others do not.
  • the customer is instructed (20) to indicate which ones follow the rules - for example by clicking a checkbox next to the valid ones.
  • the system can determine whether the user is able to distinguish valid from invalid GOTCHAs based on the rule they have selected (and the others added for them).
  • the user may be given the choice of changing the rule(s) should they have found them too difficult to interpret.
  • the rules are stored (24) as part of that user's profile (26) and can be used to generate GOTCHAs as required the next time the customer is to be contacted.
  • hackers will attempt to crack GOTCHAs and may use key-logging, screen-grabbing or man-in-the-middle techniques to obtain readable copies of one or more GOTCHAs.
  • a number of measures can be taken to avoid the simple replication of a previous GOTCHA being considered valid - even with manual GOTCHAs.
  • a further challenge can be posed by the sender ensuring that each GOTCHA sent to a given customer not only follows the rule or rules agreed with and known to that customer, but also conforms to a plurality of other rules - any of which might, as far as a hacker is concerned, be significant to the recipient. Therefore a hacker, even when in possession of a sequence of genuine GOTCHAs may find a dozen or more rules that all of the GOTCHAs appear to follow. He cannot know for sure when or if he has correctly identified all of the rules that are significant to the recipient. The existence of multiple false trails makes it harder to identify the real rule.
  • This approach can be further refined by slowly changing the set of rules that are applied when creating valid GOTCHAs so that the intended recipient does not lose site of the rule that is actually important to them.
  • GOTCHAs can be used not only to authenticate the origin of a message but also to indicate its position in a sequence. This is particularly useful in email communications where messages are sometimes lost, deleted by accident or occasionally misidentified as "spam” or otherwise placed in a different folder.
  • a range of rules can be applied to a sequence or time series of
  • GOTCHAs that allows the user to recognise that a message in the sequence has been missed or duplicated.
  • the rule could be "There is always an 'X' in the two words presented and it is always one character earlier than in the previous message (and wraps from the end of the message back to the start of the message or vice versa when appropriate).”
  • a graphical GOTCHA could follow a rule such as "the picture of a banana moves 45 degrees clockwise each time”. Angular rules such as this work well with 90, 45 degrees or 30 degrees (corresponding to the twelve numerals on a clock face).
  • Loss of a message is easy to spot as the message following the loss breaks the sequence rule and a fake message probably has no "X" at all or repeated an earlier GOTCHA with different message body. With such a rule, repetition of a valid message is easy to spot as the messages and their GOTCHAs are identical. As users become aware that successive GOTCHAs are deliberately very different from each other, they become sensitised to repeated ones - recognising at least something about the image or the words used and becoming suspicious enough to compare it with the previous (more likely genuine one).
  • a simple such sequential rule involves the insertion of a sequence number (4) visible to and easily readable by the human recipient.
  • This can be obfuscated using CAPTCHA techniques - such as a patterned background (5) yet remain easily readable to the human recipient - even more so than a random CAPTCHA word as the reader knows roughly which number to expect and can certainly distinguish it from successive numbers.
  • GOTCHAs are generated not by each authorized message sender, as implied in the discussion thus far, but where a trusted service - such as a secure web-server with signed HTTPS credentials - is responsible for issuing GOTCHAs for one or more end users.
  • a trusted service - such as a secure web-server with signed HTTPS credentials - is responsible for issuing GOTCHAs for one or more end users.
  • Each authorized sender (41 ), (51 ), (61 ) must first authenticate itself with the GOTCHA Administration system (35) before it is given the appropriate GOTCHA, or - more securely - a link to the GOTCHA rather than the GOTCHA itself.
  • This approach provides several benefits in addition to allowing an overall serial number (3) to be maintained for each end user. Firstly, it allows the GOTCHA generator (32) to apply enhanced security to the GOTCHA. For example, an incoming request via a URL to the GOTCHA generator may only be satisfied if the link comes from a computer, smartphone or tablet (30) previously identified as belonging to the intended recipient. Access from other devices may be denied or may require some form of additional challenge. Note, however, that the latter approach may encourage phishing.
  • the rule(s) held (36) in the GOTCHA Administration system by which the GOTCHA was generated are never made visible to the party (41 ), (51 ), (61 ) that wishes to attach or embed the GOTCHA within their message. If GOTCHAs are created by each sender, then the end user must either remember many different rules or, more likely, will use the same rule over and over - making it less secure as it is known to many different senders, any of which could be compromised.
  • rule (36) storage and GOTCHA generation (32) centralised for each user, they will be encouraged to use more complex (or simply more) rules than they would if they had to remember a separate set of rules for each sender (41 ), (51 ), (61 ).
  • the GOTCHA may start to look very much like an image of a bank-note - albeit one of a personalized design.
  • a long serial number (3) in one corner (though which corner is also an implicit rule - i.e. the user will notice if it's not where it normally is) provides the overall sequence number - which the user will sub-consciously note as odd should it be far from the recently received range.
  • a secondary, per-sender serial number (4) in another (variable but again consistent and significant) corner could be shown alongside, above, below or overlaid onto a small logo or icon (5) associated with that sender. Note that overlaying the serial number on top of the logo makes it more difficult to generate a copy with a different serial number as the underlying logo image will not be perfect in the fake.
  • a useful extension to the above is a hybrid topology in which part of the GOTCHA is provided by the user-centric GOTCHA system (35) while the remainder is provided by a GOTCHA generator (44) within the (authorized) sender's system (41 ), (51 ),
  • the area of the GOTCHA is divided into two regions - one of which follows the same, user-specific rules held in the database (36) of the GOTCHA Administration system (35) while the other region conforms to rules held by a particular sender (41 ), (51 ), (61 ).
  • a family of GOTCHAs is formed that is instantly recognizable to its "owner” or intended recipient yet very different from those of other individuals.
  • a user whose long thin rectangular GOTCHAs always contain an oval area to the left of centre within which sender specific images are shown.
  • FIG. 3 shows the main elements of a GOTCHA implementation.
  • Each of the servers or applications can communicate with the others via any type of network communication: wireless, wired, packet or virtual circuits.
  • the functionality can be spread across multiple servers or consolidated into fewer physical and/or virtual servers than shown in the diagram.
  • the basic principles of operation are that a user accesses the system via one or more client devices (30).
  • a user often has access to multiple devices - for example, a SmartPhone, a tablet computer, an office computer and a laptop. Access to these services may be via native applications - such as a SmartPhone "app" or a more generic interface such an HTML browser interface.
  • native applications such as a SmartPhone "app" or a more generic interface such an HTML browser interface.
  • GOTCHA user server To make use of GOTCHAs, the user must first register with (or be registered with) a GOTCHA user server (32). This holds or has access to a database (36) containing details that allow the user to be identified and authenticated when interacting with the server.
  • the user interacts with an application that implements a signup process (34) such as that discussed earlier with reference to Figure 2. In this interaction the user agrees one or more rules that will govern the (partial) GOTCHAs that are produced by the GOTCHA User Server (32) in response to requests from authenticated GOTCHA Sender applications such as (44).
  • the dashed box in Figure 3 encloses the elements of the GOTCHA system that are typically required by an organisation that wishes to send messages containing valid GOTCHAs.
  • Each organisation will already have a database (42) of its customer details, to which must be added additional information allowing it to retain knowledge of the rules agreed with the user when they interact with this sender's GOTCHA signup application (40).
  • This also implements a procedure such as that of Figure 2 but in this case the user is agreeing the rules which will be held in the sender's database (42) and will govern the generation of the (partial) GOTCHAs to be generated by this sender (44).
  • database (42) must also store the previous or next message number and be updated each time a GOTCHA is generated. Having signed up with the overall system via the user-centric GOTCHA Signup
  • the sender can now generate GOTCHAs that will satisfy the client's expectations and hence be considered as valid.
  • the sender's communication system (46) wishes to send a message to the registered GOTCHA user, it requests a GOTCHA from its local GOTCHA Generator (44), specifying the recipient in such a way that the rules and sequence number can be extracted from the sender's database (42).
  • the GOTCHA generator application (44) requests a GOTCHA for this recipient from the GOTCHA User Server. This interaction will only succeed if the Sender's application (44) is authenticated using an appropriate SSL certificate or similar.
  • the user-centric GOTCHA generator (32) looks up the recipient's rules in its database (36) and generates a partial GOTCHA which it sends to (or sends a link to) the requesting GOTCHA Generator (44). The remainder of the GOTCHA is generated by this application (44) and the merged GOTCHA or pair of partial GOTCHAs or links to the same are provided to the requesting Customer Communications Application (46). Note that both the user-centric GOTCHA generator (32) and the sender's GOTCHA generator (44) will typically create a very complex GOTCHA that not only conforms to the required rules but also to a significant number of other rules - each of which acts as a false trail or "red herring" to any hacker that may gain access to the resultant GOTCHA. In choosing these additional rules, it is important to avoid trying to apply two or more conflicting rules - hence rules are ideally independent. For example "all corners are different shapes” and “opposite corners are the same shape” conflict and only one such "corner shape” rule can be applied.
  • the GOTCHA has to be embedded in a variable location within the message - such as in the HTML body of an email - then the whole communication can be passed from the Communications Application (46) to the GOTCHA generator (44) - allowing the GOTCHA to be merged into the body of the message at the appropriate point - which typically varies from recipient to recipient.
  • the location can simply be specified as before or after a specific tag or token within the message. The resultant message may then be forwarded to the recipient and ultimately viewed on a client device (30).
  • the recipient ultimately views the new communication from the sender (41 ) on one or more of his devices (30).
  • the message is rendered, along with its embedded, attached or linked GOTCHA.
  • the GOTCHA takes the form of a well-known file or attachment format so that it is presented to the user regardless of whether or not there is any GOTCHA specific software present on the client device (30) and without the need for any knowledge of the user's GOTCHA rules.
  • GOTCHA is inserted into an SMS text message, it is simply additional text added into the appropriate point within the message text.
  • images will typically be sent as PNG, JPG, GIF or MPG files and hence displayed as would any other image of this type.
  • an audio GOTCHA would typically be included as an MP3 or WAV file or attachment and hence will be playable without any additional, GOTCHA specific software being installed on the client device.
  • any known MIME TYPE or filetype which the receiving application understands and can render may be used (e.g.
  • GOTCHA software may examine the file automatically or on request - for example, making use of embedded chunks with PNG, WAV, MP3 or JPG files - all of which are flexible, extensible file formats and can carry additional application- defined information that is harmless to and ignored by the default renderers but can be examined and acted on by the GOTCHA software to provide automated flagging of rules that have not been followed or to manipulate the data within a GOTCHA to reveal hidden watermarks etc.
  • PNG Portable Network Graphics
  • WAV Wide-Retriet Markup Language
  • MP3 or JPG files all of which are flexible, extensible file formats and can carry additional application- defined information that is harmless to and ignored by the default renderers but can be examined and acted on by the GOTCHA software to provide automated flagging of rules that have not been followed or to manipulate the data within a GOTCHA to reveal hidden watermarks etc.
  • GOTCHA In the case of a manual GOTCHA, it is up to the recipient to infer whether or not the
  • GOTCHA is valid.
  • a helper application, applet or web service must be invoked to process the received GOTCHA. This may provide one or more modified renderings of the GOTCHA (using some or all of the rules by which it was generated) and/or report on the validity of the GOTCHA according to some or all of the rules that it should obey.
  • a simpler system in which the "user” and “sender” elements are conflated into a single system is also viable - but the user will not then see consistency of any GOTCHA rules across different such systems.
  • the bank-note analogy can be taken further, using complex and convoluted borders and frames around the outside of the image.
  • GOTCHA the user will learn, without being told, that some aspects are constant while others always change.
  • user A's GOTCHAs may always have three concentric frames, the centre one of which is always thin and red while the outer two change colour but always have stripes at forty-five degrees forming a chevron pattern.
  • Scalloped edges, rounded corners and other embellishments can also be used as GOTCHA rules.
  • the recipient may be only consciously applying the one explicit rule he chose from a list of widely differing rules he was offered, but is sub-consciously checking the location of the GOTCHA within the message and the monotonically increasing sequence number within the GOTCHA.
  • some of the messages sent can include, in addition to the valid GOTCHA(s) in the expected location(s), a set of other GOTCHAs, only one or some of which are valid.
  • the user is asked to click on the valid GOTCHA(s) and their selection is conveyed to the sender's servers (typically via a hypertext link associated with each image). This allows the sender to determine whether the recipient is still able to recall the rule(s) and hence identify a valid GOTCHA from an invalid one.
  • a challenge/response such as the above can take the form of a message in the (case-sensitive) form "Please reply with the number of the word that is a valid greeting from the following: 1 :Bananas 2:el_ephanT 3:eGgplant” (in this case, the rule was "second letter and only second letter in uppercase” - hence "2" is the correct response).
  • the "gamifying" concept can be taken further if the GOTCHA can be associated with an application, applet, ActiveX control or other means of running GOTCHA specific code. This can be done in a variety of ways, including but not limited to: dragging the GOTCHA image to a pre-installed application and dropping it on it; saving the
  • GOTCHA to a pre-defined folder which is being watched by a pre-installed application; preferably, for email or instant messaging channels, by identifying the GOTCHA as a new MIME-TYPE and associating it with a pre-installed application or email client add-in.
  • This client program may render the GOTCHA graphically and/or process other information within the GOTCHA.
  • a GOTCHA may be in the form of a "PNG" ("Portable Network Graphics") file. This is a widely used format for transmitting images using lossless compression.
  • the file format allows for additional, optional, content to be included within the file.
  • the embedded information may contain encrypted and/or plain text content. This content may indicate a range of attributes, including but not limited to: date and time of transmission; expiry date/time; sequence numbering; sender's signature; recipient's signature etc. These can be used by the program to determine automatically the validity of the GOTCHA and/or to influence how, where and when it is rendered.
  • PNG Planar Network
  • JPEG Joint Pictures Expert Group
  • each GOTCHA forms just one part of a larger image that builds up piece by piece as each message is received and its GOTCHA is added to the recipient's collection.
  • a fixed size composite image can be built from identically sized component images - each of which represents an image that is mostly transparent.
  • each individual GOTCHA can be smaller than the overall image but contain within it (or in associated metadata) a definition of the offset (and optionally, rotation or other transformation) to be applied to it. As each piece has the appropriate transformation, it fills in a piece of the overall image like a single jigsaw puzzle piece contributing to an overall picture.
  • each GOTCHA may add a new section to a game, extending the space within which the game can be played or by adding a new "level” after so many messages. This brings us to an example of a hybrid-GOTCHA.
  • GOTCHA is actually cut from a larger picture - with the rest of its pixels being transparent - then it is even easier for a human to spot that a fake jigsaw puzzle piece does not match. Not only will the composite picture not make sense - with the new piece obviously not contributing properly to the overall picture, it won't actually abut tightly to the existing pieces. While a human will spot gross errors in the fit of such jigsaw puzzle pieces, the application will be able to spot even a single pixel overlap or gap that should not be present on the boundary between neighbouring GOTCHAs.
  • the jigsaw may be never-ending - with new pieces extending it ever downwards (the top rolling off or only visible via a scroll-bar). This works well for vouchers or tokens. These provide another reason to pay attention to the GOTCHAs - as they can build into something worthwhile. This may be an ongoing cartoon strip, a story or money-off vouchers. The latter could include barcodes or Quick Response Codes (QRCs) that are only complete and hence valid once several GOTCHA puzzle pieces have been assembled. These are particularly useful where GOTCHAs are part of a interaction undertaken on a mobile phone or tablet as they are compact enough to show on screen yet can be scanned at point of sale outlets to redeem the voucher.
  • QRCs Quick Response Codes
  • this approach can also serve to encourage actions on the part of the user that will lead to more messages and hence GOTCHAs being received. For example, a bank sending a message each time a credit card is used may find that users make more use of their credit card if they get hooked on the game that their GOTCHAs build into or they like the coffee vouchers they earn. Ideally, users are given a choice of the type of GOTCHA and hence rewards they accumulate.
  • a variant on the puzzle theme is to use overlapping data from one message to the next. This is particularly useful in, for example, emails advising a user of credit card transactions.
  • Such services are susceptible to phishing attempts as, although it is difficult to spoof a message showing a valid transaction, it is easy to make one up in which the user is advised of a completely fictitious payment having been made.
  • the user on receipt of such a message, assumes that their credit card has been cloned and wishes to alert the card issuer to this problem so that subsequent transactions are blocked.
  • the phisher's email merely needs to direct them to a fake site that mimics the card issuer's website and asks them to enter their card details, PIN etc. to "confirm that the card should be blocked”.
  • the above can be foiled by including at least a portion of the previous transaction within an email. If this is always done, then the recipient is immediately suspicious of an email that only contains a new, invalid transaction or attempts to show a previous transaction but that, too is made up - and does not match the one in the previous genuine notification email.
  • Sending the whole of a previous transaction is itself slightly dangerous as credit card companies often use knowledge of previous transactions to authenticate a user when talking to them on the phone. Hence sending details of more than one transaction in a single email is unnecessarily dangerous. This can be avoided by using techniques similar to those commonly used on till or ATM receipts - where only some of the card's digits are shown, i.e.
  • an email advising a user of one or more new transactions may include a copy of the last line of the previous batch of transactions, but with some of the important characters redacted or otherwise obscured or dropped.
  • this technique works with text, it can also be used on text only communications channels such as SMS - with the obscured digits sent as " * " (as used to show password entries).
  • SMS - with the obscured digits sent as " * " (as used to show password entries).
  • the obscured items can preferably be represented as the indents in a jigsaw puzzle piece. This implicitly reminds the user that these should join, seamlessly, onto the end of the previous message. This can be further reinforced by a faint outline of a similar pattern over the last transaction on each statement.
  • GOTCHAs A further approach to encouraging users to pay attention to and learn the characteristics of their GOTCHAs is to have them contain or be associated with some text (the rendering of which may or may not be related to the recipient's rule).
  • the text may provide an interesting trivia fact, a recipe or tip.
  • the pictures could build into a larger image that can be used as wallpaper and/or screen saver.
  • the recipient may already be aware of the overall image that is building up - having been shown a smaller version of it and selected the image instead of any of the typical human interpretable rules described thus far.
  • the GOTCHA builder is automatically checking the fine detail of the image pieces as they are received but the recipient is also comfortable that all is well as they can see the pieces starting to form the picture they are expecting - for example a high resolution portrait of their favourite breed of cat or the lines of their favourite song in the case of an audio GOTCHA.
  • a phisher will have had to have intercepted the initial sign-on session in which the thumbnail was chosen AND be able to predict the precise shape of each jigsaw puzzle piece to circumvent this approach.
  • the format and content of the GOTCHA may be selected from a wide range of existing file types (e.g. ".WAV”, “JPG", “.MPG”). Many of these formats allow for user extensions within which the additional GOTCHA fields can be embedded.
  • each authorised sender can create their own, unique file format, choosing from a range of potential encoding, blocking and encryption techniques such that only their own GOTCHA client can read the GOTCHAs they generate.
  • cross media GOTCHAs can be used to provide even more rigorous proof that a message is from the sender it purports to be.
  • One or more rules can be agreed that will link the GOTCHAs used on the two (or more) media.
  • the second word in the SMS GOTCHA will also appear as an anagram in the image GOTCHA contained in the email.
  • rules may be based on links between them. For example, an incongruous sound - such as a dog barking when a picture of a cat is shown - may be used as a significant rule. Similarly, lip- synchronisation, or deliberate failure thereof is also easy for the human to identify (while difficult for a computer to interpret) and thus makes a good rule.
  • rules can encompass both text and images.
  • a GOTCHA rule may state that the text within the GOTCHA will describe an object incorrectly (e.g. "Green Banana” in the text when the image shows a green apple or a yellow banana).
  • GOTCHA client application Where a received GOTCHA is displayed by a GOTCHA client application, other techniques can be adapted to provide further security layers.
  • One example of this is a digital analog of the ultra-violet lamp test. When held under an ultraviolet light, many banknotes show a (normally) hidden pattern. The same effect can be achieved by, for example, manipulating the colour map used to display a graphical image. There are many possible transformations that can be used.
  • the human recipient can be shown the hidden image using pictures that mimic the real world.
  • the hidden image may be shown over a picture of the GOTCHA being held under a hand-held ultra-violet lamp - in the same way that a human would examine the ultra-violet marks on a banknote. This helps to convey the principle of the security mechanism without the need for written instructions - and is hence more easily understood and more easily supported in all languages.
  • a further approach used in banknotes is watermarking. There are many ways in which something similar can be achieved in these images. Unless the forger knows which algorithm (of many, many possible algorithms) is going to be applied when viewing the GOTCHA he is trying to forge, it will be impossible for him to generate a convincing fake.
  • An example algorithm might be that the least significant bit of all, or a subset of pixels in the image is modified such that when combined with that of a particular neighbouring pixel in a particular way (e.g. an XOR function) and then displayed in monochrome (where 0 is black and 1 is white) a particular image is displayed - which the user will recognise.
  • the human recipient can be shown the watermark using imagery that mimics the real world.
  • the watermark image may be shown over a picture of the GOTCHA being held up to a strong light - in the same way that a human would examine the watermark of a banknote.
  • the characters could be in one or more distinctive fonts or even hand-drawn by the recipient - for example on a touch-screen or mouse-pad.
  • the location, colour and orientation of the signature are also important factors used in identifying a genuinely "signed" GOTCHA from a fake.
  • this "signature” may be deliberately obfuscated. For example, it may always appear in the bottom left corner of the "frame” of the GOTCHA image - which itself has a variety of colours and textures.
  • the "texture” of the material is also important, both in the case of bank-notes and works of art.
  • a "texture” can be overlaid onto the whole surface of a GOTCHA or, unlike the physical analogs, different textures can be applied to different elements of the image.
  • These "textures” may be visible to the human eye - giving the look of canvas, rough paper, "speckling", wood grain etc. or invisible to the human eye but discernible to the GOTCHA client via a texture recovery algorithm which can then enhance them before showing to the human. For example, it may show an image of a magnifying glass within which is visible the "magnified” irregular weave like that of a handmade paper.
  • one or more lines can be added to the image.
  • these have the effect of making it harder for an automated tool to decipher the content of the image but are readily discernible to the human recipient of an image.
  • Multiple random lines can be used to create a "crackle-glaze” effect or other recognizable style of disruption to the main image. That style, the colour, the position of the lines or the shape of one or more lines may obey a further rule that allows the recipient to distinguish a valid GOTCHA from a fake.
  • the "texture" can be the background noise or may be a particular form of distortion. For example the start or end of a word may be clipped.
  • a further refinement can be thought of as an analog to the hidden images in official documents that result in photocopies or scans of important documents such as passports or driving licences clearly showing "FAKE", "COPY” or similar disparaging words across the resultant copy. These typically exploit the limited (and often standard) resolutions at which photocopiers and scanners sample the image when copying it.
  • a similar mechanism can be employed by the GOTCHA viewer. For example, a particular viewer may be configured to take every Nth row and every Mth column to produce a lower resolution image which was effectively embedded yet hidden within the overall image. This can be combined with the colour mapping or watermarking techniques above to embed a known image within the main image in a way that is very difficult to detect unless the underlying algorithm is known.
  • a more sophisticated form of the above could use a mechanism analogous to the tumblers in the lock of a safe.
  • the rule known to the GOTCHA generator and the GOTCHA client application may involve a known "origin" and a series of angular rotations, each of which applies to a successive concentric ring of pixels about that origin. By rotating each ring of pixels by the appropriate angle and, optionally, applying the colour transformation, watermarking or other operation, a hidden image may be revealed.
  • any algorithm can be used that provides for a wholly or largely reversible manipulation of one image or a combination of a second ("watermark") image with a primary image.
  • the encoding algorithm is implemented in the GOTCHA server application to generate the GOTCHA while the decoding algorithm is implemented in the GOTCHA client to restore the image or images.
  • the algorithm allows the exact reconstruction of the original image or images, it is easy to build an automated test harness that generates test images - typically including randomly generated ones which, to the human, appear as a random mess of multicoloured pixels.
  • a GOTCHA is generated. This can be compared against the original image(s) using well known image comparison techniques to gain a measure of how well obfuscated each of the original images is.
  • the original image(s) should be restored.
  • every pixel should be identical to that of the original image - allowing for an automated certification process.
  • the recovered image is, for example, blurred or has reduced colour depth compared to the original, then more sophisticated techniques must be used to determine whether or not the algorithm has succeeded. Such algorithms could include deliberate reduction of colour depth, edge-blurring etc.
  • the similarity between the original image(s) and resultant image(s) can be measured using the same tools by which the obfuscation was measured - but this time a "good" score is a high similarity with the original image.
  • a sophisticated GOTCHA viewer can extract the various hidden images from within the main one and display all of these for the user to view. Even without being told, the user will rapidly learn several facets of a valid GOTCHA and be aware of a fake should any of these not be present. Unlike the green address bar of a browser that tells us that a website has a valid certificate, the level of instant comfort and confidence that is gained by seeing a sophisticated GOTCHA displayed - especially with the simulated "watermark” and "ultraviolet” renderings alongside the original - allows the user to feel much more a part of the validation process than relying on the invisible "magic" of the cryptographic techniques that may also be being used in the reception of the message.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un système et un procédé selon lesquels il est possible de déterminer rapidement si une communication provient d'un expéditeur autorisé ou, à l'inverse, si elle est identifiée comme provenant d'un imposteur. Contrairement aux schémas standard de chiffrement et de signature numérique, cette invention permet au destinataire humain d'identifier rapidement des messages frauduleux en reconnaissant si le jeton numérique associé ou non au message respecte au moins une règle prédéfinie, même si le système présentant le message n'a pas connaissance de ces règles, ou même du processus d'authentification dans sa globalité.
PCT/GB2013/052779 2012-10-25 2013-10-24 Système et procédé d'authentification de communications WO2014064451A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB1219235.7 2012-10-25
GB1219235.7A GB2507315A (en) 2012-10-25 2012-10-25 Authentication of messages using dynamic tokens
EP13187754 2013-10-08
EP13187754.0 2013-10-08

Publications (1)

Publication Number Publication Date
WO2014064451A1 true WO2014064451A1 (fr) 2014-05-01

Family

ID=49753418

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2013/052779 WO2014064451A1 (fr) 2012-10-25 2013-10-24 Système et procédé d'authentification de communications

Country Status (1)

Country Link
WO (1) WO2014064451A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070162394A1 (en) * 2004-02-12 2007-07-12 Iconix, Inc. Rapid identification of message authentication
US20110162078A1 (en) * 2009-12-24 2011-06-30 Ebay Inc. Dynamic pattern insertion layer
US20110173273A1 (en) * 2010-01-14 2011-07-14 Motiondrive Ag Method and system for inhibiting phishing

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070162394A1 (en) * 2004-02-12 2007-07-12 Iconix, Inc. Rapid identification of message authentication
US20110162078A1 (en) * 2009-12-24 2011-06-30 Ebay Inc. Dynamic pattern insertion layer
US20110173273A1 (en) * 2010-01-14 2011-07-14 Motiondrive Ag Method and system for inhibiting phishing

Similar Documents

Publication Publication Date Title
US9253131B2 (en) System and method for authentication of communications
US9450969B2 (en) System and method for key challenge validation
JP4948400B2 (ja) 電子メッセージ認証を与える方法及び装置
CA2584082C (fr) Procede et appareil apportant une authentification mutuelle entre une unite d'envoi et un destinataire
JP5133248B2 (ja) クライアント／サーバー認証システムにおけるオフライン認証方法
CN104683650B (zh) 认证装置、认证方法以及具备该认证装置的图像形成装置
CN103678960B (zh) 在数据文件中添加数字版权信息的方法及装置
Rizzo et al. Content-preserving text watermarking through unicode homoglyph substitution
JP2010067096A (ja) 認証装置、認証方法、情報処理プログラム及び記録媒体
JP2006244474A (ja) インターネットを介して識別情報を安全に開示する方法およびシステム
WO2014091252A1 (fr) Perfectionnements se rapportant à l'authentification d'identifiant
Martin Cryptography: The key to digital security, how it works, and why it matters
US8898733B2 (en) System security process method and properties of human authorization mechanism
Bertini et al. Can information hiding in social media posts represent a threat?
EP3350973B1 (fr) Procédé d'authentification de site de la toile et de sécurisation d'accès à un site de la toile
EP3017421B1 (fr) Procédé d'impression d'éléments graphiques de sécurité interdépendants
WO2014064451A1 (fr) Système et procédé d'authentification de communications
EP2005379B1 (fr) Sécurisation de transaction électroniques sur un réseau ouvert
Mansfield-Devine Bad behaviour: exploiting human weaknesses
Mantoro et al. Real-time printed document authentication using watermarked qr code
Suoranta et al. Electronic citizen identities and strong authentication
JP2010079515A (ja) 認証システム、そのシステムに用いるキー、認証方法およびプログラム
AU2021100429A4 (en) Printed document authentication
Usop et al. A Review of Digital Watermarking Techniques, Characteristics and Attacks in Text Documents
FR2961330A1 (fr) Procede de securisation des interactions utilisateur sur un terminal hostile

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13802695

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13802695

Country of ref document: EP

Kind code of ref document: A1