TTF/OTF file encryption or protection

Hello!
can anyone help me how to encrypt/protect a ttf/otf font file so that it could not be copied or used. Actually I am Arabic/Urdu font developer, I had developed many fonts, now I want to sale my fonts, but I need a protection that my font will run only on that system, which is allowed by me. I want to apply protection to avoid piracy of my fonts. 
How it could be done? 
Some font foundries are using a technique. they encrypt font file, you can not access its OT tables, you will be able to see fonts glyphs only.  But the allow use of their font through their plugin which allows to run font only on that computer which is  the original buyer of that font. otherwise you will not be able to access that font file. 
How it could be done, Any body can help me in this regard?
Thanks.

Comments

  • Some font foundries are using a technique.
    Which foundries?
  • The problem with any kind of font encryption is that it must be breakable, or else it won't work!

    What I mean is that if the font is to work with any application, then at some point the application must pass the complete, unencrypted font to a system font service (CoreText, Harfbuzz, DirectWrite, etc.). At which point a malicious application can simply write the unencrypted font file to disk.
  • Paul van der LaanPaul van der Laan Posts: 242
    edited August 2021
    You might want to have a look at https://type.world/

    Type.World is a distribution system for fonts developed by Jan Gerner (AKA Yanone) where the foundry can have pretty precise control about how many copies of a font a licensee can install. It can also notify the licensee of font updates, and many other things.
  • Some font foundries are using a technique.
    Which foundries?
    maryamsoft and axissoft for their plugin
  • What Simon said above is essentially correct: unless your fonts are tied to quite specific usages / applications, they are always interceptable in the unencrypted form at the OS's renderer's entry point CoreText, DirectWrite/GDI, Harfbuzz/Freetype, etc. So it just cannot be done. I personally can modify freetype to dump what it receives - it is a useful debugging technique to inspect only the received data triggering a bug, for example.

    Regarding specific usages/applications though, I have an impression that the Adobe typekit does that? Ie. Fonts are downloaded from Adobe servers etc and kept in some virtual disk location, and are tied to the user's creative cloud subscription. Such fonts are also only visible to Adobe family of applications, Illustrator, Photoshop, etc?
  • Marc OxborrowMarc Oxborrow Posts: 220
    edited August 2021
    @Hin-Tak Leung — On the Mac side, fonts activated via Adobe Fonts are visible to all applications, not just those in the Adobe Creative Cloud family. I don't have any experience with Adobe Fonts on Windows.
  • I agree with all of the above. Regarding the technical feasibility of protecting fonts: Adobe Fonts are also just OTF/TTF files stored in a folder. They are placed in a hidden folder and have cryptic names, but that’s it. My tool fontpath gives you the path of a font file on a Mac by its font or family name. I developed it for other, legitimate uses (mainly for use with the HarfBuzz shape tool). The tool is not complicated; two system-provided functions do practically all the work, the rest of the code just handles input/output and errors.

    And for Adobe Fonts I can see why they want to hide and copy-protect their files: it’s a subscription. Once you are no longer a subscriber, you should lose access to the font files. But for any perpetual desktop license, I would not accept having to install a custom font provider for just a single font family. As @Paul van der Laan pointed out, type.world would at least aggregate multiple vendors and thus just require a single font provider app, but I can not imagine its font protection to be bulletproof either.
  • On Windows any decent font manager is able to get access to fonts that are visible to all applications. Better put your time and effort into making and marketing your fonts.
  • Rob BarbaRob Barba Posts: 86
    edited August 2021
    Some font foundries are using a technique.
    Which foundries?
    I wonder if he's referring to Letterhead Fonts' DRM system (and I use that term loosely as it's not really DRM as just encryption).  I mention this as I found out about it when I bought one of their fonts earlier this year.
  • Thomas PhinneyThomas Phinney Posts: 2,730
    edited August 2021
    Although it is a kind of encryption, Letterhead’s FontGuard system is not what most people would think of, in that regard. The font is not encrypted: additional information about the purchaser is hidden (and presumably encrypted) in the font file.

    (I have kicked around ideas for how to do this with other people in the past, thought of numerous approaches to doing it. Anybody on the foundry side of the fence who wants some ideas, feel free to approach me privately.)
  • I had a quick thought about how to hide purchaser info in a font, and still think it cannot be done.

    The easiest way is to add a new custom opentype table, like a DSIG, but for purchaser info. A harder one would be some steganographic technique spreading the info across tiny repositioning of the glyph nodes, or an unused glyph.

    However, any such technique has one problem: it makes two copies of the font different. As the change must not affect the font's functioning, such technique can always be beaten by comparing two copies of the font, and just removing the differing parts. Yes, the pirate needs to buy two copies instead of one; that only makes it more costly for them, just not particularly hard to break.


  • Florian PircherFlorian Pircher Posts: 171
    edited August 2021
    Pirates don’t buy licenses. Even if, I cannot imagine a pirate (at least most) comparing e.g. the glyph order of two fonts and changing it manually to escape fingerprinting. However, such fingerprinting techniques may break compatibility if multiple designers with their own font files collaborate.
  • Hin-Tak LeungHin-Tak Leung Posts: 359
    edited August 2021
    I disagree with both statements. Not fonts, but I have heard stories of sharing licenses, where website makes a real purchases then charges a subscription fees for his clients for sharing his collections of software. If fingerprinting is used, fingerprinting is to be applied at the point of distribution, ie when the distribution channel generates a fingerprinted copy of the font from combining a master copy and purchaser's info. That's way way after font designers finish designing and collaborating. How the designer(s) collaborate is irrelevant, as fingerprinting is implemented at purchase/distribution side. If you are talking about designers each having their own different font files working on the same project, maybe you don't understand steganography - glyphs visually the same can still contain subtle identifying info.

    But these are all intellectual exercises - fonts, to be usable system-wide, are interceptable at the OS's renderer; finger-printing techniques trying to identify and ban bad buy-once-resale-many customers are breakable by getting two copies and strip away the difference. You can write a little python script wrapping ttx fonttools to do that, for example.
  • If you are talking about designers each having their own different font files working on the same project, maybe you don't understand steganography - glyphs visually the same can still contain subtle identifying info.
    That is what I mean by glyph order. Two font files can contain the exact same tables with only the glyph order differing. That way, you can encode the fingerprint as a unique glyph order. First buyer gets the glyph order A J T Q G …, next buyer gets a glyph order of E C J S L …, and so on. Store the random glyph order in a database for each purchase. Randomizing parts of the glyph order are just an example of fingerprinting. One can also, as you suggested, add superfluous nodes to glyph paths, or add a signature table, or add zero width spaces to the glyph description field, etc. Each method has its own benefits and drawbacks. Randomizing the glyph order bloats the cmap table and breaks software storing glyph ids, but keeps outlines equal.

    Once somebody TTXs your font files, its game over. But at that point they are unlikely to be a potential buyer, even with improved file protection.
  • Hmm, you need to read up on steganography. Messing with glyph order is stupid - many programs use glyph id directly instead of going via charmap. There is no need to store any thing (let alone glyph order...) on any external database. Just hashing the transaction / purchase number would do. You need to read up on hashing functions. The typical designers are unlikely to have more than 4 billion customers, so a 32-bit hash function (or even 16) to hide 32-bit is sufficient.

    As for where one hides the hashed bitstream - even tiny zero-width user-invisible contours on the .notdef glyph, for example, is far less obvious and less detectable (and breaking) than glyph order. Let's try another example: just shaking/jittering the O shape (which has at least 16 control points, or 32 co-ordinates) by 1 or 0, which is 1 part in 2048, and invisible at any reasonable rasterization (how often do you ask for point size 256?) due to hinting and fit-to-grid.

    And that goes to another area of hiding: it is also possible to hide 32-bit of information in hinting instructions which are present but totally used by any glyph at any resolution, in the form of garbage-filled user-defined routines, for example. Since it is not used, it can contain arbitrary stuff.

    Glyph order is just too visible and too breaking.
  • The glyph order is just an example; I am not advising its usage as a fingerprint. I pointed out its drawbacks. Messing with outlines in every delivered file also has drawbacks. If e.g. a software assumes glyph outlines to never change for the same font and a document of such a software is shared between designers, the software may break.
    Messing with glyph order is stupid […] You need to read up on hashing functions.
    Please avoid such a tone. It’s neither productive nor inviting.
  • Hin-Tak LeungHin-Tak Leung Posts: 359
    edited August 2021
    There are a million ways of doing a task, in this case, trying to combat piracy, poorly, badly and stupidly. I thought the discussion is on why even some of the cleverer ideas do not and cannot work, and not why some of the poor and stupid ones do not.

    In fact quite the opposite: keep talking about silly and stupid ways of DRM, gives the wrong impression that one is cleverer than those silly and stupid ideas... Being cleverer than silly and stupid is not exactly a productive thing.


  • The subject of the discussion was IF encryption were possible, not WHY, clever or not. It appears that your intent is to appear to be clever; however, please be advised that there is nothing in the least clever about ill manners. Your cooperation in this regard would be greatly appreciated.
  • I would say the concensus has reached quite early on in this thread, that encryption is "possible" (but "not worth the trouble"). And moved onto how much effort one needs to spend on increasing level of encryption, versus how easy/hard it is to break such encryption. About the "not worth the trouble" part.

    So, some people want to stay talking about easily breakable encryption; okay...
  • Hin-Tak LeungHin-Tak Leung Posts: 359
    edited August 2021
    On using user-defined functions (the FDEF instruction) in the hinting instruction table, many autohinting programs, at least AFAIK ttfautohint, and possibly Microsoft's visual truetypes too, inserts stock template functions into the prep table, and some of them end up unused. And I think Google's fontbakery or some other font optimizing tool has an option to strip unused FDEF functions out to cut file size (by a mere few bytes... Most people don't bother, given the very little size saving). So hiding hashed serial numbers in FDEF in the prep table is not too noticeable.
Sign In or Register to comment.